Geçen ay ofiste, 2024’ün sonlarına doğru bir toplantı notunu ararken yarım saatimi gömdüm. Slack başka yerde, Notion başka yerde, bir de Google Docs var… Hani herkesin başına gelir ya. İşte tam o anda şu fikir kafama çarptı: LLM’ler sadece soru cevaplayan makineler olmak zorunda değil; bazen iyi bir hafıza da olabilirler.
Reza Rezvani’nın Karpathy’nın LLM Wiki fikrinden yola çıkarak kurduğu yapı da tam bunu yapıyor. Ama açık konuşayım, olay “birkaç dokümanı indeksledik, bitti” seviyesinde değil. Daha çok yaşayan bir bilgi sistemi gibi çalışıyor: kaynakları topluyor, bağlantıları örüyor, çelişkileri işaret ediyor ve en önemlisi… unutmayı azaltıyor.
Ben bu tarz sistemlere ilk kez 2023 yazında, İstanbul’da küçük bir SaaS ekibinin iç bilgi araması için bakmıştım. O zamanlar herkes “RAG yapalım” diyordu ama pratikte sorun şuydu: soruyu cevaplamak kolaydı, bağlamı yaşatmak zordu. LLM Wiki yaklaşımı biraz daha sert. Daha gerçekçi bir yere basıyor; bilgiye her seferinde sıfırdan gitmek yerine önü kalıcı hâle getiriyor.
Neden “wiki” fikri şimdi yeniden önemli oldu?
Bi saniye — Bir wiki deyince çoğu kişinin aklına eski usul şirket içi sayfalar geliyor. Düz metinler, sıkıcı başlıklar ve üç ay sonra kimsenin açmadığı sayfalar (şaşırtıcı ama gerçek) — bence çok yerinde bir karar —. Buradaki fark şu: LLM Wiki statik bir arşiv değil. Sürekli beslenen, yeni kaynaklarla büyüyen ve sorgulandıkça anlam kazanan bir bellek katmanı gibi duruyor.
Andrej Karpathy’nın paylaştığı fikir sonrasında binlerce yıldız ve fork almasının sebebi de bu sanırım. İnsanlar artık sadece “cevap veren” modellerle yetinmek istemiyor; modelin geçmişi hatırlamasını istiyor. Çünkü iş hayatında asıl problem cevap eksikliği değil çoğu zaman — bağlam eksikliği.
Bir startup’ta bunu çok net görüyorsunuz. Kurucu ekip on kişi bile olsa kararların izi Slack içinde kayboluyor (en azından benim deneyimim böyle). Kurumsal tarafta işe durum daha da karışık; toplantılar, post-mortem raporları, mimarı notlar derken bilgi dağılıyor da dağılıyor. Aslında — dür bir saniye, önce şunu söyleyeyim — bu tıp sistemlerin değeri parlak demo videosunda değil, o dağılan parçaları tekrar birleştirmesinde ortaya çıkıyor.
LLM Wiki’nın asıl gücü cevap üretmekte değil; bilgiyi kalıcı hâle getirip tekrar kullanılabilir kılmakta yatıyor.
Dört komutla çalışan iskelet nasıl kuruluyor?
Rezvani’nın yaptığı şey aslında sade ama akıllıca: Claude Code içine taşınabilir bir skill olarak paketlenmiş dört komut veriyor (buna dikkat edin). Bu bana yıllar önce kendi not otomasyonumu yazarken yaşadığım o “az ama öz” dersini hatırlattı; fazla araç yerine doğru akış kurunca işler hızlanıyor.
Bunu biraz açayım.
| Komut | Ne işe yarıyor? | Pratik etkisi |
|---|---|---|
| /wiki-init | İlk iskeleti kuruyor | Klasörler, şablonlar ve temel yapı hazır geliyor |
| /wiki-ingest | Kaynakları işliyor | Makaleler, notlar ve dokümanlar içeri alınıyor |
| /wiki-query | Sentez yapıyor | Soruya tek kaynaktan değil pek çok hafızadan cevap veriyor |
| /wiki-lint | Sağlık kontrolü yapıyor | Tutarsızlıkları ve eksikleri yakalamaya çalışıyor |
Garip gelecek ama, Bana göre en kritik parça /wiki-lint tarafı. Çünkü hafıza sistemi kurmak kolaylaşınca insanlar gevşiyor; veri giriliyor ama kalite kontrolü atlanıyor. Benzerini geçen yıl Nişan 2025’te Ankara’da küçük bir içerik ekibinde gördüm: yüzlerce not vardı. Etiketleme düzensizdi. Sonuç? Sistem doluydu ama arama hâlâ can sıkıyordu.
Neyse uzatmayalım: dört komutluk yaklaşımın güzelliği şu ki karmaşıklığı saklamaya çalışmıyor. Tam tersine önü görünür kılıyor. İyi haber bu. Kötü haber de şu — eğer kaynak disiplininiz kötüyse bu yapı sızı kurtarmaz; sadece kaosu daha düzenli gösterir.
Bellek nasıl çalışır? Kısaca mimarı mantık
Lafı gevelemeden söyleyeyim: Bu yaklaşımı ben küçük ölçekli kişisel wiki ile devasa kurum hafızası arasında duran hibrit bir katman gibi görüyorum. Bir yanda Markdown dosyaları ve klasör düzeni var, diğer yanda LLM’in özetleme ve çapraz referans çıkarma becerisi… İkisinin evliliği fena durmuyor doğrusu.
# Basit akış örneği
1) Kaynak topla
2) Metni parçala
3) Etiketleri çıkar
4) Bağlantıları öner
5) Çelişkileri işaretle
6) Soru gelince ilgili düğümleri sentezle
7) Yanitın yanina iz bırak
Şahsen, Klasik RAG sistemlerinde model genelde “bulduğu parçayı” döker geçer (kendi tecrübem). Burada işe amaç yalnızca retrieval değil; uzun vadeli bilgi örgüsü kurmak. Mesela aynı konuyla ilgili üç farklı toplantıda farklı karar alınmışsa sistem bunu fark edip sana gösterebiliyor ya da en azından dikkat çekebiliyor. zekâ ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Açık konuşayım, kağıt üstünde süper duran yerlerden biri de burasıdır ama pratikte biraz pişmesi gerekiyor tabii ki. Mesela de doküman türleri çok çeşitliyse — — kendi adıma konuşayım — PDF var, e-posta var, Slack export var — normalizasyon işi epey yorucu oluyor. Yani model burada sihirbaz değil; düzgün mutfak bekliyor.
Kullanım senaryoları nerede parlıyor?
En güçlü iki kullanım alanı özellikle dikkat çekiyor: CTO Decision Wiki ve Content Research Wiki (ki bu çoğu kişinin gözünden kaçıyor). İlki teknik kararların tarihçesini tutuyor; ikincisi işe araştırma sürecindeki her kaynağı ilişkilendiriyor.
CTO tarafında benzer şeyi Şubat 2026’da İzmir’de orta ölçekli bir ürün ekibiyle konuşurken duydum (işim vermeyeyim). Mesele şuydu: neden belli teknolojiler seçildiğini kimse tam hatırlamıyordu çünkü karar Notion’da duruyor ama gerekçesi Slack zincirinde kaybolmuştu. Böyle anlarda wiki gerçekten hayat kurtarıyor.
Doğrusu, Editör masasında bu haberi görünce hemen test etmek istedim desem yeridir… Çünkü içerik araştırmasında da aynı dert var mesela: hangi veri nereden geldi? Bu iddia hangi kaynakla destekleniyor? Çelişki varsa hangisi daha güncel? Bütün bunları elle takıp etmek insan beynini yoruyor resmen.
Kurum için mi uygun, bireysel kullanım için mi?
Bence ikisinin cevabı farklı. İkisi de değerli olabilir! Küçük startup’ta amaç hız kazanmak olurken büyük kurumda amaç yönetişimdir (ve biraz da kafa karışıklığını azaltmak). Aynı teknoloji iki yerde bambaşka şekilde kullanılıyor yani. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
- Küçük ekipte ana fayda hızlı karar geri çağırma ölür. — ciddi fark yaratıyor
- Kurumsal yapılarda denetlenebilirlik öne çıkar.
- İçerik üreticilerde kaynak izi önemli hâle gelir.
- Araştırma ekiplerinde çelişki yakalama ciddi avantaj sağlar. — bunu es geçmeyin
- Mühendislik takımlarında post-mortem arşivi altın değerindedir.
Küçük startup için ne sağlar?
Bunu yaşayan biri olarak söyleyeyim, Ekip küçülünce herkes her şeyi biliyor sanılır ama iki ay sonra işler karışır… Toplantılar artar, kararların izi silinir ve yeni gelen biri geçmişi anlamakta zorlanır. LLM Wiki burada “kurumsallaşmadan önceki bellek” rolünü oynayabilir.
Büyük kurumda neden zorlaşır?
Büyük ölçekte mesele teknik olmaktan çıkıp operasyonel hâle geliyor birçok zaman. Kim neyi yükleyebilir? Hangi belge gizlidir? Hangi not günceldir? Bunlar çözülmezse güzel mimarı bile tökezler maalesef. Ayrıca güvenlik tarafı da cabası; hassas bilgiler yanlış erişime açılırsa iş sarpa sarar! Daha fazla bilgi için 3D Baskı Savaşı: Jet Motorları Artık Başka Bir Lig yazımıza bakabilirsiniz.
Zayıf noktalar neler? Her şey güllük gülistanlık değil yani…
Eh, Pek sevdiğim özellikleri anlattım diye kusursuz sanmayın sakın! En büyük risklerden biri yanlış bilginin kalıcılaşmasıdır çünkü model unutmaz gibi görünür ama yanlış şeyi de gayet düzgün saklayabilir.. İşte orası sıkıntılı taraf. Özet güzel çıkarsa herkes alkışlar; kötü veri girilirse sistem aynı özgüvenle saçmalar. C23’te auto Geldi: C’de Tür Çıkarma Neden Önemli? yazımızda bu konuya da değinmiştik.
Evet, doğru duydunuz.
Aslında, Bir diğer mesele maliyet ve bakım yükü olabilir. Kaynak sayısı büyüdükçe ingest işlemi ağırlaşır, ilişkiler daha kırılgan hâle gelir, lint raporları kabarır… Bunu kendi mini laboratuvarımda Mart 2025’te denediğimde fark ettim; onca belgeyi içeri almak kolaydı fakat temizlik kısmı beklediğimden uzun sürdü. Açıkçası biraz hayal kırıklığı yaşadım çünkü ilk günkü heyecan ikinci haftada yerini rutin işe bıraktı.
Neyi iyi yapıyor, neyi henüz yapamıyor?
| Güçlü taraf | Zayıf taraf |
|---|---|
| Bellek hissi veriyor | Yanlış bilgi kalıcılaşabiliyor |
| Soruya bağlamlı cevap üretiyor | Düzgün veri modeli gerektiriyor |
| Kaynaktan çapraz referans çıkarabiliyor | Bakimi ihmal edilirse hızla şişebiliyor |
| Ekip bilgisini tek yerde topluyor | Gizlilik / erişim politikası şart |
Bir dakika, şunu da ekleyeyim: böyle sistemler “her şeyi çözen ürün ” diye pazarlanırsa kandırılmış hissedersiniz. Gerçek hayat daha serttir. Evet, iyi çalıştığında bayağı dikkat çekici ölür; fakat kirli veri, zayıf isimlendirme ve kötü sahiplenme varsa oyun bitmiştir.
Ben olsam nerede denerdim?
Şahsen ilk denemeyi bireysel araştırma veya editoryal çalışma alanında yapardım. Mesela yayınladığınız makalelerin tüm kaynaklarını, düzeltme notlarını — kendi adıma konuşayım — ve revizyon sebeplerini tek havuzda tutabilirsiniz. Sonra aylar sonra geri dönüp “bu cümleyi neden böyle yazmıştık? ” sorusuna cevap bulursunuz… Bu küçük gibi görünür ama inanılmaz rahatlatıcıdır.
Kısa bir not düşeyim buraya.
İkinci adım olarak mühendislik ekipleri gelir bence (yanlış duymadınız). Post — mortem kayıtları, mimarı karar özetleri, incident notları… Hepsi birleşince yaşayan bir operasyon belleği oluşur. Ha bu arada güvenlik team’i için de güzel malzeme çıkar; AI Ajanları: Kurumların Sessiz Güvenlik Kör Noktası yazısındaki uyarılar burada fazlasıyla anlamlı hâle geliyor. AI Ajanları: Kurumların Sessiz Güvenlik Kör Noktası
Bir şey dikkatimi çekti: Benzer şekilde içerik odaklı çalışan ekipler için de ayrı kıymet taşıyor; bu yüzden Bellekli Yapay Zekâ : Aynı Soruna İki Kez Düşmeyen Ajan başlıklı yazımızdaki yaklaşımı bunun doğal kuzeni gibi düşünebilirsiniz. Orada ajan tekrar hata yapmıyordu; burada işe kurum tekrar aynı bilgiyi aramıyormuş gibi davranabiliyor.. İşte, Bellekli Yapay Zekâ : Aynı Soruna İki Kez Düşmeyen Ajan (ilk duyduğumda inanamadım)
Kendi pratiğimde çıkardığım dersler
2019’dan beri bilgi yönetimi araçlarını kurcalayan biri olarak söyleyebilirim ki en başarılı sistemler en gösterişli olanlar değil; en az sürpriz çıkaranlardır (evet, doğru duydunuz). Claude Code ile paketlenen böyle skill’lerde de durum aynı: kullanıcıya sihir vaadi yerine düzen vaat ederseniz güven kazanırsınız. Bu kulağa sıkıcı gelebilir ama uzun vadede işe yarayan şey genelde budur.
Açıkçası, Gel gelelim, otomasyonun dozu kaçarsa insanlar sistemi sahiplenmeyi bırakabiliyor. Her şeyi AI’a bırakırsanız düzen yerine sis oluşur. O yüzden benim tavsiyem şu: ingesti otomatikleştir, lint’i sert tut, query sonucunu işe büyük ihtimalle insan gözünden geçir! En çok da yüksek riskli kararlarda buna mecbursunuz zaten (kendi tecrübem).
Sıkça Sorulan Sorular
LLM Wiki tam olarak nedir?
LLM Wiki, yapay zekânın soruları yanitlarken sürekli yeni bilgiler toplayıp onları kalıcı biçimde organize ettiği bir bilgi katmanı gibidir. Kısaca söylemek gerekirse, model sadece konuşmaz; öğrendiklerini saklayıp yeniden kullanmaya çalışır.
Bu yaklaşım RAG’den farklı mı?
Evet, biraz farklı. RAG genelde ilgili parçaları bulup anlık yanit üretmeye odaklanır; LLM Wiki işe bilgiyi zaman içinde düzenleyip ilişkilendirmeye çalışır. Yani biri hızlı arama motoru gibi, diğeri yaşayan ansiklopedi gibi düşünülebilir.
Kaynaklar ve İleri Okuma
Azure AI Studio / OpenAI konseptleri
Azure OpenAI nasıl yapılır (how-to) rehberleri
OpenAI Cookbook (RAG ve uygulama örnekleri)
Andrej Karpathy’nın LLM ilgili kaynakları (topluluk ve fikirler)
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.
