Nghĩa địa skill – Tập 4: vì sao AI agent chọn công cụ sai
BlogContents
Chào mừng bạn đến với Fx Studio. Bài này xem vì sao AI agent chọn công cụ sai khi số công cụ phình lên, và vì sao lọc bớt không phải phép màu.
Tập 4 của series Nghĩa địa skill — về những skill tui viết cho Claude Code rồi không mở lại lần nào. Ba tập trước nói về cái chết; tập này lật lại: cái nào sống được. Hoá ra một skill có thể chết không vì nó dở, mà vì đứng quá gần một skill khác — và khi AI agent chọn công cụ trong một đống nhoè ranh giới, độ chính xác rơi rất sớm. Lọc bớt kéo lại được một phần, nhưng trần của nó vẫn dưới một nửa.
Tập trước tui kể hai kiểu chết rồi để dành kiểu thứ ba, vì nó khác hẳn hai kiểu kia.
Hai kiểu đầu đều là lỗi của người viết. Viết cho một phiên bản mình không sống thành. Viết đúng lúc hào hứng chứ không đúng lúc cần. Cả hai đều xảy ra ở khoảnh khắc gõ dòng đầu tiên.
Kiểu thứ ba thì không nằm ở lúc viết. Nó nằm ở chỗ các công cụ đứng cạnh nhau sau đó.
Va chạm: vì sao AI agent chọn công cụ nhầm khi có quá nhiều
Kiểu chết thứ ba bắt đầu từ chuyện này: khi trong tay có năm chục công cụ, gần như chắc chắn sẽ có vài cái làm những việc na ná nhau.
Có một ví dụ tui thấy rất đúng: search_issues, list_issues, get_issue, find_issues_by_label. Bốn cái này khác nhau thật, và người viết ra chúng biết rõ chúng khác nhau ở đâu. Nhưng với một model đang phải làm việc dưới tải ngữ cảnh lớn, cái ranh giới ngữ nghĩa giữa chúng nhoè đi. Kết quả không phải là chậm hơn. Kết quả là chọn nhầm cái này, hoặc gọi đúng cái này mà nhét tham số bê từ schema của cái kia.
Nhìn lại thư mục của tui thì đây đúng là chỗ đáng lo nhất. Cả một họ tui- cùng tiền tố, cùng giọng mô tả, cùng miền việc. Với người viết thì mỗi cái một vai rõ ràng. Với con mắt đọc mô tả thì chúng là bốn thứ nghe hơi giống nhau đứng cạnh nhau.
Tức là một skill có thể chết không phải vì nó dở, mà vì có một skill khác đứng gần quá.
Cú sập không hề êm ái: từ 43% xuống 2%
Mức sụt khi số công cụ tăng đã được đo, và con số làm tui hơi choáng.
Berkeley Function Calling Leaderboard đo trên tác vụ đặt lịch: với bốn công cụ thì độ chính xác đạt bốn mươi ba phần trăm; mở rộng lên năm mươi mốt công cụ trải nhiều miền khác nhau thì rơi xuống hai phần trăm.
Bốn mươi ba xuống hai. Đó không phải một đường cong suy giảm từ tốn. Đó là một cái vực.
Ngưỡng bắt đầu thấy vấn đề cũng thấp hơn tui tưởng. Các benchmark sản xuất ghi nhận độ chính xác suy giảm đo được khi số công cụ vượt khoảng mười tới mười lăm, và phần lớn đội làm sản phẩm thấy rõ chuyện đó khi vượt mười lăm tới hai mươi công cụ trong vòng xoay hoạt động. Trong khi OpenAI đặt trần cứng ở một trăm hai mươi tám công cụ mỗi agent — tức là chuyện hỏng xảy ra rất lâu trước khi đụng cái trần chính thức.
Có một bộ số khác cho thấy hình dạng của cái dốc: với khoảng năm mươi công cụ, phần lớn model giữ được tám mươi tư tới chín mươi lăm phần trăm; lên khoảng hai trăm công cụ thì rơi vào khoảng bốn mươi mốt tới tám mươi ba tuỳ model; và tới khoảng bảy trăm bốn mươi công cụ thì phần lớn model chỉ còn từ không tới hai mươi phần trăm.
Cách chữa nghe rất đã: lọc bớt công cụ trước khi đưa vào
Đây là chỗ mà nếu tui dừng lại thì bài này thành một bài quảng cáo.
Nghiên cứu RAG-MCP đưa ra một ý đơn giản: đừng phơi cả catalog ra trước mặt model. Lọc trước bằng tìm kiếm ngữ nghĩa, chọn ra vài cái liên quan tới câu hỏi, rồi chỉ đưa từng đó vào.
Kết quả trên benchmark của họ: độ chính xác chọn công cụ đi từ mười ba phẩy sáu hai phần trăm lên bốn mươi ba phẩy một ba phần trăm. Hơn gấp ba. Đồng thời số token trong prompt giảm hơn một nửa, từ khoảng hai nghìn một xuống còn khoảng một nghìn.
Model không đổi. Công cụ không đổi. Chỉ đổi số lượng thứ mà model nhìn thấy lúc phải quyết định.
Nếu bài dừng ở đây, kết luận sẽ rất gọn: cài một lớp lọc vào, xong.
Nhưng 43% vẫn là dưới một nửa
Bốn mươi ba phần trăm vẫn là dưới một nửa.
Đó là con số tốt nhất trong bảng đó, và nó vẫn có nghĩa là phần lớn số lần thì chọn sai. “Hơn gấp ba” nghe rất mạnh, nhưng gấp ba của mười ba thì vẫn là bốn mươi ba, và bốn mươi ba không phải chỗ để yên tâm.
Chưa hết. Bản thân nhóm RAG-MCP cũng ghi nhận rằng độ chính xác truy hồi của họ suy giảm khi kho công cụ phình lên tới hàng nghìn. Cách chữa cũng có trần của nó.
Và đây là chỗ tui thấy quan trọng nhất. Một nghiên cứu khác về truy hồi công cụ MCP cho thấy có phương pháp truy hồi còn tệ hơn cả không truy hồi gì — cụ thể là BM25, với tỉ lệ tìm trúng chỉ khoảng sáu mươi mốt phần trăm, khiến danh sách rút gọn quá nhiễu hoặc thiếu, và độ chính xác cuối cùng tụt xuống thấp hơn cả việc cứ để model tự xoay với ngữ cảnh dài. Kết luận của họ: truy hồi chỉ có lợi khi bộ truy hồi giỏi hơn khả năng tự xử ngữ cảnh của chính model.
Và chi tiết cuối, cay nhất: ngay cả khi công cụ đúng đã nằm trong danh sách rút gọn, model vẫn nhận nhầm trong khoảng mười tới mười lăm phần trăm số lần.
Lọc bớt không phải phép màu. Lọc dở còn tệ hơn không lọc.
Vậy cái gì thật sự cứu: ba dấu hiệu của một skill còn sống
Ghép hết lại thì tui rút ra thế này: thứ cứu mình không phải cái máy lọc. Máy lọc chỉ giúp được khi những thứ nó lọc vốn đã phân biệt được với nhau.
Nếu bốn skill của tui mô tả na ná nhau, thì dù có lọc hay không, cái ranh giới vẫn nhoè. Lọc chỉ thu hẹp danh sách; nó không tạo ra sự khác biệt mà bản thân các mục vốn không có.
Nên câu hỏi đúng không phải “làm sao chọn cho trúng trong đống này”, mà là “đống này có đáng để phải chọn không”.
Từ đó ra ba dấu hiệu của một skill còn sống. Tui rút từ chính chỗ các nghiên cứu trên chỉ ra là hỏng, chứ không phải từ một checklist nào.
Một, mô tả nói rõ khi nào KHÔNG dùng. Phần lớn mô tả chỉ nói công cụ làm được gì. Nhưng chỗ model chọn nhầm là chỗ hai công cụ cùng có vẻ làm được. Câu “đừng dùng cái này khi…” tạo ra ranh giới mà câu “cái này làm được…” không tạo ra nổi.
Hai, nó không giẫm chân cái nào khác. Nếu phải giải thích dài dòng để phân biệt hai skill, thì với người đọc mô tả chúng đã là một. Gộp lại, hoặc bỏ một cái.
Ba, tên nó bật ra trong đầu đúng lúc cần. Đây là phép thử từ tập 1, và tới giờ nó vẫn là phép thử rẻ nhất. Cái nào phải đi tìm mới nhớ ra thì nó đã ở ranh giới rồi.
Bớt đi không phải là mất năng lực
Cả series này tui đi từ một trực giác rất tự nhiên: nhiều công cụ hơn thì mạnh hơn.
Số liệu nói ngược. Vượt một ngưỡng thấp đáng ngạc nhiên, thêm công cụ không làm agent mạnh hơn mà làm nó yếu đi. Và cái vực bốn mươi ba xuống hai cho thấy chỗ đó không hề xa.
Nên bớt đi không phải là chấp nhận làm được ít hơn. Bớt đi chính là cách lấy lại phần năng lực đang bị mấy thứ nằm im rút mất.
Tới đây thì tui đã biết cái nào sống, biết vì sao nó sống, và biết cái nào nên đi.
Vậy mà tay tui vẫn chưa gõ được lệnh xoá.
Tập cuối: xoá.
Nguồn
- Va chạm công cụ và mô tả nhoè ranh giới: dev.to — MCP Tool Overload: Why More Tools Make Your Agent Worse
- 4 → 51 công cụ, 43% → 2% trên tác vụ đặt lịch: Berkeley Function Calling Leaderboard, dẫn qua TianPan.co — The Tool Selection Problem
- Ngưỡng ~10–15 công cụ; trần cứng 128 công cụ mỗi agent của OpenAI: MachineLearningMastery — The Complete Guide to Tool Selection in AI Agents
- Bậc thang 50 / 200 / 740 công cụ: vLLM Semantic Router — Semantic Tool Selection
- 13,62% → 43,13%, token 2133 → 1084, và cảnh báo suy giảm khi kho lên hàng nghìn: RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation, arXiv 2505.03275
- BM25 tệ hơn baseline; truy hồi chỉ có lợi khi giỏi hơn khả năng tự xử của model; chọn nhầm 10–15% dù công cụ đúng đã trong top 10: HumanMCP: A Human-Like Query Dataset for Evaluating MCP Tool Retrieval Performance
Cảm ơn bạn đã đọc bài viết này!
Related Posts:
