Mimari ve çalışma modeli
RAG hattı belgeyi doğrudan modele göndermez. Kaynağı ayrıştırır, yetki ve sürüm metadatasıyla parçalara böler, embedding üretir, adayları anahtar kelime ve vektör aramasıyla toplar, gerekirse rerank eder ve yalnız seçilen bağlamı üretim modeline verir. Cevapla birlikte kaynak kimliği, bölüm ve sürüm taşınır.
Parça boyutu tek başına kalite ayarı değildir. Başlık yapısı, tablo ve kod blokları korunmalı; örtüşme tekrar maliyetiyle bağlam devamlılığı arasında ölçülmelidir. Kullanıcı yetkisi retrieval sorgusundan önce filtrelenir. Sonradan çıktı üzerinde belge gizlemek, modelin yetkisiz içeriği görmesini engellemez.
İndeksleme ile sorgu yolu ayrı hata alanlarıdır. Kaynak değişikliği olay kuyruğuna girer, içerik karması ve embedding sürümüyle idempotent güncellenir. Sorgu yolu top-k adayları, filtre sonrası kalanları, reranker skorlarını ve kullanılan alıntıları kaydeder; ham hassas metin telemetriye sınırsız yazılmaz.
- 1Kaynak ve yetki ayrıştırma
- 2Parçalama ve sürümlü embedding
- 3Hybrid retrieval ve reranking
- 4Bağlamlı üretim ve alıntı
Tasarım parametreleri
- Parça bütçesi
- Başlıklarla 350-700 token başlangıç aralığı deneyin; tablo ve kodu anlamsal sınırda tutun.
- Aday sayısı
- İlk retrieval için top-20, reranking sonrası top-5 gibi bir huni kurup recall@k ölçün.
- Yetki filtresi
- Tenant, grup, belge sınıfı ve geçerlilik tarihini ANN aramasından önce uygulanabilir metadata yapın.
- Tazelik SLO'su
- Kaynak değişikliğinin aranabilir sürüme dönüşmesi için örneğin p95 10 dakika hedefi koyun.
Hesap ve uygulama örneği
10.000 doğrulama sorusunda ilgili bölüm ilk 20 adayda 9.300 kez bulunursa recall@20 %93'tür. Reranker doğru bölümü ilk 5'e 8.900 kez taşıyorsa recall@5 %89'dur. Son cevap doğruluğu %84 ise hata bütçesi retrieval, bağlam kullanımı ve üretim olarak ayrı etiketlenmelidir.
Her belge ortalama 18 parça ve her parça metadata ile 3 KB ise bir milyon belge yaklaşık 54 GB ham parça/metin üretir; embedding ve indeks ek yükü ayrıca ölçülür. Boyutlandırma yalnız vektör boyutu × kayıt sayısı hesabına indirgenmez.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
rag-index ingest --source sharepoint --chunk-tokens 512 --overlap 64 --embedding-version e3
rag-eval run --dataset support-v4 --metrics recall@20,mrr,groundedness,citation_precisionHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Doğru belge bulunuyor, cevap yanlış | Üretim modeli bağlamı kullanmıyor veya çelişkili parçalar seçilmiştir. | Retrieval sonucunu cevap isteminden ayırıp groundedness ve citation doğruluğunu ölçün. |
| Bazı kullanıcılar sonuç alamıyor | Yetki filtresi alanı eksik ya da filtre ANN sonrası uygulanıyordur. | Aynı sorguyu kullanıcı/tenant filtresi ve filtre öncesi aday sayılarıyla izleyin. |
| Yeni içerik saatlerce görünmüyor | İndeks kuyruğu, embedding kotası veya idempotency anahtarı takılmıştır. | Kaynak sürümü, kuyruk yaşı, başarısız iş ve indekslenen hash'i karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Belge türleri için ayrıştırma ve parça kurallarını örneklerle test edin.
- Embedding modeli ile vektör boyutunu indeks şemasında sürümleyin.
- Yetki filtresini retrieval öncesi zorunlu kılın.
- Recall@k, MRR, groundedness ve citation precision ölçün.
- Silme ve yetki kaldırma olaylarının indeks etkisini doğrulayın.
- Kaynaksız cevapta güvenli reddetme ve kullanıcı geri bildirimi sağlayın.
İlgili kavramlar
İndeks ve sorgu planı
İndeks, uygun sorgularda taranacak veriyi azaltabilir; her yeni indeks yazma, bakım ve depolama maliyeti getirir. Sütun sırası, seçicilik, filtre ve sıralama gereksinimi birlikte değerlendirilir. Sorgu yavaşlığını yalnız indeks yokluğuna bağlamayın: yanlış tahmin, kilit beklemesi, disk gecikmesi veya gereksiz veri taşıma da neden olabilir. Temsilî sorgunun yürütme planını ve gerçek satır sayılarını inceleyin. Değişikliğin okuma kazancını, yoğun yazma sırasında oluşturduğu maliyetle birlikte ölçün; üretimde kontrolsüz bakım işlemleri başlatmayın.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.