Token Yakmayı Nasıl Bıraktık ve Yapay Zeka İçin Knowledge Graph Optimizasyonunda Nasıl Uzmanlaştık?
Dün gece 500.000 satırlık eski bir fintech kod tabanında Claude Code'u test etmek için tam 3 saat harcadım.
Saat gece 02:14'te API kontrol panelimize boş gözlerle bakıyordum. Fatura göstergesi sadece yükselmemişti; adeta patlamıştı. Tek bir akşamda tam 4.000 dolar yakmıştık.
Üç saat. Dört bin dolar. Çöp oldu.
Ham Kodu Claude'a Yığmak Finansal Bir İntihardır
LLM'e bir çöp öğütücüsü gibi davrandık. Ham, yapılandırılmamış veriyi doğrudan context window'a boca ettik ve bir mucize bekledik.
İşe yaramadı.
Büyük Dil Modellerine yapısal bağlam sunmadan ham veri beslemek, paranızı ateşe atmanın kesin yoludur. Daha da kötüsü, çılgınca halüsinasyonlara yol açar. Ajan, ödeme ağ geçidinin kullanıcı şemasına nasıl bağlandığını bir türlü çözemedi. Aynı devasa repoyu tekrar tekrar okuyup mimariyi tahmin etmeye çalıştı ve bize her bir token için fatura kesti.
> Bir haritası yoksa, yapay zeka ajanı verinizi okumaz. İçinde sadece kaybolur.
Kurduğumuz sistemin gerçekliği tam o anda yüzüme çarptı. Yapay zekanın kafasının karışması için resmen servet ödüyorduk. Bu devasa token israfı kesinlikle sürdürülebilir değildi.
Testi derhal durdurduk. Ham metin yığınını yapılandırılmış bir graf ile değiştirdik; yapay zeka koda bakmadan önce fonksiyonlar arasındaki net ilişkileri haritalandırdık. Fark inanılmazdı. Token maliyetleri %99,9 çakıldı ve faturamız 4.000 dolardan tam olarak 4 dolara düştü. Ajan mimariyi anında kavradı.
Bu sadece yazılımcıların baş ağrısı değil. Tüm işiniz için çok ciddi bir sorun.
Alıcılar artık sitenize tıklamıyor. Yanıtları doğrudan yapay zeka ajanlarına soruyorlar. Ancak veri noktalarınız arasındaki ilişkileri anlayamadıkları için yapay zeka ajanlarınız sınıfta kalıyor.
Veriniz düz bir metin yığınından ibaretse, makine onu okuyamaz. Noktaları birleştiremez.
Kuruculara sürekli sadece "özel bir GPT yapın" diyen tavsiyelerden bıktım artık. Verinizi makineler arası (M2M) okuma için yapılandırmazsanız, görünmez olursunuz. Ya prompt'un içindesiniz ya da hiç yoksunuz.
Ham metnin çıkmaz sokak olduğunu anlamak, bizi her zaman kaçtığımız temel bir soruyu sormaya zorladı: Bu modeller için optimize etmek tam olarak ne anlama geliyor?
---
Geleneksel SEO ve Basit RAG Neden Çıkmaz Sokaktır?
Yapay zeka için knowledge graph optimizasyonu nedir?
Yapay zeka için knowledge graph optimizasyonu; veriyi büyük dil modellerine yapısal bağlam sağlamak amacıyla makine tarafından okunabilir düğümlere (nodes) ve kenarlara (edges) dönüştürme işlemidir. İnsanların okuduğu web sayfaları veya temel arama motoru sıralamaları yerine makineler arası (M2M) iletişimi önceliklendirdiği için geleneksel SEO'dan tamamen ayrılır.
Sözde uzmanların size basit bir RAG mimarisi kurun deyip durmasından resmen gına geldi. Çalışmıyor. Karmaşık yapay zeka görevlerinde kesinlikle işe yaramıyor.
SEO yaklaşımınız M2M (makineler arası) iletişimi hesaba katmıyorsa, modern yapay zeka ajanları için tamamen görünmezsiniz. Eski taktikler artık öldü. Sadece insan gözü için optimizasyon yapıp botların bunu çözeceğini umamazsınız.
Schema Markup Yanılgısı
Bunu acı bir yoldan öğrendik. Projeyi refactor etmek için yapay zeka kodlama ajanımıza standart varlık çözümleme (entity resolution) ve temel schema markup beslemeyi denedim. Standart SEO hilelerinin kod anlama tarafına da uyarlanabileceğini sanıyordum.
Net bir harita elde edeceğimi ummuştum.
Tamamen fiyaskoyla sonuçlandı.
Terminal çıktılarını şaşkınlıkla izledim. Ajan, gerçekte var olmayan bağımlılıklar uydurdu. Kimlik doğrulama modülümüz ile ana veritabanı arasındaki bağlantıyı tamamen kaçırdı. Sadece tahmin yürütüyordu.
Neden mi? Çünkü Google AI Overviews için geleneksel SEO varlık optimizasyonu yapmakla, karmaşık kod tabanları için yapısal bağlam haritaları oluşturmak tamamen farklı şeylerdir. Google, bir makalenin yazarının kim olduğunu bilmek ister. Bir yapay zeka kodlama ajanının ise auth.js dosyasındaki bir değişikliğin veritabanı şemasını tam olarak nasıl etkilediğini bilmesi gerekir.
> Bir repoya alelacele JSON-LD yapıştırıp otonom bir ajanın tüm mimariyi anlamasını bekleyemezsiniz.
Schema markup, arama motorlarının zengin snippet'ler göstermesi için tasarlanmıştır. Bir LLM'e devasa bir yazılım mimarisinin nasıl çalıştığını öğretmek için değil. Kurucuların bu ikisini birbirine karıştırması büyük bir hatadır.
Temel Retrieval-Augmented Generation (RAG) da aynı derecede yetersizdir. Metin parçalarını yalnızca vektör benzerliğine göre körü körüne çeker. Ham kodu alır ama ilişkileri kaybeder. Yapay zekaya kutunun üzerindeki resmi göstermeden yapboz parçalarını verir. Sonuçta elinizde parçalanmış bir karmaşa kalır.
Bizim yapısal bağlama ihtiyacımız vardı.
Temel RAG'in karmaşık mimarilerde başarısız olmasının nedenleri:
Sonuç? Kafası karışmış bir yapay zeka ajanı ve astronomik bir token faturası. Kendi haritasını bile okuyamayan bir sistem yüzünden para yakıyorduk.
---
Graphify Aydınlanması: Ham Veri Yerine Yapısal Bağlam
İşi tamamen yanlış yapıyorduk.
Devasa bir kod tabanını doğrudan bir LLM'e tıkıştırmak, parayı sokağa atmanın garantili yoludur. Bir makinenin kucağına bir milyon satırlık düz metin bırakıp karmaşık mimariyi anlamasını beklemek çok büyük bir hatadır. Yapay zeka kaybolur. Context window sınırına ulaşır. API faturanız patlar.
Köklü bir değişime ihtiyacımız vardı.
Düğümler, Kenarlar ve Halüsinasyonların Sonu
Büyük aydınlanma bizi sert vurdu. Yerel knowledge graph'lerin sadece akademisyenler için teorik bir kavram olmadığını anladık. Bunlar yapay zekanın kavraması için mutlak bir zorunluluktur.
Modele ham kod beslemeyi bıraktık. Bunun yerine tüm iş akışımızı Graphify kullanarak kalıcı bir kod grafına taşıdık.
Değişenler tam olarak şunlardı:
LLM tek bir mantık satırı bile okumadan önce, düğümleri ve kenarları haritalandırdık. Her bir fonksiyonun, sınıfın ve modülün birbiriyle nasıl etkileşime girdiğini tanımladık.
> Yapay zekaya bir labirent vermeyi bıraktık. Eline net bir harita verdik.
Bunu müşterinin reposunda test ettiğimizde iç metrikler inkâr edilemez derecedeydi. Token tüketimi %99,9 oranında azaldı. Tekrarlayan bağlamlar yüzünden 4.000 dolar yakmaktan, hafif ve yapılandırılmış bir haritayı iletmek için sadece 4 dolar harcamaya geçtik.
Doğruluk tavan yaptı. Halüsinasyonlar tamamen bitti.
Neden? Çünkü yapay zeka artık auth_module.py dosyasının veritabanı şemasına nasıl bağlandığını tahmin etmek zorunda değildi. Yapısal bağlam zaten oradaydı, grafa açıkça işlenmişti.
İşte amatör prompt mühendisliğini kurumsal düzeyde anlamsal aramadan ayıran teknik fark tam olarak budur.
Amatör prompt mühendisliği, context window'u doldurmaya ve modelin bunu çözeceğini ummaya dayanır. Tembelcedir. Pahalıdır. Kurumsal anlamsal arama ise yapısal bağlam inşa eder. Makineye ilişkiler arasında yerel olarak gezinmesi için tam olarak ne gerekiyorsa onu verir.
Yazılımcılara sadece "daha iyi prompt yazın" diyen tavsiyelerden artık gerçekten sıkıldım. Prompt'lar yapı eksikliğini düzeltemez.
Dedikleri gibi: Ya prompt'un içindesiniz ya da hiç yoksunuz. Ancak prompt'unuz sadece kaotik bir veri yığınından ibaretse, zaten kaybetmişsinizdir. İhtiyacınız olan şey bir graftır.
Bu farkındalık mimarimizi tamamen değiştirdi ama finans direktörümüzün aklına hemen teknik bir soru getirdi.
---
Gerçekten İşe Yarayan Bir Yerel Knowledge Graph Nasıl Kurulur?
Knowledge Graph'ler LLM token maliyetlerini nasıl düşürür?
Knowledge Graph'ler; devasa ve gereksiz ham metin girdilerini ilişkilerin son derece sıkıştırılmış, yapılandırılmış bir haritasıyla değiştirerek LLM token maliyetlerini düşürür ve context window'u optimize eder. Böylece yapay zekanın gereksiz verileri işlemeden, bir görevi doğru şekilde yürütmek için yalnızca gereken spesifik düğümleri ve kenarları sorgulamasını sağlar.
Bir LLM'e ham kod yığmak büyük bir para israfıdır. Klavyenin başına geçip size sadece "verilerinizi daha iyi parçalayın (chunking)" diyen sözde uzman tavsiyelerinden bıktım. Bu berbat bir tavsiye. Karmaşık mimarilerde feci şekilde çuvallar. Müşterimiz için teorik bir geçici çözüme değil, gerçek bir çözüme ihtiyacımız vardı.
Ontolojiyi Haritalandırmak: Adım Adım Rehber
Bağlam sınırlamalarınızı çözmek için uygulayabileceğiniz net çerçeve şudur:
Biraz araçlardan bahsedelim. Repoda Graphify ile code-review-graph araçlarını karşı karşıya getirdim. Hangisinin Claude Code için context window'u gerçekten optimize ettiğini görmem gerekiyordu.
Graphify gösterişlidir. Harika bir görsel temsil sunar. Peki kaputun altında ne var? Context window'u gereksiz meta verilerle şişirdi. Bunu fintech müşterimizin reposunda test ettiğimizde, sırf grafı ayrıştırmaya çalışırken bile token kullanımımızın %40 arttığını gördüm. Yapay zekaya harita yerine yine bir labirent sundu.
Sonra code-review-graph aracına geçtim.
Arayüzü çirkin. Pazarlaması sıfır. Ancak fazlalıklardan arındırılmış, düğümleri ve kenarları içeren net ontolojiyi haritalandıran yalın ve kalıcı bir kod grafı üretti.
> Yapay zekaya önce yapısal bağlam haritasını verdiğinizde, onu tahmin yürütmek yerine ilişkiler arasında gezinmeye zorlarsınız.
Fark anında görüldü. Token kullanımı %99,9'dan fazla düştü ve maliyetlerimiz sorgu başına kuruşlar seviyesine indi. Doğruluk zirve yaptı. Yapay zeka bağımlılıklar uydurmayı bıraktı ve çalışır durumda kod yazmaya başladı. Kimlik doğrulama middleware'inin veritabanı şemasına nerede bağlandığını tam olarak biliyordu çünkü graf bu ilişkiyi açıkça tanımlamıştı.
Bu mimari dönüşümü görmezden gelirseniz bu çok ciddi bir sorundur. Ya prompt'un içindesiniz ya da hiç yoksunuz.
Teknik SEO'nuz M2M iletişimini hesaba katmıyorsa, modern yapay zeka ajanları için tamamen görünmezsiniz. Alıcılar artık sitenize tıklamıyor. Kendi ajanlarına soruyorlar. Ve eğer ajanınız grafınızı okuyamıyorsa, kaybedersiniz.
---
Ya Prompt'un İçindesiniz Ya da Hiç Yoksunuz
M2M Gerçekliğiyle Yüzleşin
Bir konuda anlaşalım: Sadece insanlara yönelik arama dönemi kapandı.
Kuruculara sadece daha iyi blog yazıları yazmalarını söyleyen tavsiyelerden bıktım. İçerik insanlar içindir. Bağlam ise makineler içindir. 2026 yılındayız ve şu anda önemli olan tek geçerli para birimi makine tarafından okunabilir veridir.
Kendi analitiklerinize bakın. Alıcılar artık sitenize tıklamıyor. On mavi bağlantı arasında gezinmiyorlar. Ağır işleri yapay zeka ajanlarına yaptırıyorlar ve bu ajanlar harika tasarlanmış açılış sayfalarınızı tamamen es geçiyor.
SEO stratejiniz M2M iletişimini yok sayıyorsa, tamamen görünmezsiniz. Bu gerçekten ciddi bir sorundur.
Ham metin işe yaramaz. Düğümlere ihtiyacınız var. Kenarlara ihtiyacınız var. Bir LLM'in halüsinasyon görmeden veya devasa bir token faturası çıkarmadan okuyabileceği kalıcı bir grafa ihtiyacınız var.
> Verinizi makineler için bir grafa dönüştürmezseniz, rakipleriniz bunu kesinlikle yapacaktır.
Yapay zekaya önce yapısal bağlam haritasını onlar verecek. Context window'u onlar optimize edecek. Siz meta açıklamalarla uğraşırken onlar pazar payınızı elinizden alacak.
Biz bunu tecrübe ederek anladık. Kendi müşterilerimizin doğru mimariye sahip olmadıkları için yapay zeka çıktılarından kaybolup gitmesini izlemekten yorulmuştuk. Kendi içimizde AnswerShaper kullanmaya başlamamızın tam nedeni buydu. Şişirilmiş başka bir araca ihtiyacımız yoktu; sadece graf oluşturmayı otomatikleştirecek ve yapay zekayı tahmin yürütmek yerine ilişkilerde gezinmeye zorlayacak güvenilir bir yola ihtiyacımız vardı. Bize pazarlama süsleri olmadan yapay zeka ajanlarının talep ettiği yapısal bağlamı sağlıyor.
Orada olmayan gözler için optimizasyon yapmayı bırakın. Kararları veren ajanlar için optimize etmeye başlayın.
Ya prompt'un içindesiniz ya da hiç yoksunuz.
Karar sizin.