Câu hỏi phỏng vấn AI số 2: Làm thế nào để đảm bảo việc gọi công cụ của Mô hình Ngôn ngữ Lớn (LLM) là đáng tin cậy

Làm thế nào để đảm bảo Mô hình Ngôn ngữ Lớn (LLM) hoạt động đáng tin cậy và có kiểm soát khi gọi công cụ, thay vì chỉ dựa vào prompt để "thuyết phục" mô hình. Cần đưa ra một khung ràng buộc đa cấp một cách có hệ thống.

Ví dụ như truy vấn thời tiết, có ba hành vi "bịa đặt" phổ biến của mô hình khi gọi công cụ:
1. Không gọi công cụ, trực tiếp bịa ra câu trả lời.
2. Gọi công cụ với tham số sai định dạng (ví dụ: công cụ không hỗ trợ "ngày kia", nhưng lại truyền tham số date="ngày kia").
3. Tự ý chuyển đổi định dạng tham số (ví dụ: tự ý chuyển "ngày kia" thành ngày cụ thể), mặc dù công cụ không yêu cầu điều này.

Gốc rễ của vấn đề nằm ở bản chất đầu ra của mô hình là xác suất, prompt chỉ áp đặt "ràng buộc mềm" lên phân phối xác suất, chứ không phải cơ chế bắt buộc đảm bảo mô hình tuân thủ nghiêm ngặt. Trong các tình huống phức tạp, "ràng buộc mềm" này dễ bị phá vỡ.

Để giải quyết vấn đề này, cần có một giải pháp kỹ thuật đa cấp:

1. Cấp độ 1: Tối ưu hóa prompt (ràng buộc mềm)

   • Định vị là điểm khởi đầu của hệ thống ràng buộc, nhưng tuyệt đối không phải là điểm kết thúc.
   • Nên coi prompt như một "hợp đồng vận hành", giải thích rõ ràng mục đích của công cụ, loại của từng tham số, ranh giới, và liệt kê các ví dụ về giá trị không hợp lệ.
   • Nên thêm Few-shot examples, bằng cách hiển thị các mẫu "đầu vào đúng → gọi đúng", sử dụng học trong ngữ cảnh để neo hành vi của mô hình.

2. Cấp độ 2: Giới thiệu JSON Schema (ràng buộc cứng)

   • Đây là bước quan trọng từ "giảng giải" sang "đặt rào chắn".
   • Sử dụng định nghĩa có cấu trúc có thể đọc và xác thực bằng máy (JSON Schema) thay thế mô tả tham số bằng ngôn ngữ tự nhiên. Có thể định nghĩa chặt chẽ loại trường, bắt buộc hay không, phạm vi giá trị liệt kê, và có thể đặt additionalProperties: false để cấm mô hình xuất ra bất kỳ trường nào không được định nghĩa.
   • Các nền tảng API chính thống hỗ trợ ràng buộc đầu ra có cấu trúc này ngay trong giai đoạn giải mã của mô hình, ngăn chặn vi phạm định dạng từ nguồn gốc.

3. Cấp độ 3: Thiết lập vòng lặp xác thực-sửa chữa-thử lại (thực thi dự phòng)

   • Ngay cả khi có Schema, vẫn cần thực hiện xác thực cú pháp và Schema sau khi nhận đầu ra của mô hình.
   • Khi xác thực thất bại, nên thiết kế cơ chế tự động làm sạch và thử lại (có giới hạn), phản hồi thông tin lỗi cho mô hình để sửa đầu ra. Sau khi vượt quá số lần thử lại, cần có phương án giảm cấp hoặc xử lý thủ công.

4. Cấp độ kiến trúc: Phân tách trách nhiệm

   • Nên tách quyết định và thực thi, tạo thành kiến trúc ba lớp:
     • Lớp mô hình: Chỉ chịu trách nhiệm ra quyết định (xác định gọi công cụ nào, tạo tham số nào).
     • Lớp khung: Chịu trách nhiệm khung thực thi, bao gồm xác thực Schema, gọi công cụ, xử lý thử lại và tích hợp kết quả. Điều này đảm bảo lỗi của mô hình không ảnh hưởng trực tiếp đến an toàn của công cụ, và việc thay đổi công cụ cũng không cần điều chỉnh prompt thường xuyên.
     • Lớp công cụ: Triển khai năng lực nghiệp vụ cụ thể.
   • Các khung như LangChain, LlamaIndex đang thực hiện công việc này.

Hạn chế của giải pháp hiện tại: Xử lý tốt vấn đề định dạng tham số, nhưng vẫn chưa đủ bao phủ việc xác thực ngữ nghĩa tham số (ví dụ: tính tương đương giữa "Thượng Hải" và "Hộ"). Đây sẽ là thách thức kỹ thuật cần đối mặt trong tương lai.

Kết luận cốt lõi: Làm cho LLM gọi công cụ một cách đáng tin cậy, về bản chất là một vấn đề kỹ thuật phần mềm, cần thiết lập một giải pháp kỹ thuật hệ thống từ ràng buộc mềm, ràng buộc cứng, thực thi dự phòng đến thiết kế kiến trúc, chứ không chỉ đơn thuần dựa vào tối ưu hóa prompt.