Klinikler İçin RAG Nedir? Bilgi Bankasıyla AI Agent

Hasta akşam WhatsApp'tan yazıyor: "İmplanttan sonra ne zaman sıcak çay içebilirim?" Genel bilgiyle konuşan bir dil modeli internetteki ortalama cevabı verir. Kliniğin hekimi ise kendi talimatında başka bir süre yazmış olabilir. RAG (Retrieval-Augmented Generation, erişimle güçlendirilmiş üretim), bir dil modelinin cevap yazmadan önce kurumun kendi belgelerinden ilgili parçaları bulup okuması ve cevabını bu parçalara dayandırmasıdır. Model genel bilgisini yine kullanır. Çalışma saati, hazırlık talimatı ya da şube adresi gibi kuruma özgü bilgiyi ise güncel kaynaktan alır. Klinikler için RAG'in anlamı basittir: AI Agent "bu kurumda kural budur" diyerek cevap verebilir. Aşağıda RAG'in nasıl çalıştığını, ince ayardan farkını, yanlış bilgi riskini nasıl azalttığını ve bir klinik bilgi bankasının nasıl kurulup güncel tutulacağını anlatıyoruz.

RAG nedir?#

Terim, Lewis ve arkadaşlarının makalesiyle yerleşti. Makale, büyük dil modellerinin olgusal bilgiyi parametrelerinde sakladığını ama bu bilgiye erişme ve onu hassas biçimde kullanma yeteneğinin sınırlı olduğunu belirtir. Önerilen çözüm, modelin "parametrik hafızasını" ayrı bir belge deposundan oluşan "parametrik olmayan hafıza" ile birleştirmektir. Model soruyu aldığında önce bu depoda arama yapar, bulduğu metinleri bağlam olarak kullanır, sonra cevabı yazar.

Dil modelini iyi eğitimli ama kurumunuzu tanımayan yeni bir çalışan gibi düşünün. RAG, bu çalışanın masasına kurumun el kitabını koymak ve her soruda ilgili sayfayı açıp okumasını istemektir. Çalışan yine kendi cümleleriyle konuşur, ama bilgiyi el kitabından alır.

Sağlık kuruluşunda bu el kitabının içinde neler olur?

• Şube adresleri, çalışma saatleri, hekim ve bölüm listesi
• Randevu, iptal ve değişiklik kuralları
• İşlem öncesi hazırlık ve işlem sonrası bilgilendirme metinleri (hekim onaylı)
• Anlaşmalı kurumlar, ödeme seçenekleri ve fiyat sorularına nasıl cevap verileceği
• Sık sorulan sorular ve kurumun iletişim tonu

RAG nasıl çalışır?#

Bir RAG sistemi iki aşamada çalışır: hazırlık ve cevap.

Hazırlık aşaması

1. Belgeler toplanır. PDF, web sayfası, iç yönerge ya da tablo bir araya getirilir.
2. Parçalara bölünür. Uzun belgeler anlamlı bölümlere ayrılır; her bölüm tek bir konuyu anlatmalıdır.
3. Vektöre çevrilir. Her parça, anlamını sayısal biçimde temsil eden bir vektöre (embedding) dönüştürülür ve bir vektör veritabanında saklanır. Embedding, metnin anlamını taşıyan bir sayı listesidir.

Cevap aşaması

1. Soru gelir. Hasta "İmplant sonrası ne zaman sıcak bir şey içebilirim?" diye yazar.
2. Benzer parçalar aranır. Soru da vektöre çevrilir ve anlamca en yakın parçalar bulunur.
3. Bağlam modele verilir. Bulunan parçalar, kurumun kurallarıyla birlikte modele iletilir.
4. Cevap üretilir. Model cevabı bu parçalara dayandırır; kaynakta cevap yoksa bunu söyler ve konuyu ekibe aktarır.

Anahtar kelime aramasından farkı, eşleşmenin kelimeyle değil anlamla yapılmasıdır. "Ameliyattan sonra banyo" ile "işlem sonrası duş" aynı parçayı bulabilir.

İnce ayar (fine-tuning) ile RAG'i karıştırmayın#

Kuruma özel bilgi vermenin ikinci yolu modeli kurum verisiyle yeniden eğitmektir. İki yaklaşım farklı işlerde öne çıkar:

Klinik bilgisi sık değişir: hekim izne çıkar, çalışma saati yaza göre kayar, yeni bir şube açılır. Kurum bilgisinde varsayılan tercih o yüzden RAG'dir. İnce ayar, gerekiyorsa üslup ve biçim için ayrıca düşünülür.

Yanlış bilgi riski nasıl azaltılır?#

Dil modelleri akıcı ama yanlış cevap üretebilir. NIST'in üretken yapay zekâ risk profili kurumların bu tür riskleri tasarım, geliştirme, kullanım ve değerlendirme aşamalarında yönetmesi için gönüllü bir çerçeve sunar. Dünya Sağlık Örgütünün büyük çok kipli modeller rehberi de bu modellerin sağlıkta yaygınlaşacağını öngörürken geniş görevlerdeki yetkinliklerinin henüz kanıtlanmadığını hatırlatır.

RAG bu riski sıfırlamaz, ama kontrol edilebilir hâle getirir. Klinikte işe yarayan önlemler aşağıda:

• Kaynakta yoksa söyleme kuralı. Model, bilgi bankasında karşılığı olmayan soruda tahmin yürütmez; "Bu konuda ekibimiz size dönecek" der ve görev açar.
• Klinik sınır. Belirti, tanı ve ilaç soruları bilgi bankasından cevaplanmaz; hekime ya da acil yönlendirmesine gider.
• Hekim onaylı içerik. Hazırlık ve bakım talimatları yalnız onaylı sürümden okunur.
• Cevap denetimi. Haftalık örnek konuşmalar okunur, yanlış ya da eksik cevaplar bilgi bankasına geri yazılır.
• Çelişki taraması. Aynı konuda iki farklı belge varsa model hangisini seçeceğini bilemez; eski sürüm kaldırılır.

Klinikler için RAG: bilgi bankası örneği#

Bir diş kliniğinin bilgi bankasını düşünelim. Belgeleri konu başlığına göre ayırırsanız hem arama hem bakım kolaylaşır:

Her belgenin başında sahibi, son onay tarihi ve geçerlilik durumu yazmalıdır. Model cevap verirken bu bilgileri kullanmaz, ama ekip hangi belgenin güncel olduğunu tek bakışta görür.

İlk kurulumda bütün klasörleri birden doldurmaya çalışmayın. Gelen mesajların en sık beş konusunu belirleyin ve önce onların belgelerini yazın. Kullanım verisine göre büyüyen bilgi bankası gereksiz içerikle şişmez.

Bilgi bankasını güncel tutun#

RAG'in en büyük avantajı güncellemenin kolay olmasıdır; en büyük riski de güncellemenin unutulmasıdır. Bilgi bankasını o yüzden bir yazılım deposu gibi yönetin:

1. Tek kaynak ilkesi. Bir bilgi yalnız bir belgede durur; başka belgeler ona atıf yapar.
2. Sürüm kaydı. Her değişiklikte kim, ne zaman, neyi değiştirdi kaydedilir. Hasta "geçen ay bana farklı söylendi" dediğinde o tarihteki sürüme bakılabilir.
3. Yayın onayı. Hasta talimatı gibi hassas içerik, onaylanmadan bilgi bankasına girmez.
4. Süreli içerik. Bayram çalışma saatleri ya da geçici şube kapanışı gibi bilgiler bitiş tarihiyle girilir ve süresi dolunca otomatik çıkar.
5. Değişiklik sonrası test. Güncellenen konuda birkaç örnek soru sorulup cevabın yeni bilgiyi yansıttığı kontrol edilir.

Bilgi bankasını HBYS ya da CRM'deki canlı veriyle karıştırmayın. Hekim takvimi ve hasta kaydı gibi anlık veriler ilgili sistemin bağlantısından okunur, RAG belgesinden okunmaz. Bu ayrımın teknik tarafı HBYS ve CRM entegrasyon rehberimizde anlatılıyor.

Bilgi bankasını kimlerin göreceğini belirleyin#

Bilgi bankası, yanlış kurulduğunda veri sızıntısının yeni bir kapısına dönüşebilir. OWASP'ın vektör ve embedding zayıflıkları başlığı zayıf erişim kontrolünün gömülü hassas verileri açığa çıkarabileceğini, paylaşılan vektör veritabanlarında farklı kullanıcı ya da grupların verilerinin birbirine karışabileceğini ve belgelere gizlenmiş talimatların çıktıyı saptırabileceğini belirtir. Önerilen önlemler arasında yetkiye duyarlı vektör depoları, kaynak doğrulama ve değiştirilemez erişim kayıtları yer alır.

Sağlık kuruluşu için bu maddeler şu kurallara dönüşür:

• Hasta verisi bilgi bankasına girmez. Bilgi bankası kurum bilgisidir; tahlil sonucu, epikriz ya da hasta yazışması buraya konmaz.
• Kurum ve şube ayrımı. Birden fazla kurumun ya da şubenin verisi aynı depoda karışmamalıdır.
• Belge girişi denetlenir. Bilgi bankasına yalnız yetkili kişiler belge yükler; dışarıdan gelen dosyalar kontrol edilmeden eklenmez.
• Erişim kaydı tutulur. Hangi sorunun hangi belgeyi çağırdığı kayıt altında olur.

Kişisel Verileri Koruma Kurulunun özel nitelikli veriler kararı da erişim yetkilerinin tanımlanmasını, işlem kayıtlarının tutulmasını, verilerin kriptografik yöntemlerle saklanmasını ve uzaktan erişimde en az iki aşamalı kimlik doğrulamayı ister. Konuşma kayıtları hasta verisi içerdiği için bu kurallar AI Agent'ın konuşma geçmişine de uygulanır. Telefondaki karşılığı için KVKK uyumlu sesli AI kontrol listesine bakabilirsiniz.

RAG kurulumunda sık yapılan hatalardan kaçının#

Altyapı doğru kurulsa bile bazı alışkanlıklar cevapları bozar. İlk aylarda en sık görülenler aşağıda.

• Bütün dosyaları olduğu gibi yüklemek. Taranmış PDF'ler, eski broşürler ve tekrar eden sunumlar aramayı bulandırır. Belgeleri yüklemeden önce ayıklarsanız sonradan hata aramaya daha az zaman harcarsınız.
• Çok uzun ya da çok kısa parçalar. Tek parçada beş konu anlatılırsa model ilgisiz bilgiyi de cevaba katar. Tek cümlelik parçalar ise bağlamı kaybeder. Her parça bir soruya tek başına cevap verebilmelidir.
• Tablo ve listeleri düz metne çevirmeden yüklemek. Çalışma saatleri tablosu hücre hücre bölündüğünde hangi saatin hangi güne ait olduğu kaybolabilir.
• Ton ve kuralları belgeye gömmek. "Fiyat sorulursa şöyle cevap ver" gibi davranış kuralları AI Agent'ın kural setinde durmalıdır. Bir belge silindiğinde kural da böylece kaybolmaz.
• Test sorularını yalnız ekip yazmak. Ekip kurumun dilini bilir; hasta ise farklı kelimeler kullanır. Gerçek mesajlardan derlenen soru listesiyle yapılan test, eksik belgeleri daha hızlı ortaya çıkarır.

Bilgi bankasını kurup bırakmayın, bir sahibi olsun ve her hafta ona baksın. Haftada kısa bir gözden geçirme, aylar içinde biriken hatalardan daha ucuzdur.

AI Agent kurumun bilgisini nasıl kullanır?#

Telefon ya da WhatsApp'tan gelen bir soruda AI Agent üç kaynağa bakar: bilgi bankası (kurum bilgisi ve kurallar), bağlı sistemler (takvim, CRM) ve kurumun tanımladığı davranış kuralları (ton, sınırlar, devir koşulları). Bilgi bankası cevabın içeriğini, sistemler anlık durumu, kurallar ise neyin söylenip neyin aktarılacağını belirler.

Hasta "Cumartesi açık mısınız, implant kontrolüm için yer var mı?" diye sorduğunda AI Agent çalışma saatini bilgi bankasından, boş saati takvimden okur, uygun saati önerir ve randevu talebini kaydeder. Aynı hasta "Dikiş yerim kızardı" yazdığında bilgi bankasında cevap aramaz; konuyu hekime ya da hasta danışmanına aktarır. Kurumun belgelerini, tonunu ve kurallarını bu şekilde düzenlemek için kurumsal hafıza kurulumu sayfasına göz atabilirsiniz. AgentFix kurulumlarında bilgi bankası her kurum için ayrı tutulur. Yapay zekânın sağlıktaki genel yeri için sağlıkta yapay zekâ yazımız tamamlayıcı bir okuma olabilir.

Klinikler için RAG, AI Agent'ın kurumunuzun güncel bilgisiyle konuşmasını sağlayan yöntemdir. Teknik taraf kurulumla çözülür. Asıl emek, belgelerin sahibini, onayını ve güncelleme düzenini belirlemektir. En sık sorulan beş konunun belgesini yazarak başlayın, sonra konuşma kayıtlarına bakarak bilgi bankasını büyütün.