Định lượng nhiễu hạ tầng trong đánh giá mã hóa tác nhân

Các chuẩn đánh giá mã hóa tác nhân (agentic coding benchmarks) như SWE-bench và Terminal-Bench thường được sử dụng để so sánh khả năng kỹ thuật phần mềm của các mô hình tiên tiến—với các vị trí dẫn đầu trên bảng xếp hạng thường chỉ cách nhau vài điểm phần trăm. Những điểm số này thường được coi là các phép đo chính xác về khả năng tương đối của mô hình và ngày càng ảnh hưởng đến quyết định về việc triển khai mô hình nào. Tuy nhiên, chúng tôi phát hiện rằng chỉ riêng cấu hình hạ tầng có thể tạo ra sự khác biệt vượt quá những mức chênh lệch đó. Trong các thử nghiệm nội bộ, khoảng cách giữa thiết lập có tài nguyên nhiều nhất và ít nhất trên Terminal-Bench 2.0 là 6 điểm phần trăm (p < 0,01).

Các chuẩn đánh giá tĩnh chấm điểm trực tiếp đầu ra của mô hình—môi trường chạy không ảnh hưởng đến kết quả. Các bài đánh giá mã hóa tác nhân lại khác: các mô hình được cung cấp một môi trường đầy đủ, nơi chúng viết chương trình, chạy thử nghiệm, cài đặt phụ thuộc và lặp lại qua nhiều lượt. Môi trường chạy không còn là một vùng chứa thụ động, mà là một thành phần không thể thiếu của quá trình giải quyết vấn đề. Hai tác nhân với ngân sách tài nguyên và giới hạn thời gian khác nhau không thực hiện cùng một bài kiểm tra.

Các nhà phát triển đánh giá đã bắt đầu tính đến điều này. Terminal-Bench 2.0, chẳng hạn, chỉ định CPU và RAM được khuyến nghị cho từng tác vụ trong bản phát hành 2.0 mới nhất của họ. Tuy nhiên, chỉ định tài nguyên không giống như việc thực thi chúng một cách nhất quán. Hơn nữa, chúng tôi phát hiện ra rằng phương pháp thực thi có thể thay đổi những gì chuẩn đánh giá thực sự đo lường.

Chúng tôi chạy Terminal-Bench 2.0 trên một cụm Google Kubernetes Engine. Trong khi hiệu chỉnh thiết lập, chúng tôi nhận thấy điểm số của mình không khớp với bảng xếp hạng chính thức của chuẩn đánh giá, và tỷ lệ lỗi hạ tầng cao đáng ngạc nhiên: có tới 6% tác vụ bị thất bại do lỗi pod, hầu hết trong số đó không liên quan đến khả năng giải quyết tác vụ của mô hình.

Sự khác biệt về điểm số xuất phát từ việc thực thi. Triển khai Kubernetes của chúng tôi coi các thông số kỹ thuật tài nguyên cho từng tác vụ vừa là mức tối thiểu vừa là mức trần cứng: mỗi container được đảm bảo các tài nguyên đã chỉ định nhưng bị tiêu diệt ngay khi vượt quá chúng. Các môi trường chạy container thực thi tài nguyên thông qua hai tham số riêng biệt: một phân bổ được đảm bảo—các tài nguyên được dành trước—và một giới hạn cứng mà tại đó container bị tiêu diệt. Khi các tham số này được đặt ở cùng một giá trị, không có khoảng trống nào cho các đột biến tạm thời: một biến động bộ nhớ nhất thời có thể OOM-kill một container mà lẽ ra đã thành công. Để giải thích cho điều này, bảng xếp hạng của Terminal-Bench sử dụng một nhà cung cấp sandboxing khác, với triển khai của họ khoan dung hơn, cho phép phân bổ quá mức tạm thời mà không chấm dứt container để ưu tiên sự ổn định của hạ tầng.

Phát hiện này đặt ra một câu hỏi lớn hơn: cấu hình tài nguyên ảnh hưởng đến điểm số đánh giá ở mức độ nào?

Để định lượng tác động của scaffold, chúng tôi đã chạy Terminal-Bench 2.0 trên sáu cấu hình tài nguyên, từ thực thi nghiêm ngặt các thông số kỹ thuật cho từng tác vụ (1x), coi chúng vừa là mức sàn vừa là mức trần, cho đến hoàn toàn không giới hạn. Mọi thứ khác đều không đổi: cùng mô hình Claude, cùng

Trong các thí nghiệm của chúng tôi, tỷ lệ thành công tăng lên cùng với mức dư thừa tài nguyên. Điều này chủ yếu đến từ việc tỷ lệ lỗi hạ tầng giảm đều đặn ở mỗi bước, từ 5,8% khi thực thi nghiêm ngặt xuống còn 0,5% khi không giới hạn. Mức giảm từ thực thi nghiêm ngặt xuống dư thừa gấp 3 lần (5,8% xuống 2,1%) có ý nghĩa thống kê với p < 0,001. Với nhiều dư thừa hơn, ít container bị tiêu diệt hơn do vượt quá phân bổ.

Từ mức 1x đến 3x, điểm số thành công dao động trong biên độ nhiễu (p=0,40). Hầu hết các tác vụ bị sập ở mức 1x đều sẽ thất bại dù thế nào đi nữa – đây là điều chúng tôi quan sát được từ dữ liệu. Tác nhân khám phá, chạm vào giới hạn tài nguyên và bị chiếm quyền ưu tiên, nhưng nó chưa bao giờ đi đúng hướng để có giải pháp chính xác.

Tuy nhiên, bắt đầu từ khoảng mức 3x, xu hướng này thay đổi: tỷ lệ thành công tăng nhanh hơn tốc độ giảm của lỗi hạ tầng.

Từ mức 3x đến không giới hạn, lỗi hạ tầng giảm thêm 1,6 điểm phần trăm, trong khi thành công tăng gần 4 điểm phần trăm. Tài nguyên bổ sung cho phép tác nhân thử các cách tiếp cận chỉ khả thi với phân bổ hào phóng, như kéo các phụ thuộc lớn, sinh ra các tiến trình con tốn kém, và chạy bộ kiểm thử ngốn bộ nhớ. Ở tài nguyên không giới hạn, mức tăng tổng thể so với mức 1x là +6 điểm phần trăm (p < 0,01). Ở các tác vụ biên, như `rstan-to-pystan` và `compile-compcert`, tỷ lệ thành công cải thiện đáng kể khi có dư thừa bộ nhớ.

Cho đến khoảng mức thông số Terminal-Bench gấp 3x, tài nguyên bổ sung giải quyết các vấn đề độ tin cậy hạ tầng, cụ thể là các đột biến tài nguyên tạm thời. Nhà cung cấp sandboxing mà người duy trì Terminal-Bench sử dụng đang ngầm làm điều này; bài đánh giá trở nên ổn định hơn mà không dễ hơn.

Tuy nhiên, trên mức 3x, tài nguyên bổ sung bắt đầu tích cực giúp tác nhân giải quyết các vấn đề mà trước đây nó không thể giải quyết, cho thấy rằng giới hạn thực sự có thể thay đổi những gì bài đánh giá đo lường. Giới hạn chặt chẽ vô tình thưởng cho các chiến lược rất hiệu quả, trong khi giới hạn hào phóng dễ tha thứ hơn và thưởng cho các tác nhân có thể khai thác tốt hơn mọi tài nguyên sẵn có.

Một tác nhân viết mã gọn nhẹ, hiệu quả rất nhanh sẽ hoạt động tốt dưới các ràng buộc chặt chẽ. Một tác nhân giải quyết vấn đề bằng vũ lực với các công cụ nặng sẽ hoạt động tốt dưới các ràng buộc hào phóng. Cả hai đều là những thứ hợp lý để kiểm tra, nhưng gộp chúng vào một điểm số duy nhất mà không chỉ rõ cấu hình tài nguyên khiến cho sự khác biệt—và khả năng tổng quát hóa trong thế giới thực—khó diễn giải.

Trên `bn-fit-modify`, một tác vụ Terminal-Bench yêu cầu khớp mạng Bayesian, bước đầu tiên của một số mô hình là cài đặt bộ công cụ khoa học dữ liệu Python tiêu chuẩn: `pandas`, `networkx`, `scikit-learn`, và toàn bộ toolchain của chúng. Dưới giới hạn hào phóng, điều này hoạt động. Dưới giới hạn chặt chẽ, pod hết bộ nhớ trong quá trình cài đặt, trước khi tác nhân viết một dòng mã giải pháp nào. Một chiến lược gọn nhẹ hơn tồn tại (triển khai toán học từ đầu chỉ bằng thư viện chuẩn), và một số mô hình mặc định làm theo cách đó. Những mô hình khác thì không. Các mô hình khác nhau có các cách tiếp cận mặc định khác nhau, và tài nguyên

Cấu hình nguồn lực quyết định cách tiếp cận nào trong số đó thành công. Chúng tôi đã tái tạo phát hiện cốt lõi trên các mô hình Anthropic khác nhau. Hướng của hiệu ứng là nhất quán, trong khi mức độ dao động. Các xu hướng tương tự dường như cũng đúng trên các mô hình khác ngoài Claude, nhưng chúng tôi chưa kiểm tra chúng một cách nghiêm ngặt.

Chúng tôi cũng đã kiểm tra xem liệu mô hình này có đúng với các bài đánh giá ngoài Terminal-Bench hay không bằng cách chạy một thí nghiệm chéo trên SWE-bench. Chúng tôi đã thay đổi tổng RAM khả dụng lên tới 5 lần so với mức cơ sở trên 227 vấn đề với 10 mẫu mỗi vấn đề. Hiệu ứng tương tự vẫn đúng, mặc dù mức độ nhỏ hơn: Điểm số lại tăng đơn điệu theo RAM, nhưng chỉ cao hơn 1,54 điểm phần trăm ở mức 5 lần so với 1 lần. Các tác vụ SWE-bench ít tốn tài nguyên hơn, vì vậy hiệu ứng nhỏ hơn là dự kiến, nhưng nó cho thấy việc phân bổ tài nguyên cũng không trung lập ở đó.

Phân bổ tài nguyên không phải là biến ẩn duy nhất. Trong một số cấu hình nhất định, giới hạn thời gian cũng bắt đầu đóng vai trò.

Về nguyên tắc, mọi yếu tố của thiết lập đánh giá đều có thể ảnh hưởng đến điểm số cuối cùng, từ tình trạng cụm máy đến thông số kỹ thuật phần cứng, từ mức độ đồng thời đến thậm chí băng thông đầu ra. Các đánh giá dạng agent về bản chất là các bài kiểm tra hệ thống đầu cuối, và bất kỳ thành phần nào của hệ thống đó cũng có thể hoạt động như một yếu tố gây nhiễu. Ví dụ, chúng tôi đã quan sát thấy một cách rời rạc rằng tỷ lệ thành công dao động theo thời gian trong ngày, có khả năng là do độ trễ API thay đổi theo mô hình lưu lượng và sự cố. Chúng tôi chưa định lượng chính thức hiệu ứng này, nhưng nó minh họa cho một điểm lớn hơn: ranh giới giữa "năng lực mô hình" và "hành vi cơ sở hạ tầng" mờ nhạt hơn so với một điểm số chuẩn duy nhất gợi ý. Một nhà cung cấp mô hình có thể bảo vệ cơ sở hạ tầng đánh giá của mình khỏi điều này bằng cách dành riêng phần cứng, nhưng các nhà đánh giá bên ngoài không thể dễ dàng làm điều tương tự.

Các chuẩn mực công khai thường được thiết kế để đo lường năng lực mô hình thuần túy, nhưng trong thực tế, chúng có nguy cơ nhầm lẫn chúng với các đặc điểm kỳ quặc của cơ sở hạ tầng. Đôi khi điều này có thể là mong muốn, vì nó cho phép kiểm tra đầu cuối toàn bộ ngăn xếp, nhưng thường thì nó là