Fable 5, Opus 4.8 và Sonnet 4.6: cách so sánh công bằng các LLM trên mã của chính bạn

Khi một mô hình mới ra mắt, thông cáo trả lời câu hỏi «nó tốt hơn bao nhiêu trên các benchmark» — và không trả lời câu hỏi duy nhất mà tôi quan tâm: nó sẽ thay đổi điều gì trong công việc của tôi. Tôi đã tiến hành một thí nghiệm có kiểm soát: ba mô hình Claude — Fable 5, Opus 4.8 và Sonnet 4.6 — nhận được nguyên văn cùng một nhiệm vụ kiểm toán cơ sở mã của blog này, mỗi mô hình trong một bản sao repository riêng biệt, với một rubric đánh giá được thống nhất trước. Trong bài viết — bản thân phương pháp, có thể lặp lại trên bất kỳ dự án nào, các kết quả, và riêng — cách thí nghiệm đã hỏng hai lần và điều đó đã dạy được gì.

Vì sao benchmark không trả lời câu hỏi của tôi

Các benchmark công khai có hai vấn đề, và cả hai đều mang tính nền tảng. Thứ nhất — ô nhiễm dữ liệu: các ví dụ kiểm thử rò rỉ vào tập huấn luyện, và mô hình một phần «nhớ lại» đáp án thay vì giải bài toán. Đây không phải là một nghi ngờ lề đường, mà là đối tượng của cả một hướng nghiên cứu: tổng quan của Xu và cộng sự (2024) hệ thống hóa các nghiên cứu về ô nhiễm benchmark, còn tổng quan EMNLP 2025 ghi nhận phản ứng của ngành — chuyển từ các bài kiểm thử tĩnh sang các bài kiểm thử được sinh động.

Vấn đề thứ hai đơn giản hơn: benchmark đo lường không phải bài toán của tôi. Tôi không cần một mô hình giải bài toán olympiad giỏi nhất. Tôi cần một mô hình tìm ra các bug thực trong blog Laravel của tôi, không bịa ra những thứ không tồn tại, và chứng minh rằng bản sửa của nó hoạt động.

Từ đó rút ra một ý đơn giản: bệ thử tốt nhất để so sánh các mô hình — chính là dự án của bạn. Mã của nó trong sự kết hợp như vậy không có trong tập huấn luyện, các bài toán trên đó — đúng những thứ tôi trả tiền, và kết quả tôi có thể kiểm tra bằng tay, vì tôi biết mã này.

Thiết kế thí nghiệm: một prompt, ba thế giới biệt lập

Nhiệm vụ cho cả ba mô hình là nguyên văn giống hệt nhau — chỉ khác tên nhánh và thư mục kết quả. Bốn giai đoạn: kiểm toán hệ thống bài viết song ngữ của blog với bằng chứng cho mỗi phát hiện dưới dạng файл:строка kèm trích dẫn mã; lựa chọn giải pháp cho ba phát hiện chính với mô tả các đánh đổi; triển khai một bản sửa với tự kiểm tra; ghi chú về kết quả bằng tiếng Nga và tiếng Anh. Một chu trình công việc kỹ thuật đầy đủ, chứ không phải một «hỏi-đáp» biệt lập — cách tiếp cận này cũng được Anthropic khuyến nghị: đánh giá các agent trên các bài toán từ sản phẩm thực, theo một rubric được thống nhất trước khi chạy.

Ba quy tắc đã làm cho so sánh trở nên công bằng:

Cô lập. Mỗi mô hình làm việc trong một git worktree riêng — bản sao thư mục làm việc của chính nó với nhánh riêng. Các mô hình về mặt vật lý không thể thấy kết quả của nhau hoặc cản trở nhau.

Bảo vệ chống ảo giác — ngay trong prompt. Dòng then chốt của nhiệm vụ: «một phát hiện bịa đặt (mã không tồn tại, dòng sai) tệ hơn là không có phát hiện». Không có động lực này, mô hình được yêu cầu tìm vấn đề có xu hướng «tìm thấy» chúng trong mọi trường hợp. Có nó — mỗi phát hiện buộc phải sống sót qua kiểm tra thủ công.

Loại trừ gợi ý khỏi tính điểm. Trong repository có CLAUDE.md, mô tả các cạm bẫy đã biết của dự án — ví dụ, đường dẫn tương đối tới asset bị hỏng trên URL có tiền tố ngôn ngữ. Cả ba mô hình đều đọc tệp này, nên những phát hiện như vậy là «miễn phí»: chúng được tính cho sự cẩn thận, nhưng không tính cho độ sâu.

Rubric: chỉ đánh giá những gì có thể kiểm tra bằng tay

Trước khi chạy, tôi đã cố định sáu trục, mỗi trục năm điểm: độ chính xác của kiểm toán (kiểm tra thủ công một mẫu các phát hiện theo файл:строка), độ sâu (các phát hiện được xác nhận không có trong gợi ý), chất lượng lập luận về các đánh đổi, mã và tính thực tế của tự kiểm tra, chất lượng văn bản tiếng Nga và tiếng Anh, kỷ luật (không câu hỏi nào cho con người, không một vi phạm ràng buộc nào). Nguyên tắc giống như ở một code review tốt: trục nào càng ít dựa vào khẩu vị và càng dựa vào sự kiện kiểm chứng được, thì càng có thể tin cậy nó.

Cách mọi thứ hỏng lần đầu

Lần chạy đầu tôi đã làm sai — và hóa ra đó lại là phần dễ chuyển giao nhất của thí nghiệm. Tôi mở ba phiên tương tác song song trong cùng một thư mục repository. Vài phút sau, trong cây làm việc có những thay đổi chưa commit không thể quy cho ai: một checkout chung nghĩa là khi một phiên thực hiện git checkout -b, nhánh chuyển cho cả ba, và các thay đổi cùng commit của chúng trộn lẫn. Một trong các phiên còn thực hiện git stash và quét vào đó mọi thứ — kể cả các tệp của chính tôi, không liên quan đến thí nghiệm.

“Các AI-agent song song trong cùng một thư mục — đó không phải là thí nghiệm song song. Đó là một xung đột lớn với ba tác giả.”

– kết luận khiến tôi phải khởi động lại

Kết quả của hai phiên phải bị coi là không dùng được: ngay cả khi chúng hoàn thành đến cùng, tôi cũng không thể trung thực nói rằng mình đang đánh giá bản sửa của ai. Lần chạy thứ hai — đã trong các worktree tách biệt — vấp phải giới hạn của gói: hai agent chết ngay khi khởi động, còn agent thứ ba bị treo trong khi vẫn trông như «đang chạy» trên giao diện. Chẩn đoán do hệ thống tệp đưa ra, chứ không phải chỉ báo trạng thái: trong hai mươi phút, bản sao làm việc của nó không xuất hiện một tệp nào. Đây là bài học có thể chuyển giao thứ hai: tính sống của agent được kiểm tra qua thay đổi trên đĩa. Sau khi khởi động lại, cả ba mô hình đều trải qua chu trình đầy đủ trong điều kiện như nhau.

Kết quả: nơi các mô hình giống nhau và nơi chúng khác nhau

Kết quả quan trọng nhất là điều đã không xảy ra: không mô hình nào có ảo giác. Tôi đã kiểm tra thủ công ba phát hiện trở lên của từng mô hình — mọi trích dẫn và số dòng đều chính xác đến từng ký tự. Với các nhiệm vụ kiểm toán, đây là ngưỡng tin cậy chính, và cả ba đều vượt qua.

Tiếp theo là những khác biệt:

	Fable 5	Opus 4.8	Sonnet 4.6
Phát hiện đã xác nhận	11	5	9
Độc đáo không tầm thường	3	1	2
Tự kiểm tra bản sửa	render tích hợp trên DB tạm, xmllint, quy kết test hỏng của người khác	linter + render; bắt được lỗi của chính mình	chỉ linter và danh sách route
Token / thời gian	164k / 21 phút	101k / 12 phút	131k / 12 phút
Tổng theo rubric (trên 30)	30	24	25,5

Khác biệt định tính có tính thông tin hơn điểm số. Opus 4.8 — mô hình duy nhất không nhận ra tiêu đề bị hỏng Content-Type trong sitemap (hai mô hình kia đã tìm ra) và để nó lại trong bản sửa của chính mình; còn trong văn bản tiếng Nga của nó lọt vào một từ tiếng Anh — «и even путь к картинке». Sonnet 4.6 đã sửa đúng, nhưng phần tự kiểm tra của nó chỉ mang tính tuyên bố: linter thay vì chạy thử. Fable 5 nổi bật đúng ở phần tự kiểm tra: nó phát hiện rằng php trên máy tôi là một wrapper trên container docker được gắn vào thư mục chính, đã dựng lại mọi kiểm tra qua các container dùng một lần và chạy bản sửa của mình theo kiểu tích hợp trên cơ sở dữ liệu tạm. Khác biệt giữa «tôi đã làm» và «tôi đã chứng minh là tôi đã làm» — đó chính là trục phân biệt mạnh nhất cho các nhiệm vụ agent.

Một tín hiệu hữu ích khác là sự hội tụ: cả ba mô hình đều độc lập gọi cùng một vấn đề với sitemap là phát hiện chính. Khi các kiểm toán viên độc lập hội tụ ở phát hiện hàng đầu, đó là một dạng thay thế rẻ tiền cho sự đồng thuận giữa các chuyên gia: vấn đề gần như chắc chắn là thật.

Giám khảo nằm trong số người tham gia

Điểm theo rubric do Fable 5 chấm — chính mô hình đã tham gia so sánh. Đây là một lỗ hổng phương pháp luận, và cần nói thẳng về nó: các giám khảo LLM có xu hướng hệ thống là chấm điểm cao hơn cho văn bản của chính mình, và xu hướng này càng mạnh khi mô hình nhận ra văn bản của mình càng tốt — điều này được chỉ ra trong công trình của Panickssery và các đồng tác giả tại NeurIPS 2024. Có thể giảm thiểu thiên lệch theo hai cách, và tôi đã dùng cả hai: thứ nhất, dịch chuyển rubric tối đa từ các trục khẩu vị sang các sự kiện có thể kiểm chứng — độ chính xác của dòng, tính đầy đủ của bản sửa, từ ngoại ngữ bị lọt vào không phụ thuộc vào thiện cảm của giám khảo; thứ hai, tuyên bố rõ ràng xung đột và giao các trục gây tranh cãi cho mô hình khác hoặc người kiểm tra chéo. Các trục chủ quan trong tổng kết của tôi — chất lượng văn bản, chất lượng lập luận — nên được đọc kèm theo hiệu chỉnh này.

Giới hạn của sự trung thực

Một lần chạy cho mỗi mô hình là n=1: khác biệt một-hai điểm không có ý nghĩa gì, chỉ nên tin vào những khoảng cách định tính — lỗi bị bỏ sót, độ sâu của tự kiểm tra. Thí nghiệm đo ba mô hình trên một nhiệm vụ trong một lĩnh vực; từ đó không suy ra được «Fable 5 nói chung là tốt hơn». Và cần nhớ về chi phí: mô hình hàng đầu đã tiêu tốn gấp 1,6 lần token và gần gấp đôi thời gian so với người tham gia tiết kiệm nhất, còn token của nó theo bảng giá lại còn đắt hơn tự thân — với các nhiệm vụ thường xuyên, đây là lập luận có trọng lượng ủng hộ các mô hình đơn giản hơn.

Điều tôi giữ lại cho mình

Phương pháp luận rút gọn thành một danh sách kiểm tra ngắn, hoạt động cho bất kỳ dự án nào và bất kỳ mô hình nào:

• Bài kiểm tra — chu trình đầy đủ của công việc thật trên mã của mình, chứ không phải một bài toán tổng hợp.
• Một prompt cho tất cả, cách ly qua các worktree riêng, kết quả — trong các nhánh riêng.
• Trong prompt — nêu rõ cái giá của ảo giác: một phát hiện bịa ra tệ hơn việc không có phát hiện.
• Các gợi ý có sẵn cho mọi người (tài liệu, ghi chú trong kho mã) bị loại khỏi phần tính điểm độ sâu.
• Rubric được cố định trước khi chạy và dựa trên các sự kiện có thể kiểm chứng, chứ không dựa trên ấn tượng.
• Mẫu các phát hiện phải được kiểm tra thủ công; sự trùng khớp của các phát hiện hàng đầu ở các mô hình độc lập — là tín hiệu về tính thực của chúng.
• Giám khảo-người tham gia — xung đột đã được tuyên bố: các trục gây tranh cãi phải giao cho đánh giá chéo.
• Tính sống của agent phải kiểm tra qua đĩa, chứ không qua chỉ báo trên giao diện.

Phần thưởng nằm ngoài kế hoạch: thí nghiệm đã tự hoàn vốn. Ba cuộc kiểm toán độc lập đã tìm ra các vấn đề thật trong blog — từ sitemap thiếu các trang tiếng Anh đến các truy vấn chết trong controller — và hai bản sửa sẵn sàng đã nằm trong các nhánh, chờ được chuyển vào prod. So sánh các mô hình trên mã của chính mình, khác với việc đọc các benchmark, để lại sau nó không chỉ là một ý kiến.

Nguồn và điểm tham chiếu

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — hệ thống hóa vấn đề ô nhiễm benchmark; lập luận chính ủng hộ việc kiểm tra trên mã của chính mình.
• Đánh giá chuẩn các LLM dưới ô nhiễm dữ liệu: Từ đánh giá tĩnh đến động (EMNLP 2025) — cách ngành công nghiệp chuyển từ các bài kiểm tra tĩnh sang động; thí nghiệm của tôi là một trường hợp riêng của bài kiểm tra động.
• Giải mã các đánh giá cho tác nhân AI (Anthropic Engineering, 2026) — thực tiễn đánh giá tác nhân: nhiệm vụ từ sản phẩm thực tế, tiêu chí có thể kiểm chứng, phân biệt quỹ đạo và kết quả.
• Các bộ đánh giá LLM nhận ra và ưu ái các thế hệ của chính chúng (NeurIPS 2024) — tại sao mô hình giám khảo đánh giá cao bản thân và cần làm gì với điều đó.
• Chạy các phiên song song với worktree (Claude Code Docs) — cơ chế tiêu chuẩn để cô lập các phiên tác nhân song song, mà nếu không có nó thì lần chạy thí nghiệm đầu tiên đã đổ vỡ.