Bir LLM'i kurumsal uygulamaya bağlamak, bir API anahtarı yapıştırmak değil. Doğru desen, doğru context, doğru kontrol noktaları — ve "model halüsinasyon yaparsa ne olur?" sorusuna her seviyede cevap. Bu yazıda, IBP'de gerçek projelerde uyguladığımız desenleri ve kaçındıklarımızı paylaşıyoruz.

Üretim ortamına LLM entegre etmiş bir ekibin değiştiği üç şey vardır: nasıl test ettikleri, nasıl bütçelendirdikleri ve hata mesajlarına bakış açıları. Bu üçü de klasik yazılımdan farklıdır. Önce neden farklı, sonra nasıl başa çıkıyoruz — onu konuşalım.

Önce: LLM neden klasik bir API değil?

Bir REST endpoint çağırırsanız, aynı input için (genelde) aynı output gelir. LLM öyle değil:

  • Stokastik: Aynı prompt'a iki kez farklı cevap verebilir.
  • Sınırlı bağlam: Modelin gördüğü token sayısı sınırlı; sistemin geri kalanından bağımsız değil.
  • Eğitim tarihinden sonrasını bilmiyor: Kendi başına güncel veriden habersiz.
  • Kendinden emin yanlışlar üretebilir: "Bilmiyorum" cevabı modelden nadiren gelir — uydurma daha sık.

Bu özellikler bug değil, modelin doğası. Mühendislik işi de tam bu noktada başlıyor: bu özellikler etrafında deterministik bir sistem inşa etmek.

Üç temel desen: RAG, function calling, agentic flow

1. RAG — Retrieval-Augmented Generation

Modele yalnızca soruyu değil, soruyla ilgili veriyi de göndermek. Klasik kullanım: kurumsal döküman üzerinde Q&A, müşteri destek bot'u, içerik özetleme. 

// Basit RAG akışı
const embedding = await embed(userQuery);
const docs = await vectorDb.search(embedding, { topK: 5 });

const prompt = `
Aşağıdaki belgelere DAYANARAK cevap ver.
Bilgi yetersizse "bilmiyorum" de.

Belgeler:
${docs.map(d => d.text).join('\n---\n')}

Soru: ${userQuery}
`;

const answer = await llm.complete(prompt);

Basit gibi görünür ama üretimde işin %80'i şurada: chunking stratejisi (dökümanı nasıl parçalıyorsun), re-ranking (vector skoruna göre sıralanan ilk 5 gerçekten en alakalı mı), ve "bilgi yok" halinde modelin uyumu (rule'lara rağmen uydurma riski).

2. Function calling — modeli sisteminize bağlamak

Modele "şu fonksiyonları çağırabilirsin" demek. Model, soruya göre hangi fonksiyonu hangi parametreyle çağıracağına karar verir; sizin sisteminiz fonksiyonu çalıştırır ve sonucu modele geri besler.

Kullanım: kullanıcı "geçen haftaki siparişlerimi göster" dediğinde, model getOrders(user, range)'ı doğru argümanlarla çağırır. Doğal dil → yapılandırılmış aksiyon dönüşümü için en sağlam yol bu.

Pratik not: Fonksiyonun JSON Schema tanımını ne kadar net yazarsanız, modelin "uydurma argüman" üretme olasılığı o kadar azalır. description alanını boş geçmeyin — modelin tek rehberi orası.

3. Agentic flow — çok adımlı görevler

Modelin tek bir cevap üretmesi yerine, "düşün → araç kullan → gözle → tekrar düşün" döngüsüne girmesi. Karmaşık görevlerde (örn. "şu raporu derle, çelişkili veri varsa kaynaklara dön") tek-prompt yetmez.

Agentic akışın dikkat noktası: budget. Bir ajan teoride sonsuz tool çağrısı yapabilir. Üretimde maksimum step sayısı, maksimum token, maksimum süre — üçü de cap'lenmeli.

Kurumsal entegrasyonun gerçek zorlukları

Veri güvenliği

En çok aldığımız soru: "verimiz modele gidiyor mu?" Cevap senaryoya göre değişir:

  • Public API (OpenAI / Anthropic vb.): Veri sağlayıcıya gider; çoğu sağlayıcı "default olarak eğitimde kullanılmaz" politikası sunar. Yine de hassas veri (PII, sağlık, finansal) için ek kontroller şart.
  • Azure / AWS Bedrock üzerinden private deployment: Veri kendi tenant'ınızda kalır. Çoğu kurumsal proje için makul orta yol.
  • Self-hosted (Llama, Mistral, vs.): Veri hiç çıkmaz. Maliyet ve gecikme tarafında ödün vermek gerek.

Halüsinasyon yönetimi

Modelin yanlış bilgi üretmesine karşı tek bir çözüm yok; katmanlı savunma var:

  1. Grounding: Model yalnızca verilen bağlamdan cevaplasın (RAG, system prompt sıkı kuralları).
  2. Citation zorunluluğu: Cevabın her iddiası, kaynak ID'sine bağlansın.
  3. Validation: Çıktı yapısal mı (JSON Schema), sayılar tutarlı mı (kod ile doğrula).
  4. Insan-in-the-loop: Kritik kararlar için onay adımı.

Maliyet ve gecikme

Token başına ücretlendirme, ölçek arttıkça hızla görünür hale gelir. İki taktik:

  • Cascading models: Basit soruya küçük/ucuz model, karmaşığa büyük model. Router tabanlı seçim, maliyeti dörtte üçe kadar düşürebilir.
  • Prompt caching: Statik bağlam (sistem prompt, doc'lar) cache'lenince, sonraki istekler hem ucuzlar hem hızlanır.
LLM entegrasyonunda en pahalı hata, MVP'de doğru çalışan ama 1000 kullanıcıda iflas eden bir maliyet eğrisi yaratmaktır. Bütçe limitleri, monitoring ve fallback — gün-1 düşünülmeli.

Test ve monitoring — yeni dünya

Stokastik bir sistemin testi, klasik unit test değil. Bizim kullandığımız yaklaşımlar:

  • Eval set: 100-500 örnek input-expected pair. Her model/prompt değişiminde otomatik koşar. Skor takibi.
  • LLM-as-judge: Çıktının kalitesini başka bir LLM değerlendirir. %100 güvenilir değil ama trend görmek için iyi.
  • Production sampling: Canlı trafiğin %1-2'si örneklenip insan tarafından gözden geçirilir.
  • Cost & latency dashboard: Token/dolar/p99 üçlüsü her zaman görünür olmalı.

Hangi senaryoda LLM, hangi senaryoda klasik?

LLM çekici bir araç ama her probleme uymaz. Hızlı bir filtre:

  • İyi uyum: Doğal dil → aksiyon dönüşümü, özetleme, sınıflandırma, semantik arama, yaratıcı içerik, yapılandırılmamış veriden bilgi çıkarımı.
  • Kötü uyum: Deterministik sayısal hesaplar, kritik karar verme (insan onayı olmadan), kesin doğruluk gerektiren kompozisyon (hukuk metni vb.).

Sonuç

LLM'i bir uygulamaya bağlamanın teknik kısmı yarım gün; üretime hazır bir sistem inşa etmenin gerçek işi tasarım kararlarında ve kontrol mekanizmalarında. RAG'i kurmak kolay, doğru chunk stratejisi haftalar; function calling'i bağlamak kolay, schema'yı titiz yazmak iterasyonla olur.

İyi haber: bu desenler 2024'ten beri çok olgunlaştı. 2026'da işin teorisi değil disiplini önemli. Bizim için bu, IBP'nin geri kalan mühendislik prensiplerinden farklı değil — sadece konu yeni.