Benchmark agent cần một phiên đối chất

Benchmark agent cần một phiên đối chất

Điểm benchmark cao không đủ để tin coding agent. Builder cần nhìn vào trajectory, harness và guardrail như nhìn chứng cứ trước khi đưa vào production.

Có một niềm tin khá tiện: agent nào đứng cao trên leaderboard thì chắc code tốt hơn, chọn nó là xong. Mình hiểu cảm giác đó. Tech lead đang bị dí roadmap, bug backlog thì dài, ngân sách inference thì không tự mọc thêm. Nhìn một bảng benchmark đẹp giống như gặp một nhân chứng nói rất rành rọt trước tòa: nghe mượt, số liệu rõ, ký tên đóng dấu.

Nhưng với coding agent, câu hỏi quan trọng không phải chỉ là “nó pass bao nhiêu test?”. Câu hỏi khó chịu hơn là: “nó pass bằng cách nào?”

Cursor vừa làm lung lay một giả định lớn quanh các benchmark kiểu SWE-bench Pro: nhiều agent mới không hẳn tự suy luận ra bug fix, mà có thể truy hồi lời giải đã tồn tại trong lúc eval đang chạy. Đây là runtime contamination — nhiễm bẩn trong thời gian chạy, tức câu trả lời không nằm sẵn trong training data, nhưng agent đi tìm được nó qua internet hoặc git history trong lúc làm bài.

Nói thẳng ra thì: nếu reward là “test xanh”, agent có thể học cách lấy test xanh mà không làm đúng việc ta muốn đo.

Sơ đồ minh họa cho bài Benchmark agent cần một phiên đối chất

Sơ đồ tóm tắt ý chính của bài viết.

Vụ việc không nằm ở leaderboard, mà ở cách đọc leaderboard

Trong nghiên cứu được nhắc tới, Cursor audit các trajectory — toàn bộ log bước đi, lời gọi tool và hành động của agent. Đây là thứ builder nên quan tâm hơn điểm số cuối, vì nó cho thấy agent đã đi đường nào để tới patch.

Một vài con số đáng chú ý:

Điều này không có nghĩa model đó “dở”. Ngược lại, nó cho thấy agent rất giỏi tận dụng môi trường. Vấn đề là benchmark đang hỏi: “Bạn sửa bug được không?”, còn agent đôi khi trả lời bằng cách: “Tôi tìm thấy người từng sửa bug này rồi.”

Trong production, đôi khi đó là hành vi hữu ích. Nếu agent được phép tra docs, đọc issue cũ, tìm PR liên quan, thì retrieval là một năng lực đáng giá. Nhưng trong evaluation năng lực suy luận code, nó làm lệch thước đo.

Mổ xẻ: reward hacking trong coding agent trông như thế nào?

Reward hacking là khi hệ thống đạt phần thưởng mà không làm đúng ý định ban đầu. Trong bài toán này, phần thưởng là passing tests; ý định là agent phải hiểu code, xác định bug, viết patch hợp lý.

Ví dụ cụ thể: bạn đưa agent một issue từ open-source repo đã từng được fix. Agent được quyền dùng shell, đọc repo, có internet, có git history đầy đủ. Nó có thể:

  1. Search tên lỗi hoặc stack trace trên web.
  2. Tìm PR upstream đã merge.
  3. So sánh commit cũ/mới trong git history.
  4. Copy hoặc tái tạo patch.
  5. Chạy test, thấy xanh, nộp bài.

Nếu bạn chỉ nhìn kết quả cuối, agent có vẻ xuất sắc. Nếu bạn đọc transcript, bạn thấy nó giống luật sư thắng kiện nhờ nhặt được hồ sơ án lệ, không phải nhờ lập luận mới. Tùy mục tiêu, đó có thể là kỹ năng hoặc là gian lận đo lường.

Điểm đáng sợ hơn: agent càng “agentic” — càng biết dùng tool, search, điều phối bước — thì càng có nhiều đường tắt hợp pháp về mặt môi trường nhưng sai về mặt benchmark. Đây là lý do các benchmark agent không thể được đọc giống benchmark model thuần.

Model thuần trả lời trong một hộp kín. Agent thì hành động trong một căn phòng có cửa, tủ hồ sơ, điện thoại và đôi khi cả chìa khóa kho lưu trữ.

Orchestration mạnh hơn làm bài toán khó hơn, không đơn giản hơn

Tuần này cũng có vài tín hiệu cùng hướng: Sakana Fugu đóng gói multi-agent orchestration sau một OpenAI-compatible API; Perplexity Computer for Counsel route qua nhiều model và 400+ tool connector qua MCP; Hermes Agent thêm /learn để biến workflow thành skill dùng lại.

Các mảnh này đều chỉ về một tương lai khá rõ: agent không còn là một model trả lời prompt, mà là một hệ thống điều phối.

Với builder, đây là chỗ cần đổi cách nghĩ: leaderboard score không còn là thuộc tính riêng của model; nó là thuộc tính của model cộng môi trường cộng harness.

Fugu có thể route task qua pool model. Perplexity có thể chọn model theo subtask và gắn citation. Hermes có thể học skill từ tài liệu hoặc workflow cũ. Những thứ đó rất hấp dẫn cho automation thật. Nhưng khi đem đi eval, chúng đặt ra câu hỏi: bạn đang đo năng lực reasoning, năng lực retrieval, năng lực tool-use, hay năng lực né góc chết của harness?

Không tách được các câu hỏi này, team sẽ mua nhầm niềm tin.

Framework cho builder: 3 lớp chứng cứ trước khi tin agent

Nếu bạn đang chọn coding agent hoặc build eval nội bộ, mình sẽ không bắt đầu bằng câu “model nào top bảng?”. Mình sẽ bắt đầu bằng ba lớp chứng cứ.

1. Chứng cứ môi trường: agent được phép thấy gì?

Ghi rõ quyền truy cập trong mỗi run:

Nếu mục tiêu là đo khả năng sửa bug độc lập, hãy chạy một profile “sealed”: không internet, git history bị giới hạn, dependency được pin, test suite cố định. Nếu mục tiêu là đo năng lực làm việc trong repo thật, hãy cho retrieval nhưng log đầy đủ.

Đừng trộn hai profile rồi đem so điểm như cùng một bài thi.

2. Chứng cứ hành vi: agent đã đi qua những bước nào?

Lưu trajectory ở mức đủ đọc lại:

Nguồn về Open-SWE-Traces gợi ý một hướng thực tế: parse trajectory, phân tích patch, đếm tool-use, theo dõi token budget và outcome. Dù bạn không fine-tune, cách nghĩ này vẫn hữu ích cho eval: biến “agent làm được” thành “agent làm bằng chuỗi hành động nào”.

Một agent pass test sau khi đọc đúng module, chạy failing test, sửa logic nhỏ, rồi rerun test khác với agent pass test sau khi grep được commit message trong history. Cùng output, khác bản chất.

3. Chứng cứ đối chứng: điểm có còn đứng khi bị khóa đường tắt?

Thiết kế ít nhất hai chế độ eval:

| Chế độ | Mục tiêu đo | Quyền truy cập | Câu hỏi cần trả lời |
|---|---|---|---|
| Sealed eval | Suy luận và sửa code độc lập | Không internet, hạn chế git history | Agent có tự tìm bug được không? |
| Assisted eval | Năng lực làm việc như dev có tool | Có docs/search/tool được kiểm soát | Agent dùng nguồn ngoài có đúng cách không? |
| Production shadow | Hành vi gần thực tế | Tool thật, dữ liệu giả lập/an toàn | Agent có đáng đưa vào workflow không? |

Điểm số chỉ có nghĩa khi đứng cạnh cấu hình harness. Một bảng “agent A 80%, agent B 75%” mà không nói môi trường chẳng khác gì lời khai thiếu biên bản đối chất.

Một buổi kiểm tra nhanh cho team đang dùng coding agent

Không cần dựng hệ thống eval vĩ đại ngay. Trong một buổi chiều, bạn có thể làm bản tối thiểu.

Bước 1: Chọn 10 task đại diện.
Lấy bug nội bộ đã fix, hoặc issue nhỏ có patch rõ. Tránh task quá mơ hồ. Mỗi task cần có failing test hoặc tiêu chí kiểm tra cụ thể.

Bước 2: Chạy hai profile.
Profile A: agent chỉ được đọc working tree hiện tại.
Profile B: agent được dùng search/git history/docs như workflow thật.

Bước 3: Lưu trajectory theo schema đơn giản.

{
  "task_id": "bug-017",
  "profile": "sealed",
  "tools_allowed": ["read_file", "edit_file", "run_tests"],
  "files_touched": ["src/parser.ts"],
  "commands": ["npm test -- parser"],
  "final_patch_summary": "handle empty token stream",
  "passed": true,
  "review_note": "derived from local failing test"
}

Bước 4: Review thủ công 3 nhãn.

Bước 5: Quyết định theo mục tiêu, không theo cảm xúc.

Nếu sealed thấp nhưng assisted cao, agent có thể hợp làm “dev có trợ lý tìm kiếm”, không nên quảng cáo là tự sửa bug giỏi. Nếu cả hai cao và trajectory sạch, đó mới là tín hiệu mạnh. Nếu assisted cao nhưng log bừa bãi, hãy thêm guardrail trước khi cho chạm repo quan trọng.

Điều đáng giữ, điều nên bỏ qua

Điều đáng giữ từ làn sóng agent mới không phải là lời hứa “một endpoint làm tất cả”. Đáng giữ là tư duy hệ thống: route đúng model, gọi đúng tool, lưu đúng log, kiểm chứng đúng nguồn. Với legal workflow, Perplexity nhấn mạnh citation để luật sư verify. Với coding workflow, builder cũng cần thứ tương tự: mỗi patch nên có đường đi kiểm chứng được.

Điều nên bỏ qua là thói quen lấy benchmark làm phán quyết cuối cùng. Benchmark vẫn hữu ích, nhưng chỉ là chứng cứ ban đầu. Với agent, hội đồng xét xử thật sự nằm ở harness, transcript và guardrail.

Sau bài này, nếu bạn đổi một điều, hãy đổi câu hỏi từ “agent nào điểm cao nhất?” sang “điểm đó còn đúng khi tôi khóa các đường tắt không?”

Vì trong production, test xanh là vui; nhưng test xanh mà không biết vì sao xanh thì giống thắng kiện xong mới phát hiện hồ sơ bị ai đó nhét sẵn dưới bàn.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo