1 链路总览
一个典型的生成式搜索链路是：query → 查询理解与改写 → 检索（稀疏 / 稠密 / 混合）→ 重排 → 上下文组装 → 生成 → 引用。闭卷模型只依赖参数知识；开卷模型在生成前检索外部文档。消费级 AI 搜索多为混合形态：先判断是否需要检索，再走一轮或多轮检索与生成。
GEO 的作用点不在"让模型记住"，而在"让正确的内容在正确的时间进入上下文，并被答案采纳"。理解这一点，才能解释为什么关键词密度、外链数量这类 SEO 指标在生成式搜索里经常失效。
从工程视角看，GEO 可以拆成三个可控变量：内容能否被检索到、检索到的内容能否被采纳、采纳后能否被正确表述。三者分别对应索引覆盖、上下文竞争与生成归因，优化手段并不相同。把三者混在一起谈，往往会导致"内容发了很多，却不知道哪一步失效"。
2 查询理解与改写
用户问题先被分类、纠错、实体链接与改写。多跳问题会被拆成子查询；模糊指代会结合对话历史补全；口语化表达会被映射到更标准的检索式。
技术含义是：内容要覆盖实体、属性、场景与约束，而不是重复关键词。一个页面若能同时回答"是什么、适合谁、多少钱、和谁比"，更容易在改写后的子查询中被召回。
品牌名歧义是常见问题：同名公司、产品与人物会被实体链接混淆。统一的名称、官方域名、sameAs 声明与知识库条目，是消歧的基础。缺少这些信号时，模型可能把品牌事实归到同名实体上，且很难通过后续内容纠正。实体信号的建设周期长，但一旦建立，会同时改善检索召回与答案表述。
3 检索
稀疏检索以 BM25 为代表，擅长精确词与稀有实体：
score(D,Q) = Σ_i IDF(q_i) · f(q_i,D)(k1+1)
/ f(q_i,D) + k1(1 − b + b·\|D\|/avgdl)
稠密检索用双塔编码器把 query 与 passage 映射到同一向量空间，按余弦相似度召回，擅长语义改写与同义表达。混合检索常用 RRF 融合两路结果：
RRF(d) = Σ_i 1 / (60 + rank_i(d))
分块决定召回质量。固定窗口简单，但会截断语义；语义分块按标题与段落边界切分，通常 200--500 tokens，重叠 10%--20%。每个 chunk 应尽量自包含：不看上下文也能回答一个具体问题。把定义、条件、例外拆散到不同段落，是最常见的自伤。
索引新鲜度同样重要。抓取频率、sitemap、lastmod 与 canonical 会影响内容是否进入检索池；频繁改版、重复 URL 与软 404，会让同一事实在索引里出现多个互相竞争的版本。
大规模索引通常使用近似最近邻（ANN）结构，如 HNSW 或 IVF-PQ，以召回率换取延迟。近似检索意味着"理论上最相似的文档"不一定被召回；同一内容在不同索引分片、不同 ef 参数下，结果也可能不同。这是跨平台复现困难的底层原因之一。
4 重排与上下文组装
召回之后是 cross-encoder 重排：把 query 与候选拼接后打分，精度高但成本大，通常只对 top-50 到 top-100 重排。重排模型对实体、属性与问题类型的匹配更敏感，这也是结构化内容更容易胜出的原因之一。
上下文组装不是越多越好。"Lost in the Middle" 的实验表明，模型对长上下文中间位置的信息利用更差；冗余、冲突与低质段落会稀释信号。工程上常用 MMR 做多样性约束，并限制 token 预算。
对品牌而言，这意味着：同一事实在多个 chunk 中以一致措辞出现，比在一篇长文里重复十次更有效；相互矛盾的旧版本页面，则可能让模型在冲突信息前选择沉默或给出模糊表述。
上下文冲突是另一个常被忽略的问题。官网写"支持 A 协议"，旧版帮助中心写"仅支持 B 协议"，模型可能选择更具体、更新或更权威的一段，也可能在冲突前给出模糊答案。减少冲突比增加内容更重要：下线过期页面、统一 canonical、在页面内标注适用版本。
上下文预算也决定了截断策略。超出窗口的段落会被直接丢弃，常见的做法是保留开头与结尾、压缩中间，或先做摘要再拼接。对内容生产者而言，把关键结论放在段落开头，比放在长段末尾更安全。
5 生成与引用
生成阶段，模型在指令约束下组织答案：列表、对比表、结论段。引用可能来自检索结果的行内标注，也可能是生成后的归因匹配。不同平台的引用策略不同，跨平台比较引用率要先确认定义。
引用存在，不等于被采信。模型可能引用一个来源，却综合了另一个来源的事实；也可能给出"装饰性引用"------形式上标注了来源，但陈述并不由该来源支持。评价引用质量，至少需要 citation precision（引用是否支持对应陈述）与 recall（关键事实是否有引用）。
LLM-as-judge 可以扩展评估规模，但存在位置偏差、冗长偏差与自我偏好，必须用人工标注校准。对于高风险结论，建议保留人工复核样本，并报告标注一致性。
答案结构会影响品牌出现的概率。列表式答案的候选位有限，比较型答案更依赖属性对齐，评价型答案更依赖正负情感与证据。内容若只覆盖"品牌介绍"，而缺少可比较的属性与第三人称证据，就很难进入列表或对比表。
生成阶段的随机性同样不可忽略。即使检索结果相同，采样温度、top-p 与系统提示的微小差异，也可能改变品牌是否出现、以什么顺序出现。这也是单次截图不可靠的另一层原因。
6 品牌信息的四个技术接口
把可操作的抓手压缩，品牌信息进入答案主要有四个接口：
表 1 品牌信息进入生成式答案的四个接口
|--------|-------------------------|------------------|
| 接口 | 技术手段 | 可观测指标 |
| 实体 | 统一名称、官方域名、sameAs、知识库条目 | 实体识别准确率、歧义率 |
| 事实 | 结构化表格、规格 / 价格 / 日期、原始出处 | 事实抽取命中率、错误率 |
| 分块 | 自包含段落、问答结构、清晰标题层级 | 检索 Recall@k、被引用率 |
| 信源 | 权威第三方、原始文档、可追溯引用 | 引用份额、来源多样性 |
四个接口的优先级取决于品类：强监管行业先修事实与信源；快消与耐消更依赖场景化分块与第三方评测；B2B 则更依赖实体一致性与技术文档结构。没有统一的最优解，只有与决策场景匹配的组合。
7 内容工程规范
把页面当成"检索单元"，而不是"流量入口"。以下规范来自检索与生成的约束，而不是文风偏好：
--- 一页一个意图，H2/H3 用问题句式，标题本身可被当作子查询。
--- 首段 60--80 字直接给出答案，再展开条件、例外与证据。
--- 规格、价格、日期用表格，避免埋在长段落里；表格同时服务人与抽取器。
--- 引用原始出处，标注发布时间与更新日期；二手转述要给出链路。
--- 结构化数据使用 Organization、Product、FAQPage、Article，并填写 sameAs、dateModified、author。
--- 更新要有 changelog，避免无意义改版导致索引中的版本冲突。
一个可复用的 chunk 模板是：结论句（是什么 / 适合谁）→ 关键属性（3--5 条，含单位与口径）→ 适用条件与例外 → 原始出处（链接、日期）。四段控制在一屏内，既方便人阅读，也方便检索器抽取。
以一个产品页为例：H1 是产品名，首段回答"是什么、适合谁、价格区间"，随后是规格表、适用条件、与竞品差异、常见问题、原始出处。每个 H2 都能独立回答一个子查询；去掉导航与营销语后，任意一段仍应能被检索器直接使用。
反模式同样明确：关键词堆砌、doorway page、批量伪原创、伪造引用、schema 滥用。这些做法短期可能提高召回，长期会损害来源可信度，并增加被平台降权的风险。
8 评测
评测应分三层，而不是只看一个"可见度分数"。
--- 检索层：Recall@k、nDCG@10、目标 chunk 命中率。
--- 答案层：引用精确率 / 召回率、事实正确率、品牌提及概率与推荐概率。
--- 业务层：品牌搜索、直接访问、线索与转化；需排除季节性与投放干扰。
离线评测可用 RAGAS 一类框架计算 context precision/recall、faithfulness 与 answer relevancy；在线评估应使用 holdout 与同口径复测，避免把流量波动当成内容效果。跨平台比较时，先对齐问题集、采样频次与引用解析规则，再谈差异。
指标选择要和问题类型匹配：发现型问题看候选与列表位置，比较型问题看属性覆盖与对比胜率，验证型问题看事实正确率与负面表述比例。用一个统一的"可见度"覆盖所有问题，会掩盖真正的失效环节。
在线实验要区分"内容上线"与"索引生效"。新页面被抓取、被索引、被检索到，存在数天到数周的延迟；实验窗口应覆盖这个滞后，并用 holdout 页面做对照。否则很容易把索引延迟当成"效果还没出来"，或把平台更新当成"内容起作用"。
9 开放问题
检索索引不可见、模型频繁更新、个性化与地域差异，使得 GEO 实验很难完全复现。引用归因也缺少统一标准：不同平台对"引用"的定义不同，跨平台比较需要谨慎。
另一个开放问题是评测基准。现有 GEO 基准多基于固定问题集与单次生成，难以反映真实分布；公开基准又容易被针对性优化。建立带时间戳、可重放、覆盖多平台的评测集，比再做一个排行榜更有价值。
可迁移的资产不是某个模型的偏好清单，而是：一致的事实、可检索的结构、可追溯的信源，以及一套能重复执行的评测方法。模型会换，这三件事不会。