300.000 kitabı kapsayan bir kategori ağı nasıl yönetilir?

Bir katalog küçükken kategori sistemi basit görünür. Birkaç başlık açılır, içerikler uygun görünen yere yerleştirilir ve sistem çalışır. Ölçek büyüdüğünde ise mesele "bu kitap hangi kategoriye girer?" sorusundan çıkar. Aynı tür kararın yüz binlerce kayıt boyunca tutarlı verilip verilemeyeceği sorusuna dönüşür.

Ekip Dağıtım tarafında üzerinde çalıştığımız yapı, 300.000 kitabı kapsayan bir kategori ağıydı. Operasyon yaklaşık 12 ay sürdü ve 17 kişilik bir ekiple yürütüldü. Ahmet ve Seçil ekibi birlikte organize edip yönetti.

Büyük bir taksonomide asıl ürün kategori ağacının kendisi değil; aynı sınıflandırma mantığını yüz binlerce kayıtta tekrar üretebilen karar sistemidir.

Ölçek büyüdüğünde kategori problemi neden değişiyor?

On kitap için sezgi yeterli olabilir. Yüzlerce veya binlerce içerikte ise aynı kavrama farklı isimler verilmesi, benzer kategorilerin paralel büyümesi, alt-üst ilişkilerinin belirsizleşmesi ve ekip üyelerinin aynı kuralı farklı yorumlaması sistemik hata üretmeye başlar.

Bu yüzden bilgi mimarisini yalnızca bir ağaç çizimi olarak görmüyorum. En az beş katmanı birlikte düşünmek gerekiyor:

Bu beşli, sitede gösterdiğim operasyon akışının da özeti: Girdi → Kategori ağı → Ekip incelemesi → Kalite kontrol → Teslim.

1. Önce kelimeleri değil karar sınırlarını tasarlamak

Taksonomi çalışmasında ilk refleks kategori isimleri üretmek olabilir. Oysa isim, alttaki karar net değilse yalnızca etikettir.

Örneğin iki kategori arasında ayrım yaparken şu soruların cevapları görünür olmalı:

• Bu kategori hangi içeriği kabul eder?
• Hangi içeriği özellikle dışarıda bırakır?
• Üst kategori ile farkı nedir?
• Komşu kategori ile çakıştığında hangi kural kazanır?
• İçerik birden fazla yere aitse bunun davranışı nedir?

Bir kategori tanımını bu sınırlar olmadan ekibe vermek, aynı terimi 17 farklı zihinsel modele teslim etmek demektir.

1const taxonomyNode = {2  label: '...',3  includes: ['...'],4  excludes: ['...'],5  parent: '...',6  neighbors: ['...'],7  ambiguityRule: '...',8};

Kod burada gerçek veri modelini temsil etmiyor; zihinsel modeli gösteriyor. Bir düğümün yalnızca adı değil, karar davranışı olmalı.

2. Ağacı büyütmekten önce tekrar eden kararları bulmak

Büyük kataloglarda en pahalı sorunlardan biri gereksiz kategori çoğalmasıdır. İki farklı ekip üyesi aynı ihtiyacı farklı isimlerle çözerse ağaç genişler ama anlam zenginleşmez.

Bu nedenle yeni kategori açma kararını "bu isim mantıklı mı?" seviyesinden çıkarıp "mevcut sistem bu ayrımı gerçekten ifade edemiyor mu?" seviyesine taşımak gerekir.

Ben bunu ürün mimarisindeki yeni abstraction kararına benzetiyorum. Her yeni ihtiyaç yeni bir katman doğurmamalı. Önce mevcut sınırların yeterli olup olmadığı kontrol edilmeli.

Taksonomi kalitesi, kaç kategori ürettiğinizle değil; gerekli ayrımları mümkün olan en az belirsizlikle ifade edebilmenizle ilgilidir.

3. Ekip büyüdükçe dokümantasyon ürünün parçası olur

17 kişilik bir operasyonu yalnızca sözlü yönlendirmeyle tutarlı yürütmek mümkün değil. Bilgi mimarisinin bir bölümü kategori ağında, diğer bölümü ekip üyelerinin kafasında kalırsa sistem zamanla ayrışır.

Bu noktada dokümantasyonun amacı uzun kılavuz yazmak değil; sık tekrar eden kararları kısa, erişilebilir kurallara çevirmektir.

İyi bir karar kaydı şunları cevaplamalı:

• Karar nedir?
• Neden bu karar verildi?
• Hangi örnek bu kurala girer?
• Hangi benzer örnek girmez?
• Belirsizlikte kime veya hangi kurala dönülür?

Bu yaklaşım, bugün AI agent'larıyla çalışırken kullandığım "kaynak doğrusu" fikrine de çok benziyor. İnsan ekipte de agent ekipte de aynı sorun var: kararın tek bir güvenilir açıklaması yoksa hız tutarsızlığı büyütür.

4. Kalite kontrolü sona bırakmamak

Yüz binlerce kaydı işleyip en sonunda kontrol etmeye çalışmak verimsizdir. Çünkü yanlış yorum erken aşamada fark edilmezse aynı hata yüzlerce veya binlerce kayıtta tekrar edilmiş olabilir.

Kalite kontrolünü ayrı bir son kapı yerine operasyonun içine gömmek gerekir.

1Girdi2  ↓3Sınıflandırma4  ↓5Ekip incelemesi6  ↓7Kalite kontrol8  ↺ gerekirse kurala geri dön9  ↓10Teslim

Buradaki kritik geri dönüş, yalnızca yanlış kaydı düzeltmek değildir. Hata tekrar ediyorsa kategori tanımını veya karar kuralını düzeltmek gerekir.

Bu ayrım önemli: semptomu düzeltmek başka, karar sistemini düzeltmek başka.

5. Bir hatayı kişi problemi yerine sistem sinyali olarak okumak

Aynı tür hata birden fazla kişide ortaya çıkıyorsa ilk soru "kim yanlış yaptı?" olmamalı. Kural yeterince açık mı, kategori sınırı çakışıyor mu, örnekler yetersiz mi, inceleme aşaması problemi geç mi yakalıyor diye bakmak daha değerlidir.

Büyük ekip operasyonlarında bireysel dikkat önemlidir; fakat kaliteyi yalnızca dikkatli insanlara bağlamak ölçeklenmez.

Bu bakış açısı daha sonra ürün geliştirmede de taşıdığım en önemli prensiplerden biri oldu: tekrar eden hata çoğu zaman insan hatasından önce sistem tasarımı sinyalidir.

6. Taksonomi yalnızca içerik düzeni değildir

Kategori ağı kullanıcı arayüzünde görünmese bile arama, filtreleme, keşif, raporlama, içerik yönetimi ve ekip operasyonunu etkiler. Kötü bilgi mimarisi bu yüzeylerin her birine ayrı problem olarak sızar.

Aynı kavram farklı yerlerde farklı adlarla yaşıyorsa:

• kullanıcı doğru sonucu bulmakta zorlanır,
• filtreler anlamsız çoğalır,
• ekip aynı içeriği farklı biçimde işler,
• raporlama parçalanır,
• sonraki sistemler kirli bir kaynak veri devralır.

Bu yüzden bilgi mimarisi benim için tasarım sonrası yapılan içerik temizliği değil, sistem mimarisinin veriyle kullanıcı arasındaki katmanıdır.

7. 300.000 kitaplık ölçekte öğrendiğim şey

Bu operasyonun bana verdiği en güçlü ders, büyük bilgi sistemlerinde "doğru kategori" diye tek başına bir çıktı olmadığıydı. Doğru kategori; doğru tanım, doğru karar kuralı, tutarlı ekip uygulaması ve çalışan kalite kontrol döngüsünün sonucuydu.

Bir bilgi mimarisi projesine bugün yeniden başlasam yine şu sırayı kullanırım:

1. Girdi tiplerini ve belirsizlikleri haritala. 2. Kategori isimlerinden önce karar sınırlarını tanımla. 3. Yeni düğüm açmak için açık bir eşik koy. 4. Karar kurallarını kısa ve ortak bir kaynakta tut. 5. İnceleme ile kalite kontrolünü iş akışının içine yerleştir. 6. Tekrarlayan hatayı kayıt problemi değil sistem problemi olarak ele al. 7. Teslim kriterini "bütün kayıtlar işlendi"den daha geniş tanımla: sistem açıklanabilir ve sürdürülebilir olmalı.

1const taxonomyReady =2  clearBoundaries &&3  sharedDecisionRules &&4  reviewLoop &&5  qualityControl &&6  explainableOwnership;

Bilgi mimarisi ile sistem mimarisi aynı yerde buluşuyor

Bugün ürün ve sistem mimarisi çalışırken taksonomi deneyiminden gelen düşünme biçimini hâlâ kullanıyorum. Bir ürün modülü, veri alanı veya agent workflow'u tasarlarken sorduğum sorular şaşırtıcı biçimde benzer:

• Bu şeyin sınırı nerede başlıyor ve bitiyor?
• Kaynak doğrusu hangisi?
• Aynı kavram iki yerde tekrar mı üretiliyor?
• Belirsizlik nasıl çözülüyor?
• Kalite kişisel hafızaya mı, sisteme mi bağlı?

Bilgi mimarisi bana şunu öğretti: karmaşık bir sistemi düzenlemek, öğeleri kutulara koymak değil; kararların birbirleriyle çelişmeden tekrar edilebilmesini sağlamaktır.

Bu yüzden kendimi yalnızca ürün veya yazılım tarafında konumlandırmıyorum. Ürün, bilgi ve sistem mimarisi benim için üç ayrı disiplin değil; aynı problemin üç ölçeği: karmaşıklığı anlaşılır, sahiplenilebilir ve çalışabilir bir yapıya dönüştürmek.