Benchmark không đủ nữa rồi: RAMP đánh giá AI agent trong môi trường thực

Dạo gần đây cộng đồng AI hay nói về agentic models những model không chỉ trả lời câu hỏi mà còn tự động thực thi task, gọi tool, chạy code, rồi iterate. Nhưng có một câu hỏi mà mình thấy ít ai hỏi thẳng: benchmark hiện tại có thực sự đo được khả năng của mấy cái agent này không?

Câu trả lời ngắn gọn: không. Và paper RAMP vừa ra đã chứng minh điều đó theo cách khá brutal.

Vấn đề với benchmark kiểu cũ

Hầu hết benchmark cho coding agent hiện nay SWE-bench, HumanEval, hay các dạng tương tự đều test model trên những task isolated. Nghĩa là mỗi bài toán độc lập, không phụ thuộc nhau, không có context tích lũy từ bước trước. Giải xong task A, reset, giải task B.

Nhưng thực tế làm việc trong production không như vậy. Khi bạn build một hệ thống thực, mọi thứ có serial dependency output của bước này là input của bước tiếp theo. Nếu bước 2 fail, bước 3 không có gì để chạy. Nếu architecture bước đầu sai, toàn bộ downstream bị ảnh hưởng.

Theo kinh nghiệm của mình, đây chính xác là điểm đau khi dùng AI assistant trong các project thực. Model có thể viết một function đẹp trong isolation, nhưng khi integrate vào codebase lớn hơn, với context phức tạp hơn mọi thứ bắt đầu vỡ.

RAMP dùng compiler construction để test và đây là lý do rất hợp lý

Nhóm nghiên cứu chọn xây dựng compiler làm workload chính, cụ thể là pipeline 6 stage dựa trên YatCC:

Tại sao compiler? Vì đây là một trong những domain có strict dependency chain rõ ràng nhất trong software engineering. Bạn không thể generate LLVM IR nếu chưa có AST đúng. Bạn không thể có AST nếu parser sai. Mỗi artifact là input bắt buộc của stage tiếp theo không có shortcut.

Mình thấy cái này hay ở chỗ: nó không phải toy problem, nhưng cũng không phải một codebase enterprise hàng triệu dòng mà không ai có thể reproduce. Compiler construction là bài toán có scope rõ ràng, có ground truth để verify, và đủ phức tạp để phân biệt model thực sự capable hay chỉ đang "trông có vẻ hoạt động".

Resurrection Protocol cái trick thông minh nhất trong paper này

Đây là phần mình thích nhất về mặt methodology.

Vấn đề với long-horizon task evaluation: nếu agent fail ở stage T2, thì T3, T4, T5 đều không chạy được. Kết quả cuối cùng là model bị điểm 0 cho toàn bộ downstream nhưng điều đó không nói lên được tại sao nó fail, hay liệu nó có capable ở các stage sau không.

RAMP giải quyết bằng Resurrection Protocol: khi agent fail một intermediate task, orchestrator tự động inject một "golden artifact" tức là output hoàn hảo của stage đó và cho agent tiếp tục từ đó.

Kết quả? Bạn có thể phân biệt hai loại failure hoàn toàn khác nhau:

• "Cannot reach": Agent fail vì không làm được stage hiện tại
• "Cannot solve": Agent có thể làm stage sau, nhưng không thể tự mình đến được đó

Trong production debugging, đây là sự khác biệt cực kỳ quan trọng. Nó giống như việc bạn test một junior dev: thay vì chỉ đánh giá end result, bạn muốn biết cụ thể họ stuck ở đâu và tại sao.

15 model SOTA, không cái nào finish được pipeline

Okay, đây là phần mà mình nghĩ nhiều người sẽ bị shock.

Nhóm nghiên cứu test 15 model bao gồm Opus-4.7, GPT-5.5, DeepSeek-v4-Pro, Qwen-3.6-Max những cái tên đang được coi là SOTA hiện tại. Kết quả:

Không một model nào hoàn thành toàn bộ 6-stage pipeline.

Model perform tốt nhất Opus-4.7 bị stuck ở stage T4 (IR Generation). Tức là ngay cả model mạnh nhất hiện tại cũng không đi được đến finish line.

Nhưng cái shocking hơn là phân tích về failure taxonomy. Lý do fail phổ biến nhất không phải là model không biết thuật toán, không phải logic sai mà là Context Failure, chiếm đến 60% các hard-stop. Và nó xảy ra chủ yếu ở T2-T3, khi history và code artifact bắt đầu tích lũy đủ nhiều để overwhelm context window.

Anh em lưu ý điều này: chúng ta đang đầu tư rất nhiều vào việc làm cho model "thông minh hơn", nhưng bottleneck thực tế trong production workload lại là context management. Model không fail vì ngu nó fail vì bị chết đuối trong context của chính nó.

Cost gap 2525x con số này nói lên rất nhiều thứ

Một phát hiện khác mà mình thấy rất practical: chi phí inference giữa các model chênh lệch cực kỳ lớn.

2525x difference giữa rẻ nhất và đắt nhất. Và khi nhìn vào raw task reward thì Opus-4.7 win nhưng khi nhìn vào composite efficiency thì câu chuyện hoàn toàn khác.

Đây là lý do RAMP đề xuất metric mới: Agent Efficiency Index (AEI), đo đồng thời:

• Task effectiveness (làm được bao nhiêu)
• Time (mất bao lâu)
• Cost (tốn bao nhiêu tiền)
• Token utilization (dùng context hiệu quả không)

Dưới AEI, ranking đảo ngược hoàn toàn: GPT-5.5 đứng đầu với AEI 81.57, còn Opus-4.7 dù có raw reward cao nhất lại chỉ đạt AEI 40.00 vì resource overhead quá lớn.

Theo kinh nghiệm của mình khi làm việc với các team product, đây chính xác là cách mà engineering manager và CTO suy nghĩ khi chọn model cho production. Accuracy alone không đủ bạn phải tính đến latency, cost per request, và scalability. RAMP đang formalize cái intuition đó thành một metric cụ thể.

Tại sao điều này quan trọng với chúng ta những người đang build real systems

Nếu bạn đang evaluate xem nên dùng AI agent nào cho internal tooling, code review automation, hay bất kỳ agentic workflow nào trong team benchmark score trên HumanEval hay SWE-bench không đủ để ra quyết định.

RAMP chỉ ra rằng có một khoảng cách lớn giữa "model giỏi giải isolated coding puzzle" và "model có thể sustain performance qua một long-horizon engineering task với real dependencies". Và hiện tại, không có model nào bridge được gap đó hoàn toàn.

Cái mình takeaway từ paper này cho workflow thực tế:

1. Context window management là bottleneck thực sự khi design agentic pipeline, hãy nghĩ đến cách compress và summarize context ở các checkpoint, đừng để history tích lũy unbounded
2. Raw capability ≠ production suitability model đắt nhất, mạnh nhất không có nghĩa là lựa chọn tốt nhất cho use case của bạn
3. Failure mode analysis quan trọng hơn average score biết model fail ở đâu và tại sao còn quan trọng hơn biết nó đạt bao nhiêu điểm trung bình

Code và leaderboard của RAMP public tại ramp.yatcc-ai.com nếu bạn đang research về agentic systems thì đây là một benchmark đáng để theo dõi, đặc biệt khi nó tiếp tục được update với các model mới.