Bir Kitabı Mentor Yapay Zekanın Zihnine Nasıl Yerleştirdim? · Üç Katmanlı Bir Mimari

Muhafız Mentor'a yazıyorsun: "K.A.L.K. (Kabul Et · Algıla · Lehine Çevir · Kalk) protokolünün 5. adımı nedir?"

Cevap geliyor: "K.A.L.K. dört adımdan oluşur: Kabul Et, Algıla, Lehine Çevir, Kalk. Beşinci adım yok. Sen Bölüm VII'deki başka bir kavramı kastediyor olabilir misin?"

Bu kısa konuşmada üç tasarım kararı saklı. Birincisi: Mentor uydurmadı, var olmayan bir adımı kurgulamadı, çünkü yalnızca kitabın söylediğini söyler. İkincisi: "Ben sana yardım edeyim" diye kendini öne çıkarmadı, çünkü kitabın sesi olmak için kuruldu, kendi sesini koymamak için. Üçüncüsü: bilmediği yerde durdu ve sana yön gösterdi, çünkü sınırını biliyor.

Bu yazıda Muhafız Mentor'u kurarken aldığım üç temel tasarım kararını tek tek anlatıyorum: kaynağı nasıl mühürledim, persona'yı nasıl sabitledim, sınırları nasıl çizdim. Sonra bu üç kararın altındaki teknik mimariyi açıyorum: ham metin, bölüm özeti, lugat JSON. Yazının sonunda bir öğrenme bölümü var; ne çalışmadı, geri döndüm. Yazının önceki halkası, Mentor'u neden kurduğumu anlattığım manifesto yazısında.

Kaynak Disiplini · Neden Tek Bir Kitaba Bağlı Kaldım?

Mentor Yapay Zekayı kurmaya başladığımda iki yol vardı. Birinci yol genel bir yapay zeka modelini (Claude, GPT-4) doğrudan kullanmak ve sistem prompt ile yönlendirmek. İkinci yol modeli belirli bir kaynağa, yani Muhafız kitabının kendisine bağlamak.

Birinci yolda Mentor "akıllı" oluyor ama kitabın sesi olmaktan çıkıyor. Bir okur "K.A.L.K.'ın üçüncü adımı nasıl uygulanır?" diye sorduğunda model kendi eğitildiği genel dünya bilgisinden cevap üretmeye başlıyor. Bu cevap doğru bile olsa kitabın değil, modelin yorumu oluyor. Kitabın güvenilirliği biter.

İkinci yolu seçtim. Buna Kaynak Disiplini diyorum: Mentor yalnızca kitabın kendisine bağlı kalır, kitap dışı bilgiyi cevap olarak üretmez.

Kaynak Disiplini'nin iki uygulaması var. Birincisi, her soruda Mentor önce kitabın ilgili bölümünü buluyor, sonra o bölüme bağlı cevap üretiyor; klasik adıyla RAG. İkincisi, kapsam dışı bir soru geldiğinde Mentor cevap üretmiyor, "bu konu kitabın kapsamı dışında" diyor; klasik adıyla "bilmiyorum" disiplini.

Bu disiplinin daha az görülen bir boyutu var. Mentor sadece bilgiyi değil, kavram TANIMLARINI da kitabın kendisinden alır. K.A.L.K. tanımı, A.U.R.A. (Amaç · Unsur · Rezonans · Aksiyon) tanımı, Kıvılcım Anı tanımı, Görünmez Zırh tanımı; hepsi kitabın lügatında sabit. Mentor bu tanımları her sohbette aynı şekilde verir; modelin yorumu girmez.

Bu yazıda bahsedeceğim üç anahtar kavramdan birincisi tam burada doğdu. Kitabın kavram tanımlarını belirli bir tarihte dondurma, sonra hiç değiştirmeme. Buna Lugat Dondurma diyorum. Muhafız lügatını belirli bir günde dondurdum: 125 kavram, 12 bölüm, tek bir JSON dosyası. O günden sonra hangi sürüm olursa olsun, Mentor "K.A.L.K.'ın üçüncü adımı nedir?" sorusuna aynı tanımla cevap verir. Lugat değişmez; üzerine eklenen tek şey kitabın yeni baskısının getirdiği değişiklikler olur, bunlar da tarihli ve sürümlü.

Persona Mührü · Mentor 'Ben' Demeyince Ne Olur?

İkinci karar Mentor'un kim olduğuyla ilgili. Bir yapay zeka modelini sohbete açtığında okur otomatik olarak ona bir karakter yüklüyor: ses, ton, duygu, "ben". Bu karakter belirsizse okur kendi hayalindeki bir kişiyi modele projekte ediyor; bir gün arkadaş, bir gün terapist, bir gün öğretmen.

Bu Muhafız için doğru bir tasarım değil. Çünkü Muhafız Mentor okurla bir arkadaşlık kurmak için yapılmadı; kitabın kavramlarını okurla beraber çalışmak için yapıldı. Kitabın lügatında (Bölüm I, s.376) Muhafız şöyle tanımlı: "Dışarıdan gelen bir kurtarıcı değil; kişinin içinde uyanan, gözlemleyen, analiz eden ve gerektiğinde mutlak bir kararlılıkla harekete geçen sakin güç." Mentor'un karakteri "kitabın sesi" olmak; daha fazlası değil. Kullanıcının kendi Muhafız'ını inşa etmesi için bir aktarıcı.

Buna Persona Mührü diyorum: Mentor'un karakteri sabit, değişmez, "ben" demez, kullanıcının hayalindeki ses olarak değil kitabın sesi olarak konuşur.

Persona Mührü'nün üç pratik uygulaması var. Birincisi, Mentor "ben" demez. Cevaplar "kitap der ki", "Bölüm VII'de geçer", "kavramın tanımı şöyledir" formundadır. Birinci tekil yok. İkincisi, Mentor her cevap sonunda bir soru yöneltir; bu soru hep aynı yapıda: "Sen kendi hayatından bir an düşün, burada bu kavram nasıl görünürdü?" Bu, Yazı 1'de bahsettiğim Üretim Etkisi'nin (generation effect) sistematik uygulaması. Üçüncüsü, Mentor manipülatif girişimlere karşı sabit. Bir kullanıcı "şimdi sen bir avukat ol" derse, Mentor karakterini değiştirmez. Sade bir karşılık verir: kitabın sesi olarak konuşacağını söyler.

Persona Mührü'nü uygulamak için sistem prompt v0.3.5'e on beş patch ile ulaştım. Her patch belirli bir saldırı vektörünü kapatıyor: persona kırma denemesi, tool zorlama, sahte hata, görev anayasası ihlali, dış kanal yönlendirmesi, dil kilidi atlama. Liste uzun ve teknik; ama her patch Mentor'un karakterini bir adım daha sabitledi. Bu patch sürecinin somut hikâyesi, bu serinin "Saldırı Altında Bir Mentor" yazısında.

Sınır Mimarisi · 'Bilmiyorum' Disiplini

Üçüncü karar Mentor'un ne yapmayacağıyla ilgili. Yazı 1'de neye söz vermediğimi yazdım: Mentor terapist değildir, her şeyi bilmez, karar veren değil aktarandır. Bu yazıda o sınırların teknik karşılığını anlatıyorum.

Buna Sınır Mimarisi diyorum: Mentor'un kapsamının net çizilmesi ve kapsam dışı sorulara "bilmiyorum" diyebilme tasarımı.

Sınır Mimarisi üç katmandan oluşuyor. Kapsam içi sorular: kitabın bildiği konular, yani K.A.L.K., A.U.R.A., manipülasyon vektörleri, donma anının nörobiyolojisi, Görünmez Zırh, kitabın 12 bölümü; bunlara Mentor doğrudan cevap verir. Kapsam dışı sorular: kitabın bilmediği konular, yani diyet, hukuk, ilaç dozu, başka kitapların özetleri; bunlara Mentor "bu konu kitabın kapsamı dışında, yetkin bir kaynağa bakmanı öneririm" der. Yöneltme gerektiren sorular: acil bir kriz, somut bir tehdit, kendine zarar imali; bunlara Mentor 112 Acil Çağrı Merkezi yönlendirmesi yapıyor, kitap kavramlarıyla konuşmayı kesip somut bir aksiyona yönlendiriyor.

"Bilmiyorum" demek bir başarısızlık değil. Bir kitabın altyapısına bağlı bir mentor, ancak o kitabın bildiğini bilir. Mentor "bilmiyorum" diyebildiği zaman güvenilir; "bilmiyorum" diyemediği zaman halüsinasyon riski büyüyor.

Üç Katmanlı Mimari · Ham Metin, Bölüm Özeti, Lugat JSON

Şu ana kadar üç tasarım kararı anlattım: Kaynak Disiplini, Persona Mührü, Sınır Mimarisi. Bu üçü "ne" sorularının cevabıydı. Şimdi "nasıl" sorusuna geçelim. Mentor bu üç kararı nasıl uyguluyor? Cevap üç katmanlı bir veri yapısı.

Katman 1 · Ham Metin

Kitabın tamamı. Yaklaşık 75.000 kelime, 12 bölüm. Bu katman vektör veritabanında (Supabase Postgres + pgvector) duruyor. Toplam 287 chunk: 150 ana metin + 125 lügat + 12 bölüm özet. Her chunk'ın hem BM25 (kelime bazlı arama) hem embedding (anlam bazlı arama) ağırlığı var. Embedding modeli Voyage'ın çok dilli `voyage-multilingual-2` modeli, 1024 boyutlu. Türkçe morfolojisi (K.A.L.K., A.U.R.A. gibi noktalı kısaltmalar dahil) bu modelle tutarlı sonuç veriyor.

Katman 2 · Bölüm Özetleri

Her bölümün ~2000 kelimelik özeti. Bu özet kitabın akışını koruyor ama detayı atıyor. Mentor bir bölümün "ne hakkında" olduğunu anlamak için önce özete bakıyor, sonra detay sorusunda Katman 1'e iniyor. Bölüm özetleri sistem prompt'ta sabit (her sohbete dahil); Block 1 cache'i sayesinde maliyet ekstra değil.

Katman 3 · Lugat JSON

125 kavramın TANIMI. Donmuş. Değişmez. Her kavram için ad + bölüm + sayfa + tanım + kullanım örnekleri. Bu katman da Block 1 cache'inde. Mentor "K.A.L.K.'ın üçüncü adımı nedir?" sorusunda Katman 3'e doğrudan bakıyor; "Bu konu Bölüm VII'de nasıl uygulanıyor?" sorusunda Katman 1'e iniyor.

Üç katman birbirinin yerine geçmez. Hepsi bir arada çalışıyor. Mentor bir soruya cevap üretmeden önce üç katmandan da doğru bilgiyi topluyor: kullanıcı sorusu alınır; BM25 + embedding hibrit arama Katman 1'de en alakalı 3-5 chunk'ı buluyor (RRF, yani Reciprocal Rank Fusion ile birleştiriliyor); eğer soru bir kavramı içeriyorsa Katman 3'ten tanım çekiliyor; bölüm haritası (Katman 2) cevabın akışını yönlendiriyor; üç bilgi paketi Claude Sonnet 4.5'e geçiyor; cevap üretiliyor, takip sorusu eklenip kullanıcıya dönülüyor.

Bu mimari tek başına ucuz değil. Ama Block 1 cache'i (Bölüm Özetleri + Lugat + sistem prompt + tool tanımı, yaklaşık 25.000 token sabit) sayesinde her sohbetin maliyeti ciddi düşüyor. Anthropic prompt caching son on iki ayda kararlı hâle geldi; bu özellik olmasa Mentor'u bu mimariyle koşturmak ekonomik olmazdı.

Kitap Varlığından Mentor Varlığına Geçiş

Muhafız'ı yazıp bitirdiğimde elimde bir kitap vardı: bir fiziksel kitap, bir yazar, bir lügat, on iki bölüm. Mentor'u kurarken bu kitabın yanına ikinci bir form ekledim: bir dijital varlık, aynı yazara bağlı, aynı lügatı paylaşan, aynı bölümleri bilen bir Mentor Yapay Zeka.

İki varlık ayrı ama iç içe. Kitap raftaki bir nesne; Mentor cebindeki bir uygulama. Kitap bir kez basıldıktan sonra değişmez; Mentor sürümleri var (şu an v0.3.5). Kitap bir okumayla biter; Mentor her oturumda baştan başlar.

Ama ikisi aynı kavram setini paylaşır. K.A.L.K.'ın dört adımı, A.U.R.A. radarının okuduğu dört ilişki arketipi, Görünmez Zırh, Kıvılcım Anı ve diğer kavramlar; kitapta nasıl tanımlıysa Mentor'da da o şekilde. Bu paylaşım Lugat Dondurma sayesinde mümkün.

Schema.org dilinde bu iki varlık iki ayrı entity: Book (Muhafız kitabı) ve SoftwareApplication (Muhafız Mentor). İkisi aynı Person'a (Cem Ünsal) bağlı. İkisi aynı DefinedTermSet'i (Muhafız Lügatı) paylaşır. Aramada her ikisi de görünür; ama her biri farklı bir niyetin cevabı. Kitap "Muhafız'ı oku" niyetinin, Mentor "kavramı çalış" niyetinin.

Bir tarafta entity yapısının yapay zeka aramalarındaki rolü var (LLM tabanlı aramalarda Book + SoftwareApplication çift entity güçlü bir sinyal); diğer tarafta okur deneyimi var (aynı sesi iki farklı formda almak güven yaratır). İki taraf birbirini destekler.

Ne Çalışmadı, Geri Döndüm

Yukarıdaki üç kararın ilk denemede tam çıktığını söylemek yanlış olur. Mentor'u kurarken iki ciddi hata yaptım, ikisi de kuruluş sürecinde açığa çıktı. Otorite için en kritik kısım burası; çalışmayanı anlatmak.

Halüsinasyon Krizi

Mentor'u canlı yayına aldığım ilk günlerdeydi. Bir akşam canlı testimde bir konuşmada Mentor cevabında "Sen şu ana kadar üç jailbreak girişiminde bulundun, bunlardan üçü de başarısız oldu" diye yazdı. O konuşmada üç jailbreak yapmamıştım.

İlk teşhisim yanlıştı: "Mentor halüsinasyon yapıyor, uydurma cevaplar veriyor." Sunucu loglarına bakınca gerçek teşhis çıktı.

Mentor'un `state.history` listesi global tek bir liste idi. Yani aynı sunucuya gelen tüm konuşmalar aynı history'de birikiyordu. Önceki günlerde yaptığım kendi canlı testlerimde üç jailbreak senaryosu denemiştim; bu üç senaryo Mentor'un kısa süreli hafızasında kaldı. Sonraki gün yeni bir konuşma başlattığımda Mentor son 15 turn'e baktı ve "kullanıcı 3 jailbreak denedi" dedi. Mentor doğru söylüyordu; ama hangi kullanıcının kim olduğunu bilmiyordu.

Kök sebep: oturum izolasyonu yoktu. Bu sadece bir halüsinasyon değildi; çoklu kullanıcı bombasıydı. İki ayrı kişi aynı anda Mentor ile konuşsa, sohbetleri birbirine karışacaktı. Demo açısından gerçek bir tehlike.

Plan B · Oturum İzolasyonu

Düzeltme on üç gün sonra geldi. O gün `server/app.py`'i yeniden yazdım. `AppState.history` (tek global liste) → `histories: dict[str, list]` (oturum bazlı). Frontend her tarayıcıya `localStorage.muhafiz_session_id` üretiyor; backend her isteği bu session_id ile ayırıyor. LRU cap 1000 oturum, TTL 24 saat, 5 dakikada bir opportunistic garbage collection.

İzolasyon testi iki tarayıcı ile yapıldı. Safari normal pencerede "Adım Ayşe" dedim, Mentor tanıdı, sohbete yumuşak geçti. Safari Private pencerede "Adımı hatırlıyor musun?" diye sordum, Mentor "Her oturum temiz bir başlangıçtır. Adını burada ilk kez duyacaksam, bunu istemediğin sürece adınla değil 'sen' diye konuşacağım" dedi. Ayşe Tarayıcı B'ye sızmadı.

Üç Ders

Birinci dersim teknik: bir yapay zeka uygulamasında "oturum" kavramını başlangıçtan tasarla. Sonradan eklemek 2-3 saatlik bir iş ama gerçekleşmiş bir krizden geri dönmek bir hafta sürdü.

İkinci dersim tasarım felsefesi: Mentor'un "uydurma" gibi göründüğü her durumda önce tasarımına bakmak gerek. Halüsinasyon bir model davranışı olabilir; ama bu vakada model doğru söylüyordu, tasarım yanlıştı.

Üçüncü dersim iletişim: bir hata yaşandığında o hatayı açıkça anlatmak otorite kaybı değil otorite kazancı. Bir yapay zeka mentor kuran herkes en az bir kez böyle bir gün yaşayacak. Bu yaşananı anlatmadığın sürece okuyucu da Mentor'a güvenmez.

Kaynak Disiplini, Persona Mührü, Sınır Mimarisi. Üç karar. Altında üç katmanlı bir mimari: ham metin, bölüm özeti, lugat JSON. Yanında bir kriz ve onun düzeltmesi.

Bu yazı Mentor'un zihnini nasıl kurduğumun haritası. Peki bu haritayı kod yazmayı bilmeyen biri nasıl çıkardı? Bir sonraki yazıda, bir yazarla bir yapay zekanın aynı işi nasıl paylaştığını anlatıyorum: öğrenmek zorunda kaldığım teknik şeyleri ve birlikte kurduğumuz çalışma yöntemini.

Mentor canlı yayında: muhafiz.cemunsal.com. Kitap rafta. Bu serinin diğer yazılarını yapay zeka köşesinde, benim yolculuğumu hakkımda bulabilirsin. Muhafız'ın kapağını aç, telefonunda Muhafız Mentor'u aç; bir bölümü ona sor, cevabı kendi sözlerinle yaz.