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) kur. Küçük bir arayüz + config’le seçilen gerçek implementasyonlar; daha fazlası değil.

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

1. Arayüzü yetenek üzerinden tanımla, 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ırma — arayüz küçük ve yetenek-tabanlı kalsın.
2. Farkları açık timeout + ucuz fallback ile tolere et. Üretimde sağlayıcı yavaşlar veya rate-limit yer; her çağrıya net bir timeout koy ve gerektiğinde ucuz/yerel bir fallback’e düş. Bu, mimariyi tek bir sağlayıcının kapris yapmasına bağımlı olmaktan kurtarır.
3. Token bütçesini kenarda yönet. Her modelin context penceresi farklı; girdiyi modele sığacak şekilde kenarda truncate/özetle. “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 koy. İhtiyaç varsa stream desteğini opsiyonel olarak aynı kontratta tut; çağıran taraf sağlayıcının stream API’sını bilmesin.
5. Golden-prompt test seti tut. Aynı prompt setini her sağlayıcıya karşı çalıştır; çıktı kalitesi ve regresyon kıyaslamasını otomatikleştir. 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, iş mantığına dallanma olarak değil. Soyutlama dar oldukça sağlam olur.