Agent chọn sai tool: cắt 200 xuống 5 bằng vector search

Agent của bạn liên tục chọn sai action, bạn sửa prompt ba vòng và kết quả không khá hơn. Trước khi sửa vòng thứ tư, hãy log xem mỗi request thực sự gửi lên model bao nhiêu tool definition. Một case study vừa công bố cho thấy con số đó — chứ không phải prompt — mới là thứ cần sửa, và cách sửa là coi tool như document trong RAG.

Con số bị bỏ qua

Tác giả nhận một ticket đúng một câu: làm agent bớt trả lời sai. Thay vì sửa prompt, anh log lại payload gửi đi mỗi lần gọi model và phát hiện mỗi call mang theo khoảng 200 tool definition.

Theo phân tích trong bài, con số đó giải thích cả hai triệu chứng. Về chất lượng: "The model wasn't bad at reasoning. It was choosing from a menu that was far too long, full of noises." Về chi phí: phần lớn mỗi request bị tiêu vào việc gửi lại cùng một danh sách tool, bất kể câu hỏi có cần đến chúng hay không.

Tối ưu sai chỗ: lazy-load metadata

Thử nghiệm đầu tiên là đưa chi tiết tool vào database, agent chỉ fetch metadata cho tool mà LLM loop quyết định gọi. Cách này giảm được token, nhưng tác giả ghi nhận ba vấn đề vẫn còn nguyên:

• Số lượng mới là chi phí thật, không phải kích thước — model vẫn phải chọn trong 200 tool, nên phần lớn overhead còn đó.
• Thêm một tool vẫn đồng nghĩa với một lần deploy, vì function sống trong runtime của agent.
• Tỉ lệ trả lời sai không giảm — thực đơn vẫn dài y như cũ.

Bài học áp dụng được ngay: nếu bạn đang đo token tiết kiệm được mà không đo số tool model phải cân nhắc mỗi lượt, bạn đang tối ưu nhầm biến.

Rào chắn kiến trúc: một row không chứa được function

Bước tiếp theo — lưu cả tool vào database — vấp phải giới hạn kỹ thuật mà bài mô tả thẳng: "You can put a name and a description in a row. You can't put a function pointer in one." Lối ra duy nhất là đẩy phần implementation của mọi tool ra sau một endpoint, ví dụ external API hoặc AWS Lambda. Tác giả gọi đây là một quyết định hạ tầng, không phải refactor lén đưa vào pull request — và đó là phần team bạn cần cân nhắc trước khi đi theo.

Thiết kế cuối: retrieval cho tool

Nguyên tắc gọn một câu: "Treat tools the way RAG treats documents: retrieve the relevant ones, ignore the rest." Luồng vận hành gồm hai nửa:

1. Đăng ký tool, không cần deploy. Admin thêm tool qua một Control Plane API nằm sau SSO của công ty; name, description, example query và tag được embed ở document mode rồi lưu vào vector database cùng endpoint của nó.
2. Phục vụ request. Query của user được embed ở query mode, vector search tìm tool có embedding gần nhất, và chỉ top-k, thường là 4-5 tool, được đưa vào LLM loop. Khi model gọi tool, một tools executor chuyển request tới external API của tool đó qua egress proxy.

Bản phác (ví dụ minh hoạ, không phải production code) rút gọn thành:

async function toolsFor(query: string) {
  const vector = await embed(query, { mode: "query" });
  return vectorDb.search(vector, { topK: 5 }); // 4–5 tools thay vì ~200
}
const tools = await toolsFor(userQuery);
const answer = await runLlmLoop(userQuery, [...tools, searchTool]);

Trước khi copy kiến trúc này

Đo trước: log số tool definition mỗi request và tỉ lệ tool được gọi thật. Nếu agent của bạn chỉ có vài tool thì retrieval là phức tạp hoá vô ích; ngưỡng đáng cân nhắc nằm ở chỗ catalog phình tới mức model phải đọc nhiều thứ không liên quan mỗi lượt. Lưu ý hai chi phí mà thiết kế này thêm vào và bài không định lượng: một vòng embed cộng vector search trước mỗi lượt, và rủi ro retrieval trượt tool đúng — hãy giữ một search tool mặc định trong danh sách như sketch ở trên để có đường lui.