Geçen yıl kendi tuttuğum teknik notları, sistem mimarisi şemalarını ve operasyon loglarını yerel bir vektör veritabanına gömüp üstüne bir LLM bağladığımda, artık hiçbir şeyi manuel aramayacağımı sanıyordum; ancak sistem ilk ciddi sorguda tamamen alakasız iki log dosyasını birleştirip bana hayali bir bug çözümü üretti. Kişisel bilgi yönetimi (Personal Knowledge Management - PKM) süreçlerinde yapay zeka araçlarının bekleneni verememesinin temel sebebi, bu araçların bilgiyi anlamlandırmak yerine istatistiksel olasılıklarla kelime tahmin etmesi ve bizim kişisel bağlamımızı (context) asla tam olarak kavrayamamasıdır. AI modelleri yapılandırılmamış, dağınık ve kişisel anektodlarla dolu not yığınları arasında bağlantı kurarken semantik (anlamsal) gürültü yaratır. Bu durum, aradığımız net bilgiye ulaşmak yerine yapay zekanın halüsinasyonlarıyla vakit kaybetmemize yol açar.
Bu yazıda, kendi sistemlerimde ve geliştirdiğim projelerde yaşadığım deneyimlerden yola çıkarak, AI tabanlı bilgi yönetim sistemlerinin neden tıkandığını teknik gerekçeleriyle masaya yatıracağız. Sadece sorunu konuşmakla kalmayacak, local LLM entegrasyonları ve doğru indeksleme stratejileriyle bu sistemleri nasıl daha kararlı hale getirebileceğimizi de pratik adımlarla inceleyeceğiz.
Kişisel Bilgi Yönetimi (PKM) Süreçlerinde AI Neden Beklentiyi Karşılamıyor?
Kişisel bilgi yönetimi, dışarıdan topladığımız ham verileri kendi süzgecimizden geçirip anlamlı birer deneyim haline getirme sürecidir; ancak AI araçları bu süreci tamamen otomatize etmeye çalışarak insan zihninin “ilişkilendirme” kasını köreltiyor. Yapay zeka entegrasyonlu not uygulamaları, önümüze “tek tıkla tüm notlarını özetle” veya “notların arasında akıllı aramalar yap” gibi vaatlerle çıkıyor. Pratikte ise bu durum, kullanıcının kendi notlarıyla olan entelektüel bağını koparıyor.
Bir yazılımcı veya sistem mimarı olarak tuttuğunuz notlar, sadece kuru metinlerden ibaret değildir. O notların yazıldığı anki stres, sistemin çökme durumu veya o kararı alırken vazgeçtiğiniz alternatif mimariler (trade-off) notun satır aralarında gizlidir. AI, bu satır aralarını okuyamaz. Sizin için hazırladığı özet, teknik olarak doğru görünse de kararın arkasındaki “neden” sorusunun cevabını genellikle ıskalar. Sonuçta elimizde, dışarıdan harika görünen ama içi boşaltılmış, derinliğini kaybetmiş bir bilgi çöplüğü kalır.
Bağlam Kaybı (Context Loss) ve Anlamsal Sapma Neden Yaşanıyor?
Büyük dil modellerinin (LLM) en büyük sınırlamalarından biri, girdi olarak verilen metinlerdeki zamansal ve durumsal bağlamı (context) kaybetmeye meyilli olmalarıdır. Örneğin, beş yıl önce yazdığınız bir “PostgreSQL performans optimizasyonu” notu ile geçen ay yazdığınız güncel bir not, AI gözünde benzer vektörel uzaylarda yer alır. Modeli beslediğinizde, eski sürümdeki geçerliliğini yitirmiş bir parametreyi (örneğin eski bir checkpoint_segments ayarını), bugünkü modern PostgreSQL 16 altyapınız için geçerli bir tavsiyeymiş gibi önünüze getirebilir.
Anlamsal sapma (semantic drift) ise, kişisel kısaltmalarınız, jargona dayalı notlarınız veya o döneme ait özel isimlendirmeleriniz devreye girdiğinde başlar. Kendi yan projelerimden birinde kullandığım özel bir kütüphane ismini, AI küresel ölçekteki popüler bir teknolojiyle karıştırıp bana o popüler teknolojiye ait konfigürasyonları önermişti. Modeller, genel internet verisiyle eğitildiği için sizin mikro dünyanızdaki özel tanımları, makro dünyadaki genel geçer doğrulara ezdirir.
RAG Mimarisi Kişisel Notlarda Neden Tıkanıyor?
Retrieval-Augmented Generation (RAG), harici bir bilgi kaynağından veri çekip bunu LLM’e bağlam olarak besleyen popüler bir mimaridir; fakat bu mimari, konu son derece öznel ve bağlantısal olan kişisel notlar olduğunda ciddi yapısal sorunlar yaşar. Kurumsal bir dökümantasyon sisteminde RAG harika çalışabilir çünkü orada “X politikası nedir?” sorusunun net ve tek bir cevabı vardır. Kişisel notlarda ise bilgi doğrusal değil, ağsı (networked) bir yapıdadır.
Aşağıdaki diyagramda, tipik bir RAG akışının kişisel notlar üzerindeki çalışma mantığını ve tıkanma noktasını görebilirsiniz:
graph TD;
A["Kullanıcı Sorgusu ('Geçen yılki veritabanı hatasını nasıl çözmüştüm?')"] --> B["Embedding Model (Vektör Dönüştürme)"];
B --> C["Vector DB Arama (Cosine Similarity)"];
C --> D["En Yakın 3 Chunk'ın Çekilmesi (Bağlam)"];
D --> E["LLM Prompt Oluşturma (Sorgu + Bağlam)"];
E --> F["LLM Yanıtı (Eksik veya Yanlış İlişkilendirilmiş Bilgi)"];
style F fill:#f9f,stroke:#333,stroke-width:2px;
Bu akıştaki en büyük problem, “En Yakın 3 Chunk’ın Çekilmesi” aşamasında yaşanır. Sizin o hatayı çözerken aldığınız notlar belki de 5 farklı güne, birbiriyle doğrudan semantik benzerliği olmayan (biri network katmanıyla ilgili, diğeri disk doluluğuyla ilgili) farklı dosyalara dağılmıştı. Vektör arama sadece kelime benzerliğine odaklandığı için, bu dağınık ama yapısal olarak ilişkili notları bir araya getiremez. Sonuç olarak LLM’e eksik bağlam gider ve yanıt hatalı olur.
Vektör Arama ve Chunking Stratejileri Nerede Çuvallıyor?
Bir metni vektör veritabanına kaydetmeden önce küçük parçalara (chunk) bölmeniz gerekir. Kişisel bilgi yönetiminde standart “karakter sınırına göre bölme” (character-based chunking) veya “paragraf bazlı bölme” stratejileri tamamen çuvallar. Çünkü kişisel notlarımız genellikle düzgün paragraflardan oluşmaz; listeler, kod blokları, tek satırlık hatırlatıcılar ve anlık ekran görüntüleri içerir.
Örneğin, markdown formatında tuttuğunuz bir notta, bir kod bloğunun ortasından yapılan kontrolsüz bir “chunk” bölme işlemi, kodun syntax yapısını bozar. LLM bu yarım yamalak kodu gördüğünde ne olduğunu anlayamaz ve kendi hafızasından (hallucination) kodun geri kalanını tamamlamaya çalışır. Ayrıca, örtüşme (overlap) değerini ne kadar yüksek tutarsanız tutun, bilgi parçacıkları arasındaki hiyerarşik ilişki (ebeveyn-çocuk ilişkisi) kaybolur.
- Metin Bölme Hatası: Kod bloklarının veya iç içe listelerin ortadan bölünmesi.
- Hiyerarşi Kaybı: Alt başlıkların, ait oldukları ana başlıktan koparak anlamsızlaşması.
- Semantik Gürültü: Alakasız günlük notların (journal), teknik notların arasına sızarak benzerlik skorlarını bozması.
Obsidian ve Local LLM ile Çalışan Güvenilir Bir Altyapı Nasıl Kurulur?
Eğer kişisel notlarınız üzerinde gerçekten çalışan ve gizliliğinizi ihlal etmeyen bir AI asistanı istiyorsanız, bulut tabanlı hazır servisler yerine yerel (local) çalışan ve bilgi grafiğini (knowledge graph) koruyan bir mimari kurmalısınız. Ben kendi sistemimde, markdown tabanlı not uygulamam olan Obsidian’ı, yerel bir model sunucusu olan Ollama ve akıllı bir indeksleme aracıyla entegre ederek bu sorunu büyük oranda aştım.
Buradaki sır, tüm notları körü körüne vektör veritabanına atmak yerine, sadece doğrulanmış ve yapılandırılmış notları içeren özel bir dizini (/brain) indekslemektir. Günlük karalamalarınızı, alışveriş listelerinizi ve geçici logları bu indeksin dışında tutmalısınız.
Aşağıda, yerel makinenizde çalıştırabileceğiniz ve notlarınızı semantik olarak indekslemek için kullanabileceğiniz basit bir Python script taslağı yer alıyor. Bu script, notlarınızı chunk’lara bölerken markdown başlık hiyerarşisini korur:
import os
from langchain_text_splitters import MarkdownHeaderTextSplitter
# Notlarımızın bulunduğu dizin
NOTES_DIR = "/home/mustafa/vaults/personal/brain"
headers_to_split_on = [
("#", "Header 1"),
("##", "Header 2"),
("###", "Header 3"),
]
markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on)
def index_notes():
for root, dirs, files in os.walk(NOTES_DIR):
for file in files:
if file.endswith(".md"):
file_path = os.path.join(root, file)
with open(file_path, "r", encoding="utf-8") as f:
content = f.read()
# Markdown başlıklarına göre akıllıca bölüyoruz
splits = markdown_splitter.split_text(content)
for split in splits:
# Burada split.page_content ve split.metadata değerlerini
# yerel vektör veritabanınıza (örn: ChromaDB veya Qdrant) yazabilirsiniz.
print(f"Indexed chunk from {file} with metadata: {split.metadata}")
if __name__ == "__main__":
index_notes()Bu yöntemi kullanarak, notların anlamsal bütünlüğünü bozmadan vektörleştirebilirsiniz. Üstüne yerel olarak koşturacağınız bir llama3 veya mistral modeliyle (Ollama üzerinden), verileriniz internete çıkmadan, kendi bilgisayarınızın sınırları içinde güvenli arama ve sorgulama yapabilirsiniz.
Bilgi Oburluğu ve “İkinci Beyin” Tuzağından Nasıl Kurtuluruz?
AI araçlarının hayatımızı kolaylaştırma vaadi, bizi daha fazla tüketmeye ve daha az üretmeye yönlendiriyor. İnternette gördüğümüz her makaleyi, her tweet zincirini “belki lazım olur” diyerek yapay zeka destekli okuma listelerimize atıyoruz. AI bizim yerimize bunları özetliyor, etiketliyor ve arşivliyor; ancak günün sonunda zihnimizde o konuya dair hiçbir kalıcı iz kalmıyor. Buna “bilgi oburluğu” ve sahte üretkenlik tuzağı diyoruz.
Gerçek bir kişisel bilgi yönetimi, elemeyi ve unutmayı bilmeyi gerektirir. Her şeyi kaydetmek, hiçbir şeyi kaydetmemekle eşdeğerdir. AI sistemlerinin önümüze yığdığı o devasa “ilişkili notlar” ağları, zihinsel odaklanmamızı artırmak yerine bizi bir hiper-link cehennemine sürükler. Çözüm, yapay zekayı bir “arşiv memuru” olarak değil, sadece tıkandığımız anlarda bize alternatif bakış açıları sunan bir “tartışma ortağı” (sparring partner) olarak konumlandırmaktır.
Son Söz
Kişisel bilgi yönetimi sistemlerinde yapay zekadan mucizeler beklemeyi bırakıp, onu kendi bilişsel süreçlerimizin bir alternatifi değil, sadece bir destekçisi olarak görmeliyiz. Kendi süzgecimizden geçmeyen, üzerinde kafa yormadığımız hiçbir not, AI ne kadar gelişmiş olursa olsun bize gerçek bir değer katmayacaktır.
Eğer bu alanda bir sistem kuracaksanız, verilerinizi bulut servislerine teslim etmek yerine yerel modellerle (local LLM) çalışmayı, notlarınızı markdown gibi geleceğe dönük ve açık formatlarda tutmayı ve en önemlisi, not tutmanın asıl amacının “hatırlamak” değil “düşünmek” olduğunu unutmamayı şiar edinin. Bir sonraki yazıda, yerel ağımızda koşturduğumuz bu local modellerin performans optimizasyonunu ve GPU/CPU kaynak yönetimini nasıl yapacağımızı detaylandıracağım.