企业官网建设流程全解析

某品牌方上半年找到我做一套品牌内容智能化系统，内部代号叫微三云 GEO，核心链路一开始就是大家熟悉的 RAG：文档解析、切片、向量化、召回、拼接、生成。但真正压测完一批真实问题后，我们被迫把架构从“RAG 链路”硬生生升级成了“品牌知识图谱 + 图增强生成”的混合体系。这篇文章就把这段从 RAG 到品牌知识图谱的技术架构演进、工程实现细节、参数调优过程，以及那些文档里不会写的坑，完整复盘一遍。

这套系统面向的是品牌方的多场景问答需求，包括产品推荐、成分解释、功效查询、搭配禁忌、资质溯源等。适合做搜索、问答、知识中台、AI 客服的工程师参考，也适合产品经理理解为什么“普通 RAG 不够用、知识图谱补在哪”。全文以项目实操为主，不堆概念，尽量给到可以直接抄作业的参数和思路。

1. 为什么传统 RAG 链路撑不住品牌问答场景

1.1 chunk 化拆掉了文档里最值钱的关系

传统 RAG 的第一步是把文档按段落或固定窗口切块，然后做向量化。问题是品牌类文档里，信息是高度分散的。比如一款精华产品，它的成分列表在第 2 页，功效宣称在第 5 页，适用人群和禁忌在第 8 页，而“烟酰胺浓度超过 5% 可能刺激敏感肌”这个关键结论又埋在第 12 页的 FAQ 里。

当你把这些内容分别切成多个 chunk 后，每个块之间在向量空间里可能相距很远。用户问“敏感肌能用这款精华吗”，向量检索大概率只能召回“适用人群：敏感肌慎用”那一段，但这一段没有说清楚“为什么慎用”，也没有关联“烟酰胺浓度”这个成分信息。这就是传统 RAG 的第一个硬伤：它擅长找段落，不擅长拼逻辑。

我见过很多团队在这个问题上硬扛，靠调 embedding 模型、调 chunk 重叠率、加 rerank，效果有提升但天花板很低。因为问题的本质不是段落切得不好，而是知识本身的组织结构是图状的，用线性的文本块去承载，天然会丢失关系。

1.2 向量召回只懂“像不像”，不懂“对不对”

第二个硬伤是召回逻辑。向量召回本质上是在做语义相似度匹配，它回答的是“这段话和用户问题像不像”，而不是“这段话是不是这个问题需要的证据”。

举个例子，用户问“A 精华和 B 面霜能叠涂吗”，传统 RAG 的做法是把问题向量化，去库里找最相似的段落。如果库里有一篇文章标题是“A 精华叠涂指南”，里面正好引入了 B 面霜的某段描述，那就可能召回。但如果没有一篇文章恰好同时讲这两个产品，问题就悬空了。而这个问题在知识图谱里是有确定答案路径的：A 精华 → 含有 → 某成分；B 面霜 → 含有 → 某成分；某成分 → 相互作用 → 某成分。只要图谱里有关系，多跳路径就能算出来。

品牌场景里这类“跨文档、跨实体”的问题特别多，因为用户不是按文档结构提问的，用户是按自己的需求提问的。向量召回天然缺失这种结构化推理能力。

1.3 多跳推理和一致性维护是传统 RAG 的硬天花板

除了召回问题，生成端的幻觉也绕不开。传统 RAG 给了 LLM 一堆 chunk 文本，LLM 在拼接这些片段生成答案时，很容易把 A 文档里“成分 X 有美白功效”的结论安到 B 产品头上，因为两个 chunk 都在上下文里，模型分不清哪个结论对应哪个产品。

多跳推理更明显。用户问“干皮、黄皮、想美白，推荐一套不超过 500 元的产品组合”，需要的推理路径是：找产品 → 匹配适用人群（干皮） → 匹配功效（美白） → 匹配价格区间 → 组合成套。如果你给 LLM 的不是结构化的、带关系的候选集合，而是一堆文本片段，它只能靠猜。

这也是我们做品牌知识图谱的核心动机：把散落在文档里的实体、属性、关系结构化存下来，让检索链路从“找文本”升级为“找证据路径”，让生成端拿到的是可校验、可追责的知识结构。

2. GEO 系统的整体设计思路与模块拆解

2.1 从数据接入开始的统一 ID 体系

GEO 系统的数据源很杂：产品官网详情页、PDF 产品手册、天猫详情页文案、客服对话记录、社媒评论、内部培训资料。第一阶段的脏数据数量级大概在 1400 份文档、6 万条客服对话。

我的建议是：在没做任何抽取之前，先建立统一 ID 体系。每一款单品必须有 SKU 级 ID，每一个成分尽量映射到标准名和 CAS 号（如果有的话），每一类文档段落定义 doc_id + block_id。没有这个底座，后面做实体链接一定会乱套。

统一 ID 体系还解决了别名问题。品牌方内部叫“小白瓶”，官网上写“光感精华”，客服聊天里说“小灯泡”，这三个词如果不对齐到同一个产品实体，图谱里就会出现三个节点，检索时漏召回。我们当时的做法是建了一张别名表，由运营团队维护，每周批量导入一次，抽取时先做指代消解。

2.2 品牌知识图谱的 Schema 设计：克制是第一原则

图谱设计的核心不是“越全越好”，而是“够用且不膨胀”。我们第一版 Schema 定了 7 类实体节点、9 种关系，运行一个月后稳定下来，后期几乎没有大改。

实体类型包括：品牌、产品线、单品、成分、功效、适用人群、场景、认证资质。关系类型如下表所示：

设计原则有三条，都是踩坑换来的。第一，关系方向全局唯一，比如“含有”只能从单品指向成分，不能在另一处反向建“被含有”，否则图查询会写出两套逻辑。第二，实体属性允许冗余，比如把“规格、价格、上市时间”直接放在单品节点上，而不是单独建属性节点，减少多跳 join 开销。第三，控制图谱深度，我们刻意没有建“成分-成分-功效”这种无限深度的网络，关系最远只到两跳，因为两跳以上的路径对回答问题的置信度影响已经很低。

2.3 知识抽取与图谱构建流水线：LLM 为主、规则为辅

知识抽取是图谱建设里工作量最大的模块，没有之一。我们采用的是“LLM 抽取 + 规则校验 + 人工抽检”三层流水线。

LLM 抽取：我们调用具备结构化输出能力的 LLM，输入文档片段和固定 JSON Schema，返回实体、关系、属性三元组。比如输入“XX 精华含有 5% 烟酰胺，适合油皮使用”，抽取结果为：单品 实体（XX精华） + 含有 + 成分实体（烟酰胺，浓度=5%）；单品 + 适用 + 人群实体（油皮）。抽取 prompt 里我建议把关系类型枚举和字段定义写死，让模型做“填空”而不是“自由发挥”，明显降低幻觉。

规则校验是很多人忽略的环节。我们写了几十条校验规则：实体类型必须在白名单内、浓度字段必须是数字、关系方向必须符合 Schema 定义、同一条三元组重复出现时保留置信度高的那条。规则校验完之后，还有一个人工抽检流程，每周抽 5% 的新增三元组给业务方审核，主要是看关系语义对不对。比如“烟酰胺 具有 美白”算对，“烟酰胺 适用 干皮”这种就不太对，因为成分本身不直接声明肤质适用性，这属于产品宣称层面的关系，容易抽错。

增量更新方面，我们做了文档版本号机制。新版本文档进入管道后，会带上 version 标记，旧版本的图谱三元组自动标记为过期，不会被检索链路使用。这个机制在后面踩坑部分非常重要，旧数据不失效的问题差点把整个系统拖垮。

3. 图增强检索与生成链路：GraphRAG 的关键实现

3.1 双通道召回：向量通道和图谱通道各司其职

GEO 系统的检索层从“单通道向量召回”改成了“双通道召回 + 融合排序”，后面又加了一个轻量关键词通道兜底。

向量通道做的事和传统 RAG 一样，负责找“语义相似的文本块”，给生成端提供证据原文。图谱通道做的事是：先用实体识别模块从用户问题里抽出实体，比如“敏感肌”匹配到适用人群节点、“精华”匹配到产品线节点，然后从这些节点出发做图遍历，找回关联的单品候选集合，再为每个候选单品抓取它关联的成分、功效、禁忌等图上下文。

举个例子，用户问“敏感肌适合什么精华”，图谱通道会这样工作：定位“敏感肌”人群节点 → 沿“适用”方向反向查找所有单品 → 过滤掉那些“慎用”关系指向敏感肌的单品 → 再沿“属于”关系把这些单品归到“精华”产品线 → 输出候选产品列表及其功效、成分摘要。这个过程中，图谱回答的是“哪些产品在逻辑上满足约束”，向量回答的是“用户这句话具体在上下文里的证据是什么”，两边的产出完全不同，但正好互补。

关键词通道的标准做法是基于倒排索引做 BM25 召回，主要解决图谱里还没有覆盖到的长尾实体名称匹配。很多品牌方新上线的产品，文档都还没做图谱抽取，用户就提问了，这时候关键词通道能兜底召回原始文档，不至于完全答不上来。

3.2 子图裁剪与上下文组装：不能把整个图谱都塞给大模型

构建了图谱之后，最容易犯的错误就是“把所有关联数据都塞进上下文”。一开始我们踩过这个坑，把一个单品的完整子图序列化出来，包含几十个属性和几十条关系，直接导致 token 暴涨，而且 LLM 面对过载信息反而更容易胡编。

后来的做法是子图裁剪 + 证据片段组合。

子图裁剪三个规则：

• 深度限制：从种子实体出发，只向外扩展两跳，两跳之外全部丢弃。
• 方向过滤：根据问题类型过滤关系方向。比如用户问“功效”类问题，只保留含有、具有、宣称这三类关系；问“搭配”类问题，只保留相关关系。
• 置信度过滤：实体识别的置信度低于 0.7 的节点不参与扩展。

上下文组装格式每一条关系都带上原始文档的 doc_id 和 block_id，让生成端可以精确引用。实体属性只保留用户问题涉及到的字段，比如问美白就带功效和成分浓度，不把价格、规格、上市时间全部塞进去。这个步骤对最终答案质量的提升非常明显，上下文更精简，LLM 的注意力反而更聚焦。

3.3 生成侧 Prompt 约束与可溯源答问策略

生成端我们采用的是“可信上下文 + 强约束指令 + 自校验”三层保障。

可信上下文就是上面组装好的结构化三元组 + 证据片段。强约束指令的核心内容可以概括为：只能基于上下文回答；每个结论必须标注引用编号；上下文找不到答案时明确说不清楚，不要编造；涉及产品对比时，对比维度必须来自实体属性表。

自校验环节很多人不做，但我觉得非常值得。生成结束后，我们用一个校验 LLM 对生成答案做二次检查：答案中出现的所有产品名是否都在上下文的实体列表里、所有功效宣称是否都能在上下文里找到对应关系、如果答案里出现上下文中不存在的属性值，一律标记为疑似幻觉，打回重新生成。这层校验我们内部叫“证据回扣”，它能过滤掉大概 15% 左右的模型幻觉。

可溯源答问策略是最贴近业务需求的一点。品牌方特别在意“这个答案有没有依据”，所以问答前端每个答案底下都会展示“参考来源”，展开后能看到图谱路径和原始文档片段。这不仅是合规要求，也是用户信任系统的基础。没有溯源链路的 AI 客服，在品牌方眼里基本等于不可用。

4. 工程落地选型与关键参数调优实录

4.1 基础设施选型：图数据库、向量库、抽取与调度

图谱存储我们选的是 Neo4j，主要看重它的 Cypher 查询生态、事务能力和社区可视化工具。品牌知识图谱的规模并不大，节点 30 万左右、关系 200 万左右，单机就能扛住。选型前我也测过更轻量的方案，但查询复杂度和运维成本反而更高，Neo4j 对这个体量是最省心的。

向量库我们用了 Milvus，embedding 维度 768，索引类型 HNSW，M=16，efConstruction=200。这个配置在单机 16GB 内存下可以稳定支撑千万级向量的近实时检索。

知识抽取任务走的是异步管道，每天凌晨由 Airflow 调度跑一次，全量增量数据大约 2 小时跑完。LLM 抽取部分我们最初调的是商用 API，成本太高后改为自部署开源模型做批量抽取，配合规则校验，效果损失不大但成本降到原来的十分之一。

4.2 关键参数调优：Top-K、跳数、融合权重、上下文上限

参数调优这块直接给结果。检索链路的完整参数如下表：

这里重点说三个参数。第一个是向量 Top_K。品牌问答不像通用域问答，一个产品问题往往需要同时看三到五段不同来源的文本才能拼出完整答案，所以 Top_K 不能太小。我们试过 10，明显漏召回，调到 30 后覆盖率大幅提升，再往上收益递减且延迟变高。

第二个是图谱扩展跳数。第一版我们设成 3，结果“敏感肌”节点出发可以经过“适用人群 → 单品 → 成分 → 功效”一路延伸到几十个节点，上下文里堆满不相关功效，答案是“什么都说了但什么都没说清”。砍到 2 跳后，候选子图精确很多。

第三个是 RRF 融合权重。向量分数和图谱分数量纲不同，直接相加没有意义。我们用 RRF 方式归一化后做过一组 A/B，在品牌问题上把权重从 0.5:0.5 调到 0.4:0.4:0.2，多跳问题的精度提升了约 12%，单跳问题基本不变。这说明图谱通道解决的是增量问题，向量通道负责兜底泛化，各司其职最好。

4.3 评测集构建与线上 A/B 效果对比

没有评测集就不能调参，这是我们项目前期血泪教训。我们最终建的评测集有 400 道题，按难度分层：单跳事实题 60%、多跳关系题 25%、对比和负面约束题 10%、非品牌相关拒答题 5%。

评测指标不只看答案相关性，还加了三个指标：忠实度（答案是否完全来自上下文）、图谱覆盖率（答案涉及实体是否存在图谱节点）、溯源正确率（标注的引用是否真的支持结论）。

改造前后的效果对比：

多跳问题和拒答能力的提升是最明显的，这说明图谱给模型的不是“更多文本”，而是“更精确的推理路径”。溯源正确率从 61% 拉到 88%，对品牌方这类强信任行业来说，是上线的硬门槛。

5. 踩过的坑与排查思路实录

5.1 Schema 设计太窄导致“新问题没人能答”

第一版 Schema 只覆盖了“单品-成分-功效”这个核心三角，完全没建模“使用场景”和“认证资质”。上线后用户问“适合什么场合用”“有没有有机认证”直接崩掉，因为图谱通道根本走不出路径，只能靠向量通道碰运气召回文本。

排查思路：遇到一类问题整体答不好，第一时间检查是不是 Schema 缺实体或关系类型，而不是盲目调 embedding 或加样本。我们补上了“使用场景”实体和“认证”关系后，这两类问题立刻从不可答变成可答。

5.2 关系方向定义混乱，图越建越乱

项目中期我们发现图谱里“含有”和“被含有”、“适用于”和“适合”这种方向或语义相近的关系同时存在，导致 Cypher 查询到处写 UNION、子查询巨复杂，效果还差。

解决方法：一次性强制归一关系方向，全局只保留“单品 → 成分”方向的“含有”，删除所有反向关系；删除语义重复的“适合”关系家族，统一用“适用/慎用”两种。恢复数据后，查询速度提升明显，召回稳定性也提高了。

5.3 新旧数据打架：旧产品反复出现在答案里

最严重的一次线上事故，是一个已停产三个月的旧款精华，因为旧文档仍被检索到，AI 客服一直在推荐它。品牌方差点直接叫停项目。

排查后确认是图谱更新链路缺失“失效”机制。后来做了两个改动：第一，文档版本化，旧版本的三元组全部标记过期并在检索时过滤；第二，单品节点的“在售状态”属性由业务系统定时同步。从那之后，这类问题再没复发。

5.4 混合检索排序“打架”，召回了但排不上去

图谱通道和向量通道各自召回的结果集重合度不高，但排序分数没法直接比较。初期我们直接相加，图谱强相关的产品因为文本相似度低排到了后面，导致答案经常“没错但不够准”。

换了 RRF 融合后问题基本解决。RRF 不依赖绝对值，只依赖排名位置，两个通道都能稳定贡献高排名的结果，直接在融合层强强联合。

5.5 上下文序列化过长导致幻觉率飙升

生成端一次塞入大量序列化三元组时，模型胡编的概率显著上升。我们后来把上下文裁剪和属性筛选取代了“全量提供”，幻觉率明显下降。这个小节的经验在于：给 LLM 的知识不是越多越好，而是越“可定位”越好。

下面整理一份常见问题速查表：

6. 扩展方向与个人体会

这套系统从纯 RAG 到图谱增强，我最大的体会是：品牌知识图谱真正的价值不只是提升问答准确率，而是把品牌方的知识资产变成了可维护、可审计、可复用的结构化数据。图谱建好之后，不仅能喂问答系统，还能做竞品对比、内容生成、行业分析、导购推荐，甚至反哺产品文档的标准化建设。

我在实际推进中还有几个建议：第一，不要一上来就追求全量数据铺开，先挑 30 个核心单品跑通链路，拿到业务方认可再扩大；第二，图谱 Schema 要经历一个“做减法”的过程，前期丰富后期克制，最终留下的关系一定是业务验证过的；第三，评测集必须跟着业务走，每季度根据真实客服记录补充新的长尾问题，防止模型过拟合到旧评测集上。

如果后续继续演进，我比较看好两个方向：一是把用户实时行为数据引入图谱做个性化推荐，二是把这套 Schema 扩展到多语言站点做全球品牌知识统一管理。核心思路不会变：先确定实体和关系，再谈检索与生成。