TokenLab Fusion: Bằng chứng từ bộ dữ liệu nghiên cứu DRACO Weighted-100

Lưu ý về trạng thái nghiên cứu: TokenLab Fusion: đây là kết quả nghiên cứu dựa trên công thức chứng minh (proof-of-recipe), một kết quả nghiên cứu cơ sở mạnh mẽ mang tính lịch sử, không phải là tuyên bố về sản phẩm thương mại. Các kết quả được tạo ra bằng cách sử dụng một anchor Gemini cao cấp; một lần chạy thử nghiệm (canary run) không sử dụng gói cao cấp và một lần chạy lại cuối cùng chỉ sử dụng Fusion đang được thực hiện để xác nhận khả năng tái lập mà không cần các phụ thuộc cao cấp. DRACO weighted-100 là một đánh giá nội bộ độc quyền của TokenLab và không phải là một tiêu chuẩn đánh giá bên ngoài hoặc tiêu chuẩn hóa. Vui lòng diễn giải kết quả theo hướng này.

Tóm tắt

Báo cáo này ghi lại trạng thái bằng chứng hiện tại của TokenLab Fusion, một hệ thống điều phối suy luận đa mô hình được đánh giá dựa trên một bộ nghiên cứu đa miền cố định, có trọng số 100 (bản kê nghiên cứu DRACO weighted-100, bao gồm các tác vụ về Tài chính, Mua sắm/So sánh sản phẩm, Học thuật, Công nghệ, Kiến thức chung, Thiết kế UX, Luật, Y học, Needle-in-a-Haystack và Trợ lý cá nhân). Câu hỏi nghiên cứu trọng tâm không phải là liệu một tập hợp các mô hình có thể đạt được tổng điểm cao hơn một mô hình đơn lẻ trên một phân khúc tiêu chuẩn hay không, mà là liệu một công thức có kỷ luật (thành phần hội đồng, tổng hợp, xác thực nhận thức rubric, tìm nguồn bằng chứng và hạch toán chi phí) có thể được tổ chức thành một hệ thống có thể tái lập, kiểm toán được và nâng cấp được, vượt qua các mô hình đơn lẻ mạnh mẽ trên các miền, chứ không chỉ trên một tập hợp con thuận lợi.

Bằng chứng mạnh mẽ nhất cho đến nay đến từ lần chạy nghiên cứu weighted-100, một đánh giá có ghép cặp, hỗ trợ cơ sở so với gpt-5.5 và claude-opus-4-8 trên tập dữ liệu DRACO 100 tác vụ cố định. TokenLab Fusion đạt điểm trung bình là 86.04, với mức chênh lệch trung bình ghép cặp là +32.60 so với gpt-5.5 (thắng/thua/hòa 95/4/1, chi phí 0.71x, điểm trên mỗi đô la 2.26x) và +45.63 so với claude-opus-4-8 (thắng/thua/hòa 97/2/1, chi phí 0.69x, điểm trên mỗi đô la 3.06x). Những con số này rất mạnh, có ghép cặp và có thể tái lập dựa trên một bản kê cố định, nhưng chúng đi kèm với hai điều kiện quan trọng mà báo cáo này coi là các phát hiện hạng nhất, không phải chú thích: công thức chiến thắng đã sử dụng một mô hình Gemini Pro cao cấp lịch sử (gemini-3.1-pro-preview) làm anchor tổng hợp/giám khảo/xác thực, và trạng thái sẵn sàng phát hành của hệ thống vẫn yêu cầu một lần chạy lại cuối cùng chỉ sử dụng Fusion trước khi kết quả có thể được coi là hoàn tất. Phần còn lại của báo cáo này tách biệt những gì đã được chứng minh trong lần chạy nghiên cứu cơ sở mạnh mẽ với những gì vẫn còn bị hạn chế trước khi đưa ra bất kỳ tuyên bố sản xuất nào, và trình bày các bằng chứng cụ thể vẫn còn cần thiết, cấp bách nhất là một lần chạy thử nghiệm canary không sử dụng Gemini cao cấp, để thu hẹp khoảng cách đó.

1. Phạm vi và Mục tiêu Nghiên cứu

TokenLab Fusion được định nghĩa ở đây là sự điều phối tại thời điểm suy luận trên nhiều mô hình thượng nguồn, không phải là một mô hình đã được huấn luyện gộp trọng số. Một yêu cầu duy nhất được định tuyến qua một số vai trò mô hình (thành viên hội đồng, người tổng hợp, người xác thực, giám khảo, người đánh giá, chủ sở hữu công cụ), và công thức kiểm soát cách các đầu ra được tạo, so sánh, viết lại và trả về. Điều này gần với một cấu hình sản xuất đa mô hình có thể kiểm chứng hơn là một cuộc bỏ phiếu tập hợp không trạng thái; nó có chung nguồn gốc cấu trúc với Mixture-of-Agents và LLM-Blender, mặc dù bộ máy lựa chọn công thức và hạch toán chi phí được mô tả dưới đây vượt xa cả hai.

Mục tiêu đánh giá là bộ nghiên cứu weighted-100: một tập hợp cố định các tác vụ nghiên cứu đa miền, dày đặc bằng chứng và được chấm điểm nghiêm ngặt theo rubric. Chương trình nghiên cứu bác bỏ rõ ràng các so sánh cơ sở yếu. Các cơ sở duy nhất được chấp nhận là gpt-5.5 và claude-opus-4-8, và cả hai đều được giữ nghiêm ngặt bên ngoài các vai trò hội đồng, tổng hợp, giám khảo, xác thực và chủ sở hữu công cụ của Fusion; việc làm nhiễm bẩn hội đồng bằng mô hình cơ sở sẽ làm mất hiệu lực của bất kỳ tuyên bố nào về việc "công thức đa mô hình rẻ hơn đánh bại một mô hình đơn lẻ mạnh".

Các định danh mô hình được tham chiếu trong bài báo này--gpt-5.5, claude-opus-4-8, gemini-3.1-pro-preview, deepseek-v4-pro và glm-5.2--là các ID mô hình logic của nền tảng TokenLab Fusion và các ID cơ sở nghiên cứu được lấy từ ảnh chụp nhanh nguồn sự thật duy nhất (SSOT) của mô hình TokenLab quan sát vào ngày 2026-07-07. Các định danh này biểu thị các nhãn định tuyến và đánh giá nội bộ thay vì một bảng xếp hạng độc lập, được kiểm toán công khai, và không có tuyên bố nào cho rằng các tên này tương ứng một-một với tên gọi phát hành công khai của bất kỳ nhà cung cấp bên ngoài nào. Các định danh như gpt-5.5 và claude-opus-4-8 là các nhãn cơ sở và định tuyến nội bộ được rút ra từ SSOT của TokenLab và không nên được hiểu là các chỉ định phiên bản mô hình của nhà cung cấp công khai. Do đó, các so sánh cơ sở mạnh mẽ trong bài báo này không nên được đọc là một tuyên bố hoàn chỉnh về sự sẵn sàng sản xuất: đánh giá canary không sử dụng Gemini cao cấp và lần chạy lại chỉ sử dụng Fusion còn lại vẫn chưa hoàn thành và vẫn bị hạn chế chờ xác thực thêm. Các kết quả được trình bày ở đây đại diện cho một so sánh nghiên cứu tại một thời điểm, không phải là kết quả đánh giá sản xuất cuối cùng hoặc đã được xác thực đầy đủ.

Hai dòng sản phẩm chia sẻ cơ sở hạ tầng nghiên cứu này nhưng khác nhau về công thức: dòng Deep Research (dựa trên bằng chứng, kiểm tra tính đầy đủ của nguồn, chú trọng xác thực) và dòng Coding Agent (chú trọng thực thi công cụ, nhạy cảm với độ trễ, vẫn đang ở giai đoạn tiền Phase-0). Báo cáo này chủ yếu nói về dòng Deep Research, vì đó là nơi hiện có bằng chứng ghép cặp so với các cơ sở mạnh mẽ.

2. Tại sao lại là Bản kê 100 Tác vụ Cố định

Một lần chạy đánh giá trên một phân khúc đơn lẻ không thể hỗ trợ các quyết định về công thức. Bản kê 100 tác vụ tồn tại để phục vụ đồng thời sáu chức năng kỹ thuật riêng biệt: lựa chọn công thức đa miền (tránh quá khớp với một phân khúc may mắn), dữ liệu huấn luyện chính sách bộ định tuyến, bằng chứng phân công vai trò mô hình, xây dựng đường cong chi phí/chất lượng/độ trễ, thư viện lỗi để kiểm thử hồi quy và các canary nâng cấp mô hình trong tương lai, và một tập hồi quy phân lớp có thể tái sử dụng không cần chạy lại toàn bộ mỗi khi một mô hình thượng nguồn thay đổi.

Bản kê được sử dụng trong các thí nghiệm được báo cáo là weighted-100-v1, một phân khúc có trọng số xác định với mã băm tập tác vụ cố định (b08a09aacbc76c5e5aafd5ca0a6fa614a5061bc478f905007ae5aee4a93fc43a). Trọng số miền của nó không đồng nhất: Tài chính (20), Mua sắm/So sánh sản phẩm (16), Học thuật (12), Công nghệ (10), Kiến thức chung (9), Thiết kế UX (9), Luật (6), Y học (6), Needle-in-a-Haystack (6), Trợ lý cá nhân (6). Sự phân bổ này quan trọng vì lợi ích của Fusion phụ thuộc vào miền, và Tài chính đặc biệt mang rủi ro mở dai dẳng nhất (Phần 6).

DRACO weighted-100 là một tập dữ liệu nghiên cứu nội bộ của TokenLab được sử dụng độc quyền trong quy trình đánh giá TokenLab Fusion của bài báo này. Nó không phải là một tiêu chuẩn đánh giá bên ngoài, được duy trì công khai, và không liên kết với, được xác nhận bởi, hoặc được rút ra từ bất kỳ bộ tiêu chuẩn đánh giá của bên thứ ba nào. Bản kê weighted-100, bao gồm việc lấy mẫu mục, sơ đồ trọng số danh mục và siêu dữ liệu nguồn gốc, được quản lý bởi một bản đồ nguồn TokenLab riêng tư không được xuất bản cùng với bài báo này. Do đó, các điểm số được báo cáo nên được hiểu là các tín hiệu so sánh nội bộ cụ thể cho phương pháp đánh giá của TokenLab thay vì là các điểm số có thể so sánh với các bảng xếp hạng công khai hoặc các tiêu chuẩn cộng đồng. Độc giả không nên cho rằng kết quả DRACO weighted-100 có thể khái quát hóa cho, hoặc có thể tham chiếu chéo với, bất kỳ tập dữ liệu nào khác mang tên hoặc cấu trúc tương tự.

3. Phương pháp luận

Vòng lặp nghiên cứu lấy bằng chứng làm đầu tiên: mọi tuyên bố mạnh mẽ phải có thể truy xuất nguồn gốc đến một bản kê cố định, ID tác vụ, trọng số miền, cài đặt thời gian chạy, tệp kết quả thô, hàng chi phí và hàng cơ sở. Các con số tóm tắt tổng hợp không có các hiện vật đó không được coi là bằng chứng.

Bốn cam kết về phương pháp luận là quan trọng nhất.

Chia sẻ bằng chứng thay vì tìm kiếm gốc không minh bạch

Các công cụ tìm kiếm, lấy dữ liệu và đọc tạo ra một gói bằng chứng bên ngoài các mô hình đang được thử nghiệm, và gói đó được cung cấp cho cả hội đồng và các mô hình cơ sở bất cứ khi nào khả thi. Điều này tách biệt "liệu mô hình có thể suy luận và tổng hợp tốt không" khỏi "liệu mô hình có tình cờ tìm kiếm tốt không", và đây là yêu cầu nghiêm ngặt cho các lần chạy chứng minh bộ nghiên cứu weighted-100, so sánh cơ sở mạnh mẽ, canary nâng cấp mô hình và các lần chạy lại cuối cùng.

Hạch toán chi phí tách biệt theo vai trò

Trong một lần chạy có hỗ trợ cơ sở, cột chi phí tổng hợp trộn lẫn các cuộc gọi Fusion và cuộc gọi cơ sở; sử dụng trực tiếp nó sẽ phóng đại hoặc hạ thấp tuyên bố chi phí chỉ dành cho Fusion. Phân tích lần chạy nghiên cứu weighted-100 loại trừ rõ ràng các hàng cơ sở và điểm cơ sở để đạt được tổng số chính thức chỉ dành cho Fusion là $12.837461 trên 799 hàng chi phí. Sự phân biệt này, các hàng chi phí tách biệt theo vai trò thay vì tổng cộng hỗn hợp, là cơ sở cho mọi tuyên bố về chất lượng đã điều chỉnh chi phí trong báo cáo này.

So sánh ghép cặp thay vì trung bình không ghép cặp

Các đầu ra của Fusion và cơ sở được so sánh trên các ID tác vụ giống hệt nhau, và kết quả được báo cáo dưới dạng chênh lệch trung bình, khoảng tin cậy bootstrap, giá trị p kiểm tra dấu, số lượng thắng/thua/hòa, hệ số nhân chi phí, hệ số nhân độ trễ và chênh lệch tỷ lệ lỗi. Các trung bình không ghép cặp với phạm vi tác vụ khác nhau không được chấp nhận là bằng chứng.

Thực thi có thể tiếp tục, phân mảnh

Lần chạy nghiên cứu weighted-100 được thực hiện dưới dạng mười phân đoạn, mỗi phân đoạn mười tác vụ, sau đó được tổng hợp thành một hiện vật chứng minh duy nhất. Lần chạy lại cuối cùng chỉ dành cho Fusion (Phần 6) sử dụng cùng một mô hình phân đoạn, có thể tiếp tục.

Khía cạnh phương pháp	Cách tiếp cận được sử dụng	Cơ sở lý luận
Lựa chọn tác vụ	Bản kê 100 tác vụ có trọng số cố định, được băm	Ngăn chặn các phân khúc được chọn lọc, cho phép chạy lại
Tìm nguồn bằng chứng	Gói bằng chứng được chia sẻ, có thể tái lập	Tách biệt chất lượng suy luận khỏi sự may mắn khi tìm kiếm
Cách ly cơ sở	gpt-5.5, claude-opus-4-8 bị loại khỏi hội đồng/tổng hợp/giám khảo/xác thực	Ngăn chặn sự nhiễm bẩn cơ sở vào tuyên bố Fusion
Hạch toán chi phí	Các hàng tách biệt theo vai trò; tổng chỉ dành cho Fusion loại trừ các cuộc gọi cơ sở	Tránh làm sai lệch chi phí/đô la do chi phí hỗn hợp
Thiết kế so sánh	Ghép cặp, cùng ID tác vụ, CI bootstrap, kiểm tra dấu	Kiểm soát phương sai miền và mẫu
Thực thi	Các trình chạy phân mảnh, có thể tiếp tục	Cho phép theo dõi tiến độ một phần và chạy lại theo giai đoạn
Chấm điểm	Chấm điểm của người xác thực/giám khảo dựa trên rubric so với các rubric miền	Cho phép loại bỏ người xác thực và phân tách điểm số

TokenLab Fusion đánh giá các đầu ra của mô hình thông qua một quy trình chấm điểm tự động tổng hợp nhiều tín hiệu chỉ số thành một điểm số tổng hợp. Các quy tắc chấm điểm được áp dụng theo lập trình mà không cần đánh giá thủ công ở giai đoạn này. Dữ liệu kiểm toán của con người công khai hoặc dữ liệu đồng thuận giữa các người đánh giá cho phương pháp này vẫn chưa được công bố; các kết quả được báo cáo chỉ phản ánh đánh giá tự động, chờ xác minh độc lập.

Tính khả dụng của dữ liệu

Mã băm bản kê, các hàng chi phí, tệp kết quả thô, ảnh chụp nhanh nguồn sự thật duy nhất của mô hình và bản đồ nguồn làm cơ sở cho nghiên cứu này được lưu giữ trong kho lưu trữ nghiên cứu nội bộ của TokenLab. Các tài liệu này bị hạn chế truy cập và không được xuất bản cùng với bài báo này. Do đó, khả năng tái lập công khai bị hạn chế cho đến khi một mẫu được biên tập hoặc tập con công khai của dữ liệu cơ bản được phát hành.

4. Sự tiến hóa của Công thức: Nhiều mô hình hơn không phải là đòn bẩy

Một phát hiện sớm và quan trọng là tiêu cực: thêm nhiều mô hình vào hội đồng không cải thiện chất lượng một cách đáng tin cậy, và không thể giả định là sẽ như vậy. Công thức đã tiến hóa thông qua một chuỗi các loại bỏ có kiểm soát thay vì bằng cách mở rộng quy mô hội đồng.

Cốt lõi nhanh làm nhóm đối chứng

Một hội đồng ba mô hình chi phí thấp, đa dạng, ổn định (gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning) đóng vai trò là điều kiện đối chứng về chi phí/độ trễ mà mọi sự bổ sung và mọi biến thể người xác thực được đo lường dựa trên đó.

Kết hợp mô hình chi phí thấp cụ thể

TokenLab Fusion là một lớp điều phối tại thời điểm suy luận (inference-time), không phải là mô hình hợp nhất trọng số: nó điều phối các lệnh gọi đến nhiều mô hình hiện có và kết hợp đầu ra của chúng trong thời gian thực. Để cụ thể hóa điều này, các mô hình cơ sở gpt-5.5 và claude-opus-4-8 bị loại trừ khỏi mọi vai trò trong Fusion — hội đồng, tổng hợp, đánh giá, xác thực, rà soát và chủ sở hữu công cụ — để đảm bảo các mức tăng trưởng được báo cáo không thể quy cho việc các mô hình cơ sở đó thực hiện công việc ẩn bên trong quy trình.

Cấu hình mặc định là một bảng điều khiển nhanh, chi phí thấp gồm ba mô hình chạy song song, với tùy chọn thành viên hội đồng thứ tư được đánh giá ở chế độ chất lượng, một mỏ neo chứng minh trần hiệu năng lịch sử và một ứng viên thử nghiệm (canary) không tính phí cao cấp vẫn đang chờ bằng chứng đối chiếu.

Vai trò	(Các) Mô hình	Trạng thái
Bảng điều khiển nhanh, chi phí thấp	gemini-3.1-flash-lite, deepseek-v4-flash, grok-4-1-fast-non-reasoning	Bảng điều khiển chi phí thấp mặc định đang được kiểm chứng
Ứng viên bổ sung chất lượng	kimi-k2.7-code	Được đánh giá là thành viên hội đồng thứ tư; không được áp dụng — làm tăng độ trễ, suy giảm hiệu năng ở một số lĩnh vực khi kết hợp với trình xác thực
Mỏ neo chứng minh lịch sử	gemini-3.1-pro-preview	Được sử dụng cho tổng hợp/đánh giá/xác thực/rà soát trong công thức cơ sở mạnh; chứng minh trần hiệu năng, không phải lộ trình chi phí sản phẩm dự kiến
Ứng viên thử nghiệm không tính phí cao cấp	deepseek-v4-pro (tổng hợp/xác thực/rà soát), glm-5.2 (đánh giá độc lập)	Lộ trình chi phí dự kiến; đang chờ bằng chứng đối chiếu từ thử nghiệm

Quy trình điều phối diễn ra theo một trình tự cố định thay vì các lệnh gọi mô hình tự do:

1. Xây dựng một gói bằng chứng dùng chung một lần, để mọi thành viên hội đồng suy luận trên cùng một ngữ cảnh.
2. Chạy các thành viên hội đồng chi phí thấp song song dựa trên gói bằng chứng đó.
3. Chuẩn hóa đầu ra của hội đồng về một định dạng chung để so sánh.
4. Chạy phân tích hội đồng để làm nổi bật sự đồng thuận, xung đột và bằng chứng còn thiếu.
5. Tổng hợp một câu trả lời duy nhất, sau đó chạy trình xác thực dựa trên tiêu chí và sửa đổi một lần nếu trình xác thực gắn cờ các vấn đề.
6. Chấm điểm/đánh giá câu trả lời cuối cùng, với một chủ sở hữu công cụ được chỉ định duy nhất — các thành viên hội đồng không bao giờ trực tiếp thực thi công cụ.

Kết quả của kimi-k2.7-code và ứng viên thử nghiệm deepseek-v4-pro/glm-5.2 đang chờ xử lý được báo cáo riêng biệt với các số liệu của hội đồng mặc định để tránh nhầm lẫn giữa cấu hình đã đánh giá nhưng đã đánh giá nhưng chưa được áp dụng với công thức chi phí sản phẩm dự kiến.

Bổ sung Kimi: một tín hiệu thực nhưng nhỏ

Một thí điểm 20 tác vụ thêm một mô hình lập trình/đa dạng vào cốt lõi nhanh đã tạo ra điểm trung bình 34.36 so với cốt lõi nhanh 31.37 (chênh lệch ghép cặp +2.99, 95% CI -0.04 đến 6.10, thắng/thua/hòa 11/6/3, chi phí ~1.01x, độ trễ ~1.57x). CI nằm trên mức 0 và giá trị p kiểm tra dấu là 0.3323 có nghĩa là điều này không đủ mạnh để biện minh cho việc biến việc bổ sung thành một mặc định nhạy cảm với độ trễ; nó cũng hồi quy trên một số tác vụ Học thuật, Y học và Công nghệ. Kết luận rút ra là cụ thể theo vai trò: loại mô hình này được xử lý tốt hơn như một chuyên gia lập trình/front-end/ngữ cảnh dài hơn là một thành viên hội đồng đa năng luôn hoạt động.

Các bổ sung GLM và DeepSeek Pro cần vai trò, không phải bao gồm toàn diện

Một bổ sung GLM chỉ tạo ra khoảng +1.22 với chi phí 1.49x và độ trễ 1.85x trên một phân khúc nhỏ, bằng chứng hữu ích cho vai trò giám khảo/tổng hợp/người đánh giá lập trình, không phải bằng chứng đầy đủ cho việc thăng cấp hội đồng mặc định. Đánh giá của DeepSeek V4 Pro đã thay đổi đáng kể sau khi điều chỉnh giá (đầu vào $0.435, đầu ra $0.87 trên 1 triệu token), điều này làm mất hiệu lực của một phán đoán "quá đắt" trước đó và nâng nó lên thành ứng cử viên hàng đầu cho vai trò tổng hợp/xác thực trong một công thức chi phí thấp hơn (Phần 6). Việc điều chỉnh giá DeepSeek V4 Pro bắt nguồn từ SSOT mô hình nội bộ quan sát vào ngày 2026-07-07 và cấu thành một giả định chi phí nghiên cứu thay vì trích dẫn giá do nhà cung cấp công bố bên ngoài.

Người xác thực/viết lại là đòn bẩy đơn lẻ lớn nhất được tìm thấy

Trong một lần mở rộng 20 tác vụ, việc thêm giai đoạn người xác thực/viết lại nhận thức rubric vào cốt lõi nhanh đã tạo ra điểm trung bình 81.70 so với 29.88 chỉ cho cốt lõi nhanh, chênh lệch ghép cặp +51.81 (95% CI 42.64 đến 61.23), thắng/thua/hòa 20/0/0, với chi phí 2.14x và độ trễ 1.89x. Đây không phải là một cải tiến gia tăng; đó là một sự thay đổi cấu trúc về khả năng của công thức. Nó cũng không miễn phí: hệ số nhân chi phí vượt quá ngưỡng giữ tự động là 2.0x trong một lần phân tích, có nghĩa là kết quả tương tự xứng đáng cho một tầng nghiên cứu sâu là một ràng buộc thực sự cho một tầng sản phẩm nhanh/rẻ. Các lựa chọn thay thế rẻ hơn đã được thử nghiệm và bác bỏ như các mặc định: một biến thể đánh giá nhẹ/stack nhẹ mất khoảng 28 điểm so với xác thực đầy đủ và thua mọi so sánh ghép cặp; xác thực chọn lọc dựa trên các heuristic miền yếu chỉ tiết kiệm được khoảng 11% chi phí trong khi mất -8.53 điểm trung bình, và một biến thể chọn lọc rủi ro cao chỉ mất nhiều hơn. Do đó, xác thực chọn lọc vẫn là một vấn đề nghiên cứu định tuyến mở, không phải là một kỹ thuật giảm chi phí đã được giải quyết.

5. Kết quả Cơ sở Mạnh mẽ: Những gì đã được Chứng minh

Lần chạy nghiên cứu cơ sở mạnh mẽ weighted-100 là hiện vật bằng chứng mạnh nhất trong chương trình. Nó giữ gpt-5.5 và claude-opus-4-8 làm các bộ so sánh chỉ cơ sở, bị loại khỏi mọi vai trò Fusion.

Tóm tắt chỉ dành cho Fusion trên 100 tác vụ:

Chỉ số	Giá trị
Điểm trung bình	86.04
Tổng chi phí chính thức	$12.837461
Chi phí trung bình chính thức	$0.128375
Tổng chi phí nền tảng	$6.568959
Điểm trên mỗi đô la chính thức	670.21
Cuộc gọi thất bại	0
Tỷ lệ thất bại	0.0%
Độ trễ cuộc gọi trung bình	216.4s
Hàng chi phí	799
Tác vụ dự phòng tổng hợp	0

Giá trị được báo cáo là 670.21 biểu thị điểm trung bình thô chỉ dành cho Fusion chia cho chi phí trung bình chính thức chỉ dành cho Fusion, trong khi các con số 2.26x và 3.06x đại diện cho các hệ số nhân điểm trên mỗi đô la tương đối với cơ sở ghép cặp được tính toán dựa trên các cấu hình so sánh tương ứng.

So sánh ghép cặp với hai cơ sở mạnh mẽ:

Cơ sở	Điểm trung bình cơ sở	Chênh lệch Fusion	95% CI	Thắng/Thua/Hòa	Hệ số chi phí Fusion	Tỷ lệ Điểm/$	Hệ số độ trễ
gpt-5.5	53.43	+32.60	28.13 – 37.28	95/4/1	0.71x	2.26x	1.23x
claude-opus-4-8	40.41	+45.63	40.85 – 50.21	97/2/1	0.69x	3.06x	2.15x

Chất lượng và chất lượng đã điều chỉnh chi phí là những chiến thắng Fusion không thể nhầm lẫn trên bản kê này. Chênh lệch tỷ lệ thất bại là 0.0 điểm phần trăm làm cho sự ổn định trở thành một điểm hòa thay vì một yếu tố khác biệt. Độ trễ là một thất bại rõ ràng của Fusion: chậm hơn 1.23x so với gpt-5.5 và chậm hơn 2.15x so với claude-opus-4-8. Cách đóng khung sản phẩm trung thực từ dữ liệu này là nghiên cứu sâu chất lượng cao, hiệu quả về chi phí, có thể kiểm chứng, không phải trò chuyện tương tác độ trễ thấp.

Phân tích miền cho thấy các chênh lệch dương trên mọi miền so với cả hai cơ sở, điều này lập luận chống lại việc cải tiến là một hiện vật đơn miền. Các giá trị được chọn: so với gpt-5.5, Tài chính +37.13, Mua sắm +38.20, Needle-in-a-Haystack +62.56, Công nghệ +33.49; so với claude-opus-4-8, Mua sắm +55.96, Needle-in-a-Haystack +69.38, Công nghệ +52.43, Thiết kế UX +52.77. Tài chính cũng là miền mang rủi ro chưa được giải quyết rõ ràng nhất: tám cảnh báo bằng chứng mức độ nghiêm trọng cao, tất cả đều là Tài chính, được gắn cờ finance:needs_more_sources, trích dẫn các khoảng trống trong các thuật ngữ chỉ số, thuật ngữ giai đoạn và tìm nguồn giai đoạn chính hiện tại. Đây không phải là các cuộc gọi thất bại; chúng là các cảnh báo về tính đầy đủ của nguồn, cho thấy việc định tuyến bằng chứng cụ thể cho Tài chính vẫn chưa được giải quyết hoàn toàn ngay cả khi chênh lệch điểm số lớn.

6. Trạng thái Sẵn sàng: Đã chứng minh so với Vẫn bị hạn chế

Điều quan trọng là phải tách biệt hai lớp trạng thái. Đây là kết quả chứng minh công thức, không phải kết quả hệ thống đã xuất xưởng, và việc theo dõi trạng thái sẵn sàng được sử dụng trong chương trình phản ánh rõ ràng sự phân biệt đó.

Đã thông qua: bản kê 100 tác vụ có trọng số cố định, chính sách hội đồng, kiểm tra bộ định tuyến bằng chứng, bằng chứng loại bỏ hội đồng, bằng chứng loại bỏ người xác thực/tổng hợp, cấu hình cơ sở mạnh mẽ, bằng chứng cổng nguồn yếu, các hiện vật công thức và bằng chứng ghép cặp cơ sở mạnh mẽ được mô tả trong Phần 5.

Chưa thông qua: lần chạy lại cuối cùng chỉ dành cho Fusion.

Lần chạy lại cuối cùng không phải là một so sánh thứ hai so với các cơ sở mạnh mẽ; mục đích của nó khác và hẹp hơn: xác nhận rằng công thức chiến thắng đã đóng băng tái lập trên cùng bản kê 100 tác vụ mà không có chi phí cơ sở trong lần chạy, rằng cấu hình thời gian chạy khớp với định nghĩa công thức, rằng các hàng chi phí đầy đủ, và rằng không có sự nhiễm bẩn cơ sở trong đường dẫn chỉ dành cho Fusion. Tính đến lần chạy theo giai đoạn mới nhất, phạm vi bao phủ đạt 20 trên 100 tác vụ được chấm điểm, 20 trên 20 tương thích thời gian chạy, chi phí chính thức chỉ dành cho Fusion là $2.619654, chi phí cơ sở $0, với 80 tác vụ còn lại sẽ được thực hiện trong các giai đoạn bù đắp tiếp theo.

Sự phân biệt này quan trọng đối với cách đọc các con số của lần chạy nghiên cứu weighted-100: chênh lệch cơ sở mạnh mẽ là có thật và được ghép cặp, nhưng nó được đo lường bằng một công thức chưa được tái lập độc lập từ đầu đến cuối mà không có chi phí cơ sở trong vòng lặp, và nó đã sử dụng một anchor tổng hợp/xác thực/giám khảo mà đường dẫn chi phí sản phẩm đang cố tình loại bỏ.

Cụ thể về anchor Gemini Pro, công thức đóng băng đã tạo ra những con số này đã sử dụng gemini-3.1-pro-preview, một mô hình Gemini Pro cao cấp lịch sử, làm anchor tổng hợp/giám khảo/xác thực. Cấu hình đó thiết lập trần cho những gì cấu trúc công thức và xác thực nhận thức rubric có thể đạt được, nhưng đó không phải là cấu hình mà đường dẫn chi phí sản phẩm dự định xuất xưởng. Vì giá Gemini Pro cao cấp không phù hợp với hồ sơ chi phí mục tiêu, hiện vật bằng chứng bắt buộc tiếp theo là một canary không sử dụng Gemini cao cấp: một lần chạy lại quy mô nhỏ hơn, ghép cặp, thay thế deepseek-v4-pro cho tổng hợp/xác thực và glm-5.2 cho giám khảo, chạy trên cùng các ID tác vụ trước khi đưa ra bất kỳ tuyên bố nào rằng công thức hiệu quả về chi phí khớp với trần chất lượng đã được chứng minh.

7. Giao thức và Khả năng tương thích: Tại sao Một điểm cuối Chat là không đủ

Một công thức chỉ hoạt động với một điểm cuối chat tương thích OpenAI duy nhất sẽ không tồn tại được khi tiếp xúc với các khách hàng đại lý lập trình thực tế. Chat Completions là đủ cho việc sử dụng hội thoại đơn giản nhưng làm mất các ngữ nghĩa mà các khách hàng đại lý phụ thuộc vào: các mục đầu ra được định kiểu, ghép cặp gọi hàm/kết quả công cụ, sự kiện mục phát trực tuyến, lịch sử có trạng thái so với không trạng thái và các đảm bảo thứ tự cụ thể của nhà cung cấp.

Các bề mặt quan trọng, và ngữ nghĩa mà mỗi bề mặt mang theo, khác nhau đủ để chúng không thể bị thu gọn thành một hình dạng mà không bị mất mát:

Bề mặt	Ngữ nghĩa chính phải được bảo tồn
OpenAI Responses	các mục đầu ra được định kiểu, phân cấp hướng dẫn nhà phát triển/hệ thống, các cuộc gọi hàm và đầu ra cuộc gọi hàm, previous_response_id, store, sự kiện mục phát trực tuyến, hạch toán sử dụng
OpenAI Chat	tin nhắn/công cụ kế thừa; có thể sử dụng như một mặt tiền bị suy giảm, nhưng các mất mát tương thích phải được ghi lại
Anthropic Messages	trường hệ thống cấp cao nhất, các khối nội dung, tool_use/tool_result, các yêu cầu lịch sử đầy đủ không trạng thái, stop_reason, lỗi luồng sau 200
Hồ sơ khách hàng kiểu Codex	Responses-first, store, previous_response_id, các đối số công cụ phát trực tuyến, phát lại kết quả công cụ, thứ tự sự kiện nghiêm ngặt
Hồ sơ khách hàng kiểu Claude Code	Anthropic Messages, thứ tự tool_result tức thì, các lô công cụ song song, disable_parallel_tool_use, danh sách cho phép khám phá mô hình

Câu trả lời kiến trúc là một biểu diễn trung gian (IR) chính tắc. Các giao thức bên ngoài ánh xạ vào một biểu diễn yêu cầu/phản hồi/luồng/công cụ/sử dụng/lỗi/dấu vết nội bộ, và việc thực thi công thức cũng như các bộ điều hợp nhà cung cấp hoạt động dựa trên IR đó thay vì dựa trên bất kỳ giao thức dây đơn lẻ nào. IR được yêu cầu mang theo, tối thiểu: các định danh hội thoại và lượt cùng với các con trỏ trạng thái nhà cung cấp (previous_response_id); giao thức khách hàng và định danh công thức công khai; nguồn gốc và ưu tiên của các hướng dẫn hệ thống/nhà phát triển/cổng/công thức; tin nhắn, khối nội dung, hình ảnh và văn bản dẫn xuất; công cụ, kết quả công cụ, lựa chọn công cụ và chính sách công cụ song song; các phương thức và cài đặt tạo; hồ sơ về các mất mát tương thích; các hàng sử dụng và hàng chi phí tách biệt theo vai trò; và một dấu vết bao gồm bằng chứng, tìm kiếm, công cụ, chi phí và hoạt động vai trò mô hình.

Sự biện minh thực tế là cụ thể: tool_result của Anthropic phải theo ngay sau tool_use khớp với nó; các đầu ra gọi hàm của OpenAI Responses phải phát lại theo call_id; một mặt tiền Chat không thể bảo tồn hoàn toàn ưu tiên tin nhắn nhà phát triển; Claude Code gửi lịch sử đầy đủ không trạng thái trên mỗi lượt, trong khi các khách hàng dựa trên Responses dựa vào con trỏ trạng thái phía nhà cung cấp. Nếu không có IR và bộ tương thích thực hiện các trường hợp này trực tiếp, một hệ thống có thể vượt qua một tiêu chuẩn đánh giá và vẫn thất bại bên trong một khách hàng đại lý thực tế vì vòng lặp công cụ không bao giờ hoàn thành chính xác.

Trạng thái triển khai hiện tại nên được nêu chính xác thay vì lạc quan: lớp tương thích tồn tại dưới dạng tài liệu giao thức, định nghĩa IR bộ điều hợp, các thiết bị hợp đồng cổng, trình lập kế hoạch lượt, trình ghi luồng, các thiết bị công cụ/bằng chứng và bộ kiểm tra tương thích tổng hợp. Nó là một bộ khung tương thích ngoại tuyến, đủ để hạn chế các hình dạng giao thức, các khoảng trống bề mặt và ngăn chặn sự trôi dạt thiết kế sớm, nhưng nó chưa phải là một cổng sản xuất trực tiếp. Nó chưa bao gồm thực thi nhà cung cấp thực tế ở quy mô, bề mặt sản phẩm phát trực tuyến hướng khách hàng, thực thi công cụ trực tiếp, xác thực/thuê bao sản xuất hoặc phần phụ trợ dấu vết bền vững. Khám phá mô hình công khai được thiết kế để chỉ hiển thị các định danh công thức công khai có không gian tên; bất kỳ yêu cầu ID mô hình không công khai hoặc không có không gian tên nào sẽ thất bại đóng (ví dụ: model_not_public) thay vì cho phép khách hàng bỏ qua các ranh giới công thức, chi phí hoặc dấu vết.

8. Mô hình Kiểm soát Sử dụng Công cụ

Gọi công cụ đa mô hình là phần nguy hiểm nhất về mặt vận hành của bất kỳ phần mở rộng đại lý lập trình nào của hệ thống này. Nếu một vài mô hình có thể độc lập đưa ra các cuộc gọi công cụ trong cùng một lượt, kết quả có thể là chỉnh sửa tệp trùng lặp, gọi API bên ngoài trùng lặp, tính phí trùng lặp, ghi đồng thời, lệnh shell xung đột hoặc lộ thông tin xác thực. Mô hình kiểm soát được áp dụng cố tình hạn chế:

• Một lượt, theo mặc định, có chính xác một chủ sở hữu công cụ hoạt động.
• Các mô hình khác có thể đóng vai trò là người đánh giá hoặc nhà phê bình và có thể đề xuất thay đổi, nhưng không được thực thi công cụ.
• Văn bản có hình dạng công cụ trong đầu ra của mô hình không phải là thẩm quyền thực thi.
• Mọi cuộc gọi công cụ đều được chuẩn hóa thành một ToolCall IR chính tắc trước khi bất kỳ quyết định thực thi nào được đưa ra.
• Một trình lập lịch phân loại mỗi cuộc gọi là executable (có thể thực thi), advice_only (chỉ tư vấn), blocked (bị chặn) hoặc requires_approval (yêu cầu phê duyệt).
• Các cuộc gọi chỉ đọc, đọc mạng và chỉ tính toán có thể chạy đồng thời trong một nhóm song song trong các điều kiện an toàn.
• Các cuộc gọi ghi, ghi shell, thanh toán, thông tin xác thực và lớp phá hoại được tuần tự hóa và mặc định là yêu cầu phê duyệt.
• Kết quả công cụ được phát lại một cách xác định trở lại hình dạng mong đợi của giao thức mục tiêu.
• JSON một phần không bao giờ được thực thi; ngay cả JSON được hình thành tốt cũng phải vượt qua các kiểm tra lược đồ, tác dụng phụ, phê duyệt và chủ sở hữu.

Đây là một sự khởi đầu có ý nghĩa so với các minh chứng đa đại lý điển hình, nơi một vài đại lý có thể cùng cố gắng "giải quyết" một vấn đề đồng thời. Một công thức lập trình hướng sản xuất yêu cầu kỷ luật vai trò đối với sự an toàn thực thi: một người đánh giá có thể gắn cờ rằng một bản vá được đề xuất sẽ phá vỡ một bộ kiểm tra, nhưng chính nó không thể chạy một lệnh shell phá hoại. Một chủ sở hữu công cụ có thể bắt đầu chỉnh sửa tệp hoặc lệnh shell, nhưng đầu ra của nó vẫn được cổng xác minh trước khi thực thi.

Điều này cũng hạn chế cách đọc các thẻ khả năng công cụ của thư viện mô hình: thẻ "tool-use" có nghĩa là một mô hình có thể biểu đạt một cuộc gọi công cụ một cách hợp lý, không phải là nó được xóa để trở thành một chủ sở hữu công cụ sản xuất. Việc thăng cấp lên trạng thái chủ sở hữu yêu cầu vượt qua một bộ tương thích bao gồm các đối số công cụ phát trực tuyến, tính ổn định ID công cụ, sửa chữa JSON bị hỏng, phát lại kết quả công cụ, chính sách công cụ song song, hạch toán sử dụng và hình dạng lỗi. Một trường hợp biên liên quan là "giải cứu" công cụ nội dòng: một số nhà cung cấp phát ra các cuộc gọi công cụ dưới dạng văn bản trợ lý (các khối XML/JSON, thẻ hàm riêng tư, đối tượng hoặc đối số được mã hóa kép). Lớp bộ điều hợp có thể phát hiện và sửa chữa các phương ngữ này, nhưng việc sửa chữa chỉ tạo ra một ToolCall IR ứng viên; nó không cấp thẩm quyền thực thi, nó chỉ giới hạn trong văn bản phản hồi của chủ sở hữu hiện tại (không bao giờ cho văn bản người dùng, kết quả công cụ, ghi chú người đánh giá hoặc câu trả lời Fusion cuối cùng), và một cuộc gọi đã sửa chữa vẫn phải vượt qua các cổng chủ sở hữu, lược đồ, tác dụng phụ, phê duyệt, tính song song và tính lũy đẳng. JSON bị hỏng lặp đi lặp lại sẽ làm thất bại kiểm tra tương thích của chủ sở hữu đó cho lượt thay vì bị thực thi âm thầm.

9. Tầm nhìn và Tìm kiếm Web: Công bằng so với Trải nghiệm Sản phẩm

Các lộ trình đánh giá và sản phẩm cố tình phân kỳ ở đây. Chứng minh tiêu chuẩn đánh giá sử dụng bằng chứng được chia sẻ, có thể tái lập; các yêu cầu sản xuất có thể sử dụng tìm kiếm hoặc tầm nhìn gốc, nhưng chỉ khi có thể truy xuất nguồn gốc.

Tìm kiếm được xử lý thông qua ba lộ trình riêng biệt: shared_evidence (một gói tìm kiếm/lấy/đọc bên ngoài do Fusion sở hữu, có thể tái lập, bắt buộc cho các lần chạy chứng minh bộ nghiên cứu weighted-100, so sánh cơ sở mạnh mẽ, canary nâng cấp mô hình và các lần chạy lại cuối cùng), native_search (khả năng web/duyệt/nền tảng của chính mô hình hoặc nhà cung cấp), và external_search (các công cụ bên ngoài có thể truy xuất nguồn gốc như lấy, đọc trình duyệt hoặc trích xuất tài liệu). Tìm kiếm gốc không bị cấm; nó có thể cải thiện trải nghiệm sản phẩm, nhưng nó không thể hỗ trợ một tuyên bố tiêu chuẩn đánh giá công bằng, vì nếu hành vi tìm kiếm, nguồn được truy xuất và dấu vết trích dẫn của chính mô hình là không minh bạch, sự so sánh ngừng là một sự so sánh cùng tác vụ.

Tầm nhìn tuân theo logic tương tự. Tầm nhìn gốc và văn bản OCR/chú thích dẫn xuất không phải là các đầu vào tương đương, và một sự so sánh giữa các mô hình với khả năng hiển thị khác nhau vào một hình ảnh không phải là một sự so sánh tầm nhìn công bằng. Dấu vết ghi lại khả năng hiển thị của mỗi mô hình một cách rõ ràng là native_image, derived_text hoặc none. Mô hình sản xuất được khuyến nghị là một mô hình lai: các mô hình chính có thể sử dụng tầm nhìn gốc trong khi các người đánh giá chi phí thấp hơn làm việc từ văn bản dẫn xuất; các tác vụ sự kiện hiện tại mặc định là tìm kiếm/lấy bên ngoài, và tìm kiếm gốc chỉ được cho phép khi một lộ trình đã vượt qua một thăm dò khả năng và tạo ra một dấu vết hoàn chỉnh. Tuy nhiên, đánh giá luôn mặc định là bằng chứng được chia sẻ và một gói bằng chứng được băm.

10. Thư viện Mô hình như một Lược đồ Lựa chọn Nhận thức Vai trò

Danh mục mô hình làm cơ sở cho TokenLab Fusion đã chuyển từ một bảng khả năng phẳng sang một lược đồ lựa chọn phân lớp với các trường cho tầng chi phí, vai trò Fusion, thẻ khả năng, chỉ số lựa chọn, hồ sơ định tuyến và lộ trình đánh giá được khuyến nghị. Điều này phản ánh một thực tế sản phẩm rằng một bảng xếp hạng "mô hình này mạnh đến mức nào" duy nhất không nắm bắt được: một mô hình có thể là một người đánh giá lập trình xuất sắc và một người tham gia hội đồng nghiên cứu độ trễ thấp kém; một mô hình có thể không đắt nhưng có ID cuộc gọi công cụ không ổn định; một mô hình có thể mang thẻ khả năng tầm nhìn gốc mà chưa có bằng chứng dấu vết đủ cho một đánh giá bị hạn chế công bằng.

Lớp	Vai trò đại diện	Ý nghĩa sản phẩm
Luôn hoạt động giá rẻ	các ứng cử viên hội đồng/người đánh giá/giám khảo chi phí thấp	Thành phần hội đồng mặc định, chỉ được thăng cấp thông qua bằng chứng canary ghép cặp
Nâng cấp suy luận mạnh	leo thang tác vụ khó	Vai trò tổng hợp/xác thực/giám khảo cho các tác vụ khó
Chuyên gia lập trình/đại lý	vòng lặp công cụ, quy mô repo, đánh giá front-end	Các ứng cử viên chủ sở hữu công cụ và người đánh giá đại lý lập trình
Chuyên gia tầm nhìn/tìm kiếm	quy trình sản phẩm nặng về hình ảnh/tìm kiếm	Yêu cầu thăm dò dấu vết trước khi sử dụng bị hạn chế công bằng
Giữ lại ngữ cảnh siêu dài	chẩn đoán repo/gói bằng chứng khổng lồ	Không phải là thành viên hội đồng mặc định
Bộ so sánh hộp đen	hệ thống đa đại lý phía nhà cung cấp	Chỉ là điểm tham chiếu; thuộc tính Fusion nội bộ không thể được rút ra từ nó

Phán quyết hiện tại về anchor cao cấp đã nghỉ hưu xứng đáng được nêu rõ ràng: mô hình Gemini Pro cao cấp lịch sử đã neo giữ bằng chứng weighted-100 đã được nghỉ hưu khỏi kế hoạch công thức chi phí sản phẩm tích cực, và một mô hình tầng Gemini flash giá thấp hơn cũng đã bị loại khỏi kế hoạch mặc định do giá đầu ra không phù hợp với hồ sơ chi phí công thức mục tiêu. Điều này không sửa đổi kết quả lần chạy nghiên cứu weighted-100, bằng chứng đó vẫn được ghi lại, nhưng nó có nghĩa là bằng chứng và công thức xuất xưởng dự định không phải là cùng một hệ thống, đó chính xác là lý do tại sao canary không sử dụng Gemini cao cấp là bước bằng chứng bắt buộc tiếp theo, không phải là bước tùy chọn.

11. Các Cổng Nâng cấp Thư viện Mô hình

Một mối quan tâm vận hành định kỳ là liệu mọi thay đổi mô hình có yêu cầu chạy lại toàn bộ 100 tác vụ hay không. Câu trả lời được chương trình áp dụng là các cổng hạn chế rủi ro, tỷ lệ thuận thay vì một trong hai thái cực (chạy lại toàn bộ mù quáng trên mọi thay đổi, hoặc thay thế cùng gia đình mù quáng mà không có bằng chứng):

1. Smoke hợp đồng: xác nhận lộ trình, giá cả, phát trực tuyến, cửa sổ ngữ cảnh, giới hạn đầu ra, phương thức và các thẻ công cụ/tìm kiếm/tầm nhìn.
2. Bộ tương thích: thực hiện Chat OpenAI, Responses OpenAI, Messages Anthropic, gọi công cụ, kết quả công cụ, công cụ song song, sử dụng, lỗi và xử lý luồng.
3. Đánh giá Sentinel: chạy một tập hợp cụ thể theo miền nhỏ khớp với vai trò được tuyên bố của mô hình (ví dụ: tính đầy đủ của nguồn tài chính, vòng lặp công cụ lập trình, đánh giá hình ảnh front-end).
4. Canary ghép cặp: so sánh với công thức hiện tại trên các ID tác vụ giống hệt nhau về chất lượng, chi phí, độ trễ và tỷ lệ thất bại.
5. Chạy 100 tác vụ đầy đủ: dành riêng cho các ứng cử viên có thể thay đổi công thức mặc định hoặc một tuyên bố cơ sở mạnh mẽ.

Ngay cả một nâng cấp cùng gia đình có vẻ nhỏ cũng yêu cầu bước qua phễu này: giá cả, hành vi gọi công cụ, phát trực tuyến và chất lượng ghép cặp đều cần xác minh độc lập thay vì được suy ra từ tên gia đình mô hình được chia sẻ. Đây cũng là lý do tại sao bản kê 100 tác vụ không được chạy liên tục; nó được dành riêng cho xác nhận cuối cùng, trong khi các thay đổi mô hình hàng ngày được quản lý bởi các cổng rẻ hơn, nhanh hơn ở trên.

12. Công trình Liên quan và Những gì được (và không được) Tái sử dụng

Chương trình rút ra từ một số hướng nghiên cứu và công cụ công khai mà không áp dụng hoàn toàn các mục tiêu của chúng. Mixture-of-Agents thúc đẩy ý tưởng rằng các đầu ra mô hình yếu hơn vẫn có thể điều kiện hóa một bộ tổng hợp mạnh hơn một cách hữu ích, nhưng các phát hiện về sự phình to hội đồng trong Phần 4 cảnh báo chống lại việc phân lớp mà không loại bỏ. LLM-Blender đóng góp cấu trúc tạo ứng cử viên, xếp hạng ghép cặp, tổng hợp tạo sinh mà các giai đoạn hội đồng/giám khảo/tổng hợp giống với, mặc dù không có bộ xếp hạng được huấn luyện chuyên dụng nào hiện thay thế giám khảo dựa trên rubric. FrugalGPT và RouteLLM thúc đẩy phân tầng và định tuyến nhận thức chi phí, nhưng vấn đề định tuyến ở đây là đa vai trò (hội đồng, tổng hợp, giám khảo, xác thực, chiến lược tìm kiếm, chủ sở hữu công cụ mỗi bên có thể định tuyến độc lập), không phải là một lựa chọn mô hình nhị phân duy nhất. Các công cụ khai thác đánh giá như Inspect AI, OpenAI Evals, Promptfoo và Ragas thông báo mô hình kỹ thuật của một vòng lặp đánh giá có hệ thống, thân thiện với CI, nhưng không ai trong số chúng thay thế cho bản kê có trọng số cố định, kiểm tra tính đầy đủ của nguồn, các hàng chi phí tách biệt theo vai trò hoặc cấu trúc bằng chứng ghép cặp có trọng số miền được sử dụng ở đây.

13. Hạn chế

Hạn chế	Trạng thái hiện tại	Tại sao nó quan trọng
Phụ thuộc anchor cao cấp	Bằng chứng weighted-100 đã sử dụng một mô hình Gemini Pro cao cấp lịch sử làm tổng hợp/giám khảo/xác thực	Chứng minh trần công thức, không phải công thức chi phí sản phẩm dự định
Chạy lại cuối cùng chưa hoàn thành	Chạy lại chỉ dành cho Fusion ở mức 20/100 tác vụ, 20/20 tương thích thời gian chạy	Khả năng tái lập mà không có chi phí cơ sở chưa được xác nhận đầy đủ
Không có dữ liệu kiểm toán con người hoặc đồng thuận giữa các người đánh giá công khai	Kết quả kiểm toán con người và đồng thuận giữa các người đánh giá chưa được công bố hoặc cung cấp công khai cho quy trình đánh giá này	Độ tin cậy và tính nhất quán của các điểm số tự động so với phán đoán của con người vẫn chưa được xác minh, hạn chế sự tự tin trong việc diễn giải điểm số tuyệt đối
Bất lợi về độ trễ	1.23x so với gpt-5.5, 2.15x so với claude-opus-4-8	Có thể chấp nhận được cho nghiên cứu sâu, có khả năng không chấp nhận được cho các đại lý lập trình tương tác
Người xác thực nhận thức rubric	Người xác thực nhìn thấy rubric/danh sách kiểm tra chấm điểm	Các so sánh phải tiết lộ điều này; không thể so sánh trực tiếp với các hệ thống mù rubric
Cảnh báo nguồn tài chính	8 cảnh báo finance:needs_more_sources mức độ nghiêm trọng cao	Tính đầy đủ của nguồn trong Tài chính chưa được giải quyết mặc dù chênh lệch điểm số lớn
Suy luận khả năng gốc	Các thẻ khả năng tìm kiếm/tầm nhìn không phải là bằng chứng hỗ trợ dấu vết cấp sản xuất	Yêu cầu thăm dò mỗi lộ trình trước khi sử dụng đánh giá bị hạn chế công bằng
Độ trưởng thành lớp tương thích	Khung ngoại tuyến (IR, thiết bị, hợp đồng bộ định tuyến, trình lập kế hoạch, trình ghi luồng)	Chưa phải là một cổng sản xuất trực tiếp với thực thi nhà cung cấp thực tế, xác thực/thuê bao hoặc lưu trữ dấu vết bền vững
Biến động giá/lộ trình	Điều chỉnh giá DeepSeek V4 Pro đã thay đổi một quyết định chiến lược	Phân tầng thư viện mô hình phải được xác minh lại khi giá cả và hành vi lộ trình thay đổi

14. Câu hỏi thường gặp

Kết quả 100 tác vụ có nghĩa là TokenLab Fusion đánh bại GPT-5.5 và Claude Opus 4.8 nói chung không?

Kết quả ghép cặp giữ nguyên cụ thể trên bản kê nghiên cứu weighted-100 cố định, sử dụng bằng chứng được chia sẻ và hạch toán chi phí tách biệt theo vai trò, với gpt-5.5 và claude-opus-4-8 được giữ bên ngoài hội đồng Fusion. Đó là bằng chứng mạnh mẽ, rộng khắp miền trong phạm vi đó, không phải là một tuyên bố chung độc lập với loại tác vụ, điều kiện bằng chứng hoặc thành phần bản kê.

Tại sao anchor Gemini Pro lại quan trọng nếu chênh lệch điểm số đã lớn?

Chênh lệch được tạo ra bởi một công thức sử dụng một mô hình Gemini Pro cao cấp lịch sử để tổng hợp, chấm điểm và xác thực. Cấu hình đó thiết lập những gì cấu trúc công thức có thể đạt được, nhưng đó không phải là hồ sơ chi phí mà lộ trình sản phẩm dự định xuất xưởng. Cho đến khi cấu hình không sử dụng Gemini cao cấp được chạy như một canary ghép cặp so với cùng các ID tác vụ, chất lượng đạt được và chi phí xuất xưởng dự định được chứng minh riêng biệt, không phải cùng nhau.

Chi phí mỗi cuộc gọi thấp hơn có giống với chi phí thấp hơn trên mỗi đơn vị chất lượng không?

Không, và cả hai được báo cáo riêng biệt vì lý do này. Các hệ số nhân chi phí 0.71x và 0.69x mô tả chi phí thô so với hai cơ sở; các tỷ lệ điểm trên mỗi đô la 2.26x và 3.06x mô tả chất lượng đã điều chỉnh chi phí. Cả hai đều cần thiết, vì một hệ thống có thể rẻ hơn trên mỗi cuộc gọi và vẫn đạt điểm kém hơn, hoặc đắt hơn trên mỗi cuộc gọi và vẫn hiệu quả hơn về chi phí trên mỗi đơn vị chất lượng; đánh giá này báo cáo cả hai một cách rõ ràng thay vì thu gọn chúng.

Tại sao loại bỏ người xác thực lại quan trọng đối với kết quả này?

Giai đoạn người xác thực/viết lại nhận thức rubric đã tạo ra thay đổi chất lượng đơn lẻ lớn nhất được đo lường trong chương trình này (chênh lệch ghép cặp +51.81 trên một lần mở rộng 20 tác vụ), với chi phí khoảng 2.14x và độ trễ 1.89x so với đối chứng cốt lõi nhanh. Bất kỳ sự so sánh nào giữa các công thức, hoặc giữa Fusion và một cơ sở, cần tiết lộ liệu giai đoạn người xác thực có hoạt động hay không, vì nó thay đổi cả hồ sơ chi phí và khung công bằng (người xác thực có khả năng hiển thị vào các rubric chấm điểm).

TokenLab Fusion đã sẵn sàng chạy bên trong một khách hàng đại lý lập trình thực tế ngay hôm nay chưa?

Chưa. Kiến trúc kiểm soát sử dụng công cụ và giao thức (IR chính tắc, bộ tương thích, mô hình chủ sở hữu công cụ) tồn tại dưới dạng một khung tương thích ngoại tuyến với các ánh xạ giao thức được ghi lại, nhưng nó chưa bao gồm một cổng sản xuất trực tiếp, thực thi nhà cung cấp thực tế ở quy mô, xác thực/thuê bao hoặc lưu trữ dấu vết bền vững. Bằng chứng Deep Research và dòng Coding Agent được đánh giá trên các mốc thời gian khác nhau, và dòng lập trình chưa hoàn thành giai đoạn xác thực mẫu nhỏ đầu tiên.

15. Kết thúc Nghiên cứu

Những gì đã được chứng minh

Trên một bản kê đa miền 100 tác vụ có trọng số, cố định, được băm, sử dụng bằng chứng được chia sẻ và hạch toán chi phí tách biệt theo vai trò, một công thức đa mô hình được trang bị người xác thực đã đạt được chênh lệch điểm trung bình ghép cặp là +32.60 so với gpt-5.5 và +45.63 so với claude-opus-4-8, với chi phí lần lượt là 0.71x và 0.69x, với không có cuộc gọi thất bại nào trên 799 hàng chi phí. Xác thực nhận thức rubric được xác nhận là đòn bẩy chất lượng đơn lẻ lớn nhất được thử nghiệm, với chênh lệch ghép cặp là +51.81 so với đối chứng cốt lõi nhanh. Các chênh lệch dương giữ nguyên trên mọi miền trong bản kê so với cả hai cơ sở, cho thấy lợi ích không tập trung vào một loại tác vụ.

Những gì vẫn bị hạn chế

Lần chạy lại cuối cùng chỉ dành cho Fusion của công thức chiến thắng đã đóng băng chưa hoàn thành (20 trên 100 tác vụ ở lần kiểm tra cuối) và phải đạt được phạm vi bao phủ đầy đủ với một cuộc kiểm toán trạng thái sẵn sàng sạch sẽ trước khi bằng chứng có thể được gọi là có thể tái lập từ đầu đến cuối. Công thức tạo ra bằng chứng phụ thuộc vào một anchor Gemini Pro cao cấp lịch sử mà lộ trình chi phí sản phẩm dự định loại bỏ; chưa có bằng chứng ghép cặp nào tồn tại cho sự thay thế Gemini không cao cấp dự định. Độ trễ vẫn là một sự đánh đổi sản phẩm chưa được giải quyết, đặc biệt là đối với bất kỳ ứng dụng đại lý lập trình nào. Tính đầy đủ của nguồn tài chính mang tám cảnh báo mức độ nghiêm trọng cao chưa được giải quyết mặc dù có lợi thế điểm số lớn trong miền đó. Lớp tương thích giao thức được xác định về mặt kiến trúc nhưng chưa phải là một cổng sản xuất đang chạy.

Những bằng chứng nào nên được thu thập tiếp theo

Hoàn thành lần chạy lại cuối cùng chỉ dành cho Fusion trên 80 tác vụ còn lại và chạy lại cuộc kiểm toán trạng thái sẵn sàng để xác nhận khả năng tái lập mà không có chi phí cơ sở trong vòng lặp. Chạy một canary ghép cặp, cùng ID tác vụ thay thế deepseek-v4-pro cho tổng hợp/xác thực và glm-5.2 cho giám khảo thay cho anchor Gemini Pro cao cấp, bắt đầu ở quy mô nhỏ trước khi đưa ra bất kỳ tuyên bố đầy đủ bản kê nào. Đóng tám cảnh báo tính đầy đủ của bằng chứng Tài chính còn tồn đọng với công việc cổng nguồn cụ thể theo miền trước khi coi kết quả miền Tài chính đã được giải quyết hoàn toàn. Mở rộng bộ tương thích từ một khung ngoại tuyến hướng tới thực thi nhà cung cấp trực tiếp, và chạy một giai đoạn xác thực đại lý lập trình mẫu nhỏ (theo thứ tự năm tác vụ) để kiểm tra xem kiến trúc chủ sở hữu/người đánh giá công cụ có tạo ra lợi thế hội đồng-trên-mô hình-đơn lẻ có thể đo lường được hay không trước khi đầu tư thêm vào cơ sở hạ tầng đại lý lập trình. Mỗi điều này là một thí nghiệm tiếp theo cụ thể, có thể làm sai lệch, không phải là một mục lộ trình chung.