AI for Research

Deep Research 是 agent loop，不是 RAG

背景与原理

普通 RAG 是一次性的：embed query → 召回 top-k → 塞进 context → 生成。它的天花板是「你第一次问对了关键词」。Deep Research 不同——它是一个多轮 agentic loop：plan → search → read → 基于读到的新信息再 search → … → synthesize。OpenAI 公开说 Deep Research 是用端到端 RL 在浏览 + 推理任务上训出来的，模型学会了 plan、backtrack、对实时信息做反应；Gemini Deep Research 的描述几乎一样——「像你一样浏览：搜索、发现线索、基于学到的东西开启新搜索」。关键区别在于query 是动态生成的：第一轮你不知道该搜什么，读完第一批结果才知道第二轮该问什么。这正是 RAG 做不到的——RAG 的 query 在召回那一刻就定死了。

代价是真实的：一份 Deep Research 报告通常跑 5–30 分钟、烧掉远超普通对话的 token。所以决策不是「能不能用」，而是「值不值」。

实战示例

选型清单——把任务对号入座，别一律上 Deep Research：

# 单次 search 就够（秒级）
- 事实查询：「X 的最新版本号 / 发布日期」
- 已知关键词、答案在单个页面

# RAG（你有私有语料库）
- 在固定文档集里问答（内部 wiki、合同、论文库）
- query 一次就能命中相关 chunk

# Deep Research（分钟级、值得等）
- 开放式、需要跨多源综合：「对比 A/B/C 三家方案的 X」
- 答案需要「读完一批才知道下一步搜什么」
- 输出价值高到能 justify 15× 成本 + 几十分钟

判据是「下一步搜什么取决于上一步读到什么」——满足才上 Deep Research，否则更便宜的方案准确率不输还快得多。

自建研究 harness：orchestrator + fan-out subagents

背景与原理

Anthropic 在《How we built our multi-agent research system》里给出了可抄的架构：一个 Lead Researcher（orchestrator）把问题拆成若干子方向，并行 spawn 多个 subagent，每个 subagent 在独立 context window 里搜一个子方向，最后把摘要回收给 lead 综合。他们报告这种结构在内部研究类评测上比单 agent 强 90%+，原因是把推理分散到多个独立上下文，绕开了单 agent 的 context 上限。但同一篇也给了冷水：multi-agent 大约消耗 15× 于普通 chat 的 token——只有当结果价值远超成本、且任务能并行拆分时才划算。这正好接上 Day 13 的「协调税」：研究恰是少数协调收益 > 协调成本的场景，因为子方向之间弱依赖（搜 A 公司和搜 B 公司互不阻塞）。

实战示例

最小研究 harness 的骨架——重点是 orchestrator 只发 query、不自己读，subagent 只读一个方向、context 隔离：

def research(question):
    # 1) ORCHESTRATOR：把问题拆成弱依赖子方向
    subqs = plan(question)        # LLM 输出 3-5 个正交子问题
    # 2) FAN-OUT：每个子方向一个隔离 context 的 subagent（可并行）
    findings = parallel_map(subagent, subqs)
    # 3) SYNTHESIZE：lead 只看摘要 + 引用，不碰原始网页
    return synthesize(question, findings)

def subagent(subq, max_iters=8):
    notes = []
    for _ in range(max_iters):
        q = next_query(subq, notes)      # 动态生成下一个 query
        hits = web_search(q)
        for h in rank_sources(hits)[:3]:   # 见 §3：先筛源
            notes.append(extract(fetch(h.url), keep_quote=True))
        if enough(subq, notes): break     # loop control，别无限搜
    return compress(notes)   # 压成 {claim, url, quote}，原文丢掉

四个关键：子问题正交（重叠 = 浪费并行）、context 隔离（subagent 的网页噪声不污染 lead）、每个 subagent 有 max_iters（防无限搜）、回收的是 {claim, url, quote} 不是原文（为 §4 的引用追溯留锚点）。

信息源筛选：搜到 ≠ 可信

背景与原理

web_search 返回的是按相关性排序，不是按可信度排序。SEO 农场、AI 生成的二手洗稿、过期内容会和一手权威源混在一起排进 top-k。如果 subagent 不加判断地 fetch 前几条，等于把噪声当事实喂给综合层——而 LLM 不会自动质疑来源权威性，它默认你给的都可信。所以筛源必须是 harness 层显式的一步，发生在 fetch 之前。可用的信号：一手 vs 二手（官方文档/原论文 > 博客转述 > 聚合站）、域名权威度（官方域、arXiv、知名机构 > 内容农场）、时效（对快变主题，旧页面要降权）、去重（多个站点抄同一篇稿，本质是单一来源，别当成「多源印证」）。这一步也是把 §4 的「跨源印证」做实的前提——你得先知道哪些是真正独立的源。

实战示例

一个轻量 source ranking，插在 search 和 fetch 之间：

def rank_sources(hits):
    AUTHORITY = {"arxiv.org":3, "*.gov":3, ".edu":2,
                 "official_docs":3, "content_farm":-2}
    def score(h):
        s = AUTHORITY.get(domain_class(h.url), 0)
        s += 2 if is_primary(h) else 0   # 一手来源加权
        s -= recency_penalty(h.date, topic)        # 快变主题旧页降权
        return s
    uniq = dedup_by_content(hits)   # 抄稿合并：别把转载当独立源
    return sorted(uniq, key=score, reverse=True)

更省事的版本：直接在 subagent 的 prompt 里写明「优先一手来源，遇到二手转述要回溯到原始出处，对单一来源的关键结论标注 [需印证]」——把筛源指令前置，比事后纠错便宜得多。

引用追溯与对抗式验证

背景与原理

承接 Day 11：引用、URL、日期、数字是 LLM 最容易编造的 token——而这些恰恰是研究报告的主体。一个读起来完美的综述，引用可能一半是模型「脑补」出来的——格式正确、链接 404、或链接真实但内容根本没说那句话。治理靠两件事。其一 grounded generation：综合层只允许引用 subagent 实际 fetch 回来的 {claim, url, quote}，不给模型「自由发挥引用」的口子。Anthropic 的 Citations API 把这做成原生能力——它把源文档切成句子，让 Claude 引用确实用到的原句，官方称比纯 prompt 方案更可靠（且不对引文 quote 收输出 token 费）。其二 对抗式验证：综合完成后，再跑一遍「逐条 claim → 回到 quote 核对 → 标注支撑强度」，这是 evaluator pattern 在研究场景的应用。

实战示例

一个 quote-grounded synthesis + 验证 prompt，直接拷：

# 综合阶段：禁止自由引用
你只能基于下面提供的 FINDINGS 写综述。每个结论后必须附 [url]。
若某结论在 FINDINGS 里找不到直接支撑句 → 写「证据不足」，不要补全。

FINDINGS = [{claim, url, quote}, ...]   # 来自 subagent，带原句

# 验证阶段（单独一轮，对抗式）：逐条核对
逐条检查上面综述里的每个带引用结论：
1. 这个结论是否被它引用的 quote 直接支撑？(yes/partial/no)
2. 该结论是否只有单一来源？是 → 标 [单源未印证]
3. 标 no 的结论 → 删除或降级为「有观点称…」
输出修订后的综述 + 一份 claim→证据强度对照表。

核心是把「生成」和「验证」拆成两轮、用不同视角。同一轮里让模型边写边自检几乎无效（它会顺着自己刚写的合理化）；独立一轮做对抗核对，才抓得住编造的引用。