Geçen hafta, paylaşımlı bir repoda çalışan bir kod ajanının yaptığı tuhaf şeyi görünce durup baktım — ister istemez. Doğru dosyaları açmıştı. Doğru notları okumuştu. Hatta ilgili dokümanların çoğunu da yakalamıştı… ama yine de yanlış değişikliği yaptı. İşin aslı şu: sorun modelin “zekâsı” değildi. Bağlamın nasıl tutulduğuydu.
Benzer bir sahneyi 2024 yazında İstanbul’da, küçük bir ürün ekibiyle çalışırken de yaşamıştım. Ekip “her şeyi tek yerde toplayalım” diye güzel bir çalışma alanı kurmuştu; wiki’ler, görev notları, sohbet dökümleri, endpoint açıklamaları… Kâğıt üstünde süperdi. Pratikte ise ajan hâlâ “bu servisin sahibi kimdi?” sorusunda tökezliyordu. Çünkü elinde belge vardı, ama ilişki yoktu.
Asıl mesele: Bağlam dosya yığını değil
Birçok AI çalışma alanı aracı bağlamı şöyle görüyor: dokümanlar, kod parçaları, sohbet geçmişi, arama sonuçları… Bu yaklaşım küçük sorularda iş görüyor, tabi. Mesela “bu fonksiyon nerede kullanılmış?” ya da “şu dosyayı özetle” dediğinizde fena değil. Ama iş biraz büyüyünce — hele güvenlik, yetki veya dağıtım tarafına geçince — duvar gibi karşınıza çıkıyor. Ciddi duvar.
Hmm, bunu nasıl anlatsamdı…
Çünkü gerçek sistemlerde anlam çoğu zaman isimlerde değil, ilişkilerde saklı oluyor. Düşünün: bir servis başka bir servise bağlı mı? Bu agent hangi kullanıcı adına işlem yapıyor? Hangi tool staging’de serbest ama prod’da yasak? Hangi izin kimden devralınmış? Bunlar düz metinden zor çıkıyor; bazen çıkıyor ama yarım yamalak, eksik, belirsiz çıkıyor.
Bakın şimdi, burası kritik. Copilot tarzı alanlar size isimleri topluyor olabilir. Ama knowledge graph dediğimiz yapı size fiilleri gösteriyor — kim neye bağlı, kim kime yetki vermiş, hangi olay neyi tetiklemiş. Asıl zeka burada başlıyor bence.
Neden salt arama yetmiyor?
Arama motoru iyi bir sekreter gibi davranır. İstediğiniz kelimeyi bulur, önünüze koyar, güzel iş yapar — hakkını yemeyelim. Fakat sekreterin hafızası vardır demekle organizasyonun mantığı vardır demek aynı şey değil. Hiç değil.
Geçen ay Ankara’daki bir kurum projesinde buna çok net şahit oldum. Log’larda cevap vardı (söylemesi ayıp) ama sebep zinciri yoktu; ajan doğru anahtar kelimeyi buldu, yanlış kararı verdi. Hani o meşhur durum var ya — her şey gözünüzün önünde ama tabloyu bir türlü göremiyorsunuz, sebebini de tam anlayamıyorsunuz. Tam öyle.
Grafik ne veriyor? İlişkiler
Eh, Knowledge graph aslında sihirli bir kutu değil. Baya sade bir fikir üzerine kurulu: varlıkları ve ilişkileri tutmak. Yani “Service A”, “DB Ledger”, “Approval Ops”, “Agent X” gibi düğümleriniz olur; bunların arasında da anlam taşıyan kenarlar bulunur. Hepsi bu kadar, teoride.
İşte tam da bu noktada devreye giriyor.
Şöyle ki, Böyle bakınca context artık bulanık bir çorba olmaktan çıkıyor. Sorgulanabilir hale geliyor. Ajan da ezber yapmıyor; bağlantıları izleyerek düşünmeye başlıyor. Açık konuşayım — benim için en büyük fark bu oldu. Gerçekten.
| Yaklaşım | Ne iyi yapar? | Nerede zorlanır? |
|---|---|---|
| Düz doküman / RAG | Metin bulma, özet çıkarma | Sahiplik, yetki ve bağımlılık ilişkileri |
| Knowledge graph | Sebep-sonuç ve ilişki sorguları | Kurma maliyeti ve bakım disiplini |
| İkisi birlikte | Kapsam + anlam dengesi | Daha fazla tasarım işi ister |
E tabi burada küçük bir hayal kırıklığı da var — grafik tarafı ilk bakışta biraz ağır geliyor — bence çok yerinde bir karar —. Her şeyi node-edge diye modellemek kolay değil; ekiplerin veri disiplini yoksa yapı hemen kirleniyor, hızla. Yani kâğıt üstünde parlak duran fikir pratikte insanı fena terletiyor. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Koddan daha fazlası lazım olduğunda…
// Basit fikir: sadece belgeyi çekmek yerine ilişkiyi de çek
MATCH (a:Agent)-[:DELEGATED_BY]->(u:User)
MATCH (a)-[:ALLOWED_TO_USE]->(t:Tool)
MATCH (t)-[:REQUIRES]->(ap:Approval)
RETURN a.name, u.name, t.name, ap.type;Bunu ilk kez Neo4j ile denediğimde şaşırmıştım açıkçası. Dosya listesi yerine ilişki grafiği görünce soru sorma biçimim bile değişti — bir anda “hangi dosya önemli?” sorusundan “hangi karar hangi kapıyı açmış?” sorusuna geçiyorsunuz, farkında bile olmadan. Aradaki fark bayağı büyük.
Ajan neden yanlış karar veriyor?
Doğrusu, Ajanların saçmaladığı anlar çoğu zaman model bozuk olduğu için değil, girdinin eksik olmasından kaynaklanıyor. Mesela ortak repolarda veya çok ekipli yapılarda aynı terim farklı şeyler ifade edebiliyor; mesela “staging key” ile “prod secret” arasındaki çizgi herkes için o kadar da açık olmayabiliyor. Maalesef. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Evet, doğru duydunuz. Daha fazla bilgi için Wilmer’e Tool Calling Geldi: Yerel AI Akışı Değişiyor yazımıza bakabilirsiniz.
Bir de şu var. Ajanlar genelde yakın bağlama aşırı güveniyor — son sprint notunu gördüyse onu mutlak gerçek sanabiliyor, halbuki geçen hafta değişmiş olabilir o not. Ben bunu 2023’te İzmir’de kendi yan projelerimde test etmiştim; README güncelken policy dosyası eski kalmıştı. Sistem bambaşka yönde gitmişti. Tam anlamıyla gözümün önünde oldu.
Search size kelimeyi verir; grafik ise o kelimenin hikâyesini anlatır.
Küçük startup ile enterprise arasında fark ne?
Küçük startup tarafında problem genelde hızdır. Herkes her şeye dokunur, bilgi Slack içinde eriyip gider. Burada hafif bir grafik katmanı bile ciddi rahatlık sağlar; çünkü sahiplik ve izin karmaşasını azaltır, şaşırtıcı biçimde. Yapay Zekâ Kod Yazıyor Ama İsim Vermek Hâlâ Zor yazımızda bu konuya da değinmiştik.
Enterprise seviyede ise mesele bambaşka oluyor. Uyumluluk, denetim izi, onay zinciri, veri sınırları devreye giriyor — orada knowledge graph sadece konfor aracı değil, neredeyse operasyonel ihtiyaç haline geliyor. Fark büyük.
- Startup: hızlı kurulum, az bakım yükü, net sahiplik takibi (bu kritik)
- Büyüyen ekip: tool çağrıları ve approval akışlarını izleme ihtiyacı
- Kurum: denetim izi, erişim politikaları ve veri soy ağacı
Peki bu yapı nasıl kuruluyor?
Şöyle ki, Lafı gevelemeden söyleyeyim. Önce veri kaynaklarını seçiyorsunuz, sonra ilişkileri tarif ediyorsunuz. Git commit’leri var mı? Seçeceksiniz. Jira ticket’ları var mı? Onlar da girsin. Slack kayıtları var mı? Tamam ama filtreleyerek — hepsini körlemesine basarsanız grafik çabucak çöplüğe döner, bunu deneyimledim (şaşırtıcı ama gerçek)
Editör masasında bu haberi hazırlarken özellikle şuna dikkat ettim: her bilgi kaynağı eşit ağırlıkta değildir. Doküman başka şeydir, politika başka şeydir, log başka şeydir. Hepsini aynı sepete atmak kolaydır ama faydası sınırlı kalıyor. Neden önemli bu? Çok sınırlı. Bu konuyla ilgili neden ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim.
Dengeyi nasıl kurarsınız?
- Sadece can alıcı ilişkileri modele alın.
- Sahiplik bilgisi olmadan hiçbir node’u tam kabul etmeyin. — bunu es geçmeyin
- Zaman boyutunu ekleyin; çünkü bugün doğru olan yarın bozulabilir. (bu kritik)
- Ajanın cevabına çoğu zaman kaynak yolu ekleyin (hangi node’dan geldi?).
Neyse uzatmayayım — burada amaç bütün şirket bilgisini grafiğe taşımak değil. Önce en çok hata üreten noktaları yakalamak daha mantıklı. Yetki akışı, deployment bağımlılığı, güvenlik politikası gibi yerler genelde ilk aday oluyor.
Sadece teknoloji meselesi de değil
Bence bu tartışmanın altında kültürel bir taraf da var — bence çok yerinde bir karar —. Ekipler yıllardır belge üretmeye alıştı ama ilişki tutmaya pek alışmadı. Halbuki modern yazılımda bilgi sadece içerikte değil, bağlantıda yaşıyor; bir PR’ın hangi ticket’tan çıktığını bilmek bazen PR metninden daha değerli oluyor (ciddiyim). Bunu söyleyince bazıları şaşırıyor ama öyle.
Bana göre en iyi kullanım senaryosu hibrit yaklaşım. Metin tabanlı arama hızlı keşif sağlar; grafik ise doğrulama yapar. Yani biri sizi doğru mahalleye götürür, öbürü doğru kapıyı açtırır. İkisini birlikte kullanınca sistem daha az sallanıyor — fark ediliyor gerçekten.
Nerede tıkanabilir?
İlginç olan şu ki, Ters köşe kısmı şu: grafik kurmak teknik olarak mümkün olsa bile bakım disiplini yoksa kısa sürede eskiyor. Bilhassa de manuel etiketleme ağırlıklı sistemlerde insanlar güncelleme yapmayı unutuyor — sonra ajan yine yanlış kapıya gidiyor, sadece daha pahalı bir harita üzerinde dolaşıyor. Biraz acı ironi var burada.
Benden kısa notlar ve pratik tavsiye
Eğer küçük bir ekipteyseniz önce üç ilişkiye odaklanın: sahiplik, yetki, bağımlılık. Bunlar oturdu mu geri kalanını genişletmek kolaylaşıyor. Daha büyük organizasyonda ise audit trail’i baştan düşünün — sonradan eklemeye kalkınca gerçekten can sıkıyor, inanın.
Dürüst olmak gerekirse, Kendi test ettiğim birkaç senaryoda en çok işe yarayan şey basit olmuştu. Ajan cevabı verirken kullandığı ilişkileri açıkça göstermeli (evet, doğru duydunuz). Kullanıcı neden o sonuca vardığını görürse güven artıyor; görmezse cevap doğru olsa bile havada kalıyor. Bu kadar.
Bazıları buna gereksiz karmaşa diyor. Kısmen haklılar — her problem knowledge graph istemez, sıradan belge araması çoğu gün yeterli. Ama konu güvenlik, izin, sahiplik, deploy zinciri olunca düz klasör düzeni çabuk pes ediyor. Çok çabuk.
Sıkça Sorulan Sorular
Knowledge graph ile RAG aynı şey mi?
Hayır, aynı şey değiller. RAG metinden ilgili parçaları çekmeye odaklanır; knowledge graph ise varlıklar arasındaki ilişkileri tutar. En iyi sonuç çoğu zaman ikisini birlikte kullanınca gelir.
Küçük ekipler için knowledge graph gerekli mi?
Doğrusu, Zorunlu değil,ama bazı durumlarda bayağı işe yarar. Mesela de sahiplik,yetki ve bağımlılık karmaşası varsa küçük ölçekte bile fayda sağlar. Basit başlayıp sonra büyütmek en sağlıklısıdır.
Ajan neden doğru dosyayı okuyup yine de yanlış karar veriyor?
Çünkü doğru dosya tek başına yeterli olmayabilir. Kararı etkileyen asıl unsur bazen ilişkilerdir: kim onay verdi,hangi politika geçerli,hangi ortamda çalışılıyor gibi bilgiler düz metinde kaybolabilir.
Knowledge graph kurmak pahalı mı?
Araya gireyim: Evet,kurulum maliyeti olabilir; özellikle veri temizliği tarafında uğraştırır. Ama kritik süreçlerde hatayı azaltıyorsa yatırım geri dönebilir. Mesele ne kadar büyük başladığınızla alakalıdır.
Kaynaklar ve İleri Okuma
Doğrusu, Neo4j Resmi Dokümantasyonu
Microsoft Azure Knowledge Graph Rehberi
Hani, Semantic Search Ölçekte Neden Zorlaşıyor? RAG’in Dersi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
