veri-ve-anlam · derinlemesine

RAG’den önce çözmeniz gereken anlamsal veri problemi

İlgili parçayı bulmak, AI’ın hangi bilgiye neden güvenmesi gerektiğini bilmek değildir.

Bir RAG sistemi kurmaya karar verildiğinde teknik konuşma çok hızlı biçimde şu başlıklara kayabilir: hangi gömme modeli, hangi vektör veritabanı, parçalar kaç belirteç olsun, yeniden sıralama kullanalım mı, kaç belge getirelim?

Bunların tamamı gerçek tasarım sorularıdır. Ancak daha temel bir soru cevaplanmadan sorulduklarında çok iyi ayarlanmış bir sistem, kurumsal belirsizliği daha hızlı getiren bir mekanizmaya dönüşebilir.

Vektör benzerliği, kurumsal doğruluk için tasarlanmış bir otorite modeli değildir. Bir metnin soruya dilsel olarak yakın olması; güncel, yetkili, kapsamı doğru veya o kullanım için geçerli olduğu anlamına gelmez.

Bu ayrım özellikle kurumsal RAG sistemlerinde önemlidir. Arama katmanı semantik yakınlığı başarıyla optimize ederken, sistem birbirine yakın fakat farklı statüdeki iki kaynağı aynı cevap bağlamına taşıyabilir. Sonuç akıcıdır. Hatta ikna edicidir. Fakat hangi bilginin neden üstün tutulduğu açıklanamaz.

AI hangi bilgiye güveneceğini biliyor mu?

Bu sorudaki “bilmek” modele insan gibi niyet atfetmek değildir. Sistem tasarımında şu ilişkilerin açık olup olmadığını sormaktır: Bir kavramın yetkili kaynağı hangisi? İki kayıt aynı varlığı mı temsil ediyor? Bir terim farklı ekiplerde aynı anlama mı geliyor? Bir bilginin hangi tarihte geçerli olduğu biliniyor mu? Cevabın dayandığı kaynağa geri dönülebiliyor mu?

RAG, ilgisiz cevap sorununu azaltabilir. Fakat anlamsal uyuşmazlığı kendiliğinden çözmez.

Parçalama stratejisi de anlamsal modelden bağımsız değildir.

Parça boyutu çoğu zaman belirteç sayısı üzerinden konuşulur. Fakat kurumsal bilgi her zaman eşit uzunlukta parçalara ayrılabilecek bir metin değildir. Bir politika maddesinin istisnası sonraki paragrafta, bir gereksinimin koşulu dipnotta veya bir ürün tanımının kapsamı başka tabloda olabilir.

Parçalama işlemi bu ilişkileri koparırsa arama katmanı doğru cümleyi bulabilir, fakat cümlenin sınırını kaybedebilir. “Yapılabilir” ifadesi gelir; “yalnız şu koşulda” kısmı başka parçada kalır.

Bu nedenle parçalama yalnız performans ayarı değil, anlam sınırı kararıdır. Doküman yapısı, başlık hiyerarşisi, madde-istisna ilişkisi ve tablolardaki bağlam gerektiğinde parça modeline taşınmalıdır.

RAG’den önce görünür hâle getirmeniz gereken beş problem

1. Kaynak otoritesi

Aynı müşteri, ürün, politika veya teknik varlık üç farklı sistemde tutulabilir. “En güncel kayıt” ile “yetkili kayıt” aynı şey olmayabilir. Bir kaynağın veriyi sık güncellemesi, o kavram için kurumsal otorite olduğu anlamına gelmez.

Örnek: Satış sistemi “Client”, faturalama sistemi “Customer”, kimlik yönetimi “Account holder” diyor. Gömme benzerliği bunların yakın olduğunu görebilir. Fakat hangi kullanımda aynı varlığı temsil ettiklerini ve hangi alan için hangi kaynağın yetkili olduğunu söyleyemez.

Otorite bazen kaynak düzeyinde değil, alan düzeyindedir

“CRM ana kaynaktır” cümlesi de fazla kaba olabilir. Aynı varlığın iletişim bilgisi için CRM, sözleşme durumu için sözleşme sistemi, ödeme statüsü için finans sistemi yetkili olabilir. RAG katmanı yalnız belge veya sistem önceliği biliyorsa bu alan düzeyindeki otorite farkını kaybedebilir.

Dolayısıyla kaynak otoritesi bir logo veya sistem adı listesi değildir. Hangi kavramın, hangi özniteliğinin, hangi koşulda ve hangi zaman aralığında hangi kaynaktan alınacağını açıklayan bir karar yapısıdır.

2. Varlık kimliği

İki isim birbirine benzediği için aynı varlık olmayabilir. Aynı varlık da farklı kaynaklarda bütünüyle farklı kimliklerle yaşayabilir. Bu sorun yalnızca tekrarlı kayıtları temizleme meselesi değildir. Kimlik ölçütünün açık olmadığı yerde birleştirme de ayırma da anlam kaybı üretebilir.

Yanlış birleştirme iki ayrı varlığın bilgisini tek cevapta harmanlayabilir. Yanlış ayırma ise aynı varlığa ait kanıtı parçalayarak sistemin eksik bağlam getirmesine yol açabilir. Her iki hata da son cevap katmanında “model hatası” gibi görünebilir.

Varlık çözümleme bu yüzden yalnız bir veri temizliği görevi değildir. Kimliği hangi özniteliklerin belirlediği, eşleşmenin ne kadar kesin olduğu ve belirsiz eşleşmelerin nasıl ele alınacağı açık olmalıdır.

3. Kavram belirsizliği

“Aktif”, “onaylı”, “kritik”, “ürün”, “hizmet” gibi kelimeler kurum içinde tek anlama sahipmiş gibi kullanılabilir. Oysa ekipler aynı kelimeyle farklı durumları tarif ediyor olabilir.

Bir LLM bu kullanımları dilsel olarak makul biçimde bir araya getirebilir. Sorun da tam burada başlar: Dilsel akıcılık, kurumsal anlamsal tutarlılık değildir.

Bir kontrollü sözlük de yalnız eş anlamlılar listesi değildir. “Aynıdır”, “daha geniş kavramdır”, “yalnız belirli bağlamda eşdeğerdir” ve “karıştırılmamalıdır” ilişkileri birbirinden ayrılmadığında bütün terimler yakın anlamlı bir torbaya dönüşür.

Örneğin “müşteri”, “hesap sahibi” ve “fatura alıcısı” bazı süreçlerde aynı kişiyi gösterebilir. Başka bir süreçte üçü farklı rollerdir. RAG tasarımında bu ayrım yoksa sistem yakın metni bulur, fakat yanlış rolü cevapta kullanabilir.

4. Zaman ve geçerlilik

RAG sisteminiz geçen yıl geçerli olan politika ile bu ay yürürlüğe giren politikayı birlikte getirebilir. Her iki belge de “ilgili”dir. Fakat cevap için aynı ağırlığa sahip değildir.

Yürürlük, geçerlilik aralığı, sürüm, yerini aldığı kayıt ve kaynak tarihi modellenmiyorsa “en alakalı parça” yanlış zamanda doğru bilgi olabilir.

Burada iki zaman sorusu birbirinden ayrılabilir: Bilgi gerçek dünyada ne zaman geçerliydi ve sistem bu bilgiyi ne zaman kaydetti? Eski bir kararın neden verildiğini araştırırken geçmişte geçerli olan kayıt gerekir. Bugünkü uygulamayı sorarken güncel yürürlük gerekir. Tek bir “son güncelleme tarihi” her iki soruyu da cevaplamaz.

Bu nedenle zaman bilgisi yalnız filtreleme kolaylığı değil, cevabın hangi bağlamda doğru olduğunu belirleyen anlamsal bir özelliktir.

5. Köken ve izlenebilirlik

Cevapta bir iddia oluştuğunda yalnızca belge bağlantısı görmek bazen yetmez. Hangi kaynak alanından, hangi dönüştürme kuralından ve hangi eşlemeden geldiği de kritik olabilir.

Özellikle kaynaklar birleştirildiyse soru şudur: Bu bilgi kaynaktan mı geldi, dönüşüm sırasında mı üretildi, yoksa bir modelin çıkarımı mı?

Bir özetleme adımı, normalizasyon kuralı veya otomatik eşleme yeni bilgi üretmiş olabilir. Kullanıcı yalnız son doküman bağlantısını görürse bu ara dönüşümlerin etkisi görünmez. Oysa bir iddiaya itiraz edildiğinde tam da bu zincire dönmek gerekir.

Köken bilgisi, cevabın kaynağını göstermekten daha geniştir. Kaynak, dönüşüm, eşleme ve çıkarım adımlarının izini sürmeyi sağlar. Bu iz olmadan yanlış bir cevabın hangi aşamada bozulduğunu ayırmak zorlaşır.

Son cevap, zincirin yalnızca son halkasıdır

SORU / GÖREV
↓
BİLGİ GETİRME
↓
GETİRİLEN BAĞLAM
↓
BAĞLAMIN GEÇERLİLİĞİ?
↓
BAĞLAMI KULLANMA
↓
CEVAP / İŞ SONUCU

Basitleştirilmiş kavramsal gösterim. RAG sistemindeki hata, son cevaptan önce zincirin başka bir katmanında başlayabilir.

Bir RAG cevabı yanlış olduğunda yalnızca “model halüsinasyon yaptı” demek teşhis değildir.

Yanlış belge mi getirildi? Doğru belge getirildi ama eski miydi? Doğru parçalar geldi ama birbirleriyle çelişiyor muydu? Model bağlamı yanlış mı kullandı? Yoksa cevap doğruydu ama iş kuralı farklı mıydı?

Son cevap skoru tek başına sistem teşhisi değildir.

Bu nedenle değerlendirme de katmanlı olmalıdır. Bilgi getirme başarısı, bağlam geçerliliği, kaynak otoritesi, cevap doğruluğu ve iş sonucu aynı metrik altında eritildiğinde düzeltmenin nereye yapılacağı belirsizleşir.

Örneğin bilgi getirme başarısı yükselirken cevap güvenilirliği düşebilir. Sistem daha fazla ilgili parça bulmaya başlamış, fakat eski ve yeni politika sürümlerini birlikte getirmiş olabilir. “Bilgi getirme duyarlılığı (retrieval recall) arttı” teknik olarak doğruyken karar desteği zayıflamış olabilir.

Tersi de mümkündür. Model cevabı kısa ve doğru üretir, fakat kaynak zinciri görünür değildir. Gösterim başarılı görünür; denetim, itiraz veya kritik karar anında sistemin neden o cevabı verdiği açıklanamaz.

Hata yalıtımı bu nedenle değerlendirme tasarımının parçasıdır. Hangi katmanın hangi başarı ve başarısızlık bilgisini ürettiği ayrılmalıdır.

Kurumsal arama ile karar desteği aynı güven düzeyini gerektirmeyebilir

Bir çalışanın “bu konuda hangi belgeler var?” sorusuna cevap veren arama yardımcısı ile “bu işlem onaylanabilir mi?” sorusuna cevap veren karar destek sistemi aynı riskte değildir. İlkinde kullanıcı farklı belgeleri açıp karşılaştırabilir. İkincisinde tek cevap doğrudan iş kararını etkileyebilir.

Aynı RAG teknolojisi kullanılsa bile kaynak otoritesi, köken, zaman ve insan incelemesi gereksinimleri farklılaşabilir. Bu yüzden “RAG güvenilir mi?” sorusunun tek cevabı yoktur. Güven gereksinimi kullanım amacından çıkar.

İlk müdahale: teknoloji seçmeden önce veri gerçekliğini temsilî kesitte sınayın

Kurumsal veri tabanının tamamını temizlemek veya büyük bir ontoloji programı başlatmak ilk adım olmak zorunda değildir.

Benim tercih ettiğim başlangıç daha küçüktür:

1. RAG kullanım amacını tek bir karar veya görev üzerinden sınırla.
2. Bu görev için gerçekten kullanılan kaynakları belirle.
3. Temsilî bir kayıt kesitinde kaynak otoritesi, varlık kimliği ve kavram belirsizliklerini çıkar.
4. Çelişki, zaman ve köken ilişkilerini görünür hâle getir.
5. Hedef veri ve anlam yapısını gerçek uçtan uca örnek üzerinde doğrula.
6. Ancak sonra ölçekleme ve teknoloji tercihlerini netleştir.

Bu çalışma sonunda “graf veritabanı kullanmalıyız” sonucu çıkabilir. Çıkmayabilir de. Kontrollü sözlük, ilişkisel model, kaynak otoritesi kaydı veya basit ama açık dönüşüm kuralları yeterli olabilir.

Temsilî kesit çalışmasının somut çıktısı da “veri kirli” tespiti olmamalıdır. Yetkili kaynak haritası, belirsiz kavram listesi, kritik varlık ve ilişki modeli, zaman/geçerlilik kuralları ve köken gereksinimleri gibi uygulanabilir kararlar çıkmalıdır.

Bu kararlar bir sonraki teknoloji seçimini daha dar ve daha dürüst hâle getirir. Gömme modeli, yeniden sıralama veya bilgi grafı ancak hangi problemi çözeceği açık olduğunda anlamlı bir tasarım kararı olur.

Önce teknoloji seçip veriyi ona uydurmak yerine, kullanım amacı ve veri gerçekliği incelenmelidir.

Her anlamsal problem büyük bir kurumsal ontoloji gerektirmez

“Semantik” kelimesi kolayca büyük programlara dönüşebilir. Her kavram için komite, her veri için kurumsal ontoloji ve her ilişki için bilgi grafı kurmak da başka bir aşırı uçtur.

İhtiyaç kadar model gerekir.

Bir kullanım alanı yalnız üç kritik varlık ve beş ilişki üzerinde çalışıyorsa, önce o sınırda doğruluk ve izlenebilirlik kurulabilir. Zamanla yeni kullanım alanları geldikçe kontrollü biçimde genişletilebilir.

Graf veritabanı güçlü ilişki sorguları gerekiyorsa yararlı olabilir. Kurumsal ontoloji ortak kavramların çok sayıda sistem ve ekip arasında tutarlı yönetilmesi gerekiyorsa değerli olabilir. Bilgi grafı, varlık ve ilişkilerin açıklanabilir biçimde dolaşılması gereken kullanım alanlarında doğru tercih olabilir.

Fakat bunların hiçbiri “AI projesi yapıyoruz” cümlesinin otomatik devamı değildir. Teknoloji, görünür hâle getirilen anlamsal probleme cevap vermelidir.

Temel soru teknoloji değildir:

İki kayıt gerçekten aynı varlığı mı temsil ediyor ve AI bu kararı hangi gerekçeyle verecek?

İLGİLİ ÇALIŞMA ALANI

AI-ready veri ve anlamsal mimari

Kaynak otoritesi, varlık kimliği, anlamsal belirsizlik, ilişki ve köken problemlerini AI kullanım amacı bağlamında bağımsız olarak inceleyin.

Hizmeti inceleyin →

10 DK OKUMA