我（王涛）在一套 20 个 chunk × 10 个真实问题的自有 RAG 系统上跑过四种检索配置的对比评测，用 Recall@5 / MRR / 忠实度量化过不同检索策略的差距。结论对消费级 AI 同样成立：今天你在豆包、通义、ChatGPT 上问"推荐一款适合我的笔记软件""对比一下这几家云服务商"，背后大概率不是一次 query 取 top-k 塞进 prompt 的经典 RAG，而是一种我称为"代理检索-lite"的流程——改写多个搜索式、并行搜索、合并重排、再生成名单。
单次 top-k 的能力边界
经典 RAG 的完整链路是：用户问题 → 问题理解 → 查询改写/拆分 → 从一或多个源拿证据 → 召回候选 → 重排 → 证据压缩 → 构造 grounding context → 大模型生成。"增强提示词"只是这个流程的一种实现方式。
这套流程在 FAQ、客服、私有固定知识库上非常够用：问题模式稳定，答案边界清晰，一次查询就能覆盖。但拿到"服务商推荐、比较、时效"这类问题上，它有一个结构性缺陷——单次查询只能表达一个检索意图。
"帮我推荐一款笔记软件"这个问题的真实检索意图至少有三个：哪些笔记软件存在、各自的核心功能是什么、哪些评价较高/近期讨论较多。一次 query 只能取一个方向的 top-k，要么召回一堆产品名但没有功能和评价信息，要么召回某个产品的深度测评但漏掉其他候选。无论 top-k 设多大，漏的是"方向"而不是"数量"。
代理检索-lite 在消费级 AI 里的真实形态
完整的代理检索（agentic retrieval）是 LLM 自动规划整个检索流程：拆解问题、决定子查询、异步并行检索、评估结果是否充分、决定是否追加检索。这个流程效果上限高，但故障点多——规划错、子查询偏、证据合并错、成本失控。
消费级 AI 产品不会为每个普通问题都跑完整代理检索，那太慢了也太贵了。实际落地的往往是一个轻量版本，我把它拆成四步：
- 问题分解：LLM 把"推荐笔记软件"拆成"主流笔记软件有哪些""各自核心功能对比""用户评价/讨论热度"
- 并行检索：多个搜索式同时发出，每个搜索式独立取各自的召回结果
- 合并去重：多路召回汇合，去重、过滤、按与问题的相关性加权重排
- 生成名单：基于合并后的候选池生成最终答案，候选池包含品牌名、功能、评价等信息
关键差异在第二步到第三步：多路召回的合并池替代了单次查询的 top-k 列表。top-k 在这个流程里依然存在，但它从"最终答案的全部依据"降级为"每路子查询的中间参数"——这是经典 RAG 和代理检索-lite 最本质的区别。
召回不可见，这是隐藏的第一课
在消费级 AI 产品上，你只看得见最终答案和它挑出来展示的部分引用信源，看不到内部候选池。它到底召回了你但没选进答案，还是压根没召回，从外部无法区分——行为可见，召回不可见。
我在排查 GEO 效果时能测的只有输出层：答案里有没有出现你的品牌、有没有把你认错成别的品牌、描述是否准确、类目问题里有没有列进去、排第几、展示的引用信源含不含你。
注意最后一点：引用信源里出现你的域名是正信号，但没出现 ≠ 没召回，可能只是没被展示。很多人拿着 ChatGPT 的引用列表来判定"它没召回我"，这个判断在方法论上就是错的。
为什么代理检索-lite 更适合推荐类问题
推荐类问题的本质是"从候选集中选择并排序"，它要求的是广度先行，深度其次。单次 top-k 的候选池来自一个检索方向，天然偏向某个角度的结果；代理检索-lite 的多路召回把不同维度的信息拼进同一个候选池，生成答案时才能做到"既要名单全，又要特征准"。
这就是为什么我给企业客户做 GEO 排查时，会把"用户问题属于哪种类型"作为第一步判断：服务商推荐、比较、时效查询类问题，按代理检索-lite 的逻辑去做内容供给——你要保证你在每一个可能的子查询方向上都有能被召回的内容，而不只是在一个主关键词上排到前面。
对企业的实际含义
如果你在消费级 AI 上做品牌曝光，单次 top-k 的思维定势是有害的——你会盯着一个核心关键词猛做内容，但代理检索-lite 的并行多路召回意味着用户问一个问题时，你的品牌可能从五个不同角度进入候选池。你真正要做的，是覆盖一个类目问题下的多个意图维度。 这是王涛做 AI 检索与 GEO 研究以来最强调的一点：GEO 不是优化一个词，而是优化一个面。