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.

Kısa cevap

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. Laravel tarafında bu arayüzün hangi implementasyona bağlanacağını seçen mekanizma zaten elinizde — servis sağlayıcı ve container yazısında anlattığım binding tam olarak bu iş içindir.

Neden

1. Vendor’ı değil yeteneği soyutlamak arayüzü küçük tutar. complete(prompt, opts): Result gibi minik bir kontrat yeter; Ollama, Bedrock ve OpenAI bunun üç implementasyonu olur. Sağlayıcıya özel parametreleri core mantığa sızdırdığınız anda soyutlama işlevini kaybeder.

2. Farklar iş mantığında değil konfigürasyonda yaşamalı. “Lokalde küçük, üretimde büyük context penceresi” gibi ayrımlar if bloğuna dönüşürse, her yeni sağlayıcı kod tabanına yeni bir dallanma ekler.

Ne yapmalı

1. Arayüzü yetenek üzerinden tanımlayıp seçimi config’e bırakın. Hangi implementasyonun çalışacağını config/env seçsin; çağıran taraf hangi sağlayıcıyla konuştuğunu bilmesin.

2. Açık timeout + ucuz fallback koyun. Üretimde sağlayıcı yavaşlar veya rate-limit yer; her çağrıya net bir timeout verin ve gerektiğinde ucuz/yerel bir fallback’e düşün.

3. Token bütçesini kenarda yönetin. Her modelin context penceresi farklı; girdiyi modele sığacak şekilde kenarda truncate/özetleyin.

4. Streaming’i aynı kontratın arkasına koyun. İhtiyaç varsa opsiyonel olarak aynı arayüzde 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; sağlayıcı değiştirdiğinizde 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.