Quantifying infrastructure noise in agentic coding evals

Anthropic · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Anthropic là nhà cung cấp model và tự chạy eval cho model của mình; các con số dưới đây là "theo Anthropic".

Bối cảnh

• Benchmark coding kiểu agent (SWE-bench, Terminal-Bench) cho model cả một môi trường để viết code, chạy test, cài dependency qua nhiều lượt; runtime không còn là container thụ động mà là một phần của bài toán. Bảng xếp hạng thường cách nhau vài điểm phần trăm và được dùng để chọn model.
• Anthropic chạy Terminal-Bench 2.0 trên GKE. Khi hiệu chỉnh, điểm không khớp bảng xếp hạng chính thức, và tới 6% task hỏng vì lỗi pod, phần lớn không liên quan khả năng của model.

Thay đổi chính

• Nguyên nhân là cách ép tài nguyên: cài đặt Kubernetes của họ đặt spec CPU/RAM mỗi task vừa là mức bảo đảm (request) vừa là trần cứng (limit). Request = limit thì không còn biên cho đột biến ngắn: một lần bộ nhớ nhảy lên là container bị OOM-kill dù lẽ ra làm xong. Nhà cung cấp sandbox của bảng xếp hạng thì cho vượt tạm thời.
• Đo ảnh hưởng: chạy Terminal-Bench 2.0 ở 6 cấu hình, từ đúng spec (1x) tới không giới hạn; giữ nguyên model, harness, bộ task.
  • Lỗi hạ tầng giảm đều: 5,8% ở 1x, 2,1% ở 3x (p < 0,001), 0,5% khi không giới hạn.
  • Từ 1x tới 3x, điểm thành công dao động trong nhiễu (p = 0,40): phần lớn task bị giết ở 1x vốn cũng sẽ thất bại.
  • Trên 3x, điểm tăng nhanh hơn lỗi giảm: tài nguyên dư cho agent dùng cách chỉ chạy được khi rộng rãi (kéo dependency lớn, chạy test suite ngốn RAM). Không giới hạn so với 1x: +6 điểm (p < 0,01). Ví dụ một task Bayesian network: model cài cả bộ pandas/networkx/scikit-learn thì hết RAM ngay lúc cài nếu chặt, model tự viết toán bằng thư viện chuẩn thì qua.
  • SWE-bench (227 bài × 10 mẫu, RAM tới 5x): cùng chiều nhưng chỉ +1,54 điểm.
• Biến ẩn khác: giới hạn thời gian, sức khoẻ cụm, cấu hình phần cứng, độ song song, băng thông ra ngoài; tỉ lệ qua dao động theo giờ trong ngày (có lẽ do latency API), chưa đo chính thức.

Vì sao

• Dưới khoảng 3x, tài nguyên thêm chỉ sửa độ ổn định hạ tầng; trên đó, nó đổi cái eval đo: giới hạn chặt thưởng chiến lược tiết kiệm, giới hạn rộng thưởng chiến lược nặng tay. Gộp cả hai vào một điểm mà không ghi cấu hình thì khó diễn giải.
• Khuyến nghị của Anthropic: eval ghi riêng mức bảo đảm và ngưỡng kill cho mỗi task thay vì một giá trị ghim; hiệu chỉnh khoảng giữa hai mức sao cho điểm ở sàn và trần nằm trong nhiễu (với Terminal-Bench 2.0, trần 3x cắt khoảng hai phần ba lỗi hạ tầng mà điểm không đổi đáng kể); báo cáo hệ số đã dùng. Chênh dưới 3 điểm trên bảng xếp hạng nên nghi ngờ cho tới khi cấu hình được công bố và khớp nhau.

Bài học cho SWE

• Một bài test end-to-end chạy trên hạ tầng thì đo cả hạ tầng: tài nguyên, thời gian, giờ chạy đều là biến gây nhiễu, phải ghi lại như biến thí nghiệm.
• Request = limit trong container là cấu hình mong manh với tải có đột biến; tách hai giá trị và chừa biên.
• Phân biệt "lỗi hạ tầng" và "thất bại thật" trong kết quả test trước khi so sánh hai bên.

Liên quan

• Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn) · Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)
• Anthropic 2025 (lỗi chất lượng do hạ tầng mà eval không bắt) · Achievers 2023 (công cụ kiểm chứng cũng phải được kiểm) · ASOS 2021 (mặc định của nền tảng là giới hạn ẩn)