Grok 4.7 xử lý tác vụ lập trình kéo dài nhiều giờ tốt hơn Grok 4.6. Tuy nhiên, mô hình chưa đủ tin cậy để làm việc hoàn toàn không có giám sát. Grok 4.7 đạt 38.0% trên Terminal-Bench 4.0, tăng từ 20.3%. Kết quả này vẫn đồng nghĩa với thất bại trong phần lớn trường hợp của phép đánh giá.
Theo bài viết của The New Stack về sức bền của Grok 4.7, SpaceXAI phát hành mô hình sau một đợt học tăng cường dài hơn. Quá trình huấn luyện ưu tiên những bài toán khó có thể cần “nhiều giờ” để hoàn thành. Công ty cho biết mô hình cũng quản lý ngữ cảnh dài và kiểm tra lại công việc tốt hơn.
Một tác tử lập trình chạy liên tục trong nhiều giờ có thể đưa ra hàng chục quyết định khi sửa tệp, chạy kiểm thử và xử lý lỗi. Một hướng đi sai có thể ảnh hưởng đến toàn bộ phần việc còn lại nếu tác tử không tự phát hiện. Mỗi lần thử sai cũng làm lịch sử tương tác dài thêm, khiến một giả định không chính xác tiếp tục chi phối các bước sau.
Khả năng quản lý ngữ cảnh và tự xác minh quyết định tác tử có thể làm việc lâu mà không cần người giám sát hay không. Đây là giới hạn quan trọng khi đánh giá cách tác tử lập trình trí tuệ nhân tạo hoạt động trong dự án thực tế.
Nội dung các điểm chuẩn cho thấy tiến bộ chưa đồng nghĩa với ổn định
Grok 4.7 cải thiện rõ rệt trên ba phép đánh giá được công bố, nhưng kết quả chưa cho thấy độ ổn định cần thiết để giao toàn bộ quy trình cho tác tử. Theo The New Stack, trên Terminal-Bench 4.0, tỷ lệ thành công 38.0% đồng nghĩa mô hình vẫn không hoàn thành phần lớn trường hợp thử nghiệm.
Mức tăng trên ba phép đánh giá
Trên Terminal-Bench 4.0, Grok 4.7 đạt 38.0%, tăng từ 20.3% của Grok 4.6. Theo The New Stack, điểm CursorBench 4.0 cũng tăng từ 40.4% lên 46.3%. Đây là phép đánh giá các quy trình lập trình kéo dài trong trình soạn thảo. Ở AA Briefcase v1.1, bài đánh giá công việc chuyên môn kéo dài nhiều giờ, điểm số tăng từ 1,546 lên 1,657.
Mức cải thiện giữa hai thế hệ là rõ ràng, nhưng Grok 4.7 vẫn chưa dẫn đầu. Theo bảng xếp hạng độc lập Terminal-Bench 4.0, Claude Fable 5.1 của Anthropic đạt 57.9%. Mức này cao hơn Grok 4.7 đúng 19.9 điểm phần trăm.
Một phép đánh giá gần đây trên các kho mã riêng còn cho thấy ngay cả mô hình đứng đầu cũng thất bại hơn 60% số lần. The New Stack dẫn kết quả này để minh họa khoảng cách giữa khả năng hoàn thành một phần tác vụ và độ tin cậy cần thiết để giao toàn bộ quy trình cho tác tử.
SpaceXAI cho rằng kết quả mới đến từ việc kết hợp mô hình nền lớn hơn với đợt học tăng cường kéo dài, tập trung vào các bài toán khó và tốn nhiều giờ. Công ty nhấn mạnh hai cải thiện là tự xác minh và quản lý ngữ cảnh dài, nhưng chưa giải thích cơ chế cụ thể.
Những chi tiết SpaceXAI chưa công bố
Chưa có thông tin về nguồn gốc của khả năng quản lý ngữ cảnh tốt hơn. Nó có thể liên quan đến kiến trúc, kỹ thuật tóm tắt, truy xuất dữ liệu hoặc khả năng ghi nhớ trong chuỗi tương tác dài. SpaceXAI cũng chưa công bố cách họ đánh giá khả năng tự xác minh trong quá trình học tăng cường. Các điểm số xác nhận kết quả tốt hơn. Tuy vậy, chúng chưa chỉ ra phần nào trong phương pháp huấn luyện tạo ra mức tăng đó.
Khung điều phối đang trở thành một phần của mô hình
SpaceXAI huấn luyện Grok 4.7 để hiểu trực tiếp khung điều phối Grok Bot. Việc tích hợp với hạ tầng vận hành có thể giảm công sức diễn giải công cụ và phản hồi thực thi. Đổi lại, hiệu suất của tác tử có thể phụ thuộc nhiều hơn vào môi trường đã dùng trong huấn luyện.
Khung điều phối hỗ trợ tác tử như thế nào
Khung điều phối đảm nhận phần việc bao quanh mô hình. Nó cung cấp công cụ, định dạng phản hồi từ thiết bị đầu cuối và đưa kết quả thực thi trở lại ngữ cảnh. Khung này cũng quyết định bước tiếp theo. Mô hình đã quen với khung điều phối không phải học lại mọi định dạng công cụ và kiểu tương tác khi bắt đầu chạy.
Việc tích hợp từ giai đoạn huấn luyện có thể giảm chi phí xử lý phát sinh khi tác tử dùng công cụ và thực hiện nhiều bước liên tiếp. Tuy nhiên, SpaceXAI chưa công bố đủ chi tiết để tách riêng phần cải thiện đến từ Grok Bot khỏi phần đến từ mô hình nền và quá trình học tăng cường.
Rủi ro phụ thuộc vào môi trường huấn luyện
Cách tiếp cận này cũng tạo ra một rủi ro cho nhà phát triển. Mô hình có thể được tối ưu quanh một lược đồ công cụ, định dạng ngữ cảnh và môi trường thực thi cụ thể. Khi đó, việc thay sang mô hình khác có thể làm giảm hiệu suất của tác tử. Đây là vấn đề rộng hơn của hạ tầng trí tuệ nhân tạo và cách vận hành. Chất lượng phụ thuộc vào cả mô hình lẫn hệ thống bao quanh nó.
OpenAI đi theo hướng tương tự khi mở khung điều phối Codex dưới dạng Agents API. Hạ tầng dành cho tác tử chạy dài nhờ đó trở thành một dịch vụ được quản lý. Google chọn hướng khác để giúp ngôn ngữ Go dễ sử dụng hơn với tác tử trí tuệ nhân tạo. Công ty thay đổi môi trường phát triển thay vì huấn luyện mô hình quanh môi trường đó.
Cả hai cách cho thấy mô hình không còn là thành phần duy nhất được tối ưu. Công cụ, giao diện thực thi và cơ chế phản hồi kết quả cũng tác động trực tiếp đến hiệu quả của tác tử.
Chi phí thấp hơn chưa giải quyết được tỷ lệ thất bại
Grok 4.7 có mức giá có thể giảm chi phí cho những phiên tác tử kéo dài. Tuy nhiên, giá token thấp hơn không làm giảm hậu quả của một quyết định sai. Theo The New Stack, với tỷ lệ thành công 38.0% trên Terminal-Bench 4.0, quy trình vẫn cần kiểm thử, điểm dừng và cơ chế kiểm chứng.
Giá token và chi phí chạy tác tử
Theo tài liệu mô hình của xAI, Grok 4.7 có giá khởi điểm 2 USD cho mỗi một triệu token đầu vào. Giá đầu ra là 6 USD cho mỗi một triệu token. Mức giá này có thể giúp các phiên kéo dài nhiều giờ ít tốn kém hơn. Dù vậy, chi phí thấp hơn không loại bỏ rủi ro từ một chuỗi quyết định sai.
Khoảng cách trên Terminal-Bench 4.0 vẫn đáng kể. Grok 4.7 đạt 38.0%, trong khi Claude Fable 5.1 đạt 57.9% theo bảng xếp hạng độc lập. Grok 4.7 tiến bộ mạnh so với Grok 4.6 nhưng vẫn thất bại trong phần lớn trường hợp của phép đánh giá này.
Kiểm chứng vẫn là yêu cầu bắt buộc
Đối với đội ngũ phát triển, kết quả đó đặt trọng tâm vào khâu kiểm chứng. Thời gian tác tử có thể chạy không phải thước đo duy nhất. Một hệ thống làm việc hàng giờ không có nhiều giá trị nếu lỗi ở bước đầu lan sang hàng chục bước sau. Vì điểm chuẩn cho thấy tỷ lệ thất bại còn cao, việc xác minh yêu cầu hợp nhất mã cần diễn ra trước khi tác tử chuyển sang bước tiếp theo. Đây là phần không thể tách rời khi tự động hóa đảm nhận nhiều công việc hơn.
Grok 4.7 cho thấy ba hướng phát triển của tác tử chạy dài. Mô hình được huấn luyện trên tác vụ lâu hơn, tăng khả năng tự kiểm tra và gắn chặt hơn với khung điều phối. Các điểm chuẩn cũng cho thấy giới hạn của hướng tiếp cận này. Tác tử có thể làm việc lâu hơn trước. Người dùng vẫn cần kiểm chứng kết quả thay vì mặc nhiên tin rằng công việc đã được hoàn thành đúng.
Hãy tiếp tục theo dõi Sine để cập nhật cách các tác tử lập trình tiến từ chạy lâu sang làm việc đáng tin cậy hơn.
