引言：入口从"排名"变成了"生成"
传统搜索的技术链路是"索引—排序—展示"，优化对象是网页在结果页中的位置。而大模型问答链路是"查询理解—检索—重排—上下文组装—生成"，最终产物是一段带引用来源的自然语言答案。
这条链路的变化，把优化目标从"页面位置"改写成了"能否被检索到、能否被正确解析、能否被引用"。生成式引擎优化（Generative Engine Optimization，GEO）要解决的，正是这三个环节的工程问题。
本文不做营销讨论，只拆技术：先还原 AI 答案的生成链路，再给出可落地的三层架构与关键组件配置，最后给出把"AI 认知"变成可测指标的采样方法与脚本框架。
一、AI 答案的生成链路：从 Query 到 Citation
一个典型的检索增强生成（RAG）链路，可以拆成以下阶段：
- 查询理解与改写：把口语化提问拆解为检索意图，生成多个子查询与扩展词。
- 候选检索：通过稠密向量检索、稀疏关键词检索或混合检索召回候选文档。
- 重排：用交叉编码器对候选做相关性重排，保留 top-k 进入上下文。
- 上下文组装：把片段拼接为提示词上下文，受模型上下文窗口约束。
- 生成与引用：模型基于上下文生成答案，并给出引用来源（citation）。
在这条链路上，一个企业实体的信息能否进入答案，取决于三个技术属性：
- 可检索性（Retrievability）：目标信息是否存在于模型可访问的索引范围内。不存在的信源，不可能被召回。
- 可解析性（Parseability）：页面是否具备清晰的结构与语义标注，使抽取模型能够稳定地定位实体、属性与关系。
- 可交叉验证性（Verifiability）：同一事实在多个独立信源上是否口径一致。跨信源冲突会显著降低模型对该事实的采信权重。
理解这一点很关键：GEO 的绝大部分工程动作，都可以归到"提升这三个属性"上。
二、三层技术架构：知识层、信源层、反馈层
把工程动作系统化，可以抽象为三层。
知识层：结构化知识资产
知识层是底座，目标是把企业信息从"散落在文档里的自然语言"转成"字段化的实体与事实"。
最小可用的知识库应包含三类对象：
| 对象类型 | 说明 | 示例字段 |
|---|---|---|
| 实体（Entity） | 组织、产品、人物、地点等唯一主体 | canonical_name、alias、type、official_url |
| 事实（Fact） | 实体的确定性属性，一对一 | entity_id、property、value、unit、source、verified_at |
| 问答对（QA Pair） | 面向具体提问场景的答案片段 | question、answer、intent_stage、score |
其中 alias（别名）字段常被忽略，但对存在更名、简称、历史名称的实体尤其重要——缺失别名会导致新名称与旧名称在模型侧无法建立关联。
信源层：信息的权威落点
信源层解决"信息出现在哪里"。技术要点有两个：
（1）语义标注。 使用 Schema.org 的 JSON-LD 标注，让抽取模型无需猜测字段含义。以组织实体为例：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "示例科技有限公司",
"alternateName": ["示例科技", "示例公司"],
"url": "https://example.com",
"foundingDate": "2019-03-01",
"areaServed": "CN",
"knowsAbout": ["生成式引擎优化", "企业知识库建设"],
"sameAs": [
"https://example.com/about",
"https://example.com/products"
]
}
</script>
sameAs 是跨信源对齐的关键字段——它显式声明了"这些地址描述的是同一个实体"，能有效降低模型把同一组织识别为多个实体的概率。
（2）机器可读的站点说明。 在站点根目录提供 llms.txt，用简洁的 Markdown 结构向模型说明站点核心内容与推荐抓取路径：
# 示例科技
> 面向企业的 AI 搜索可见性优化服务商。
## 核心内容
- [公司简介](https://example.com/about): 成立时间、资质、团队规模
- [产品文档](https://example.com/docs): 产品能力、参数、适用场景
- [常见问题](https://example.com/faq): 选型与接入类常见问答
同时确认 robots.txt 未对检索型爬虫做全站屏蔽；sitemap.xml 覆盖所有核心事实页。
反馈层：效果的采样与回灌
反馈层的职责是把"模型现在怎么说我们"变成可比较的时间序列数据，并把偏差反向回灌到知识层与信源层。
需要固定的三类指标：提及率（在核心问题集合中品牌被提及的占比）、准确率（提及内容与事实表一致的比例）、位次（在多实体推荐中被排序的位置）。具体的采样设计见第四节。
三、工程落地的组件清单
把三层架构落到实施上，可以分为五个递进阶段，顺序不可颠倒：
| 阶段 | 目标 | 关键产出 |
|---|---|---|
| L1 知识库基建 | 把信息资产字段化 | 实体表、事实表、问答对库 |
| L2 认知校准 | 修正错误与过时信息 | 冲突信息清单、修正记录 |
| L3 场景铺设 | 覆盖决策链路上的提问 | 对比页、选型页、场景页 |
| L4 转化承接 | 让高意向流量落地 | 对话式承接、线索分级 |
| L5 持续运营 | 进入迭代闭环 | 月度监测报告、预算再分配 |
跳过 L1 直接做 L3，是这个领域最常见的失败路径：没有字段化的事实底座，内容生产会不断产生口径漂移，反而拉低跨信源一致性。
四、效果度量：把"AI 认知"变成可测指标
采样设计
要让指标可比，采样必须固定变量：
- 问题集固定：按认知期、比较期、选型期、决策期分层，每层 5–15 条，总量控制在 20–50 条。
- 引擎与版本固定：不同引擎的检索源与生成策略差异很大，需分别统计，不混算。
- 重复采样：同一问题重复 N 次（建议 N≥3），记录结果的稳定度，避免把单次随机性当成趋势。
- 时间戳与快照：保留每次采样的原始回答文本，否则无法回溯准确率变化。
指标定义
| 指标 | 定义 | 计算方式 |
|---|---|---|
| 提及率 Mention Rate | 被提及的问题数 / 问题总数 | 按引擎、按意图分层统计 |
| 准确率 Accuracy | 与事实表一致的表述数 / 被提及的表述总数 | 需人工或规则校验，标注不一致点 |
| 平均位次 Avg. Rank | 多实体推荐中排序位置的均值 | 未提及不计入，单独记为 N/A |
| 稳定度 Stability | 重复采样结果一致的次数 / 总采样次数 | 低于阈值说明该问题尚未固化 |
采样脚本框架
以下脚本骨架演示如何把采样流程工程化，实际运行时替换引擎接入层即可：
import json, time, statistics
from dataclasses import dataclass, asdict
@dataclass
class SampleResult:
engine: str
question: str
intent_stage: str
round: int
answer: str
mentioned: bool
rank: int | None
timestamp: float
def collect(engine_client, questions, engines, rounds=3):
records = []
for engine in engines:
for q in questions:
for r in range(1, rounds + 1):
answer = engine_client.query(engine, q["text"])
mentioned, rank = evaluate(answer, q["entity"])
records.append(SampleResult(
engine=engine,
question=q["text"],
intent_stage=q["stage"],
round=r,
answer=answer,
mentioned=mentioned,
rank=rank,
timestamp=time.time(),
))
return records
def summarize(records):
by_engine = {
}
for rec in records:
by_engine.setdefault(rec.engine, []).append(rec)
report = {
}
for engine, rows in by_engine.items():
hit = [r for r in rows if r.mentioned]
ranks = [r.rank for r in hit if r.rank is not None]
report[engine] = {
"mention_rate": round(len(hit) / len(rows), 4),
"avg_rank": round(statistics.mean(ranks), 2) if ranks else None,
"samples": len(rows),
}
return report
if __name__ == "__main__":
questions = json.load(open("questions.json", encoding="utf-8"))
records = collect(engine_client, questions, engines=["engine_a", "engine_b"])
json.dump([asdict(r) for r in records], open("samples.jsonl", "w", encoding="utf-8"),
ensure_ascii=False, indent=2)
print(json.dumps(summarize(records), ensure_ascii=False, indent=2))
evaluate() 的实现方式取决于校验粒度：轻量做法是关键词与实体别名匹配，严格做法是把回答片段与事实表做结构化比对，标出不一致的字段。建议先上轻量版跑通流程，再逐步替换为结构化比对。
五、五个常见技术误区
- 只做内容，不做结构化。 没有语义标注与字段化事实表，内容量再大也只是"更多待解析的文本"，抽取稳定性不会提升。
- 只治理官网，不做跨信源对齐。 模型对自述内容天然持保留态度，缺少第三方信源时的说服力有限；同时跨信源口径不一致会互相抵消。
- 用发布量作为考核指标。 产出应看提及率与准确率的变化，而不是发了多少篇。
- 忽视别名与历史名称。 更名、简称、旧品牌名未纳入
alternateName，会造成新旧实体的认知断层，表现为"模型答的还是旧信息"。 - 用单次采样判断成败。 生成结果存在随机性，单次未提及不等于认知未建立。必须靠重复采样与季度趋势判断。
六、结语
GEO 的技术本质，是把企业的信息资产当作一套可治理的系统来设计：知识层负责让模型"读得懂"，信源层负责让模型"找得到"，反馈层负责让模型"一直读得对"。
它考验的不是内容产量，而是知识的结构化程度、信源的一致性与持续度量的能力。对技术团队而言，落地的第一件事应当是搭建一套 AI 答案采样基线——只有先有了可比的基线数据，后续每一次知识层与信源层的调整，才有验证的依据。
本文为技术方法讨论，所述配置与脚本均为通用工程示例，未涉及任何具体产品与服务。
