企业官网建设流程全解析

从传统 SEO 转做 GEO（生成引擎优化）这一年多，我最大的感受是：以前我们研究怎么让爬虫读懂页面，现在研究的重心变成了怎么让大模型愿意引用你的品牌信息。而真正支撑起这件事的，不是靠堆文案，而是背后一套能把品牌知识结构化、检索出来、再喂给大模型的工程链路。这篇博文想聊的，就是如何从一条 RAG 管道出发，逐步构建出品牌知识图谱，并把它落地成一个可量化的 GEO 系统。内容会偏向架构设计、工程取舍和实践中踩过的坑，适合正在搭建品牌内容系统、知识中台或者 AI 搜索优化方案的技术同学参考。

很多团队做 GEO 还停留在“让 AI 工具提到你”的层面，做法是到处铺量、写问答式文章。但这种方式的问题很明显：大模型回答问题时，依赖的是检索到的知识片段是否完整、是否一致、是否来自可信来源。如果你的品牌信息散落在几百个页面里，互相之间还有矛盾，那模型引用的概率会非常低。我们做这套 GEO 系统的核心逻辑，就是先把品牌知识做成一张可推理的图谱，再用 RAG 的方式把图谱内容转化成模型友好的上下文，最终让 AI 搜索场景下的品牌可见度变成可计算、可优化的指标。

1. AI 搜索重新划重点：为什么品牌知识必须先“原子化”

在做系统之前，我们花了很长时间去理解一个问题：AI 搜索和传统搜索在“读”品牌信息时，到底有什么本质区别。传统搜索引擎的做法是建立倒排索引，把关键词映射到文档集合，然后靠链接和内容质量打分。AI 搜索不同，它先做意图理解，然后在一个或者多个信息库里检索相关片段，再把这些片段压缩成一段自然语言答案。这里面的关键点在于：模型不是“读完整页面的”，它读的是被检索出来的若干片段。

这意味着品牌信息必须足够碎片化、足够独立、足够自洽。我们内部管这个过程叫“品牌知识的原子化”。比如“某品牌成立于哪一年”“主打哪些产品线”“有什么核心技术优势”“创始人背景”等等，每一条信息都应该能独立拿出来回答问题，而不是藏在某段大段落的第三个句子里。

这个认知直接决定了系统的第一个设计原则：不做页面级别的采集入库，而是做实体级别的知识抽取与组织。

我们早期试过直接把优质页面整篇向量化存进向量库，结果很惨。大模型在回答“这个品牌和竞品有什么差异”时，由于每个页面的内容重心不同，检索到的片段可能是产品介绍、可能是企业文化、也可能是招聘信息，拼凑出来的答案根本不能用。后来换了路径，先做知识抽取，把页面内容拆成“实体—关系—属性”三元组，再以此为基础建设知识图谱。这个改动之后，检索的稳定性明显上来了。

具体落地时，我们把品牌知识分成了几个层次：

• 基础实体内核：品牌、产品、人物、组织、资质、专利、事件这些关键实体，每个实体有全局唯一的 ID 和标准属性。
• 事实关系层：实体之间的语义关系，比如“某产品是某品牌旗下产品”、“某品牌与某企业达成合作”、“某技术在某某领域取得突破”。
• 片段引用层：图谱中的每个实体和关系都保留对应的原文片段来源，确保生成答案时可追溯、可验证。

这里要特别提醒一句：知识图谱不是一个“建完就完”的东西，它的价值在于有人持续维护。我们后来引入了半自动更新机制，每两周跑一轮采集，把新增的新闻、公告、自媒体内容重新抽取、对齐、合并进图谱，才能保证 AI 搜索给出的答案不是停留在过去的旧信息。

2. 双路存储与一体检索：图谱和向量库缺一不可

系统建设到中后期，我们确定了“知识图谱 + 向量库”双路存储的架构。为什么不能只用一条路？这个问题我们在设计阶段反复权衡过。

如果只用知识图谱，所有问题都必须转化成图查询，例如“品牌有哪些产品线”“某产品属于哪个品牌”。这种形式适合结构清晰的事实型问题，但如果问题是“这个品牌在用户口碑方面表现如何”，需要先找到相关的口碑类文档，再判断情感倾向，图谱查询就没法直接处理了。

如果只用向量库，检索能力确实灵活，可以处理各种自然语言问法，但向量检索本质上是相似度匹配，它不理解实体之间的逻辑关系，会导致两个问题：一是语义相似的片段可能不是同一个实体上的事实，容易张冠李戴；二是缺少多跳推理能力，比如“A 品牌收购了 B 公司，B 旗下的产品叫什么”，这种依赖两步推理的问题，纯向量库很难答对。

所以我们最终的方案是两条路并行：

向量库负责初筛相关性，图谱负责精确约束和推理增强。

具体流程是这样的：

1. 用户提问进来后，先不用急着检索。我们先用一个轻量级的意图分类器判断这个问题是“事实型”“对比型”还是“开放型”。
2. 对事实型和对比型问题，先抽取问题中的实体和关系意图，拿到实体候选列表。然后在图谱上做子图召回，把相关实体、属性和关系路径全部取出来。
3. 对开放型问题，则先走向量检索，在文档片段库里拉到 Top-K 相关上下文。同时用图谱做一个语义约束：将向量检索到的片段里涉及的实体映射到图谱实体上，如果中出现明显的实体不一致，直接降权。
4. 最终把“图谱子图的序列化文本”和“向量召回的高相关片段”合并，重排后交给大模型生成答案。

这里有一个很关键的实现细节：**图谱子图怎么序列化成文本。**我们试过直接输出三元组列表，比如“品牌A——收购——公司B；公司B——拥有——产品C”，模型能看懂，但这是“读代码”的模式，生成效果不够自然。后来我们改成把每个子图渲染成一小段带上下文的句子，再拼进 Prompt。比如同样这条知识，渲染成：“品牌 A 在 2023 年完成了对 B 公司的收购，B 公司的主打产品是 C。这次收购让品牌 A 进入了 XX 市场。”这样给到大模型的文本是连贯的叙述，生成出来的回答质量直接上升了一个台阶。

向量库方面我们用的是主流的 Embedding 模型加向量数据库组合。这里有一件事必须强调：**不要把品牌资料文档和通用文档混在一个向量库的同一个集合里。**品牌文档有很强的实体中心性，混在一起后召回的精度会下降得很厉害。我们是按品牌、按内容类型建了多个 Collection，并且给每个 Collection 挂了独立的元数据过滤条件。成本高一点，但换来的是召回精度的可控性。

3. 品牌知识图谱的冷启动：从零到一千个实体的工程路线

很多团队看到知识图谱的第一反应是“我该用什么图数据库”。我们走完整个流程后想说：图数据库只是最后一步，真正的难点在前面，在于怎么把一堆非结构化内容变成图谱里的实体和关系。

冷启动阶段我们的原始数据来自几个渠道：官网页面、行业媒体文章、企业公告、半结构化的数据库导出。前两类是纯文本，后一类相对规整。建图谱的工程路线大致分了五步。

第一步是实体抽取。我们用了传统的 NER 加规则兜底的模式。传统 NER 负责识别人名、组织名、产品名、地名，规则负责识别我们非常明确的品牌词库和产品词库。因为品牌领域有很强的专名特征，单纯依赖通用 NER 会漏掉很多特定产品型号，比如“某某安全网关”这种词，通用模型大概率只会抽到“安全网关”。所以必须叠加一个业务词表。

第二步是实体对齐与消歧。这一步是坑最多的地方。同一个品牌在不同来源里可能叫“某某集团股份有限公司”“某某集团”或者简称“某某”，还有输入来源里的 OCR 错误和其他变体。我们当时的做法是：先做标准化清洗，把全称后缀、中间空格、标点符号统一处理；再用别名表收录常见简称；最后做基于上下文向量的聚类，把相似实体归并到一起。这一步必须留人审，纯自动消歧只能做到 80% 的准确率，涉及大额投资关系、母子公司归属这些问题，错一个后面都会跟着错。

第三步是关系抽取。我们采用了两条腿走路：规则模板负责高置信度的关系，比如收购、成立、任职、股权占比，这类关系在文本里往往有固定的动词模式；对于更开放的关系，比如“合作”“竞争”“支持”，则用大模型的零样本能力来标注，然后过人工抽检。

第四步是属性补全。实体和关系搭完之后，很多属性是缺失的。我们日常维护中发现，单纯靠抽取拿到的属性覆盖度大概只有 60% 左右。所以又加了一个专门跑属性提取的管道，针对“成立时间”“总部地址”“创始人”“员工规模”这几类高频属性做针对性抽取。

第五步是把图谱数据导入图数据库，同时同步构建图谱的应用索引，包含实体 ID 到文档片段的映射、实体别名表、层级关系路径等。这一步相对简单，但有个运维层面的提醒：图数据库的存储成本不低，如果品牌量非常大，可以考虑按品牌分库或者分图，避免一次查询扫描全图。

冷启动会花多长时间？我们第一批做的是三个品牌的图谱，大概两万份文档，用了三周左右，其中大量时间花在实体对齐和人工审核上。如果只用全自动抽取，三天就能跑完，但可信度没法保证。这个时间成本必须在项目开始前就让业务方有心理预期。

4. 检索增强生成链路里那些容易翻车的细节

当图谱和向量库都准备就绪后，RAG 管道本身就成了决定最终 GEO 效果的主战场。我们在真实场景里跑了几轮之后，发现大多数问题并不出在模型能力上，而是出在检索和上下文组装这些看起来“很琐碎”的地方。

第一个翻车点是检索时机混为一谈。一开始我们贪图简单，把所有背景知识不分青红皂白全部塞进 Prompt，结果模型生成的内容被大量无关信息干扰，有时候甚至会张冠李戴。后来给出的方案是做一个分层策略：先跑一个意图识别，如果用户问的是产品对比，就只提供给图谱中与这些产品相关的子图；如果问的是品牌发展历程，再切换到时间线属性和大事记片段。把不必要的知识挡在 Prompt 外面，效果比模型本身的能力差异还大。

第二个翻车点是上下文长度分配不合理。大模型的上下文窗口是有限的，如果把一段 2000 字的长文完整塞进去，留给模型的“思考冗余”就没了。我们当时做了个简单的切分策略：图谱序列化文本控制在 800 字左右，向量召回片段按段落切分，每段不超过 500 字，最多取 4 段。加上 Prompt 的固定指令，整体控制在 2500 字以内。实测下来，2500 字是一个性价比比较高的区间，太长则生成速度变慢且容易跑偏，太短则信息量不足。

第三个翻车点是答案的可信度无法验证。RAG 最大的优势是能给出有来源的答案，但这个优势需要显式设计。我们在生成阶段强制模型输出引用来源标识，也就是每说一个事实，后面跟上片段来源的编号。然后在下游做一层校验，把模型声称的来源编号和实际传入的检索片段做一致性比对，如果模型说了一个不在检索片段里的来源，这条答案会被标记为低置信度，不进 GEO 统计。

第四个翻车点是多轮对话中的实体继承。用户在 AI 搜索场景下经常连续追问，比如先问“这个品牌做过什么融资”，再问“最近一轮是谁投的”。第二问里没有出现品牌名，如果系统不做指代消解，第二轮就检索不到正确实体。我们的做法是在第一轮生成时把识别到的实体 ID 缓存到会话状态里，后面几轮如果检测到问题里没有明显的品牌实体，就自动沿用上一轮的实体作用域。这个小机制解决了很多体验问题。

第五个翻车点比较隐蔽，是图谱直连生成导致的信息过时。图谱里的数据更新频率低于新闻页面，如果你在检索时只看图谱，会错过很多新信息。我们在管道里做了一个“新鲜度加权”逻辑：对于时间属性敏感的问题，比如“最新动态”“最近新闻”，强制加入实时检索结果，而不是只依赖图谱。

5. 让 GEO 效果可量化：覆盖度、一致性与引用率

做系统做久了就会发现，凡是不能量化的优化，最后都会变成玄学。GEO 系统的效果到底好不好，不能只看品牌在某个 AI 搜索里是否被提到，因为那只是一个抽样结果。我们设计了一套内部评估框架，围绕三个核心指标。

第一个指标叫“知识覆盖度”。我们把用户关心的品牌问题整理成一组标准问句集，大约几百条，分为产品类、公司类、技术类、口碑类。每次系统更新后，用这套问句集跑一遍全流程，统计有多少比例的问题能从图谱或文档库中检索出有效答案。覆盖度低于 90% 的实体，我们会进入待补全列表。这个指标直接反映品牌知识库的完整程度。

第二个指标叫“回答一致性”。同一组问题，我们会在不同时间点多次提问，看系统给出的答案在关键事实上是否一致。比如“某产品支持哪些协议”这个问题，如果第一次答了支持三种协议，第二次答了五种，那说明知识库里很可能有冲突信息或者图谱更新逻辑出了问题。我们内部用 JSON 抽取关键事实字段，做自动比对，低于 80% 一致性的问题会进入人工复核流程。

第三个指标也是业务最关心的，叫“引用率”。在真实 AI 搜索引擎或问答产品中，品牌被引用的次数与总相关问题的比例。这部分需要对接搜索平台的数据回传逻辑。我们没有能力拿到所有平台的全量数据，但能接入的几个核心渠道已经足够看出趋势。引用率提升之后，我们会反向回归到知识图谱里，看看是哪几次知识补全带来的提升。这种归因分析做多了之后，内容团队就有了明确的方向：不是拍脑袋写文章，而是看图谱里哪些实体问得多、覆盖低、引用少，就优先补哪些。

这套指标跑了一段时间后，业务侧最直观的感受是“运营动作变得有依据了”。以前说“我们要提高品牌在 AI 搜索里的声量”，大家各说各话，现在变成了一张清单：哪些实体缺知识、哪些关系没建立、哪些历史信息已经过时，全部清清楚楚列在板上。

这里我特别想分享一个认知：GEO 优化本质上是一件“内容工程”的事，不是“投词”的事。传统 SEO 的核心是关键词布局，GEO 的核心是让模型觉得你的知识更完整、更可信、更一致。而知识图谱加 RAG 的组合，恰好是建立这种信任的底层基础设施。跟着热词去改文案是短期行为，把品牌知识体系真正建起来才是长期壁垒。

6. 工程化落地中的维护机制与团队分工

最后聊一聊可持续运行的问题。任何一个系统，上线第一天都是最好用的，后面如果不维护，三天就会腐化。GEO 系统里知识图谱的维护尤其明显，因为品牌是活的：新产品在发、高管在变动、合作在不断谈成，这些信息如果不能及时进图谱，RAG 管道再先进都没用。

我们的维护机制分成了三个层面。

数据层面，每个品牌对应一个采集源列表，定时跑采集任务，发现新内容后自动抽取并进入待审核队列。这一步全自动化，不需要人盯。

质量层面，设了一个“知识运营”角色，日常工作就是看待审核队列、看一致性报告、处理各类实体冲突报警。这个角色不需要深度算法背景，但需要对品牌和行业有足够的判断力。区别在于：算法只能告诉你这两个实体相似度很高，但能不能合并，需要人来拍板。

效果层面，每两周做一次问句集回归测试，用上面的三项指标检查系统老化和更新情况。如果有指标大幅下滑，立刻回看数据管道，定位是采集源问题、抽取问题还是图谱结构问题。

研发团队和知识运营团队的工作流大概是这样的：研发负责搭管道、调检索、修指标，知识运营负责往管道里注入行业知识和判断逻辑。这个分工如果能跑顺，系统的迭代速度会非常快。我们最快的一次从发现“某品牌缺一个实体关系”到知识入库再到指标回升，只用了三天。

过程中也有一些意外的收获。比如内容生产团队后来直接接入了知识图谱的数据导出功能，写新品介绍或者品牌故事时，直接在后台看图谱里的实体和关系图谱，真正做到了“写之前先看知识地图”，避免重复写已知信息，也避免写出和已有知识矛盾的内容。这样一来，内容团队也从“自由创作”变成了“有约束的专业创作”，产出质量的方差小了很多。

如果你也在计划做类似的 GEO 系统，我给到的核心建议只有一条：不要把精力全部砸在模型 Prompt 上，真正的瓶颈永远是“你有哪些高质量知识、能不能快速找回来、能不能保持一致”。先把知识库的骨架搭好，再去追求花哨的生成效果。这样跑出来的系统，才是能跟着业务一起活的系统。