3 điểm bởi GN⁺ 2026-02-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là benchmark đầu tiên nhằm đánh giá định lượng hiệu quả của kỹ năng (Agent Skills) trong các agent dựa trên mô hình ngôn ngữ lớn (LLM), bao gồm 84 tác vụ thuộc 11 lĩnh vực
  • Mỗi tác vụ được đánh giá trong ba điều kiện: không áp dụng kỹ năng, áp dụng kỹ năng được tuyển chọn, và áp dụng kỹ năng do mô hình tự tạo, với tổng cộng 7.308 quỹ đạo thực thi được thu thập
  • Các kỹ năng được tuyển chọn cho thấy mức cải thiện hiệu năng trung bình +16,2 điểm phần trăm, nhưng chênh lệch giữa các lĩnh vực rất lớn và ở một số tác vụ (16 trên 84) hiệu năng còn giảm đi
  • Kỹ năng tự sinh (Self-generated Skills) nhìn chung không mang lại hiệu quả, cho thấy mô hình chưa thể tự tạo ra tri thức thủ tục một cách ổn định
  • Các mô-đun kỹ năng nhỏ, tập trung (gồm 2–3 phần) hiệu quả hơn các kỹ năng dạng tài liệu tổng quát, và mô hình nhỏ có dùng kỹ năng đạt hiệu năng tương đương mô hình lớn không dùng kỹ năng

Tổng quan về SKILLSBENCH

  • SKILLSBENCH là benchmark nhằm đánh giá hiệu quả tăng cường bằng kỹ năng cho agent LLM, được xây dựng dựa trên framework Harbor
    • Mỗi tác vụ bao gồm môi trường container, bộ kiểm chứng xác định, và đáp án tham chiếu (oracle)
    • Cùng một tác vụ được chạy lặp lại tùy theo có áp dụng kỹ năng hay không để đo tác động thuần túy của kỹ năng
  • Khác với các benchmark trước đây chỉ đánh giá năng lực nền của mô hình, SKILLSBENCH trực tiếp đo mức ảnh hưởng của kỹ năng lên hiệu năng

Định nghĩa và cấu thành của kỹ năng (Agent Skills)

  • Kỹ năng là gói có cấu trúc chứa tri thức thủ tục (procedural knowledge), giúp mở rộng hành vi của agent tại thời điểm suy luận mà không cần chỉnh sửa mô hình
    • Thành phần gồm: SKILL.md (quy trình tiếp cận tác vụ), script có thể thực thi, template mã, ví dụ, v.v.
  • Kỹ năng phải đáp ứng bốn tiêu chí sau
    • Có nội dung mang tính thủ tục
    • Áp dụng cho lớp tác vụ chứ không phải chỉ một trường hợp đơn lẻ
    • Có các thành phần được cấu trúc rõ ràng
    • Dựa trên hệ thống tệp để đảm bảo tính di động
  • System prompt, ví dụ few-shot, truy xuất RAG, và tài liệu công cụ không được xem là kỹ năng

Cấu trúc tác vụ (Task) và xây dựng bộ dữ liệu

  • Mỗi tác vụ gồm bốn thành phần: chỉ dẫn, môi trường, lời giải, bộ kiểm chứng
    • Môi trường được cô lập bằng container Docker để đảm bảo khả năng tái lập
    • Bộ kiểm chứng là script kiểm thử xác định, tự động phân loại đậu/rớt
  • 105 người đóng góp đã gửi 322 tác vụ ứng viên; sau khi qua bước kiểm chứng tự động và rà soát thủ công, 84 tác vụ cuối cùng được chọn
  • Người đóng góp phải đáp ứng các yêu cầu sau
    • Chỉ dẫn do con người viết (không được do LLM tạo)
    • Kỹ năng phải cung cấp hướng dẫn thủ tục, không phải lời giải cho một tác vụ cụ thể
    • Mọi kiểm chứng phải được thực hiện theo cách xác định (dựa trên assertion)
    • Phải vượt qua kiểm tra cấu trúc tự động, chạy oracle, phát hiện nội dung do AI tạo, và kiểm toán rò rỉ
  • Để ngăn rò rỉ, kỹ năng sẽ bị loại nếu chứa tên tệp theo từng tác vụ, hằng số, tham chiếu kiểm thử v.v.

Cấu hình benchmark và phân loại độ khó

  • SKILLSBENCH gồm 84 tác vụ thuộc 11 lĩnh vực (phần mềm, y tế, tài chính, robot, v.v.)
  • Độ khó được chia thành ba mức dựa trên thời gian con người hoàn thành
    • Core (dưới 60 phút): 17 tác vụ
    • Extended (1–4 giờ): 43 tác vụ
    • Extreme (trên 4 giờ): 26 tác vụ

Thiết lập thí nghiệm

  • Đánh giá ba agent harness thương mại: Claude Code, Gemini CLI, Codex CLI
  • Sử dụng bảy mô hình: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash
  • Đánh giá trong ba điều kiện
    • No Skills: không áp dụng kỹ năng
    • With Skills: áp dụng kỹ năng được tuyển chọn
    • Self-Generated Skills: mô hình tự tạo kỹ năng rồi áp dụng
  • Thu thập tổng cộng 7.308 quỹ đạo thực thi (trajectories) hợp lệ

Chỉ số đánh giá

  • Tỷ lệ vượt qua (pass rate) được dùng làm chỉ số cơ bản
  • Mức tăng chuẩn hóa (normalized gain) được tính thêm để phân tích đồng thời mức cải thiện tuyệt đối và theo tỷ lệ
  • Mỗi tác vụ được lặp lại 5 lần rồi lấy điểm trung bình

Kết quả chính

  • Kỹ năng được tuyển chọn mang lại mức cải thiện trung bình +16,2 điểm phần trăm, với biên độ +13,6 đến +23,3 điểm phần trăm tùy cấu hình
    • Chênh lệch lớn giữa các lĩnh vực; y tế cải thiện mạnh nhất (+51,9 điểm phần trăm), còn kỹ thuật phần mềm thấp nhất (+4,5 điểm phần trăm)
    • Trong 16 trên 84 tác vụ, hiệu năng lại giảm
  • Kỹ năng tự sinh nhìn chung không hiệu quả hoặc còn gây tác động tiêu cực
    • Mô hình chưa thể tự tạo ra tri thức thủ tục một cách ổn định
  • Kỹ năng tập trung (2–3 mô-đun) hiệu quả hơn loại tài liệu tổng quát
  • Mô hình nhỏ + kỹ năng đạt hiệu năng tương đương mô hình lớn không dùng kỹ năng

Kết luận

  • SKILLSBENCH cung cấp một khung đánh giá lấy kỹ năng làm trung tâm, đồng thời chứng minh định lượng tác động của kỹ năng lên năng lực thực thi tác vụ thực tế của agent LLM
  • Kết quả cho thấy chất lượng thiết kế kỹ năng và độ phù hợp theo lĩnh vực là yếu tố quyết định đối với cải thiện hiệu năng
  • Đây có thể trở thành nền tảng cho các nghiên cứu tiếp theo nhằm làm rõ nguyên tắc thiết kế cấu trúc của kỹ năng và giới hạn của việc tự động sinh kỹ năng

1 bình luận

 
GN⁺ 2026-02-18
Ý kiến Hacker News
  • Khái niệm “Self-Generated Skills” khá thú vị, nhưng tôi muốn chỉ ra rằng nó khác với điều mọi người thường nghĩ là “quá trình LLM tự học kỹ năng”
    Trong nghiên cứu này, họ chỉ đơn giản là đưa prompt để mô hình tạo ra tri thức mang tính thủ tục liên quan trước khi giải bài toán, nên còn khá xa so với một “kỹ năng học được từ kinh nghiệm” thực sự
    Mong báo chí phân biệt rõ sự khác nhau này khi đưa tin

    • Phạm vi ‘task’ trong thí nghiệm quá hạn chế. Chỉ dùng một file Markdown và bộ kiểm chứng, không đụng tới các vấn đề thực tế như codebase sẵn có hay refactoring
      Dù LLM có tự tạo kỹ năng đi nữa thì cấu trúc này cũng không cho phép khám phá hay học hỏi, nên rốt cuộc chỉ là lặp lại chính ngữ cảnh của nó
      Khái quát hóa các kết quả như vậy rất dễ gây hiểu lầm
    • Mục đích ban đầu của ‘skill’ là giống như một ghi chú how-to ngắn để gọi ra và dùng đúng lúc cần
      Nếu tri thức đó đã nằm sẵn bên trong mô hình thì không cần viết thành tài liệu làm gì, chỉ có ý nghĩa khi đó là thông tin thật sự khó bộc lộ ra
    • Tôi cũng quan tâm tới cách để LLM tổng kết bài học sau khi thử nghiệm thành kỹ năng
      Việc tạo kỹ năng trước khi thử làm là một cách tiếp cận khá xa rời thực tế
    • Tôi đã tạo được những skill hữu ích thông qua ‘role play session’
      Cách hiệu quả là để agent đặt câu hỏi, đi qua quá trình giải quyết vấn đề, rồi tổng hợp kết quả đó thành một skill cô đọng dựa trên bằng chứng
    • Như tôi đã viết tại thisistheway.to/ai, chúng tôi xem thất bại của agent là cơ hội học tập
      ① bắt lỗi thất bại → ② chẩn đoán nguyên nhân → ③ chọn công cụ cải thiện → ④ ghi lại dưới dạng đầu ra có quản lý phiên bản → ⑤ khi cần thì nâng thành gate
      Chúng tôi đưa vòng lặp này vào hướng dẫn mặc định cho mọi agent
  • Tôi đang dùng riêng một skill-creator cho Claude
    Để ngăn Claude viết lại thành skill những thứ nó đã biết sẵn, tài liệu bắt buộc chỉ được chứa
    ① thông tin nằm ngoài dữ liệu huấn luyện, ② ngữ cảnh chỉ có hiệu lực trong phiên hiện tại, ③ thông tin giúp căn chỉnh hành vi của Claude trong tương lai
    Toàn bộ nội dung ở liên kết GitHub

    • Khả năng LLM tự phản tỉnh về những gì nó biết và không biết còn yếu, nhưng tôi vẫn thấy cách tiếp cận này rất hữu ích
    • Tuy vậy, việc giả định Claude có thể chọn ra “tri thức tốt nhất” là khá rủi ro
      Dữ liệu học từ internet có chất lượng rất không đồng đều, nên khó kỳ vọng mô hình sẽ đưa ra lựa chọn ở cấp độ chuyên gia
    • Tôi thích việc tài liệu skill này đọc như một bài blog hay
      Có thể xem một bài viết chứa các insight không hiển nhiên là tiêu chí của một skill tốt
    • Những insight thực tiễn kiểu này có lẽ nên được các nhà nghiên cứu công bố trước trên arXiv trước khi ra paper chính thức
  • Điều thú vị nhất trong kết quả nghiên cứu là skill do mô hình tự tạo làm giảm hiệu năng (-1.3pp), trong khi skill được tuyển chọn lại cải thiện mạnh (+16.2pp)
    Điều này khớp với giả thuyết rằng LLM rất giỏi với vai trò người tiêu thụ tri thức thủ tục, nhưng yếu với vai trò người sản xuất
    Đặc biệt hiệu quả ở healthcare lớn hơn rất nhiều so với software, có lẽ vì dữ liệu SWE vốn đã rất phong phú

    • Tôi cũng chú ý tới khác biệt này. Khi làm với thư viện mới hoặc hiếm gặp, hiệu quả của skill tăng lên cực mạnh
      Ví dụ Adobe React Spectrum UI nếu dùng không có skill thì rất tệ, nhưng dùng skill được viết tốt thì khác hẳn
  • Chỉ đơn giản bảo mô hình “hãy tạo skill” thì không có nhiều ý nghĩa
    Nếu không mở rộng tri thức bằng thông tin mới hoặc tài liệu bên ngoài, thì cuối cùng cũng chỉ là vòng lặp lấy đầu ra của chính nó làm đầu vào
    Tôi dùng skill-creator có thể tự động nghiên cứu khi tạo skill, rồi tinh chỉnh theo thông tin mới nhất hay workflow hiện tại

    • Trong nghiên cứu này, họ không cấp cho agent quyền tự khám phá hay truy cập tài liệu
      Trong điều kiện như vậy thì tạo skill gần như vô nghĩa
    • Trên thực tế, sẽ hữu ích hơn nhiều nếu sau khi dùng skill ngoài hiện trường, nó còn có thể tự động cải thiện bằng feedback
  • Càng tự động hóa LLM theo nhiều tầng, chất lượng ở mỗi bước càng có xu hướng giảm
    Nếu con người đưa ra ý tưởng và kế hoạch triển khai rồi để LLM chỉ code thôi thì còn ổn, nhưng giao cả phần lập kế hoạch thì sẽ xảy ra suy giảm chất lượng rất nhanh

    • Tôi gọi hiện tượng này là ‘semantic collapse’
      Khi cứ lặp đi lặp lại việc tóm tắt hay tái tạo, ý nghĩa cuối cùng sẽ sụp đổ
      Cứ đến một thời điểm nhất định lại cần đầu vào mới từ con người
    • Nhưng nếu quản lý ngữ cảnh tốt thì cũng có trường hợp ngược lại
      Với codebase lớn, tôi để LLM viết báo cáo khám phá trước, rồi ở phiên mới dùng báo cáo đó để tiếp tục làm việc
      Tốn thêm token nhưng không bỏ sót các chi tiết quan trọng
    • Aletheia của Google thậm chí còn cải thiện hiệu năng trong kiểu cấu trúc pipeline này
      Cuối cùng mấu chốt vẫn là có cung cấp đủ tri thức về thế giới cho mô hình hay không
    • Tôi muốn ví quá trình này như trò chơi truyền tin
      Ngôn ngữ tự nhiên vốn dĩ bất ổn, nên càng truyền đi lặp lại thì méo mó càng nhiều
      Việc chúng ta có thể giao tiếp tốt với nhau như vậy vốn đã là điều đáng ngạc nhiên
    • Tuy vậy, nếu có feedback loop thì câu chuyện sẽ khác
      Trong cấu trúc open loop độ chính xác sẽ giảm, nhưng nếu mỗi bước có thể tự điều chỉnh thì hệ thống sẽ ổn định hơn nhiều
  • Tôi đang xây một data warehouse sẵn sàng cho agentic ( GitHub.com/mathisdrn/orca )
    Ban đầu tôi định tối ưu skill bằng benchmark, nhưng cách dùng chính ngôn ngữ của mô hình làm evaluator lẫn builder như DsPyGEPA có vẻ hiệu quả hơn
    Tôi cũng tò mò không biết skill-creator của Anthropic hay OpenAI có cấu trúc tự tối ưu hóa kiểu này không

  • Tôi không thấy nghiên cứu này có gì bất ngờ, cũng không thấy nó có nhiều ý nghĩa thực tiễn
    Ngoài đời thật, gần như không có chuyện mô hình tạo skill chỉ từ tri thức tiềm ẩn của chính nó
    Nghiên cứu lại thử nghiệm trong điều kiện bị giới hạn như vậy nên kết quả là điều dễ đoán
    Điều thú vị hơn sẽ là để mô hình phỏng vấn con người hoặc tạo skill sau khi nghiên cứu sâu

    • Tôi hoàn toàn đồng ý với nhận xét này.
      Thậm chí điều làm tôi ngạc nhiên hơn là paper như vậy vẫn được xuất bản
    • Khoa học hiện đại còn khuyến khích xuất bản cả “kết quả không bất ngờ”
      Hơn nữa, nghiên cứu kiểu này cũng giúp ngăn những nhà quản lý bắt mô hình viết tài liệu best practices mà không cung cấp chút ngữ cảnh nào
    • Trước đây cũng từng có những trường hợp mà cách tiếp cận kiểu ‘lập kế hoạch rồi thực thi’ thật sự hiệu quả
      Nghiên cứu lần này không xét tới bối cảnh đó
    • Rốt cuộc, nói như vậy cũng chẳng khác gì bảo rằng việc để mô hình tự viết CLAUDE.md hay AGENTS.md là vô nghĩa
  • Dạo này tôi có cảm giác quá nhiều người thông minh đang lãng phí năng lượng vào các cuộc tranh luận AI kiểu này
    Ngày xưa họ chỉ làm phần mềm hữu ích, còn giờ lại bị cuốn vào những chủ đề AI mới xuất hiện mỗi tuần
    Hiệu ứng nerd-sniping của nó còn mạnh hơn cả Web3 hay framework JS
    Bài này thực chất cũng chỉ xác nhận một kết quả có thể đoán trước

    • Hiện tại đang là một quá trình tiến hóa phân tán, nên có rất nhiều thử nghiệm trùng lặp
      Nhưng cũng rất có thể model mới sẽ sớm xuất hiện và khiến cả cuộc thảo luận này trở nên vô nghĩa
      Nhiều team được yêu cầu chuyển sang “chiến lược skill”, nhưng trong lúc đó model mới lại làm tốt hơn rồi
      Cuối cùng ai cũng đang loay hoay trong một cấu trúc sinh tồn bất ổn mà chưa tìm ra phương hướng
  • Tôi cũng thường xuyên chứng kiến sự xuống cấp chất lượng của tài liệu tự sinh
    Khi LLM trích xuất ‘best practices’ từ code, nó thường tài liệu hóa nguyên xi cả những pattern sai
    Ví dụ trong code C# từng có trường hợp lạm dụng ConfigureAwait(false) hay Task.Run
    Để giải quyết vấn đề này, chúng tôi đang xây dựng một hệ thống tri thức được tuyển chọn
    Tôi tin rằng agentic coding dựa trên Markdown sẽ trở thành lớp trừu tượng của thế hệ tiếp theo

    • Tuy vậy, tầng LLM khác với các ngôn ngữ trước đây ở chỗ nó phi quyết định
      Tính chất này sẽ ảnh hưởng thế nào tới cách hệ thống vận hành tổng thể thì hiện vẫn chưa rõ
  • Tiêu đề đã gửi là “Self-generated agent skills are useless”, nhưng như vậy là trái với quy định HN
    Giữ nguyên tiêu đề gốc và thể hiện ý kiến ở phần bình luận mới là công bằng

    • Nhưng việc để kết quả cốt lõi bị chìm dưới một tiêu đề quá mơ hồ cũng là vấn đề
      Tôi nghĩ tiêu đề rõ ràng có thể mang lại insight lớn hơn cho cộng đồng
      Mục đích không phải để câu click mà là nhấn mạnh phát hiện cốt lõi