Tại sao chúng tôi từ chối giải pháp tiết kiệm 96% token

Chúng tôi đã tìm thấy một MCP server giúp tiết kiệm tới 96% lượng token. Nó chỉ sử dụng một công cụ duy nhất: execute_code. Thay vì gọi các hàm cụ thể, agent sẽ viết JavaScript để lấy dữ liệu.

Trên lý thuyết, nó thắng thế. Đối với các tác vụ phức tạp, việc thực thi mã (code execution) vượt trội hơn việc gọi công cụ (tool-calling) về mặt hiệu suất.

Nhưng chúng tôi đã không áp dụng nó. Thay vào đó, chúng tôi vẫn giữ các công cụ riêng biệt và có tên gọi cụ thể.

Dưới đây là lý do tại sao lựa chọn hiển nhiên đó lại là lựa chọn sai lầm cho agent của chúng tôi.

Đối tượng mục tiêu quyết định thiết kế

Hầu hết mọi người xây dựng hệ thống cho các mô hình tiên phong (frontier models) trong cửa sổ chat. Những mô hình đó có ngân sách token khổng lồ. Với chúng, thực thi mã là vua.

Chúng tôi xây dựng một agent ưu tiên giọng nói (voice-first) chạy trên một mô hình cục bộ nhỏ (Hermes 3 8B) ngay trên một con thuyền.

Đối với một mô hình nhỏ, ràng buộc không phải là token. Ràng buộc chính là độ tin cậy.

Nếu một mô hình nhỏ đã gặp khó khăn khi gọi một công cụ đơn giản, thì việc yêu cầu nó viết JavaScript chính xác sẽ là một nhiệm vụ khó khăn hơn nhiều. execute_code đánh đổi độ tin cậy để lấy token. Chúng tôi không thể chấp nhận sự đánh đổi đó.

Vấn đề "dặm cuối" (The Last-Mile Problem)

Việc thực thi mã đẩy phần việc "dặm cuối" lên vai agent. Agent phải:

  • Lọc dữ liệu
  • Sắp xếp kết quả
  • Định dạng đầu ra

Các công cụ của chúng tôi thực hiện công việc này ngay bên trong server. Ví dụ, khi hỏi về tình trạng pin, công cụ của chúng tôi sẽ trả về một chuỗi văn bản đã sẵn sàng để chuyển thành giọng nói (text-to-speech). Nó sẽ nói "68 phần trăm, 12,8 vôn" thay vì chỉ trả về các con số thô.

Nếu sử dụng execute_code, agent sẽ phải tự viết logic để định dạng lời nói đó. Các mô hình nhỏ liên tục thất bại ở bước này.

Quy tắc về sự vắng mặt (The Absence Rule)

Trên một con thuyền, các cảm biến có thể bị mất kết nối. Trong hệ thống của chúng tôi, một cảm biến bị thiếu sẽ trả về một giá trị null sạch sẽ. Đây được coi là một lần gọi thành công.

Trong mô hình thực thi mã, một cảm biến bị thiếu thường sẽ gây ra lỗi. Nếu một mô hình nhỏ đoán sai vài hướng đi, nó sẽ kích hoạt giới hạn lỗi và làm hỏng agent. Các công cụ có tên gọi cho phép chúng tôi coi sự vắng mặt là một kết quả thành công, chứ không phải là một lỗi.

Danh sách kiểm tra: Áp dụng hay Tự xây dựng

Trước khi bạn áp dụng hoặc xây dựng một MCP server, hãy tự hỏi những câu hỏi sau:

• Đối tượng agent mục tiêu là ai? (Mô hình tiên phong vs. Mô hình cục bộ nhỏ) • Ràng buộc chính là gì? (Token vs. Độ tin cậy) • Ai thực hiện bước dặm cuối? (Công cụ định dạng dữ liệu hay agent làm?) • Nó xử lý sự vắng mặt như thế nào? (Giá trị thiếu là một lỗi hay là null?) • Chi phí bảo trì là bao nhiêu? (Bạn có đang thừa hưởng một mã nguồn không còn được duy trì không?)

Chúng tôi không hề phớt lờ dự án kia. Chúng tôi đã thu hoạch các ý tưởng từ nó. Chúng tôi đã lấy logic xử lý báo động và khám phá đường đi của họ để đưa vào lộ trình phát triển của mình.

Hiệu suất là điều tuyệt vời, nhưng độ tin cậy mới là điều bắt buộc khi bạn đang ở trên mặt nước.

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi