联网检索与时效性
知识库解决的是"你自己的语料"，联网检索解决的是"外部的、会变的语料"。两者经常被当成同一件事的两种实现，然后做出来的系统两边都不讨好：知识库里塞了一堆抓来的网页，过期了没人管；或者所有问题都实时去搜，成本翻倍还拿到了一堆不可控的来源。
这篇文章讲清楚两件事：时效性不是一个全局开关，以及引用在联网场景里该怎么验。
1. 三种联网形态
厂商内置的联网能力。 模型供应商在 API 里直接提供搜索并附引用，接入成本最低，几乎不用改代码。代价是你被绑定在这家的模型阵容上，检索策略、来源白名单、freshness 粒度都由它决定，你只能接受或不用。
搜索 API。 自己调搜索接口，拿回结果再自己组装上下文。可控性最高——能限定域名、能设时间窗、能按查询类型改参数。代价是多一跳延迟和一份 API 账单。
自托管抓取。 自己爬、自己清洗、自己入向量库。只有规模足够大时才划算，而且越来越难：Cloudflare 从 2024 年 7 月起对新接入的域名默认拦截 AI 爬虫（存量客户可选开启），针对批量抓取的付费抓取（pay-per-crawl）目前还是可选服务——但方向已经明确，全量重爬的合规成本和价格每个季度都在涨。查询时按需抓几页真实用户能访问的页面，反而绕开了这个问题。
大多数团队的落点是内置 + 一个搜索 API，按时效需求路由：稳定的定义性问题走缓存或知识库，时效敏感的走搜索 API。
2. 时效性不是一个全局开关
这是最常见的设计错误。给整个系统配一个"最多接受一周内的内容"，然后所有查询都按它走，结果是两类问题同时出现：问今天的服务中断，召回了上周另一次不相关的事故；问某个标准库函数怎么用，却被塞了一堆当天的博客。
正确做法是按查询类型分 freshness window：
股价、库存、赛事比分 → 秒级，通常直接绕过缓存
新闻、公告、产品页 → 小时到天
协议、标准、百科定义 → 周到月，甚至不设窗口
分档的依据是"这类内容多久会变一次"，不是"我们希望数据多新"。分类可以是一个小模型，也可以是一组关键词加启发式规则——先有分档，再谈优化，比一开始就上复杂路由重要得多。
3. 注入内容的方式
三件事做对了， grounding 质量会提升一个档次；做错了，加再多来源也没用。
注入正文，不注入 URL。 模型在生成时不会去访问链接。给它一串 URL 不给正文，等于没给它任何依据。正确形式是"来源 URL + 该来源的正文片段"成对出现。
放在问题的紧前面。 检索到的上下文要紧贴用户问题，而不是放在系统指令之前。这样模型注意力要跨越的距离更短。注意这条和《提示缓存怎么才命中》里的排布要求是有张力的：缓存希望稳定内容在前，检索结果天然是变化的。解法是分层——系统指令与工具定义在前（可缓存），检索到的上下文紧贴问题在后（不可缓存），把缓存断点打在稳定段的末尾。
三到五条高相关的，好过十条低相关的。 无关文档进入上下文会主动拉低答案质量，因为模型会把错误信息也编进流畅的回答里。设一个相关性阈值，低于阈值的直接丢掉，而不是"来者不拒"。
4. 引用必须结构性校验
联网场景里引用比内部知识库更容易出问题，因为 URL 是模型可以编造的自由文本。
校验规则很简单但很有用：每一个被引用的 URL 必须出现在本次召回集合里。编造的 URL 会在这条规则上结构性失败，不需要任何语义判断。同样要校验时间戳——对时效敏感的断言，引用一个一周前抓的页面应当判为不合 freshness 要求。
两个值得分开统计的指标：
- 引用覆盖率：生成的回答里有多少条事实断言带引用。低于 80% 通常说明模型在用训练数据而不是检索内容
- 引用忠实度：被引用的那段到底支不支持它配的那条断言
这两个指标是互相独立的：答案对但引错来源是可能的，引了来源但来源不支持也是可能的。只测其中一个，会漏掉另一类错误。判据与权衡见《答案要能追溯到出处》。
5. 缓存与失效
联网检索的成本只有靠缓存才压得下来，而缓存的正确性只有靠 TTL 才保得住。
TTL 按主题设，不按全局设。 股价几秒，产品页几天，百科几周。查询进来先查缓存，未过期的直接返回，过期的才触发实时抓取。
失效和过期同等重要。 TTL 只处理"时间到了"这一种情况。还有几种必须立即失效：你引用过的页面 404 了；你信任的源发布了更正；问题里出现了已知的高波动实体。这些要有一条显式的失效路径，不能等时钟走完。
重新嵌入的粒度。 抓回来的内容按 markdown 结构切块（标题、段落），而不是按 HTML 切。清洗后的 markdown 比原始 HTML 少掉大量导航与广告文本，token 数下降明显，切片也更自包含。这一点和《多模态内容怎么入库》里处理非纯文本文档的思路是一致的。
6. 抓不到就拒答
grounding 系统的一个判据：它是否会拒绝。如果所有情况下都能给出一个流畅答案，那它不是 grounded，只是"接了搜索"。
设计上应当明确：召回集合为空、相关性全部低于阈值、或引用校验不通过时，输出"我无法从提供的资料中确认这一点"，并给出转人工或澄清的出口（客服场景的做法见《反馈回流与人工转接》）。把不可验证的答案发出去，比承认不知道的代价高得多。
7. 与自有知识库合并时的三条纪律
生产系统通常两者都有，合并时容易出问题：
分开标记来源类型。 内部文档引用和网页引用不要混进同一个列表，用户需要知道一条依据是"公司文档"还是"外部网页"，这两者的可信度不同。
冲突时要有裁决规则。 内部文档说退货 30 天，抓到的网页说 15 天，模型会自己挑一个并说得很流畅。必须显式规定优先级——通常是内部文档优先，且在提示里写明"冲突时以内部文档为准，并说明存在冲突"。
权限过滤不能因为来源变成外部就跳过。 联网内容虽然没有内部权限问题，但合并后的上下文里如果同时有内部切片，权限过滤仍然要在检索前做（见《权限过滤要在检索前》）。
8. 一条总原则
联网检索买的不是"更多知识"，是新鲜度加可审计性。如果你的问题既不要求新鲜也不要求外部来源，那它就是纯粹的成本增量。
判断要不要上联网，问一句就够：这个问题答错了，是不是因为答案变了？ 是，才需要联网；不是（答错是因为检索没找到、切片切坏了、模型理解错了），联网帮不上忙，先修《RAG 链路与失败模式》里那些更基础的问题。