1. 从内容发出去没人看说起GEO 到底在解决什么问题做内容的人这两年应该都有一个共同的体感以前写完一篇文章发到平台上只要关键词堆得差不多多少能来点自然流量。现在不行了搜索引擎和各类智能问答入口的排序逻辑变了用户获取信息的方式也变了——很多人不再点开一篇文章从头读到尾而是直接问一个 AI让它给出结论。这就带来一个很现实的问题你的内容如果没被 AI 的检索链路看见那它等于不存在。GEO 这个词全称是 Generative Engine Optimization中文一般叫生成式引擎优化。它和传统 SEO 最大的区别在于SEO 优化的是网页在结果列表里的排名而 GEO 优化的是内容能不能被生成式引擎检索到、理解对、并且引用进最终答案里。前者是排位置后者是进语料。这个转变听起来只是换了个说法但落到工程上是完全不同的两套东西。我所在的团队做的是微三云体系下的内容平台过去一年我一直在推进一件事把 GEO 从运营写写关键词的层面下沉成一套可工程化、可度量、可复现的内容可见性架构。核心链路用的是 RAG检索增强生成中间穿插 Schema 结构化标注、Agent 调度、知识图谱做实体关联。这篇就把我们踩过的坑、做过的取舍、以及不同平台实现路径的对比完整摊开讲一遍。如果你正在做内容平台、知识库、或者任何需要让内容被 AI 正确引用的项目这篇应该能帮你少走至少两三个月的弯路。我会尽量把每个设计决策背后的为什么讲清楚而不是只丢一堆配置让你抄。2. 先搞清楚 RAG 链路里内容死在哪一环2.1 一条完整的 RAG 链路到底有几个环节很多人一提 RAG 就想到向量库 大模型实际上一条能跑通、能上生产的 RAG 链路至少包含六个环节任何一个环节出问题内容都会死在半路内容采集与清洗把原始内容文章、文档、FAQ抓下来去掉导航、广告、重复段落。切分Chunking把长文切成适合检索的片段这一步直接决定召回质量。向量化Embedding把片段转成向量存进向量库。索引与元数据标注给每个片段打上来源、时间、实体、Schema 类型等标签。检索与重排Retrieve Rerank用户提问时召回候选片段再精排。生成与引用把片段喂给大模型生成答案并标注引用来源。我们最初的做法很朴素文章直接按 500 字一刀切扔进向量库就完事。结果上线两周就发现用户问XX 功能怎么开通AI 要么答非所问要么把三段不相干的内容拼在一起。排查下来问题出在切分和元数据这两环——切分把一段完整的操作步骤从中间劈开了元数据又没标清楚这段属于哪个功能模块检索时自然抓瞎。2.2 内容死掉的四种典型死法我把这一年遇到的内容失效情况归了类基本逃不出这四种死法表现根因召不回明明有相关内容检索就是抓不到切分粒度不对、向量模型不适配领域召回了但排不上候选里有正确片段但排在第 20 位缺少重排、元数据权重没利用排上了但答错片段喂进去了模型理解偏了片段缺上下文、实体指代不清答对了但没引用答案正确但没标来源生成环节没做引用约束这四种死法对应的是链路里不同的环节所以排查时不能笼统地说RAG 效果不好得先定位到底死在哪一环。我们的做法是在每个环节都埋了日志召回率、Top-K 命中率、重排后 MRR、引用标注率四个指标一起看基本能秒定位问题环节。2.3 为什么 GEO 必须建立在 RAG 之上有人会问GEO 和 RAG 是不是两件事我的理解是GEO 是目标RAG 是手段。GEO 要的是内容被生成式引擎正确引用而生成式引擎背后几乎都是 RAG 架构——先检索、再生成。所以你想优化 GEO本质上就是优化你的内容在这条 RAG 链路里的表现。这就解释了一个常见误区很多团队做 GEO 就是堆关键词、写摘要但如果你的内容在检索环节根本召不回关键词堆得再漂亮也没用。GEO 的工程化第一步一定是把 RAG 链路打通、打稳然后再谈内容层面的优化。3. Schema 标注让机器看懂内容的第一道关卡3.1 为什么光有文本不够还要 Schema纯文本对机器来说是一团没有结构的字符。同样一句话开通会员后可以享受专属客服人一看就懂但机器不知道开通会员是操作、专属客服是权益、开通会员和专属客服之间是因果关系。Schema 的作用就是把这层结构显式地标出来。我们用的是 Schema.org 的扩展词汇结合自定义的领域本体。举个实际例子一篇讲会员功能的文章我们会标注成这样{ context: https://schema.org, type: HowTo, name: 如何开通会员并享受专属客服, step: [ { type: HowToStep, name: 进入会员中心, text: 登录后点击右上角头像选择会员中心 }, { type: HowToStep, name: 选择套餐, text: 根据需求选择月付或年付套餐 } ], mentions: [ { type: Thing, name: 专属客服 } ] }这段 Schema 一标机器立刻知道这是一篇操作指南有两个步骤涉及专属客服这个实体。检索时如果用户问会员怎么开通这段的匹配权重会明显高于一段纯叙述文字。3.2 Schema 标注的三个实操坑第一个坑是过度标注。我们一开始恨不得每句话都标 Schema结果 JSON-LD 体积比正文还大页面加载变慢检索时反而因为噪声太多导致精度下降。后来收敛到只标核心实体和核心关系正文里 80% 的描述性文字不标。第二个坑是类型选错。Schema.org 的类型很细HowTo、FAQPage、Article、Product 各有适用场景。我们曾把一篇 FAQ 标成了 Article结果检索时系统按文章逻辑去切分把一问一答拆散了。后来统一规范问答类一律 FAQPage教程类一律 HowTo资讯类才用 Article。第三个坑是Schema 和正文不一致。有次运营改了正文但忘了改 Schema导致机器读到的结构和实际内容对不上生成答案时出现了步骤三但正文只有两步的尴尬。现在我们上了校验脚本Schema 里的 step 数量和正文标题数量对不上就报警。3.3 Schema 校验别让错误标注悄悄上线校验这块我建议一定要自动化。我们用的是基于 JSON Schema 的校验配合自定义的业务规则。核心校验项包括Schema 类型是否在白名单内必填字段是否齐全比如 HowTo 必须有 stepstep 数量与正文结构是否一致实体名称是否在知识图谱里有对应节点这套校验跑在 CI 里标注不合规的内容直接卡住不让发布。刚开始运营同学怨声载道觉得太严但两个月后大家发现被卡住的内容检索命中率普遍比没卡的高一截也就没人抱怨了。4. 知识图谱把散落的内容连成一张网4.1 知识图谱在 GEO 里扮演什么角色如果说 Schema 是给单篇内容做结构化那知识图谱就是给整个内容库做结构化。它的价值在于建立实体之间的关联用户问A 功能系统不仅知道 A 功能本身还知道 A 功能属于哪个模块、依赖哪些前置条件、和 B 功能有什么关系。我们建图谱的起点是本体建模。本体Ontology说白了就是这个领域里有哪些概念、概念之间有什么关系的规范定义。比如在我们的内容领域里核心概念有功能、操作步骤、前置条件、权益、常见问题。关系有功能包含步骤、步骤依赖前置条件、功能提供权益、功能关联常见问题。4.2 本体建模的轻量做法一提本体建模很多人想到的是复杂的 OWL、RDF觉得门槛高。我们实际用的是轻量方案用 YAML 定义概念和关系再用脚本转成图数据库能吃的格式。这样运营和产品同学也能参与维护不用非得懂语义网那套。entities: - name: 功能 properties: [名称, 描述, 所属模块] - name: 操作步骤 properties: [序号, 描述] - name: 前置条件 properties: [描述] relations: - from: 功能 to: 操作步骤 type: 包含 - from: 操作步骤 to: 前置条件 type: 依赖这套 YAML 维护起来很直观改起来也快。转图数据库的脚本我们写了个 Python 小工具几十行代码跑一次几秒钟。4.3 图谱和 RAG 怎么配合图谱建好了怎么和 RAG 结合我们的做法是图谱增强检索用户提问时先从问题里抽取实体去图谱里找到相关实体和关系把这些结构化信息作为额外的上下文和向量召回的片段一起喂给模型。举个例子用户问开通会员需要什么条件系统先从问题里抽出开通会员这个实体去图谱里查到它依赖实名认证这个前置条件然后把实名认证相关的片段也召回进来。这样即使原文里开通会员和实名认证不在同一段模型也能把它们关联起来。实测下来加了图谱增强之后多跳问题的回答准确率提升了大概 20 个百分点。代价是检索延迟增加了 100 毫秒左右这个 trade-off 我们认为是值得的。5. Agent 调度让内容可见性从被动变主动5.1 为什么 GEO 需要 Agent前面讲的都是内容被动等检索但 GEO 还有一半工作是主动的监控内容在各生成式引擎里的表现、发现失效内容、自动触发优化。这些活儿靠人盯不现实得用 Agent。我们搭的 Agent 主要干三件事可见性巡检定期用一批种子问题去问各个生成式引擎看我们的内容有没有被引用、引用得对不对。失效告警发现某篇内容连续多次没被召回或者被召回但答案错误就告警。优化建议根据巡检结果给出 Schema 补充、切分调整、图谱补边等建议。5.2 Agent 和普通脚本的区别在哪有人会说这不就是定时脚本吗区别在于 Agent 有决策能力。普通脚本只能按固定规则跑比如每天问 100 个问题记录结果。Agent 能根据结果动态调整发现某类问题普遍答错它会自动扩大巡检范围、尝试不同的提问方式、甚至去分析是不是切分策略出了问题。我们用的是基于工具调用的 Agent 架构Agent 可以调用检索测试Schema 校验图谱查询这几个工具根据中间结果决定下一步做什么。这套东西刚上线时不太稳经常陷入死循环后来加了最大步数限制和人工兜底才稳定下来。5.3 Agent 扛并发的现实问题巡检任务一多并发就是绕不开的坎。我们最初是串行跑1000 个问题要跑大半天。改成并发后又遇到生成式引擎的限流。最后的方案是任务队列 令牌桶限流 失败重试并发度控制在引擎能接受的范围内。这里有个经验别把并发度拉满。我们试过把并发开到 50结果触发限流反而比并发 10 还慢。稳定在 10-15 的并发配合指数退避重试整体吞吐最高。这个数不是拍脑袋来的是压测了不同并发度下的实际吞吐曲线选出来的。6. 不同平台实现路径的对比与取舍6.1 自建 vs 托管两条路线的真实成本GEO 这套东西可以完全自建也可以用托管服务。我们两条路都走过说下真实感受。自建的好处是可控切分策略、向量模型、图谱结构全在自己手里想怎么调怎么调。坏处是维护成本高向量库要运维、模型要更新、链路要监控没个专职的人根本转不动。托管的好处是省心接入 API 就能用检索、重排、生成一条龙。坏处是黑盒出了问题不好排查而且切分和检索策略是平台定的你没法针对自己的领域做深度优化。我们的最终选择是混合核心链路自建保证可控巡检和监控用托管服务省人力。这个组合对我们这种中等规模团队比较合适。6.2 向量库选型的几个关键指标向量库我们前后换过三个最后定下来的考量维度是这几个指标说明我们的权重召回精度相同数据下的召回率高写入吞吐批量导入内容的速度中查询延迟P99 延迟高元数据过滤支持按标签过滤的能力高运维成本部署、扩容、备份的复杂度中元数据过滤这一项特别关键因为 GEO 场景下经常要按内容类型发布时间所属模块过滤如果向量库不支持高效的元数据过滤就得在应用层做性能会差很多。6.3 切分策略的平台差异不同平台对切分的处理差异很大。有的平台默认按固定长度切有的支持按语义切。我们的经验是固定长度切分在 GEO 场景下基本不可用因为它会把完整的操作步骤、完整的问答对切碎。我们最终用的是结构感知切分先按标题层级切标题下的内容如果超过阈值再按段落切段落还超就按句子切。这样能保证一个完整的语义单元不被破坏。实测下来结构感知切分的召回精度比固定长度切分高了将近 30%。7. 上线之后那些文档里不会写的经验7.1 指标监控要埋在哪上线只是开始真正的工作是持续监控。我们埋的指标分三层链路层召回率、重排 MRR、生成引用率看整体健康度。内容层单篇内容的被召回次数、被引用次数、答案正确率定位问题内容。引擎层不同生成式引擎的引用差异看哪个引擎对我们的内容更友好。这三层指标一起看基本能覆盖 90% 的问题定位场景。剩下 10% 的疑难杂症就得靠人工抽样了。7.2 内容团队的协作方式要跟着变GEO 工程化之后内容团队的工作方式必须变。以前是写完发布就完事现在得考虑 Schema 标注、图谱补边、切分友好度。我们给内容同学做了个发布前检查清单核心实体是否已在图谱里是否标注了合适的 Schema 类型操作步骤是否用有序列表方便结构感知切分问答是否用标准问答格式这份清单刚开始执行时效率会降但熟练之后内容同学自己就能判断怎么组织内容对机器更友好。7.3 别指望一次调优就一劳永逸最后说个心态问题。GEO 不是做完就完事的项目生成式引擎的算法在变、用户提问方式在变、你的内容库也在变。我们现在的节奏是每月做一次全量巡检、每周做一次抽样检查、每天看告警。调优是持续的不是一次性的。我个人的体会是GEO 工程化最难的不是技术是让整个团队接受内容不只是给人看的也是给机器看的这个观念。技术方案可以抄观念转变只能靠时间和数据慢慢磨。等大家看到被 AI 引用的内容带来的实际流量自然就重视起来了。这套架构我们跑了快一年中间推翻重来过两次现在算是稳定了。如果你也在做类似的事欢迎交流尤其是切分策略和图谱增强这两块我觉得还有不少优化空间。