So sánh Claude Fable 5 và GPT-5.6 Sol trên bài toán NP-khó: Tham số /goal có thực sự hiệu quả?

TL;DR: Tôi đã đưa cho Claude Fable 5 và GPT-5.6 Sol cùng một bài toán tối ưu hóa NP-hard chưa từng được công bố, với cả hai trường hợp có và không sử dụng chế độ /goal mặc định của chúng. Fable 5 thực sự là một "con quái vật"; /goal không phải là yếu tố thay đổi cuộc chơi.

Bối cảnh: Đây là một bài toán nghiên cứu vận hành từng được đưa ra cho các sinh viên tại một cuộc thi hackathon. Nhiều năm trước, tôi đã dành cả tuần để viết mã C++ nhằm giải quyết nó, vì vậy tôi có một thước đo cơ sở hữu ích từ con người.

Fable 5 thực sự là một "con quái vật" trong bài kiểm tra này. Nó tạo ra kết quả tốt nhất xét trên tổng thể, và sự ổn định của nó vượt xa bất cứ thứ gì tôi từng thấy từ một mô hình đối với bài toán này. Đây là trí tuệ thuần túy. Thật đáng kinh ngạc.

Kết quả khác cho thấy /goal không phải là một nút bấm "cố gắng hơn" chung chung. Nó thay đổi vòng lặp điều khiển và đường dẫn tìm kiếm. Đôi khi nó tìm thấy một lưu vực (basin) tốt hơn. Đôi khi nó lại cho một ý tưởng tồi thêm thời gian để phát triển.

Tất cả mã nguồn, câu lệnh (prompt), bảng kết quả, các trường hợp loại trừ và ghi chú về quỹ đạo đều nằm trong CLIArena. Đây là phần tiếp theo của bài viết đầu tiên của tôi về bài kiểm tra này.

Bài toán

KIRO là một bài toán thiết kế mạng lưới cáp quang mà tôi đã thực hiện khi còn là sinh viên kỹ thuật vào năm 2018. Với các ma trận khoảng cách có hướng cho Grenoble, Nice và Paris, trình giải phải kết nối các điểm phân phối và thiết bị đầu cuối bằng các vòng lặp và chuỗi ngắn trong khi vẫn phải tuân thủ một số ràng buộc cấu trúc. Mục tiêu là tổng chiều dài cáp. Càng thấp càng tốt.

Một mạng lưới hợp lệ bao gồm các vòng lặp dự phòng bắt nguồn từ các trung tâm phân phối, với các nhánh ngắn treo từ các tháp trên các vòng lặp đó. Mỗi tháp phải xuất hiện chính xác một lần, và việc đảo ngược một đoạn cáp có thể làm thay đổi chi phí của nó.

Không gian tìm kiếm lớn đến mức nào?

Không có một công thức đếm đóng (closed-form) duy nhất nào vì một giải pháp có thể sử dụng bất kỳ số lượng vòng lặp nào, kích thước vòng lặp thay đổi, và các nhánh được neo cũng như sắp xếp khác nhau. Nhưng chỉ riêng Paris đã cung cấp một cận dưới hữu ích.

Ngay cả khi chúng ta bỏ qua việc sắp xếp và các nhánh, chỉ gán mỗi thiết bị trong số 532 thiết bị đầu cuối cho một trong 11 trung tâm phân phối, thì đã có 11^532 cách gán khả thi.

Một cận dưới mạnh hơn đến từ một nhóm các giải pháp hợp lệ được giới hạn một cách có chủ đích: chính xác 19 vòng lặp, mỗi vòng 28 thiết bị đầu cuối, không có nhánh. Điều này bao phủ tất cả 532 thiết bị đầu cuối vì 19 x 28 = 532, trong khi vẫn nằm dưới giới hạn 30 thiết bị cho một vòng lặp. Sắp xếp 532 thiết bị đầu cuối, chia thứ tự đó thành 19 nhóm liên tiếp, chia cho 19! vì tập hợp các vòng lặp không có thứ tự, và chọn một trong 11 trung tâm cho mỗi vòng lặp:

(532! / 19!) x 11^19 ~= 10^1223

Những gì tôi đã thử nghiệm

Thử nghiệm chính được giới hạn một cách có chủ đích:

Kết quả

Trước khi tập trung các lần lặp lại vào cặp mô hình chủ lực, tôi đã chạy một cặp thử nghiệm 30 phút không gợi ý cho mỗi mô hình trong danh sách. Đối với Fable và Sol, biểu đồ sử dụng Cặp 1 từ bộ tiêu đề đã sao chép; bốn mô hình còn lại mỗi mô hình có một cặp.

Sau đó, tôi lặp lại phép so sánh chủ lực cho đến khi có ba lần chạy khớp cho Fable 5 và ba lần cho Sol.

Số âm có nghĩa là /goal tốt hơn. Goal thắng bốn trong sáu lần thử, vì vậy chỉ riêng tỷ lệ thắng cũng làm cho tính năng này có vẻ hữu ích. Các giá trị trung bình cho thấy nửa còn lại của câu chuyện:

Cả hai mô hình thường nhận được một lợi ích nhỏ và đôi khi phải chịu một sự suy giảm lớn. Đó là lý do tại sao /goal thắng hầu hết các lần chạy nhưng lại làm cho cả hai giá trị trung bình trở nên tệ hơn.

Fable cũng rõ ràng mạnh hơn. Giá trị trung bình ở chế độ thường của nó đánh bại Sol 1.875 điểm, và giá trị trung bình ở chế độ goal đánh bại Sol 1.984 điểm. Quan trọng hơn, Fable ở chế độ thường duy trì trong phạm vi nhỏ 319 điểm trong khi Sol ở chế độ thường trải dài tới 1.958 điểm. Fable ở chế độ goal tạo ra điểm số sạch tốt nhất là 31.934; Fable ở chế độ thường là cấu hình an toàn nhất.

Tìm hiểu sâu về lệnh goal

Cùng một lệnh nhưng ẩn chứa hai hệ thống khác nhau

Claude Code và Codex đều cung cấp /goal, nhưng cách triển khai lại khác biệt cơ bản.

Claude Code: một trình đánh giá riêng biệt

Claude Code triển khai /goal như một điểm dừng (Stop hook) trong phạm vi phiên làm việc. Sau mỗi lượt của mô hình chính, một mô hình đánh giá nhỏ, mặc định là Haiku, sẽ đọc điều kiện và cuộc hội thoại. Nó trả về có hoặc không kèm theo lý do. Một câu trả lời "không" sẽ bắt đầu một lượt khác; một câu trả lời "có" sẽ xóa mục tiêu.

Trình đánh giá không thể sử dụng công cụ hoặc kiểm tra tệp. Nó chỉ có thể đánh giá bằng chứng xuất hiện trong bản ghi. Điều đó có thể phát hiện việc thoát sớm, nhưng nó không thể biết liệu mười triệu lần lặp giải thuật khác có đáng giá hay không. Tài liệu về goal của Anthropic

Hãy nhớ rằng Claude Code không phải là mã nguồn mở, vì vậy chúng ta chỉ dựa hoàn toàn vào những gì Anthropic cung cấp.

Codex: trạng thái bền vững và các công cụ vòng đời

Tôi cũng đã đọc mã nguồn cho bản phát hành được kiểm chuẩn, Codex CLI 0.144.4. Codex coi một mục tiêu là trạng thái luồng bền vững:

Claude ủy quyền việc hoàn thành cho một mô hình khác. Codex cho phép mô hình đang làm việc tự tuyên bố hoàn thành, sau đó tiếp tục công việc trong khi mục tiêu bền vững vẫn hoạt động. Trình đánh giá của Claude độc lập nhưng chỉ thấy bản ghi; Codex thấy các tệp và công cụ nhưng thực tế là tự chấm điểm công việc của chính mình.

Tại sao /goal có thể thắng hầu hết các lần chạy nhưng vẫn là một thiết lập mặc định tồi

Trong một tác vụ lập trình thông thường, tiến độ thường dễ nhận thấy: một lượt khác có thể sửa lỗi hoặc hoàn thành quá trình di chuyển dữ liệu. Tối ưu hóa thì khác. Một khi tác nhân chọn một trình giải, thời gian thêm vào có thể khuếch đại một quyết định đúng hoặc một quyết định sai.

Đó chính xác là những gì đã xảy ra ở đây. Goal giúp ích khi nó duy trì danh mục biên dịch nhanh của Fable hoặc việc phân vùng chuỗi thành công của Sol. Nó gây hại khi Fable xây dựng một trình giải chậm hoặc Sol cam kết thực hiện một quá trình quét neo (anchor sweep) toàn diện. Giá trị trung vị di chuyển nhẹ theo hướng đúng; phần đuôi xấu di chuyển xa hơn nhiều theo hướng sai.

Hạn chế

Đây là một tác vụ NP-hard chưa được công bố, không phải là bảng xếp hạng lập trình chung. Chỉ có Fable và Sol là có ba cặp khớp sạch. Các so sánh khác kết hợp các câu lệnh, phiên bản wrapper và giới hạn thời gian, và các thử nghiệm chạy tuần tự thông qua các dịch vụ đăng ký có thể đã có sự sai lệch.

Các container đã lộ ra tám CPU mặc dù siêu dữ liệu tác vụ khai báo là một, điều này ưu tiên cho các danh mục song song của Fable. Mọi kết quả đầu ra được chấm điểm của Fable và Sol đều hợp lệ, một phần vì wrapper yêu cầu các điểm kiểm tra sớm và xác minh cuối cùng. Bài kiểm tra đo lường toàn bộ hệ thống: mô hình, CLI, câu lệnh, dịch vụ đăng ký và khung kiểm thử.

Tái tạo kết quả này

Tác vụ kiểm chuẩn, các wrapper, tập lệnh phân tích, trình tạo hình ảnh và bản ghi nhớ bằng chứng đầy đủ đều nằm trong CLIArena. Các thư mục công việc thô bị loại trừ khỏi Git do kích thước của chúng, nhưng bản ghi nhớ ghi lại mọi điểm số có thể công bố, phân tích theo thành phố, thời gian đã trôi qua, chiến lược, loại trừ và ID chạy.