Onlarca projenin dokümanını tek sunucudan servis etmek

Bir kodlama ajanına projenin dokümanını vermenin yolu MCP’den geçiyor. Zor olan protokol değil; onlarca projede aynı şeyi tekrar tekrar kurmak.

Proje başına sunucu, proje sayısınca bakım

İlk üç projede her birine ayrı bir MCP sunucusu kurmak makul görünüyordu. Sonra sunucular birbirinden ayrı yaşamaya başladı: hangisi hangi dizini indeksliyordu, hangisi en son ne zaman senkronlanmıştı, hangisinin kendi chunk’lama kodu vardı. Her yeni proje aynı chunker’ı, aynı embedding döngüsünü ve aynı artımlı indeksleyiciyi bir kez daha yazmak demekti — sonra da hepsini sürdürmek.

Contextator bu tekrarı tek bir kuruluma indiriyor. Bir proje, kaynaklarının toplamıdır: sunucuda bağlı bir klasör, bir git deposu (ya da onun tek bir alt dizini), yüklenmiş bir arşiv, bir Obsidian kasası veya bir Notion çalışma alanı. Hepsi tek bir uçta birleşiyor ve her kaynak kendi adının altına monte ediliyor, böylece bir doküman handbook/install.md diye okunuyor.

Yalıtım bir ayar değil, adresin kendisi

Her proje kendi URL’ini alıyor: /mcp/<proje>. /mcp/billing’e bağlı bir istemci /mcp/mobile’ı hiç görmüyor.

Bunun alternatifi tek bir uç açıp isteğe bir project parametresi koymaktı; o tasarımda yalıtım, ajanın doğru parametreyi göndermesine bağlı kalırdı. Bedeli açık ve kabul edilmiş durumda: projeler arası arama yok. Tek soruda iki projeye bakılamıyor, çünkü bakılabilseydi her arama sessizce her projeye yayılırdı.

Anahtarsız çalışması bir koşuldu

Embedding’ler varsayılan olarak makinenin CPU’sunda üretiliyor. Bunun sebebi maliyetten önce şu: sürekli sorgulanmak üzere kurulmuş bir aracın çalışması için bir API anahtarı istemesi, “kendi sunucunda çalışır” vaadini baştan bozar. Birkaç ortam değişkeniyle OpenAI embedding’lerine geçmek mümkün, ama varsayılan yol dışarıya hiç çıkmıyor.

Bedeli ilk açılışta ödeniyor: model indiriliyor ve container’ın ayağa kalkması birkaç dakika sürüyor. Sonraki başlangıçlar saniyeler sürüyor.

Vektörün temsil etmediği şey

Bir cümle modelinin HALYARD_DISPATCH_TIMEOUT diye bir şeyden haberi yok — yalnız çevresindeki kelimelerden haberi var. Dokümantasyonda aranan şeyin önemli bir kısmı ise tam olarak bu: bir sabit adı, bir hata kodu, bir bayrak.

O yüzden her chunk hem vektör hem tam metin dizininde duruyor ve bir arama iki listeyi birden alıp sıralamalarını birleştiriyor. Skorlar değil sıralamalar birleştiriliyor, çünkü skorların ağırlıklandırılması embedding modeli her değiştiğinde yeniden öğrenilmek zorunda kalırdı.

Bunun görünür bedeli şu: sonuçtaki benzerlik skoru artık o sonucun neden orada olduğunu açıklamıyor.

Ölçülüp bırakılan sınır

Diller arası arama çalışmıyor: Türkçe sorulan bir sorunun cevabı İngilizce bir sayfada duruyorsa çoğunlukla bulunmuyor. Bu bir eksik değil, kapatılmış bir karar. İki çözüm denendi: önce hibrit arama, sonra çok dilli bir yeniden sıralama modeli. İkisi de ölçüldü, ikisi de yetmedi ve sonuçlar depoda duruyor. Gerçek çözüm ikinci bir çeviri-eğitimli model, yani dört kat indirme ve her kurulumda tam yeniden indeksleme; bir doküman sunucusu için bu fiyat ödenmedi.

Kayıt bu yüzden “yapılacaklar” listesinde değil, dokümantasyonda duruyor. Ürünün künyesi portfolyoda.