本番環境で自然言語APIを導入する際に安定性を確保するための必須ガイド（Microsoft Developer Community）
(techcommunity.microsoft.com)中核原則
- 自然言語APIを本番構築する際は、semantic parsing と execution の分離が必須
- LLMは自然言語 → 構造化リクエスト（canonical structured requests）への変換にのみ使用
- 自然言語は入力としてのみ扱い、API契約にしてはならない（言語は脆弱）
自然言語を直接使う問題点
- 非決定的な挙動（nondeterministic behavior）
- プロンプトベースのビジネスロジック → デバッグ・再現が困難
- 暗黙的なAPI契約 → 小さな変化で動作が変質
- サイレントフェイル（silent failures）が発生し、システムが脆弱になる
アーキテクチャ: 2段階レイヤー分離
1. Semantic Parse API（自然言語 → 構造変換）
- ユーザーテキスト入力を受け付ける
- LLMで intent・entities を抽出
- あらかじめ定義されたスキーマを完成させる
- 情報不足時は clarification の質問を行う（ビジネスロジックの実行は禁止）
- コンパイラの役割（e.g., “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8}）
2. Structured Execution API（構造 → 実行）
- 構造化入力のみ受け付ける
- 決定論的・バージョン管理可能・テスト可能
- 自然言語処理は行わず、安定したバックエンドとして機能
主要要素: Canonical Schemas
- コードで定義された intent ごとの契約（必須/任意フィールド、値の範囲、バリデーションルール）
- 自然言語の揺らぎを吸収 → 一貫した出力を保証
- API契約の backbone として機能
Schema Completion（Clarification）
- 情報不足時は “needs_clarification” を返す（missing fields, targeted question, current state）
- 状態オブジェクトでメモリ管理（API自体は stateless）
- クライアントが状態を渡しながら対話を継続 → 完成時に canonical_request を実行
オーケストレーション: LangGraph の活用
- 構造化ワークフローをモデリング（intent 分類 → entity 抽出 → schema マージ → バリデーション → 完成/Clarification ルーティング）
- コードベースで判断し、LLMは提案のみを行う
- 明確な状態遷移・可観測性・安全なリトライ
安全装置: Confidence Gates
- LLM出力に confidence score を要求
- しきい値未満なら実行をブロックし、clarification を要求（e.g., 曖昧な “the bag” → 低信頼度 → 追加質問）
- サイレントな誤解釈を防止
正規化: Lightweight Ontologies
- コードベース（許可された intent、synonym mappings、cross-field validation）
- LLMの提案値 → コードで正規化（e.g., “cheaper” → price_bias: -0.7）
- 論理的不整合時は clarification（e.g., cheap + high quality の優先順位を質問）
性能面の考慮
- レイテンシ: intent 分類 ~40ms、entity 抽出 ~200ms、検証 1ms → 合計 250300ms
- チャットUXでは許容可能で、エラーコストより安い
主な教訓（Key Takeaways）
- 言語はAPI契約ではなく、構造に変換すべき
- サーバー側が schema completion を所有すべき
- LLMは discovery・extraction のみに使い、実行には使わない
- 安全性と決定論性を最優先
- Azure OpenAI + LangGraph による実システム構築経験に基づく
まだコメントはありません。