LLM sağlayıcısını (Ollama → Bedrock/OpenAI) nasıl soyutlamalıyım?

Kısa cevap: Sağlayıcının etrafına değil, yeteneğin etrafına dar bir port/adapter (Strategy) kurun. Küçük bir arayüz + config’le seçilen gerçek implementasyonlar; daha fazlası değil.

Sizin asıl tehlikeniz aşırı soyutlama: insanlar bunu jenerik bir “AI framework”e çevirmeye çalışıp aylarını yiyor. İhtiyacınız olan tek bir ince arayüz.

1. Arayüzü yetenek üzerinden tanımlayın, vendor üzerinden değil. complete(prompt, opts): Result gibi minik bir kontrat yeter. Ollama, Bedrock ve OpenAI bunun üç implementasyonu olur; hangisinin çalışacağını config/env seçer. Sağlayıcıya özel parametreleri core mantığa sızdırmayın — arayüz küçük ve yetenek-tabanlı kalsın.
2. Farkları açık timeout + ucuz fallback ile tolere edin. Üretimde sağlayıcı yavaşlar veya rate-limit yer; her çağrıya net bir timeout koyun ve gerektiğinde ucuz/yerel bir fallback’e düşün. Bu, mimariyi tek bir sağlayıcının kapris yapmasına bağımlı olmaktan kurtarır.
3. Token bütçesini kenarda yönetin. Her modelin context penceresi farklı; girdiyi modele sığacak şekilde kenarda truncate/özetleyin. “Lokalde küçük, üretimde büyük pencere” gibi farklar iş mantığında if olmamalı — config olmalı.
4. Streaming’i aynı arayüzün arkasına koyun. İhtiyaç varsa stream desteğini opsiyonel olarak aynı kontratta tutun; çağıran taraf sağlayıcının stream API’sını bilmesin.
5. Golden-prompt test seti tutun. Aynı prompt setini her sağlayıcıya karşı çalıştırın; çıktı kalitesi ve regresyon kıyaslamasını otomatikleştirin. Sağlayıcı değiştirdiğinde neyin bozulduğunu bu yakalar.

Sonuç: Ben olsam tek bir küçük arayüz, üç gerçek implementasyon ve config-tabanlı seçim kurardım — fazlası YAGNI. Yerel Ollama dev maliyeti ve hızlı iterasyon içindir; üretimdeki context penceresi, gecikme, rate-limit ve maliyet farklarını konfigürasyon olarak ele alın, iş mantığına dallanma olarak değil. Soyutlama dar oldukça sağlam olur.