Prodüksiyonda doğal dil API’leri kullanırken güvenilirliği sağlamak için temel rehber (Microsoft Developer Community)

Temel ilkeler

• Doğal dil API’lerini prodüksiyonda kurarken semantic parsing ile execution katmanlarının ayrılması şart
• LLM yalnızca doğal dil → yapılandırılmış istekler (canonical structured requests) dönüşümü için kullanılmalı
• Doğal dil yalnızca girdi olarak ele alınmalı, API sözleşmesi haline getirilmemeli (dil kırılgandır)

Doğal dili doğrudan kullanmanın sorunları

• Belirlenimci olmayan davranış (nondeterministic behavior)
• Prompt tabanlı iş mantığı → hata ayıklama ve yeniden üretim zor
• Örtük API sözleşmesi → küçük değişikliklerle davranışın değişmesi
• Sessiz hatalar (silent failures) oluşur, sistem kırılgan hale gelir

Mimari: 2 aşamalı katman ayrımı

1. Semantic Parse API (doğal dil → yapı dönüşümü)

• Kullanıcının metin girdisini kabul eder
• LLM ile intent ve entity’leri çıkarır
• Önceden tanımlanmış şemayı tamamlar
• Bilgi eksikse clarification sorusu sorar (iş mantığı çalıştırmak yasak)
• Derleyici rolü üstlenir (ör. “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (yapı → yürütme)

• Yalnızca yapılandırılmış girdileri kabul eder
• Deterministik, sürüm kontrollü ve test edilebilir
• Doğal dil işlemez, kararlı backend rolü görür

Ana bileşen: Canonical Schemas

• Kodla tanımlanmış, her intent için sözleşmeler (zorunlu/isteğe bağlı alanlar, değer aralıkları, doğrulama kuralları)
• Doğal dil varyasyonlarını emer → tutarlı çıktı garantiler
• API sözleşmesinin backbone’u olarak görev yapar

Schema Completion (Clarification)

• Bilgi eksikse “needs_clarification” yanıtı döner (eksik alanlar, hedefli soru, mevcut durum)
• Bellek, durum nesnesi ile yönetilir (API stateless’tir)
• İstemci durumu taşıyarak diyaloğu sürdürür → tamamlandığında canonical_request çalıştırılır

Orkestrasyon: LangGraph kullanımı

• Yapılandırılmış iş akışlarını modeller (intent sınıflandırma → entity çıkarımı → şema birleştirme → doğrulama → tamamlama/Clarification yönlendirmesi)
• Kararlar kod tabanlıdır, LLM yalnızca öneri sunar
• Net durum geçişleri, gözlemlenebilirlik ve güvenli yeniden denemeler

Güvenlik önlemi: Confidence Gates

• LLM çıktısı için confidence score istenir
• Eşik altındaysa yürütme engellenir, clarification istenir (ör. belirsiz “the bag” → düşük güven → ek soru)
• Sessiz yanlış yorumlamayı önler

Normalizasyon: Lightweight Ontologies

• Kod tabanlıdır (izin verilen intent’ler, synonym mappings, alanlar arası doğrulama)
• LLM’in önerdiği değerler kodla normalize edilir (ör. “cheaper” → price_bias: -0.7)
• Mantıksal tutarsızlık varsa clarification istenir (ör. ucuz + yüksek kalite için öncelik sorusu)

Performans değerlendirmesi

• Gecikme: intent sınıflandırma ~40ms, entity çıkarımı ~200ms, doğrulama 1ms → toplam 250300ms
• Chat UX içinde kabul edilebilir, hata maliyetinden daha ucuz

Başlıca dersler (Key Takeaways)

• Dil bir API sözleşmesi değildir, yapıya dönüştürülmelidir
• Sunucu tarafı schema completion’ın sahibi olmalıdır
• LLM yalnızca discovery ve extraction için kullanılmalı, execution için değil
• Güvenlik ve determinizm en yüksek önceliktir
• Azure OpenAI + LangGraph ile gerçek sistem kurma deneyimine dayanır

https://aisparkup.com/posts/9012