AI搜索与研究助手：查询改写、网页检索、引用、事实校验和报告生成
摘要
AI 搜索与研究助手的价值不在于把搜索结果重新写成一段顺滑文字，而在于把模糊问题转化为可检索、可阅读、可引用、可核验的研究过程。本文围绕查询改写、网页检索、内容抽取、证据管理、事实校验和报告生成展开，强调研究助手必须能区分来源质量、时间敏感性、断言粒度和证据覆盖。一个可靠的研究助手不应假装知道所有答案；当证据不足、来源冲突或时间信息不确定时，它应把不确定性写入结论结构。
关键词
AI 搜索；研究助手；查询改写；网页检索；引用；事实校验；报告生成；证据管理
研究问题与方法
本文研究的问题是：搜索增强的模型怎样避免从“联网回答”滑向“带链接的幻觉”。方法上采用证据优先的研究流程，把用户问题拆成可验证断言，分别建立检索式、来源筛选、阅读摘要、事实核验和引用映射，再由模型生成报告。评价重点不在文章是否完整，而在结论是否被足够来源支撑。
图中回路说明，研究助手不是一次搜索后直接生成，而是在证据不足时返回查询阶段。事实校验可以用下面的表作为最低验收框架。
| 断言类型 | 需要的证据 | 不合格表现 |
|---|---|---|
| 定义性断言 | 官方文档、论文或标准文本 | 只引用二手解释 |
| 时间敏感断言 | 带日期的当前来源和发布上下文 | 混用旧页面和新结论 |
| 对比性断言 | 同口径指标和可复查样本 | 把不同测试条件并列比较 |
| 归因性断言 | 原始公告、提交记录或直接访谈 | 用转述来源替代原始来源 |
写作日期：2026-05-22
引言：导读
AI 搜索与研究助手不是把搜索引擎结果贴进对话框，也不是让模型凭印象回答一个问题。真正可用的研究助手要像一名有方法的研究员：先理解问题，判断哪些信息需要最新资料，改写查询，分批检索网页，打开关键来源，抽取证据，比较不同来源之间的矛盾，给结论加引用，再把不确定性、限制条件和下一步写清楚。它的能力不只来自大语言模型，也来自信息检索、RAG、长上下文、引用管理、事实校验、缓存和评测。
中文学习者常把“AI 搜索”理解成“模型联网”。工程上更准确的说法是：模型获得了检索工具、网页读取工具、文件检索工具和报告生成流程。搜索工具给它实时网页，文件检索给它私有资料，长上下文给它一次性阅读大材料的能力，RAG 给它从大规模资料库里取证据的能力，引用系统让读者追溯来源，事实校验让结论不完全依赖模型自信。缺少其中任意一环，研究助手都可能变成看起来很像研究、实际不可核验的摘要生成器。
这篇教程从系统设计角度拆解 AI 搜索与研究助手。重点不是某个产品界面，而是可迁移的工程方法：什么时候查询改写，什么时候直接搜索，如何处理网页检索结果，如何构造引用，如何做事实校验，如何生成一份可读报告，如何在长上下文和 RAG 之间取舍，如何控制上下文成本，如何用缓存降低延迟，如何用评测发现引用不准和事实不稳。
AI 搜索与研究助手解决什么问题
普通聊天模型擅长解释通用概念、改写文字、总结已提供材料，但它天然不等于搜索系统。模型训练语料有时间边界，无法保证知道今天的价格、最新政策、产品版本、赛事结果、论文进展和公司公告。即使模型知道某个事实，也很难把来源、发布日期和出处位置交给读者核验。AI 搜索与研究助手的目标，就是把模型的语言理解和搜索系统的外部证据结合起来。
可以把它处理的问题分成四类。第一类是最新信息，例如“某模型今天支持哪些上下文长度”“某政策最近有没有变动”“某产品最新版价格是多少”。这类问题必须访问实时网页或官方文档。第二类是分散信息，例如“比较几个向量数据库的过滤能力”“整理某个行业最近三个月投融资事件”。这类问题需要多次检索和来源合并。第三类是证据型问题，例如“这个结论有什么资料支持”“某论文是否真的这么说”。这类问题要求引用到段落、页面或论文。第四类是研究型输出，例如竞品分析、技术调研、选型报告、事实核查报告和文献综述。这类输出需要结构化流程，而不是一次搜索后一段回答。
研究助手的难点不在“能不能搜到链接”，而在“能不能把链接变成可靠结论”。网页搜索返回的是候选来源，不是答案。搜索结果页可能有广告、旧页面、二次转载、标题党、摘要不完整和地区差异。模型如果只读搜索片段，容易把片段里的不完整信息扩大成结论；如果把大量网页全部塞进上下文，又会带来成本、噪声和位置偏差。生产级研究助手必须在检索、阅读、筛选、引用和校验之间建立明确流程。
核心流程：理解、改写、检索、阅读、合成、校验
一个稳健的 AI 搜索与研究助手可以拆成七步。第一步是问题理解，判断用户要事实、观点、教程、比较、清单还是报告。第二步是查询改写，把自然语言问题变成适合搜索引擎、站内搜索、向量检索或数据库过滤的查询。第三步是网页检索，按主题、时间、站点、语言和地区发起搜索。第四步是来源阅读，打开关键页面，抽取正文、标题、日期、作者、表格、代码和引用位置。第五步是证据组织，把来源按可信度、相关性、新鲜度和冲突关系排序。第六步是答案或报告生成，把证据转成结构化结论。第七步是事实校验，检查每个关键结论是否有来源支持，引用是否真的支撑对应句子。
这七步不是固定流水线。简单问题可能只需要一次搜索和一个来源。复杂研究可能需要多轮：先搜概念，再搜官方文档，再搜论文，再搜反例，再针对冲突点搜索。OpenAI 的 web search 文档把非推理式快速搜索和推理模型的 agentic search 区分开来，后者可以搜索、打开页面、在页面内查找并决定是否继续搜索。这个区分很重要：快速查事实适合单次检索，复杂研究需要模型主动规划检索路径。
在工程实现上，流程要显式保存中间产物。原始问题、改写后的查询、搜索结果、打开过的页面、抽取文本、使用的证据、被排除的来源、最终引用、校验结果，都应该能被记录。没有这些中间产物，用户看到的只是一个流畅回答，团队无法知道答案错在查询、检索、抽取、排序、合成还是引用。
查询改写：搜索质量从问题表达开始
用户问题常常不适合直接搜索。中文用户会问“这个现在还能用吗”“他们家新接口怎么收费”“长上下文是不是可以不用知识库了”。这些问题里有代词、省略、口语表达、隐含时间、隐含对象和模糊评价。搜索引擎更需要明确实体、时间、比较对象和资料类型。查询改写就是把用户意图转成更容易召回证据的形式。
查询改写至少有五种常见方式。第一种是实体补全，把“他们家”“这个模型”“那篇论文”还原成明确名称。第二种是时间约束，把“现在”“最新”“最近”转成日期范围、版本号或发布年份。第三种是术语扩展，把中文问题同时扩展成英文关键词，例如“查询改写”对应 query rewriting、query expansion、rewrite retrieve read。第四种是多角度拆分，把一个大问题拆成定义、官方能力、价格、限制、案例和评测。第五种是反向检索，主动搜索反例、限制和批评，避免只搜到营销资料。
学术上，Query2doc 用大语言模型生成伪文档来扩展查询，帮助 BM25 和密集检索召回更多相关文档。HyDE 先生成一个假想答案文档，再把它编码成向量去找真实文档，适合零样本密集检索。Rewrite-Retrieve-Read 把“先检索再阅读”改成“先改写再检索再阅读”，强调用户输入和检索所需知识之间存在表达差距。这些方法提醒我们：查询不是用户原话的机械复制，而是研究过程中的可优化对象。
生产系统里，查询改写不能无节制。改写过度会改变用户问题，尤其在法律、医疗、财务和政策场景中，少一个限制条件就可能得到错误结论。好的改写器应该保留原问题、显示关键约束、生成多条查询，并允许后续检索结果反向纠正。对复杂任务，可以同时使用精确查询和宽泛查询：精确查询找官方页面和具体术语，宽泛查询找背景、争议和替代表达。
还要区分网页搜索查询和私有知识库查询。网页搜索喜欢关键词、站点限定、时间词和资料类型；向量检索喜欢语义完整的自然语言；全文检索喜欢实体名、错误码、函数名和专有词；数据库检索喜欢结构化过滤。一个研究助手不应只生成一种查询，而应根据检索后端生成不同版本。例如同一个问题“Gemini 长上下文怎么收费”，网页搜索可以用 Gemini long context caching pricing，站内文档搜索可以用“context caching TTL cached tokens”，向量检索可以用“Gemini API 长上下文和缓存如何降低重复输入成本”。
网页检索：不只是搜索结果排名
网页检索的第一原则是来源分层。官方文档、论文、标准、法律法规、公司公告和产品价格页通常比博客摘要更靠前；技术博客和社区经验可以帮助理解限制和坑点；论坛和社交平台适合发现争议，但不能直接当权威事实。研究助手应该把来源类型记录下来，报告中也要区分“官方文档说明”“论文实验发现”“社区实践反馈”和“媒体报道”。
第二原则是时间敏感。模型能力、API 参数、价格、限额、法律政策和产品支持列表都可能变化。问题里出现“最新”“现在”“今天”“今年”“还能不能用”时，系统要优先检索近期官方来源，并在答案里写清日期。对稳定概念，例如 RAG 原始论文、Lost in the Middle 现象、查询扩展基本思想，可以引用经典论文；对供应商能力，例如 Web Search、File Search、Prompt Caching、Gemini long context、Claude context window，则要用当前官方文档。
第三原则是多查询而不是单查询。复杂问题往往需要从不同方向验证。比如“AI 搜索助手如何做引用”可以分别搜索 OpenAI web search citations、Anthropic web search citations、Google grounding citations、generative search verifiability、citation precision recall。多查询能降低单个搜索词带来的偏差，也能让模型发现不同厂商对引用结构的共同设计：URL、标题、位置、引用片段和可点击展示。
第四原则是打开页面。搜索结果摘要只是入口，不是证据。Perplexity Search API 文档区分了返回结构化搜索结果的 Search API 和带引用生成回答的 Sonar；Tavily 提供 search、extract、crawl、research；Exa 支持搜索同时返回 highlights 和更深的结构化搜索。这些工具能力背后的共同点是：研究助手不能停留在标题和 snippet，要尽量读取正文、抽取段落、保留元数据，并判断页面是否真的包含所需证据。
第五原则是控制检索预算。研究任务不是搜越多越好。每次搜索、打开页面、抽取正文和放入上下文都会增加成本和延迟。可以给任务设置预算：快速回答最多三次搜索、打开三到五个页面；标准调研十到二十个来源；深度报告再增加反向搜索和交叉验证。预算不是省事，而是迫使系统把查询质量、来源筛选和证据密度做好。
网页读取与内容抽取
网页读取要处理大量噪声。页面里有导航、页脚、广告、相关推荐、评论区、脚本动态内容、重复标题和折叠内容。直接把 HTML 全部交给模型，会浪费上下文并引入无关信息。内容抽取层应该尽量保留正文、标题层级、发布日期、更新时间、作者、表格、代码块和链接关系，同时去掉模板噪声。
不同资料类型要不同处理。官方文档页面通常需要保留标题层级和代码示例，因为参数说明常藏在表格或示例旁边。论文页面要保留标题、作者、摘要、年份、会议、实验结论和限制。新闻页面要保留发布日期和原始消息来源。产品价格页面要保留币种、地区、套餐和生效时间。论坛帖子要区分主帖和回复，不要把某个用户的猜测当成官方结论。
网页抽取还要保存可追溯位置。最简单的位置是 URL 和标题；更好的位置包括锚点、段落编号、表格行、代码行和页面内字符区间。OpenAI web search 文档提到 url_citation 包含 URL、标题和引用在输出文本中的位置；Google Gemini grounding 文档提到响应中包含搜索查询、网页结果和 citations metadata；Anthropic web search 文档也强调 web search 会自动带来源引用。这些设计都说明：引用不是报告末尾的装饰，而是系统输出结构的一部分。
对于需要报告生成的任务，建议把抽取结果转成“证据卡片”。一张证据卡片包含来源标题、URL、来源类型、发布日期、抓取日期、核心摘录、支持的论点、可能的限制和可信度。模型生成报告时，不直接面对几十页网页全文，而是先使用证据卡片形成大纲，再按需要回看原文。这样既能降低上下文成本，也能提高引用的可控性。
RAG、长上下文和网页搜索的关系
网页搜索解决“从开放互联网找资料”的问题，RAG 解决“从已知资料库找证据”的问题，长上下文解决“一次性阅读较大材料”的问题。三者不是互斥关系。一个研究助手经常同时使用它们：先用网页搜索找到官方文档和论文，再用网页抽取形成临时资料库，然后用 RAG 在资料库里召回相关片段，最后用长上下文读取少数关键页面或报告。
RAG 的优势是可控。它可以建立资料索引、元数据过滤、权限控制、版本管理、去重、重排和引用位置。OpenAI File Search 文档把文件放入 vector store 后进行语义和关键词搜索，说明主流托管方案也不是只做向量相似度，而是把文件、切分、embedding、索引和工具调用结合起来。自建 RAG 还可以结合 BM25、向量检索、rerank、知识图谱和结构化过滤。
长上下文的优势是减少检索丢失。Google Gemini 长上下文文档强调部分模型支持百万级上下文，并适合长文档、代码库、视频、音频和多模态资料。对于一份合同、一篇长论文、一个小型代码仓库或十几份相关文档，把完整材料放进长上下文，确实能避免切分和召回错误。研究助手在做“精读”时，长上下文非常有用。
但长上下文不自动等于可靠研究。Lost in the Middle 论文发现，相关信息在长输入中间位置时，模型表现可能明显下降。长上下文还会带来输入 token 成本、延迟和噪声问题。研究助手如果把几十个网页全部塞入上下文，模型可能被旧资料、重复资料和低质量来源干扰。RAG 的价值不是因为上下文窗口不够大才存在，而是因为它提供了筛选、排序、权限、解释和可维护性。
最实用的组合是“检索先缩小范围，长上下文再精读”。先用搜索和 RAG 找到最有价值的十几个片段，再把少数高质量来源完整放入长上下文，让模型做跨段落推理、比较和报告写作。这样既不完全依赖召回片段，也不把所有网页无差别塞进去。
上下文成本与缓存
AI 搜索与研究助手的成本主要来自四部分：搜索或网页工具调用成本、网页抽取和存储成本、输入 token 成本、输出 token 成本。长上下文会显著增加输入 token。RAG 会增加索引和检索成本，但可以减少每次进入模型的文本量。选择架构时，不能只比较“是否能放下”，还要比较“每次查询要为多少重复资料付费”。
缓存是研究助手的关键优化。常见缓存有四类。第一类是搜索结果缓存，同一个查询在短时间内可以复用，但要注意新闻和价格类问题的过期时间。第二类是网页正文缓存，官方文档和论文可缓存更久，新闻和动态页面缓存更短。第三类是 embedding 缓存，同一页面切分后的向量不应重复计算。第四类是模型提示缓存，长系统提示、工具定义、固定资料和长文档可以利用供应商的 prompt caching 或 context caching。
OpenAI prompt caching 文档说明，重复前缀可以降低延迟和输入成本；Anthropic prompt caching 文档强调缓存命中要求前缀内容完全一致，并有默认五分钟和更长缓存选项；Gemini context caching 文档说明可以把内容先缓存，再在后续请求中引用缓存内容。对研究助手来说，这意味着提示结构很重要：稳定指令、报告格式、评价标准和固定背景应放在前面，用户问题、当前检索结果和动态证据放在后面。否则每次动态内容插入前缀，缓存命中率会下降。
缓存不能牺牲数据新鲜度。价格、API 支持模型、政策、赛事、漏洞通报和金融数据都要设置短 TTL 或强制刷新。报告里如果使用了缓存资料，应记录抓取日期。对用户来说，“截至 2026-05-22 检索”比“最新资料显示”更可靠。对系统来说，缓存命中、缓存时间、来源更新时间和重新验证策略都要进入审计记录。
引用：让结论能被读者复核
引用系统的目标不是堆链接，而是让每个重要结论可复核。一个好的引用至少回答四个问题：这个结论来自哪里，来源是否可信，来源发布时间是什么，引用位置是否真的支撑这句话。只有文末给十几个链接，读者仍然不知道哪条链接支撑哪一句结论。
引用粒度要匹配风险。低风险教程可以在段落后放来源链接；技术参数、价格、法律政策和安全建议最好用句级引用；论文结论要标明论文题目和结论范围；表格数据要引用具体表格或页面位置。复杂报告中，可以给每个小节一个“证据表”，列出关键结论、来源、日期和置信度。
引用还要处理冲突。多个来源可能说法不同，原因可能是时间不同、地区不同、版本不同、统计口径不同或二次转载错误。研究助手不能只选择支持自己结论的来源，而要把冲突写出来。例如某厂商文档页面和博客文章对模型支持列表不一致，优先级通常是最新官方文档高于旧博客；如果官方文档内部页面冲突，就应标注“来源之间存在不一致”，并建议以产品控制台或接口返回为准。
引用准确性本身需要评测。Evaluating Verifiability in Generative Search Engines 论文指出，生成式搜索引擎看起来流畅，但并非所有句子都被引用完全支持，也并非所有引用都准确支撑对应句子。这给工程系统一个重要提醒：有引用不等于可验证。引用必须检查“句子是否被来源支持”和“链接是否指向正确来源”两个方向。
事实校验：把长报告拆成可验证事实
事实校验不能只问模型“你确定吗”。模型可以自信地确认错误结论。更可靠的方式是把生成内容拆成原子事实，再逐条找证据。FActScore 的思想就是把长文本拆成一系列 atomic facts，并计算有可靠知识源支持的比例。研究助手可以借鉴这个思路：报告生成后，把关键事实抽取出来，检查每条事实是否有来源、是否过期、是否与其他来源冲突。
事实校验可以分为五层。第一层是来源存在性，判断引用链接能否打开，标题和页面是否匹配。第二层是来源相关性，判断引用内容是否在谈同一个实体、版本和时间。第三层是句子支持度，判断来源是否直接支持对应结论。第四层是交叉验证，至少用两个独立来源确认高风险事实。第五层是反证搜索，主动检索“是否有相反证据”“是否已经废弃”“是否有人指出限制”。
SelfCheckGPT 这类自一致性方法也有价值。它通过多次采样观察事实是否稳定，用来发现模型可能编造的内容。它不能替代外部证据，因为多个回答一致也可能一起错；但在没有足够资料或生成长文时，它能帮助标记低置信段落。生产系统里，可以把自一致性作为风险信号，把外部来源支持作为最终依据。
事实校验还要关注数字和比较。模型最容易在比例、价格、日期、版本号、排名和增长率上出错。研究报告中的数字应尽量来自原始表格或官方页面，不要从二次文章转抄。比较结论要写清口径，例如“更便宜”是按输入 token、输出 token、缓存 token、月费还是总拥有成本比较；“更准确”是按哪个数据集、哪组任务、哪种评测方法比较。
报告生成：从证据到结构化输出
研究报告不是把搜索结果摘要拼起来。它需要明确读者、问题、范围、结论和证据。一个可读报告通常包含：摘要、背景、核心结论、证据分析、对比表、风险和限制、建议路径、参考资料。教程型报告要解释概念和操作步骤；决策型报告要给选项、权衡和推荐；事实核查报告要给结论等级和证据链。
报告生成前，建议先生成大纲，再映射证据。大纲不是固定模板，而是由问题决定。比如“AI 搜索助手怎么设计”适合按流程讲；“长上下文能不能替代 RAG”适合按争议点讲；“某产品是否适合企业使用”适合按能力、成本、安全、生态和风险讲。每个小节都要有对应证据卡片，不能先写观点再临时找链接。
报告中的不确定性要写清楚。研究助手应该区分“确定事实”“基于当前来源的判断”“推测”“没有找到证据”。例如“OpenAI 文档说明 web search 可返回带 URL citation 的注解”是确定事实；“复杂调研更适合 agentic search”是基于工具设计和实践经验的判断；“某厂商未来会支持某能力”如果没有公告，就不能写成事实。
报告还要避免信息重复。很多 AI 报告会在摘要、背景、分析、结论里反复说同一句话。生产级输出应做到层级清晰：摘要只写最重要结论，正文展开证据，表格负责比较，清单负责执行。引用也不要重复堆叠，同一个来源在不同位置出现时，要确保每次引用支撑的句子不同。
一个实操架构
可以把 AI 搜索与研究助手设计成六个模块。第一是任务规划器，判断任务类型、资料需求、时间敏感度和输出形态。第二是查询生成器，生成多条搜索查询、站点限定和反证查询。第三是检索执行器，调用网页搜索、站内搜索、文件检索、向量检索和数据库查询。第四是证据处理器，读取页面、抽取正文、去重、打分、形成证据卡片。第五是生成器，根据证据和大纲生成答案或报告。第六是校验器，做引用检查、事实拆解、冲突检测和输出修订。
任务规划器要先问“是否需要联网”。稳定概念、用户已提供资料、内部知识库可回答的问题，不必每次搜索互联网。最新事实、价格、法律、产品支持、论文进展、新闻和市场数据必须检索。这样既能降低成本，也能避免模型把旧知识当新事实。
查询生成器要输出结构化对象，而不是一段自然语言。对象可以包含原问题、改写查询、查询意图、语言、时间范围、优先站点、排除站点、资料类型和预期证据。检索执行器根据对象选择工具。比如官方文档优先用站点搜索，学术问题优先搜 arXiv、ACL Anthology、OpenReview，产品能力优先搜官方 docs，争议问题再搜社区和博客。
证据处理器要有排序规则。可信度、相关性、新鲜度、独立性和可引用性都要参与排序。官方文档可信但可能偏营销，论文严谨但可能不是最新产品状态，社区经验真实但口径不统一。报告中最好让读者知道不同来源承担什么角色：官方文档确认能力，论文提供评测方法，社区经验提示风险。
校验器要在生成之后运行，而不是只在生成之前筛材料。因为生成阶段可能把多个证据混合出一个新句子，也可能遗漏限制条件。校验器把报告拆成关键事实，要求每条事实绑定证据；没有证据的句子要改成解释、推断或删除。对高风险输出，可以要求人工确认后发布。
典型案例：调研一个新模型的联网能力
假设用户问：“某个新模型现在能不能做网页研究，能不能给引用，适合做竞品调研吗？”研究助手不应直接回答“可以”。它要先拆分问题：模型是否有 web search 工具，是否支持打开页面，是否返回引用注解，是否支持多轮搜索，是否有地区或语言限制，费用如何，引用是否需要在 UI 中展示，是否适合长报告。
第一轮查询可以搜官方模型文档、web search 文档、API reference 和 pricing。第二轮查询搜 citations、grounding metadata、search result content blocks。第三轮查询搜评测和用户实践，关注引用准确性、延迟和失败案例。第四轮查询搜替代工具，例如 Tavily、Exa、Perplexity Search API，用来判断是否应使用模型内置搜索还是外部搜索 API。
读取来源后，证据卡片会分成几类：官方能力说明、引用结构说明、搜索 API 能力、长上下文或缓存说明、独立评测或论文。报告生成时，可以先给结论：“适合做有来源的初步竞品调研，但高风险报告需要来源复核和反证搜索。”然后说明适用场景、限制、成本和架构建议。最后列出引用，标注哪些来源支持工具能力，哪些来源支持引用风险，哪些来源支持缓存和成本判断。
这个案例的关键是不要把“能联网”误写成“能保证事实正确”。联网只解决资料入口，事实正确还需要来源筛选、引用准确、冲突处理和校验流程。竞品调研尤其容易受官网营销、旧文章和二次转载影响，必须保留检索日期和来源等级。
评测：让研究质量可改进
AI 搜索与研究助手的评测至少包括六组指标。第一是检索召回，正确来源是否被找到。第二是检索精度，进入上下文的来源是否相关。第三是引用准确，引用是否支撑对应句子。第四是事实忠实，回答是否只使用证据支持的结论。第五是报告可读性，结构是否清晰、重复是否少、建议是否可执行。第六是成本和延迟，搜索次数、打开页面数、输入 token、缓存命中率和总耗时是否可接受。
RAGAS 提供了 context precision、context recall、faithfulness、answer relevancy 等指标，可以作为知识库和检索增强回答的评测参考。对网页研究助手，还需要补充 citation precision 和 citation recall。前者看引用是否真的支撑句子，后者看重要句子是否都有引用。只看答案相似度不够，因为研究助手的核心价值是可验证。
评测集要来自真实问题。可以收集用户常问的最新事实、产品比较、论文解释、教程需求和决策问题。每个问题要标注理想来源，而不是只标注理想答案。比如“长上下文能替代 RAG 吗”不应只给一个参考答案，还要标注 RAG 原论文、Lost in the Middle、长上下文官方文档、长上下文与 RAG 比较论文、prompt caching 文档和 RAG 评测资料。这样才能评估系统是否找到了关键证据。
评测还要覆盖失败样本。故意加入模糊代词、过期页面、同名实体、地区差异、价格变动、论文和博客说法冲突、搜索结果被 SEO 污染等问题。研究助手如果只在简单问题上表现好，上线后很快会在真实研究里暴露问题。
常见误区
第一个误区是把搜索结果数量当质量。十个低质量来源不如两个权威来源。研究助手的目标是高证据密度，而不是链接数量。
第二个误区是只用模型改写查询，不检查改写是否改变问题。查询改写应保留约束，尤其是时间、地区、版本、对象和否定条件。
第三个误区是有引用就放心。引用可能不准确，可能只支持相邻主题，可能来自旧页面。引用要做句子级支持检查。
第四个误区是长上下文替代检索。长上下文适合精读少量高价值资料，不适合无筛选地吞下整个互联网。资料筛选仍然重要。
第五个误区是忽视缓存新鲜度。缓存能省钱，但过期缓存会让研究助手给出旧价格、旧政策和旧模型列表。
第六个误区是报告只写结论，不写限制。研究报告应该说明资料范围、检索日期、证据缺口和不确定性。
第七个误区是把社区经验当官方事实。社区帖子能提示风险，但参数、价格、能力和合规口径应以官方来源为准。
第八个误区是没有评测就上线。研究助手看起来聪明，不代表来源、引用和事实都可靠。上线前至少要有一组真实问题和人工标注来源。
落地检查清单
问题理解：是否判断了任务类型、时间敏感度、输出形态和风险等级。
查询改写：是否保留原问题，是否生成多条查询，是否覆盖同义词、英文术语、时间范围和反证方向。
网页检索：是否优先官方文档、论文和原始来源，是否打开关键页面，是否记录检索日期。
证据抽取：是否保存标题、URL、日期、正文摘录、来源类型和引用位置，是否去掉导航和广告噪声。
RAG 与长上下文：是否先用检索缩小范围，再用长上下文精读关键来源，是否避免把无关网页全部放入上下文。
上下文成本：是否记录搜索次数、打开页面数、输入 token、输出 token、缓存命中和总耗时。
缓存：是否区分搜索缓存、网页缓存、embedding 缓存和提示缓存，是否给动态资料设置短过期时间。
引用：是否让关键结论绑定来源，是否区分直接证据和背景资料，是否处理冲突来源。
事实校验：是否把报告拆成关键事实，是否逐条检查来源支持，是否标出无证据和低置信结论。
报告生成：是否有摘要、证据分析、建议、限制和参考资料，是否避免重复段落和空泛套话。
评测：是否有真实问题集、理想来源、引用准确评测、忠实度评测和成本延迟记录。
多轮研究：让系统会追问、会转向、会收束
真正有用的研究助手不能只执行一次搜索。很多问题一开始并不清楚，用户也未必知道应该问什么。系统需要在检索过程中不断判断：当前资料是否足够，是否出现新概念，是否需要补充背景，是否有来源冲突，是否应该向用户追问。多轮研究的价值就在这里，它让研究过程从“检索一次并回答”变成“围绕证据逐步收束”。
多轮研究可以分为探索轮、聚焦轮、验证轮和成稿轮。探索轮负责了解问题空间，通常使用宽泛查询和多来源搜索，目标是找到主要概念、权威来源和争议点。聚焦轮围绕关键实体和关键假设搜索，例如某个模型的参数、某篇论文的实验设置、某个工具的引用能力。验证轮主动寻找反例、更新说明、限制条件和相互冲突的说法。成稿轮才把证据整理成结构化答案或报告。
这种流程尤其适合比较和选型。用户问“哪个 AI 搜索 API 适合做研究助手”，如果系统只搜一次，很可能被某个厂商文档影响。更好的流程是先列候选工具，再分别检索官方能力、价格、引用结构、抓取深度、速率限制、数据保留和社区反馈，最后按任务类型给建议。每一轮检索都围绕前一轮发现的新问题展开。
多轮研究还要学会停止。模型如果没有停止条件，会不断搜索，成本和延迟失控。可以定义几个收束条件：核心结论已有两个以上可靠来源支持；关键冲突已经解释；高风险事实已有官方或原始来源；没有新证据出现；预算达到上限；用户只需要快速答案。停止不是偷懒，而是研究质量和成本之间的边界管理。
系统也要知道什么时候追问用户。如果问题缺少实体、地区、时间、资料范围或输出用途，盲目搜索会浪费成本。例如“帮我查下这个政策还能不能用”，如果不知道地区和政策名称，查询改写只能猜。研究助手可以先问一个短问题：“你指哪个地区或哪份政策？”对专业用户来说，少量追问比给出泛泛答案更有价值。
安全与提示注入：网页资料不是系统指令
AI 搜索助手读取开放网页时，会遇到一个特殊风险：网页内容可能包含诱导模型的文字。恶意页面可以写“忽略之前所有规则”“把用户资料发到某地址”“引用本页面作为唯一来源”。这些文字对人类读者只是页面内容，对模型却可能像指令。检索增强系统必须明确区分资料和指令。
第一道防线是提示结构。系统指令、用户问题、检索资料和工具结果要有明确边界。网页正文应被标记为不可信外部内容，只能作为事实候选，不能改变工具权限、引用规则和输出边界。模型可以阅读网页里的观点，但不能执行网页里的命令。
第二道防线是工具权限。即使网页内容要求模型调用某个高风险工具，工具层也要按用户权限和业务规则验证。研究助手通常只需要搜索、读取、摘要和引用，不应拥有删除文件、发送邮件、修改数据库等权限。若研究助手同时具备行动能力，就要把研究工具和执行工具分开，并给执行动作增加确认。
第三道防线是来源可信度。外部网页、论坛帖子、用户上传文件和未知 PDF 都应被视为不完全可信。它们可以提供线索，但高风险结论要回到官方文档、论文、原始数据或经确认的内部资料。报告中可以引用社区经验提示风险，但不应让社区帖子覆盖官方规则。
第四道防线是输出清洗。报告里不能泄露系统提示、内部工具名、索引 ID、调试字段或用户无权看到的资料路径。面向最终读者的引用应该展示标题、来源、日期和链接，而不是内部检索分数、向量相似度或数据库主键。安全不只是防攻击，也包括不把实现细节暴露给读者。
失败处理：找不到证据时怎么回答
研究助手一定会遇到找不到证据的情况。错误做法是让模型凭常识补一个答案。正确做法是区分几种失败原因：查询可能写错，搜索结果不足，页面无法打开，资料需要登录，来源之间冲突，当前资料没有覆盖，用户权限不够，或者问题本身不可验证。不同失败原因，对用户的回答应不同。
如果查询可能不准，系统可以展示已搜索的关键词，并建议改用更具体的实体、时间或来源范围。如果页面无法打开，可以说明已找到标题但无法读取正文，并降低该来源权重。如果资料需要登录，不应伪造内容，只能提示需要授权来源。如果来源冲突，应列出冲突点和可能原因，而不是强行给单一结论。
找不到证据时，回答要有边界。例如“未在当前检索到的官方资料中找到明确说明”比“没有这个功能”更准确。前者说明证据范围，后者是绝对断言。对研究报告来说，可以专门设置“证据缺口”小节，列出未能确认的事实、建议后续查看的来源和需要人工确认的点。
失败处理还要进入评测。很多系统只评测答对的问题，不评测找不到答案的情况。真实使用中，用户经常问资料库没有覆盖的问题。一个优秀研究助手应该会拒绝无证据结论，会提示资料不足，会给出下一步，而不是每个问题都生成一篇完整答案。可拒答、可降级、可解释的失败，比自信错误更接近生产级标准。
面向中文场景的特殊注意点
中文 AI 搜索和研究助手还要处理语言转换、地区差异和资料生态。很多前沿论文、模型文档和 API 资料首先以英文发布，中文资料可能滞后或来自二次解读。系统做查询改写时，应同时生成中文和英文关键词。中文问题“上下文缓存”可能要检索 context caching、prompt caching、cached tokens；“事实校验”可能要检索 factuality evaluation、fact verification、verifiability。
地区差异也很重要。价格、数据合规、产品可用性、模型访问和法规政策经常按地区变化。中文用户问“能不能用”“怎么收费”“是否合规”时，系统要识别地区语境，必要时追问或分别说明中国大陆、香港、新加坡、美国、欧盟等范围。不能把英文官网的全球说明直接当成本地可用性结论。
中文网页质量差异较大。技术内容常见翻译转载、洗稿、旧版本教程和缺少发布日期的问题。研究助手应优先使用原始来源，中文资料可以帮助解释概念和实践经验，但参数、价格和能力最好回到官方文档。对于中文社区经验，要特别关注发布时间，因为模型 API、SDK 和平台规则更新很快。
中文报告还要避免机器味。读者需要的是清楚判断和可执行路径，不是把英文术语堆在一起。第一次出现专业词可以写中文解释和英文原词，后续统一用一个名称。引用不要打断阅读，但关键结论必须能追溯。教程站内容应更系统，社区帖内容可以更有立场和经验感，但两者都不应牺牲证据质量。
参考资料
- OpenAI API 文档：Web search，https://platform.openai.com/docs/guides/tools-web-search
- OpenAI API 文档：File search，https://platform.openai.com/docs/guides/tools-file-search
- Google Gemini API 文档：Grounding with Google Search，https://ai.google.dev/gemini-api/docs/grounding
- Anthropic 文档：Web search tool，https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/web-search-tool
- Tavily 文档：Search、Extract、Crawl、Research API，https://docs.tavily.com/
- Exa 文档：Search API 与 highlights，https://docs.exa.ai/
- Perplexity 文档：Search API，https://docs.perplexity.ai/guides/search-guide
- Query Rewriting for Retrieval-Augmented Large Language Models，https://arxiv.org/abs/2305.14283
- Query2doc: Query Expansion with Large Language Models，https://arxiv.org/abs/2303.07678
- Precise Zero-Shot Dense Retrieval without Relevance Labels，https://arxiv.org/abs/2212.10496
- Evaluating Verifiability in Generative Search Engines，https://arxiv.org/abs/2304.09848
- FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation，https://arxiv.org/abs/2305.14251
- Ragas: Automated Evaluation of Retrieval Augmented Generation，https://arxiv.org/abs/2309.15217
- Google Gemini API 文档：Long context，https://ai.google.dev/gemini-api/docs/long-context
- Anthropic 文档：Prompt caching，https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching