Merhabalar,

Bu yazıda son aylarda yapay zekâ gündeminde sıkça karşımıza çıkan üç kavramı inceleyeceğiz: LLM Wiki, Open Knowledge Format (OKF) ve OpenWiki. Üçünün ne olduğunu, hangi problemi çözdüğünü, arka planda nasıl çalıştığını ve birbirine nasıl bağlandığını örneklerle ele alacağız.

Her Sabah İşe Yeni Başlayan Bir Stajyer

Ekibinize çok zeki bir stajyer katıldığını düşünelim. Ne sorsanız arşive gidiyor, ilgili dosyaları buluyor, okuyor ve size gayet iyi bir cevap veriyor. Tek bir sorun var: Ertesi sabah her şeyi unutmuş oluyor.

Dün “Kargoya verilmiş sipariş iptal edilebilir mi?” diye sordunuz. Arşivden sipariş kurallarını, kargo sözleşmesini ve iade politikasını okuyup cevapladı. Bugün aynı soruyu sordunuz; yine aynı üç dosyayı baştan buluyor, baştan okuyor, baştan birleştiriyor. Dün öğrendiği hiçbir şey bir yere yazılmamış.

Bugün kullandığımız AI agent’ların çoğu tam olarak bu stajyer gibi çalışıyor. Andrej Karpathy Nisan 2026’da bu soruna basit bir cevap önerdi: Stajyere bir defter verin ve okuduklarını oraya yazdırın. Ardından Google bu defter için herkesin okuyabileceği ortak bir format yayımladı, LangChain de defteri sizin yerinize tutan bir araç çıkardı. Yazının geri kalanında bu üç adımı sırayla açacağız.

Önce Temel: RAG Nasıl Çalışır ve Neden Her Seferinde Sıfırdan Başlar?

Bugün bir yapay zekâya kendi belgelerimizi kullandırmanın en yaygın yolu RAG (Retrieval-Augmented Generation), yani “getirilen bilgiyle desteklenmiş üretim”. Mantığı üç adımdan oluşuyor:

1. Belgeler küçük parçalara (chunk) bölünür ve aranabilir hale getirilir.
2. Bir soru geldiğinde en alakalı parçalar bulunur.
3. Bu parçalar soruyla birlikte modele verilir ve model cevabı yazar.

Şimdi gelin bunu stajyer örneğimizle görelim. Soru yine aynı: “Kargoya verilmiş sipariş iptal edilebilir mi?”

• RAG, sipariş kurallarından bir paragraf, kargo sözleşmesinden bir sayfa ve iade politikasından bir bölüm getirir.
• Model okur ve iki belgenin farklı şeyler söylediğini fark eder. Kargo sözleşmesi “kargodaki sipariş iptal edilemez” der, iade politikası ise “teslimden sonra iade talebi açılabilir” der.
• Model bu ikisini birleştirir ve doğru cevabı verir: İptal edilemez, ama teslimden sonra iade süreci başlatılabilir.

Güzel bir cevap. Peki bu cevaba ulaşırken bulunan “iptal ile iade aynı şey değil” bilgisi nereye kaydedildi? Hiçbir yere. Yarın aynı soru geldiğinde RAG aynı üç parçayı yeniden bulacak, model aynı çelişkiyi yeniden fark edecek ve aynı sonuca yeniden ulaşacak.

RAG’in yapısal sınırı tam olarak bu: Bilgi birikmez. Her sorgu sıfırdan başlar; bir sorgudan diğerine hiçbir şey öğrenilmez. Bir araştırma makalesinin ifadesiyle RAG uzun metin problemini çözer ama birikim problemini çözmez; oturumlar arasında hiçbir şey derlenmez, çapraz bağlanmaz, güncel tutulmaz.

Bunun maliyetini Token Kaçağı yazısında konuşmuştuk: Agent’ın harcadığı tokenların büyük kısmı üretilen cevaptan değil, o cevaba ulaşmak için tekrar tekrar okunan context’ten geliyor. Stajyerimizin her sabah aynı arşivi baştan taraması da tam olarak bu.

LLM Wiki Nedir? Stajyere Bir Defter Vermek

Andrej Karpathy 4 Nisan 2026’da GitHub’da “LLM Wiki” başlıklı kısa bir not paylaştı. Bu bir ürün ya da kütüphane değil; bir AI agent’a yapıştırılıp birlikte uygulanmak üzere yazılmış bir fikir dosyası.

Fikir şu: LLM, okuduğu kaynakları her soruda baştan sentezlemek yerine, kalıcı ve birbirine bağlı markdown sayfalarından oluşan bir wiki’yi adım adım kendisi yazsın ve güncel tutsun. Sentez bir kez, kaynak içeri alınırken yapılır. Sorular, hazır derlenmiş bu wiki üzerinden cevaplanır.

Peki bu neden şimdi mümkün? İnsanlar kişisel wiki’leri genelde bir süre sonra bırakır. Sebep okumak ya da düşünmek değil, kayıt tutmanın yükü. Wiki büyüdükçe bakım maliyeti, getirdiği faydadan daha hızlı artar. Karpathy’nin tespitine göre LLM’ler tam bu işte iyi: Sıkılmazlar, bir çapraz bağlantıyı güncellemeyi unutmazlar ve tek seferde 15 dosyaya dokunabilirler. Fikrin kökü de eski: Vannevar Bush’un 1945’te hayal ettiği, birbirine bağlı kişisel bilgi makinesi Memex.

Üç katman

• Ham kaynaklar: Makaleler, sözleşmeler, toplantı notları. Değiştirilmez; sadece okunur.
• Wiki: LLM’in yazdığı, birbirine bağlantılı markdown sayfaları.
• Şema: LLM’e wiki’yi nasıl tutacağını anlatan kural dosyası. Genelde CLAUDE.md ya da AGENTS.md.

Üç işlem

• Ingest (içeri alma): Yeni bir kaynak geldiğinde LLM onu okur, ilgili sayfaları günceller, gerekirse yeni sayfa açar ve bağlantıları ekler.
• Query (sorgulama): Soru geldiğinde LLM önce içindekiler sayfasına bakar, ilgili sayfaları okur ve cevaplar. Değerli bir cevabı wiki’ye geri yazar.
• Lint (bakım): Düzenli aralıklarla çelişkileri, kopuk bağlantıları ve eksikleri arar.

İki dosyanın özel bir rolü var: index.md wiki’nin içindekiler sayfası, log.md ise tarih sırasıyla tutulan değişiklik günlüğü.

Adım adım bir örnek

Stajyerimizin defteri diskte şöyle görünsün:

sirket-wiki/
├── raw/
│   ├── kargo-sozlesmesi.pdf
│   ├── iade-politikasi.docx
│   └── 2026-11-03-toplanti-notu.md
├── wiki/
│   ├── index.md
│   ├── log.md
│   ├── siparis-iptali.md
│   ├── iade-sureci.md
│   └── kargo-durumlari.md
└── AGENTS.md

Bugün raw/ klasörüne yeni bir toplantı notu düştü: “Ocak 2027’den itibaren iade süresi 14 günden 30 güne çıkıyor.” Ingest başlıyor:

1. LLM notu okur ve bunun iade süresiyle ilgili olduğunu anlar.
2. iade-sureci.md sayfasındaki süreyi 30 gün olarak günceller ve kaynağını not eder.
3. siparis-iptali.md sayfasında “teslimden sonra iade” yönlendirmesindeki süreyi de düzeltir.
4. Eski bir SSS sayfasının hâlâ 14 gün dediğini fark eder ve bunu çelişki olarak işaretler.
5. log.md dosyasına bir kayıt ekler:

## [2026-11-03] ingest | Toplantı notu: iade süresi
- iade-sureci.md: iade süresi 14 → 30 gün olarak güncellendi
- siparis-iptali.md: iade yönlendirmesindeki süre düzeltildi
- Çelişki: sss.md hâlâ 14 gün diyor, bakım için işaretlendi

Tek bir not, wiki’de birden fazla sayfaya dokundu. Ertesi sabah aynı soru geldiğinde stajyer arşive gitmiyor; defteri açıyor. siparis-iptali.md sayfasında cevap zaten derlenmiş halde duruyor: “Kargodaki sipariş iptal edilemez; teslimden sonra 30 gün içinde iade başlatılabilir.”

Karpathy bu yaklaşımın yaklaşık 100 kaynak ve birkaç yüz sayfaya kadar, vektör tabanlı bir RAG altyapısı kurmadan şaşırtıcı derecede iyi çalıştığını belirtiyor. Kendi wiki’sinin yaklaşık 100 makale ve 400 bin kelimeye ulaştığı da aktarılıyor. Sayfaları gezmek için Obsidian gibi bir not uygulaması öneriyor; ama dosyalar düz markdown olduğu için bu zorunlu değil.

OKF Nedir? Herkesin Okuyabileceği Ortak Bir Defter

LLM Wiki fikri hızla yayıldı ve kısa sürede onlarca uygulama ortaya çıktı. Ama bir sorun vardı: Her biri kendi kafasına göre kurulmuştu.

Şirketinizde üç farklı ekibin üç farklı stajyeri olduğunu düşünelim. Her biri defterini tutuyor ama biri başlıkları büyük harfle yazıyor, biri tarihleri en üste koyuyor, biri kendi kısaltmalarını kullanıyor. Her defter sadece onu yazan stajyerin işine yarıyor.

Google Cloud ekibi aynı tespiti yaptı. Karpathy’nin wiki’si, sizin ekibinizin wiki’si ve bir firmanın dışa aktardığı katalog birbirine benziyor: markdown, üst bilgi, çapraz bağlantılar. Ama hiçbiri birlikte çalışacak şekilde tasarlanmamış. Her belgenin hangi alanları taşıması gerektiğine ya da hangi dosya adının ne anlama geldiğine dair ortak bir cevap yok. Sonuç: Bilgi, onu üreten ekibin içinde hapsoluyor.

Google’ın cevabı Open Knowledge Format (OKF) oldu. 12 Haziran 2026’da Sam McVeety ve Amir Hormati tarafından duyurulan OKF, LLM Wiki desenini taşınabilir ve birlikte çalışabilir bir formata dönüştüren açık, satıcıdan bağımsız bir spesifikasyon. Google’ın tespiti net: Eksik olan yeni bir servis değil, ortak bir format.

OKF nasıl çalışır?

OKF bilinçli olarak sade tutulmuş:

• Sadece markdown: Her editörde okunur, GitHub’da görüntülenir.
• Sadece dosya: Bir klasör; git deposunda tutulabilir, sıkıştırılıp gönderilebilir.
• Sadece YAML üst bilgisi: Sorgulanabilir olması gereken birkaç alan için.

Bir OKF paketi (bundle) bir klasördür. Her dosya bir kavramı anlatır: bir tablo, bir metrik, bir politika, bir runbook. Dosyanın yolu o kavramın kimliğidir. Kavramlar birbirine normal markdown bağlantılarıyla bağlanır ve klasör bir bilgi ağına dönüşür. index.md bir klasörde ne olduğunu, log.md ise değişikliklerin tarihçesini tutar.

Stajyerimizin siparis-iptali.md sayfası OKF’de şöyle görünür (temsili örnek):

---
type: Politika
title: Sipariş İptali
description: Siparişin hangi durumda iptal edilip edilemeyeceği.
tags: [sipariş, kargo, iade]
---

# Kural
Kargoya verilmiş sipariş iptal edilemez.
Müşteri teslimden sonra [iade sürecini](/politikalar/iade-sureci.md) başlatabilir.

Buradaki tek zorunlu alan type. Başlık, açıklama, kaynak bağlantısı ve etiketler önerilen alanlar; geri kalan her şey üreticiye bırakılmış.

Tasarımın arkasında üç ilke var:

1. Asgari kural: Spesifikasyon sadece birlikte çalışmayı tanımlar, içeriği değil.
2. Üretici ile tüketici bağımsız: Bir insanın elle yazdığı paketi bir agent okuyabilir. Bir LLM’in ürettiği paketi başka bir LLM sorgulayabilir.
3. Platform değil, format: Herhangi bir bulut, veritabanı, model ya da agent çatısına bağlı değil.

Google spesifikasyonla birlikte örnek araçlar da yayımladı: Bir BigQuery veri setini gezip her tablo için kavram sayfası yazan bir zenginleştirme agent’ı, paketi etkileşimli bir ağ olarak gösteren tek dosyalık bir HTML görüntüleyici ve üç örnek paket. Spesifikasyon GitHub’da Apache 2.0 lisansıyla duruyor.

Küçük bir not: Bu OKF, aynı kısaltmayı kullanan Open Knowledge Foundation ile karıştırılmamalı; ikisi tamamen farklı şeyler.

v0.2: Bu sayfayı kim yazdı, kim doğruladı?

İlk sürümde önemli bir boşluk vardı: Bir sayfanın bir agent tarafından mı yazıldığı, yoksa bir insan tarafından mı kontrol edildiği anlaşılmıyordu. Google’ın kendi ifadesiyle, bir insanın yazdığı wiki sayfasında örtük bir güvence vardır: Yanlışsa birinden hesap sorabilirsiniz. Bir agent bir gecede on bin kavram ürettiğinde bu güvence ortadan kalkar.

Temmuz 2026’nın sonunda yayımlanan OKF v0.2, bu yüzden beş isteğe bağlı güven sinyali ekledi:

Soru	OKF v0.2 alanı
Bu bilgi neyden üretildi?	sources
Kim üretti, kim doğruladı?	generated, verified
Hâlâ geçerli mi?	stale_after
Güncel sürüm mü?	status (taslak, kararlı, kullanımdan kalkmış)
Bu sayı onaylı yöntemle mi hesaplandı?	Attested Computation

Stajyerimizin sayfası v0.2 ile şöyle bir üst bilgi kazanır (temsili örnek):

generated: { by: ajan/stajyer-bot, at: 2026-11-03T09:00:00Z }
verified:
  - { by: human:ayse@sirket, at: 2026-11-03T16:00:00Z }
status: stable
stale_after: 2027-01-01
sources:
  - id: iade-politikasi
    resource: raw/iade-politikasi.docx

Artık bir agent bu sayfayı okumadan önce şunu bilir: Sayfayı bir bot yazmış, Ayşe Hanım doğrulamış ve 1 Ocak 2027’de yeniden kontrol edilmesi gerekiyor. Google bilerek bir “güvenilirlik puanı” eklemedi; format kanıtı kaydediyor, kararı okuyan sisteme bırakıyor.

Attested Computation ise en ilginç ekleme. Bir agent’a “yılbaşından bu yana ciro ne kadar?” diye sorduğunuzu düşünün. Agent kendi SQL sorgusunu yazar, yanlış tabloyu birleştirir ve kendinden emin bir sayı döndürür. Attested Computation’da onaylı sorgu paketin içinde durur. Agent yalnızca yıl gibi izin verilen parametreleri doldurabilir. Sorgu çalıştıktan sonra LLM içermeyen basit bir kod, çalışan SQL’i onaylı sürümle karşılaştırır. Tablo adı değişmişse ya da bir filtre eklenmişse doğrulama başarısız olur ve sayı gösterilmez.

OpenWiki Nedir? Defteri Sizin Yerinize Tutan Araç

Fikir ve format hazır. Geriye pratik bir soru kalıyor: Bu defteri kim yazacak ve her gün kim güncel tutacak?

LangChain 1 Temmuz 2026’da bu soruya OpenWiki ile cevap verdi. OpenWiki, kod tabanları için dokümantasyon üreten ve bakımını yapan açık kaynaklı bir agent ve komut satırı aracı. Ekip, DeepWiki, AutoWiki ve Karpathy’nin LLM Wiki fikrinden ilham aldığını açıkça söylüyor.

Çıkış noktası basit. Agent’lar çalıştıkları repoyu anladıklarında daha iyi kod yazar: kritik mantığın nerede durduğunu, dosyaların nasıl bağlandığını ve hangi kalıpların beklendiğini bilmeleri gerekir. İyi dokümantasyon bu bağlamı verir. Ama dokümantasyonu yazmak zaman alır, her kod değişikliğinde güncellemek daha da zordur. Sık PR alan büyük repolarda dokümanlar hızla eskir.

Nasıl çalışır?

Kurulum iki komut:

npm install -g openwiki
openwiki --init

--init komutu bir model sağlayıcısı ve API anahtarı ister, ardından repo için wiki’yi üretir. OpenAI, Anthropic, Gemini, Bedrock ve OpenRouter gibi sağlayıcılar destekleniyor.

Asıl akıllıca kısım wiki üretildikten sonra geliyor. OpenWiki, reponuzdaki AGENTS.md ya da CLAUDE.md dosyasına wiki’ye işaret eden kısa bir referans ekliyor. Wiki’nin tamamını bu dosyalara koymuyor, çünkü büyük bir repoda wiki yüzlerce dosyaya ulaşabilir ve bunu her agent çalışmasına yüklemek israf olur. Kodlama agent’ınız bu dosyayı zaten okuduğu için wiki’yi kendiliğinden buluyor.

Eklenen referans kabaca şuna benzer (temsili örnek):

## Repository wiki
Bu repo için güncel dokümantasyon openwiki/ klasöründe.
Kod tabanı hakkında bağlam gerektiğinde önce openwiki/index.md dosyasını oku.

Bu, Token Kaçağı yazısında önerdiğimiz yaklaşımın aynısı: Her proje kuralını her task’a yüklemek yerine, agent’a doğru anda doğru yere bakmasını söylemek.

Defteri güncel tutmak

Bir kez üretmek faydalı; asıl değer güncel tutmakta. OpenWiki zamanlanmış bir GitHub Action ile, örneğin günde bir kez, güncelleme modunda çalışabiliyor. Son çalışmadan bu yana gelen commit’lere bakıyor, git diff’lerinden neyin değiştiğini anlıyor ve wiki’yi buna göre güncelliyor. İçerik değiştiğinde bir PR açıyor; yani wiki değişikliklerini de kod gibi inceleyebiliyorsunuz.

Stajyer örneğimize dönelim. Pazartesi günü bir geliştirici CancelOrderHandler sınıfına “kısmi kargolanmış siparişler” için yeni bir kural ekliyor. Gece çalışan action bu diff’i görüyor, openwiki/ altındaki ilgili sayfayı güncelliyor ve bir PR açıyor. Salı sabahı agent aynı soruyu sorduğunda yeni kuralı zaten wiki’de buluyor; repoyu baştan taramıyor.

Diğer özellikler

• İki mod: Kod modu repoda openwiki/ klasörü oluşturur. Kişisel mod ise git repoları, Gmail, Notion, web araması, Hacker News ve X gibi kaynaklardan bilgisayarınızda kişisel bir wiki kurar.
• Kaynağa bağlı iddialar (Grounded Claims): Önemli bilgileri sürümlü kaynak kanıtına bağlar ve kanıt değiştiğinde sayfayı yeniler.
• Arama: Wiki sayfaları MCP üzerinden sorgulanabilir ve ilişkili repoların wiki’leri gruplanabilir.
• OKF çıktısı: OpenWiki, wiki’yi OKF v0.2 formatında, üst bilgileri, index dosyaları ve bağlantılı kavramlarıyla üretebiliyor.

Son madde önemli: OpenWiki tek başına bir ürün değil; LLM Wiki fikrini uygulayan ve çıktısını OKF formatında veren bir araç. Üç kavram burada birleşiyor.

Üçü Bir Arada: Fikir, Format ve Araç

Bu üç kavram birbirinin rakibi değil; aynı zincirin üç halkası. Karışıklığın çoğu, üçünün aynı şeymiş gibi anılmasından geliyor. Aradaki farkı tek tabloda görelim:

	LLM Wiki	OKF	OpenWiki
Nedir?	Bir fikir, bir çalışma deseni	Bir dosya formatı (spesifikasyon)	Bir araç (agent ve komut satırı)
Kimden?	Andrej Karpathy	Google Cloud	LangChain
Ne zaman?	4 Nisan 2026	12 Haziran 2026 (v0.2: Temmuz 2026)	1 Temmuz 2026
Cevapladığı soru	Bilgi neden her seferinde sıfırdan okunuyor?	Farklı ekiplerin wiki’leri nasıl aynı dili konuşur?	Bu wiki’yi kim yazacak ve güncel tutacak?
Stajyer benzetmesinde	Deftere yazma alışkanlığı	Defterin herkesin okuyabildiği ortak şablonu	Defteri her gece güncelleyen asistan

Şimdi gelin hepsini tek bir senaryoda birleştirelim. Bir e-ticaret şirketinin destek ve yazılım ekipleri aynı bilgiyi kullanıyor:

1. Kaynaklar bir klasörde duruyor: kargo sözleşmesi, iade politikası, toplantı notları ve sipariş servisinin kaynak kodu.
2. OpenWiki her gece kaynak kodu ve yeni notları okuyor. Karpathy’nin tarif ettiği ingest adımını uyguluyor: ilgili sayfaları güncelliyor, çelişkileri işaretliyor, log.md’ye kayıt düşüyor.
3. Çıktı bir OKF paketi olarak yazılıyor. Her sayfanın type, sources, generated ve stale_after alanları var. İnsan kontrolünden geçen sayfalara verified ekleniyor.
4. Paket git’te duruyor. Wiki değişiklikleri bir PR olarak geliyor ve ekipten biri onaylıyor.
5. Farklı agent’lar aynı paketi okuyor. Kodlama agent’ı AGENTS.md’deki referans üzerinden wiki’ye ulaşıyor. Destek ekibinin agent’ı, başka bir model ve başka bir araçla aynı paketi sorguluyor. Format ortak olduğu için kimsenin çeviri yapmasına gerek kalmıyor.

Kaynaklar (sözleşme, politika, notlar, kaynak kod)
      ↓
OpenWiki: her gece diff'leri okur, wiki'yi günceller
      ↓
OKF paketi: index.md, log.md, kavram sayfaları  ← ekipten biri PR'ı onaylar
      ↓
Kodlama agent'ı (AGENTS.md ile) ve destek agent'ı (başka model) aynı paketi okur

Stajyer artık yalnız değil: Defteri her gece güncelleyen bir asistanı ve herkesin okuyabildiği ortak bir şablonu var.

Dürüst Olalım: Defterin de Sınırları Var

Bir fikri anlatırken sadece güçlü yanlarını yazmak kolay. LLM Wiki, OKF ve OpenWiki’nin de net sınırları var ve bunlar topluluk içinde açıkça tartışılıyor.

Hata birikmesi

En ciddi eleştiri bu. LLM bir kaynağı özetlerken yüzde 95’ini doğru, yüzde 5’ini biraz yanlış yazdığını varsayalım. Sonra bu sayfayı başka sayfalarla birleştirip bir karşılaştırma yazıyor. O yüzde 5’lik hata artık yeni sayfanın içinde. Her katman orijinalden biraz daha uzaklaşıyor ve kimse bunu kontrol etmiyorsa hata büyüyor.

Burada RAG ile önemli bir fark var. RAG her soruda orijinal kaynağı yeniden okur. LLM Wiki ise LLM’in kaynağa dair yorumunu wiki’nin içine kalıcı olarak yazar. Yani stajyer defterine yanlış bir şey yazdıysa, ertesi gün arşive bakmadan o yanlışı tekrarlar.

Çözümler de bu yüzden aynı yöne bakıyor: Ham kaynakları silmemek, her bilginin kaynağını kaydetmek (OKF’deki sources), önemli sayfaları bir insana onaylatmak (verified) ve iddiaları kaynak kanıtına bağlamak (OpenWiki’deki Grounded Claims).

Bilgi kaybı

Wiki bir özettir ve her özet bir şeyleri dışarıda bırakır. Bu konuyu ölçen bir araştırmada, kontrolsüz yapılan derlemenin bilgiyi aşırı sıkıştırdığı ve ciddi bilgi kaybına yol açtığı görülmüş. Asıl ilginç tespit şu: RAG’de hata genelde doğru parçanın bulunamamasından gelir. Wiki’de ise doğru bilgi derlenen sayfaya hiç girmemiş olduğu için gelir.

Bayatlama

Wiki, en son güncellendiği an kadar doğrudur. Günde bir kez güncellenen bir wiki, en fazla bir günlük bayat bilgi taşır. OKF v0.2’deki stale_after alanı ve OpenWiki’nin zamanlanmış güncellemeleri bu riski azaltır ama sıfırlamaz. Sık değişen bir bilgi için bir sonraki güncellemeyi beklemek kabul edilebilir olmayabilir.

Ölçek

Karpathy’nin kendi ifadesi yaklaşık 100 kaynak ve birkaç yüz sayfa. Binlerce belgenin olduğu ve sürekli değiştiği bir ortamda tek bir index.md yetmez; arama yine gerekir. OKF de bu yüzden aramanın yerine geçmez, arama sisteminin indeksleyebileceği bir kaynak olur.

Güvenlik

Bir OKF paketi, agent’ın okuyup talimat gibi uygulayabileceği bir metindir. Bu da onu dolaylı prompt injection için bir yol haline getirir. Paketteki değişiklikler, agent’a verilen diğer talimatlar gibi incelenmeli; özellikle dışarıdan katkı ya da başka agent’lar yazabiliyorsa. Agent’ın ürettiği şeylere nasıl güvenebileceğimizi Çalışan Kod Yetmez yazısında konuşmuştuk; aynı disiplin burada wiki için de geçerli.

Kişisel veri ve yönetişim

verified alanındaki human:ayse@sirket gibi kimlikler kişisel veridir. Avrupa’da bu konu GDPR kapsamında değerlendiriliyor; Türkiye’de de KVKK açısından benzer bir değerlendirme yapmak gerekir. Git geçmişi ise silme işini kolaylaştırmaz, zorlaştırır. Ad mı, takma kimlik mi, yoksa sadece rol mü yazılacağına baştan karar vermek gerekiyor.

Son olarak OKF hâlâ bir Google deposunda duruyor ve arkasında bir standart kuruluşu yok. Bir analistin ifadesiyle: Lisansı açık, ama yönetişimi henüz açık değil. Bir de keşif sorunu var: OKF bilgiyi paketler ama bir agent’ın o paketi nasıl bulacağını söylemez. Şimdilik bunu siz çözüyorsunuz: agent’ı talimat dosyasıyla, bir skill’le ya da bir MCP sunucusuyla pakete yönlendirerek.

LLM Wiki, OKF ve OpenWiki Hakkında Sık Sorulan Sorular

LLM Wiki nedir?

LLM Wiki, Andrej Karpathy’nin Nisan 2026’da önerdiği bir çalışma desenidir. LLM, kaynakları her soruda baştan okumak yerine, birbirine bağlı markdown sayfalarından oluşan kalıcı bir wiki’yi kendisi yazar ve güncel tutar.

LLM Wiki RAG’in yerini alır mı?

Her durumda değil. Seçilmiş ve görece sabit bir kaynak setinde LLM Wiki daha verimli olabilir. Binlerce belgenin olduğu ve sürekli değiştiği ortamlarda arama yine gerekir. Pratikte ikisi çoğu zaman birlikte kullanılır.

OKF nedir?

Open Knowledge Format, Google Cloud’un Haziran 2026’da yayımladığı açık ve satıcıdan bağımsız bir spesifikasyondur. Bilgiyi YAML üst bilgili markdown dosyalarından oluşan bir klasör olarak saklar. Tek zorunlu alan type’tır.

OKF kullanmak için Google Cloud gerekir mi?

Hayır. Bir OKF paketi sadece bir klasör dolusu markdown dosyasıdır. Dosya okuyabilen her araç ve agent onu kullanabilir.

OpenWiki nedir?

OpenWiki, LangChain’in Temmuz 2026’da yayımladığı açık kaynaklı bir araçtır. Kod tabanınız için wiki üretir, bunu AGENTS.md ve CLAUDE.md üzerinden kodlama agent’ınıza bağlar ve kod değiştikçe günceller. Çıktısını OKF formatında da verebilir.

Bunları kullanmak için Obsidian gerekli mi?

Hayır. Hepsi düz markdown dosyalarıyla çalışır. Obsidian sadece sayfaları rahat gezmek ve aralarındaki bağlantıları görmek için önerilen bir seçenek.

Sonuç

Bu yazıda LLM Wiki, OKF ve OpenWiki’yi inceledik. RAG’in her soruda sıfırdan başladığını ve bilgiyi biriktirmediğini gördük. LLM Wiki’nin bu soruna LLM’e kalıcı bir wiki yazdırarak cevap verdiğini, OKF’nin bu wiki’leri farklı ekiplerin ve agent’ların ortak okuyabileceği bir formata bağladığını, OpenWiki’nin ise bu wiki’yi kod tabanı için sizin yerinize yazıp güncel tuttuğunu konuştuk. Üçünün de hata birikmesi, bayatlama, güvenlik ve yönetişim gibi gerçek sınırları olduğunu da gördük.

Stajyer benzetmesiyle özetlersek: LLM Wiki stajyere deftere yazmayı öğretiyor, OKF o defterin herkesin okuyabileceği bir şablonda tutulmasını sağlıyor, OpenWiki de defteri her gece güncelleyen bir asistan gibi çalışıyor.

Agent’ın hangi bilgiyi context’inde taşıması gerektiğini Agentic AI’da Context Problemi yazısında ele almıştık. Bu yazıdaki fikirler o sorunun bir sonraki adımı: Agent’ın her şeyi hatırlaması gerekmiyor; neyi nereye yazdığını ve neyi nereden okuyacağını bilmesi yeterli.

Gelecekte iyi bir agent sistemi, en çok bilgiye erişebilen sistem olmayacak. Öğrendiğini bir yere yazan, yazdığının kaynağını gösteren ve ne zaman yeniden kontrol edilmesi gerektiğini bilen sistem olacak.

Bir sonraki yazılarda görüşmek üzere.

İyi çalışmalar.

• Yapay Zeka