Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Document parsing/indexing ve online query aynı kaynak profiline sahip değildir.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
RAG sisteminde en pahalı hata bazen model değil parsing’dir. PDF tabloları, OCR, chunk yapısı, embedding ve retrieval zincirinden biri bozuksa güçlü LLM de yanlış context alır. Kurulumu belge pipeline’ı üzerinden test edin.
PDF “yüklendi” durumunu başarı saymayın. Rastgele 10 sayfadan tablo, başlık, dipnot ve Türkçe karakterleri retrieval ile doğrulamadıkça ingestion kalitesi bilinmez.
RAGFlow için CPU/RAM kadar ingestion workload önemlidir. Yüzlerce PDF’yi ilk kez parse ederken kaynak kullanımı, normal chat inference döneminden çok farklı olabilir. Initial indexing ve steady-state query kapasitesini ayrı ölçün.
RAGFlow için CPU/RAM kadar ingestion workload önemlidir. Yüzlerce PDF’yi ilk kez parse ederken kaynak kullanımı, normal chat inference döneminden çok farklı olabilir. Initial indexing ve steady-state query kapasitesini ayrı ölçün.
RAGFlow’u VPS üzerinde production için kurun. Docker host, document parser yükü, object/file storage, vector/search katmanı, model endpoint, backup ve ingestion testleri.
Document parsing/indexing ve online query aynı kaynak profiline sahip değildir.
Yanlış chunk sınırı retrieval kalitesini modelden önce düşürür.
RAG cevabının kaynak chunk’a geri izlenebilmesi önemlidir.
Yalnız vector/index yedeği değil ham kaynak dokümanları da koruyun.
Upload, parse, chunk, embed, retrieve ve generate adımlarını ayrı gözlemlemek “model halüsinasyon yaptı” gibi belirsiz teşhisleri azaltır.
| Aşama | Test |
|---|---|
| Parse | Metin/tablo doğru mu? |
| Chunk | Bağlam bölünmüş mü? |
| Embed | Vector üretildi mi? |
| Retrieve | Beklenen chunk top-k’da mı? |
| Generate | Cevap sadece context’e mi dayanıyor? |
OCR/parser ve embedding çağrıları yüzlerce dokümanda CPU/RAM/IO’yu yükseltebilir. Production query ile aynı saate planlamayın.
nprocfree -hdf -hTiostat -xz 1 5 2>/dev/null || truedocker stats --no-streamIndex yeniden üretilebilir olabilir ama ham kaynak kaybolursa yeniden üretim de mümkün olmaz. Retention ve backup değerleri aynı değildir.
Chat model iyi olsa bile embedding modeli/dimension değişimi tüm index’in yeniden üretilmesini gerektirebilir. Provider/model değişikliğini migration olarak yönetin.
| Bileşen | Değişiklik etkisi |
|---|---|
| Chat LLM | Cevap üslubu/reasoning |
| Embedding model | Index uyumluluğu/rebuild |
| Reranker | Top-k sıralama |
Her soru için beklenen source document/page/chunk belirleyin. Model cevabından önce retrieval hit-rate ölçün.
Database/object store yedeği restore olsa bile search/vector service version mismatch query’yi bozabilir. Restore testinde golden set’ten en az birkaç soru çalıştırın.
docker compose psdocker compose logs --tail 120 | grep -Ei "error|fail|oom" || truedf -hTUI’da klasörü gizlemek authorization değildir. Tenant/department/user scope retrieval sorgusuna server-side filtre olarak uygulanmalıdır.
Eka Sunucu VPS/GPU üzerinde RAGFlow parser, vector/search ve model inference katmanlarını tek veya ayrı node’larda workload’a göre planlayabilirsiniz.
Rehber hazırlanırken esas alınan birincil dokümantasyon ve teknik kaynaklar.
İlgili altyapı ve uygulama rehberleriyle devam edin.
RAGFlow VPS
Platform/parsing bazı işlerde CPU ile çalışabilir; local embedding/LLM/OCR workload ve seçilen model GPU ihtiyacını belirler. Remote model API kullanıyorsanız GPU ayrı sunucuda olabilir.
Hayır. Parse edilen metin, tablo, chunk ve retrieval sonucunu örnek sayfalarda doğrulamak gerekir.
Vector dimension/semantic space değişebilir; mevcut index ile uyumluluk garanti değildir ve re-index gerekebilir.
Hayır. RAG sorgu anında dış bilgi kaynağından ilgili context getirir; model ağırlıklarını değiştirmek zorunda değildir.