Araştırma havuzundan bilgi tabanına — Kaynakları çalışabilir bir sisteme dönüştürmek

Araştırma dosyalarıyla dolu bir klasör henüz proje bilgisi değildir. Kaynaklar, ilişkiler, çelişkiler ve proje sonuçları insanların ve yapay zekânın bunları bulabileceği, kontrol edebileceği ve kararlarda kullanabileceği biçimde yapılandırıldığında gerçek bir bilgi tabanı ortaya çıkar.

İyi bir araştırma zincirinden sonra çok değerli ama aynı zamanda zahmetli bir şey oluşur: çok sayıda belge. Farklı araştırmalar farklı bakış açılarını inceler, birbirini tekrarlar, bazen çelişir ve çoğu zaman farklı ayrıntı düzeylerinde hazırlanır. Yapay zekâ destekli proje yönetiminde kolayca küçümsenen ikinci çalışma aşaması tam burada başlar.

Soru artık Daha ne araştırabiliriz? değildir. Asıl soru şudur: Toplanan malzemeyi projenin gerçekten kullanabileceği bir bilgi sistemine nasıl dönüştürürüz?

Bu geçiş somut biçimde gözlemlenebilir: onlarca Deep Research belgesi bir araya getirilir, anlamsal olarak ilişkilendirilir ve ortak bir bilgi tabanına dönüştürülür. Buradaki temel ilke kullanılan araçtan bağımsızdır: araştırma havuzu ham malzemedir. Bilgi tabanı ise bir çalışma mimarisidir.

Araştırma havuzu değerlidir ama henüz yönetilebilir değildir

40, 60 veya 100 araştırma dosyası düşünelim. Her biri tek başına iyi olabilir. Buna rağmen hemen şu sorunlar ortaya çıkar:

• Hangi dosya hangi soruyu yanıtlıyor?

• Hangi ifadeler yalnızca tekrar?

• Kaynaklar nerede birbiriyle çelişiyor?

• Hangi bulgu doğrulanmış, hangisi yalnızca olası?

• Hangi bilgi pazar, teknoloji, risk veya gereksinim alanına ait?

• Hangi bulgu daha önce bir proje kararına dönüştürüldü?

• Hangi kaynak artık eski ya da yalnızca tarihsel öneme sahip?

Bir insan küçük bir koleksiyonu elle tarayabilir. Proje büyüdükçe bu yaklaşım pahalı hale gelir. Yapay zekâ büyük miktarda içeriği daha hızlı okuyabilir; fakat kaynak kökeninin ve bağlamın kaybolmaması için onun da yapıya ihtiyacı vardır.

Asıl sorun dosya sayısı değildir. Sorun, dosyalar arasındaki yönlendirme eksikliğidir.

Bir bilgi tabanının en az üç katmanı vardır

Yapay zekâ projelerinde bilgi tabanını tek büyük depo olarak değil, birbiriyle bağlantılı üç katman olarak düşünmek faydalıdır.

1. Kaynak katmanı

Burada orijinaller bulunur: araştırma belgeleri, çalışmalar, toplantı notları, iç analizler, müşteri geri bildirimleri, teknik notlar, sonuçlar ve daha sonra proje dokümanları.

Bu katman mümkün olduğunca az değiştirilmelidir. Kimse artık kaynakta gerçekten ne yazdığını ve sonradan neyin özetlenip yorumlandığını ayırt edemiyorsa orijinal belge değer kaybeder.

Her kaynakta en az şu bilgiler bulunmalıdır: benzersiz ad veya sabit kimlik; köken; tarih veya sürüm; konu ya da geçerlilik alanı; durum: güncel, incelenmemiş, yerine yenisi gelmiş, tarihsel; gerekiyorsa hassasiyet veya erişim sınırı.

Kaynak katmanı projenin kanıt hafızasıdır.

2. Anlamsal katman

Burada ilişkiler kurulur. Veri kalitesi araştırması teknik uygulanabilirlik analizine bağlanır. Kullanıcı gözlemi bir gereksinime yönlendirir. İki kaynak çelişkili olarak işaretlenir. Birkaç araştırma ortak bir kavram altında toplanır.

Anlamsal katman şu sorulara yanıt verir: Hangi belgeler aynı kavramdan söz ediyor? Hangi bulgular aynı gereksinimi destekliyor? Hangi ifadeler birbiriyle çelişiyor? Hangi bilgiler aynı riske bağlanıyor? Belirli bir karar için hangi kaynak özellikle önemli?

Bu katman depolamayı yönlendirmeye dönüştürür.

3. Operasyonel katman

Burada bilgi eyleme dönüşür. Bulgular karar, gereksinim, görev, risk, kontrol ve proje çıktısına çevrilir.

Proje ekibi artık yalnızca "Kaynaklarımız ne diyor?" diye sormaz. Şunları sorar: Hangi bulgular kapsamımızı değiştiriyor? Hangi açık noktalar sonraki kararı engelliyor? Hangi gereksinimler yeterince desteklenmiş durumda? Hangi varsayım test edilmeli? Hangi proje sonuçları yeniden bilgi tabanına dönmeli?

Bilgi koleksiyonunu proje aracına dönüştüren katman budur.

Orijinali koru, sıkıştırmayı onun üzerine ekle

Konsolidasyonda yapılan yaygın hatalardan biri birçok kaynağı tek büyük "ana metinde" eritmek olur. Bu düzenli görünür; fakat daha sonra önemli olacak farklılıkları ortadan kaldırabilir.

Daha güçlü ilke iki aşamalıdır: Orijinali koru. Üzerine yoğunlaştırılmış katman ekle.

Bir kaynak belgenin üzerinde kısa bir kaynak notu bulunabilir:

# SOURCE NOTE

Kaynak: R-017
Konu: Yerel yapay zekâ sistemi için veri gereksinimleri

## Temel ifadeler
- ...
- ...

## Proje açısından önem
- ...

## Sınırlar / açık noktalar
- ...

## Bağlantılar
- [[Veri kalitesi]]
- [[Yerel mimari]]
- [[Risk: güncellik eksikliği]]

Bu kısa not kaynağın kendisi değildir. Kaynağa ulaşmak için bir navigasyon katmanıdır.

Bu hem insanlar hem yapay zekâ ajanları için önemlidir. Özet hızlı okunur. Fakat bir ifade karar açısından kritik hale gelirse orijinal belgeye dönüş yolu açık kalmalıdır.

Anlamsal bağlantı klasör yapısından daha fazlasıdır

Klasörler çoğunlukla şu soruyu yanıtlar: Bir şey nerede duruyor? Bilgi mimarisi ise ayrıca şunu yanıtlamalıdır: Neyle bağlantılı?

Tek bir dosya aynı anda şu alanlar için önemli olabilir:

• teknik uygulanabilirlik;

• veri koruma;

• maliyet;

• kullanıcı deneyimi;

• tedarik;

• proje riski.

Klasik klasör mantığında tek yer seçmek veya kopyalar oluşturmak gerekir. Anlamsal bağlantılar aynı kaynağın birden fazla bağlamda görünür kalmasını sağlar.

Bu durum yapay zekâ projelerinde özellikle önemlidir; çünkü birçok karar disiplinler arasıdır. Bir mimari tercihi aynı anda maliyeti, veri işleme biçimini, ekip yetkinliğini ve daha sonraki yönetiş gereksinimlerini etkileyebilir.

Bilgi bu nedenle raftan çok bir ağa benzer.

Çelişkiler bilgi tabanına aittir — halının altına değil

İki araştırma farklı sonuçlara ulaştığında "daha iyi" görünen ifadeyi seçip diğerini silmek cazip gelebilir. Proje çalışmasında bu tehlikelidir.

Çelişki şu nedenlerle oluşabilir: farklı tarihler; farklı tanımlar; farklı hedef gruplar; farklı varsayımlar; eşit olmayan veri kalitesi; farklı ölçüm yöntemleri.

Bu nedenle bilgi sistemi çatışmayı görünür tutmalıdır.

# CONFLICT NOTE

Konu: Beklenen işletme maliyeti

Kaynak A:
- İfade ...

Kaynak B:
- İfade ...

Farkın olası nedeni:
- ...

Ne kontrol edilmeli?
- ...

Karara etkisi:
- ...

Böylece çelişkinin kendisi bir çalışma maddesine dönüşür. Sistem, belirsizliğin düzgün yazılmış bir özet içinde kaybolmasını önler.

Bilgi tabanı yalnızca dosyalara değil, haritalara da ihtiyaç duyar

Koleksiyon büyüdükçe giriş noktaları kritik hale gelir. Hiç kimse proje bilgisinin nasıl düzenlendiğini anlamak için 80 dosya adını taramak zorunda kalmamalıdır.

Map of Content, genel bakış sayfaları veya tema haritaları faydalıdır. Bunlar tüm içeriği tekrar etmez; önemli ilişkileri görünür kılar.

Örneğin "Teknik Mimari" haritası şöyle olabilir:

# MAP — TEKNİK MİMARİ

## Temeller
- [[R-004 Sistem gereksinimleri]]
- [[R-011 Altyapı karşılaştırması]]

## Kararlar
- [[D-003 Hibrit mimari]]

## Riskler
- [[RK-007 Sağlayıcı bağımlılığı]]
- [[RK-012 Veri sızıntısı]]

## Açık sorular
- [[Q-018 İşletme maliyeti]]
- [[Q-024 Yedekleme stratejisi]]

Bu harita belgelerin yerine geçmez. Bilgi alanı için bir okuma merceğidir.

Yapı içerikten büyümelidir

Burada önemli bir nokta açık hale gelir: Var olan bir veritabanı yapısı yalnızca daha önce kullanıldığı için körü körüne kopyalanmamalıdır. Mimari, malzemeye ve projeye uymalıdır.

Yani önce 30 klasör oluşturup sonra her kaynağı bunlardan birine zorlamak yerine:

1. kaynakları oku;

2. tekrar eden temaları belirle;

3. önemli ilişkileri bul;

4. kategori, harita ve bağlantıları bunlardan türet;

5. yapı fazla karmaşık hale gelirse daha sonra sadeleştir.

Bu yaklaşım gerçek bilgi çalışmasına daha yakındır. Teknik olarak düzenli fakat içerik açısından hiçbir şey açıklamayan arşiv probleminden kaçınır.

Kökeni kaybetmeden sıkıştır

Gerçek projelerde platform sınırları vardır. Bir tarayıcı çalışma alanı sınırlı sayıda dosya kabul edebilir. Bir modelin bağlam penceresi sınırlıdır. Ekip üyesi mobil çalışıyor olabilir ve tüm bilgi alanını yükleyemeyebilir.

Bu durumda sıkıştırma faydalıdır; ancak kontrollü yapılmalıdır.

Sağlam zincir şudur: Kaynak → çıkarım → sentez → çalışma bağlamı. Şu değildir: Kaynak → özet → orijinali unut.

Daha küçük bir çalışma bağlamı için örneğin 60 kaynak on tematik senteze sıkıştırılabilir. Fakat bu sentezler orijinal kaynaklara bağlanmaya devam etmelidir. Böylece izlenebilirlik korunur.

Sıkıştırılmış katman bilginin taşıma biçimidir, tek depolama alanı değildir.

Veritabanı araştırma aşaması bittiğinde sona ermez

Dersin en güçlü fikirlerinden biri, bilgi tabanının yalnızca proje başlangıcını desteklememesidir. Tüm proje yaşam döngüsüne eşlik eder.

Proje ilerledikçe yeni öğeler eklenir: uygulanabilirlik analizleri; kararlar ve gerekçeler; testler ve test sonuçları; müşteri geri bildirimi; değişiklik talepleri; hatalar ve olaylar; yeni araştırmalar; durum raporları; retrospektifler; nihai sonuçlar.

Böylece araştırma tabanı adım adım bir proje hafızasına dönüşür.

Bilgi tabanı planlama, uygulama, inceleme ve sonraki öğrenmeyi birbirine bağlar. Derste bunun için "projenin omuriliği" benzetmesi kullanıldı: bilgi yalnızca içeri girmez, projenin farklı bölümlerini birbirine bağlar.

Yapay zekâ arşivci olabilir — ama ancak açık kurallarla

İyi yapılandırılmış bilgi tabanı yapay zekânın ilişkileri daha hızlı fark etmesini sağlar. Şu soruları yanıtlayabilir: Bu karar hangi kaynağa dayanıyor? Hangi açık riskler bu gereksinimle bağlantılı? Son plan sürümünden beri hangi bulgular eklendi? Hangi kaynaklar mevcut varsayımla çelişiyor? Bir review için hangi belgeler okunmalı?

Fakat bu, yapay zekânın otomatik olarak güvenilir bilgi yöneticisi olduğu anlamına gelmez. Kurallara ihtiyacı vardır:

• orijinal kaynaklar sessizce üzerine yazılmaz;

• sentezler orijinallerden ayırt edilebilir kalır;

• çelişkiler yumuşatılmaz, işaretlenir;

• belirsiz köken belirsizlik olarak ele alınır;

• eski bilgiler güncelmiş gibi kullanılmaz;

• hassas bilgiler açık erişim sınırlarına sahip olur.

Yapay zekânın bilgiye erişim kalitesi doğrudan bilgi mimarisinin kalitesine bağlıdır.

Araçtan bağımsız düşün: Obsidian veya Drive'dan önce yöntem

Obsidian bağlantılı Markdown bilgi alanları için güçlüdür. Küçük projelerde normal dosya sistemi yeterli olabilir. Özel knowledge graph sistemleri de uygun olabilir.

Önce yöntem gelir.

Minimal bir bilgi mimarisi şöyle olabilir:

01 Kaynaklar
02 Çıkarımlar
03 Kavramlar
04 Çelişkiler
05 Kararlar
06 Riskler
07 Proje çıktıları
08 Genel bakışlar

Klasör adlarından daha önemli dört özellik vardır:

1. Köken görünür kalır.

2. İlişkiler izlenebilir olur.

3. Durum ve güncellik anlaşılır olur.

4. Bilgi somut proje kararına dönüştürülebilir.

Bu dört özellik varsa yapı daha sonra Obsidian veya başka sisteme taşınabilir; mantığı yeniden icat etmek gerekmez.

Uygulanabilir sekiz adımlı süreç

Adım 1 — Kaynakları envantere al

Her dosyaya sabit kimlik, köken, tarih ve genel konu ekle.

Adım 2 — Kopyaları ve varyantları tespit et

Aynı veya çok benzer belgeleri işaretle. Eski sürümleri erişilebilir tut ama durumlarını açıkça belirt.

Adım 3 — Karar açısından önemli ifadeleri çıkar

Her şeyi özetleme. Yalnızca proje kararını değiştirebilecek ifadeleri, sınırları, örnekleri ve açık soruları çıkar.

Adım 4 — Kavram ve temaları oluştur

Tekrarlanan fikirleri kavram kartlarına dönüştür. Bir kaynak birden fazla kavrama bağlanabilir.

Adım 5 — Çelişkileri işaretle

Çelişen ifadeleri hemen çözmeye çalışma. Önce neden farklı olduklarını ve farkın karar açısından önemli olup olmadığını incele.

Adım 6 — Genel bakış haritaları oluştur

Ana proje alanları için insanların ve yapay zekânın bilgi alanına hızlı girmesini sağlayacak harita veya indeksler oluştur.

Adım 7 — Proje kararlarını bağla

Kararlar dayandıkları kaynak ve sentezlere geri bağlansın. Böylece mevcut planın neden bu biçimde olduğu görülebilir.

Adım 8 — Uygulama sırasında bilgiyi güncelle

Yeni sonuç, test, geri bildirim ve değişiklikleri sisteme geri aktar. Bilgi tabanı statik arşiv değil, canlı çalışma malzemesi olarak kalır.

Bilgi tabanı ne zaman çalışabilir durumdadır?

Büyük olduğunda değil. Güzel göründüğünde değil. Her belge bir yere konduğunda da değil.

Bir insan veya ajan şu sorulara güvenilir biçimde cevap verebildiğinde çalışabilir durumdadır: Bu ifadeyi hangi kaynak destekliyor? Bununla başka hangi bilgiler bağlantılı? Nerede belirsizlik veya çelişki var? Hangi sürüm güncel? Buradan hangi karar türetildi? Sonraki soru veya görev nedir?

Böylece araştırmanın rolü değişir. Proje planından sonra kaybolan ön aşama olmaktan çıkar ve sürekli bilgi döngüsünün ilk parçası olur.

Sonuç: Daha fazla dosya değil, daha fazla ilişki

Yapay zekâ büyük miktarda araştırma üretmeyi kolaylaştırır. Bu nedenle ikinci yetenek daha kritik hale gelir: bilginin kökenini, farklılıklarını ve belirsizliğini yok etmeden onu organize etmek.

Araştırma havuzu farklı perspektifleri toplar. Bilgi tabanı bunları bulunabilir, bağlantılı ve kullanılabilir hale getirir. Orijinalleri sentezlerden ayırır, çelişkileri korur, bulguları kararlara bağlar ve proje boyunca büyümeye devam eder.

Belirleyici adım tek bir araca mümkün olduğunca çok malzeme yüklemek değildir. Her önemli bulgunun bir yeri, kökeni, ilişkisi ve sonraki kullanımı olan bir bilgi alanı kurmaktır.

Bir sonraki makale tam bu temelin üzerine kurulabilir: Farklı insanlar veya projeler farklı yöntemler, deneyimler ve çözümler sunduğunda ortak bilgi tabanı bunlardan kolektif bir yöntem haritası üretmek için kullanılabilir.

Çalışma kâğıdı: Altı araştırmadan mini bilgi tabanı kur

Aynı konuya ait altı araştırma veya proje belgesi seç. Amaç kusursuz Vault değil, küçük ve izlenebilir bir bilgi mimarisi oluşturmaktır.

1. Kaynakları envantere al

Her dosyaya kimlik ver ve köken, tarih, konu ve durumunu kaydet.

2. Temel ifadeleri çıkar

Her kaynak için proje kararını değiştirebilecek en fazla beş ifade yaz.

3. Üç kavram kartı oluştur

Tekrarlanan üç tema belirle ve her kaynağı en az bir kavram kartına bağla.

4. Bir çelişkiyi belgeye dönüştür

Tam olarak uyuşmayan iki ifade bul. Olası nedeni, açık soruyu ve proje üzerindeki etkisini yaz.

5. Bir genel bakış sayfası kur

Kaynaklara, kavramlara, çelişkiye ve açık sorulara doğrudan ulaşabileceğin bir giriş sayfası oluştur.

6. Bir kararı bağla

Küçük bir proje kararı yaz ve bu kararın dayandığı kaynakları belirt.

7. Geri besleme döngüsünü tanımla

Gelecekte hangi proje sonuçlarının yeniden bilgi tabanına alınması gerektiğini belirle.

Yansıtma

Basit bir dosya klasöründe en kolay kaybolacak bilgi hangisiydi? _________________________________________________

İki kaynak arasındaki hangi ilişki proje kararını en güçlü biçimde değiştiriyor? _______________________________________________

İndirilecek tüm materyaller — konu özeti ve çalışma kâğıdı: