Bu hafta yine yoğun bir haftaydı: Anadolu Efes, BR Mağazacılık, Boyner Group, Sephora, QNB, Borusan Holding, Yaşar Holding, Özaltın Holding, ve Victor sunumlarımı hazırlarken hep aynı sorunla karşılaştım. Her müşteri için eğitim sunum formatı farklı çıkıyordu ve revize etmem gerekiyordu. Oysa Victor, yapay zeka dosya yapımı, talimatlarımı, “skill”lerimi çok iyi biliyordu. Ses dosyam vardı; sunum dosyam vardı; marka kurallarım vardı; daha önce iyi sonuç vermiş örneklerim vardı. Yine de ilk taslak bazen bana hiç benzemiyordu. Bu hafta sonu bu problemi nasıl çözerim, ona odaklandım.
Problemim, yapay zekam dosyalarımı görüyordu ama doğru olanı seçemiyordu. İlk refleksim promptu veya skill’i düzeltmekti. Daha açık yazdım; daha uzun yazdım; kuralları tekrar anlattım; örnek ekledim. Bazen sonuç iyileşti; sonraki görevde yine bozuldu. Çünkü problem “prompt”ta değildi. Modelin önünde iyi bir talimat vardı fakat o talimatın kullanması gereken dosyalar birbirini tanımıyordu. O yüzden kendi “Graph Engineering” denetimimi yaptım.
”İkinci Beynini Kurmak” ve “CLAUDE.md dosyanı sil” yazılarında hafızayı sohbetin içinde bırakmamayı, kuralları yönetip klasörde tutmayı anlatmıştım. Claude Code sistemini kurduktan sonra da çoğu kişi aynı noktada takılıyor: talimat dosyası var, skill var, ama dosyalar birbirini görmüyor. Bu yazı o zincirin son halkası veya şimdilik son halkası. Konu yeni bir araç değil; konu, en dağınık bir klasörde dört prompt ile bir “MAP.md” çıkarmak ve yarın ekibin aynı klasörü çekebilmesi.
Her yeni kavram ayrı bir sistem değil
Prompt Engineering. Context Engineering. Loop Engineering. Graph Engineering.
İsimler çoğaldıkça yeni bir araç satın almanız veya baştan bir sistem kurmanız gerekiyormuş gibi görünüyor ama gerekmiyor. Bunlar aynı çalışmanın farklı sorularını çözüyor:
“Prompt Engineering” - Yapay zekaya işi nasıl tarif ediyorum?
“Context Engineering” - Modelin önüne şu anda hangi bilgi geliyor?
“Graph Engineering” - Gerekli bilgi nerede ve diğer bilgilerle nasıl bağlı?
“Loop Engineering” - Çıktı hangi kontrolden geçiyor ve başarısızsa ne oluyor?
Birini diğerinin yerine kullanamazsınız.
İyi prompt, yanlış kaynağı doğru kullanabilir.
İyi bağlam, yalnızca seçtiğiniz dosyaları modele gösterebilir.
İyi kontrol döngüsü, yanlış kaynakla üretilmiş çıktıyı tekrar tekrar düzeltebilir.
Graph Engineering ise daha önce gelen soruyu çözer: Sistem doğru kaynağın var olduğunu biliyor mu?
“Graph Engineering” dosyaların arasındaki ilişkiyi tanımlar
“Graph Engineering” için henüz herkesin kabul ettiği tek bir standart tanım yok.
“Graph Engineering”, bir yapay zeka sistemindeki bilgi varlıklarını, bu varlıkların kaynaklarını ve aralarındaki yönlü ilişkileri açık hâle getirme işidir.
Buradaki graph, güzel bir ağ görseli değildir. Şunların cevabıdır:
Hangi dosya kanonik kaynak?
Hangisi çalışan kopya?
Hangi çıktı hangi kaynaktan üretildi?
İki kaynak çelişirse hangisi kazanır?
Bir dosya güncellendiğinde başka ne kontrol edilmeli?
Hangi içerik hiçbir iş akışı tarafından çağrılmıyor?
Hangi bağlantı belgede gerçekten var, hangisi yalnızca çıkarım?
Kısaca sorduğu soru: Doğru bilgiye hangi yoldan ulaşacaksın?
Bu yüzden “Graph Engineering”, “Context Engineering”den önce gelir. Bağlam pencereye neyin gireceğini seçer. Ağ, seçilebilecek şeylerin nerede olduğunu ve hangisine güvenileceğini söyler.
Benim sistemimde sorun klasörlerin dağınık görünmesi değildi
Benim yapay zeka çalışma sistemimde kanonik ikinci beyin, Claude’un kullandığı canlı skill kopyaları, eklenti kataloğu, proje ayarları ve kullanım dışı arşiv aynı anda yaşıyordu.
İçeriden bakınca düzenli görünüyordu. Dosya adlarını biliyordum. Hangi işi nerede yaptığımı biliyordum. Bu yüzden sistemin de bildiğini varsaydım.
Bilgi ağını çıkardığımda farklı bir tablo gördüm:
Canlı çalışan bazı skill’lerin kanonik kaynağı belli değildi.
Site metni kendisinden daha güncel bir kanıt dosyasına dayanıyor görünüyordu fakat eski değerleri taşıyordu.
Aynı kampanyanın e-posta ve bülten sürümleri birbirini referanslamıyordu.
Emekliye ayrılmış bir marka skill’i güncel marka dosyalarını kaynak gösteriyor fakat o dosyalarla çelişen kurallar üretiyordu.
Arşivde duran içerik ile çalışan sistemde kullanılan içerik arasında açık bir sınır yoktu.
Promptlarım ve skilllerim kötü değildi; bağlam dosyalarım da eksik değildi. Sorun, bir dosyanın diğerine hangi yetkiyle bağlandığının yazılmamış olmasıydı.
Bir dosya “marka kaynağım bu” diyordu. İşaret ettiği kaynak artık başka bir şey söylüyordu. Sistem ikisini de görebiliyor fakat hangisinin kazanacağını bilmiyordu.
Bu bir prompt problemi değil. Bu bir bilgi ağı problemidir.
MAP.md dosya listesi değildir
İlk bilgi ağı denemenizde en kolay hata, bütün dosyaları bir listeye dökmektir. Bu envanterdir.
Bilgi ağı için çizgilere ihtiyacınız vardır. Bir “MAP.md" dosyası en azından şunları göstermeli:
ana konular ve ilgili kaynaklar,
kanonik kaynak ile türetilmiş kopyalar,
dosyalar arasındaki açık referanslar,
içerik benzerliğinden çıkarılan muhtemel ilişkiler,
bağlantısız içerikler,
çelişkiler ve tekrarlar,
güncelleme yönü,
insan kararı gerektiren noktalar.
En önemli kural şu: Bulunan ilişki ile tahmin edilen ilişki aynı etiketle yazılmamalı.
Ben kendi sistemimde DOĞRULANMIŞ ve ÇIKARIM ayrımını kullanıyorum.
İki dosya birbirini açıkça anıyorsa ilişki doğrulanmıştır. Model yalnızca içerik benzerliğinden bir bağ kuruyorsa bu çıkarımdır.
Bu ayrım yoksa bilgi ağınız hızla modelin tahminlerinden oluşan yeni bir doğruluk kaynağına dönüşür.
Daha fazla bağlam eklemek graph sorununu çözmez
Bu önemli, çünkü doğal tepki genellikle şudur: “O zaman bütün dosyaları bağlama yükleyelim.”
Bunu yapmayın. Anthropic’in önerdiği ilke, görevi tamamlayacak yüksek sinyalli ve mümkün olduğunca küçük bağlamı kurmaktır. Her şeyi aynı anda yüklemek seçim problemini ortadan kaldırmaz. Seçimi modelin sınırlı dikkat alanının içine taşır. Anthropic, Effective context engineering for AI agents.
Daha iyi tasarım şudur:
Kök harita yalnızca ana alanları ve yönlendirmeleri taşır.
Yerel haritalar kendi klasörlerindeki ilişkileri açıklar.
Talimat dosyası önce ilgili haritanın okunmasını ister.
Model yalnızca görevle ilgili kaynakları bağlama alır.
Kontrol döngüsü kullanılan kaynakları çıktı ile birlikte doğrular.
Bu düzen aynı çalıştırmada bütün katmanları birleştirir: “Graph” bulur. “Prompt” yön verir. “Context” taşır. “Loop” kontrol eder.
Kendi sisteminizi küçük başlatın
Bütün bilgisayarınızı haritalamayın. En dağınık klasörü de seçmeyin. Her hafta karar üretirken açtığınız tek bir klasörü seçin. Müşteri notları, teklifler, kampanyalar, araştırma arşivi veya toplantı kayıtları olabilir. Önce hiçbir dosyayı değiştirmeden görünürlük isteyin.
1. Haritayı çıkar
Bu klasörde erişebildiğin bütün dosyaları incele. Hiçbir dosyayı atlama.
Her dosya için şunları belirle:
- ana konu
- belge türü
- tarih veya sürüm bilgisi
- açıkça referans verdiği diğer dosyalar
- içerik benzerliğine göre ilişkili olabileceği dosyalar
- kanonik kaynak mı, türetilmiş kopya mı, arşiv mi olduğu
Klasörün kökünde MAP.md oluştur.
MAP.md içinde şu bölümler bulunsun:
- kapsam ve okunamayan dosyalar
- konu dizini
- kanonik kaynaklar ve türetilmiş kopyalar
- doğrulanmış bağlantılar
- çıkarım olarak önerilen bağlantılar
- bağlantısız içerikler
- çelişkiler ve tekrarlar
- önerilen güncelleme yönleri
Her ilişkiyi DOĞRULANMIŞ veya ÇIKARIM olarak etiketle.
DOĞRULANMIŞ için iki dosyadan da kanıt göster.
Emin olmadığın bağlantıyı gerçek gibi yazma.
Henüz hiçbir dosyayı değiştirme.Bu promptun görevi klasörü temizlemek değildir. Sizi temizliğe başlamadan önce gerçekle karşılaştırmaktır.
2. Riski ve en küçük düzeltmeyi bul
MAP.md içindeki çelişki, kopya ve bağlantısız içerikleri incele.
Her sorun için şunları yaz:
- kanıt
- olduğu gibi bırakılırsa etkisi
- en küçük güvenli düzeltme
- etkilenecek dosyalar
- geri alma yöntemi
- insan kararı gereken nokta
Henüz değişiklik yapma.
Önce etkisi yüksek ve geri alınması kolay işleri sırala.Burada amaç “her şeyi bağlamak” değildir. Bazı dosyalar gerçekten arşivdir. Bazıları bağımsız kalmalıdır. Bazıları silinmemeli, yalnızca aktif sistemden ayrılmalıdır. “Graph Engineering”in işi bağlantı sayısını artırmak değil, doğru bağlantıyı ve doğru sınırı görünür kılmaktır.
3. Onaylanan değişiklikleri uygula
Yalnızca onayladığım maddeleri uygula.
Her değişiklikten önce:
- değişecek dosyaları listele
- beklenen sonucu yaz
- geri alma yolunu belirt
Değişiklikten sonra:
- neyin değiştiğini özetle
- bağlantıları yeniden kontrol et
- MAP.md içindeki ilgili kaydı güncelle
Belirsizlik varsa dur ve sor.
Yayımlanmış veya harici paylaşılan içeriği açık onay olmadan değiştirme.Bu noktada “Graph”, “Loop” ile birleşir.
“Graph” sorunu bulur —> risk değerlendirmesi düzeltmeyi sınırlar —> insan onay verir —> sistem uygular ve bağlantıları yeniden kontrol eder.
4. Bilgi ağını çalışma akışına bağla
Bilgi ağı bir kere üretilip unutulursa rapordur. Her işin başında okunur ve işin sonunda güncellenirse sistemdir.
Claude Code kullanıyorsanız ilgili CLAUDE.md dosyasına şu kuralı ekleyebilirsiniz:
# Bilgi haritası
- Göreve başlamadan önce kök MAP.md dosyasını oku.
- Görev belirli bir klasördeyse o klasörün MAP.md dosyasını da oku.
- Yalnızca görevle ilgili kaynakları bağlama al.
- DOĞRULANMIŞ ile ÇIKARIM etiketlerini karıştırma.
- Dosya değişikliklerinde önce etkiyi ve geri alma yolunu göster.
- İş bittiğinde yeni veya değişen bağlantıları MAP.md içine ekle.Codex kullanıyorsanız aynı yönlendirmeyi proje kapsamındaki AGENTS.md dosyasına koyabilirsiniz.
Unutmayın araç değişir; mimari değişmez.
Sisteminizin çalıştığını nasıl anlarsınız?
Normalde cevaplamak için farklı dosyalar açmanız gereken, sonucunu bildiğiniz gerçek bir soru sorun.
Sonra şunlara bakın:
Sistem doğru kaynakları buldu mu?
Eski kopya ile güncel kaynağı ayırdı mı?
Çelişkiyi saklamak yerine gösterdi mi?
Kanıt ile çıkarımı ayırdı mı?
Kullanmadığı dosyaları da belirtti mi?
Hangi dosyayı neden seçtiğini açıkladı mı?
Belirsizlikte durdu mu?
Bunları yapıyorsa harita çalışıyor. Sadece renkli düğümler ve çizgiler üretiyorsa henüz bir bilgi sistemi kurmadınız. Bir görselleştirme yaptınız.
Bu gece yapacağınız iş
En büyük arşivinizi seçmeyin. En sık çalıştığınız klasörünüzü seçin.
Haritayı çıkarın. Dosyaları hemen taşımayın. Önce kaynakları, kopyaları, çelişkileri ve bağlantısız içerikleri görün. Sonra sonucu bildiğiniz gerçek bir işle test edin.
Promptunuz ne kadar iyi olursa olsun, model doğru bilgiye giden yolu bilmiyorsa güvenilir bir sisteminiz yoktur. “Graph Engineering” o yolu kurar.
