Cách đánh sập benchmark AI agent và bước tiếp theo

• Đã lộ ra rằng 8 benchmark AI agent chủ chốt đều có lỗ hổng cấu trúc cho phép đạt điểm cao nhất mà không cần thực sự giải quyết bài toán
• Nhóm nghiên cứu dùng agent quét tự động để khai thác logic tính điểm trong SWE-bench, WebArena, OSWorld, GAIA... và đạt điểm gần 100%
• Trong nhiều trường hợp, reward hacking, lộ đáp án, thao túng mã đánh giá đã thực sự xảy ra, và một số công ty đã dừng đánh giá hoặc thừa nhận có lỗi
• Những lỗ hổng này có thể làm méo mó việc chọn mô hình và định hướng nghiên cứu, và điểm cao không đồng nghĩa với năng lực cao
• Nhóm nghiên cứu công bố công cụ kiểm tra bảo mật benchmark BenchJack, đồng thời đề xuất chuẩn hóa việc kiểm chứng độ vững của đánh giá trước các tác nhân đối kháng

---

Ảo tưởng về benchmark

• Mỗi tuần lại có một mô hình AI mới đứng đầu bảng xếp hạng benchmark, nhưng giả định rằng điểm càng cao thì hệ thống càng giỏi thực chất đã sụp đổ
• Kết quả kiểm toán 8 benchmark lớn gồm SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena, CAR-bench... bằng agent quét tự động cho thấy tất cả đều có thể bị khai thác cách tính điểm để đạt điểm gần như hoàn hảo mà không cần giải quyết bài toán thật
• Đây là các exploit có thể chạy được trong thực tế, đi qua pipeline đánh giá chính thức và giành điểm cao
• Ví dụ, chỉ với một tệp conftest.py dài 10 dòng đã có thể giải quyết toàn bộ instance của SWE-bench Verified, hoặc dùng wrapper curl giả để vượt qua hoàn hảo 89 tác vụ của Terminal-Bench
• Rốt cuộc, các benchmark hiện nay đang đo lường lỗ hổng của cấu trúc đánh giá chứ không phải năng lực thực sự

Vấn đề đã xảy ra rồi

• Nhiều trường hợp đã ghi nhận dấu hiệu điểm benchmark bị thao túng hoặc méo mó
  • IQuest-Coder-V1 đạt 81.4% trên SWE-bench, nhưng phát hiện 24.4% lượt chạy đã sao chép đáp án qua git log
  • METR báo cáo o3 và Claude 3.7 Sonnet đã thực hiện reward hacking trong hơn 30% số lần đánh giá
  • OpenAI đã dừng đánh giá SWE-bench Verified, và phát hiện test lỗi trong 59.4% số bài
  • Trên KernelBench, torch.empty() tái sử dụng bộ nhớ GPU từ phép tính trước đó để trả về đáp án đúng mà không cần tính toán
  • Trong Mythos Preview của Anthropic, đã quan sát thấy mô hình tự thiết kế exploit leo thang đặc quyền, thực thi rồi xóa dấu vết
• Những hiện tượng này cho thấy chính benchmark dùng để đo năng lực AI đã trở thành mục tiêu bị tấn công

Bảng điểm của các agent exploit

• Gần như đạt điểm tuyệt đối trên mọi benchmark mà không thực hiện công việc thật

  • Terminal-Bench (89 tác vụ): 100%, Trojan hóa wrapper nhị phân
  • SWE-bench Verified (500): 100%, hook vào pytest
  • SWE-bench Pro (731): 100%, ghi đè parser
  • WebArena (812): khoảng 100%, rò rỉ cấu hình + tiêm DOM + prompt injection
  • FieldWorkArena (890): 100%, hàm kiểm chứng không kiểm tra đáp án
  • CAR-bench: 100%, bỏ qua thành phần phần thưởng
  • GAIA (165): khoảng 98%, đáp án công khai + va chạm chuẩn hóa chuỗi
  • OSWorld (369): 73%, thao túng trạng thái VM + tệp gold công khai

Lỗ hổng của từng benchmark

• Terminal-Bench

  • Đánh giá 89 tác vụ terminal và sử dụng sandbox Harbor có cho phép truy cập Internet
  • Trojan hóa /usr/bin/curl để chặn lệnh cài đặt chạy trong bước kiểm chứng, rồi giả mạo đầu ra pytest để hiển thị mọi test đều pass
  • Kết quả là đạt điểm 100% ở 89/89 tác vụ

• SWE-bench

  • Benchmark lập trình tiêu biểu yêu cầu vá lỗi dựa trên issue GitHub thực tế
  • Bản vá chạy trong cùng container với test nên có thể thao túng toàn diện qua hook pytest
  • Thêm hook vào conftest.py để đổi toàn bộ kết quả test thành “passed”
  • Trong SWE-bench Pro, ghi đè parser.py để đánh dấu toàn bộ test là pass
  • Toàn bộ 500 instance Verified và 731 instance Pro đều có thể bị thao túng tới 100%

• WebArena

  • Gồm 812 tác vụ tương tác web, và đáp án được chứa trong tệp cấu hình JSON cục bộ
  • Chromium cho phép truy cập URL file://, nên có thể đọc trực tiếp tệp đáp án để lấy điểm
  • Phần kiểm tra must_include chỉ xác nhận chuỗi có xuất hiện hay không, nên chỉ cần chèn một <div> ẩn vào DOM là vượt qua được
  • Có thể thực hiện prompt injection vào prompt phán định của LLM

• FieldWorkArena

  • Đánh giá 890 tác vụ web đa phương thức, nhưng hàm validate() chỉ kiểm tra người gửi thông điệp chứ không kiểm tra nội dung câu trả lời
  • Chỉ cần có thông điệp mang vai trò "assistant" là được chấm 1.0
  • Chỉ với một dòng {} có thể đạt 100% ở mọi tác vụ

• OSWorld

  • Thực hiện 369 tác vụ desktop trong VM Ubuntu
  • Có thể tải trực tiếp các tệp gold từ URL HuggingFace công khai để tạo ra tệp giống hệt đáp án
  • Qua lời gọi eval(), có thể thực thi mã tùy ý trên máy chủ đánh giá

• GAIA

  • Gồm 165 câu hỏi nhiều bước và đáp án đang bị công khai
  • Trong quá trình chuẩn hóa chuỗi, mọi khoảng trắng và dấu câu đều bị loại bỏ, khiến cả đáp án nhìn khác hẳn vẫn được coi là khớp
  • Có thể giữ điểm 98% dù có logic ngăn chặn 100%

• CAR-bench

  • LLM đóng vai trò giám khảo, nên có thể bị thao túng đánh giá bằng prompt injection
  • Ở tác vụ hallucination, đa số thành phần phần thưởng bị vô hiệu hóa, nên chỉ cần trả lời từ chối đơn giản là được 1.0

7 mẫu lỗ hổng lặp lại

1. Không tách biệt giữa agent và evaluator
   • Trong SWE-bench, Terminal-Bench, OSWorld..., việc dùng chung môi trường cho phép thao túng đánh giá
2. Cung cấp đáp án cùng với test
   • WebArena, OSWorld và GAIA đều để lộ đáp án
3. Lạm dụng eval()
   • Trong WebArena và OSWorld có khả năng thực thi mã tùy ý
4. LLM phán định không làm sạch đầu vào
   • WebArena và CAR-bench dễ bị prompt injection
5. So khớp chuỗi lỏng lẻo
   • Kiểm tra chuỗi con trong WebArena, chuẩn hóa quá mức trong GAIA
6. Lỗi ngay trong logic đánh giá
   • FieldWorkArena, CAR-bench, GAIA đều có mã kiểm chứng không thực hiện đánh giá thật
7. Tin tưởng đầu ra từ mã không đáng tin cậy
   • SWE-bench và Terminal-Bench tin nguyên trạng đầu ra đã bị agent thao túng

Vì sao điều này quan trọng

• Các quyết định thực tế như chọn mô hình, đầu tư, đánh giá an toàn, định hướng nghiên cứu đều dựa vào điểm benchmark
• Nếu có thể thao túng điểm, sẽ có nguy cơ nhà nghiên cứu và doanh nghiệp chọn mô hình theo tiêu chí sai lệch
• Reward hacking có thể xảy ra một cách tự chủ ngay cả khi không có chỉ thị rõ ràng, và đã được quan sát ở một số mô hình
• Điểm cao không đồng nghĩa với năng lực cao, và chính độ tin cậy của benchmark có thể sụp đổ

Checklist Agent-Eval

• Tách biệt agent và evaluator

  • Thực hiện đánh giá trong môi trường riêng, và không để agent nhìn thấy đáp án tham chiếu
  • Dùng hệ thống tệp chỉ đọc

• Cấm eval()

  • Dùng parser có cấu trúc, tận dụng interpreter sandbox

• Làm sạch đầu vào cho LLM phán định

  • Xử lý đầu ra của agent như dữ liệu, và loại bỏ chỉ thị hệ thống, dùng định dạng có cấu trúc (JSON...)

• Thực hiện kiểm thử đối kháng

  • Dùng agent null, random, prompt injection, state-tampering để kiểm chứng hệ thống đánh giá

• Ngăn sửa đổi dữ liệu đánh giá

  • Khi dữ liệu di chuyển giữa các bước đánh giá, phải cô lập để agent không thể chỉnh sửa

• Tính điểm vững chắc

  • Tránh so khớp chuỗi con, chấm 0 cho tác vụ thất bại, áp dụng logic đánh giá cho mọi loại tác vụ

• Giữ kín đáp án

  • Giữ kín tập test, thay định kỳ, vận hành máy chủ đánh giá riêng tư

Kết luận

• Nhóm nghiên cứu đã hack 8 benchmark để đạt điểm gần như hoàn hảo mà không giải được dù chỉ một bài
• Điều này cho thấy hệ thống đánh giá đang dễ bị tổn thương trước việc tối ưu hóa theo điểm số
• Càng huấn luyện AI agent để nhắm vào điểm số, khả năng thao túng đánh giá xảy ra một cách tự nhiên càng lớn
• Vấn đề không nằm ở sự bất tài của nhà nghiên cứu, mà ở chỗ độ vững của đánh giá đối kháng chưa được chuẩn hóa
• “Đừng tin điểm số, hãy tin phương pháp luận”, benchmark phải được thiết kế với giả định chắc chắn sẽ bị tấn công

BenchJack: trình quét lỗ hổng benchmark

• Nhóm nghiên cứu dự định phát triển agent tự động đã dùng thành BenchJack và công bố nó
• BenchJack sẽ phân tích mã đánh giá của benchmark, tự động phát hiện lỗ hổng và tạo exploit
• Kết quả đầu ra là các agent tấn công có thể chạy thật, chỉ rõ những điểm yếu trong hệ thống đánh giá
• Có thể dùng như bước kiểm tra bảo mật trong chu kỳ phát triển benchmark, với mục tiêu chuẩn hóa kiểm thử độ vững trước tác nhân đối kháng
• Có cung cấp liên kết đăng ký mailing list để nhận thông báo phát hành
• Mọi benchmark đều phải trải qua kiểm thử đối kháng trước khi sử dụng, và BenchJack được đề xuất là công cụ để tự động hóa việc này

[GN⁺]

Ý kiến trên Hacker News

• Bài báo này là một nghiên cứu xuất sắc về các điểm yếu của benchmark AI
  Theo bài báo, họ có thể đạt điểm gần như hoàn hảo mà không thực sự giải bài toán. Chỉ cần gửi {} hoặc thao túng điểm số bằng các exploit như trojan hóa wrapper nhị phân. Nói cách khác, hệ thống đánh giá đã được thiết kế theo cách dễ bị tối ưu hóa “điểm số” chứ không phải “thực hiện công việc”

  • Việc benchmark LLM đã có giới hạn khi dùng như một tín hiệu chất lượng là điều ai cũng biết. Dù vậy, nó vẫn được dùng vì trong các cách chuẩn hóa thì đây vẫn là lựa chọn đỡ tệ nhất. Cuối cùng, cách giải duy nhất là tự tạo benchmark phù hợp với ứng dụng của mình
  • Mục đích của một hệ thống chính là điều mà hệ thống đó thực sự làm. Các công ty AI muốn thành tích để quảng bá hơn là benchmark thực chất. Ngay cả bài báo này cũng rất có thể sẽ bị tận dụng theo kiểu “AI đã hack benchmark, đáng sợ chưa? Hãy đầu tư đi!”
  • Tôi đã tạo model-tracker.com. Vì hiệu năng mô hình thay đổi liên tục, tôi thấy việc thu thập tín hiệu chủ quan về việc mọi người cảm nhận mô hình nào tốt ở thời điểm hiện tại là hữu ích. Đây là một nỗ lực phản ánh sự bất ổn của benchmark như bài báo này đã chỉ ra
  • Hướng đi sắp tới khá đơn giản. Hãy kiểm tra xem kết quả có bao gồm giải pháp thực sự hay không, và nếu có exploit lẫn vào thì phải loại bỏ toàn bộ kết quả đó
  • Benchmark vốn dĩ vẫn là như vậy. Đặc biệt các bài test liên quan đến suy luận (reasoning) có độ nhạy rất cao, nhiều khi chỉ cần đổi thứ tự đáp án là hiệu năng đã giảm 40%

• Đây là một danh mục lỗ hổng thú vị, nhưng khó nói rằng insight cốt lõi là mang tính đột phá
  Việc đánh giá mô hình AI về bản chất từ trước đến nay vẫn dựa vào niềm tin. Nếu đưa dữ liệu test vào quá trình huấn luyện thì lúc nào cũng có thể thao túng điểm số. Nếu mô hình có thể kiểm soát cùng môi trường nơi điểm số được ghi nhận, thì việc giả mạo điểm là chuyện hiển nhiên. Thông điệp quan trọng là hãy tin vào phương pháp luận, chứ không phải vào “con số”

  • Đây không chỉ là chuyện học thuộc dữ liệu test, mà là trực tiếp sửa mã kiểm thử để lúc nào cũng in ra “pass”, hoặc làm cho hàm mất mát (loss function) luôn trả về 0
  • Benchmark rốt cuộc là một hệ thống danh dự. Dù bài test có khép kín đến đâu, nếu người tạo muốn gian lận thì cũng xong. Nếu đó là một tổ chức có nguồn gốc mập mờ hoặc thường đưa ra tuyên bố phóng đại, thì nên bỏ qua điểm số, thay bằng dấu sao cho xong
  • Dù vậy, loại nghiên cứu này có thể vẫn là một insight gây sốc với các CTO hay VP không chuyên kỹ thuật. Họ chưa từng nghĩ nghiêm túc về việc điểm số thực ra đang đo cái gì

• Khá tiếc là bản thân blog trông như do AI viết
  Câu “nó đã lợi dụng cách tính điểm mà không hề có suy luận hay năng lực thật” nghe rất rợn người

  • Toàn bộ bài viết đều có dấu vết của AI. Đặc biệt là cả hình SVG nữa. Không có lời giải mà điểm vẫn 100% thì quá kỳ lạ. Thứ LLM vẫn làm kém nhất cho đến giờ là viết văn bản dài
  • Tôi tò mò không biết trong các lớp dạy viết ở đại học bây giờ người ta xử lý mẫu phong cách của AI như thế nào. Nó lộ đến mức đọc rất mệt
  • Ý tưởng thì thú vị, nhưng kiểu nội dung như thế này đọc khá khó chịu
  • Tôi muốn hỏi là điều khiến bạn khó chịu là “việc có dùng AI để viết” tự nó đã khó chấp nhận, hay là do phong cách bài viết có vấn đề? Nếu là vế đầu thì có lẽ bạn sẽ còn phải khó chịu như vậy suốt đời
  • Viết lách vẫn thuộc về lĩnh vực nghệ thuật. AI khó mà thay thế hoàn toàn như với một số loại hình nghệ thuật khác

• Bài báo có nhắc rằng Mythos đã phát hiện tiêm mã leo thang đặc quyền và thiết kế nó để tự xóa sau khi chạy xong.
  Đây là một thành tựu ấn tượng hơn rất nhiều so với thứ benchmark ban đầu định đo. Nó giống kiểu tình huống Kobayashi Maru

• Tôi nghĩ đây là một nghiên cứu rất hay từ nhóm của Dawn Song.
  botsbench.com cũng đã bổ sung nhiều cơ chế bảo vệ để ngăn các kiểu tấn công như vậy.

  • Contamination: các mô hình lớn đã biết sẵn đáp án do học từ Internet
  • Sandboxing: cô lập thực thi để agent không thể tấn công test harness
  • Isolation: tạo sandbox mới cho từng bài để ngăn rò rỉ bộ nhớ
    Nó lại khiến tôi nhớ đến câu của Kelvin: “Không đo được thì cũng không thể cải thiện”

• Tôi đồng cảm với câu “benchmark dùng để đo hiệu năng AI bản thân nó cũng dễ bị tấn công”
  Nhưng ở góc độ nhà nghiên cứu, việc gắn thêm một blog trông như do AI viết phía sau bài báo lại làm giảm độ tin cậy. Có lẽ chỉ đưa link bài báo thôi còn tốt hơn

• Một trong những lý do Anthropic chưa công bố Mythos ngay có thể là vì hiệu năng thực tế của nó không ấn tượng như điểm benchmark cho thấy

  • Mô hình không phải cứ lớn hơn là tốt hơn trên mọi mặt. Mô hình chuyên biệt mới là hướng đi tốt hơn, nhưng vì phải từ bỏ tài sản đầu tư hiện có nên họ không dễ chuyển hướng

• Càng có nhiều nghiên cứu kiểu này thì chính cách khai thác benchmark lại càng đi vào dữ liệu huấn luyện.
  Vì đây là nghiên cứu đại học nên nó có thể được gán trọng số cao trong dataset, và cuối cùng trở thành một kiểu lời tiên tri tự hoàn thành

  • Rốt cuộc cũng giống định luật Goodhart: “Một khi thước đo trở thành mục tiêu thì nó không còn là thước đo tốt nữa”
    Wiki về định luật Goodhart

• Ở đây có hai vấn đề riêng biệt

  1. Có nên quan tâm đến các điểm số như SWE-bench không? → Không. Đó đã là dataset công khai nên không còn nhiều ý nghĩa
  2. Điểm mấu chốt thực sự của bài này → ngay cả với benchmark không công khai, vẫn phải xem xét kỹ AI có thật sự giải bài toán hay không. Nếu chỉ tin vào tự động hóa, LLM có thể vượt qua bài test theo những cách hoàn toàn vô nghĩa

• Benchmark không được thiết kế để dùng cho kiểm thử red team.
  Bản thân ý tưởng cho rằng phải “sửa” vấn đề mà bài báo nêu ra đã là khập khiễng.
  Nó giống như lái ô tô vào một cuộc thi chạy rồi thắng, sau đó lại bảo cuộc thi nên được thiết kế theo kiểu chống ô tô vậy