Bài 5 — Khi model chọn sai tool hoặc điền sai tham số

Model sẽ chọn nhầm tool, gọi tool khi không cần, hoặc điền tham số bịa. Đây không phải bug hiếm — nó là hành vi mặc định cần được kiểm soát. Bài này gom các kỹ thuật giảm và bắt lỗi chọn tool. Điều quan trọng cần chấp nhận sớm: bạn không thể làm model không bao giờ sai; mục tiêu thực tế là giảm xác suất sai và dựng nhiều lớp lưới đỡ để một lần chọn sai không gây hậu quả nghiêm trọng.

Vì sao model chọn sai

• Tool trùng nghĩa: search_product và find_item khiến model phân vân.
• Description mơ hồ: model không biết ranh giới nên đoán.
• Quá nhiều tool: cho 30 tool, xác suất chọn nhầm tăng vọt.
• Thiếu thông tin nhưng vẫn gọi: người dùng chưa cho email, model bịa email để thỏa required.

Kỹ thuật 1 — Gọt schema (đòn bẩy lớn nhất)

Giảm sai từ gốc bằng schema tốt (nhắc lại Bài 2):

• Gộp tool trùng nghĩa làm một.
• Viết rõ khi nào KHÔNG dùng trong description.
• Dùng enum để chặn giá trị rác.

{
  "name": "cancel_order",
  "description": "Hủy MỘT đơn theo id. KHÔNG dùng để hoàn tiền (dùng refund_order) hoặc đổi địa chỉ (dùng update_order)."
}

Kỹ thuật 2 — Validate cứng trước khi thực thi

Schema chỉ là lớp một. Ở dispatcher, validate lại và từ chối nếu vô lý — trả lỗi để model sửa:

def validate_cancel(args):
    oid = args.get("order_id", "")
    if not re.fullmatch(r"ORD-\d{6}", oid):
        return "order_id phải dạng ORD-000123. Hãy hỏi lại người dùng."
    return None  # hợp lệ

Nếu người dùng chưa cung cấp order_id mà model bịa ORD-123456, việc validate + tra DB sẽ trả "không tồn tại", buộc model quay lại hỏi người dùng thay vì hành động mù.

Kỹ thuật 3 — Chống bịa tham số

Dạy model hỏi lại khi thiếu. Hai cách:

• Trong system prompt: "Nếu thiếu thông tin bắt buộc, hãy HỎI người dùng, tuyệt đối không tự đoán."
• Trong description field: "email của khách; nếu người dùng chưa cung cấp, đừng gọi tool này."

Kỹ thuật 4 — Xác nhận cho hành động nguy hiểm

Với write tool rủi ro cao, chèn bước xác nhận người-trong-vòng-lặp (human-in-the-loop):

if TOOLS[name].get("dangerous"):
    return {"needs_confirmation": True,
            "preview": f"Sắp {name} với {args}. Xác nhận?"}

Agent hiển thị preview cho người dùng; chỉ thực thi khi có "đồng ý". Đây là chốt chặn cuối khi model chọn sai một hành động phá hủy.

Kỹ thuật 5 — Quan sát và đánh giá

Log mọi tool call (tên, tham số, kết quả). Định kỳ xem lại: tool nào hay bị gọi nhầm? Đó là tín hiệu schema cần gọt. Xây một tập test nhỏ các câu hỏi và kỳ vọng tool nào được gọi, chạy lại sau mỗi lần sửa.

Khung tư duy: 4 lớp phòng thủ

1. Schema tốt     → giảm xác suất chọn sai
2. Validate cứng  → chặn tham số vô lý trước khi chạy
3. Hỏi-lại/không-đoán → chặn bịa dữ liệu
4. Xác nhận       → chặn hậu quả của hành động nguy hiểm

Checklist

• [ ] Không có hai tool trùng nghĩa.
• [ ] Mỗi tool nói rõ khi nào KHÔNG dùng.
• [ ] Dispatcher validate tham số, trả lỗi gợi ý.
• [ ] System prompt cấm bịa dữ liệu, yêu cầu hỏi lại.
• [ ] Write tool nguy hiểm có bước xác nhận.
• [ ] Có log + tập test tool-selection để đo cải thiện.

Sai lầm thường gặp

• Đổ lỗi cho model, sửa bằng prompt dài dòng trong khi gốc rễ là schema trùng nghĩa. Sửa schema trước.
• Tin tham số model đưa là đúng. Luôn validate; model bịa order_id, email, số tiền là chuyện thường.
• Không có bước xác nhận cho hành động phá hủy. Một delete_all bị gọi nhầm là không thể hoàn tác.
• Thêm tool mới mà không kiểm tra chồng lấn với tool cũ, làm model càng dễ lẫn.
• Không đo lường. Không log tool call thì bạn không biết model chọn sai ở đâu để mà sửa.