Yapay Zekâ Tabanlı İkinci Beyin

Yapay zekâ asistanlarının iş akışlarımıza dahil olduğu bu dönemde, sistemlerin gerçek katma değeri modellerin kendisinden ziyade onlara beslediğimiz kişisel ve kurumsal bağlamda (context) gizlidir. Kişisel notlarımızı statik yazılar olmaktan çıkarıp otonom ajanların karar alırken kullanabileceği dinamik bir hafıza katmanına dönüştürmek, yapay zekâ entegrasyonlarının en kritik basamağıdır. Bu yazıda, Obsidian altyapısını kullanarak yapay zekâ modelleri için kararlı bir ikinci beyin (second brain) sistemini nasıl kurguladığımı ve bu yapının teknik bileşenlerini paylaşıyorum.

Kısa cevap: Ajanlı bir ikinci beyin, notlarınızı arama kutusuna değil, bir yapay zekâ ajanının okuyup güncelleyebildiği yapılandırılmış bir markdown deposuna dönüştürür. Üç katman vardır: değiştirilmeyen ham kaynaklar, ajanın yazdığı wiki notları ve ajanın nasıl davranacağını tanımlayan şema dosyası. Ajan yeni kaynak geldiğinde onu işler, ilgili notları günceller ve çelişkileri işaretler. Kazanç, bilgiyi saklamak değil biriktirmektir: her soru sıfırdan cevaplanmaz, cevaplar kalıcı sayfalara dönüşür.

Vektörel Arama ve İkinci Beyin Kavramı

Geleneksel not tutma sistemleri klasör yapılarına ve etiketlere dayanır. İnsan beyni bu yapıyı yönetmekte zorlanmasa da, dil modelleri için binlerce dağınık not dosyasını tek tek okumak bağlam penceresini (context window) şişirir ve maliyeti katlar. İlk akla gelen çözüm, notları vektörel veri tabanlarında anlamsal olarak indekslemek ve ajanların yalnız ilgili parçaları çekmesini sağlamaktır.

Bu doğru bir başlangıçtır ama tek başına yetmez. Vektörel arama her soruda ilgili parçaları yeniden bulur; bulduğu şeyi kalıcı hâle getirmez. Bir hafta sonra aynı soruyu sorduğunuzda sistem aynı işi baştan yapar. İkinci beyin fikrinin özü ise tam tersidir: bir kez anlaşılan şey yazıya geçirilir ve bir daha çözülmez. Bu yüzden olgun bir kurulumda arama katmanı ile bilgi katmanı birbirinin yerine geçmez, birbirini besler.

Agentic Second Brain: Ajanlı İkinci Beyin Neyi Değiştirir?

Klasik ikinci beyin yaklaşımında notları insan yazar, insan düzenler ve zamanla insan ihmal eder. Not sistemlerinin çürümesinin sebebi disiplinsizlik değil, bakımın sıkıcı olmasıdır: bağlantı kurmak, tekrarı ayıklamak, eskiyen bilgiyi güncellemek. Agentic second brain kavramı bu bakım işini bir ajana devretmeyi önerir.

Ayrım şurada netleşir: klasik kurulumda yapay zekâ notlarınızı okur; ajanlı kurulumda notlarınızı yazar ve bakımını yapar. İnsanın rolü kaybolmaz, değişir — insan yön verir ve neyin dahil edileceğine karar verir, ajan mekanik bakımı üstlenir. Bu iş bölümü, kişisel bilgi sistemlerinde uzun süredir çözülemeyen sorunu hedefler: sistem büyüdükçe bakım maliyetinin faydayı geçmesi.

Bu yaklaşım daha geniş bir tartışmanın parçasıdır. Ink & Switch'in yumuşak yazılım (malleable software) makalesi, kullanıcıların kendi araçlarını şekillendirebilmesini savunur; ajanlı ikinci beyin de tam olarak bunun kişisel bilgi yönetimindeki karşılığıdır. Hazır bir not uygulamasının dayattığı yapıya uymak yerine, kendi kurallarınızı yazdığınız ve ajanın bu kurallara göre çalıştığı bir depo kurarsınız.

Karpathy'nin LLM Wiki Reçetesi ve Üç Katmanlı Mimari

Andrej Karpathy'nin 2026 Nisan'ında yayımladığı LLM Wiki gist'i, temiz ve otonom bir ikinci beyin için sade bir yapı önerir. Sistem üç katmana dayanır:

• Ham kaynaklar: Makaleler, akademik metinler, toplantı dökümleri ve görseller. Bu katman değiştirilmez; ajan buraya yazmaz, yalnız okur.
• Wiki: Ajanın bakımını üstlendiği markdown dosyaları — varlık sayfaları, kavram sayfaları, özetler ve bir dizin. Her işleme (ingest) ile zenginleşen katman budur.
• Şema: CLAUDE.md veya AGENTS.md gibi bir yapılandırma dosyası; iş akışlarını, adlandırma kurallarını ve sayfa yapısını belgeler. İnsan ve ajan bu dosyayı birlikte geliştirir.

Gist iki özel dosyayı ayrıca vurgular: index.md, tüm sayfaların bağlantı, özet ve kategori bilgisiyle düzenlenmiş kataloğudur; log.md ise işleme, sorgu ve bakım olaylarının kronolojik, yalnız eklemeli kaydıdır ve klasik komut satırı araçlarıyla ayrıştırılabilecek biçimde tutulur. Sayfalar arası bağlantı [[wikilink]] biçimiyle kurulur; hedef, sayfaların insan tarafından okunabilir, ajan tarafından düzenlenebilir ve araçlar arasında taşınabilir kalmasıdır.

RAG mi, Wiki mi? İki Yaklaşımın Ayrıldığı Nokta

Bu mimarinin en önemli iddiası, klasik RAG kurulumlarıyla arasındaki farktır. Karpathy'nin gist'i sorunu net koyar: RAG'da model her soruda bilgiyi sıfırdan yeniden keşfeder, birikim olmaz. LLM wiki deseninde ise model kaynak malzemeyi birbirine bağlı markdown dosyalarına derler; bilgi bir kez derlenir ve güncel tutulur, her sorguda ham belgelerden yeniden türetilmez.

Pratik sonuç şudur: aynı soruyu ikinci kez sorduğunuzda RAG aynı maliyeti tekrar öder, wiki ödemez. Buna karşılık wiki bakım gerektirir; ham kaynak değiştiğinde türetilmiş sayfalar eskir. Yani seçim «hangisi daha iyi» değil, «bilgim ne sıklıkla değişiyor ve aynı soruları ne sıklıkla soruyorum» sorusudur. Kurumsal tarafta RAG'ın nasıl kurulduğunu RAG mimarisi ve kurumsal bilgi bankaları yazısında ayrıntılı anlattım.

Uygulamada ikisi birlikte de kullanılabilir: wiki katmanı sık sorulan ve olgunlaşmış bilgiyi taşır, vektörel arama ise henüz işlenmemiş ham yığında keşif yapmak için kalır. Bu ayrım, hangi bilginin «derlenmeye değer» olduğuna karar vermeyi gerektirir ve bu karar otomatikleştirilemez; insanın kalması gereken yer burasıdır.

Not Sistemi Otomasyonu: Ingest, Query ve Lint Döngüsü

Not sistemi otomasyonu dendiğinde çoğu kişi «notları otomatik özetlet» anlar. Oysa işleyen bir kurulumda üç ayrı işlem vardır ve her biri farklı bir sorunu çözer:

• Ingest (işleme): Yeni bir kaynak geldiğinde ajan kilit bilgileri çıkarır ve mevcut wiki sayfalarına işler; çapraz referansları günceller, çelişkileri işaretler. Tek bir kaynak genellikle birden çok sayfaya dokunur.
• Query (sorgu): Bir soru sorulduğunda ajan ilgili wiki sayfalarını tarar ve yanıtı sentezler. Değerli bulunan araştırmalar yeni birer wiki sayfası olarak dosyalanır — yani sorgu, sistemi tüketmez, besler.
• Lint (bakım denetimi): Düzenli aralıklarla çelişkiler, öksüz kalmış sayfalar, eskimiş iddialar ve eksik çapraz referanslar taranır. Wiki'lerin çürümesinin sebebi bu işin hiç yapılmamasıdır.

Bu üçlünün asıl değeri sırasındadır. Yalnız ingest kurulan bir sistem hızla şişer ve tekrarla dolar; lint olmadan büyüyen bir not deposu, aramanın işe yaramadığı bir çöplüğe dönüşür. Otomasyon kurarken en sık atlanan adım da budur: üretmek kolaydır, budamak zordur.

Otomasyonun bir sınırı olduğunu baştan kabul etmek de bu döngünün parçasıdır. Ajan bir kaynağı işleyebilir, çelişkiyi görebilir, eskimiş ifadeyi işaretleyebilir; ama iki kaynaktan hangisinin daha güvenilir olduğuna karar vermek yargı gerektirir. Bu kararı ajana bırakan kurulumlarda depo hızla kendinden emin ama yanlış cümlelerle dolar ve yanlışın nereden geldiği artık okunamaz. Doğru iş bölümü şudur: ajan çelişkiyi bulur ve görünür kılar, insan çözer. Bu yüzden lint çıktısı bir rapor değil, bir yapılacaklar listesi olarak okunmalıdır.

İkinci sınır tetikleme biçimindedir. Her dosya değişikliğinde koşan bir otomasyon, hem gereksiz token harcar hem de yarım bırakılmış notları işleyip depoya taşır. Pratikte işleyen düzen, işlemeyi kaynak eklendiğinde elle tetiklemek ve bakım denetimini haftalık bir takvime bağlamaktır. Böylece hangi çıktının hangi girdiden doğduğu izlenebilir kalır; sürekli koşan bir arka plan süreci bu izlenebilirliği ilk kaybettiren şeydir. Otomasyonun amacı sistemi görünmez kılmak değil, bakım yükünü azaltırken denetimi elde tutmaktır.

Çalışılmış Örnek: Bir Raporun Vault İçindeki Yolculuğu

Girdi: Bir sektör raporunun PDF'i raw/ klasörüne düşürülür.

1. Ingest: Ajan PDF'i okur, içindeki iddiaları ayıklar ve her iddiayı kaynağa bağlar. Rapor bir pazar büyüklüğü rakamı veriyorsa, bu rakam ilgili kavram sayfasına kaynak ve tarih bilgisiyle birlikte yazılır. Ajan aynı sayfada daha eski ve farklı bir rakam bulursa silmez, çelişki olarak işaretler.

2. Bağlantı: Rapor bir şirketten söz ediyorsa o şirketin varlık sayfası güncellenir ve kavram sayfasıyla [[wikilink]] üzerinden bağ kurulur. index.md yeni sayfayı kataloğa alır, log.md işlemin kaydını düşer.

3. Query: Haftalar sonra «bu pazarda kim ne iddia ediyor» diye sorduğunuzda ajan PDF'i yeniden okumaz; işlenmiş sayfaları okur, çelişki işaretlerini de göstererek yanıt verir. Yanıt yeterince değerliyse yeni bir karşılaştırma sayfası olarak dosyalanır.

4. Lint: Haftalık denetimde ajan, hiçbir sayfadan bağlantı almayan öksüz notu ve altı ay önce yazılmış «güncel» ifadesini işaretler.

Kritik nokta: Bu akışta kazanç özet üretmek değil, iddianın kaynağını kaybetmemektir. Kaynağa bağlanmayan bir özet, altı ay sonra doğrulanamayan bir cümleye dönüşür ve sistemin tamamına duyulan güveni düşürür.

Silo Yapısı ve Ajanların Bilgiye Hızlı Erişimi

Arama motorları için geliştirilen silo (konu kümesi) mantığı, otonom ajanların gezindiği bir not deposunda da işe yarar: birbiriyle ilgili sayfalar aynı küme içinde yoğun biçimde bağlanır, kümeler arası bağlantı ise seçici tutulur. Böylece ajan bir konuya girdiğinde ilgili her şeyi birkaç adımda bulur ve alakasız dosyaları hiç okumaz.

Bunun ölçülebilir faydası bağlam maliyetindedir: iyi bağlanmış bir kümede ajan üç dosya okuyup yanıt üretirken, bağlantısız bir yığında aynı yanıt için onlarca dosya taramak zorunda kalır. Bağlantı disiplini burada estetik bir tercih değil, doğrudan token maliyetidir. Aynı ilkeyi bağlam mühendisliği yazısında genel çerçevesiyle ele aldım.

Gizlilik Sınırı, Yerel Depo ve Araç Erişimi

Kişisel bir ikinci beyin, tanımı gereği hassas veri taşır: müşteri notları, mali kayıtlar, sağlık bilgileri, yarım kalmış fikirler. Bu yüzden mimarinin ilk kararı depolamanın nerede olacağıdır. Düz markdown dosyalarından oluşan yerel bir depo, veriyi kapalı bir bulut hizmetine teslim etmeden çalışmayı mümkün kılar ve hangi dosyanın hangi ajana açıldığını denetlenebilir hâle getirir.

İkinci karar, ajanın dış dünyaya nasıl bağlandığıdır. Her araç için ayrı entegrasyon yazmak yerine standart bir arayüz kullanmak, yeni bir kaynak eklendiğinde sistemi yeniden yazmayı önler; Model Context Protocol (MCP) bu ihtiyacı hedefleyen açık bir standarttır. Yetki tarafında kural sadedir: ajan yalnız görev için gerekli klasörü okur, yazma yetkisi wiki katmanıyla sınırlıdır ve ham kaynaklara asla yazamaz. Bu ayrım, bir hatanın orijinal veriyi bozmasını yapısal olarak imkânsız kılar. Çok ajanlı kurulumlarda yetki ayrımının nasıl kurulduğunu üretim ortamında çoklu ajan mimarisi yazısında ayrıntılandırdım.

Ölçüm ve Veri: İkinci Beyin Ne Zaman İşe Yarıyor Sayılır?

Not sisteminin başarısını not sayısıyla ölçmek yanıltıcıdır; okunmayan not maliyet üretir, değer üretmez. İzlenmesi anlamlı olan ölçütler şunlardır:

Bu dört ölçüt kurulumun ilk günü taban çizgisi olarak kaydedilir. Sonraki her değişiklik — yeni bir klasör düzeni, farklı bir şema dosyası, ek bir ajan — bu tabana göre değerlendirilir. Ölçmeden yapılan iyileştirme, sistemi karmaşıklaştırıp faydayı azaltabilir ve bunu fark etmezsiniz.

Second Brain Sistemi Kurulumu: Nereden Başlanır?

Bir second brain sistemi kurmanın en yaygın hatası, en baştan eksiksiz bir klasör mimarisi tasarlamaya çalışmaktır. Boş bir iskelet kurup içini doldurmayı beklemek neredeyse her zaman terk edilmiş bir depoyla sonuçlanır; çünkü yapı, biriken içerikten doğar, içeriği önceden şekillendirmez. İşleyen kurulum şu sırayla ilerler.

1. Tek bir konu seçin. Hakkında zaten on beş civarı kaynağınız olan ve önümüzdeki aylarda gerçekten çalışacağınız bir konu belirleyin. İkinci beynin değeri kapsamından değil yoğunluğundan gelir: tek konuda derin bir ağ, otuz konuda dağınık notlardan fazlasını yapar. Bu aşamada hiçbir şey silmeyin, yalnız neyin dahil olacağına karar verin.

2. İki klasör açın. Ham kaynaklar bir klasöre, işlenmiş notlar diğerine. Bu ayrım tek başına en büyük kazancı sağlar; çünkü hangi metnin orijinal, hangisinin türetilmiş olduğunu her zaman bilirsiniz. Ham klasöre ajanın yazma yetkisi verilmez ve bu kural sonradan gevşetilmez.

3. Şema dosyasını yazın. Ajanın nasıl davranacağını anlatan kısa bir sözleşme hazırlayın: sayfa adları nasıl verilir, bir iddia hangi biçimde kaynağa bağlanır, çelişki bulunduğunda ne yapılır, hangi klasöre yazılabilir. On beş satırlık bir dosya yeterlidir; önemli olan uzunluğu değil, ajanın her koşumda aynı kurallara uymasıdır. Bu dosya zamanla insan ve ajan tarafından birlikte geliştirilir.

4. İlk işlemeyi elle denetleyin. İlk beş kaynağı ajanla işleyin ve çıktıyı satır satır okuyun. Bu okuma bir kalite kontrolünden fazlasıdır: şema dosyanızdaki boşlukları burada görürsünüz. Ajan bir iddiayı kaynaksız yazdıysa kural eksiktir, sayfayı yanlış adlandırdıysa adlandırma kuralı belirsizdir. Düzeltmeyi çıktıda değil sözleşmede yapın; aksi hâlde aynı hatayı her hafta elle düzeltirsiniz.

5. Bakım denetimini takvime bağlayın. Haftada bir kez lint çalıştırın: öksüz sayfalar, çelişkiler, eskimiş ifadeler. Bu adım atlanırsa depo birkaç ay içinde aranabilir olmaktan çıkar. Takvime bağlamanın sebebi disiplin değil, bakımın hiçbir zaman acil görünmemesidir; acil olmayan iş, planlanmadığında yapılmaz.

6. Ancak işe yaradığını gördükten sonra genişletin. Dört ölçütünüzü ilk ayın sonunda okuyun. Yeniden kullanım oranı düşükse sorun kapsamda değil, notların yazılış biçimindedir; kapsamı büyütmek bu sorunu çözmez, ölçekler. Sistem gerçekten sorularınızı yanıtlamaya başladığında ikinci konuyu ekleyin.

Bu altı adımın tamamı bir hafta sonunda kurulabilir. Kurulumun uzun sürmesi, genellikle araç seçimiyle uğraşmaktan kaynaklanır; oysa düz markdown dosyaları ve bir ajan yeterlidir, geri kalanı sonradan değiştirilebilir. Taşınabilirlik de buradan gelir: sayfalar düz metin olduğu sürece aracı değiştirmek deponuzu kaybetmek anlamına gelmez.

Kurulumun kalıcı olup olmayacağını belirleyen şey de araç değil alışkanlıktır. Depoya yeni kaynak girmiyorsa en iyi mimari bile birkaç ay içinde arşive dönüşür; buna karşılık düzensiz ama sürekli beslenen basit bir yapı zamanla gerçekten işe yarar hâle gelir. Bu yüzden ilk ayın hedefi sistemi mükemmelleştirmek değil, kaynak eklemeyi rutine bağlamak olmalıdır. Mimari kararları, hangi soruların tekrar tekrar sorulduğunu gördükten sonra vermek her zaman daha isabetli olur; erken alınan yapısal kararların çoğu, henüz karşılaşılmamış bir ihtiyacı tahmin etme denemesidir ve genellikle yanlış çıkar.

Hata Desenleri, Riskler ve Kaçınılacak Tuzaklar

• Ham kaynağı ajana yazdırmak. Ajanın orijinal belgeyi değiştirebildiği bir kurulumda geri dönüş noktası kalmaz. Ham katman değiştirilemez olmalıdır.
• Çelişkiyi sessizce çözmek. İki kaynak farklı şey söylüyorsa ajan birini seçip diğerini silmemelidir; çelişki işaretlenir ve kararı insan verir.
• Lint adımını atlamak. Yalnız üreten bir sistem birkaç ay içinde tekrar ve eskimiş bilgiyle dolar. Budama, üretme kadar önemlidir.
• Kaynaksız özet biriktirmek. Kaynağa bağlanmayan bir iddia zamanla doğrulanamaz hâle gelir ve tüm depoya duyulan güveni düşürür.
• Her şeyi işlemek. Depoya giren her belge işlenmeye değmez. Neyin dahil edileceğine karar vermek insanın işidir; bu filtre olmadan sistem büyür ama zenginleşmez.
• Şema dosyasını yazmadan başlamak. Ajanın nasıl davranacağını tanımlayan sözleşme yoksa her koşumda farklı biçimde yazar ve depo tutarsızlaşır.

Obsidian Türkçe Second Brain Mimari Tablosu

Bu düzeni kurmanın en hızlı yolu küçük başlamaktır: tek bir konuda on kaynak, bir şema dosyası ve haftalık bir lint. Sistem işe yarıyorsa kapsamı genişletirsiniz; yaramıyorsa on dosya silmek, iki yıllık bir depoyu temizlemekten kolaydır. Veri kaynaklarını ajanlara bağlarken izlenecek yolu MCP ile veritabanı bağlama yazısında adım adım anlattım.