Phần lớn tin tức về bản phát hành “Open Data for Agents” của NVIDIA đóng khung nó như một câu chuyện huấn luyện model: đây là một kho trajectory khổng lồ, đây là cách bạn fine-tune một agent trên đó. Điều đó đúng, nhưng nó làm giảm giá trị thực sự của bản phát hành này nếu bạn không huấn luyện foundation model — mà đang điều hành một team xây dựng công cụ nội bộ trên nền Claude Code, Cursor, hoặc một agent harness tự phát triển, và bạn không có cách hệ thống nào để trả lời câu hỏi “agent của chúng ta thực sự đang tốt lên hay tệ đi theo thời gian”.

Các bộ dữ liệu — Open-SWE-Traces (hơn 200 nghìn trajectory), SWE-Zero (318 nghìn trajectory), SWE-Hero (34 nghìn trajectory) — đáng đọc không phải vì trọng số model chúng sẽ tạo ra, mà vì cấu trúc (schema) mà chúng chuẩn hóa. Cấu trúc đó là một định dạng eval nội bộ tốt hơn nhiều so với những gì phần lớn các team đang dùng hiện nay.

Một trajectory thực sự chứa gì

Một trajectory trong định dạng này không phải là cặp prompt/response. Đó là bản ghi đầy đủ của một phiên agent: mô tả tác vụ, mọi lệnh gọi tool mà agent thực hiện theo trình tự, giá trị trả về của tool, phần suy luận của agent giữa các lệnh gọi, và kết quả cuối cùng (một patch, kết quả test, hoặc một thất bại). Các trajectory của Open-SWE-Traces được tổng hợp bằng cách chạy SWE-agent và OpenHands trên các issue GitHub thực tế, với Minimax-M2.5 tạo ra các trace “có suy luận hiển thị” và Qwen3.5-122B-A10B tạo ra tập so sánh “không có suy luận hiển thị” — bản thân đây là một lựa chọn thiết kế hữu ích: nó cho bạn dữ liệu ghép cặp về việc một bước suy luận hiển thị làm thay đổi độ chính xác của tool call trên cùng một tác vụ đến mức nào.

Cấu trúc đó — tác vụ, các lệnh gọi tool theo thứ tự, trạng thái trung gian, kết quả cuối cùng — chính xác là những gì bạn cần để trả lời các câu hỏi mà team bạn gần như chắc chắn chưa trả lời được ngay bây giờ: agent của chúng ta retry những tool call nào một cách không cần thiết? Nó ảo giác ra đường dẫn file sai ở đâu thay vì kiểm tra trước? Kiểu thất bại nào lặp lại xuyên suốt các tác vụ không liên quan?

Tái sử dụng schema này cho eval harness của riêng bạn

Bạn không cần chính các bộ dữ liệu của NVIDIA để có được giá trị ở đây — bạn cần áp dụng schema trajectory của họ lên log của chính agent bạn. Phần lớn agent harness (kể cả Claude Code) đã phát ra thứ gần giống thế này nếu bạn ghi lại toàn bộ transcript thay vì chỉ output cuối cùng. Đây là phiên bản tối giản của schema đó mà bạn có thể áp dụng ngược lên log hiện có:

from dataclasses import dataclass, field
from typing import Literal

@dataclass
class ToolCall:
    name: str
    args: dict
    result: str
    succeeded: bool

@dataclass
class Trajectory:
    task_id: str
    task_description: str
    tool_calls: list[ToolCall] = field(default_factory=list)
    outcome: Literal["success", "partial", "failure"] = "failure"
    outcome_detail: str = ""  # vd: output test, patch diff, error trace

def failure_signature(traj: Trajectory) -> str:
    """Rút gọn một trajectory thất bại thành chữ ký có thể so sánh để gom cụm."""
    failed_calls = [tc.name for tc in traj.tool_calls if not tc.succeeded]
    return f"{traj.outcome}:{'>'.join(failed_calls[-3:])}"  # 3 tool call thất bại cuối cùng

def cluster_failures(trajectories: list[Trajectory]) -> dict[str, int]:
    from collections import Counter
    sigs = [failure_signature(t) for t in trajectories if t.outcome == "failure"]
    return dict(Counter(sigs).most_common(10))

Chạy cluster_failures trên log phiên agent của bạn trong một tuần, bạn sẽ có một danh sách xếp hạng các dạng thất bại lặp lại — không phải “agent thất bại 40 lần”, mà là “37 trong số 40 lần thất bại đó kết thúc theo cùng một khuôn mẫu ba tool call: grep không trả về gì, read đoán sai đường dẫn, edit thất bại vì số dòng đã cũ.” Đó là một báo cáo lỗi có thể hành động được, nhắm vào chính công cụ hoặc thiết kế prompt của bạn, được tạo ra từ dữ liệu bạn đã có sẵn nhưng chưa từng cấu trúc hóa.

Vì sao sự phân tách “có suy luận” và “không suy luận” quan trọng hơn vẻ ngoài của nó

Cách tiếp cận tổng hợp ghép cặp — cùng một tác vụ, cùng công cụ, một lượt chạy có trace suy luận hiển thị và một lượt không có — là phần tôi thực sự sẽ “mượn” cho việc đánh giá nội bộ, độc lập với chính các bộ dữ liệu đó. Nếu bạn đang cân nhắc có nên bật extended thinking, thêm một bước lập kế hoạch, hay thêm dòng system prompt “suy nghĩ trước khi gọi tool” cho agent của mình hay không, cách đo lường trung thực sự khác biệt đó không phải là cảm tính — mà là chạy cùng một tập tác vụ theo cả hai cách rồi so sánh kết quả trajectory, không chỉ pass/fail mà cả hiệu quả tool-call (ít lệnh gọi lãng phí hơn, ít đoán sai đường dẫn hơn, phục hồi lỗi sạch hơn).

Phần lớn các team bỏ qua việc này vì xây dựng harness để chạy cùng tập tác vụ hai lần rồi diff trace nghe có vẻ tốn công. NVIDIA đã công bố hiệu quả một bản triển khai tham chiếu cho harness đó ở quy mô dataset — bạn có thể xây một phiên bản nhỏ hơn nhiều, giới hạn trong phân bố tác vụ của repo mình, trong một buổi chiều.

Những giới hạn cần thừa nhận thẳng thắn

Đây là dữ liệu kiểu SWE-bench — giải quyết issue GitHub trên các repo công khai, tối ưu cho tính đúng đắn của patch dựa trên bộ test đã biết. Nó không bao phủ các kiểu thất bại quan trọng nhất trong nhiều bối cảnh công cụ nội bộ: hội thoại nhiều lượt với ý định con người mơ hồ, các tác vụ chạm vào API nội bộ độc quyền mà model chưa từng thấy, hay các phiên chạy dài kéo dài nhiều ngày thay vì một lần ngồi. Fine-tune trực tiếp trên Open-SWE-Traces sẽ cải thiện các tác vụ sửa code chung chung, nhưng sẽ cho bạn biết rất ít về các kiểu thất bại thực sự của agent nội bộ trên chính codebase của bạn.

Đó chính xác là lý do vì sao schema, chứ không phải trọng số, mới là phần đáng tái sử dụng. Dữ liệu trajectory công khai huấn luyện ra một model chung chung tốt hơn một chút. Dữ liệu trajectory của chính bạn, được ghi lại theo cùng định dạng có cấu trúc, mới là thứ duy nhất cho bạn biết nơi triển khai agent cụ thể của bạn đang thực sự gãy — và cho tới nay, phần lớn các team chưa có một khuôn mẫu chuẩn để ghi lại nó. Bản phát hành này giống một lời nhắc nhở “hãy bắt đầu ghi log phiên agent của bạn dưới dạng trajectory có cấu trúc, không chỉ output cuối cùng” chẳng kém gì việc nó là một kho dữ liệu huấn luyện.

Nguồn:

Xuất nội dung

Bình luận