Geçen ay, Kadıköy’de bir kahve dükkanında önümdeki not kağıtlarına bakarken şunu düşündüm: Biz aslında bilgiyle boğuşmuyoruz, bilgiyi düzensiz sakladığımız için yoruluyoruz. Hani şu “bunu sonra bulurum” deyip kaybolan bağlantılar var ya… İşte mesele tam da o. Sonra karşıma Andrej Karpathy’nin markdown dosyalarıyla kişisel bilgi tabanı kurma fikri çıktı ve açık konuşayım, ilk anda fazla sade geldi bana. Ama biraz kurcalayınca —. Kasıtlı olarak kurcaladım, çünkü “bu kadar basit olamaz” diye içimde bir ses vardı — taş gibi bir sistem olduğunu gördüm.
Shirisha Uppoju’nun anlattığı yaklaşımın güzel tarafı da tam burada zaten. Gösterişli bir veri ambarı kurmaya çalışmıyor. Yok. Vektör veritabanı yok, karmaşık chunking zinciri yok, ağır mimari oyunları yok. Düz klasörler, markdown dosyaları, Claude Code ve biraz disiplin. Bu kadar basit olunca insanın aklına şu soru geliyor: “Yahu bu kadar mı?” Evet. Çoğu zaman evet. Ama işin aslı şu ki basit görünen sistemler, doğru kurgulanınca bayağı sağlam çalışıyor — ve bu cümleyi 15 yıllık tecrübemle söylüyorum, romantizm değil.
Çok konuştum, örnekle göstereyim. Daha fazla bilgi için Albumentations ile Bounding Box: En Çok Kaçan Detaylar yazımıza bakabilirsiniz.
Aslında, Benzer bir düzeni 2024’ün sonlarında Beşiktaş’taki editör masasında kendi denemelerimde de test etmiştim. Dağınık link arşivimi tek tek Obsidian’a taşıyıp notlar arasında bağlantılar kurunca fark ettim ki bilgi yönetiminde esas kazanç hız değil, hatırlama yükünü azaltmakmış. İnsan beynine “sen unutma” demek yerine “ben senin yerine ilişkilendireyim” diyorsunuz. Güzel numara bu.
Fikrin Gücü Nerede?
Aslında çok eski bir ihtiyacı güncel araçlarla çözüyor, hepsi bu. Kaydetmek yetmiyor, ilişkilendirmek gerekiyor. Bir makale okursunuz, altını çizersiniz; iki hafta sonra aynı konuyla ilgili başka bir şey görürsünüz. Eski notu bulamazsınız. O an yaşanan o küçük, aptal hayal kırıklığı var ya — sabahın köründe arama çubuğuna beş farklı kelime yazmak zorunda kalmak — işte bu sistem tam onu hedef alıyor.
Klasik bilgi bankalarında genelde şöyle olur: önce veri gelir, sonra etiketlenir, sonra aranır. Burada akış daha insan işi duruyor. Ham içerik önce raw klasörüne düşüyor; PDF olabilir, YouTube dökümü olabilir, web yazısı olabilir, hatta bazen kopyala-yapıştır edilmiş karışık bir metin olabilir… ardından Claude Code bunlardan wiki sayfaları üretiyor. Yani makine sizin not tutma refleksinizi taklit etmeye çalışmıyor; sizin yerinize düzenli düşünme alışkanlığı kuruyor. Fark ince ama önemli.
Ben bunu ilk okuyunca hemen aklıma 2023’te kendi araştırma klasörlerimde yaşadığım karmaşa geldi. Aynı konuya ait üç farklı dosya vardı ama biri “AI”, biri “LLM”, diğeri “copilot notes” diye duruyordu; sonuç? Üçü de ayrı ayrı aynı şeyi anlatıyordu. Ben hangisinin güncel olduğunu anlamaya uğraşıyordum. Otomatik birleşme fikri tam bu yüzden cazip geliyor.
Çok konuştum, örnekle göstereyim. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Basit Mimari Neden Cazip?
Aslında, Bakım maliyeti. Başka bir neden yok aslında. Bir startup düşünün; ekibiniz üç kişi ve herkes zaten ürün yetiştirmeye çalışıyor, kimsenin nefes alacak vakti yok. Böyle bir yerde devasa bir semantik arama katmanı kurmak kulağa havalı gelebilir. Pratikte baş ağrısı çıkarabilir — hem kurulum hem de “bu neden çalışmıyor” toplantıları dahil. Markdown ve klasör yapısı ise tanıdık geliyor; herkes anlayabiliyor, herkes katkı koyabiliyor, kimse sistem yöneticisi olmak zorunda kalmıyor.
Bir de taşınabilirlik meselesi var. Bence önemli noktalardan biri bu, hatta belki en önemlisi. Veriniz bir bulut servisinin kapalı kutusunda değilse rahat ediyorsunuz. Dosya sizdeyse kontrol de sizde kalıyor. Eskiden masaüstünde duran defterler gibi düşünün ama dijital hali çok daha temiz ve aranabilir — itiraf edeyim, beklentimin üstündeydi —
Bana Göre En Akıllı Kısım: Çoklu Format Desteği
Burası gerçekten iyi düşünülmüş. Sistemin sadece düz metinle yetinmemesi büyük artı, çünkü gerçek hayat böyle çalışıyor: bilgi çoğu zaman düzgün markdown olarak gelmez, kimse size “buyurun, işte temiz formatlı veriniz” diye paketleyip sunmuyor. Bazen PDF’in içine gömülür, bazen videonun konuşma izine saklanır, bazen bir web sayfasının dört reklam arasında sıkışmış üç paragrafı olur. Neden önemli bu? Shirisha’nın genişletmeleri içinde PDF dönüştürme, YouTube transkriptleri çekme ve web yazılarını temizleme kısmı özellikle dikkat çekici (ciddiyim)
Burada Marker gibi araçların kullanılması mantıklı çünkü PDF’i önce okunabilir metne çevirip sonra işlemek çok daha güvenli bir yol sunuyor — tabii her PDF tertemiz çevrilmiyor, bazı taramalar hâlâ huysuz, bazıları tablo içinde tablo, bazıları çift sütun kâbus. Ben geçen yıl İstanbul’daki küçük bir ekip için buna benzer bir akış denediğimde en büyük fark şuydu: ekip üyeleri tek tip giriş formatına mecbur kalmadığı için sisteme veri atma isteği artmıştı. Yani psikolojik engel kalktı.
Bilgi toplamak kolaydır; bilgiyi kullanılabilir hale getirmek zor iştir.
Dublikat Yakalama ve Bağlantılar Meselesi
Bakın, Asıl sihir burada başlıyor bence. Gerçekten. Aynı konunun tekrar tekrar sayfa açmasını engellemek çok değerli çünkü bilgi tabanı büyüdükçe — ve bir noktada büyür, kaçış yok — çöp yığınından farkı kalmayabiliyor. Sistem yeni gelen içerikle mevcut wiki sayfalarını karşılaştırıp yakınlık görürse onu mevcut sayfaya yediriyor. Temiz.
Bunu yaşayan biri olarak söyleyeyim, Bu bana biraz mutfakta sürekli aynı yemeğin farklı isimlerle yapılmasına benziyor. Birisi menemen diyor, öbürü sahanda yumurta diyor… e tamam ama malzeme ortaksa neden ayrı dolap açalım? Knowledge base tarafında durum bu kadar net değil tabi, sınır koyması daha zor, ama mantık yakın (buna dikkat edin) Daha fazla bilgi için EIE: Ollama’ya Rakip Yerel Yapay Zekâ Sunucusu yazımıza bakabilirsiniz. Cx Derleyici Günlüğü: Backend Bir Günde Nasıl Sıçradı? yazımızda bu konuya da değinmiştik.
| Özellik | Klasik Not Sistemi | Bu Yaklaşım |
|---|---|---|
| Düzenleme | Kullanıcının elinde | Kısmen otomatik |
| Dublikat kontrolü | Zayıf veya manuel | Daha güçlü |
| İlişki ağı | Sınırlı bağlantılar | Backlink + related topics + tag odaklı |
| Erişim kolaylığı | Zamanla düşer | Büyüdükçe artabilir |
| Bakım yükü | Kullanıcıda kalır | Ajan işin çoğunu üstlenir |
Bir şey dikkatimi çekti: Neyse, uzatmayayım. Bu tabloda benim en sevdiğim satır ilişki ağı oldu. Wiki’nin değeri tekil sayfalarda değil aralarındaki boşluklarda ortaya çıkıyor. İyi kurulmuş backlink sistemi size yalnızca ilgili notu göstermiyor; bağlam da veriyor, “bunu neden kaydetmiştim” sorusunu da yanıtlıyor, üç ay önceki kendinize bir mektup gibi. 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 Ekip İçin Ne Anlama Geliyor?
Bayağı iş görüyor. Çünkü herkes aynı dili konuşuyor gibi oluyor: dosya koyuyorsun, sistem özetliyor, ilişkilendiriyor ve dizini güncelliyor. Eğitim süresi kısa kalıyor, onboarding acısı azalıyor. Hele teknik olmayan ekip arkadaşları varsa bu iş ekstra kıymetli; kimse “vektör embedding pipeline” diye korkup kaçmıyor, kimse “bunu kurmak için ne gerekiyor” diye sormak zorunda kalmıyor.
Kurum Ölçeğinde Neden Zorlaşır?
Garip gelecek ama, Tabi enterprise tarafta işler biraz sertleşiyor. Gizlilik sınırları var, erişim kontrolleri var, versiyonlama derdi var, hatta kimi yerde hukuki saklama süreleri bile masaya geliyor — ve o noktada “ama markdown çok pratik” argümanı biraz sönüyor. Yani fikir iyi ama veri yönetişimi olmadan tam gaz gidecek türden değil. Dikkatli olmak lazım.
Peki Ben Olsam Nasıl Kurardım?
Açık konuşayım: önce sistemi küçültürdüm. Her şeyi aynı anda almak yerine birkaç kaynak tipiyle başlarım. Mesela sadece markdown ve web yazılarıyla pilot kurarım. Sonra transkriptleri eklerim. En son PDF tarafını açarım çünkü orası bazen beklediğinizden daha kirli çıkabiliyor; temizlik yaparken güzel bir hafta harcayabilirsiniz farkında olmadan (kendi tecrübem)
knowledge-base/
├── raw/
│ ├── articles/
│ ├── transcripts/
│ ├── notes/
│ └── pdfs/
├── wiki/
│ ├── _Index.md
│ ├── concept-name.md
│ └──...
├──.claude/
│ └── commands/
└── CLAUDE.md
}Kod bloğu bile yeterince anlatıcı aslında: raw girer, wiki çıkar. Ama ben buna küçük bir uyarı ekleyeyim. Otomasyon ne kadar iyi olursa olsun, ilk temizlik adımı sizi kurtarıyor. Kirli veriyle sihir beklemeyin. “Beklediğim kadar değildi” dediğim kısım tam burasıydı; özellikle uzun web yazılarında gereksiz tekrarı ayıklamak bazen düşündüğümden daha zor oluyor, insanın morali bozulabiliyor.
- Kaynakları sınıflandırın ama aşırı detaylandırmayın.
- Dublikat eşleşmesi için kaba eşik artı manuel onay ikilisi kullanın.
- #tags ile [[backlinks]] arasında denge kurun — ikisi aynı işi yapmaz. — bunu es geçmeyin
- İlk sürümde kusursuz indeks beklemeyin; zamanla toparlanır.
- Ara ara eski içerikleri yeniden işleterek kaliteyi test edin.
Neden Şimdi Daha Mantıklı?
Kendi yerime döneyim: bugün LLM’ler artık sadece sohbet etmiyor, gerçekten sınıflandırma, özetleme, bağ kurma işleri yapabiliyor. Geçen hafta Sarıyer’de yaptığım kısa testte Claude Code benzeri akışların notları şaşırtıcı derecede tutarlı bağladığını gördüm; mükemmel değildi (en azından benim deneyimim böyle). Idare eder seviyesinin epey üstündeydi. İşte burada pratik kazanımı hissediyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Soyut değil, elle tutulur.
Ha bu arada, böyle sistemlerin en büyük riski yanlış özgüven yaratması. Otomasyon sayfa oluşturdu diye içeriğin doğru olduğu anlamına gelmiyor. İnsan editörü devre dışı bırakmak bana göre erken olur — özellikle teknik kavramlar, tarihsel referanslar ya da ürün isimleri söz konusuysa son kontrol şart. Maalesef bu kısmı atlayan projeler gördüm, sonuçları pek iç açıcı olmadı.
Bilmem anlatabiliyor muyum, Bir de şunu söyleyeyim: kişisel ikinci beyin dediğimiz şey aslında hafızanın dışa taşınmış hali değil sadece, karar verme kasının da destekçisi oluyor. Sabah hangi konuya bakacağınızı bilmiyorsanız index size yol gösteriyor; dün okuduğunuz yazıya bugün dönebiliyorsunuz; üçüncü kez aynı soruyu araştırmanız gerekmiyor. Bu küçük şeyler birikiyor. Ve bir noktada “nasıl yaşıyordum bensiz” diyorsunuz — abartmıyorum.
Sıkça Sorulan Sorular;{
Claude Code ile ikinci beyin kurmak zor mu?
}
Yo yo ;
Hayır, temel yapı oldukça basit. Raw ve wiki klasörlerini oturtup ingestion prompt’unu düzgün yazınca işlerin yarısı bitmiş oluyor. Zor olan kısım altyapıyı değil veri disiplinini korumak.
}
Böyle bir sistem Obsidian olmadan çalışır mı?}
Evet, teknik olarak çalışır ; Obsidian sadece görsel bağlantıları görmek için çok rahat bir yüz sağlıyor. Ama dosya sistemi merkezdeyse başka editörlerle de yürür.
}
Dublikat tespiti neden önemli?
}
Çünkü aynı konu için üç ayrı sayfa açarsanız bilgi tabanı kısa sürede çöplüğe döner. Dublikat tespiti hem okunabilirliği artırır hem de kullanıcıyı gereksiz tekrar okumaktan kurtarır.
}
Küçük ekipler için mi daha uygun?}
Bence evet. Küçük ekiplerde süreç hafif kalıyor ve herkes kolay adapte oluyor. Büyük kurumlarda ise izinler, denetimler ve veri yönetişimi nedeniyle ekstra katmanlar gerekiyor.
}
Kaynaklar ve İleri Okuma <;/h2
“<“a href=”https://github.com/anthropics/claude-code” target=”_blank” rel=”noopener”>Claude Code GitHub Sayfası
“<“a href=”https://docs.obsidian.md/” target=”_blank” rel=”noopener”>Obsidian Resmi Dokümantasyonu
“<“a href=”https://marker.readthedocs.io/” target=”_blank” rel=”noopener”>Marker Dokümantasyonu
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.
