Hướng dẫn thiết yếu để đảm bảo độ ổn định khi triển khai Natural Language API trong production (Microsoft Developer Community)

Nguyên tắc cốt lõi

• Khi xây dựng Natural Language API cho production, bắt buộc phải tách riêng semantic parsing và execution
• Chỉ dùng LLM cho việc chuyển đổi ngôn ngữ tự nhiên → yêu cầu có cấu trúc chuẩn hóa (canonical structured requests)
• Chỉ xem ngôn ngữ tự nhiên là đầu vào, không dùng làm hợp đồng API (ngôn ngữ rất mong manh)

Vấn đề khi dùng trực tiếp ngôn ngữ tự nhiên

• Hành vi không xác định (nondeterministic behavior)
• Logic nghiệp vụ dựa trên prompt → khó debug và tái hiện
• Hợp đồng API ngầm định → thay đổi nhỏ cũng làm biến đổi hành vi
• Dễ phát sinh lỗi im lặng (silent failures), khiến hệ thống mong manh

Kiến trúc: tách thành 2 lớp

1. Semantic Parse API (ngôn ngữ tự nhiên → chuyển thành cấu trúc)

• Nhận đầu vào là văn bản người dùng
• Dùng LLM để trích xuất intent và entities
• Hoàn thiện schema được định nghĩa sẵn
• Khi thiếu thông tin thì đặt câu hỏi làm rõ (không được thực thi logic nghiệp vụ)
• Đóng vai trò như trình biên dịch (ví dụ: “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (cấu trúc → thực thi)

• Chỉ nhận đầu vào đã được cấu trúc hóa
• Có tính quyết định, quản lý phiên bản được, kiểm thử được
• Không xử lý ngôn ngữ tự nhiên, đóng vai trò backend ổn định

Thành phần chính: Canonical Schemas

• Hợp đồng cho từng intent được định nghĩa bằng code (trường bắt buộc/tùy chọn, phạm vi giá trị, quy tắc hợp lệ)
• Hấp thụ các biến thể ngôn ngữ tự nhiên → bảo đảm đầu ra nhất quán
• Đóng vai trò xương sống của hợp đồng API

Schema Completion (Clarification)

• Khi thiếu thông tin thì trả về “needs_clarification” (các trường còn thiếu, câu hỏi mục tiêu, trạng thái hiện tại)
• Quản lý bộ nhớ bằng đối tượng trạng thái (API là stateless)
• Client truyền trạng thái để duy trì hội thoại → khi hoàn tất thì thực thi canonical_request

Điều phối: dùng LangGraph

• Mô hình hóa workflow có cấu trúc (phân loại intent → trích xuất entity → hợp nhất schema → kiểm tra hợp lệ → định tuyến hoàn tất/Clarification)
• Quyết định dựa trên code, LLM chỉ đưa ra đề xuất
• Chuyển trạng thái rõ ràng, dễ quan sát, retry an toàn

Cơ chế an toàn: Confidence Gates

• Yêu cầu confidence score cho đầu ra của LLM
• Nếu không đạt ngưỡng thì chặn thực thi và yêu cầu làm rõ (ví dụ: “the bag” mơ hồ → độ tin cậy thấp → hỏi thêm)
• Ngăn chặn việc diễn giải sai trong im lặng

Chuẩn hóa: Lightweight Ontologies

• Dựa trên code (intent được cho phép, synonym mappings, cross-field validation)
• Giá trị do LLM đề xuất → được chuẩn hóa bằng code (ví dụ: “cheaper” → price_bias: -0.7)
• Nếu logic không nhất quán thì yêu cầu làm rõ (ví dụ: ưu tiên giá rẻ + chất lượng cao thì cần hỏi thứ tự ưu tiên)

Cân nhắc về hiệu năng

• Độ trễ: phân loại intent ~40ms, trích xuất entity ~200ms, kiểm tra hợp lệ 1ms → tổng 250300ms
• Chấp nhận được trong UX chat, rẻ hơn chi phí do lỗi gây ra

Bài học chính (Key Takeaways)

• Ngôn ngữ không phải hợp đồng API, hãy chuyển sang cấu trúc
• Phía server phải sở hữu việc hoàn thiện schema
• LLM chỉ dùng cho discovery và extraction, không dùng để thực thi
• Ưu tiên hàng đầu là an toàn và tính quyết định
• Dựa trên kinh nghiệm xây dựng hệ thống thực tế với Azure OpenAI + LangGraph

https://aisparkup.com/posts/9012