İstem Kayıt Defteri (Prompt Registry): YAML, Tablo veya Servis?
- Depo içi YAML kayıt defteri dürüst ve yalındır; her şey için zaten kod incelemesi kullanan küçük ekipler için en doğrusudur.
- Veritabanı tablosu; A/B testlerini, trafik bölmeyi ve yeniden dağıtım yapmadan geri almayı destekleyen en ucuz yapıdır.
- Bağımsız bir kayıt servisi, çok sayıda yazarınız veya ağır regülasyon denetimi şartınız yoksa erken mühendislik yüküdür.
- Yanlış kayıt defteri daha az özelliği olan değil, sürtünme yarattığı için kimsenin güncellemediği kayıt defteridir.
Bir müşteri projesinde istemleri ilk kez sürüm kontrolüne aldığımızda, ekibin dört servise dağılmış 38 canlı istemi vardı. Bunların 12’si kopyaydı, 6’sı eskimişti ve 3’ü sağlayıcının sekiz ay önce kullanımdan kaldırdığı bir modeli çağırıyordu. Ekibin bir istem kayıt defteri yoktu; tesadüfen çalışan bir istem karmaşası vardı.
Canlıda çalışan üç kayıt defteri şekli vardır ve her biri farklı bir ölçekte parlar:
1. Depoda YAML Dosyası ve 2. Veritabanı Tablosu
10 mühendisin ve 20 istemin altındaki ekipler için en dürüst seçim prompts/*.yaml dosyalarıdır. Sürüm geçmişi git log, inceleme PR, geri alma ise git revert ile yapılır. İstem şemasında id, version, owner, model, temperature, text ve eval.passing_threshold yer alır. Bu yapı iki durumda tıkanır: aynı anda birden fazla A/B testi yapılmaya başlandığında ve mühendis olmayan ürün yöneticileri istem metinlerini düzenlemek istediğinde.
İstem sayısı 30’u geçtiğinde, haftalık A/B testleri başladığında veya ürün ekibi sürece girdiğinde tek bir Postgres tablosuna (prompts(id, version, text, model, status, traffic_split)) geçeriz. Yeni sürüm bir INSERT, geri alma ise yeniden dağıtım gerektirmeyen bir UPDATE işlemidir. Yanına sunucu taraflı basit bir yönetim sayfası eklemek mühendisleri “istem editörü” olmaktan kurtarır.
3. İç Servis ve Doğru Seçim Kriterleri
50’den fazla mühendisin olduğu, istem sayısının 100’ü aştığı veya sağlık, finans ve EU AI Act yüksek risk kategorisi gibi sıkı denetim izi (kim, ne zaman, kimin onayıyla değiştirdi) gerektiren ortamlarda tablonun önüne yetkilendirme ve onay akışı olan bir HTTP servisi (veya Langfuse gibi hazır bir ürün) konur.
Unutulmaması gereken nokta şudur: kayıt defteri yalnızca bir depolama ve inceleme katmanıdır; kendi başına eval çalıştırmaz ve kötü bir istemi iyi yapmaz. İstem veri şemasını (id, version, text, model, owner) ilk günden sabit tutarsanız, ileride YAML’dan tabloya veya servise geçmek yalnızca bir taşıma katmanı değişikliği olur.
Sıkça sorulan sorular
YAML tabanlı bir kayıt defteriyle A/B testi yapılabilir mi?
Evet ama operasyonel yükü fazladır. İki ayrı dosya ve bir özellik bayrağı gerekir. Aynı anda bir veya ikiden fazla A/B testi yürütüyorsanız `traffic_split` sütunu olan bir veritabanı tablosuna geçmek çok daha temizdir.
Kayıt defteri kullanmak istem geliştirme hızını yavaşlatır mı?
İlk üç istemden sonra tam tersine hızlandırır. Onuncu isteme geldiğinizde ekip saniyeler içinde sürüm değiştirip yeniden dağıtım (deploy) yapmadan eski sürüme dönebilir hale gelir.
Hazır barındırılan (hosted) bir prompt registry ürünü kullanmaya değer mi?
Langfuse veya Helicone gibi araçlar eval paketinizle ve erişim kontrolünüzle entegre oluyorsa değerlidir. Ancak henüz on isteminiz bile yokken sizi ağır bir SaaS sözleşmesine zorluyorsa kaçının; markadan çok mimari şekil önemlidir.