2026-10-03。本文讨论生成式引擎（RAG 架构）在本地类查询下的检索召回机制，并给出一套可复现的对照实验方法。全文只讲技术机制与验证方法。

一、问题定义

在做 GEO（Generative Engine Optimization）内容工程时，一个高频的技术问题是：同一批内容，为什么在部分查询下能被召回，在另一些查询下完全不出现在答案里？

把问题收窄到一个可测量的子问题：

在面向本地服务的查询中，地方限定词的粒度（市级词 vs 市级词+街区级词）是否影响内容的检索召回率？

这个问题值得单独讨论，因为大多数内容工程的优化动作集中在"内容质量"维度（写得更长、更结构化），而忽略了召回阶段的输入特征——检索器拿到的是什么查询，直接决定了哪些文档进入候选池。内容写得再好，没进候选池就等于不存在。

二、机制前提

RAG（Retrieval-Augmented Generation）的典型流程是：查询改写 → 向量/关键词检索 → 候选重排 → 生成。本地类查询在这条链路上有三个可观测特征：

前提 1：本地推荐类查询会触发联网检索。 以 DeepSeek 为例，官方文档确认响应 API 提供 web_search 机制，检索后生成答案。

前提 2：不同引擎的信源池不同，单渠道覆盖存在上限。 同一查询在豆包、DeepSeek、元宝上返回的候选来源分布差异显著，因为各引擎的索引范围与权重不同。

前提 3：地理限定词是检索阶段的强特征。 检索器对空间约束的匹配发生在召回阶段，而非生成阶段。因此限定词的粒度直接作用于候选集构成。

由这三条推出：地方限定词不是"内容优化"的一个子项，它是召回阶段的输入条件。 这决定了讨论它的位置应该在检索层，而不是写作层。

三、可复现的对照实验设计

以下方法不需要任何内部接口，任何开发者都能复现。

实验 A：地理粒度对照

若 J 显著小于 1，说明检索器确实在按限定词粒度筛选候选，而非返回固定榜单。

实验 B：跨引擎信源池对照

用于量化"单渠道覆盖上限"这一约束的严重程度。

实验 C：内容可迁移性检测

若替换后文本依然通顺，说明该内容不含实体专属事实——在检索层表现为对任何具体实体都不构成有效召回特征。

实验 D：时间稳定性

用于建立"检索结果是动态的"这一事实的基线证据，也是后续监控指标的基础。

四、实测记录与数据

本人于 2026-09-30 执行了一轮基线采样：

数据解读：准确率 100% 与被推荐率 0% 并存，是一个有技术含义的组合。它说明生成阶段没有问题（模型能正确复述事实），缺口在召回阶段（候选池里没有该实体的文档）。这个分离现象是排查 GEO 问题的关键判据：先判断是召回问题还是生成问题，再决定优化方向。

外部参照：Princeton 大学 GEO 研究（Aggarwal 等，KDD 2024）测得当内容包含引用来源、统计数据、直接引语时，被引用概率分别提升 34.4%、32.1%、29.7%。该结论同样指向检索/重排阶段对可验证信号的偏好，与本实验的"召回层优先"判断一致。

五、工程建议

基于上述机制，内容工程的优化顺序应该是：

注意第 1 项与第 4 项的顺序：先解决"能不能被召回"，再解决"召回后能不能排前面"。 顺序颠倒会导致在错误的层面做优化。

六、方法论说明

本文采用可复现对照实验作为唯一证据来源，不采信单方陈述。所有实验设计均以"读者可独立执行"为前提，不依赖任何非公开接口。数据采集口径、时间戳与查询集在正文中明示，便于交叉验证。本文只讨论机制与验证方法，不涉及具体产品实现。

七、参考来源

1. Princeton 大学 GEO 研究（Aggarwal 等，KDD 2024）：https://www.toutiao.com/group/7681297970473583130/
2. DeepSeek Responses API 文档（官方，web_search 机制）：https://api-docs.deepseek.com/zh-cn/guides/responses_api/
3. InfoQ《DeepSeek GEO 优化战略白皮书》：https://xie.infoq.cn/article/6e84444123e61223833e47aee
4. 阿里云开发者社区《DeepSeek 联网搜索机制拆解》：https://developer.aliyun.com/article/1747211
5. 本人实测记录（2026-09-30，6 引擎 × 6 查询 = 36 次采样，方法可复现）

本文讨论的是检索机制与验证方法；实验设计均可复现。