Trả lời ngắn: Research agent là runtime hỗ trợ chia câu hỏi, tìm và đọc nguồn, rồi ghép evidence trong phạm vi đã đặt. Nó không biến link thành sự thật và không thay researcher. Một case an toàn cần query plan, source policy, evidence ledger, citation, uncertainty, read-only tools và human review trước khi dùng bản draft.

Đọc xong, bạn sẽ hiểu:

  • Cách biến một câu hỏi rộng thành query plan có scope và cutoff date.
  • Cách ghi claim, source, excerpt, date và confidence trong evidence ledger.
  • Cách tách fact, inference và unknown trước khi viết synthesis.
  • Cách đặt citation, stop gate và human review cho một research flow giả.

Lưu ý giáo dục: Đây là case study read-only dùng nguồn public/official hoặc fixture giả. Không nhập credentials, PII, customer data, private prompt hay tài liệu chưa được phép. Citation và score không phải certification, legal advice, investment advice hoặc bảo đảm output đúng tuyệt đối.

1. Case study: research agent giải bài toán nào?

Research agent là runtime hỗ trợ chia câu hỏi, tìm/đọc nguồn và ghép evidence trong scope; nó không phải “người biết mọi thứ trên internet”. Ta dùng một request giả: “Trong quý gần đây, một ngành giả định thay đổi ở điểm nào? Hãy tạo bản note có nguồn để người review đọc.”

Trước khi tìm, chốt năm điều:

  • User: research analyst cần bản nháp để tiết kiệm bước thu thập.
  • Outcome: research note có claim, evidence, citation và phần chưa biết.
  • Scope: ngành giả định, public/official documents, một cutoff date rõ.
  • Không làm: không đưa lệnh mua bán, không suy ra nguyên nhân khi nguồn chỉ mô tả hiện tượng, không mở private data.
  • Review gate: analyst đọc lại source và quyết định có dùng claim hay không.

Model tóm tắt một đoạn; search assistant trả link. Research agent nối các bước phân rã câu hỏi, search/read, ghi evidence, nhận diện gap và tạo draft, nên cần state, source rule và điểm dừng.

Ví dụ đời thường: search assistant giống người thủ thư đưa ba quyển sách; research agent giống trợ lý ghi câu hỏi vào sổ, tìm đúng ngăn, chép trang liên quan, đánh dấu chỗ hai quyển mâu thuẫn rồi đưa bản note cho biên tập viên. Trợ lý không tự xuất bản sách.

Hình 1 — Research flow read-only từ câu hỏi tới evidence packet và human review, không có bước tự phát hành.

2. Query plan và source policy

Query plan là danh sách sub-question và thứ tự tìm. Một câu hỏi rộng như “ngành thay đổi gì?” nên tách thành:

  1. Có sự kiện hoặc policy nào được nguồn chính thức ghi nhận không?
  2. Chỉ số hoặc mô tả nào cho thấy thay đổi, trong cutoff date nào?
  3. Nguồn primary nói trực tiếp gì; nguồn secondary chỉ giải thích gì?
  4. Claim nào còn thiếu evidence hoặc đang mâu thuẫn?

Agent không nên chạy một câu query dài rồi lấy top link đầu tiên. Query plan giúp biết mình đang tìm để trả lời sub-question nào, tránh over-retrieval và dễ review lại.

Source tier là nhóm nguồn theo authority, proximity và mục đích dùng. Primary document, trang tổ chức chịu trách nhiệm hoặc dữ liệu công khai gốc thường phù hợp để support fact trực tiếp. Secondary analysis giúp thêm bối cảnh nhưng không tự thay primary source. Một blog không biến thành evidence mạnh chỉ vì đoạn viết tự tin.

Source policy cũng cần ghi:

  • domain/collection được phép tìm;
  • cutoff date và version;
  • nguồn nào chỉ để discovery, nguồn nào được cite;

Microsoft mô tả các kiến trúc search/tool-use theo agent, skill và tool; search có thể là một capability được gọi khi cần, còn logic deterministic giúp precision và giảm chi phí ở bước lặp. Microsoft search and tool use architectures

Hình 2 — Source policy xếp nguồn theo mục đích, authority và freshness; không lấy discovery snippet làm citation cuối.

3. Retrieval, evidence ledger và claim graph

Evidence ledger là bảng nối claim, source, excerpt, date, status và confidence. Đây là nơi biến “agent đã tìm thấy vài link” thành bằng chứng có thể kiểm. Provenance là dấu vết nguồn gốc của claim hoặc đoạn thông tin: người review cần mở lại được source và biết agent đã dựa vào đoạn nào.

Một flow read-only có thể gồm:

  1. Agent đọc query plan và chọn sub-question đầu tiên.
  2. Gọi search_documents(query, cutoff_date); chỉ nhận metadata và link được phép.
  3. Gọi read_source(url); lưu title, publisher, date, excerpt và source version.
  4. Chuẩn hóa claim nhỏ, không gộp hai ý chưa có cùng evidence.
  5. Đối chiếu nguồn thứ hai; đánh dấu SUPPORTED, CONFLICT, MISSING hoặc OUT_OF_SCOPE.
  6. Đưa claim bundle vào synthesis, còn gap vào phần cần review.

Một claim graph đơn giản nối claim → evidence → source → date → citation. Nếu một claim có hai nguồn mâu thuẫn, graph không nên tự chọn câu nghe thuận. Trạng thái phải là CONFLICT, ghi cả hai excerpt và chuyển reviewer. Nếu source chỉ nói “có thể”, synthesis cũng không được biến thành “đã chắc chắn”.

Google Cloud mô tả grounded answers dùng nguồn grounding và cung cấp cách kiểm mức answer candidate bám vào facts; điều quan trọng ở đây là claim phải được đối chiếu với tập facts đã chọn, không chỉ có một URL ở cuối đoạn. Google grounded answers và grounding check

Hình 3 — Evidence ledger làm lộ claim được support, claim mâu thuẫn và claim chưa đủ nguồn trước khi synthesis.

4. Synthesis, citation và human review

Citation là tham chiếu giúp người đọc mở lại source hỗ trợ claim. Groundedness là mức output bám vào evidence được chọn. Bản synthesis tốt không chỉ đặt bốn link ở cuối; nó nối từng claim quan trọng với citation phù hợp, ghi cutoff date và tách ba loại câu:

  • Fact: source nói trực tiếp, có excerpt và date.
  • Inference: người viết suy ra từ nhiều fact; phải dùng ngôn ngữ có điều kiện.
  • Unknown: chưa có evidence đủ, source conflict hoặc scope không cho phép; ghi rõ và không điền số giả.

Research agent có thể đề xuất đoạn draft theo claim bundle. Human review kiểm:

  1. Coverage: claim chính đã có evidence chưa?
  2. Provenance: citation có trỏ đúng đoạn support không?
  3. Freshness: source có nằm trước cutoff và đúng version không?
  4. Scope: câu kết có vượt request hoặc source không?
  5. Contradiction: nguồn trái chiều có được ghi nhận không?
  6. Language: fact và inference có bị viết cùng một mức chắc chắn không?

Review không phải bước trang trí. Nó là decision boundary: draft có thể được sửa, giữ ở NEEDS_REVIEW, hoặc loại. Nếu source chưa đủ, agent nên trả “chưa xác minh” thay vì thêm một đoạn nghe mượt.

Bảng kiểm claim nhỏ

Claim Evidence Citation Status Reviewer action
Policy A được công bố trước cutoff Excerpt từ primary document Link + ngày SUPPORTED Giữ trong draft
Hai report giải thích nguyên nhân khác nhau Hai excerpt mâu thuẫn Cả hai link CONFLICT Không kết luận, handoff
Tác động tới doanh nghiệp Chưa có nguồn trực tiếp Chưa có MISSING Viết UNKNOWN

NIST Generative AI Profile nhấn mạnh provenance, evaluation và human oversight; vì vậy ledger và reviewer phải nằm trong workflow. NIST Generative AI Profile

Hình 4 — Stop gate giữ claim ở fact/inference/unknown; thiếu citation, conflict hoặc injection thì chuyển người review.

5. Sai lầm, giới hạn và safety gate

Một research agent hay gặp các lỗi và rủi ro sau:

  • Link hallucination: URL trông hợp lệ nhưng không mở được hoặc không chứa claim.
  • Citation-washing: một citation được gắn vào cả đoạn dài dù chỉ support một câu.
  • Source drift: tài liệu đổi sau lần chạy nhưng ledger không ghi version/date.
  • Over-retrieval: càng nhiều result càng tưởng chắc chắn, trong khi claim chính vẫn không có evidence.
  • Confirmation bias: query chỉ tìm thứ hợp với giả thuyết ban đầu.
  • Prompt injection trong source: PDF/web page chứa instruction “bỏ qua rule” và agent làm theo thay vì coi đó là data.
  • False precision: viết số hoặc nguyên nhân cụ thể dù source chỉ mô tả xu hướng chung.

Safety gate cho case này nên giữ agent ở read-only. Tool search chỉ được vào domain/collection cho phép; tool read trả content và metadata, không thực thi instruction trong content. Không gửi email, sửa record, mua data hoặc tải PII. Query, source, excerpt, state và reviewer decision được ghi ở mức tối thiểu cần thiết.

Human review là người đọc và quyết định trước khi dùng output. Handoff khi có CONFLICT, MISSING, source ngoài cutoff, evidence thấp, claim nhạy cảm hoặc request vượt scope. Đừng dùng confidence như con dấu đúng; confidence chỉ là tín hiệu có điều kiện dựa trên evidence và giới hạn.

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes miễn phí. Dùng một research question giả, bốn source fixture/public và timer 15 phút. Chia thời gian: 3 phút viết query plan, 5 phút ghi ledger, 4 phút kiểm citation, 3 phút viết review decision. Không dùng customer data, private document, credential, tiền thật hay tài liệu không được phép.

Mẫu đối chiếu đã điền

Ô Mẫu Decision
Query plan 3 sub-question: policy, mô tả thay đổi, gap Chạy từng nhóm
Source tier Primary official trước; secondary chỉ thêm context Không cite snippet
Claim “Policy A được công bố trước cutoff” SUPPORTED
Evidence Excerpt + publisher + date + version Lưu provenance
Conflict Hai report nêu nguyên nhân khác nhau CONFLICT → reviewer
Missing Chưa có nguồn cho tác động cụ thể UNKNOWN/NEEDS_REVIEW
Source instruction Một PDF yêu cầu bỏ qua safety rule BLOCK instruction, giữ PDF là data
Draft Fact trước, inference có điều kiện Chưa release

Kết quả mong đợi là một ledger nhỏ có thể mở lại, không phải bài viết dài. Nếu bạn không chỉ ra được claim lấy từ đoạn nào, hãy hạ trạng thái xuống NEEDS_REVIEW. Nếu query plan không biết tìm gì tiếp, đó là gap của question chứ không phải lý do để agent tự bịa.

7. Tổng kết: evidence trước, câu chữ sau

a. Năm ý chính

  • Research agent hỗ trợ chia câu hỏi, tìm/đọc nguồn và ghép evidence; không thay researcher hay tự xuất bản.
  • Query plan và source policy giới hạn agent tìm gì, theo cutoff nào và nguồn nào được cite.
  • Evidence ledger nối claim với excerpt, source, date, status và provenance để reviewer kiểm lại.
  • Synthesis phải tách fact, inference và unknown; citation cần support đúng claim, không citation-wash.
  • Conflict, missing evidence, prompt injection hoặc scope vượt giới hạn phải dẫn tới NEEDS_REVIEW, block hoặc handoff.

b. Câu hỏi tự kiểm tra

  • Vì sao query plan tốt hơn một query dài cho research case?
  • Evidence ledger cần những trường nào?
  • Khi hai source mâu thuẫn, agent nên làm gì?
  • Citation khác gì với groundedness?

c. Gợi ý đáp án

Xem gợi ý câu 1

Query plan tách sub-question, thứ tự và gap nên dễ kiểm hơn; query dài dễ over-retrieval và khó biết đang support ý nào. Xem lại mục 2.

Xem gợi ý câu 2

Claim, source, excerpt, date, status, citation/provenance và confidence; thêm query hoặc version khi cần trace. Xem lại mục 3.

Xem gợi ý câu 3

Đánh dấu CONFLICT, giữ cả evidence và chuyển reviewer; không chọn nguồn thuận tai rồi viết như đã chắc chắn. Xem lại mục 3 và mục 4.

Xem gợi ý câu 4

Citation là tham chiếu để mở lại nguồn; groundedness là mức output bám vào evidence. Có link chưa chắc đã support đúng claim. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Research agent Runtime hỗ trợ chia câu hỏi, tìm/đọc nguồn và ghép evidence trong scope.
Query plan Danh sách sub-question và thứ tự tìm.
Source tier Nhóm nguồn theo authority, proximity và mục đích.
Evidence ledger Bảng nối claim, source, excerpt, date, status và confidence.
Provenance Dấu vết nguồn gốc của claim hoặc đoạn thông tin.
Citation Tham chiếu giúp mở lại source hỗ trợ claim.
Groundedness Mức output bám vào evidence đã chọn.
Confidence Mức tin cậy có điều kiện từ evidence và giới hạn.
Cutoff date Mốc thời gian không lấy dữ kiện sau đó.
Human review Người đọc và quyết định trước khi dùng output.

e. Nguồn tham khảo

Bài trước là Integrated AI System Design Framework #12. Bài tiếp theo là Case Study: Content Production Agent #14.

Lưu ý giáo dục: Một bản research tốt phải cho người khác lần lại evidence và thấy phần chưa biết. Hãy giữ agent read-only, dùng nguồn được phép, ghi cutoff date và để human review quyết định trước khi dùng claim.