Research agent: từ tóm tắt sang phản biện

Research agent: từ tóm tắt sang phản biện

Phần lớn research agent chỉ biết mô tả. Playbook 4 bước để agent biết đối chất dữ liệu với giả thuyết — như hội đồng xét xử thay vì thư ký tòa.

Tuần trước mình ngồi review một research agent mà team 4 người xây suốt hai sprint. Hỏi "Apple có đang undervalued không?", nó trả về ba đoạn văn mô tả P/E, revenue growth, rồi kết bằng câu "nhìn chung khá tích cực". Sếp hỏi lại: "Vậy mua hay không mua?" — im lặng. Agent biết kể, nhưng không biết phản biện.

Đây không phải lỗi model. Đây là lỗi thiết kế pipeline.

Mục tiêu: agent biết xét xử, không chỉ biết ghi biên bản

Phần lớn research agent ngoài kia hoạt động như thư ký — gom thông tin, tóm lại, trình bày. Nhưng người dùng thật (trader, product lead, tech lead đang evaluate vendor) cần một thứ khác: họ đưa ra một giả thuyết, và cần hệ thống kiểm chứng giả thuyết đó bằng dữ liệu.

Dịch sang tiếng người: thay vì hỏi "kể cho tôi nghe về X", workflow thật là "tôi nghĩ X đúng vì Y — dữ liệu có ủng hộ không?" Đó là sự khác biệt giữa một thư ký tòa ghi chép và một hội đồng xét xử thật sự cân nhắc chứng cứ hai phía.

Playbook này giúp bạn xây pipeline thứ hai — cái biết đối chất.

Checklist: 4 thành phần bắt buộc

Trước khi code dòng đầu tiên, kiểm tra xem kiến trúc có đủ bốn lớp:

Thiếu bất kỳ lớp nào, agent sẽ rơi về chế độ "tóm tắt".

Từng bước: xây evidence pipeline trong một buổi chiều

Bước 1 — Tách thesis thành checkable claims

Khi user nhập "NVIDIA đang overvalued vì AI hype sẽ xẹp", đừng ném nguyên câu vào prompt rồi bảo model "phân tích". Thay vào đó, dùng một bước structured output để tách thành:

{
  "ticker": "NVDA",
  "claims": [
    {"statement": "Giá hiện tại cao hơn fair value", "evidence_needed": "P/E vs industry, DCF range"},
    {"statement": "AI revenue growth sẽ giảm", "evidence_needed": "QoQ revenue trend, guidance"}
  ]
}

Mỗi claim trở thành một "đầu bài" riêng cho evidence fetcher. Nếu dùng MCP server (ví dụ EODHD cho financial data), mỗi claim map sang một hoặc hai tool call cụ thể.

Bước 2 — Fetch evidence có metadata

Đừng chỉ lấy raw data. Mỗi evidence object cần kèm:

{
  "claim_id": "price_overvalued",
  "data_source": "eodhd_fundamentals",
  "value": {"pe_ratio": 58.3, "industry_avg": 32.1},
  "freshness": "2026-05-01",
  "confidence": "high"  # dựa trên data completeness
}

freshness và confidence là hai field mà team hay bỏ qua — nhưng nếu thiếu, verdict synthesizer không có cơ sở để weigh evidence. Orchestration (điều phối luồng xử lý giữa các bước) ở đây là tuần tự: parser → fetcher → evaluator. Đừng chạy song song fetcher trước khi parser xong — sẽ fetch thừa data không liên quan.

Bước 3 — Signal evaluation: support, contradict, missing

Đây là bước nhiều team skip vì "model tự hiểu". Không. Bạn cần một prompt riêng (hoặc một function riêng) chỉ làm đúng một việc: nhận claim + evidence, trả về verdict cho từng cặp.

def evaluate_signal(claim, evidence):
    # Returns: "supports", "contradicts", or "insufficient"
    # Kèm reasoning ngắn (1-2 câu)

Giả sử team bạn 5 người đang xây internal research tool cho quỹ đầu tư nhỏ. Nếu bỏ bước này, output cuối sẽ là "có số liệu A, có số liệu B, kết luận tùy bạn" — không khác gì Google search.

Bước 4 — Verdict memo với guardrail

Synthesizer nhận toàn bộ signal đã evaluate, viết memo ngắn. Guardrail (rào chắn kiểm soát output) quan trọng nhất ở bước này:

Không có guardrail, model sẽ luôn tìm cách đưa ra kết luận nghe có vẻ tự tin — dù chứng cứ chưa đủ. Giống phiên tòa mà thẩm phán tuyên án khi mới nghe một bên.

Bẫy: ba sai lầm phổ biến

1. Ném tất cả vào một prompt duy nhất. Team ở Đà Nẵng mình biết từng nhồi cả thesis parsing, data fetching instruction, và evaluation criteria vào một system prompt 3000 token. Kết quả: model "sáng tạo" thêm data không tồn tại — hallucination (bịa thông tin nghe rất đúng) tăng rõ rệt so với khi tách pipeline.

2. Không validate freshness. Agent research mà dùng data cũ 6 tháng để đánh giá claim về quý hiện tại thì memo đó là giấy lộn. Luôn check timestamp của evidence trước khi đưa vào evaluator.

3. Sub-agent không có scope rõ. Nếu dùng kiến trúc multi-agent (ví dụ LangGraph với sub-agent delegation), mỗi sub-agent phải có tool set giới hạn. Sub-agent phụ trách fundamentals không cần access web search — cho nó search là mời nó hallucinate khi API trả về thiếu data.

Hành động tiếp: thử ngay với stack tối thiểu

Bạn không cần hạ tầng phức tạp để prototype pipeline này:

  1. LLM: Bất kỳ model hỗ trợ tool calling — Groq free tier với Llama 3.3, hoặc OpenAI, Anthropic đều được
  2. Data source: MCP server cho financial data, hoặc đơn giản hơn là một Python function gọi API bất kỳ
  3. Framework: LangGraph nếu cần state machine rõ ràng, hoặc viết tay bằng Python thuần nếu team nhỏ muốn kiểm soát hoàn toàn
  4. Memory: JSON file đơn giản cho long-term memory (bộ nhớ dài hạn qua nhiều phiên) — đừng over-engineer bước này lúc đầu

Một buổi chiều đủ để có prototype chạy được trong Jupyter notebook. Phần khó không phải code — phần khó là discipline giữ pipeline 4 bước thay vì nhồi tất cả vào một prompt.

Nói thẳng ra thì: agent research mạnh không phải nhờ model giỏi hơn, mà nhờ pipeline biết tách "thu thập" khỏi "phán xét". Đừng để thư ký kiêm luôn thẩm phán.

---

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

Nguồn tham khảo