Production Natural Language API अपनाते समय स्थिरता सुनिश्चित करने के लिए अनिवार्य गाइड (Microsoft Developer Community)

मुख्य सिद्धांत

• Natural Language API को production में बनाते समय semantic parsing और execution को अलग करना अनिवार्य है
• LLM का उपयोग केवल natural language → structured request (canonical structured requests) में बदलने के लिए करें
• Natural language को सिर्फ input की तरह लें, उसे API contract न बनाएं (भाषा नाज़ुक होती है)

Natural language को सीधे उपयोग करने की समस्याएँ

• nondeterministic behavior
• prompt-आधारित business logic → debugging और reproduction कठिन
• implicit API contract → छोटे बदलाव से behavior बदल सकता है
• silent failures होती हैं, जिससे system नाज़ुक बनता है

आर्किटेक्चर: 2-स्तरीय layer separation

1. Semantic Parse API (natural language → structured conversion)

• user text input स्वीकार करता है
• LLM से intent और entities extract करता है
• pre-defined schema को पूरा करता है
• जानकारी कम होने पर clarification question पूछता है (business logic execute नहीं करना)
• compiler की भूमिका (e.g., “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (structure → execution)

• केवल structured input स्वीकार करता है
• deterministic, version-controlled, और testable
• natural language processing नहीं, stable backend की भूमिका

मुख्य तत्व: Canonical Schemas

• code में परिभाषित intent-विशिष्ट contract (required/optional fields, value range, validation rules)
• natural language की विविधता को absorb करके consistent output सुनिश्चित करता है
• API contract की backbone की भूमिका

Schema Completion (Clarification)

• जानकारी कम होने पर needs_clarification response (missing fields, targeted question, current state)
• state object से memory management (API stateless रहता है)
• client state भेजते हुए conversation बनाए रखता है → पूरा होने पर canonical_request execute होता है

Orchestration: LangGraph का उपयोग

• structured workflow modeling (intent classification → entity extraction → schema merge → validation → completion/clarification routing)
• निर्णय code-आधारित, LLM सिर्फ suggestion देता है
• स्पष्ट state transition, observability, और safe retry

सुरक्षा उपाय: Confidence Gates

• LLM output में confidence score अनिवार्य करें
• threshold से कम होने पर execution रोकें और clarification माँगें (e.g., अस्पष्ट “the bag” → low confidence → अतिरिक्त प्रश्न)
• silent misinterpretation को रोकता है

Normalization: Lightweight Ontologies

• code-आधारित (allowed intents, synonym mappings, cross-field validation)
• LLM के सुझाए गए values → code से normalize करें (e.g., “cheaper” → price_bias: -0.7)
• logic mismatch होने पर clarification (e.g., cheap + high quality के बीच प्राथमिकता पूछना)

Performance considerations

• latency: intent classification ~40ms, entity extraction ~200ms, validation 1ms → कुल 250300ms
• chat UX में स्वीकार्य, और error cost से सस्ता

मुख्य सीख (Key Takeaways)

• भाषा API contract नहीं है, उसे structure में बदलें
• server-side schema completion का ownership रखें
• LLM केवल discovery और extraction के लिए, execution के लिए नहीं
• safety और determinism सर्वोच्च प्राथमिकता हैं
• Azure OpenAI + LangGraph के साथ वास्तविक system building अनुभव पर आधारित

https://aisparkup.com/posts/9012