RAG bir ürün değildir.

Teknik akış ile kullanıcı sonucu aynı şey değil

RAG mimarisi “ilgili bilgiyi bulup modele verebilir miyiz?” sorusunu çözer. Kullanıcı ise “doğru bilgiye, doğru yetkiyle, karar verebileceğim kadar güvenerek ulaşabilir miyim?” diye bakar.

Aradaki fark; arayüzden çok ürün kararlarında ortaya çıkar. Hangi kaynakların kapsama girdiği, bilginin ne kadar güncel olduğu, cevabın ne zaman reddedileceği ve kullanıcının hatayı nasıl bildireceği netleşmelidir.

Şöyle bir örnek düşünün: İK politikalarını cevaplayan bir asistan. Soruyu alıyor, doğru dokümanı buluyor, cevabı üretiyor. Ama çalışan "yıllık iznimi devredebilir miyim?" diye sorduğunda bu cevap hangi lokasyon ve hangi sözleşme tipi için geçerli? Akış bunu bilmiyorsa cevap teknik olarak doğru, kullanıcı için yanlış olabiliyor.

Kurumsal bilgi yalnızca içerik değildir

Bir dokümana erişebilmek, o dokümandaki her parçanın herkes tarafından görülebileceği anlamına gelmez. Kullanıcı, grup, kaynak ve hatta belge içindeki hassas bölüm seviyesinde yetki ihtiyacı doğabilir.

Bu yüzden güvenlik sonradan eklenen bir filtre değil; ürün deneyiminin başlangıç koşuludur.

RAG projelerinde en çok takılınan yer genelde burası. Herkes "dokümanları yükleyelim" diyor ama o dokümanın bugün kime, hangi yetkiyle açık olduğunu kimse tam bilmiyor. Maaş tablosu olan bir klasörü yanlışlıkla kapsama almak, bir RAG projesinin güvenini bir günde bitirmeye yeter.

Sözleşmelerde gördüğüm: asıl iş veri hazırlığı

Bunu sözleşmeler üzerinde çalışırken yaşadık. Pilotta birkaç temiz sözleşmeyle her şey çok iyiydi. Daha geniş veriye geçince Word dosyaları, imzalı PDF'ler ve yıllardır yenilenerek devam eden, bağlı bilgileri ortak alanlarda bulunmayan sözleşmeler çıktı. Model bilgi eksik olduğunda da bir cevap vermeye çalıştı, yani tahmin yürüttü.

Çözüm modeli değiştirmek olmadı. Önce veriyi hazırladık: Dosyaları ortak alanlardan toplayıp kriterlere göre kontrol ettik ve temizledik, bunu yaparken modellerden de yardım aldık. Chunk ayarlarını baştan ele aldık; PDF için ayrı, Word ve Excel için ayrı işleme süreçleri kurduk. En uzun süren kısım buydu. Canlıya geçiş ise en kolayı oldu.

Kaynak göstermek güvenin başlangıcıdır

Kullanıcı cevabın hangi belgeye ve hangi bölüme dayandığını görebilmelidir. Fakat kaynak göstermek tek başına doğruluk garantisi değildir. Eski, çelişkili veya sahibi olmayan içerik doğru şekilde bulunmuş olsa bile yanlış iş kararına götürebilir.

RAG projesi aynı zamanda bir bilgi sahipliği ve içerik yaşam döngüsü projesidir.

Eski bir doküman, doğru bulunmuş olsa bile yanlış sonuç doğurur. O yüzden her kaynağın bir sahibi ve bir son güncelleme tarihi olmalı. Ben kaynak listesinde "bu dokümanın sahibi kim?" sorusunun cevabı yoksa o kaynağı kapsama almamayı öneriyorum.

Ürün, cevap üretmekten sonra başlar

Kalite ölçümü, geri bildirim, erişim politikaları, maliyet, gecikme, izleme ve operasyon sorumluluğu görünür olduğunda teknik akış bir ürüne dönüşmeye başlar.

Bu nedenle ilk soru “hangi vektör veritabanını kullanalım?” değil, “kimin hangi kararı daha güvenilir vermesine yardımcı oluyoruz?” olmalıdır.

Benim için ilk soru hala aynı: Bu sistem kimin hangi kararını kolaylaştırıyor? Cevap "herkesin her sorusu" ise kapsam çok geniş demektir. "Satış ekibinin teklif hazırlarken fiyat politikasını bulması" gibi dar bir hedefle başlamak hem ölçmeyi hem güveni kolaylaştırıyor.