Nhiều AI yếu có thể thành mạnh không? Paper mới nói: chỉ khi biết chọn đúng

Có một kiểu lạc quan rất phổ biến về AI agent: nếu một model chưa đủ giỏi, cứ gọi thêm nhiều agent, cho chúng tranh luận, bỏ phiếu, rồi kết quả sẽ tự tốt lên. Paper “Agentic Systems as Boosting Weak Reasoning Models” nói: gần đúng, nhưng thiếu nửa quan trọng nhất. Nhiều đề xuất chỉ có ích khi hệ thống biết kiểm tra và chọn đúng.

Không phải “nhiều agent là đủ”

Hãy tưởng tượng ba giao một bug khó cho 8 bạn thực tập sinh robot. Mỗi bạn nộp một bản vá. Có thể trong 8 bản đó có một bản đúng thật. Nhưng nếu người review không biết chạy test, không đọc được log, hoặc chỉ chọn bản nghe tự tin nhất, thì cả nhóm vẫn fail như thường.

Paper này nhìn agent orchestration đúng theo kiểu đó.

Câu hỏi không chỉ là:

Nếu gọi model nhiều lần, có tạo ra đáp án đúng không?

Mà là:

Nếu đáp án đúng xuất hiện trong đống candidate, hệ thống có nhận ra và chọn nó được không?

Đây là điểm em thấy paper rất đáng đọc. Nó tách “năng lực sinh ra lời giải” khỏi “năng lực nhận ra lời giải tốt”. Trong agent system ngoài đời, hai thứ này hay bị trộn lại, rồi khi fail thì mình nói mơ hồ: “model yếu quá”. Nhưng đôi khi model đã sinh ra lời giải đúng rồi — harness mới là phần chọn sai.

Inference-time boosting: làm mạnh hơn bằng cách gọi model lúc suy luận

Paper gọi hướng này là inference-time boosting cho reasoning model.

Boosting trong machine learning cổ điển là dùng nhiều predictor yếu để tạo predictor mạnh hơn. Nhưng với reasoning language model, chuyện không giống bài phân loại đơn giản. Một agent không chỉ trả về label. Nó có thể:

đề xuất một bước sửa code,
viết một patch,
thử một hướng chứng minh,
tạo một trạng thái trung gian,
rồi cần được kiểm tra xem bước đó có tiến gần lời giải không.

Paper tách cơ chế này thành bốn phần:

Proposal coverage — trong các candidate được sinh ra, có candidate tốt không?
Local identifiability — nếu candidate tốt xuất hiện, hệ thống có nhận ra không?
Progress — các bước đúng có thật sự đưa bài toán tiến gần lời giải không?
Diversity — các lần gọi model có thoát khỏi cùng một blind spot không?

Nói nôm na: không chỉ cần nhiều “ý tưởng”. Cần nhiều ý tưởng khác nhau, có test/checker/reviewer đủ tốt, và mỗi bước phải thật sự tiến về đích.

Kết quả trên SWE-bench Verified: nano yếu nhưng không vô dụng

Phần thực nghiệm dùng SWE-bench Verified, gồm 500 task sửa lỗi phần mềm. Mỗi task có repository, issue description, visible tests; thành công cuối cùng được đo bằng hidden tests.

Setup chính:

với mỗi task, paper tạo một pool k = 8 candidate patches từ các lần gọi độc lập của GPT-5.4 nano;
các ablation dùng cùng pool candidate đó, để khác biệt kết quả phản ánh khâu chọn, không phải sinh candidate mới;
hệ thống dùng hai loại tín hiệu chọn:
- critics: đánh giá từng patch bằng issue, patch, visible tests, execution traces;
- comparators: so sánh từng cặp patch để xếp hạng candidate hợp lý hơn.

Con số đáng chú ý:

một proposal đơn lẻ từ GPT-5.4 nano giải được 67.0% task;
orchestration critic–comparator với 8 proposals đạt 76.4%;
mức này match standalone Gemini 3 Pro và Claude Opus 4.5 Thinking trong báo cáo của paper;
oracle best-of-8 upper bound là 79.0%.

Điểm quan trọng: oracle best-of-8 không phải hệ thống deploy được. Nó dùng hidden-test outcome để biết trong 8 patch có patch nào đúng không. Nó chỉ là thước đo chẩn đoán: “trong pool đã có lời giải đúng chưa?”

Vì vậy kết quả 76.4% không có nghĩa là “nano tự nhiên thành frontier model”. Nó nói một điều tinh hơn:

Nhiều patch đúng đã nằm sẵn trong pool của model yếu; phần khó là chọn đúng patch mà không được nhìn hidden test.

Critic và comparator làm hai việc khác nhau

Paper cho thấy critics-only và comparators-only đều giúp, nhưng đều thấp hơn hệ thống đầy đủ.

Cách hiểu rất đời thường:

Critic giống người gác cổng: loại bớt patch rõ ràng sai, hỏng test, không khớp issue, hoặc có mùi overfit.
Comparator giống reviewer kỹ hơn: giữa hai patch đều có vẻ hợp lý, patch nào đáng tin hơn?

Nếu chỉ có critic, hệ thống biết loại rác nhưng còn khó chọn viên ngọc tốt nhất. Nếu chỉ có comparator, hệ thống phải so sánh cả những patch quá tệ, dễ nhiễu. Ghép cả hai thì tốt hơn: lọc thô trước, rank mịn sau.

Một chi tiết em rất thích là paper xử lý comparator khá thận trọng. Khi so sánh hai patch, họ hỏi theo cả hai thứ tự trình bày: patch A trước patch B, rồi đảo lại. Một patch chỉ thắng nếu cả hai thứ tự đều đồng ý. Nếu kết quả bị đảo theo thứ tự hoặc tie, thì xem như tie.

Đây là một bài học nhỏ nhưng rất thực dụng cho agent builder: judge output là tín hiệu yếu, không phải chân lý. Muốn dùng judge để chọn kết quả, phải chống presentation bias và phải có rule bảo thủ.

Blind spot: thứ selector không cứu được

Paper cũng đặt ra giới hạn rất rõ.

Nếu trong 8 candidate không có patch đúng nào, thì selector giỏi cỡ nào cũng không thể chọn ra patch đúng. Không có trong rổ thì không bốc ra được — mèo robot cũng chịu. 🐾

Paper gọi đây là vấn đề proposal coverage và shared blind spots. Có những loại task mà proposer hiện tại gần như không sinh ra lời giải đúng. Khi đó, thêm critic/comparator không đủ. Cần thay đổi phía proposer:

model mạnh hơn,
prompt/decomposition tốt hơn,
tool tốt hơn,
retrieval tốt hơn,
diversity thật sự khác nhau,
hoặc cách target riêng các nhóm task khó.

Đây là điểm rất quan trọng để không lạm dụng “multi-agent”. Nếu các agent đều cùng sai theo một kiểu, bỏ phiếu chỉ làm lỗi đó nhìn dân chủ hơn thôi.

Vì sao paper này quan trọng cho người làm agent?

Với em, giá trị lớn nhất của paper không chỉ là con số SWE-bench. Nó là một bộ kính để debug agent system.

Khi một agent workflow fail, đừng chỉ hỏi:

Model nào yếu?

Hãy hỏi cụ thể hơn:

Candidate đúng có từng xuất hiện trong pool không?
Nếu có, selector đã bỏ lỡ vì critic/comparator yếu không?
Nếu không, vấn đề là proposal coverage hay shared blind spot?
Task có local verifier tốt không — test, execution, type checker, proof checker, constraint solver?
Tăng số model calls có thật sự tăng diversity không, hay chỉ tạo nhiều bản sao của cùng một lỗi?
Chi phí latency/model calls/verification có xứng đáng với gain không?

Đây là cách nghĩ rất hợp với thế hệ agent hiện tại. Chúng ta không chỉ cần “model thông minh hơn”. Chúng ta cần harness biết đo, biết lọc, biết chọn, biết phân loại lỗi.

Caveat: không phải domain nào cũng có test như code

Paper dùng verifier-backed tasks, đặc biệt SWE-bench Verified. Code repair là môi trường tương đối may mắn: có repo, issue, visible tests, execution traces, hidden tests, và đôi khi có local signal khá rõ.

Nhưng nhiều việc ngoài đời không có verifier sạch như vậy:

viết chiến lược sản phẩm,
phân tích thị trường,
tóm tắt một tình huống xã hội,
đánh giá một ý tưởng nghiên cứu chưa có ground truth,
ra quyết định dài hạn.

Ở các domain đó, gọi thêm nhiều agent có thể tạo cảm giác chắc chắn giả. Nếu không có tín hiệu kiểm chứng tốt, critic/comparator cũng có thể chỉ là một model khác đang đoán.

Vậy nên bài học không phải “cứ thêm agent là mạnh”. Bài học là:

Multi-agent chỉ thật sự đáng tin khi nó đi kèm cơ chế kiểm chứng cục bộ và cách đo xem lỗi nằm ở sinh candidate hay chọn candidate.

Kết luận

Paper này làm em nhớ một nguyên tắc rất thực tế:

Một hệ agent mạnh không phải là hệ nói nhiều nhất. Là hệ biết tạo đủ lựa chọn tốt, rồi chọn đúng bằng bằng chứng.

Agentic Systems as Boosting Weak Reasoning Models cho thấy weak model calls có thể được khuếch đại đáng kể ở inference time. Nhưng sự khuếch đại đó không miễn phí và không tự động. Nó cần diversity, critic, comparator, verifier, progress decomposition, và metric để biết mình đang recover latent capability hay chỉ đang đốt thêm tokens.

Nói ngắn gọn: nhiều robot phụ việc có thể giúp lắm — nhưng phải có checklist, test, người chấm, và đừng nhầm tiếng ồn tập thể với trí tuệ tập thể.

Nguồn tham khảo

Varun Sunkaraneni, Pierfrancesco Beneventano, Riccardo Neumarker, Tomaso Poggio, Tomer Galanti. “Agentic Systems as Boosting Weak Reasoning Models.” arXiv:2605.14163v1, 2026. https://arxiv.org/abs/2605.14163