一、从“页面工程”到“知识工程”技术对象变了传统 SEO 工程本质上是围绕“页面作为信息载体”做工程你优化的是 URL、HTML 结构、sitemap、robots、页面性能、内部链接、日志分析。生成式引擎优化GEO工程技术对象换成了“知识作为信息载体”你要处理的是实体、属性、关系、向量空间、知识图谱、上下文窗口、投喂策略、一致性和可信度。对技术团队来说差别可以概括成一句话从“让搜索引擎看懂页面”到“让大模型看懂你整套业务知识”。要完成这次升级技术栈本身可能差不多依然是数据库、检索引擎、服务端、API。但在工程能力上需要补上五个关键点。能力一数据层从“文章表”升级到“实体表 事实表 关系表”1. SEO 工程常见的数据设计很多传统内容系统的数据结构是这样的articles文章/页面表id,title,content,category_id,tags,created_at…categories分类表links外链/友链表再加点 PV 统计、评论表之类。这对“页面为核心”的 SEO 来说够用搜索引擎只需要识别页面结构和内容。2. GEO 工程的数据模型需求在 GEO 里生成式引擎关注的是实体和事实而不是只关心页面。技术团队需要引入几类新表结构entities实体表entity_id,entity_typebrand/product/store/city/faq/case…,name,aliases,status…facts事实表fact_id,entity_id,fact_typeaddress/capability/metric/scene…,value,source,source_type,confidence,valid_from,valid_to…relations关系表from_entity_id,to_entity_id,relation_typebrand-has-product, product-serves-scene, store-in-city……versions/audit_log版本与审计表谁改了什么事实、什么时候改、改前改后差异。这意味着小的业务改动比如门店地址更新不再只是改页面里的几行文本而是改一条facts记录页面只是这些实体和事实的“视图”不是原始真相技术团队要具备“知识建模”的能力而不是只做 CMS 字段管理。从工程角度这就是把“内容工程”升级为“知识工程”。能力二检索层从单一倒排索引扩展为“向量 图 结构化”三合一1. SEO 工程中的检索习惯传统搜索实现里技术栈往往是分词 → 倒排索引 → BM25 / TF-IDF加一些业务规则贝叶斯排序、点击反馈、类目过滤。这套东西很好地解决了“关键词搜索网页”的问题但对 GEO 场景有两个明显局限对自然语言问题的语义理解有限对实体和关系的结构化查询能力弱。2. GEO 工程的检索架构要求在 GEO 场景里一条用户问题大致要经历三种检索语义检索向量对问题做 Embedding在向量数据库中检索语义相近的片段FAQ、场景描述、案例摘要。结构化检索实体/事实把问题映射到实体类型和属性条件“这家公司在东京有几家门店” →entity_type store,city Tokyo在实体表和事实表中做 SQL 查询和聚合。图检索关系对问题涉及的关系做扩展比如“这款产品适合什么场景”需要沿着product - scene关系走“这个城市有哪些服务形态”需要沿着city - store - service图谱查询。技术团队需要具备引入向量库pgvector / Milvus / FAISS 等的知识和实践为实体和关系设计图结构或类似能力图数据库或自建关系层用统一服务封装三种检索方式并根据问题类型选择组合语义检索 实体过滤实体检索 图关系扩展多路召回 统一打分。这不是“换一种搜索引擎”这么简单而是让检索层能同时处理语义、结构和关系这三种维度。能力三从“内容发布”到“信源治理 一致性检测”的工程能力1. 在 SEO 工程中“多发内容”被视为正向操作很多团队的 SEO 策略是不断生产文章、专题页、FAQ 页、案例页在不同栏目、语言、城市、渠道下复制和改写内容用“覆盖更多长尾”来提升整体流量。这种做法在搜索引擎只看页面时问题不那么直接暴露。但在生成式引擎里一致性问题会被放大。2. 在 GEO 场景里“多源矛盾”会直接破坏模型信任比如官网城市页写“东京有 3 家门店”旧文档里写“东京有 5 家门店”第三方平台上显示 4 家从技术角度看这是一组facts在不同source下出现了冲突。如果系统不做治理模型看到的就是一个“不可信的、混乱的信息集”。技术团队需要补上的工程能力包括多源采集 事实聚合不同来源的门店信息、品牌信息、产品信息汇总到entitiesfacts层每条事实带上source、source_type官方、第三方、用户、timestamp。规则或模型驱动的一致性检测定期或实时对同一实体的关键事实做比对检查数值差异、文本差异、状态差异把检测结果作为“问题记录”推给运营或数据治理团队。信源权重与可信度打分根据来源类型、更新频率、历史稳定性给事实打分高分事实进入“投喂集合”低分事实留在“待确认”区。这是把“谁说的算数”这件事工程化为信源治理和一致性检测而不再只是编辑和运营的手工判断。能力四引入“答案质量监控”和“认知占位评估”的工程体系1. 传统 SEO 的监控重心在“页面行为数据”日志和报表里常见的是PV、UV、跳出率、停留时间某个词的访问量和转化来源渠道自然搜索、投放、社交。这些数据对优化页面和漏斗很有价值但在 GEO 工程里还缺一个维度用户看到的生成式答案里你表现得怎么样2. GEO 工程需要的监控和评估指标技术团队需要能回答这些问题给定一组典型问题你的品牌/产品/门店在生成的答案里出现了多少次出现在哪个位置是主要推荐还是顺带一提模型对你的描述是否贴合内部标准版是否有明显错误或过时信息引入 GEO 中台之后这些指标是否发生改善要实现这些就需要在工程上补上几件事答案日志采集和结构化对内部 QA、对话系统、搜索系统的生成答案做采集抽取其中的实体、属性描述和引用链接按业务维度品牌、产品、城市、场景进行聚合统计。认知占位指标设计实体引用率某品牌在某类问题下被写入答案的比例位置权重在答案中的段落位置和语义角色主角/对比项/背景项描述一致性答案描述与内部标准知识的相似度。监控与告警当错误描述超过阈值时发出告警当重要实体长期在某类问题中缺席时发出告警。这些都是可以写进系统的而不是只能在复盘会上靠拍脑袋讨论。能力五把“上下文投喂策略”当成一等公民而不是临时逻辑1. 目前常见的做法是“随机拼上下文”很多团队在接大模型时是这么干的从知识库里随便拿几条 FAQ 拼进 prompt从数据库里查一点产品信息拼进 prompt觉得“能跑起来就行”投喂逻辑写在服务代码中没规范也没监控。这种方式在早期探索阶段可行但在 GEO 工程中会遇到几个问题上下文窗口有限乱拼容易把关键事实挤出去不同场景需要不同的上下文配方但代码里难以区分无法评估“哪种投喂策略效果更好”更谈不上持续优化。2. GEO 工程中的投喂策略需要工程化技术团队需要补上的能力是上下文策略抽象与配置化为不同场景定义上下文模板比如“产品问答”模板包含产品能力矩阵 常见限制条件 2 个典型案例“门店查询”模板包含城市信息 门店列表 营业时间 交通方式。把策略存成配置或策略表而不是硬编码在函数里。投喂流程编排在服务端建立“上下文构建管线”解析问题 → 识别场景和实体 → 调用 GEO 中台获取相关事实和 FAQ → 根据策略组装上下文 →送入模型。让每一步都有监控点有日志有可调参数。策略效果评估与 A/B 测试对比不同策略下的答案质量指标正确率、完整性、引用率基于数据选择更好的策略并将策略演化纳入迭代计划。这会把“如何跟模型说话”从“临时拼字符串”升级到“可复用、可版本控制、可持续改进的工程资产”。总结从 SEO 到 GEO是一次工程视角的升级不是简单改名从技术团队的角度看“从 SEO 工程到 GEO 工程”不是抛弃过去的经验而是把过去在索引、页面、日志上的成熟能力融入一套更完整的“知识工程 检索工程 生成工程”体系把页面当成知识的表现层而不是唯一的存储形态把检索从单一倒排索引扩展为“向量 图 结构化”的组合把内容从“只管发布”扩展到“还要治理信源、一致性和版本”把监控从“页面数据”扩展到“答案质量和认知占位”把与模型交互从“拼 prompt”扩展到“设计上下文投喂策略”。
一、从“页面工程”到“知识工程”技术对象变了传统 SEO 工程本质上是围绕“页面作为信息载体”做工程你优化的是 URL、HTML 结构、sitemap、robots、页面性能、内部链接、日志分析。生成式引擎优化GEO工程技术对象换成了“知识作为信息载体”你要处理的是实体、属性、关系、向量空间、知识图谱、上下文窗口、投喂策略、一致性和可信度。对技术团队来说差别可以概括成一句话从“让搜索引擎看懂页面”到“让大模型看懂你整套业务知识”。要完成这次升级技术栈本身可能差不多依然是数据库、检索引擎、服务端、API。但在工程能力上需要补上五个关键点。能力一数据层从“文章表”升级到“实体表 事实表 关系表”1. SEO 工程常见的数据设计很多传统内容系统的数据结构是这样的articles文章/页面表id,title,content,category_id,tags,created_at…categories分类表links外链/友链表再加点 PV 统计、评论表之类。这对“页面为核心”的 SEO 来说够用搜索引擎只需要识别页面结构和内容。2. GEO 工程的数据模型需求在 GEO 里生成式引擎关注的是实体和事实而不是只关心页面。技术团队需要引入几类新表结构entities实体表entity_id,entity_typebrand/product/store/city/faq/case…,name,aliases,status…facts事实表fact_id,entity_id,fact_typeaddress/capability/metric/scene…,value,source,source_type,confidence,valid_from,valid_to…relations关系表from_entity_id,to_entity_id,relation_typebrand-has-product, product-serves-scene, store-in-city……versions/audit_log版本与审计表谁改了什么事实、什么时候改、改前改后差异。这意味着小的业务改动比如门店地址更新不再只是改页面里的几行文本而是改一条facts记录页面只是这些实体和事实的“视图”不是原始真相技术团队要具备“知识建模”的能力而不是只做 CMS 字段管理。从工程角度这就是把“内容工程”升级为“知识工程”。能力二检索层从单一倒排索引扩展为“向量 图 结构化”三合一1. SEO 工程中的检索习惯传统搜索实现里技术栈往往是分词 → 倒排索引 → BM25 / TF-IDF加一些业务规则贝叶斯排序、点击反馈、类目过滤。这套东西很好地解决了“关键词搜索网页”的问题但对 GEO 场景有两个明显局限对自然语言问题的语义理解有限对实体和关系的结构化查询能力弱。2. GEO 工程的检索架构要求在 GEO 场景里一条用户问题大致要经历三种检索语义检索向量对问题做 Embedding在向量数据库中检索语义相近的片段FAQ、场景描述、案例摘要。结构化检索实体/事实把问题映射到实体类型和属性条件“这家公司在东京有几家门店” →entity_type store,city Tokyo在实体表和事实表中做 SQL 查询和聚合。图检索关系对问题涉及的关系做扩展比如“这款产品适合什么场景”需要沿着product - scene关系走“这个城市有哪些服务形态”需要沿着city - store - service图谱查询。技术团队需要具备引入向量库pgvector / Milvus / FAISS 等的知识和实践为实体和关系设计图结构或类似能力图数据库或自建关系层用统一服务封装三种检索方式并根据问题类型选择组合语义检索 实体过滤实体检索 图关系扩展多路召回 统一打分。这不是“换一种搜索引擎”这么简单而是让检索层能同时处理语义、结构和关系这三种维度。能力三从“内容发布”到“信源治理 一致性检测”的工程能力1. 在 SEO 工程中“多发内容”被视为正向操作很多团队的 SEO 策略是不断生产文章、专题页、FAQ 页、案例页在不同栏目、语言、城市、渠道下复制和改写内容用“覆盖更多长尾”来提升整体流量。这种做法在搜索引擎只看页面时问题不那么直接暴露。但在生成式引擎里一致性问题会被放大。2. 在 GEO 场景里“多源矛盾”会直接破坏模型信任比如官网城市页写“东京有 3 家门店”旧文档里写“东京有 5 家门店”第三方平台上显示 4 家从技术角度看这是一组facts在不同source下出现了冲突。如果系统不做治理模型看到的就是一个“不可信的、混乱的信息集”。技术团队需要补上的工程能力包括多源采集 事实聚合不同来源的门店信息、品牌信息、产品信息汇总到entitiesfacts层每条事实带上source、source_type官方、第三方、用户、timestamp。规则或模型驱动的一致性检测定期或实时对同一实体的关键事实做比对检查数值差异、文本差异、状态差异把检测结果作为“问题记录”推给运营或数据治理团队。信源权重与可信度打分根据来源类型、更新频率、历史稳定性给事实打分高分事实进入“投喂集合”低分事实留在“待确认”区。这是把“谁说的算数”这件事工程化为信源治理和一致性检测而不再只是编辑和运营的手工判断。能力四引入“答案质量监控”和“认知占位评估”的工程体系1. 传统 SEO 的监控重心在“页面行为数据”日志和报表里常见的是PV、UV、跳出率、停留时间某个词的访问量和转化来源渠道自然搜索、投放、社交。这些数据对优化页面和漏斗很有价值但在 GEO 工程里还缺一个维度用户看到的生成式答案里你表现得怎么样2. GEO 工程需要的监控和评估指标技术团队需要能回答这些问题给定一组典型问题你的品牌/产品/门店在生成的答案里出现了多少次出现在哪个位置是主要推荐还是顺带一提模型对你的描述是否贴合内部标准版是否有明显错误或过时信息引入 GEO 中台之后这些指标是否发生改善要实现这些就需要在工程上补上几件事答案日志采集和结构化对内部 QA、对话系统、搜索系统的生成答案做采集抽取其中的实体、属性描述和引用链接按业务维度品牌、产品、城市、场景进行聚合统计。认知占位指标设计实体引用率某品牌在某类问题下被写入答案的比例位置权重在答案中的段落位置和语义角色主角/对比项/背景项描述一致性答案描述与内部标准知识的相似度。监控与告警当错误描述超过阈值时发出告警当重要实体长期在某类问题中缺席时发出告警。这些都是可以写进系统的而不是只能在复盘会上靠拍脑袋讨论。能力五把“上下文投喂策略”当成一等公民而不是临时逻辑1. 目前常见的做法是“随机拼上下文”很多团队在接大模型时是这么干的从知识库里随便拿几条 FAQ 拼进 prompt从数据库里查一点产品信息拼进 prompt觉得“能跑起来就行”投喂逻辑写在服务代码中没规范也没监控。这种方式在早期探索阶段可行但在 GEO 工程中会遇到几个问题上下文窗口有限乱拼容易把关键事实挤出去不同场景需要不同的上下文配方但代码里难以区分无法评估“哪种投喂策略效果更好”更谈不上持续优化。2. GEO 工程中的投喂策略需要工程化技术团队需要补上的能力是上下文策略抽象与配置化为不同场景定义上下文模板比如“产品问答”模板包含产品能力矩阵 常见限制条件 2 个典型案例“门店查询”模板包含城市信息 门店列表 营业时间 交通方式。把策略存成配置或策略表而不是硬编码在函数里。投喂流程编排在服务端建立“上下文构建管线”解析问题 → 识别场景和实体 → 调用 GEO 中台获取相关事实和 FAQ → 根据策略组装上下文 →送入模型。让每一步都有监控点有日志有可调参数。策略效果评估与 A/B 测试对比不同策略下的答案质量指标正确率、完整性、引用率基于数据选择更好的策略并将策略演化纳入迭代计划。这会把“如何跟模型说话”从“临时拼字符串”升级到“可复用、可版本控制、可持续改进的工程资产”。总结从 SEO 到 GEO是一次工程视角的升级不是简单改名从技术团队的角度看“从 SEO 工程到 GEO 工程”不是抛弃过去的经验而是把过去在索引、页面、日志上的成熟能力融入一套更完整的“知识工程 检索工程 生成工程”体系把页面当成知识的表现层而不是唯一的存储形态把检索从单一倒排索引扩展为“向量 图 结构化”的组合把内容从“只管发布”扩展到“还要治理信源、一致性和版本”把监控从“页面数据”扩展到“答案质量和认知占位”把与模型交互从“拼 prompt”扩展到“设计上下文投喂策略”。
双梁正问题 【 torch 实战】（Python代码实现）)
