Benchmark mới: agent phải gom chứng cứ

Benchmark mới: agent phải gom chứng cứ

WANDR không chỉ là benchmark mới. Nó là tín hiệu rằng research agent đang bị kéo từ trả lời hay sang thu thập đủ, đúng, có chứng cứ.

“Em ơi, agent research của mình tìm giúp danh sách công ty vừa thay CFO nhé.”

Nghe như một task vô hại. Cho tới khi bạn mở spreadsheet ra và thấy 12 dòng đầu rất đẹp, 8 dòng sau bắt đầu lẫn tin bổ nhiệm nội bộ, vài link là bài tổng hợp không có nguồn gốc, còn một công ty thì… không ở Mỹ.

Đây là kiểu lỗi mà demo hiếm khi phơi ra. Demo thích một câu trả lời gọn. Production lại cần một bộ bằng chứng đủ lớn, đủ đúng, đủ kiểm được. Và đó là lý do mình thấy WANDR đáng bàn: không phải vì nó là benchmark mới, mà vì nó cho thấy thị trường đang đổi tiêu chí chấm agent.

Nói thẳng ra thì: research agent sắp bị đánh giá như người làm ops dữ liệu, không phải như chatbot viết văn hay.

Sơ đồ minh họa cho bài Benchmark mới: agent phải gom chứng cứ

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu lạ: benchmark không hỏi “trả lời gì”, mà hỏi “gom được bao nhiêu chứng cứ”

WANDR, viết tắt của Wide ANd Deep Research, là benchmark mở và evaluation harness — bộ bài test kèm khung chấm điểm — cho research agent. Điểm khác nằm ở chữ wide và deep.

Điều này khác khá xa kiểu benchmark hỏi một câu rồi chấm một đáp án. Nếu ví việc đánh giá agent như xem tranh, benchmark cũ thường nhìn bức tranh hoàn thiện từ xa: bố cục ổn không, màu có đẹp không. WANDR bắt đầu soi từng lớp nền: nét nào có chứng cứ, mảng nào chỉ được tô cho đầy.

Ví dụ cụ thể: task ceo_cfo_appointments yêu cầu ít nhất 70 công ty tại Mỹ có thông báo bổ nhiệm CEO hoặc CFO lần đầu trong khoảng 1/3 đến 30/4/2026. Mỗi công ty cần một trang bổ nhiệm có thẩm quyền. Subtask còn thêm trang authority listing cho mỗi công ty. Tổng cộng là 140 record có nguồn chống lưng.

Đây không còn là “hãy viết report về xu hướng thay CFO”. Đây là “hãy xây một collection mà từng dòng đều kiểm được”.

Ai hưởng lợi khi tiêu chí đổi từ câu trả lời sang collection?

Tín hiệu thị trường ở đây khá rõ: bên nào kiểm soát được search, evidence, và interface cho agent sẽ có lợi thế.

Perplexity không chỉ tung WANDR. Họ còn có pplx, một CLI chính thức cho Search API. pplx không phải chat client. Nó có hai bề mặt làm việc rất gọn:

pplx search web "CEO CFO appointment March April 2026 US company"
pplx content fetch "https://example.com/press-release"

Điểm đáng chú ý không phải lệnh ngắn. Điểm đáng chú ý là contract cho agent:

Với builder, đây là một nét cọ rất thực dụng: agent không cần đọc giao diện web, không cần đoán HTML, không cần parse trang kết quả như trò may rủi. Nó nhận JSON, branch theo error.code, lưu artifact, rồi đi tiếp.

Cùng lúc đó, Pinecone nói về text match filters — bộ lọc khớp văn bản để ép phạm vi retrieval. Semantic search, tức tìm kiếm theo nghĩa, có thể trả kết quả “gần nghĩa” nhưng sai ngữ cảnh. Người đọc thấy sai thì bỏ qua. Agent thì dễ coi đó là sự thật rồi xây tiếp tool call phía sau.

Ví dụ Pinecone đưa ra: hỏi “top presidential candidates” ở Mỹ nhưng kết quả semantic lại về bầu cử Pháp. Với người, thiếu chữ “US” vẫn hiểu được. Với agent, thiếu chữ đó có thể kéo cả pipeline lệch hướng.

Ghép các mảnh lại, mình thấy một shift: agent stack đang cần lớp kiểm soát phạm vi và bằng chứng nhiều hơn cần thêm một model biết nói trơn tru.

Mổ xẻ WANDR: cái hay nằm ở cây điều kiện

Một chi tiết trong WANDR rất đáng để team builder mượn về: qualification key hierarchy — cây điều kiện dùng để mô tả cấu trúc bằng chứng cần thu thập.

Ví dụ dạng:

company(n) -> employee(m) -> url(k)

Hiểu nôm na: cần n công ty đủ điều kiện, mỗi công ty cần m nhân viên, mỗi nhân viên cần k URL hỗ trợ. Mỗi đường đi hoàn chỉnh trong cây được validate riêng.

Đây là điểm khác biệt quan trọng. Nhiều team hiện vẫn chấm research agent bằng output cuối:

Nhưng WANDR gợi ý cách chấm theo path:

Hình dung thế này: team bạn đang build agent để làm competitor mapping cho khách hàng B2B SaaS. Nếu chỉ yêu cầu “tìm 50 đối thủ”, agent sẽ nhặt đủ thứ: đối thủ trực tiếp, công cụ bổ trợ, bài blog so sánh, thậm chí vendor đã ngừng hoạt động. Nhưng nếu bạn định nghĩa cây:

company(50) -> product_page(1) -> pricing_page(1) -> proof_url(2)

thì agent không được phép chỉ nộp danh sách tên. Nó phải chứng minh từng công ty có sản phẩm liên quan, có trang pricing, và có nguồn để kiểm.

Đây là framework mình muốn bạn mang về: đừng prompt agent làm research; hãy vẽ schema bằng chứng trước.

Thứ nên giữ: evaluation theo artifact, không theo cảm giác

Nếu bạn đang làm tech lead, mình sẽ không khuyên “đổi ngay sang WANDR” như một nghi thức cho đủ trend. Thứ đáng giữ là cách nghĩ.

Một research agent production nên tạo ra artifact có thể test được:

{
  "entity": "Example Corp",
  "claim": "Announced CFO appointment between March 1 and April 30, 2026",
  "evidence_url": "https://example.com/news/cfo-appointment",
  "authority_url": "https://example.com/company/leadership",
  "checked_at": "2026-07-28",
  "confidence_reason": "Official company press release and leadership page match the appointment"
}

Không cần copy y nguyên. Nhưng bạn nên có các field kiểu:

Điểm quan trọng: cho phép agent thất bại có cấu trúc. Một dòng “không tìm thấy authority page” hữu ích hơn một dòng được điền bừa cho đủ quota.

Đây cũng là nơi các công cụ như pplx có ích: output JSON ổn định, lỗi có mã, có thể chạy trong coding agent hoặc pipeline CI nhẹ. Và đây là nơi text match filters có ích: đừng để agent tìm “ứng viên tổng thống” rồi tự quyết quốc gia bằng linh cảm.

Thứ nên bỏ qua: đừng biến benchmark thành bảng màu để khoe

Có một bẫy quen thuộc: thấy benchmark mới là lập tức hỏi “model nào đứng đầu?”. Với WANDR, câu hỏi đó hơi lệch.

Vì bài toán wide-and-deep không chỉ phụ thuộc model. Nó phụ thuộc ít nhất 5 lớp:

  1. Search strategy: agent mở rộng truy vấn thế nào.
  2. Retrieval scope: dữ liệu được lọc theo ngữ cảnh ra sao.
  3. Evidence extraction: trích claim từ trang nguồn có ổn không.
  4. Deduplication: có loại trùng thực thể và URL không.
  5. Validation loop: thiếu bằng chứng thì retry hay đánh dấu fail.

Một model mạnh có thể viết reasoning hay hơn, nhưng nếu retrieval kéo nhầm vùng, nó vẫn tô sai màu lên canvas. Ngược lại, một model vừa đủ nhưng có schema, filter, và tool contract rõ có thể cho output dễ vận hành hơn.

Ở đây, OpenWorker cũng là tín hiệu phụ đáng nhìn: desktop agent chuyển từ chat sang deliverable — sản phẩm hoàn chỉnh. Photon-1 thì đẩy hướng agent học từ video và trạng thái màn hình. Hai hướng này khác nhau, nhưng cùng nói một chuyện: thị trường đang rời khỏi “model trả lời” để tiến về “hệ thống hoàn thành việc”.

Và khi hệ thống hoàn thành việc, evaluation phải bám vào việc thật: file nào được tạo, record nào đúng, URL nào chứng minh, action nào có side effect.

Khung quyết định cho team Việt Nam: mua model hay xây harness?

Nếu là team nhỏ ở Việt Nam, ngân sách và thời gian đều có hạn, mình sẽ dùng khung 3 câu này trước khi đổ tiền vào model mới:

1. Task của bạn là answer hay collection?
Nếu người dùng cần một câu trả lời tổng hợp, benchmark kiểu long-form report có thể đủ. Nếu người dùng cần danh sách lead, hồ sơ vendor, mapping đối thủ, literature table, thì bạn đang ở vùng WANDR.

2. Mỗi dòng output có cần chứng cứ độc lập không?
Nếu có, hãy thiết kế schema trước prompt. Đừng chờ agent trả về rồi mới nghĩ cách kiểm.

3. Sai phạm vi có đắt không?
Nếu retrieval sai làm kéo theo nhiều tool call, nhiều token, hoặc quyết định kinh doanh sai, bạn cần filter và validation sớm. Pinecone gọi đúng bệnh: unstated context — ngữ cảnh người dùng ngầm hiểu nhưng hệ thống không biết — là nguồn lỗi rất độc.

Một buổi chiều đủ để làm bản phác thảo đầu tiên:

Độc giả sẽ nghĩ khác điều gì sau bài này? Đừng hỏi “agent này thông minh cỡ nào?” trước. Hãy hỏi: agent này có gom được đủ bằng chứng có cấu trúc cho công việc của mình không?

Vì trong production, một câu trả lời bóng bẩy mà thiếu chứng cứ chỉ là lớp sơn đẹp trên nền còn ướt — nhìn xa thì ổn, chạm vào là lem.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo