Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
RAG sistemi document ingestion'dan answer generation'a kadar birden çok servis içerir. OCR/extraction, chunking, embedding, vector DB, reranking, LLM ve source citation zincirinin her halkası ayrı latency, kalite ve güvenlik riski taşır. Production RAG tek container değildir.
Workload'a göre değişir. Generation LLM GPU maliyeti yüksek olabilir; milyonlarca dokümanın embedding/indexing işlemi toplu compute ister; yoğun vector search RAM/NVMe tüketir; reranker online latency ekler. Bu yüzden tüm stack tek GPU/RAM hesabıyla boyutlandırılmamalıdır.
Belge extraction/chunking sonrası embedding edilir ve vector DB'ye yazılır. Query embedding adayları getirir, reranker top context'i seçer, LLM cevap üretir ve source metadata ile citation oluşturulur.
Tek sunucu başlangıç için mümkün olabilir; büyümede en çok zorlanan katmanı ayrıştırın.
Retrieval recall, source precision, reranker gain, answer faithfulness ve citation doğruluğu ayrı test setleriyle ölçülmelidir.
Tenant/user permission metadata retrieval filter'larına yansıtılmalıdır. Aksi halde LLM cevap vermese bile unauthorized document chunk retrieval veri sızıntısı olabilir.
Port ve model adlarını kendi stack'inize göre değiştirin.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
curl -s http://127.0.0.1:6333/healthzcurl -s http://127.0.0.1:8080/info | headcurl -s http://127.0.0.1:8000/v1/models | headnvidia-smidf -hBüyük corpus ve semantic retrieval için yaygın çözümdür; küçük sabit içerikte full-context veya klasik search de yeterli olabilir.
Hayır. Ancak top-k adayların kalite sıralamasını geliştirebilir; latency ve compute maliyetiyle birlikte ölçülmelidir.
Retrieval sonucu seçilen context generation modeline gönderilir. Eğer harici API LLM kullanılıyorsa bu context dış sağlayıcıya gidebilir; veri politikası buna göre tasarlanmalıdır.
Belge/token hacmi, günlük query, vector DB, reranker ve LLM modelini iletin; ingestion ve online serving kaynaklarını ayrı planlayalım.