Fable 5 vs. GPT-5.6 Sol: `/goal` có hữu ích với bài toán NP-khó không?

 (charlesazam.com)
1 điểm bởi GN⁺ 1 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả cho thấy khi cho giải một bài toán tối ưu hóa mạng cáp quang chưa công bố trong 30 phút mỗi lần, Fable 5 đạt điểm cao nhất và hiệu năng ổn định nhất, nhưng /goal không tạo ra cải thiện nhất quán
  • /goal không đơn thuần là chức năng khiến mô hình làm việc lâu hơn, mà thay đổi vòng lặp điều khiển và đường đi tìm kiếm, nên có thể duy trì cả chiến lược tốt lẫn chiến lược sai
  • Trong 6 lần so sánh giữa Fable 5 và GPT-5.6 Sol, /goal thắng 4 lần, nhưng do đôi khi xuất hiện mức suy giảm hiệu năng lớn nên điểm trung bình lại xấu đi 759 điểm và 868 điểm tương ứng
  • Chế độ thường của Fable 5 ổn định nhất với trung bình 32.386 điểm và biên độ 319 điểm, còn chế độ /goal đạt kỷ lục tốt nhất toàn bộ là 31.934 điểm
  • Với các bài toán tối ưu khó, điều quan trọng không phải có lặp lại hay không mà là chất lượng của chiến lược được lặp lại, và tỷ lệ thắng từng lần có thể dẫn tới kết luận ngược với hiệu năng trung bình

Bài toán tối ưu hóa mạng cáp quang KIRO

  • KIRO là một bài toán nghiên cứu vận hành từng được nộp cho hackathon dành cho sinh viên kỹ thuật năm 2018, yêu cầu tối thiểu hóa tổng chiều dài cáp bằng cách dùng ma trận khoảng cách có hướng của Grenoble, Nice và Paris
  • Mạng được cấu thành từ các vòng lặp dư bắt đầu từ hub phân phối và các nhánh ngắn tỏa ra từ các cột trên vòng lặp
    • Mỗi cột phải xuất hiện đúng một lần
    • Phải thỏa mãn nhiều ràng buộc cấu trúc
    • Chi phí của đoạn cáp có thể khác nhau nếu đảo chiều
    • Điểm càng thấp thì lời giải càng tốt
  • Mốc chuẩn của con người là một solver C++ từng được viết trong một tuần để giải bài toán này trước đây

  • Quy mô không gian tìm kiếm

    • Do số lượng và kích thước vòng lặp, cùng điểm gốc và thứ tự của các nhánh đều thay đổi, rất khó tính toàn bộ không gian tìm kiếm bằng một công thức đóng duy nhất
    • Chỉ riêng trường hợp gán 532 terminal của Paris cho 11 hub phân phối mà không xét thứ tự hay nhánh đã có 11^532 khả năng
    • Ngay cả khi chỉ tính các lời giải hợp lệ bị giới hạn, dùng 19 vòng lặp mỗi vòng 28 terminal và không có nhánh, không gian tìm kiếm vẫn vào khoảng 10^1223
    • 19 × 28 = 532 nên bao phủ toàn bộ terminal
    • Mỗi vòng lặp đều không vượt giới hạn 30 terminal
    • Công thức tính là (532! / 19!) × 11^19 ≈ 10^1223

Mô hình và điều kiện chạy

  • So sánh các mô hình dòng Claude gồm Fable 5·Opus 4.8·Sonnet 5 và dòng GPT gồm GPT-5.6 Sol·Terra·Luna
  • Mỗi mô hình được chạy ở chế độ thường và chế độ /goal gốc
    • Thời gian tối ưu hóa là 30 phút
    • Giới hạn thời gian của external agent là 1.900 giây
    • Thiết lập suy luận dùng mức tối đa có sẵn trên từng mô hình
    • Môi trường chạy là Harbor 0.1.43, Docker và xác thực thuê bao
  • Trước tiên, tất cả mô hình đều được chạy một lần theo cặp chế độ thường và /goal trong 30 phút không gợi ý
  • Với hai đối tượng so sánh chính là Fable 5 và GPT-5.6 Sol, thí nghiệm được lặp lại cho đến khi mỗi bên có 3 cặp chạy đối ứng
  • Toàn bộ mã, prompt, bảng kết quả, tiêu chí loại trừ và quỹ đạo chạy có trong CLIArena, đây là thí nghiệm tiếp nối của bài benchmark trước

Kết quả của Fable 5 và GPT-5.6 Sol

  • Nếu lấy điểm /goal trừ điểm chế độ thường mà ra giá trị âm thì /goal cho kết quả tốt hơn
  • Fable 5 có ba kết quả chạy như sau
    • Lần 1: thường 32.197 điểm, /goal 31.934 điểm, cải thiện 263 điểm
    • Lần 2: thường 32.516 điểm, /goal 32.324 điểm, cải thiện 192 điểm
    • Lần 3: thường 32.446 điểm, /goal 35.178 điểm, xấu đi 2.732 điểm
  • GPT-5.6 Sol có ba kết quả chạy như sau
    • Lần 1: thường 33.581 điểm, /goal 39.371 điểm, xấu đi 5.790 điểm
    • Lần 2: thường 35.539 điểm, /goal 32.703 điểm, cải thiện 2.836 điểm
    • Lần 3: thường 33.663 điểm, /goal 33.313 điểm, cải thiện 350 điểm

  • Vì sao tỷ lệ thắng và trung bình lại lệch nhau

    • /goal thắng 4 trong 6 lần, nhưng ở cả hai mô hình, đổi lại việc thường xuyên có được các cải thiện nhỏ là đôi khi gặp suy giảm hiệu năng rất lớn
    • Fable 5 có trung bình chế độ thường là 32.386 điểm, trung bình /goal là 33.145 điểm, tức xấu đi 759 điểm
    • Theo trung vị thì cải thiện 192 điểm
    • GPT-5.6 Sol có trung bình chế độ thường là 34.261 điểm, trung bình /goal là 35.129 điểm, tức xấu đi 868 điểm
    • Theo trung vị thì cải thiện 350 điểm
    • Trung bình chế độ thường của Fable 5 tốt hơn Sol 1.875 điểm, và trung bình /goal cũng hơn 1.984 điểm
    • Sự khác biệt cũng thể hiện ở độ ổn định
      • Ba kết quả của Fable 5 ở chế độ thường nằm trong biên độ 319 điểm
      • Sol ở chế độ thường trải trên biên độ 1.958 điểm
    • Fable 5 /goal ghi được điểm tốt nhất toàn bộ là 31.934 điểm
    • Cấu hình an toàn nhất là Fable 5 chế độ thường

Cùng là /goal, nhưng triển khai khác nhau

  • Mô hình đánh giá tách biệt của Claude Code

    • /goal của Claude Code hoạt động như một hook Stop ở phạm vi session
    • Mỗi khi mô hình chính kết thúc một lượt, mô hình đánh giá mặc định là Haiku sẽ đọc điều kiện mục tiêu và hội thoại rồi trả về yes hoặc no kèm lý do
    • Nếu là no thì bắt đầu lượt mới, nếu là yes thì gỡ mục tiêu
    • Mô hình đánh giá không thể dùng công cụ hay kiểm tra tệp, và chỉ phán đoán dựa trên bằng chứng xuất hiện trong lịch sử hội thoại
    • Nó có thể phát hiện trường hợp công việc kết thúc quá sớm, nhưng không thể biết liệu có đáng chạy solver thêm 10 triệu lần nữa hay không
    • Vì Claude Code không mã nguồn mở nên thông tin triển khai dựa vào tài liệu goal của Anthropic

  • Trạng thái bền vững và công cụ vòng đời của Codex

    • Codex CLI 0.144.4 được dùng trong benchmark coi mục tiêu là trạng thái bền vững gắn với thread
    • TUI lưu mục tiêu của thread đang hoạt động và SQLite ghi lại trạng thái cùng mức sử dụng ngân sách
    • Mô hình tác vụ nhận các công cụ create_goal, get_goal, update_goal
    • Khi thread trở nên nhàn rỗi trong lúc mục tiêu vẫn đang kích hoạt, hệ thống sẽ chèn một lượt tiếp theo bao gồm mục tiêu và kiểm tra hoàn tất
    • Claude giao việc phán đoán hoàn tất cho mô hình đánh giá độc lập, nhưng mô hình đó chỉ nhìn thấy lịch sử hội thoại
    • Trong Codex, mô hình tác vụ có thể dùng tệp và công cụ, tự tuyên bố hoàn tất, và nếu mục tiêu bền vững vẫn còn kích hoạt thì sẽ tiếp tục làm việc

Cách /goal khuếch đại chiến lược

  • Với các tác vụ code thông thường, nhờ có thêm lượt nên dễ xác nhận tiến độ như sửa test hay hoàn tất migration
  • Trong tối ưu hóa, sau khi agent chọn solver, thời gian bổ sung có thể khuếch đại cả quyết định đúng lẫn quyết định sai
  • Các trường hợp /goal có ích gồm
    • Tiếp tục chạy danh mục chiến lược biên dịch nhanh của Fable 5
    • Duy trì chiến lược chia lại chuỗi thành công của Sol
  • Ngược lại, cũng có trường hợp làm hiệu năng giảm
    • Fable 5 xây dựng một solver chậm rồi tiếp tục chạy nó
    • Sol bám chặt vào tìm kiếm vét cạn quét toàn bộ điểm gốc
  • Trung vị có cải thiện nhẹ, nhưng phần đuôi của các kết quả xấu lại tệ đi nhiều hơn, khiến hiệu năng trung bình giảm xuống

Giới hạn trong cách diễn giải kết quả

  • Đối tượng thí nghiệm là đúng một bài toán NP-khó chưa công bố, nên không thể xem như bảng xếp hạng coding tổng quát
  • Chỉ Fable 5 và Sol là có đủ 3 cặp chạy đối ứng sạch cho mỗi bên
  • So sánh các mô hình khác bị trộn lẫn các prompt, phiên bản wrapper và giới hạn thời gian khác nhau
  • Vì được chạy tuần tự qua dịch vụ thuê bao nên trạng thái dịch vụ có thể đã thay đổi trong lúc thí nghiệm diễn ra
  • Metadata của tác vụ ghi là 1 CPU, nhưng container lại lộ ra 8 CPU, điều này có lợi cho danh mục chạy song song của Fable 5
  • Nhờ wrapper yêu cầu checkpoint giữa chừng và xác minh cuối cùng, mọi đầu ra của Fable 5 và Sol được tính điểm đều hợp lệ
  • Thứ được đo không phải riêng mô hình mà là toàn bộ hệ thống gồm mô hình, CLI, prompt, dịch vụ thuê bao và harness

Tài liệu tái lập và kết luận

  • CLIArena công khai tác vụ benchmark, wrapper, script phân tích, trình tạo biểu đồ và toàn bộ ghi chú bằng chứng
  • Thư mục tác vụ thô bị loại khỏi Git do kích thước lớn, nhưng ghi chú vẫn lưu mọi điểm số, kết quả theo từng thành phố, thời gian trôi qua, chiến lược, mục loại trừ và ID chạy có thể công bố
  • Các lệnh chạy chính như sau
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal không làm hiệu năng tăng hay giảm theo một chiều cố định; nó có thể thắng trong đa số lần chạy riêng lẻ nhưng vẫn làm xấu đi hiệu năng trung bình quan sát được
  • Trong tối ưu hóa khó, điều quan trọng hơn chất lượng của bản thân vòng lặp điều khiển là chất lượng của chiến lược mà vòng lặp đó lặp đi lặp lại

Bài viết liên quan

1 bình luận

 
GN⁺ 1 ngày trước
Ý kiến trên Hacker News

  • Biểu đồ trên hơi gây rối. Có ghi “càng thấp càng tốt” nhưng trục y lại bị đảo, nên về mặt hình ảnh thì phía trên là tốt hơn còn về mặt số liệu thì càng thấp càng tốt

    • Có vẻ trục không bị đảo. 32.000 ở dưới, 40.000 ở trên, nên có thể đã được sửa sau bình luận đó

  • Claude có xu hướng quên chỉ dẫn trong các công việc dài hạn kéo dài nhiều tuần, dù có nhấn mạnh tầm quan trọng đến đâu. Tôi chưa dùng /goal, nhưng có lẽ nó thực sự giúp ghi nhớ chỉ dẫn cốt lõi. Có vẻ ở đây đang nói về các phiên ngắn hơn, nơi vấn đề này ít nghiêm trọng hơn

    • Tôi đã thêm mức sử dụng ngữ cảnh vào thanh trạng thái của Claude Code, và có vẻ từ khoảng 50~60% là nó thực sự bắt đầu “đuối”. Tôi yêu cầu sửa môi trường kiểm thử và thêm test thì nó trì hoãn, nói rằng đó là “công việc hạ tầng khá lớn”, nhưng sau khi dùng /compact rồi yêu cầu lại thì nó xử lý mà không than phiền
      Tuy vậy, /compact hay lỗi nên tôi không khuyến nghị dùng giữa chừng khi đang làm việc. Nó có liên quan và hữu ích khi chuyển sang công việc mới, nhưng với các chỉnh sửa cần ngữ cảnh của quá trình tạo ra, như trạng thái bế tắc của đoạn code vừa viết, thì không tốt vì nó vứt bỏ quá trình suy nghĩ
    • Đó là một trong những điểm mạnh của pi. Chúng tôi đã tạo lệnh /protect để loại trừ tin nhắn khỏi việc nén, và cũng tự động bảo vệ cả skill. Trong công việc dài hạn, tôi dùng kiểu như /protect your goal is...
    • Sau khi dùng Claude và GPT lâu dài trong nhiều môi trường thực thi, tôi đồng ý rằng nguyên nhân là nén ngữ cảnh. Cách nén của Codex duy trì hội thoại liên tục một cách tự nhiên gần như kỳ diệu, còn với Claude thì phải quản lý rất cẩn thận thời điểm nén
    • Chất lượng giảm từ rất lâu trước khi chạm ngưỡng nén. Cảnh báo nén giống như biển báo “trạm xăng tiếp theo cách 100 dặm”, nhưng thực ra lúc đó bạn đã ở giữa vùng hoang địa rồi
      Không cần quy trình quá phức tạp, nhưng nên theo thứ tự: chia nhỏ công việc → lập kế hoạch trong ngữ cảnh mới → triển khai trong ngữ cảnh mới → /code-review trong ngữ cảnh mới → sửa trong ngữ cảnh mới. Với Fable 5, khi ngữ cảnh vượt 50% thì chất lượng giảm mạnh, đến mức cùng một cách triển khai xuất hiện bốn lần trong codebase. Bắt nó tự rà soát công việc của chính mình trong cùng một phiên cũng giống như để học sinh tự chấm bài thi của mình
    • Ở ngữ cảnh khoảng 700 nghìn token, Fable cũng suy giảm khả năng phán đoán đáng kể. Quyết định của OpenAI khi giới hạn ngữ cảnh Codex ở 400 nghìn có thể là đúng, và có vẻ đó là điểm cân bằng phù hợp để phần lớn ngữ cảnh vẫn còn đáng tin

  • Nếu so sánh chiến lược tìm kiếm thì chế độ Ultra có khả năng vượt trội hơn, nên tôi tò mò về các đánh giá tiếp theo
    Ultra triển khai song song các tác tử nghiên cứu, thực hiện rà soát đối kháng tại các điểm kiểm tra định sẵn, và dùng nhiều kỹ thuật để tránh mắc kẹt ở nghiệm tối ưu cục bộ. /goal phù hợp hơn cho kiểu nghiên cứu theo một đường duy nhất hoặc các công việc phân tán-thu thập quy mô nhỏ

    • Chế độ Ultra cần được mô tả rõ hơn trong tài liệu hoặc gắn thêm cảnh báo. Nhiều lập trình viên, trong đó có tôi, hiểu nó như một tính năng vạn năng khiến mô hình làm việc chăm hơn để cho kết quả tốt hơn, nhưng với nhiều tác vụ thì hiệu năng thực ra có thể tệ hơn và chi phí thì chắc chắn cao hơn

  • Anthropic đang bị OpenAI bỏ xa trong mảng coding. Đến tận tháng 3 năm ngoái tôi vẫn quản lý một kho lưu trữ quy mô 400 nghìn dòng bằng Claude Code trên gói mặc định, nhưng nó rất chậm và dù đã có test, observability, tài liệu và kiến trúc phân tầng thì vẫn không sửa được vấn đề cho ra hồn
    Chúng tôi là một nhóm 3 người giao sản phẩm cho chính quyền địa phương; sau khi chuyển sang Codex thì dễ chịu hơn nhiều và cũng không còn lo lắng về hạn mức sử dụng. Mỗi người trong nhóm đang quản toàn bộ bằng hai tài khoản Codex Plus. Anthropic cần làm ra mô hình hiệu quả hơn thay vì gieo rắc nỗi sợ; không phải ai cũng cần Fable

    • Với tôi thì Opus 4.8 rất xuất sắc, còn Codex chỉ ở mức bình thường. Có lẽ còn tùy người dùng và công việc
    • Điều này thay đổi rất nhiều theo miền bài toán và ngôn ngữ. GPT viết Elixir và xử lý các tác vụ mở khá tệ; hiện tại Opus mạnh hơn về Elixir, còn Fable thì giỏi hơn hẳn cả hai ở khả năng hiểu chính miền vấn đề
      Trong 6 tuần chuyển sang GPT, nó liên tục đưa ra sự tự tin sai lầm nên cuối cùng tôi dừng hẳn, và phần công việc trong giai đoạn đó về cơ bản là lãng phí. Giờ tôi dùng kết hợp Opus/Fable và DeepSeek Pro. DeepSeek vượt trội về chi phí và tốc độ, đủ cho 90% công việc triển khai, nhưng với Elixir thì nó sụp đổ khi cố dùng tính năng runtime ở thời điểm compile. Các vấn đề ban đầu được Fable xử lý rất nhanh
      Mỗi mô hình đều có những điểm mạnh riêng khó phát hiện, nên tôi không nghĩ trong tương lai gần sẽ chỉ dùng một cái. Khi cần chất lượng, tôi sẵn sàng đánh đổi hiệu quả

  • /goal trong công việc của tôi đã thay thế chế độ lập kế hoạch, và tôi dùng cách sau cho 95% tác vụ AI của mình
    Trước hết, tôi yêu cầu nó đọc một tính năng cụ thể và xác nhận rằng nó đã hiểu hoàn toàn, rồi lặp lại nếu bản tóm tắt còn thiếu chi tiết. Sau đó tôi hỏi thời gian hiện tại, rồi dùng /goal để buộc nó viết một tài liệu thiết kế kỹ thuật không mơ hồ trong một khoảng thời gian nhất định, đồng thời phản ánh rõ ràng carry_forward_requirements.md và testing_best_practices.md. Tôi yêu cầu đưa vào các tham chiếu mã và tài liệu cụ thể cùng những thay đổi để ngay cả người triển khai không có ngữ cảnh cũng có thể thực hiện, rồi dùng hết toàn bộ thời gian để rà soát và không được kết thúc sớm
    Chỉ cần ép GPT dành đúng 10 phút để viết tài liệu thiết kế cũng đã cho kết quả chắc chắn hơn nhiều so với chế độ lập kế hoạch, giúp tiết kiệm thời gian chỉnh sửa bản nháp

    • Việc kết thúc theo thời gian có vẻ giống như đặt điều kiện dừng của một hàm đệ quy theo thời gian đã trôi qua chứ không phải theo kết quả thực thi thực tế
      Tôi đưa vào /goal một mục tiêu rõ ràng mà tác nhân phải đạt được. Tôi nêu ra các điều kiện mà thiết kế và kiến trúc phải đáp ứng, rồi liên tục đối chiếu kết quả và chỉ kết thúc khi đã đạt hết. Dù là 10 phút hay 10 giờ, cốt lõi của /goal là hoàn thành một kết quả cụ thể
    • Để tác nhân đạt được mục tiêu một cách ổn định, giai đoạn tạo giả thuyết có vẻ là quan trọng nhất. Bắt đầu ngay từ đầu trong đúng không gian tìm kiếm là yếu tố dự đoán thành công tốt nhất, và dù mô hình có mạnh đến đâu, cách bắt nó tự mò mẫm mọi giả thuyết từ đầu trong một vòng lặp khổng lồ duy nhất có lẽ sẽ đi vào ngõ cụt trong các công việc thực tế
      Trong các lĩnh vực phức tạp, cách tốt nhất để tạo nền tảng cho tác nhân là giao phần điều tra chuyên sâu cho một lệnh gọi công cụ riêng. Nếu giao việc điều tra cho vòng lặp chính của tác nhân, RLHF sẽ làm giảm chất lượng vì nó có xu hướng giữ ngữ cảnh và trả lời nhanh. Khi cung cấp dưới dạng công cụ, nó có thể điều tra nhiều lần mà chẳng nhận ra đang tiêu tốn hàng tỷ token, và dù có lãng phí nhiều token cho việc tạo và kiểm chứng các giả thuyết độc lập, vẫn có thể mở rộng không gian tìm kiếm lên 10~100 lần trước khi thay đổi môi trường. Trong nhiều trường hợp, thứ tự ưu tiên chính xác > thời gian > chi phí là hợp lý
    • Việc coi LLM là đã “hiểu hoàn toàn” điều gì đó nghe khá lạ. Nó giống các kỹ thuật prompt kiểu “cho đến khi bạn tự tin 95%”, nên tôi tò mò điều đó thực sự ảnh hưởng thế nào đến công việc. Tôi cũng thắc mắc nếu viết “cho đến khi chắc chắn là đã hiểu” thì sẽ khác gì

  • Tôi thắc mắc /goal là gì

    • Cả Codex lẫn Claude Code đều cung cấp, nhưng cách hoạt động có hơi khác nhau
      Với Claude Code, Haiku đọc lịch sử hội thoại và phán đoán mục tiêu đã hoàn thành hay chưa; nếu chưa thì nó lại bơm phần việc còn lại vào mô hình chính. Trong Codex, công cụ mà mô hình chính có thể gọi và môi trường thực thi xung quanh sẽ phối hợp hoạt động, rồi lại prompt tiếp nếu chưa có dấu hiệu hoàn tất
      Đây là một tính năng nhằm xử lý tình huống mô hình dừng lại sau khi chỉ hoàn thành một phần công việc do vấn đề chú ý. Thay vì người dùng phải liên tục giục nó tiếp tục, hệ thống sẽ tự động đưa thêm chỉ thị để thúc đẩy hoàn thành công việc
    • Nếu dùng /goal ngay từ đầu trong Claude, nó sẽ không dừng cho đến khi đạt mục tiêu hoặc cạn khả năng của prompt. Cảm giác như “đây là nhiệm vụ, hãy thực hiện nó”, và tôi dùng vài lần mỗi tuần
    • Đây là tính năng lặp chạy LLM cho đến khi nó đáp ứng được điều kiện mục tiêu
    • Chính xác hơn là nó lặp cho đến khi tự đánh giá rằng mình đã hoàn thành mục tiêu
    • Bản thân tác nhân là một cấu trúc lặp chạy LLM rồi quyết định có nên dừng hay không. /goal gần giống như đặt thêm một tác nhân cha ở phía trên, liên tục ra lệnh “vẫn chưa xong nên hãy tiếp tục” cho đến khi tác nhân con phán đoán là đã xong

  • Từ sau khi phát hành, tôi đã dùng rất nhiều GPT 5.6 Sol Xhigh và Fable 5. Trí tuệ của nó có vẻ tương tự 5.5, nhưng độ lì được đẩy lên cực cao nên tỷ lệ hoàn thành nhiệm vụ và khả năng cạnh tranh trên benchmark dường như tốt hơn. Mặt khác, khả năng dùng tới các phương pháp bất thường hoặc rủi ro cũng tăng lên nên phải giám sát liên tục
    Gần đây nó đã cố đọc các biến môi trường runtime không liên quan đến công việc qua CLI, và khi không truy cập được khóa SSH thì nó yêu cầu quyền điều khiển máy tính. Sau khi tôi dừng lại và hỏi lý do, nó trả lời rằng đã định tự lục 1Password để tìm khóa, và khi tôi truy vấn tiếp thì nó thừa nhận các biến môi trường runtime đó thực ra không cần thiết. Từ đó tôi đã tắt chế độ “approve for me” và chỉ dùng nó cho các thay đổi đơn giản và sửa lỗi
    Fable không chỉ thông minh hơn mà còn có trực giác tốt hơn, nắm bắt ý đồ tốt và hành xử như một quản lý sản phẩm chuyên sâu theo miền dựa trên kiến thức thực tế. Nó cũng đưa ra các đề xuất ngoài dự đoán, trong khi với GPT 5.6 thì phải chỉ dẫn sát nghĩa hơn nhiều

    • Fable có vẻ là mô hình lớn hơn nên chi phí chạy cao hơn, và trong kỹ nghệ phần mềm thông thường thì không có vẻ vượt trội, nhưng trong các công việc đòi hỏi trí tuệ thuần túy thì quy mô có thể là lợi thế
      Trong DeepSWE 1.1, 5.6-Sol xhigh có điểm hơi cao hơn Fable 5 trong khi số token chỉ bằng một nửa và chi phí khoảng một phần ba. Ngược lại, trong chỉ số trí tuệ của Artificial Analysis, Fable 5 nhỉnh hơn một chút nhưng chi phí gấp ba
      Khi lập trình, tôi gửi cùng một tác vụ cho cả hai mô hình để nhận nhiều câu trả lời, nhưng vì kết quả mang tính chủ quan nên khó đoán bên nào sẽ thắng. Tác vụ trong bài gốc có ưu điểm là có thể định lượng, nhưng nhiều công việc phần mềm thì khó đánh giá theo cách đó

  • Vì GPT gần đây đã đánh bại các thí sinh con người hàng đầu trong cuộc thi heuristic AtCoder, nên với các bài toán tối ưu hóa kiểu này nó đáng lẽ phải mạnh hơn. Có vẻ Anthropic tương đối ít tập trung vào loại này

  • Tôi muốn thấy không chỉ điểm số cuối cùng mà cả điểm tốt nhất theo thời gian. Như vậy sẽ hữu ích hơn để đánh giá hiệu quả của /goal

  • Mỗi mô hình chỉ được đánh giá một lần, và vì đây là một không gian bài toán rộng cần nhiều lần thử mới giải tốt được nên phần lớn kết quả trông giống nhiễu

    • Thực tế tôi đã chạy nhiều hơn với việc thay đổi prompt và thời gian thực thi, nhưng mỗi lần ảnh hưởng của /goal đều nhỏ hoặc không có ý nghĩa