Sessiz Hatalar: Üretim RAG Sistemleri Neden Hata Vermeden Bozulur?

Üretime yönelik bir RAG sistemi her operasyonel kontrolü geçebilir ve yine de önemli olan tek test olan doğruyu söylemekte başarısız olabilir. İstekler tamamlanır, gecikme hedef dahilinde kalır ve altındaki kanıtlar eksik, eski veya yanlış okunurken oluşturulan metin güvenle okunur.

Bunun nedeni, teknik kullanılabilirlik ve anlamsal doğruluğun farklı özellikler olmasıdır. Bir vektör veritabanı, ilgisiz olsalar bile sonuçları döndürebilir. Bir dil modeli, eksik kanıtlardan tam bir yanıt üretebilir. Bir iş akışı, tüm zincir boyunca yanlış bir değer taşırken her adımı başarıyla gerçekleştirebilir.

Bu nedenle üretim güvenilirliği, çalışma süresinin izlenmesinden daha fazlasını gerektirir. Sistemin doğru kanıtları alıp almadığını, bu kanıtların güncel sürümünü kullanıp kullanmadığını, birden fazla adımda değerleri koruduğunu ve modeller ve veriler değiştikçe sabit kalıp kalmadığını tespit eden mekanizmalara ihtiyaç duyar.

Dört arıza modu özellikle önemlidir: halüsinasyon amplifikasyonu, sıralama kayması, eski bağlam ve retrieval boşlukları. Kullanıcı kötü bir yanıt fark edene kadar her biri görünmez kalabilir. Her birinin farklı bir nedeni vardır ve farklı bir çözüm gerektirir.

Sessiz Başarısızlık Bir Durumdur, İstisna Değil

Geleneksel bir arka uç arızasının sınıflandırılması kolaydır. Bir veritabanı bağlantısı zaman aşımına uğradı, bir istek 500 döndürüyor veya bir şema doğrulayıcı hatalı biçimlendirilmiş girişi reddediyor. Bu olaylar açık operasyonel sinyaller bırakıyor.

Anlamsal bir başarısızlık her teknik sözleşmeyi karşılayabilir:

• İstek geçerlidir.
• Retrieval, beş adet chunks döndürür.
• Model geçerli JSON üretir.
• Yanıt API şemasını geçer.
• Gecikme, hizmet düzeyi hedefi dahilinde kalır.
• Nihai değer yanlış veya desteklenmiyor.

Bu nedenle RAG sistemleri anlamsal gözlemlenebilirliğe ihtiyaç duyar. Günlükler alınan ve oluşturulan verileri kaydetmeli, değerlendirme sürekli olarak yürütülmeli ve bilinen sorular kullanıcı raporlarını beklemek yerine proaktif bir şekilde sorulmalıdır.

Başarısızlık Modu 1: Halüsinasyon Yükseltmesi

Halüsinasyon amplifikasyonu, erken bir hatanın daha sonraki adımlar için kabul edilen bir girdi haline gelmesiyle ortaya çıkar. Hata, her aşağı akış işleminin önceki çıktıyı güvenilir durum olarak ele alması nedeniyle büyür.

Çok adımlı bir satın alma analizini düşünün:

1. Belge çıkarma adımında birim fiyat 150.00 yerine 15.00 olarak okunur.
2. Bir hesaplama adımı yanlış fiyatı satın alınan miktarla çarpıyor.
3. Bir karşılaştırma adımı, tedarikçinin alternatiflerden önemli ölçüde daha ucuz olduğu sonucuna varır.
4. Son sentez, yanlış toplama dayalı bir satın alma kararı önerir.

Sonraki her adım kendi içinde tutarlı olabilir. Hesap makinesi yanlış girişi doğru şekilde çarpıyor. Karşılaştırmada yanlış toplam doğru şekilde kullanılıyor. Açıklama, aldığı sonucu doğru bir şekilde açıklıyor. Tutarlı bir akıl yürütme zincirine sarılmış olduğundan orijinal hatanın görülmesi zorlaştı.

İlk Hatanın Önlenmesi

İlk savunma hattı şema topraklamasıdır. Bir model, yapılandırılmış bir kaynağı sorgulamadan önce tam şemayı, alan tanımlarını, birimleri ve izin verilen işlemleri almalıdır. unit_price_net adlı alan brüt tutar, indirim veya liste fiyatıyla karıştırılmamalıdır.

Belge çıkarma için sistem, her değer için kaynak bölgeyi ve güveni korumalıdır. Kaynak referansı olmayan birim fiyat hesaplamaya girmemelidir.

Aritmetiğin deterministik olması gerekir. Dil modeli, hangi değerlerin bir formüle ait olduğunu seçebilir, ancak hesaplamayı bir hesap makinesi veya yazılan işlev gerçekleştirmelidir.

Adım Sınırlarını Korumak

Ara sonuçlar serbest biçimli düzyazı olarak iletilmek yerine yapılandırılmalıdır:

{
  "product_code": "PRD-482",
  "unit_price": 150.00,
  "currency": "EUR",
  "source": "invoice-2026-0148-line-04",
  "confidence": 0.97
}

Her geçiş daha sonra basit koşulları zorunlu kılabilir:

• Zorunlu alanlar mevcut.
• Sayısal değerlerin sayısal türleri vardır.
• Para birimi ve birimler açıktır.
• Bir kaynak referansı mevcut.
• Güven, otomatik işleme eşiğini karşılıyor.

Bir koşul başarısız olursa iş akışı durmalı veya öğeyi incelemeye yönlendirmelidir. Açıkça boş bir değer, daha sonraki adımların yanlış bir şekilde gerçek olarak yorumlayabileceği belirsiz bir cümleden daha güvenlidir.

Çalışma Zamanı Tutarlılığı Kontrolleri

Yanıt teslim edilmeden önce kullanıcıya görüntülenen değerler, bunları oluşturmak için kullanılan araç çıktılarıyla karşılaştırılmalıdır. SQL, 150.00'i döndürdüyse ve son yanıtta 15.00 belirtiliyorsa yanıtın engellenmesi ve yeniden oluşturulması gerekir.

Bu kontrol veritabanı değerinin doğru olduğunu kanıtlamaz. Bu, dil modelinin generation sırasında kanıtları değiştirmediğini kanıtlıyor. Bu daha dar garanti hala değerlidir ve deterministik bir şekilde uygulanabilir.

Rejenerasyonun ayrıca sınırlı bir arıza yoluna sahip olması gerekir. İkinci deneme hala doğrulanan araç çıktısıyla çelişiyorsa sistem oluşturmayı durdurmalı, kullanıcıya güvenilir bir yanıt sağlayamayacağını söylemeli ve isteğin etkisi yüksek olduğunda izlemeyi bir inceleme kuyruğuna eklemelidir. Tekrarlanan yeniden denemeler yalnızca maliyeti artırır ve tespit edilen tutarsızlığı güvenle ifade edilen bir hataya dönüştürebilir.

Orijinal Hatayı Bulma

Bir izleme sorgunun yeniden yazımını, yönlendirici kararını, araç bağımsız değişkenlerini, alınan satırları veya chunks'i, hesaplamaları, ara durumu ve son yanıtı kaydetmelidir. Bir hata bulunduğunda izleme, hatanın çıkarmadan mı, şema yorumlamadan mı, retrieval'ten mi, hesaplamadan mı yoksa generation'ten mi kaynaklandığını gösterir.

Düzeltilen durum daha sonra golden dataset'e eklenmelidir. Önleme, sınır doğrulama, izleme ve regresyon testleri amplifikasyona karşı tam bir savunma oluşturur.

Başarısızlık Modu 2: Sıralama Kayması

Sıralama kayması, daha önce doğru kanıtı en üstte döndüren bir sorgunun daha düşük sıralamaya başlamasıyla ortaya çıkar. Hiçbir uygulama kodunun değiştirilmesine gerek yoktur. retrieval kalitesi düşerken sistem hızlı ve kullanılabilir durumda kalabilir.

İki neden yaygındır ve bunlar aynı sorun olarak ele alınmamalıdır.

Embedding Alan Değişiklikleri

Bir embedding modelini değiştirmek veya fine-tuning, yeni bir vektör alanı oluşturur. Eski ve yeni modellerin ürettiği vektörlerin karşılaştırılabilir olduğu varsayılamaz. Bunları tek bir endekste karıştırmak tutarsız sıralamalara neden olur.

Güvenli bir geçiş şunları gerektirir:

1. Orijinal kaynak metni vektör dizininden bağımsız olarak koruyun.
2. Yeni model için ayrı bir dizin oluşturun.
3. Tüm derlemi tek bir sabitlenmiş model sürümü ve konfigürasyonuyla yeniden yerleştirin.
4. embedding model sürümünü meta veri olarak saklayın.
5. Altın retrieval setini yeni dizine göre çalıştırın.
6. Bir takma ad veya yapılandırma değişikliği yoluyla trafiği atomik olarak değiştirin.
7. Geri alma için eski dizini geçici olarak saklayın.

Bir canlı dizin içindeki vektörlerin aşamalı olarak değiştirilmesi, sıralamaların tutarlı bir anlam taşımadığı, kısmen taşınmış bir koleksiyon bırakabilir.

Corpus Büyümesi

Sıralama, model değişmeden kaldığı halde derlem büyüdüğünde de düşebilir. Bir zamanlar 10.000 pasajı arayan bir ürün sorgusu, daha sonra benzer terminolojiye sahip yüz binlerce yeni pasajla rekabet edebilir.

Aynı model ile aynı metni yeniden embedding olarak kullanmak bu kayma biçimini çözmez. Vektörler bozuk değil; sıralama rekabeti değişti.

Teşhiste hangi sorgu kategorilerinin kalitesinin düştüğü sorulmalıdır:

• Şirket, tedarikçi veya ürün filtreleri eksikse sorun sorgunun anlaşılmasında veya yönlendirilmesinde olabilir.
• Filtreleme doğruysa ancak ilgili pasajlar kötü sıralanıyorsa, reranking, chunk kalitesi veya aday derinliği sorumlu olabilir.
• Geniş filtrelenmemiş aramaların kalitesi düşerse dizin parametreleri, top-k ve reranker kapasitesinin ayarlanması gerekebilir.
• Tam tanımlayıcılar başarısız olursa, sözcüksel retrieval yolda eksik olabilir.

Altın veri kümeleri külliyatla birlikte büyümelidir. Yalnızca eski ürünleri içeren bir kıyaslama, yeni eklenen bilgiler için retrieval kalitesi hakkında hiçbir şey ortaya çıkarmazken geçmiş sorguların hala çalıştığını doğrulayabilir.

Sıralamadaki Kaymayı Tespit Etme

Retrieval ölçümleri yalnızca sürümler sırasında değil, zaman içinde izlenmelidir:

• Recall ve k
• Ortalama Karşılıklı Sıra
• Normalleştirilmiş indirimli kümülatif kazanç
• Benzerlik puanı dağılımı
• Reranker puanı dağılımı
• Düşük güven oranı retrieval
• Sorgu kategorisine göre doğru kaynak sıralaması

embedding geçişinden sonraki ani değişim, vektör uzayı tutarsızlığına işaret ediyor. Derlem büyümesiyle ilişkili kademeli bir düşüş, rekabeti, filtrelemeyi veya sıralama kapasitesini akla getirir.

Açıklayıcı bir derlem büyüme olayını düşünün: Ürün fiyatı sorguları için Recall@10, üç hafta içinde 0.91'ten 0.74'e düşerken gecikme ve hata oranları sabit kalır. Düşüş, 40.000 yeni, benzer ifadelere sahip pasajın dizine girip eski ürün kayıtlarıyla rekabet etmesiyle başlıyor. Metriğin sorgu kategorisine göre ayrılması, en çok etkilenen ürün kodlarının olduğunu ortaya koyuyor; meta veri filtreleri eklemek, aday derinliğini artırmak ve sözcüksel artı yoğun bir reranker uygulamak, Recall@10'i 0.89'e geri yükler. Rakamlar tek başına düzeltmeyi belirlemez ancak yanıt kalitesiyle ilgili belirsiz bir şikayeti test edilebilir bir retrieval hipotezine dönüştürür.

Başarısızlık Modu 3: Güncelliğini Yitirmiş Bağlam

Eski bağlam, daha yeni bir kaynak mevcut olsa veya olması gerekse bile sistemin eski bir bilgi sürümünden yanıt vermesi anlamına gelir.

İki farklı senaryo var.

Ingestion Gecikme

Yeni bir fiyat listesi veya fatura geldi ancak kuyrukta bekliyor, ayrıştırılması başarısız oldu veya henüz eklenmedi. Veritabanı hiçbir zaman aranabilir hale gelmeyen verileri geri getiremez.

ingestion pipeline bir durum makinesini açığa çıkarmalıdır:

received → validating → parsing → embedding → indexing → searchable

Her belgenin zaman damgalarına, duruma, yeniden deneme sayısına, model sürümüne ve hata nedenine ihtiyacı vardır. İzleme, her aşamada kaç belgenin beklediğini ve bunların ne kadar süre orada kaldığını ortaya çıkarmalıdır.

Bir sistem, ilgili belgeler hala beklemedeyken endeksinin güncel olduğunu iddia etmemelidir. Zamana duyarlı istekler için yönlendiricinin ingestion durumunu kontrol etmesi veya yapılandırılmış kaynağı doğrudan sorgulaması gerekebilir.

Rakip Versiyonlar

Eski sürüm mevcut kalırken yeni belge zaten dizine eklenmiş olabilir. Genel bir anlamsal arama, tazelik açık bir şekilde temsil edilmediği sürece her ikisini de getirebilir.

Her kayıt, kaynak tarihi, geçerlilik süresi, ingestion zamanı ve sürümü gibi temporal meta verilerini içermelidir. retrieval politikası daha sonra aşağıdakileri ayırt edebilir:

• En yeni etkili kaydı tercih etmesi gereken mevcut durum soruları
• İstenilen döneme göre filtrelenmesi gereken geçmiş sorular
• Birkaç versiyon gerektirebilecek karşılaştırmalı sorular

Eski veriler her zaman silinmemelidir. Tarihsel analiz buna bağlıdır. Doğru çözüm, gelişigüzel kaldırma değil, temporal yönlendirme ve filtrelemedir.

Kullanıcıların hangi sürümün sonucu desteklediğini görebilmesi için nihai yanıtta ilgili tarih veya dönem belirtilmelidir.

Başarısızlık Modu 4: Retrieval Boşlukları

Kaynakta ve dizinde doğru bilgi mevcut olduğunda ancak arama yolu bu bilgiyi almakta başarısız olduğunda bir retrieval boşluğu oluşur. Sistem hâlâ bir şeyler döndürüyor; genellikle düşük puanlı ancak makul bir pasaj.

Retrieval boşlukları genellikle üç kategoriye ayrılır.

Bozuk veya Bağlamdan Bağımsız Chunks

Bir tablo, ürün kodu bir chunk'te ve birim fiyatı diğerinde olacak şekilde bölünebilir. “Yüzde 20 oranında artırılan tutar” gibi bir ifade, hangi tutarı ve dönemi tanımladığını belirten başlığını kaybedebilir.

Çözüm ingestion'e aittir:

• Belgeleri düzen farkındalığıyla ayrıştırın.
• Tablo başlıklarını ve satırlarını bir arada tutun.
• Bölüm hiyerarşisini koruyun.
• Bağımsız olarak belirsiz chunks'e bağlamsal başlıklar ekleyin.
• Kaynak koordinatlarını ve ebeveyn-çocuk ilişkilerini saklayın.

Hiçbir sorgu dönüşümü, tutarlı bir geri alınabilir birim olarak hiçbir zaman depolanmayan bilgileri güvenilir bir şekilde kurtaramaz.

Sorgu ve Belge Terminolojisi Farklı

Belgede "net birim maliyet" kullanılırken kullanıcı "satın alma fiyatı" isteyebilir. Embeddings genellikle bu boşluğu doldurur ancak alan terminolojisi ve kısaltmalar yine de gözden kaçmaya neden olabilir.

Sorgunun yeniden yazılması, derlem terminolojisini kullanarak isteği genişletebilir. Yeniden yazılan sorgu, kontrollü eşanlamlılar eklerken orijinal varlıkları, tarih aralığını ve amacı korumalıdır. Yanlış bir yeniden yazma yeni bir hata yaratabileceğinden dönüşümün kendisi izlenmeli ve değerlendirilmelidir.

Tam Tanımlayıcıların Anlamları Zayıftır

Ürün kodları, fatura numaraları ve belge kimliklerinin anlamlı anlamsal komşuları olmayabilir. Yoğun retrieval, korpusta tam dize mevcut olsa bile bunları gözden kaçırabilir.

Hibrit arama sözcüksel bir kanal ekler. BM25 tam belirteçleri alırken yoğun retrieval açıklayıcı içeriği yakalar. Fusion ve reranking iki aday seti birleştiriyor.

Kritik yapılandırılmış değerler kesinlikle retrieval metnine bırakılmamalıdır. Doğrulanmış birim fiyatlar ve toplamlar ilişkisel tablolarda saklanıyorsa yönlendiricinin tam sayısal soruları SQL'e göndermesi gerekir.

Retrieval Boşluklarını Algılama

Düşük puanlı ve boş retrieval olaylarının günlüğe kaydedilmesi gerekir ancak bunlar yeterli değildir. Bazı sistemler, hiçbiri kullanışlı olmasa bile her zaman k sonuçlarını döndürür.

Tespit şunları birleştirmelidir:

• Altın rengi bir retrieval setinde recall bağlamı
• En yüksek benzerlik ve reranker puanlarının dağılımı
• Sık sık çekimser kalan sorgu kategorileri
• Kullanıcının yeniden formülasyon davranışı
• Düşük güvenirlik sonuçlarının manuel olarak incelenmesi
• Dizinde beklenen chunk'in mevcut olduğunun doğrulanması

Teşhis kanıtları takip etmelidir. Beklenen chunk hatalı biçimlendirilmişse ingestion'i düzeltin. Tutarlıysa ancak terminoloji farklıysa sorgu dönüşümünü iyileştirin. Tam bir kod atlanırsa retrieval sözcüklerini güçlendirin. Her boşluğa aynı çareyi uygulamak yeni gerilemeler yaratır.

İzleme Tabanlı Semantik Gözlemlenebilirlik

Geleneksel günlükler genellikle yalnızca isteği, yanıt kodunu ve gecikmeyi kaydeder. Bir RAG izlemesinin anlamsal yolu yakalaması gerekir:

Original query
→ rewritten query
→ routing decision
→ metadata filters
→ retrieved candidates and scores
→ reranked context
→ prompt
→ tool results and calculations
→ generated answer
→ citations
→ token, cost, and latency data

Bu iz, bir olayın tekrar oynatılmasına ve sınıflandırılmasına olanak tanır. Bu olmadan, "cevap yanlıştı", ilgisiz hizmet günlükleri ve eksik model durumu arasında bir arama haline gelir.

LangSmith ve Langfuse gibi LLM odaklı gözlemlenebilirlik platformları, iç içe geçmiş retrieval, model ve araç aralıklarını yakalamak için pratik başlangıç noktaları sağlar. Platform, istikrarlı izleme yapısını, sürüm meta verilerini, girdileri, çıktıları, puanları ve kaynak isteğe giden bağlantıları korumaktan daha az önemlidir.

İzleme, erişim kontrollerine ve veri saklama politikalarına uygun olmalıdır. Tanımlayıcılar ve puanlar teşhis için kullanılabilir durumda kalırken, hassas kaynak metnin redaksiyona veya kontrollü depolamaya ihtiyacı olabilir.

Gözlemlenebilirliği Risk ve Ölçekle Eşleştirin

Her RAG uygulamasının ilk günde gölge trafiğe, sürekli model tabanlı değerlendirmeye ve büyük bir golden dataset'e ihtiyacı yoktur. Düşük hacimli, düşük riskli bir dahili asistan, yapılandırılmış izlemelerle, küçük bir altın setle, deterministik kontrollerle ve arızaların manuel olarak incelenmesiyle başlayabilir. Trafik, değişiklik sıklığı, mevzuata maruz kalma veya yanlış yanıtın maliyeti arttıkça tüm yığının gerekçelendirilmesi kolaylaşır; örnekleme ve riske dayalı yönlendirme, değerlendirme harcamasını koruduğu değerle orantılı tutar.

Dört Katmanlı Üretim Kontrol Paneli

Retrieval Sağlığı

Boş retrieval oranını, düşük güven oranını, puan dağılımlarını, sentetik veya altın test sorguları için doğru kaynak sıralamasını, dizin boyutunu, ingestion gecikmesini ve filtre kullanımını izleyin. Trendler izole edilmiş değerlerden daha önemlidir.

Cevap Kalitesi

Temellilik ve answer relevancy için örnek üretim trafiği. Alıntı kapsamını, doğrulanmış alıntı desteğini, çekimser kalma oranını, şema doğrulama hatalarını ve çalışma zamanı tutarlılık kontrolü hatalarını izleyin. Ragas, DeepEval ve Arize Phoenix, faithfulness veya topraklama, yanıt alaka düzeyi ve retrieval alaka düzeyi gibi ölçümler için uygulamalar sağlar. Alıntı kapsamı deterministik bir ölçüm olarak kalabilir: alıntı desteğinin alıntılanan metne göre ayrı ayrı kontrol edildiği, geçerli bir kaynağa bağlı gerçek iddiaların veya yanıt bölümlerinin payı.

Son derece düşük bir çekimserlik oranı, modelin kanıtlar eksik olduğunda bile yanıt verdiğini gösterebilir. Son derece yüksek bir oran, retrieval'in bozulmasına işaret edebilir.

Operasyonel Sağlık

P50, P95 ve P99 gecikmesini yalnızca uçtan uca değil, aşama aşama izleyin. Retrieval, reranking, generation modeli ve araçların ayrı aralıkları olmalıdır. İstek başına belirteçleri, rota başına maliyeti, zaman aşımlarını, yeniden denemeleri ve kuyruk derinliğini izleyin.

Kullanıcı Sinyalleri

Açık derecelendirmeler faydalıdır ancak seyrektir. Örtülü davranış sessiz başarısızlıkları ortaya çıkarabilir:

• Kullanıcı aynı soruyu farklı ifadelerle tekrarlar.
• Oturum, yanıtın hemen ardından sona erer.
• Bir yanıt birkaç kez yeniden oluşturulur.
• Bir sorgu kategorisi orantısız olumsuz geri bildirim alıyor.

Kısa bir süre içinde yeniden formülasyon özellikle değerlidir çünkü çoğu zaman ilk cevabın isteği karşılamadığını gösterir.

Anlamsal Sağlık Kontrolü Olarak Sentetik ve Altın Sorgular

Sentetik ve altın test sorguları, bir programa göre üretime karşı çalıştırılan bilinen küçük bir soru kümesidir. Uygulama düzeyinde bir durum kontrolü görevi görürler. Bazen anlamsal kanaryalar olarak adlandırılırlar, ancak bunlar planlanmış araştırmalardır; canlı kullanıcı trafiğini kademeli olarak aday bir sürüme kaydıran canary sürümüyle aynı mekanizma değildir.

Test seti şunları içermelidir:

• Tam ürün kodu retrieval
• Güncel ve geçmiş fiyat araması
• Çoklu belge soruları
• Çekimser kalmayı gerektiren sorular
• Son eklenen belgelere ilişkin sorgular
• Bilinen çıktılarla kritik hesaplamalar

Sistem, alınan kaynakları, yapılandırılmış çıktıları ve nihai yanıtları beklenen değerlerle karşılaştırmalıdır. Bir arıza, sıradan kullanıcılar bildirmeden önce bir yukarı akış model değişikliğini, dizin sorununu, eski ingestion pipeline veya prompt gerilemesini tespit edebilir.

Arızaların tek bir farklılaşmamış uyarı üretmek yerine, etkilenen yeteneği tanımlaması için sorgular sürümlendirilmeli ve etiketlenmelidir.

Gölge Dağıtımları ve Canary Sürümleri

Yeni bir prompt, model, chunking stratejisi veya dizin, kullanıcılara yanıtlarını göndermeden üretim trafiğinin bir kopyasını alabilir. Daha sonra mevcut ve aday sistemler aynı talepler doğrultusunda karşılaştırılır.

Gölge değerlendirmesi şunları incelemelidir:

• Rota farklılıkları
• Alınan kaynak çakışması
• Sıralama değişiklikleri
• Yapılandırılmış değer anlaşması
• Faithfulness ve alaka düzeyi
• Gecikme ve maliyet

Sonuçlar kabul edilen eşikler dahilinde kalırsa trafik, yüzde 5, yüzde 25 ve tam dağıtım gibi aşamalardan kademeli olarak ilerleyebilir. Bu aşamalı gösterim bir canary sürümüdür: yukarıda planlanmış sentetik sorgulardan farklı olarak, bir adayı kontrollü bir canlı trafik payına sahip olarak değerlendirir. Yeni sürüm kararlı hale gelinceye kadar geri alma mümkün kalmalıdır.

Gölge trafiği özellikle sessiz hatalar için değerlidir çünkü test veri kümeleri her üretim sorgu modelini temsil edemez.

Sürekli Çevrimiçi Değerlendirme

Her üretim tepkisini ikinci bir modelle değerlendirmek çok pahalı olabilir. Örnekleme en yüksek değere sahip trafiği hedefleyebilir:

• Rastgele bir temel örnek
• Düşük güven gerektiren alımlar
• Olumsuz geri bildirim içeren yanıtlar
• Yüksek değerli hesaplamalar
• Yeni eklenen sorgu kategorileri
• Yeni bir model veya dizin sürümü tarafından sunulan istekler

Odak noktası dağılımlar ve eğilimler olmalıdır. Tek bir düşük temellilik puanı gürültü olabilir. Bir güzergahta veya ürün kategorisinde sürekli bir düşüş, gerçek bir soruna işaret eder.

Dil modeli yargıçları insan açıklamalarına göre kalibre edilmelidir. Kesin sayısal yanıtlar ve araç tutarlılığı, mümkün olan her yerde deterministik kontrolleri kullanmalıdır.

Yalnızca Eşikler Değil, Değişiklikler Hakkında da Uyarı Verme

Statik eşikler faydalıdır ancak anlamsal sistemler bunların üzerinde kalarak yavaş yavaş bozulabilir. Uyarılar aynı zamanda son temel çizgilerden sapmaları da tespit etmelidir.

Örnekler şunları içerir:

• Ayakta kalma durumu yedi günlük ortalamanın önemli ölçüde altına düşüyor.
• En yüksek retrieval puanının ortalama değeri bir dizin güncellemesinden sonra değişiyor.
• Ürün-fiyat sorgularında yeniden formülasyon oranı artar.
• Yeni belgeler biriktikçe Ingestion süresi artar.
• prompt veya top-k güncellemesinden sonra sorgu başına maliyet değişir.
• Bir model sürümü ait olmadığı bir dizinde görünüyor.

İncelemenin hemen başlayabilmesi için uyarılar rota, model sürümü, dizin sürümü ve temsili izleme kimliklerini içermelidir.

Olay Döngüsünü Kapatma

Gözlemlenebilirlik yalnızca olaylar sistemi kalıcı olarak iyileştirdiğinde değer yaratır. Onaylanan her anlamsal hatanın bir yaşam döngüsü takip etmesi gerekir:

1. İzin tamamını yakalayın.
2. Arızalı katmanı sınıflandırın.
3. Doğru kaynağı ve yanıtı doğrulayın.
4. Hedeflenen en küçük düzeltmeyi uygulayın.
5. Kasayı golden dataset'e ekleyin.
6. Düzeltmeyi diğer regresyon kategorileriyle karşılaştırarak test edin.
7. Kontrollü bir dağıtım yoluyla dağıtın.
8. Etkilenen metriği yayınlandıktan sonra izleyin.

Bu süreç, üretim izlemeyi çevrimdışı değerlendirmeyle birleştirir. golden dataset, sistemin tekrarlamasına artık izin verilmeyen arızaların kaydı haline gelir.

Çalışma Süresinin Ötesinde Güvenilirlik

Halüsinasyon amplifikasyonu, sıralama kayması, eski bağlam ve retrieval boşlukları ortak bir özelliğe sahiptir: API'i bozmadan ikna edici yanıtlar üretebilirler. Ancak bunların nedenleri farklıdır. Amplifikasyon korumalı adım sınırları gerektirir. Sıralama kayması, sürümlendirilmiş indeksler ve sürekli sıralama ölçümleri gerektirir. Eskilik, temporal meta verilerini ve ingestion görünürlüğünü gerektirir. Retrieval boşlukları, ayrıştırma, sorgu anlama ve arama yöntemleri genelinde teşhis gerektirir.

Güvenilir RAG sistemleri bu ayrımları görünür kılar. Anlamsal durumu izlerler, sentetik ve altın sorgular çalıştırırlar, aday sürümleri gölge modunda karşılaştırırlar, örneklenen trafiği değerlendirirler ve kullanıcı davranışından öğrenirler. En önemlisi, onaylanan her başarısızlığı bir regresyon testine dönüştürürler.

Bu kontroller ücretsiz değildir. Depolama, değerlendirici harcaması, operasyonel karmaşıklık ve hatalı pozitif veya uyarı yorgunluğu riskini eklerler. Amaç, her yerde maksimum gözlemlenebilirlik değil, uygulamanın başarısızlık maliyetini karşılayacak kadar iyi kalibre edilmiş kanıttır; Bir mühendislik kararını asla değiştirmeyen uyarılar kaldırılmalı veya yeniden tasarlanmalıdır.

API sağlık kontrolü, sistemin yanıt verdiğini kanıtlayabilir. Anlamsal gözlemlenebilirlik, hala doğru yanıt verdiğini kanıtlayan şeydir.