Multi-agent sistemleri işi makine hızında üretebilir, değerlendirebilir ve orkestre edebilir — ama hepsinin ortak bir zayıflığı var: her agent’ın hafızası, context window’uyla birlikte ölür. İki belgeyi bağlayan, üç farklı kaynaktan gelen gerçeği zincirleyen veya oturumlar arası paylaşılan bir dünya modelini sürdüren bir şey istiyorsanız, context window yetmez. İşte tam burada knowledge graph engineering devreye giriyor — Anthropic’in yayınladığı Knowledge Graph Cookbook ve Building Effective AI Agents dokümanlarına dayanan, çok-agent’lı sistemler için eksik altyapı katmanı.
Bu yazıda dört aşamalı bir pipeline’ı (extraction → resolution → assembly → querying) baştan sona inceleyeceğiz, neden RAG’ın multi-hop sorgularda yetersiz kaldığını göstereceğiz, ve bir knowledge graph’ın Anthropic’in beş canonical agent pattern’inde (augmented LLM, prompt chaining, routing, orchestrator–workers, evaluator–optimizer) tam olarak nereye oturduğunu göreceğiz.
Problem ve Tetikleyici Soru
Elimizde yapılandırılmamış bir belge yığını var ve cevabın tek bir belgede olmadığı sorular soruyoruz: “X projesinde çalışan kişilerin çalıştığı kişiler kim?”, “Bu olayla bağlantılı vendor’lar hangileri?” Hiçbir tek kaynak cevabı içermiyor.
Retrieval-augmented generation (RAG) semantik benzerlikle ilgili chunk’ları yüzeye çıkarabilir — ama gerçekleri sizin için zincirleyemez. İhtiyacınız olan şey bir knowledge graph: entity’ler node, tipli ilişkiler edge, böylece multi-hop reasoning graph traversal’a dönüşür.
Bir tane inşa etmek eskiden alanınıza özel named entity recognizer eğitmek, bir relation classifier eğitmek, ve entity-resolution için elle yazılmış heuristik’leri sürdürmek demekti. Veri kaydıkça her biri kırılıyordu. Claude ile bu üç aşama, üç prompt’a dönüşüyor. Klasik NLP pipeline’ı, “training data”sı bir Pydantic schema olan structured-output call‘lardan oluşan bir diziye çöküyor.
Knowledge Graph Neden Multi-Agent Sistemler İçin Kritik
Anthropic’in mühendislik rehberi agent’ları “tipik olarak sadece environmental feedback’e göre tool kullanan LLM’ler” olarak tanımlıyor ve en çok alıntılanan tavsiyesi complex framework’ler yerine simple, composable pattern’leri tercih edin yönünde. Beş canonical pattern (augmented LLM, prompt chaining, routing, orchestrator–workers, evaluator–optimizer) bu tür sistemleri inşa etmek için kelime hazinesi. Ama her biri bilginin context window’a sığdığını ya da tek bir arama çağrısıyla retrieve edilebileceğini varsayıyor.
Cevaplar belge ötesi zincirleme gerektirdiğinde veya birden çok agent’ın ortak bir dünya modelini paylaşıp üzerine inşa etmesi gerektiğinde, pattern’in altında bir altyapı katmanına ihtiyaç var. İşte o katman knowledge graph.
Somut Bir Senaryo
Bir competitive intelligence multi-agent sistemi düşünün. Bir orchestrator beş worker agent’a delege ediyor: pricing analyst, product analyst, financial analyst, marketing analyst ve strategic synthesizer. Her worker farklı bir belge dilimini işliyor.
Strategic synthesizer beş analizi birbirine zincirlemek zorunda: “Fiyatını %15 düşüren rakip, patent başvurusu yeni ürün hattına işaret eden ve çeyreklik raporunda R&D harcamasını ikiye katlayan aynı şirket.” Hiçbir tek worker üç gerçeği de görmedi. Worker’lar yalnızca orchestrator’ın context window’ı üzerinden iletişim kuruyorsa, o window worker sayısıyla doğrusal büyüyüp en büyük modelin bile kapasitesini aşıyor. Ama worker’lar bulgularını entity ve ilişki olarak paylaşılan bir knowledge graph’a yazarsa, synthesizer bu bağlantıyı hiçbir intermediate context olmadan graph traversal ile keşfedebilir.
Pipeline: Dört Aşama
Tüm pipeline dört aşamadan oluşuyor ve her biri tek bir Claude API call olarak implemente ediliyor — eğitilmiş model yok, harici NLP kütüphanesi yok, graph database zorunluluğu yok.
- Extraction — Haiku. Belge başına typed entity’ler + S-P-O triple’ları çıkarır.
- Resolution — Sonnet. Surface-form varyantlarını canonical node’lara birleştirir (“Edwin Aldrin” → “Buzz Aldrin”).
- Assembly — Graph + Summarization. MultiDiGraph + entity profile’ları oluşturur.
- Querying — Sonnet. Subgraph’ı serialize eder → grounded answer üretir (edge-level citation’lı).
Aşama 1: Extraction (Haiku)
Klasik NER text span’lerini etiketler (PERSON, ORG, LOC). Klasik relation extraction tagged span çiftlerini ilişki tiplerine sınıflandırır (works_at, located_in). Biz her iki aşamayı belge başına tek bir Claude call’a çökertiyoruz. Anahtar nokta structured outputs: çıktı şeklini bir Pydantic model olarak tanımlıyoruz ve client.messages.parse()‘a veriyoruz. Claude’un cevabı bu schema’ya karşı validate olacağı garanti — typed Python object olarak dönüyor. Regex yok, JSON decode hatası yok, defensive check yok.
EntityType = Literal["PERSON", "ORGANIZATION",
"LOCATION", "EVENT", "ARTIFACT"]
class Entity(BaseModel):
name: str
type: EntityType
description: str # tek satır, disambiguation için
class Relation(BaseModel):
source: str
predicate: str # kısa verb phrase
target: str
class ExtractedGraph(BaseModel):
entities: list[Entity]
relations: list[Relation]Extraction Prompt’unun Gücü
Prompt Claude’a dört şey söylüyor:
- Yalnızca belgeye merkezi olan entity’leri çıkar — incidental mention’ları atla.
- Her entity için bu belgeye dayanan tek cümlelik description yaz (bunlar entity resolution’ın disambiguation sinyali).
- Predicate olarak kısa verb phrase’ler kullan (
"commanded","launched from","part of"). - Her relation çıkardığın iki entity’yi birbirine bağlamalı.
Description’lar kritik: “Armstrong — Moon’a ayak basan ilk kişi” ile “Armstrong — caz trompetçisi” aynı isme sahip ama asla merge edilmemeli. Description, eğitilmiş bir classifier’ın alan-spesifik labeled data’dan öğreneceği şeyin yerini alıyor.
Prompt’taki “sadece merkezi entity’leri çıkar” ifadesi bilinçli bir tercih — recall’u feda edip precision’ı koruyor. Recall önemliyse zayıflatabilirsiniz, ama büyük corpus’ta her yanlış entity yanlış ilişki doğurur. Bu trade-off’ı bilinçli yapabilmenizi sağlayan şey, birazdan göreceğimiz evaluation feedback loop.
Aşama 2: Resolution (Sonnet)
Ham extraction overlapping mention’lar veriyor: “NASA” ve “National Aeronautics and Space Administration”, “Neil Armstrong” ve “Armstrong”, “the Moon” ve “Moon”. Doğrudan bunun üzerine graph kurmak, aynı kavramın parçalanmış node’lara bölündüğü kırık bir yapı üretir.
Geleneksel yaklaşım edit distance + Jaccard gibi string similarity + blocking rules kullanır. Bu typo’lar için çalışır ama “Edwin Aldrin” ile “Buzz Aldrin” için tamamen başarısız olur — sıfır karakter örtüşmesi olan ama aynı kişiye atıfta bulunan iki isim. Biz bunun yerine Sonnet’tan (güçlü reasoning’i için) entity’leri type’a göre cluster etmesini, extraction’dan gelen tek satırlık description’ları disambiguation context olarak kullanmasını istiyoruz.
class Cluster(BaseModel):
canonical: str # en eksiksiz form
aliases: list[str] # tüm surface form'lar
class ResolvedClusters(BaseModel):
clusters: list[Cluster]
RESOLVE_PROMPT = """Below are {entity_type} entities
extracted from several documents. Some are different
surface forms of the same real-world entity.
Cluster them. Each input name must appear in exactly
one cluster's aliases list. Entities that are
genuinely distinct get their own single-element
cluster. Use the descriptions to avoid merging
entities that merely share a name. The canonical
name should be the most complete, unambiguous
form."""Apollo corpus’unda resolution, 24 unique surface form‘u 22 canonical entity‘ye indirdi — “Edwin Aldrin” → “Buzz Aldrin” ve “Neil Armstrong” → “Neil Alden Armstrong” yakalandı. String similarity’in tamamen kaçıracağı durumlar.
İki Failure Mode
Resolution aşamasında izlenmesi gereken iki başarısızlık modu var. Birincisi: bir ham isim hiçbir cluster’a girmezse sessizce kaybolur (alias map’te entry’si yok). Production resolver unmatched isimler için single-element cluster fallback uygulamalı. İkincisi: over-merging — örneğin “Gemini 12”‘yi description örtüşmesi yüzünden “Project Gemini”‘ye katlayabilir. Biri node kaybeder, diğeri precision kaybeder. İkisi de spot-check edilmeli — Section VIII’deki evaluation harness tam da bunu yakalayan feedback loop’u sağlıyor.
Aşama 3: Assembly ve Summarization
Temiz bir alias map ile her relation endpoint’i canonical formuna yeniden yazılır ve NetworkX MultiDiGraph‘a yüklenir. MultiDiGraph kullanmamızın sebebi: iki entity birkaç farklı predicate ile bağlanabilir ("launched from" ve "operated by") ve yön önemlidir (“Armstrong commanded Apollo 11” ile “Apollo 11 commanded Armstrong” aynı edge değildir). Her node type, source document ve mention count taşır; her edge predicate ve provenance document taşır.
Apollo graph’ı: 22 node, 34 edge, 1 connected component. Tek connected component olması başlı başına resolution’ın çalıştığının kanıtı — parçalanmış adalar, merge edilmesi gerekip edilememiş varyantlara işaret eder. Hub node’lar (Apollo program ve Apollo 11, her biri degree 9) corpus’u birbirine bağlayan entity’ler; visualization’da node boyutu degree ile ölçeklenir ve builder’a corpus yapısının hızlı tanısını verir.
Summarization Ne Zaman?
Summarization pahalı — birden çok belgeyi ve graph neighborhood’u Sonnet call’unda birleştirmek gerekiyor — bu yüzden seçici uygulanmalı. Doğal kriter degree: degree’e göre top-k node’ları özetle, çünkü bunlar en çok belgeyi bağlayan ve cross-document synthesis’ten en çok fayda gören entity’ler. Pratik kesim noktası: degree ≥ 3 (en az iki farklı yönden iki belgede geçmiş). Altında, tek-belge description’ı genelde yeterli.
Aşama 4: Multi-Hop Querying
Bir knowledge graph kurmanın asıl getirisi multi-hop reasoning: lexical veya semantik benzerlik paylaşmayan belgelerdeki gerçekleri zincirleyen soruları cevaplamak. “Apollo 11’de uçan kişilerin bağlantılı olduğu location’lar hangileri?” için bir belgeden person→mission edge’leri, bir diğerinden person→location edge’leri, sonra resolver’ın person node’larını birleştirmiş olması gerekir — ancak o zaman o edge’ler buluşabilir.
Querying mekanizması basit: ilgili subgraph’ı (seed entity’nin k-hop neighborhood’unu) triple olarak serialize et ve Claude’a üzerinde reasoning yaptır. Grounded answer ile ungrounded answer arasındaki fark, multi-agent sistemler için belirleyici: grounded answer her iddiayı belirli bir edge ve belirli bir belgeye cite eder. Claude’un prior knowledge’ı olmadığı private corpus’ta yalnızca grounded answer çalışır.
Subgraph Seçimi: k Değeri
k (seed entity’den hop sayısı) coverage/noise trade-off’unu kontrol eder. k=1‘de sadece doğrudan komşular — hızlı ve odaklı ama dolaylı bağlantıları kaçırır. k=2‘de komşuların komşuları — çoğu multi-hop sorusu için sweet spot, graph’ın değerli kılan zincirleri yakalar. k=3 ve ötesinde subgraph hızla büyüyüp context window’u aşabilir, bu noktada serialize edilmiş triple’lar Claude’a beslenmeden önce filtering veya summarization gerekir. Apollo corpus’unda herhangi bir hub’dan k=2, neredeyse tüm graph’ı (22 node, 34 edge) yakalar ve tek bir Sonnet call’una rahatça sığar.
RAG ile Knowledge Graph Arasındaki Fark
RAG semantic similarity ile text chunk’larını retrieve edip context window’a besler. Bu, cevabın tek bir pasajda bulunduğu single-hop sorular için iyi çalışır. Cevap, kendi aralarında ve sorguyla hiçbir lexical veya semantik benzerlik paylaşmayan pasajlardaki gerçekleri zincirlemeyi gerektiren multi-hop sorularda başarısız olur. Bir knowledge graph bu boşluğu doldurur: iki aksi halde ilgisiz belgeyi bağlayan entity, ikisine de explicit edge ile bağlı bir node’dur ve graph traversal bu bağlantıyı surface-form benzerliğinden bağımsız olarak keşfeder.
İki yaklaşım rakip değil, tamamlayıcı. RAG ucuz ve direct retrieval için etkili. Knowledge graph RAG’ın yapamadığı structural reasoning’i yapar. LLM ise her iki kaynağı birleştirerek sentezler. Pratikte en iyi sonuç, hepsinin birlikte kullanılmasıyla çıkar.
Knowledge Graph, Beş Agent Pattern’inde
Anthropic’in dokümante ettiği beş pattern’in her birinin knowledge graph ile doğal bir entegrasyon noktası var.
| Pattern | KG rolü | Nasıl yardımcı olur |
|---|---|---|
| Augmented LLM | Retrieval source | Multi-hop sorular için vector search yerine graph traversal; LLM graph’ı tool olarak sorgular. |
| Prompt chaining | Gate signal | Chain adımları arasında graph query, yeni entity’lerin mevcut node’larla çakışıp çakışmadığını kontrol eder. |
| Routing | Classifier input | Graph’tan gelen entity type ve degree, sorguyu doğru uzmana yönlendirir — LLM call’a gerek kalmadan. |
| Orchestrator–workers | Shared memory | Worker’lar graph’tan okur/graph’a yazar; orchestrator’ın window’u temiz kalır. |
| Evaluator–optimizer | Grounding layer | Evaluator iddiaları provenance’lı graph edge’lerine karşı kontrol eder. |
Orchestrator–Workers İçin Shared Memory
Bir orchestrator beş worker agent’a delege ettiğinde, her biri kendi context window’unda çalışır. Klasik problem context management: “context tek bir agent’ın etkili bir şekilde yönetemeyeceği kadar karmaşık hale gelir, agent’lar tutarlılığı korumakta zorlanırken performans darboğazları oluşur.” Knowledge graph bunu yapısal olarak çözüyor. Özetleri orchestrator’ın window’undan geçirmek yerine (worker sayısıyla doğrusal büyür), her worker göreviyle ilgili subgraph’ı okur ve yeni entity/relation’ları yazar. Orchestrator’ın context’i küçük kalır; paylaşılan durum graph’ta yaşar, herhangi bir agent tarafından herhangi bir zamanda sorgulanabilir.
Evaluator–Optimizer İçin Grounding Layer
Evaluator–optimizer pattern’i “iki AI sistemini iteratif döngülerde çalıştırır: biri içerik üretirken diğeri değerlendirip geri bildirim sağlar, kalite standardı karşılanana dek tekrarlanır.” Herhangi bir evaluator’ın en zor tarafı yargı dayanağıdır: ground truth olmadan evaluator “bu doğru görünüyor mu” diye sorar, “bu doğru mu” değil. Knowledge graph, evaluator’a daha iyi bir şey veriyor — generator’ın iddia ettiği spesifik triple’ı graph’ta sorgulayabilir, predicate’in ne olduğunu, hangi source document’tan geldiğini kontrol edebilir. Bu, evaluator’ı bir okuyucudan bir fact-checker’a kaydırır; verdiği geri bildirim “bu yanlış” değil “(X, works_at, Y) triple’ı graph’ta yok; graph (X, left, Y) içeriyor, document Z’den” olur.
Somut bir örnek: bir generator agent “Armstrong commanded Gemini 12” diye bir araştırma özeti üretiyor. Graph erişimi olmayan bir evaluator bunu geçirebilir — iddia mantıklı, Armstrong gerçekten bir astronottu ve Gemini 12 gerçek bir görevdi. Graph erişimi olan evaluator (Neil Alden Armstrong) --[commanded]--> (Gemini 12) için sorgu çalıştırır ve böyle bir edge bulamaz. (Buzz Aldrin) --[flew on]--> (Gemini 12) ve (Neil Alden Armstrong) --[commanded]--> (Apollo 11) bulur. Geri bildirim kesin: “Armstrong Gemini 12’ye komuta etmedi; Aldrin Gemini 12’de uçtu. Armstrong Apollo 11’e komuta etti.” Bu fact-checking, model estimation değil — graph her edge’i belirli bir belgeye kadar taşıdığı için.
Loops İçin Persistent World Model
Self-improving bir loop’un context-window flush’larına dayanan hafızaya ihtiyacı var. Graph o hafıza. Gece boyunca yeni belgeler gelir, mevcut canonical set’e karşı resolve edilir (birbirlerine karşı değil), edge’leri eklenir. Bir entity yalnızca source-document set’i maddi olarak değiştiğinde yeniden özetlenir. Loop’un state file’ı hangi belgelerin işlendiğini ve hangi entity’lerin yeniden özetlenmesi gerektiğini kaydeder; graph’ın kendisi run’lar arasında biriken dünya modelidir. Bu, Anthropic’in “session context window değildir” ilkesinin multi-agent karşılığı: session — burada knowledge graph — durable, append-only ve positional slice ile sorgulanabilir. Worker’ın context’i flush edildiğinde kaybolmaz.
Evaluation Feedback Loop
Knowledge graph kalitesi bir gold set’e karşı precision ve recall ile ölçülür. Değerlendirme iki şeyi puanlar: ham extractor çıktısı ve resolution sonrası aynı entity’ler. Apollo corpus’unda precision mükemmel (1.00) — Haiku’nun çıkardığı her şey doğruydu. Recall daha düşük (0.38–0.55) — extractor gold set’in önemli saydığı bazı entity’leri kaçırdı.
Bu trade-off bilinçli: bir production sistemde false positive (graph’ta yanlış entity) false negativeten (eksik entity) daha zor tespit edilir ve daha zararlıdır — çünkü yanlış bir entity, multi-hop reasoning boyunca yayılan yanlış ilişkiler doğurur. Eksik entity eksik ama doğru bir graph üretir; yanlış entity aktif olarak yanlış yönlendiren bir graph üretir.
Feedback loop — extraction prompt’unu değiştir, scorer’ı yeniden çalıştır, F1’in nasıl hareket ettiğini izle — bir demo’yu production sistemine dönüştüren mekanizma. Bu loop, self-improving agentic loop ile aynı şekildedir: act (extract), observe (score), learn (prompt’u tune et), repeat. Knowledge graph hem böyle bir loop’un çıktısı hem de çalışmasını sağlayan altyapıdır. Pipeline’ı evaluation harness olmadan teslim eden bir ekibin, prompt değişikliklerinin kaliteyi iyileştirip kötüleştirdiğini bilme, corpus evrildikçe oluşan yavaş drift’i yakalama yolu yoktur.
Ölçeklendirme Rehberi
Cookbook altı belgeyi bellekte işledi. Production knowledge graph’ları binlerce. Dört düşünce geçişi yönetir.
Extraction Maliyeti
Haiku büyük corpus’larda çalıştırmaya yetecek kadar ucuz, ama extraction schema ve instruction’ları sabit kaldığında prompt caching maliyetleri daha da düşürür — system prompt ve schema’yı cache’le, yalnızca belge metni için tam fiyat öde. Message Batches API 24 saate kadar latency’yi tolere eden işler için %50 indirim sağlar. Ortalama 2.000 token olan 10.000 belgelik bir corpus için extraction maliyeti, Haiku fiyatlarında tek haneli dolar seviyesinde — dedicated bir NER modeli eğitmenin ve çalıştırmanın küçük bir kesri.
Resolution Ölçekte
On bin PERSON entity’sini tek bir prompt’ta Claude’a beslemek çalışmaz. Önce block: adayları ucuz sinyallere göre grupla (aynı soyadı, örtüşen token’lar, embedding benzerliği), Claude yalnızca küçük block’lar içinde hakemlik yapsın. Resolution prompt, 50–100’lük block’larda değişmeden çalışır. Blocking’in kendisi name token’ları üzerine basit bir inverted index ile implemente edilebilir — model call gerekmez. Bu hibrit yaklaşım — ucuz deterministic blocking + block içinde pahalı LLM arbitration — pipeline’ın her yerinde kullandığı aynı pattern: judgment gerektiren parçalar için modeli tut, geri kalan her şey için deterministic logic kullan.
Incremental Updates
Yeni belge geldiğinde, entity’lerini çıkar, mevcut canonical set’e karşı resolve et (birbirlerine karşı değil) ve yalnızca yeni edge’leri ekle. Bir entity’yi yalnızca source-document set’i maddi olarak değiştiğinde yeniden özetle. Graph, loop’un state file’ının analoğudur: biriktirir, yeniden inşa etmez.
Depolama
NetworkX birkaç yüz bin edge’e kadar yeterlidir. Ötesinde, schema doğrudan bir property graph’a (Neo4j, Neptune) veya üç Postgres tablosuna eşlenir: entities(id, name, type, summary), relations(source_id, target_id, predicate), aliases(entity_id, alias). Extraction ve resolution kodu değişmez — yalnızca persistence katmanı değişir. Neo4j zaten çalışan ekipler için eşleme doğrudandır: her entity type, description ve source document property’leri taşıyan labeled node olur; her relation provenance property’si taşıyan typed edge olur. Graph database olmayan ekipler için Postgres yaklaşımı daha basit: üç tablo, standart SQL, recursive CTE ile graph query.
Uzun Belgeler İçin Chunking
Cookbook Wikipedia özetlerini kullanıyor — tek bir extraction call’una rahat sığan kısa metinler. Production belgeleri daha uzun: hukuki sözleşmeler, araştırma makaleleri, teknik dokümantasyon. Bunlar için belge, extraction’dan önce chunk’lanmalı ve chunk’lar entity’lerle ilişkileri aynı chunk içinde tutacak şekilde tasarlanmalı. Token sayısına göre naif chunking entity’leri context’ten ayırır; paragraf veya section boundary’ye göre semantic chunking, extractor’ın bağımlı olduğu co-occurrence yapısını korur. Pratik bir kural: section boundary’de chunk’la, bir paragraf örtüşmesiyle — böylece bir section’ın sonunda anılan entity, bir sonrakinin başında tanımlanan ilişkiler için hâlâ context’te olur. Extraction prompt chunk’lar üzerinde değişmeden çalışır; ek adım, resolution’dan önce aynı belgenin chunk’ları arasında entity’leri deduplicate etmektir — exact string matching ile hafif bir per-document resolution pass’ı.
Production Monitoring
Bir production knowledge-graph pipeline’ı dört monitoring sinyaline ihtiyaç duyar:
- Extraction rate — Belge başına çıkarılan entity ve relation sayısı. Ani düşüş, corpus’un prompt’un kötü işlediği bir alana kaydığını; ani spike, extractor’ın peripheral mention’ları aşırı çıkardığını gösterir.
- Resolution compression ratio — Ham surface form sayısı / canonical entity sayısı. 1.0’a yakın oran corpus’un tutarlı adlandırma kullandığını ve resolution’ın az iş yaptığını; 2.0 üstü oran ciddi naming varyasyonu olduğunu ve resolution’ın maliyetini hak ettiğini gösterir.
- Graph connectivity — Connected component sayısı ve en büyüğünün boyutu. Büyüyen disconnected component sayısı, resolution’ın cross-document bağlantıları kaçırdığını gösterir.
- Query latency — Sorudan grounded answer’a geçen süre. Real-time uygulamalar için yüksek trafiğe sahip seed entity’ler için subgraph serialization önceden hesaplanmalıdır.
Bilmeniz Gereken Sınırlamalar
Üç sınırlama açıkça söylenmeli. Birincisi, extraction kalitesi prompt engineering’e bağlıdır; evaluation harness feedback loop sağlar ama loop’un çalıştırılması gerekir. İkincisi, resolution ölçekte domain-dependent blocking heuristics gerektirir — clustering prompt’u evrensel ama blocking değil. Üçüncüsü, graph yalnızca inşa edildiği belgeler kadar iyidir; önyargılı veya eksik bir corpus, önyargılı veya eksik bir graph üretir ve önyargılı bir graph üzerinde hiçbir miktarda multi-hop reasoning, önyargısız cevap üretmez. Graph, corpus’un kalitesini amplify eder — tıpkı bir loop’un builder’ın yargısını amplify etmesi gibi.
Gelecek Yönler
Üç doğal uzantı var. Birincisi, temporal graphs: edge’lere timestamp ekleyerek graph’ın sadece neyin doğru olduğunu değil ne zaman doğru olduğunu yakalaması — “Bu rolü Q3 2024’te kim tutuyordu?” gibi soruları mevcut atemporal graph cevaplayamıyor. EntityProfile zaten TimeRange içeriyor; relation’ları benzer bir field ile extend etmek schema’da basit ve Claude’un reasoning’den önce subgraph’ları time window’a göre filtrelemesini sağlar. İkincisi, confidence scoring: her edge’e, model’in kendi belirsizliğinden veya cross-document corroboration’dan türetilen bir extraction-confidence sinyali eklemek — üç bağımsız belgeden çıkarılan edge, tek bir kaynaktan çıkarılandan daha güvenilir. Bu, evaluator’ın tüm edge’leri eşit güvenilir olarak değil ağırlıklandırarak fact-check yapmasını sağlar. Üçüncüsü, graph-of-graphs: çoklu ekip ortamında her ekip kendi domain graph’ını korur; meta-graph domain graph’ları arasındaki bağlantıları kaydeder, uyumsuz schema’ları birleştirmeden cross-team reasoning sağlar.
Sonuç
Knowledge graph engineering, multi-agent sistemlerin “her agent’ın hafızası context window’uyla birlikte ölür” temel zayıflığına yapısal bir cevaptır. Graph, durable, sorgulanabilir, provenance taşıyan dünya modelidir — agent’ların durumu orchestrator’ın darboğazından geçirmeden paylaşmasını, evaluator’ın kendi estimation’larına karşı değil extracted edge’lere karşı fact-check yapmasını sağlar.
Tüm pipeline — extraction (Haiku), resolution (Sonnet), assembly (NetworkX + Sonnet summarization), querying (Sonnet + serialized subgraph) — eğitilmiş model olmadan, harici NLP kütüphanesi olmadan, graph database olmadan çalışır. Pydantic schema tek “training data”dır; graph Claude’un okuyabildiği her alanda çalışır; tüm pipeline prompt, schema ve graph kütüphanesinden ibarettir.
Pratik bir başlangıç noktası arıyorsanız: Entity, Relation, ExtractedGraph için Pydantic modellerini tanımlayın, yukarıdaki extraction prompt’unu alın, küçük bir corpus üzerinde Haiku ile extraction yapın, Sonnet ile resolution yapın, NetworkX’e yükleyin, manuel olarak sorgulayın. İlk grounded answer’ınızı aldığınızda, RAG’ın “bulamaz” dediği yerde graph’ın “bulur” demesini izlemenin verdiği tatmin, tüm pipeline’ın neden bu kadar hızlı geri ödediğini açıklıyor.
Bu yazı Anthropic’in yayınladığı “Knowledge Graph Cookbook”, “Building Effective AI Agents” ve Claude API dokümantasyonuna dayanan, 2026 Working Note on Agentic Software Engineering Practice: “Knowledge Graph Engineering for Multi-Agentic Systems: The Anthropic Playbook” sentezinden hazırlanmıştır. Anthropic ile bağlantı veya onay yoktur.
Emre Zorlu 