1. 项目为什么启动：AI搜索生态下的GEO不是选择题而是生存题
1.1 从“百度SEO”到“AI问答”，用户获取信息的方式彻底换了链路
今年年初，我们团队在上海接了一个挺有意思的需求。客户是一家做工业设备的企业，官网在传统搜索引擎上的排名一直不错，主要产品词都能排进首页。但当我们试着用最近比较热的几条AI搜索流量入口去问“某某公司设备支持哪些通信协议”时，发现AI回答得很完整，甚至把竞争品牌的型号参数都列出来了，却整段没有提客户的名字。
这个现象不是个例。我身边越来越多的同行在讨论同一件事：用户不再只通过“输入关键词、翻搜索结果”的方式找信息，而是直接问AI搜索框或大模型助手。AI搜索会读多个网页，提炼成一段“看起来可信”的答案，用户几乎没有耐心点开引用链接。这就导致一个残酷结果：你的官网还挂在搜索结果页第一位，但AI的答案是来自第三方论坛、问答社区甚至友商官网的内容，你的品牌在那里等于隐形。
这件事背后的技术名词叫GEO，全称是Generative Engine Optimization，生成式引擎优化。简单说，传统SEO优化的是搜索引擎排名算法，而GEO优化的是大模型和AI搜索对品牌内容的“检索命中率、引用概率和答案转化率”。只要你的内容没进入知识库，没有被RAG链路召回，没有在生成环节被模型当作论据，那你在这个新流量生态里就不存在。
1.2 GEO和SEO的核心差异，以及我们踩过的第一个认知坑
刚开始做项目时，团队内部还有人觉得“GEO不就是把SEO做细一点嘛”。真上手之后才发现，两者底层逻辑差异很大。
SEO的核心是关键词部署、外链权重、页面层级和点击率，本质是跟搜索引擎的爬虫和排序算法打交道。GEO的核心是让AI搜索在“理解问题、检索信息、生成答案”的三个环节里，都把你的内容当作可信来源。这意味着要考虑的维度变成了：文档结构是否清晰到能被切分和检索、语义向量是否能与用户真实提问对齐、答案里是否包含AI引用时需要的关键信息点（比如参数、口径、资质、来源链接），以及跨模型回答时内容口吻是否足够“客观可信”。
我们踩的第一个坑是：硬把传统SEO文章往RAG知识库里塞。结果一句话被切得七零八碎，模型检索时抽出的片段既没有前因也没有后果，生成答案时自然不会优先引用。后来才明白，GEO工程的第一步不是写文章，而是重构信息单元。
1.3 项目目标和可验证闭环的最终定义
这个上海的工程项目，最终目标定为：让目标企业的内容在主流AI搜索问答中被稳定引用，并且这个过程是可量化、可复现、可回归的。
我们最终把整个方案拆成了一个循环闭环：结构化知识库负责“让信息可检索”，RAG内容生成负责“让答案有营养可引用”，跨模型监测负责“持续验证和反馈哪里没被命中”。这个闭环里的每一环都有明确产物：知识库有文档覆盖率，内容生成有引用命中率，监测有跨模型对比报告。有了这些，优化就不再靠感觉，而是一轮一轮有数据支撑的迭代。
2. 结构化知识库：让AI能“读懂”你的内容
2.1 为什么直接扔PDF和Word进去，检索效果总是飘
很多团队做RAG项目时，默认步骤就是把几十个PDF丢给LangChain或Dify，用内置Loader解析，切块，灌进向量库。这套流程demo跑起来很快，但生产环境里检索质量极其不稳定。
原因是：企业原始文档大多面向“人阅读”而非“机器检索”。典型的表现包括：一段话里糅合了三四个主题；产品参数散落在叙述性段落里没有独立表格；FAQ的答案只有一句“可以”，缺少适用前提；兼容性描述用“绝大多数场景”这种模糊表达代替具体版本号。这种内容即使切块后向量化，跟用户问题“接口支持佳能还是尼康”做相似度匹配，效果也往往不如预期。
所以我们在上海项目里定了一条铁律：进入知识库之前，所有高价值内容必须先做结构化改造。不是简单清洗，而是重新设计信息的Schema。
2.2 从非结构化到结构化：我们选择的Schema设计方案
结构化改造的第一步是做信息类型的盘点。工业设备企业的高频内容包括：
- 产品规格参数（型号、尺寸、电压、功率、协议）
- 兼容性列表（支持哪些相机品牌、型号、接口、系统）
- 常见问题解答（故障代码、安装步骤、售后政策）
- 资质与认证（专利、检测报告、行业标准）
- 应用场景案例（某工厂产线、某品牌官方合作）
针对每种类型，我们定义了不同的结构化模板。以产品规格参数为例，我们统一采用“属性名+属性值+适用条件+来源证明材料”的四元组。比如“电源输入：100-240V AC，50/60Hz；适用所有F系列设备；来源：产品说明书2.3节”。这条记录在关系表里单独成行，后面生成问答时就非常容易被检索。
实际操作里，我们没有一上来就上知识图谱，而是先用轻量的JSON字段 + 表格关系模型把信息装进去。原因是知识图谱构建和关系抽取的工程量太大，前期收益并不明显。先用结构化表格解决检索准确率，等语料规模上万条后再考虑图谱化，这是一条更稳妥的路径。
2.3 切块策略和Embedding选型：决定RAG检索上限的一公里
结构化改造做完，才轮到切块和向量化。这里的每一个参数都值得较真。
切块我强烈建议按“语义边界”切，而不是简单按字符数均分。我们内部叫“标题感知切块”：读取Markdown/HTML层级，优先以第二章、三级标题、表格、列表这些逻辑边界作为切割点。比如一个产品FAQ，把每个问题当作独立切块单位，不跟下一个问题混在一起。这样切出来的块，语义内聚度高，召回后不用二次裁剪就能直接作为上下文。
关于块大小，我们试过256、512、1024、2048四种配置后发现：对内容密度高的技术文档，512-768字符（中文字符）效果最稳定，既不会因为太短导致上下文不足，也不会因为太长让向量语义被稀释。overlap设置在10%-15%足够，主要覆盖标题与正文之间的过渡信息。如果overlap过大，容易造成同一个事实被重复召回，浪费上下文窗口。
Embedding模型选择上，我们优先用开源的BGE-M3做主力向量模型。原因很实际：它支持中文和多语言，且对专有名词和长文本有不错的泛化能力，在Milvus、Qdrant里都能方便部署。如果你对部署没有精力，直接用云厂商的向量化API也可以，但要注意统一模型版本，否则后续向量空间不一致，检索结果没法横向对比。
选好切块和Embedding后，我们还额外建立了一个“黄金测试集”。整理出业务方最关注的100个真实问题，每次调整知识库或向量模型，都拿这100个问题跑一遍召回率。只有召回率不降，才允许继续新的改动。这一步让整个优化过程不再是玄学。
3. RAG内容生成：如何写出AI搜索真正愿意引用的内容
3.1 RAG核心链路与多路召回的设计思路
知识库是弹药，真正跟AI搜索打交道还要靠RAG链路。RAG的全称是检索增强生成，核心思路是先根据用户问题，从一个外部知识库里召回相关内容，再把召回内容作为背景信息交给大模型，最后生成答案。
但工程实践里，单靠“用户问题 embedding 一次，去向量库找TopK”这种朴素方案根本不够用。特别是专业领域的提问，用户的问法和文档里的标准描述往往差异很大，比如用户问“发热严重怎么处理”，文档里可能是“设备持续高温运行时的故障排查”，纯语义向量很难对齐。
我们在项目里采用多路召回：第一路是向量召回，适合语义相似但表述差异大的情况；第二路是BM25关键词召回，适合专业术语、型号编码精确匹配；第三路是结构化属性过滤，比如用户问“F300设备电压范围”，直接到规格参数表里查对应的型号和属性。三路召回结果做加权融合，再统一输入给重排模型。
3.2 重排模型和上下文拼装：把最精准的信息送到大模型面前
召回阶段可以适当多召回，比如Top50，但真正拼进提示词的上下文如果太多，效果反而不行。所以中间必须要加一个重排环节，把一堆候选块按“相关性+可信度”重新排序。我们用的是开源的bge-reranker-base模型，虽然多一次推理，但对最终答案质量的提升非常明显。
重排排序后，不一定只取Top1。实际经验是取Top3-5更稳，因为这些块可能分别覆盖了问题的不同侧面，比如一个块讲故障现象，一个块讲解决方法，还有一个块讲注意事项。拼上下文时，我们会给每段内容加一个前缀，标注来源文档和章节路径，比如“[来源：F300用户手册-第4章故障排查]”。这样大模型生成答案时，更容易把引用来源带到最终答复里。
3.3 内容生成规范：答案里如何自然嵌入关键词和引用来源
我们准备RAG内容生成时，不只是让自己编写的技术回答能被人看懂，还要让大模型在引用时觉得“这是很好的答案素材”。这里有一些非常实用的写作规则：
- 开头直接给结论，把最关键的信息放在第一句。
- 每个答案里明确写出适用条件和边界，比如“适用于F300型号，其他型号请查看对应章节”。
- 技术参数、版本号、型号名一定要写全称，并保持口径统一。
- 涉及流程动作时，用有序步骤描述，比如“第一步、第二步、第三步”，方便大模型直接引用和转述。
- 适当加入同义转述，便于向量召回。
举个例子，我们给客户写了一条关于“通信协议”的答案素材：
“F300系列设备支持Modbus TCP、Profinet和EtherNet/IP三种主流工业通信协议。其中Modbus TCP适用于大多数PLC系统，Profinet适用于西门子环境，EtherNet/IP适用于罗克韦尔环境。用户在配置时需在控制面板的‘通信设置’中选择对应协议，并确认固件版本不低于V2.3。”
这段内容在传统SEO文里可能只是列表中的一个条目，但经过结构化后，它自带了一个完整答案的骨架，大模型直接引用就会非常自然。
4. 跨模型监测：让优化效果可量化、可追踪
4.1 监测架构：一套脚本同时调多个大模型API，不需要反复切换平台
建设闭环的第三块是跨模型监测。一开始我们的测试方式很原始，同事轮番拿手机去问不同AI搜索App，截图对比。但这种方式没法持续追踪，也没法回归验证。最头痛的一个问题是：一个内容上线后，可能在某一个模型里被引用了，在另一个模型里却完全消失，到底信哪个？
后来我写了一个轻量级的监测脚本，统一封装问问题集、调不同AI服务商的API、收集响应结果的流程。用Python的异步请求跑一遍200个问题集，大概十几分钟就能拿到全量对比数据。脚本里用一个配置列表管理各家API的endpoint、key和模型名，所有调用逻辑共用一套。这样既避免了在多个平台手动切换的低效，也保证了问题集、参数设置完全一致，拿到了数据才有可比性。
这里特别提醒一点：做跨模型监测的API key和调用凭证一定要走统一密钥管理，不能写死在代码仓库里。我们早期有过一次密钥硬编码，导致一位离职同事拿旧代码还能调接口，后面虽然权限关得快，但已经产生了费用风险。
4.2 核心指标设计：除了引用占比，还应该看什么
跑完采集只是第一步，更关键的是定义好衡量GEO效果的核心指标。我们设置了一整套指标体系：
| 指标名称 | 定义与计算方法 | 为什么重要 |
|---|---|---|
| 引用命中率 | 在所有测试问题中，AI答案里明确提到目标企业、产品或链接的比例 | 这是最直接的曝光指标 |
| 来源链接完整度 | AI回答末尾是否展示官网/文档链接，以及链接是否是我们希望展示的落地页 | 光提名字还不够，要保证能跳转转化 |
| 答案事实准确率 | 抽样人工核对AI提到的技术参数、兼容型号、流程步骤与官方资料是否一致 | 避免大模型幻觉给我方内容“加戏” |
| 内容上下文占比 | 我方知识库内容在整段AI答案中的比重（人工或LLM打分） | 反映我们的内容是不是答题主力 |
| 竞争品牌的相对位置 | 同一次回答里，我方与友商品牌出现的先后顺序和篇幅对比 | 在AI场景下，先被提到的品牌往往占认知优势 |
其中引用命中率最好统计，但参考价值不能单看。我们遇到过一种情况：AI回答里确实提了客户公司名称，但讲的内容是错的——把其他型号的旧参数安到了新设备头上。如果只看命中率，以为效果不错，其实用户已经接收到错误信息。所以跨模型监测里一定要加事实抽检，我通常每周抽20条回答，让业务专家做一轮标注，再反馈给知识库修正。
4.3 从监测结果反向驱动知识库更新，形成闭环
跨模型监测的最终目的不是出一份周报，而是让优化动作有的放矢。
我们的迭代节奏是这样的：周一出监测报告，分析哪些问题没有被正确回答，或者哪些回答里出现了信息缺失。然后判断问题出在知识库缺失（没有对应内容）、还是检索失败（有内容但没被召回）、还是生成阶段被模型忽略。第三步针对不同原因做修改：知识库缺失就去补文档；检索失败就调整切块、重写高密度摘要或增加关键词表；生成被忽略就优化答素材的“可引性”，比如增加开头结论、补充来源标注。
下一周再用同一套问题集跑监测，对比指标变化。这样的好处是，每个优化动作都能明确对应到数据的涨跌，团队的精力不会再花在盲目的“内容刷量”上。
5. 完整实操过程：从0到1跑通一个GEO优化周期
5.1 第一步：用Dify搭建企业内部RAG知识库
在项目初期，我们反而没有直接写代码搭全套RAG框架，而是先用开源工具Dify快速跑通一条MVP链路。Dify自带文档解析、分段、向量化、检索、Agent工作流和发布API的能力，对于企业知识库的RAG应用来说，节省了太多重复造轮子的时间。
具体操作上，我们在Dify里建了一个“GEO知识库”，接入客户的产品文档Markdown、技术参数Excel、FAQ Json三类数据源。Dify会自动完成切块，但我建议切块参数还是要按前面说的原则手动调，不要只用默认值。上传文档后，把Embedding模型配置为BGE-M3，检索模式设为混合检索（向量+全文），并在“检索策略”里开启Rerank。
Dify的好处是把应用构建和API发布打包在一起，前端对话界面也能直接预览。但要注意，Dify默认对聊天记录、引用来源的处理不一定符合你的展示需求，生产环境还是需要在它的接口之上做一层定制。
5.2 第二步：把优化后的内容写成AI友好的“答案素材”
知识库框架搭好后，真正的难点在于内容质量。我们组织内容组梳理客户的三大核心产品线，把每个产品的常用问题（预计覆盖80%的客户提问）按前文所述规则写成标准答案素材。每个问题素材控制在150-300字，开头直接给结论，后续补充适用条件、具体步骤、关联文档。
写完后，我们会把素材转成Markdown格式，并人为加入一些标题关键词。比如“## F300通信协议与PLC连接步骤”，这既是给人类读者看的，也是给AI切块和检索看的。标题里的关键词要跟真实用户提问的高频用语对齐，而不是只写专业术语。
这个过程千万不要外包给不懂技术的写手。有一次我们试着让文案团队按“SEO软文”风格生产，结果一堆“领先、卓越、广泛”的形容词，AI抓取后被模型判定为无信息量内容，检索权重很低。后来内容组必须跟着一起看检索结果，自己写的素材能被检索到什么位置，心里要有数。
5.3 第三步：跨模型巡检，用数据找出没有被AI看到的死角
内容上线后，我会生成一批专项测试题，通常是100条真实客户问题，把它们放到前文说的监测脚本里批量跑。测试的模型包括国内主流的几个大模型API（如通义千问、智谱GLM、Kimi、文心一言）以及集成了AI搜索形态的服务端接口，确保覆盖面足够。
跑完之后，我会重点看几个丢分最多的地方：许多问题在“回答正确率”上得分高，但引用来源却不是我方，这说明知识库信息与模型自身记忆冲突，模型选择了自己“更自信”的内容，我们就需要给知识库内容增加更多的客观证据，比如标注产品型号、版本号、官方网址。另一些问题是“召回率低”，即知识库里明明有，但AI没搜到。针对这类，我们会把问题原文作为“同义问句”补充到对应文档的aliases字段里，比如“设备停机”这个词，可以加上“死机、故障、不工作、无法启动”等别名。
5.4 第四步：优化前后对比，给出可展示的ROI
项目执行到第六周，我们把100条测试题分别跑了一遍优化前和优化后的跨模型监测。
优化前，客户相关内容引用命中率只有8%左右，且多数是散落在论坛里的信息，官网内容几乎未被引用。优化后，引用命中率提升到67%，来源链接指向官网的比例也从个位数提升到接近四成。更关键的是，企业最看重的“产品技术参数”类问题，AI回答中引用我们内容的占比达到了82%，直接使一批高意向客户在AI搜索阶段就对产品建立了信任感。
这个结果说明：GEO优化只要链路闭环，且每一步都用数据验证效果，完全可以在不到两个月内实现可观的流量抓手。
6. 常见问题与排查技巧实录
6.1 切块后语义断裂、信息碎片化怎么解决
很多团队会遇到“召回的内容像拼图碎片”的问题。最常见原因是切块时机太早，直接对原始文档做了暴力切分。我们后来严格遵守“先结构化、后切块”的顺序：每份文档上线前，先人工或使用LLM抽取关键信息，形成标准问答对和参数表，再针对这些结构化记录做切块。对于无法结构化的长篇幅说明文，再使用标题感知切块。
如果已经出现碎片化，还有一个立竿见影的修复方法：在每个切块开头增加一段“导语”，用30-50字概括这个切块的核心结论。比如切块内容是一段关于操作步骤的长文，就在块首加“本文说明F300固件升级的完整操作，适用于2.3版本以上”。这样即使切块只命中了后半段，大模型也能从导语里接收到完整主题信息。
6.2 多个AI模型的回答方向不一致，该听谁的
不同 AI 模型训练数据、指令遵循能力、上下文利用方式不同，对同一问题的答案风格常有差异。有的模型倾向引用官网原文，有的模型更喜欢综合多个来源后重新表述。横比之后，往往会有“A模型命中、B模型未命中”的情况。
我的经验是：不要试图让所有模型100%保持一致，因为底层模型差异我们无法控制。但可以通过强化知识库的“唯一权威性”来提高整体命中概率。具体做法是把核心事实内容写成“单一事实源”，使用模棱两可和“大多数情况下”这类的模糊表达。同时，在知识库里加入证明权威性的字段，比如“官方文档”、“检测编号”，让模型更倾向于选择我们的内容。最优情况下，至少保证头部两三个主流AI模型都能稳定引用，小体量模型不作为重点。
6.3 引用来源丢失和生成幻觉，如何追查和修正
RAG链路中最让人头疼的是大模型在回答里“不带来源”或“编造来源”。这个问题通常有三个根因：知识库根本没把来源信息送入上下文；模型训练时预先理解了某段信息；提示词里没有强制要求给出引用。
工程上，我推荐在提示词中强制要求模型每一步都标注来源，例如提示语写：“如果引用了知识库内容，请在回答末尾使用参考资料格式列出文档编号”。另外在知识库里给每份文档录入独立的document_id，并在检索结果返回时保留来源元数据。如果模型还是“幻觉”，就要考虑是不是多路召回结果里混入了低质量内容，检查重排阈值是否放太低。
6.4 成本控制与API调用配额优化
跨模型监测如果每天全量跑200个问题，乘以多路模型API，费用和速率限制都会带来压力。我们后期做了一波降本优化：把全量测试从每天改为一周两次，每次先跑30条“预警问题”，如果命中率比上周下降不超过3%，就不再做全量回归；只有当预警问题触发阈值时，才启动全量测试。这种方式当月API成本减少了40%以上。
另外，不要把同一批问题并发打到所有API上，尽量设置限速。用Python的asyncio.Semaphore控制并发量，可以避免触发模型服务端的429限流，也降低因超时导致的无效调用。
6.5 一张实用的问题排查速查表
| 现象 | 可能原因 | 排查与修复方式 |
|---|---|---|
| 答案里不出现企业品牌 | 知识库内容没有覆盖该信息点 | 补写标准答案素材，确保主题与高频问题对齐 |
| 答案引用了友商内容 | 我方信息密度和可引性不足 | 重写答案，增加具体参数、出处、步骤 |
| 模型回答正确但没引用我方来源 | 生成阶段模型选择了自身记忆 | 在提示词中强调知识库引用，并突出来源权威性 |
| 同一问题不同模型结果差异大 | 模型训练语料和关注点不一致 | 聚焦头部模型优化，积累单模型对比报告 |
| 检索召回片段与用户提问无关 | 切块粒度太粗或Embedding模型不合适 | 调整切块策略，尝试混合检索，测试其他Embedding |
| 成本超标 | 测试问题集过大、调用频率过高 | 分层测试机制，使用并发限制和异常重试 |
最后说点实在的
这套GEO闭环体系在上海项目里跑通后，我们又陆续复用到几个制造业和B2B软件客户，整体思路并没有变。我个人最大的体会是：GEO优化不是一次性内容改造，更像一套围绕AI搜索反馈循环的持续运营机制。知识库是地基，内容生成是钢筋，跨模型监测是质检员，三者缺一不可。
如果你现在正打算启动类似项目，我的建议是从一个最小的高价值产品线开始，先把20个核心问题做到被主流AI搜索稳定引用，再慢慢扩展到更多文档。很多团队一上来就想把所有资料一股脑灌进知识库，结果检索效果差、分析不出问题，最后挫败感很强。先小步快跑，把指标基线建立起来，后续每一轮优化都会有清晰的方向。
最后再分享一个小技巧：GEO优化过程中，保存好每一轮的知识库版本和监测报告。我们后来遇到一次效果回退，就是靠两个月前的旧版本知识库对比，定位到新版切块逻辑引入了一条语义重复的数据。这种版本管理平时不起眼，关键时刻能救命。
