Panduan penting untuk memastikan keandalan saat menerapkan API bahasa alami di produksi (Microsoft Developer Community)

Prinsip inti

• Saat membangun API bahasa alami untuk produksi, semantic parsing dan execution wajib dipisahkan
• LLM hanya digunakan untuk mengubah bahasa alami → permintaan terstruktur kanonis (canonical structured requests)
• Bahasa alami harus diperlakukan hanya sebagai input, bukan sebagai kontrak API (bahasa itu rapuh)

Masalah saat langsung menggunakan bahasa alami

• Perilaku non-deterministik (nondeterministic behavior)
• Logika bisnis berbasis prompt → sulit di-debug dan direproduksi
• Kontrak API implisit → perubahan kecil dapat mengubah perilaku
• Terjadi kegagalan senyap (silent failures), sistem menjadi rapuh

Arsitektur: pemisahan layer 2 tahap

1. Semantic Parse API (bahasa alami → transformasi struktur)

• Menerima input teks pengguna
• Mengekstrak intent dan entities dengan LLM
• Melengkapi skema yang telah didefinisikan sebelumnya
• Jika informasi kurang, ajukan pertanyaan klarifikasi (dilarang menjalankan logika bisnis)
• Berperan seperti compiler (mis., “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (struktur → eksekusi)

• Hanya menerima input terstruktur
• Deterministik, memiliki versioning, dan dapat diuji
• Tidak memproses bahasa alami, berperan sebagai backend yang stabil

Elemen utama: Canonical Schemas

• Kontrak per intent yang didefinisikan dalam kode (field wajib/opsional, rentang nilai, aturan validasi)
• Menyerap variasi bahasa alami → menjamin output yang konsisten
• Berperan sebagai backbone kontrak API

Schema Completion (Clarification)

• Jika informasi kurang, kembalikan respons needs_clarification (missing fields, targeted question, current state)
• Kelola memori dengan objek state (API bersifat stateless)
• Klien meneruskan state untuk menjaga percakapan → saat lengkap, jalankan canonical_request

Orkestrasi: menggunakan LangGraph

• Memodelkan workflow terstruktur (klasifikasi intent → ekstraksi entity → penggabungan skema → validasi → routing ke complete/Clarification)
• Keputusan dibuat berbasis kode, LLM hanya memberi usulan
• Transisi state jelas, dapat diamati, dan aman untuk retry

Pengaman: Confidence Gates

• Minta confidence score pada output LLM
• Jika di bawah ambang batas, blokir eksekusi dan minta klarifikasi (mis., “the bag” yang ambigu → confidence rendah → pertanyaan tambahan)
• Mencegah salah tafsir senyap

Normalisasi: Lightweight Ontologies

• Berbasis kode (intent yang diizinkan, synonym mappings, cross-field validation)
• Nilai usulan dari LLM → dinormalisasi lewat kode (mis., “cheaper” → price_bias: -0.7)
• Jika ada inkonsistensi logis, minta klarifikasi (mis., murah + kualitas tinggi → tanyakan prioritas)

Pertimbangan performa

• Latensi: klasifikasi intent ~40ms, ekstraksi entity ~200ms, validasi 1ms → total 250300ms
• Dapat diterima dalam UX chat, lebih murah daripada biaya kesalahan

Pelajaran utama (Key Takeaways)

• Bahasa bukan kontrak API, ubah ke struktur
• Penyelesaian skema harus dimiliki sisi server
• LLM hanya untuk discovery dan extraction, bukan eksekusi
• Keamanan dan determinisme adalah prioritas utama
• Berdasarkan pengalaman membangun sistem nyata dengan Azure OpenAI + LangGraph

https://aisparkup.com/posts/9012