Cevaplar için teşekkürler, hepsi kıymetli. Konuyu açarken kendi tarafımı yazmamıştım, onu da ekleyeyim; benzer işi yapacaklara faydası olur.

Kurumsal bir ERP/üretim ortamında iki agent üzerinde çalışıyorum: biri veri sohbeti (kullanıcı Türkçe soruyor, arkada sorgu üretilip çalıştırılıyor, sonuç yorumlanıyor), diğeri planlama tarafında emniyet stoğu ve min lot önerisi üreten bir agent. Geldiğim yerler şöyle:

1) Local tercihinin sebebi maliyet değil, veri. Üretim ve maliyet verisi dışarı çıkamıyorsa local zaten bir zorunluluk. Bu kısıt yoksa fiyat/performansta bulut API'yi geçmek gerçekten zor — @Nebulous; ve @tosunpasa; bu konuda haklı.

2) En büyük kazanç, modele iş yaptırmayı bırakmak oldu. Başta "sorguyu sen yaz" mantığındaydı; küçük modellerde join'ler ve tarih filtreleri sürekli kayıyordu. Şu anki kurgu: matematik ve kritik karar mekanizmaları tamamen uygulama tarafında, sorgular parametreli ve hazır; modele sadece "şu çıktıyı yorumla", "şu sapmayı açıkla", "şu niyeti şu fonksiyona eşle" diyorum. Doğruluk kıyaslanamayacak kadar arttı.

3) Tool/function calling tarafında küçük modellerin zayıf noktası çok adımlı zincir. Tek turda tek tool çağırıp sonucu tekrar modele veriyorum, adım sayısını da sınırlıyorum. Ayrıca tool seçimini tamamen modele bırakmak yerine önüne deterministik bir niyet sınıflandırıcı koydum; "hangi aracı çağırayım" kararı modele kalınca hata oranı ciddi artıyor.

4) Şema bilgisini prompt'a doldurmak yerine vektör veritabanında tutuyorum (Qdrant + embedding). Tablo/kolon açıklamaları RAG ile geliyor, context şişmiyor. Uygulama .NET, orkestrasyon Semantic Kernel, model tarafı Ollama — model değiştirmek tek ayar olsun diye o katmanı soyutladım, bu iyi bir karardı.

5) Doğruluk ölçümü olmadan bu iş yürümüyor. Agent'ın her önerisi bir onay ekranına düşüyor; kullanıcı reddederse red sebebini de alıyorum. "İyi çalışıyor mu" sorusunun tek dürüst cevabı zamanla oluşan o tablo oluyor, his değil.

6) Maliyet tarafında somut bir veri: aynı işi bulut API ile yaptırdığımızda çalışma başına ~1 USD seviyesindeyiz. Local'de bu maliyet sabit donanıma dönüyor. Yani günlük çalışma sayınızı koyup break-even'ı hesaplamadan karar vermeyin; çoğu senaryoda API daha ucuz çıkıyor.

7) @tosunpasa; 'nın çapraz doğrulama önerisi bende de karşılık buldu. Üreten ile denetleyenin aynı model ve aynı context olmaması, hata yakalama oranını gözle görülür artırıyor.

Özetle çıkarımım: local LLM'i "her şeyi yapan beyin" olarak değil, dar ve iyi tanımlanmış bir işi yapan bir bileşen olarak konumlandırınca 7-8B seviyesi bile üretimde işe yarıyor. Muhakemenin ağır bastığı yerde ise hâlâ büyük modeller lazım.

Deneyen arkadaşlar sonuçlarını da yazarsa karşılaştırmak isterim.