- Công bố kết quả benchmark so sánh chất lượng bản vá của ba mô hình GPT-5.5, GPT-5.4 và Opus 4.7 trên 56 tác vụ lập trình thực tế được trích xuất từ hai kho mã nguồn mở (Zod, graphql-go-tools)
- GPT-5.5 đạt thành tích cao nhất ở mọi chỉ số: tỷ lệ vượt qua kiểm thử, mức độ tương đương với bản vá của con người, và tỷ lệ vượt review mã (clean pass)
- Opus 4.7 tạo ra các bản vá nhỏ nhất và có rủi ro footprint thấp, nhưng có mẫu thất bại lặp lại là triển khai không trọn vẹn do bỏ sót các tác vụ đi kèm
- Chỉ vượt qua kiểm thử thôi chưa đủ để đánh giá chất lượng bản vá; cần đánh giá đa tầng bao gồm cả mức độ được reviewer chấp nhận
- Thứ hạng của cùng một mô hình thay đổi tùy theo kho mã, nên chạy benchmark trên chính codebase của bạn là yếu tố then chốt khi chọn mô hình
Tổng quan benchmark và môi trường chạy
- So sánh ba mô hình trên tổng cộng 56 tác vụ lập trình thực tế: 27 tác vụ từ Zod và 29 tác vụ từ graphql-go-tools
- Mỗi mô hình được chạy với cấu hình mặc định trong agent harness chính thức của riêng mình: Opus 4.7 dùng Claude Code, còn GPT-5.4 và GPT-5.5 dùng OpenAI Codex CLI
- Mức reasoning của tất cả mô hình được thống nhất ở high
- Dùng framework đánh giá Stet để chấm đa tầng ngoài việc pass test, bao gồm tương đương hành vi, khả năng được review mã chấp nhận, rủi ro footprint, cùng rubric về tay nghề (craft) / kỷ luật (discipline)
- Chạy 1 lần cho mỗi tác vụ với một seed duy nhất; mô hình dùng để chấm tính tương đương và rubric là GPT-5.4
Tóm tắt kết quả tổng thể
- GPT-5.5 đứng đầu mọi chỉ số với 38/56 tác vụ pass test, 40/56 tương đương với bản vá của con người, và 28/56 clean pass
- Opus 4.7 đạt 33/56 pass test, 19/56 tương đương, 10/56 clean pass, là mô hình có điểm chất lượng thấp nhất
- Tuy vậy, mô hình này có rủi ro footprint trung bình 0.20, thấp nhất, nên vượt trội về kích thước bản vá
- GPT-5.4 đạt 31/56 pass test, 35/56 tương đương, 11/56 clean pass
- Có chi phí $2.39 cho mỗi tác vụ là thấp nhất, nhưng không đủ bù đắp khoảng cách ở clean pass
- GPT-5.5 có thời gian xử lý trung bình 6 phút 56 giây mỗi tác vụ, với 201.8M token đầu vào và 0.72M token đầu ra, nên cũng đứng đầu về hiệu quả
Phân tích kết quả theo từng kho mã
- Zod (27 tác vụ): GPT-5.5 và Opus cùng pass 12 bài kiểm thử, nhưng GPT-5.5 có 10 clean pass so với 5 của Opus, cho thấy chất lượng review tốt hơn
- Opus vượt trội về kích thước diff, nên ở Zod tồn tại một trade-off thực tế
- graphql-go-tools (29 tác vụ): GPT-5.5 vượt trội rõ rệt với 26 bài test pass và 18 clean pass
- Opus pass 21 bài test nhưng chỉ có 5 clean pass, cho thấy chiến lược bản vá nhỏ đã dẫn tới bỏ sót công việc tích hợp
Các chỉ số chất lượng chi tiết
- Vượt review mã: GPT-5.5 33/56, GPT-5.4 16/56, Opus 11/56
- Điểm review mã trung bình (độ đúng + độ an toàn về bug): GPT-5.5 3.08, GPT-5.4 2.59, Opus 2.33
- Riêng độ đúng (correctness): GPT-5.5 3.16 vs GPT-5.4 2.60 vs Opus 2.11
- Độ an toàn khi tránh đưa bug mới vào: GPT-5.5 3.04 vs GPT-5.4 2.56 vs Opus 2.55
- Điểm trung bình của bộ chấm tùy chỉnh (8 rubric): GPT-5.5 2.62, GPT-5.4 2.40, Opus 2.33
- Điểm tay nghề (clarity/coherence/robustness): GPT-5.5 đứng đầu ở cả ba hạng mục con
- Điểm kỷ luật (scope discipline/diff minimality): GPT-5.5 2.36 nhỉnh hơn một chút, Opus 2.20
- Dù Opus dẫn trước về footprint thô, nhưng xét theo mức kỷ luật tương đối so với yêu cầu tác vụ, GPT-5.5 tốt hơn
Pass test không phải tiêu chí phán quyết cuối cùng
- Ở Zod, Opus và GPT-5.5 cùng pass 12 bài test, nhưng clean pass là GPT-5.5 10 so với Opus 5
- Ở graphql-go-tools, cùng một mẫu này còn rõ hơn: GPT-5.5 có 26 test pass / 18 clean pass, còn Opus là 21 test pass / 5 clean pass
- Trường hợp GraphQL PR #1001: cả ba mô hình đều pass test và được đánh giá là tương đương, nhưng chỉ GPT-5.5 vượt qua review mã
- Hai mô hình còn lại bị cảnh báo ở hình dạng API, việc lộ đối tượng raw HTTP, và độ vững chắc ở ranh giới hook
Những khác biệt cụ thể thể hiện qua review mã
- Tác vụ codec bất đồng bộ và giá trị mặc định trong Zod: cả ba mô hình đều fail test
- Opus sửa 8 file nhưng bỏ sót ngữ nghĩa cốt lõi (cho phép
undefined trong giá trị mặc định, giữ định nghĩa codec ở dạng đồng bộ)
- GPT-5.4 vá 11 file, được công nhận là tương đương nhưng lại siết quá mức API lân cận (
prefault)
- GPT-5.5 cũng fail test nhưng bao phủ hành vi schema/build gọn gàng hơn, nên đạt điểm cao nhất về độ đúng và rủi ro bug
- Kiểm chứng tương thích GraphQL Apollo (PR #1169): cả ba mô hình đều pass test, nhưng chỉ GPT-5.5 pass cả tương đương lẫn review
- Opus sửa 11 file, nhưng bỏ sót kiểm chứng leaf cho enum/wrapping scalar
- GPT-5.4 sửa 12 file, song mở rộng phạm vi quá mức với metadata kiểm chứng vô điều kiện
- GPT-5.5 chỉ sửa 10 file (6 file không phải test), ít nhất nhưng vẫn triển khai chính xác hành vi mục tiêu
Đặc điểm và giới hạn của Opus 4.7
- Tạo ra các bản vá bảo thủ, chính xác và có footprint thấp
- Phát huy thế mạnh khi tác vụ mang tính cục bộ và bề mặt thay đổi hẹp
- Mẫu thất bại lặp lại: chỉ triển khai hành vi cốt lõi nhưng không hoàn tất các công việc đi kèm (companion work)
- Trong trường hợp cây song song Node/Deno của Zod: Opus chỉ sửa 4 file và pass test, còn GPT-5.5 sửa 11 file bao gồm cả bề mặt phân phối song song nên tương đương với bản vá của con người
- Ở graphql-go-tools, vấn đề còn nghiêm trọng hơn: tại PR #1155 (nhiều thay đổi trên bề mặt engine như trường scalar lặp lại của datasource gRPC), Opus thậm chí không tạo được bản vá, trong khi chỉ GPT-5.5 pass cả test, tương đương và review
- Điểm phân biệt cốt lõi: bản vá nhỏ của Opus là kỷ luật ở tác vụ cục bộ, nhưng là triển khai chưa hoàn tất ở tác vụ tích hợp
Thay đổi từ GPT-5.4 sang GPT-5.5
- GPT-5.4 thường tìm đúng hướng tiếp cận nhưng thất bại ở khâu thực thi
- Ở Zod, mô hình này có 18 tác vụ tương đương (bằng GPT-5.5) nhưng chỉ pass test 9 tác vụ
- GPT-5.5 giữ được hành vi tích hợp rộng hơn đồng thời ít tạo ra bản vá hỏng hơn
- So sánh các trường hợp cụ thể:
- Bộ sinh schema→TypeScript: Opus và GPT-5.5 cùng triển khai recursive visitor, còn GPT-5.4 lại hiểu sai tác vụ thành tạo file hướng dẫn cho kho mã
- Sửa parser đệ quy: cả hai mô hình GPT đều dùng cách theo dõi số lần thăm, nhưng GPT-5.5 loại bỏ trạng thái không cần thiết nên gọn hơn
- Kiểm chứng CIDR: GPT-5.5 cập nhật cả bản mirror cho Deno, trong khi GPT-5.4 không phản ánh phần mirror này (vấn đề vệ sinh kho mã)
- Trong graphql-go-tools PR #1232 (loại bỏ trùng lặp single fetch giống nhau + viết lại tham chiếu phụ thuộc): chỉ GPT-5.5 pass cả test, tương đương và review
- Tóm tắt mẫu hành vi: GPT-5.5 thực hiện tốt hơn các công việc tích hợp nhàm chán nhưng cần thiết để biến một chỉnh sửa cục bộ thông minh thành thay đổi có thể triển khai được trên kho mã
Trade-off giữa kích thước bản vá và chi phí
- Kích thước bản vá trung bình ở graphql-go-tools: GPT-5.5 khoảng 33KB, GPT-5.4 là 27KB, Opus là 19KB
- Điểm footprint: Opus 0.19, GPT-5.4 0.32, GPT-5.5 0.34
- Bản vá lớn làm tăng độ khó review, khả năng xung đột và rủi ro chạm vào các đường đi nhạy cảm
- Trong workflow ưu tiên khả năng audit, Opus vẫn có lợi thế thực tế
- Tuy nhiên, nếu đánh giá diff minimality theo mức tương đối so với yêu cầu tác vụ, GPT-5.5 lại nhỉnh hơn một chút
- Điểm cốt lõi: một bản vá 5KB bỏ sót bề mặt cần thiết không tối giản hơn một bản vá 20KB hoàn tất được tác vụ
- So sánh chi phí:
- Ở Zod, Opus và GPT-5.5 gần tương đương nhau (Opus $45.53 vs GPT-5.5 $46.69)
- Ở graphql-go-tools, Opus dùng 186.1M token đầu vào / 934K đầu ra / 8.56h thời gian agent, còn GPT-5.5 là 151.4M / 431K / 4.16h, nên GPT-5.5 hiệu quả hơn nhiều
Tóm tắt đặc tính hành vi theo từng mô hình
- Opus 4.7 — under-reach: bảo thủ, chính xác, footprint thấp, mạnh ở tác vụ cục bộ nhưng yếu ở các bề mặt đi kèm mà test không bao phủ đầy đủ; kiểu thất bại là “pass test nhưng không phải cùng một thay đổi”
- GPT-5.4 — đúng hình thức, sai thực thi: định hướng đúng nhưng không ổn định; thường xuyên xuất hiện bản mirror lỗi thời, refactor không cần thiết, và các bản vá được bộ chấm đánh giá cao hơn so với kết quả test
- GPT-5.5 — rộng hơn, footprint lớn hơn: hoàn thiện hơn ở bề mặt tích hợp, cập nhật code xung quanh tốt hơn, dễ vượt review hơn, và có tỷ lệ chuyển hóa hành vi mong muốn thành mã thực tế cao hơn; rủi ro là khi sai thì lỗi lan trên nhiều file hơn
Khác biệt trong hành vi của agent
- Ở graphql-go-tools, Opus trung bình gọi lập kế hoạch tường minh 3.17 lần mỗi tác vụ, còn GPT-5.5 là 0 lần
- Opus gọi vá lỗi 10.2 lần mỗi tác vụ, còn GPT-5.5 là 9.9 lần, gần tương đương
- GPT-5.5 thực hiện số lần gọi shell gần gấp đôi và cũng gọi tìm kiếm nhiều hơn, trong khi Opus tiêu tốn nhiều ngân sách hơn cho lập kế hoạch và viết lại bản vá
- Trong kho mã này, việc khám phá kho rộng hơn đã hiệu quả hơn việc suy nghĩ kỹ hơn về một bản vá hẹp
Vì sao kết quả này quan trọng
- Câu hỏi cốt lõi không phải “mô hình nào tốt nhất”, mà là “trong kho mã này, với harness này, và với loại tác vụ thực tế đang triển khai, có thể tin cậy bản vá của mô hình nào”
- Ở Zod, GPT-5.5 và Opus ở thế trade-off; còn ở graphql-go-tools, GPT-5.5 có ưu thế đơn giản, rõ ràng
- Benchmark công khai thường làm phẳng hành vi mô hình thành một con số tổng hợp ở quy mô lớn, nhưng trong mã thực tế, điều đó chuyển thành quyết định workflow dựa trên codebase cụ thể và tiêu chí riêng
Lưu ý
- 56 tác vụ vẫn là một mẫu nhỏ; chênh lệch một tác vụ có thể làm tỷ lệ ở cấp kho mã thay đổi vài điểm phần trăm
- Mỗi mô hình chỉ chạy 1 lần cho mỗi tác vụ, nên một số kết quả sít sao có thể đảo chiều khi chạy lại
- Mô hình dùng để chấm tương đương và rubric là GPT-5.4, nên có thể tồn tại thiên lệch cùng họ mô hình
- Tuy vậy, GPT-5.5 vẫn vượt GPT-5.4 một cách rõ rệt, lợi thế footprint của Opus vẫn được giữ, và nhiều thất bại về tương đương của Opus là do thiếu file cụ thể, nên điều này không giải thích toàn bộ kết quả
- Kết quả phụ thuộc vào harness: Claude Code và Codex CLI khác nhau về system prompt, vòng lặp lập kế hoạch và bề mặt công cụ
- Nếu chạy Opus trên Codex API hoặc GPT-5.5 trên Claude Code, kết quả có thể thay đổi
- Các con số ở đây phản ánh hành vi của mô hình trong chính harness mà kỹ sư thực tế đang dùng
Kết luận chính
- GPT-5.5 là mô hình triển khai mặc định tối ưu trên hai kho mã này
- Opus 4.7 vẫn là mô hình footprint thấp, phù hợp khi diff hẹp là ưu tiên hàng đầu
- GPT-5.4 có chi phí thấp nhất trên mỗi tác vụ, nhưng chưa đủ để bù đắp khoảng cách clean pass
- Chỉ nhìn vào test sẽ che khuất những kết quả quan trọng nhất
- Thứ hạng của cùng một mô hình thay đổi theo từng kho mã, và đó chính là lý do cốt lõi để benchmark trên kho mã của riêng bạn
1 bình luận
Đôi khi còn khiến người ta nghĩ là họ đang thông đồng với nhau.