Thiết Kế Giao Diện Tool

Những điều bạn cần biết

Mô tả tool là cơ chế CHÍNH mà các LLM dùng để lựa chọn tool. Đây không phải là metadata phụ trợ. Đây không phải là một thứ nghĩ thêm sau. Đây LÀ cơ chế. Khi một model nhận được một tập hợp các tool, nó đọc các mô tả để quyết định gọi tool nào. Nếu các mô tả đó tối giản — kiểu như "Truy xuất thông tin khách hàng" — model thiếu ngữ cảnh để phân biệt giữa các tool có mục đích chồng chéo nhau.

Điều Gì Tạo Nên Một Mô Tả Tool Tốt

Một mô tả tool đạt chuẩn production bao gồm năm yếu tố:

1. Tool làm gì — mục đích chính của nó, được nêu rõ ràng không mập mờ
2. Tool kỳ vọng đầu vào gì — kiểu dữ liệu, định dạng, ràng buộc, và trường bắt buộc so với trường tùy chọn
3. Các truy vấn ví dụ mà tool xử lý tốt — các trường hợp sử dụng cụ thể giúp neo giữ sự hiểu biết của model
4. Trường hợp biên và giới hạn — những gì tool KHÔNG làm, và điều gì xảy ra khi đầu vào nằm ngoài phạm vi kỳ vọng
5. Ranh giới rõ ràng — khi nào dùng tool NÀY so với các tool tương tự trong cùng bộ công cụ

Đây là sự khác biệt giữa một mô tả tối giản và một mô tả đạt chuẩn production:

Tối giản (gây định tuyến sai):

get_customer: "Truy xuất thông tin khách hàng" lookup_order: "Truy xuất chi tiết đơn hàng"

Đạt chuẩn production (lựa chọn đáng tin cậy):

get_customer: "Tra cứu tài khoản khách hàng theo địa chỉ email, số điện thoại, hoặc customer ID. Trả về hồ sơ khách hàng (tên, chi tiết liên hệ, trạng thái tài khoản, hạng thành viên). Dùng cái này khi bạn cần xác minh khách hàng là ai. KHÔNG dùng cho các truy vấn liên quan đến đơn hàng cụ thể — hãy dùng lookup_order cho việc đó."

lookup_order: "Truy xuất chi tiết đơn hàng theo số đơn hàng (định dạng: #NNNNN) hoặc mã theo dõi. Trả về trạng thái đơn hàng, mặt hàng, chi tiết giao hàng, và điều kiện hoàn tiền. Dùng cái này khi khách hàng hỏi về một đơn hàng cụ thể. KHÔNG dùng để xác minh danh tính khách hàng — hãy dùng get_customer cho việc đó."

Phiên bản thứ hai cho model sự phân biệt rõ ràng. Nó biết mỗi tool chấp nhận định danh nào, mỗi tool trả về gì, và quan trọng nhất, khi nào KHÔNG nên dùng mỗi tool.

Vấn Đề Định Tuyến Sai

Hai tool có mô tả chồng chéo hoặc gần giống hệt nhau gây ra sự nhầm lẫn trong lựa chọn. Câu Q2 của kỳ thi trình bày chính xác kịch bản này: get_customer và lookup_order với mô tả tối giản, khiến agent định tuyến "kiểm tra đơn hàng #12345 của tôi" đến sai tool.

Kỳ thi kiểm tra khả năng của bạn trong việc xác định cách khắc phục đúng. Có bốn lựa chọn khả thi, và ba trong số đó là sai:

• Mở rộng mô tả — đúng. Nỗ lực thấp, hiệu quả cao, giải quyết trực tiếp nguyên nhân gốc rễ.
• Ví dụ few-shot — sai. Thêm chi phí token mà không khắc phục lý do model bị nhầm lẫn. Bạn đang điều trị triệu chứng, không phải căn bệnh.
• Bộ phân loại định tuyến (routing classifier) — sai. Bị over-engineer khi làm bước đầu tiên. Bỏ qua khả năng hiểu ngôn ngữ tự nhiên của LLM và thêm độ phức tạp hạ tầng.
• Hợp nhất tool — sai khi là bước đầu tiên. Đây là một lựa chọn kiến trúc hợp lệ về lâu dài, nhưng đòi hỏi nỗ lực đáng kể hơn nhiều so với việc mở rộng mô tả.

Kỳ thi luôn ưu tiên các cách khắc phục nỗ lực thấp, hiệu quả cao. Mô tả tốt hơn trước khi dùng bộ phân loại định tuyến. Quyền truy cập có phạm vi trước khi cấp toàn quyền truy cập. Server cộng đồng trước khi tự xây dựng.

Tách Tool

Các tool đa năng với trách nhiệm rộng tạo ra sự mập mờ. Cách khắc phục là tách chúng thành các tool chuyên biệt theo mục đích, với hợp đồng đầu vào/đầu ra rõ ràng.

Trước khi tách:

analyze_document: "Phân tích một tài liệu và trả về kết quả"

Sau khi tách:

extract_data_points: "Trích xuất các trường dữ liệu có cấu trúc (ngày tháng, số tiền, tên) từ một tài liệu"

summarize_content: "Tạo ra một bản tóm tắt ngắn gọn về các luận điểm và kết luận chính của tài liệu"

verify_claim_against_source: "Kiểm tra xem một tuyên bố cụ thể có được hỗ trợ bởi tài liệu nguồn hay không, trả về bằng chứng ủng hộ/mâu thuẫn"

Mỗi tool kết quả có một mục đích hẹp, được mô tả rõ ràng. Model có thể chọn đúng tool dựa trên nhu cầu thực sự của người dùng.

Đổi Tên Tool Để Rõ Ràng Hơn

Khi hai tool có tên gây nhầm lẫn tương tự nhau, việc đổi tên loại bỏ sự chồng chéo về chức năng ở cấp độ giao diện. Ví dụ, đổi tên analyze_content thành extract_web_results với một mô tả chuyên biệt cho web làm cho mục đích của tool trở nên rõ ràng mà không cần thay đổi cách triển khai của nó.

Tương Tác Với System Prompt

Các chỉ thị nhạy cảm với từ khóa trong system prompt có thể tạo ra các liên kết tool ngoài ý muốn, ghi đè lên các mô tả được viết tốt. Nếu system prompt của bạn nói "luôn kiểm tra thông tin khách hàng trước khi tiếp tục", model có thể liên kết bất kỳ truy vấn nào liên quan đến khách hàng với get_customer bất kể mô tả tool nói gì.

Luôn xem lại system prompt để phát hiện xung đột sau khi cập nhật mô tả tool. Đây là một mẫu lỗi tinh vi mà kỳ thi kiểm tra.

Bẫy thi

Tình huống luyện tập

Không tìm thấy câu hỏi luyện tập "q-2-1-001".

Bài tập thực hành

Nguồn tham khảo

• Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.1 — Anthropic
• Tool use — Anthropic API Documentation — Anthropic
• Model Context Protocol Specification — Tools — Model Context Protocol