RAG'e taze web verisi: edinme, güncellik ve atıf

Kendi belgeleriniz üzerinde erişimle desteklenmiş üretim (RAG) oldukça iyi bilinen bir problemdir: derlem yavaş değişir ve denetim sizdedir. Aynı hattı web'e yönelttiğinizde iki şey değişir. Derlem ayağınızın altında kayar ve pek çok soru bir zaman boyutu kazanır. "Tedarikçinin fiyat sayfası ne diyor" sorusu aslında "şu anda ne diyor" demektir; geçen çeyreğin kopyasından üretilmiş kendinden emin bir yanıt, fark edilmesi zor bir biçimde yanlıştır. Bu rehber veri canlı olduğunda farklılaşan kısımları ele alıyor: her yanıtın ne kadar taze olması gerektiğine karar vermek, sayfaları edinmek, kaynak bilgisini kaydetmek, atıf için parçalamak, zamanı hesaba katarak sıralamak ve sessiz kaymaya izin vermeden yenilemek.

"Canlı"nın ne anlama geleceğine karar verin

Tazelik tek bir gereksinim değildir. Beklediğiniz soruları, yanıtlarının ne kadar hızlı değiştiğine ve eskimiş bir yanıtın neye mal olacağına göre gruplayın:

Bu tablo üç mimariye işaret eder. Soru anında getirme, bir arama API'sini çağırır, ilk sonuçları indirir ve çıkarılan metni modele verir. Tanımı gereği tazedir; ama daha yavaştır, yeniden üretilmesi zordur ve başkasının sıralamasına bağımlıdır. Önceden dizinleme, sayfaları önceden edinir, dizine ekler ve yanıtları dizinden üretir. Hızlı ve tekrarlanabilirdir; ama ancak son yenileme kadar tazedir. Üretimdeki sistemlerin çoğu sonunda karma bir yapıya varır: önemli olduğunu bildiğiniz kaynaklar için bakımı yapılan bir dizin, geri kalan uzun kuyruk için soru anında arama. İlk ikisi arasındaki ödünleşimi vektör veritabanı olmadan aramaya dayalı RAG yazısı ele alıyor; bu rehberin geri kalanı her ikisi için de geçerli.

Edinme: sıkıcı ama güvenilir yolu seçin

Bir kazıyıcıya uzanmadan önce sitenin sunduğu en yapılandırılmış kanalı kullanın:

• Beslemeler ve site haritaları. RSS ya da Atom beslemeleri ve lastmod değerleri içeren XML site haritaları, her şeyi indirmeden neyin yeni olduğunu söyler.
• Resmî API'ler ve veri indirmeleri. Daha temiz veri sunar, çoğu zaman açık kullanım koşullarıyla gelir.
• Arama API'leri. URL'leri önceden bilmediğinizde keşif için. Bkz. web arama API'si nedir.
• Bilinen URL'leri indirmek. Başsız tarayıcıyı yalnızca içeriğin görünmesi için JavaScript gerektiğinde kullanın.

Ardından sayfanın tamamını değil, ana içeriği çıkarın. Menüler, çerez bildirimleri ve "ilgili haberler" şeritleri erişimi zehirler; çünkü sayfalar arasında tekrarlanır ve pek çok sorguyla eşleşir. Şablon metin ayıklama ve üst veri konusunu makale çıkarma rehberi anlatıyor. Robots kurallarına ve site koşullarına baştan sona uyun. Saklamanıza izin verilmeyen bir kaynak, soru anında indirme teknik olarak çalışsa bile kalıcı bir dizin için aday değildir.

Kaynak bilgisi her parçayla birlikte taşınır

Canlı web dizininde getirilen bir pasajla ilgili en önemli soru, ilgili olup olmadığı değil, nereden ve ne zaman geldiğidir. Bunu yalnızca belgeye değil, her parçaya yazın:

{
  "chunk_id":      "sayfa-anahtari:fiyatlar/ekip-paketi:2",
  "url":           "https://tedarikci.example.com/fiyatlar?ref=nav",
  "canonical_url": "https://tedarikci.example.com/fiyatlar",
  "retrieved_at":  "YYYY-MM-DDThh:mm:ssZ",
  "published":     null,
  "modified":      "YYYY-MM-DD",
  "heading_path":  ["Fiyatlar", "Ekip paketi"],
  "content_hash":  "sha256:...",
  "source_type":   "tedarikçi sayfası",
  "status":        "current",
  "text":          "..."
}

retrieved_at dürüst zaman damgasıdır: sayfa o anda bunu söylüyordu. modified sitenin kendi beyanıdır; eksik ya da yanlış olabilir. status güncel parçaları, yerini yenisine bırakmış olanlardan ve o arada kaybolan sayfalardan ayırır. Bu alanlar olmadan "bu ne zaman doğruydu" sorusunu yanıtlayamazsınız; model de yanıtlayamaz.

Yalnızca bulunabilirlik için değil, atıf için parçalayın

Parçalama önerilerinin çoğu erişim kalitesini en iyilemeye odaklanır. Web verisinde ikinci bir hedef daha koyun: her parça alıntılanabilir ve kolayca bulunabilir olmalı.

• Yapıya göre bölün. Sabit boyutlara dönmeden önce başlıkları, liste sınırlarını ve tablo kenarlarını kullanın. Ortadan ikiye bölünmüş bir fiyat tablosu, kendinden emin yanlış yanıtlar üretir.
• Bağlamı parçaya taşıyın. Her parçanın başına sayfa başlığını ve başlık yolunu ekleyin; böylece "Ekip paketi şunları içerir" cümlesi tek başına da anlam taşır.
• Kimlikleri kararlı tutun. Parça kimliklerini kanonik URL, başlık yolu ve konumdan türetin; böylece tek bir bölümü değiştiren bir yenileme bütün sayfayı yeniden numaralandırmaz.
• Site genelinde tekrarlanan şablon metni dizinlemeden önce atın; yoksa sonuçlarda gerçek içeriği bastırır.
• Konum bilgisini saklayın. Parçanın çıkarılan metinde nerede durduğunu kaydedin; böylece atıf yapılan bir cümle özgün bağlamında gösterilebilir.

Saatin kaç olduğunu bilen erişim ve yanıtlar

Benzerlik aramasının zaman duygusu yoktur. Bunu açıkça ekleyin:

• Yerini yenisine bırakmış ve kaldırılmış parçaları varsayılan olarak eleyin; geçmişe dair sorular için sorgulanabilir tutun.
• Zamana duyarlı soru türlerinde, ilgililik birbirine yakınsa daha yeni alınmış parçaları öne alın; bir parçanın taze bir indirme olmadan kullanılamayacağı en yüksek yaşı belirleyin.
• İstemde her pasajın yanına alınma tarihini koyun ve modelden zamana duyarlı sorularda tarih belirtmesini isteyin.
• Kaynaklar çeliştiğinde, modelin sessizce birini seçmesine izin vermek yerine ikisini de tarihleriyle gösterin.

Atıflar için yanıttaki her iddianın bir parçaya dayanmasını şart koşun ve alıntılanan metnin o parçada gerçekten geçtiğini mekanik olarak kontrol edin. Açılan bir bağlantı, iddiayı destekleyen bir pasajla aynı şey değildir. İlgili hiçbir şey getirilmediğinde doğru yanıt akıcı bir tahmin değil, "kaynak bulunamadı" demektir. Bu hata türünü halüsinasyonları azaltmak için temellendirme yazısı daha ayrıntılı işliyor.

Sessiz kayma olmadan yenileyin

Canlı bir dizin, kurulduğu andan itibaren eskimeye başlar. Yenilemeyi birinci sınıf bir iş olarak ele alın:

1. Sıklığı kaynak bazında belirleyin; her şey için tek bir takvim yerine tazelik tablosundan yola çıkın.
2. Önce ucuz değişiklik kontrollerini kullanın. ETag ya da Last-Modified ile yapılan koşullu HTTP istekleri, site haritası tarihleri ve besleme girdileri, tam indirme yapmadan neyin değiştiğini söyler. Pek çok sayfada yalnızca reklamlar değiştiği için içerik özetlerini çıkarma sonrasında karşılaştırın.
3. Yalnızca değişeni yeniden parçalayın ve vektörleştirin; eski parçaları silmek yerine yerini yenisine bırakmış olarak işaretleyin ki geçmiş yanıtlar açıklanabilir kalsın.
4. Kaybolan sayfaları ele alın. Artık 404 döndüren ya da başka yere yönlenen bir sayfa kaldırılmış olarak işaretlenmeli, eski metni sunmaya devam etmemeli.
5. Önbellekteki yanıtları geçersiz kılın; özellikle değişen parçalara atıf yapanları.
6. Yenilemenin kendisini izleyin. Bir kaynak yenilenemediğinde, çıkarma birden çok daha az metin döndürdüğünde ya da bir sitenin yapısı değiştiğinde uyarı üretin. Yanıt tarafından bakıldığında, haftalardır başarısız olan bir yenileme işi sağlıklı bir işle tıpatıp aynı görünür.

Bazı değişiklikler otomatik yeniden dizinleme yerine bir insanın dikkatini hak eder; değişen bir mevzuat maddesi ya da revize edilmiş bir sözleşme koşulu gibi. Bunlar için sessiz bir güncelleme yerine incelenen bir izleme adımı daha iyi çalışır; bkz. izlemeye başlamadan önce temel çizgi belirleyin.

GoCux nerede devreye girer

GoCux bir web arama API'si değildir ve açık web'i okumaz; dolayısıyla canlı web RAG hattının edinme katmanı değildir. Bilgi arama, bir soruyu tek bir projenin kendi belgeleri içinde yanıtlar ve pasajları atıflarıyla birlikte döndürür. Tam metin arama malzeme içe aktarıldığı anda çalışır; anlamsal erişim ise kullanılabilir olduğunda buna katkı verir. Hatların sıkça birbirine karıştırdığı iki sonucu da ayrı tutar: boş bir sonuç meşru bir yanıttır, kullanılamayan bir arama ise farklı bir durumdur ve öyle bildirilir.

Web sayfaları bir projeye yalnızca yetkilendirilmiş bir tarama ya da dışa aktarma adımıyla ulaşır ve içe aktarılırken özgün sayfa referansını ve alınma tarihini korur; yukarıdaki kaynak bilgisi alanlarını bu sağlar. Güncel kalması gereken sorular için Pulse, seçtiğiniz kaynaklar üzerinde tekrarlanan bir soruyu çalıştırır ve elinizdekinin üzerine sessizce yazmak yerine her değişikliği incelemenize sunar. Bellek bunun yerini tutmaz, çünkü canlı bir akış değildir; taze bilgi yenilenmiş kaynaklardan gelir. İşin hangi kaynaklara dayanabileceğine dair kurallar için kaynak politikası belgelerine bakın.

Canlıya almadan önce kontrol listesi

• Her soru türünün bir tazelik gereksinimi ve bir mimarisi var: soru anında, ön dizinli ya da karma.
• Her kaynağın bir edinme kanalı, saklama izni ve yenileme sıklığı var.
• Ana içerik çıkarılıyor; site şablonları dizinlemeden önce temizleniyor.
• Her parça URL, kanonik URL, alınma zamanı, site tarihleri, başlık yolu, içerik özeti ve durum bilgisi taşıyor.
• Yerini yenisine bırakmış ve kaldırılmış parçalar varsayılan olarak eleniyor ama geçmiş için saklanıyor.
• Yanıtlar zamana duyarlı iddialarda tarih veriyor; alıntılar parçalara karşı kontrol ediliyor.
• "Kaynak bulunamadı" izin verilen bir yanıt.
• Yenileme hataları ve çıkarma anormallikleri, adı belli bir sorumluya uyarı olarak gidiyor.