企业官网建设流程全解析

前面一篇文章里，我们讨论了 RAG 系统中的文档切分。

文档切分解决的是一个问题：如何把原始文档拆成适合检索和回答的语义单元。

但文档切好之后，还需要进入下一步：Embedding。

Embedding 的作用，是把用户问题和文档片段转换成向量，让系统可以在语义空间里比较它们之间的相关性。

很多 RAG 项目刚开始选 Embedding 模型时，会很自然地关注几个指标：

• 向量维度是多少。
• 榜单排名高不高。
• 模型参数量大不大。
• 是否支持中文。
• 价格贵不贵。

这些指标当然有参考价值。

但如果只看这些，很容易选错。

因为 RAG 里真正重要的不是“模型看起来强不强”，而是“它能不能在你的文档和你的问题上召回正确内容”。

Embedding 模型选得不合适，后面即使换更好的向量数据库、调更复杂的 Prompt、加更多 Rerank，也可能只是补救。

所以这篇文章想讨论一个更实际的问题：

在 RAG 系统里，Embedding 模型到底应该怎么选？

Embedding 在 RAG 里负责什么？

先把 Embedding 的位置放清楚。

一个基础 RAG 流程大概是：

用户问题 ↓ 问题 Embedding ↓ 向量检索 ↓ 召回文档片段 ↓ 大模型基于上下文生成答案

文档入库阶段也会用到 Embedding：

文档片段 ↓ 文档 Embedding ↓ 写入向量索引

所以 Embedding 模型负责把两类文本放到同一个向量空间里：

• 用户问题。
• 文档片段。

如果问题和文档语义相关，它们在向量空间里的距离应该更近。

比如：

用户问题：试用期员工能不能申请年假？ 文档片段：入职未满一年的员工，年休假按实际工作月份折算。

这两句话表面词汇不完全一致，但业务含义有关。一个合适的 Embedding 模型，应该尽量把它们匹配到一起。

再比如：

用户问题：生产环境数据库多久备份一次？ 文档片段：线上数据库每日凌晨执行全量备份，每小时执行增量备份。

这里“生产环境”和“线上”是近义表达，“多久备份一次”和“每日凌晨、每小时”也存在语义对应。

Embedding 模型的价值就在于捕捉这种语义相关性。

但要注意，Embedding 不是万能理解。

它不是业务规则引擎，也不是数据库查询语言，更不是最终答案生成器。

它主要解决的是：如何从大量文档片段中找到语义上可能相关的候选内容。

能不能最终答对，还要看文档切分、检索策略、Rerank、Prompt、引用和模型生成。

向量维度不是越高越好

很多人选 Embedding 模型时，会先看向量维度。

比如一个模型输出 768 维，另一个模型输出 1024 维，还有一个模型输出 3072 维。

直觉上，很容易觉得维度越高，信息表达能力越强，效果就越好。

但在实际 RAG 系统里，向量维度不能单独作为判断标准。

维度高可能带来更强的表达能力，但也可能带来更多成本。

比如：

• 存储空间更大。
• 向量索引占用更多内存。
• 检索计算成本更高。
• 索引构建速度更慢。
• 网络传输和持久化成本增加。

如果知识库规模很小，这些差异可能不明显。

但当文档片段数量达到几十万、几百万甚至更多时，向量维度会直接影响系统成本和性能。

更重要的是，维度高不代表一定更适合你的业务。

一个高维通用模型，在某些中文企业制度、技术文档、行业术语场景里，未必比一个更适配中文或领域文本的中等维度模型效果好。

所以看 Embedding 模型时，不要只问：

这个模型是多少维？

更应该问：

它在我的问题和文档上，能不能召回正确片段？ 在相同成本下，它的召回质量是否更好？ 它的速度和索引成本能不能接受？

向量维度是工程参数，不是质量保证。

中文效果要单独评估

如果知识库主要是中文文档，中文效果必须单独评估。

这点非常重要。

很多 Embedding 模型在英文语义匹配上表现很好，但在中文语境里未必稳定。

中文知识库有几个特点：

• 句子边界不总是清晰。
• 同义表达很多。
• 业务术语和口语表达差异大。
• 中英文混写很常见。
• 缩写、编号、产品名、部门名经常出现。

比如：

用户问题：还没转正能不能休年假？ 文档片段：试用期员工年休假按入职时间折算。

这里“还没转正”和“试用期”是业务上的近义表达。

如果 Embedding 模型对中文口语表达理解不好，就可能召回不到正确片段。

再比如：

用户问题：线上库备份策略是什么？ 文档片段：生产环境数据库采用每日全量备份和每小时增量备份。

“线上库”和“生产环境数据库”在技术团队里可能指同一类对象，但并不是完全相同的词。

这些都需要模型能理解中文语境和领域表达。

所以选择 Embedding 模型时，不要只看它是否“支持中文”。

支持中文只是最低要求。

更关键的是，它是否能在你的中文业务问题里召回正确内容。

通用模型和领域模型怎么取舍？

Embedding 模型大致可以分成两类：

• 通用 Embedding 模型。
• 面向特定领域或特定语料优化的 Embedding 模型。

通用模型的优势是适用范围广。

它通常能处理日常问答、普通文档、说明文本、FAQ、百科类内容。对于很多早期 RAG 系统来说，通用模型已经足够作为起点。

领域模型的优势是对特定语境更敏感。

比如法律、金融、医疗、代码、学术论文、企业内部技术文档等场景，通用模型可能无法很好理解专业术语和表达方式。

但领域模型也不是一定更好。

它可能在某个领域表现很好，但泛化能力弱；也可能对训练语料外的问题不稳定；还可能部署成本更高。

所以取舍时可以考虑：

• 文档是否有大量领域术语。
• 用户问题是否高度专业化。
• 通用模型是否经常召回错误内容。
• 领域模型是否真的在你的测试集上更好。
• 模型部署和调用成本是否可接受。

如果只是普通企业知识库、产品文档、制度问答、项目资料，通常可以先从成熟的通用中文或多语言 Embedding 模型开始。

如果测试发现大量专业问题召回失败，再考虑领域模型或微调方案。

不要一开始就为了“更专业”而引入复杂模型。

RAG 的工程原则是：先用简单可靠的方案跑通评测，再根据真实问题升级。

不同内容类型对 Embedding 的影响

真实知识库不是只有普通段落。

它可能包含：

• 中文制度说明。
• 英文技术文档。
• 中英文混合内容。
• 代码片段。
• 表格。
• 接口参数。
• 产品型号。
• 错误码。
• 合同条款。
• 操作流程。

不同内容类型对 Embedding 的要求不一样。

普通说明文本更依赖语义理解。

比如：

如何申请远程办公？ 远程办公申请流程是什么？

这类问题主要看语义相似。

但技术文档经常依赖精确匹配。

比如：

ERR_1024 是什么意思？ POST /orders 的 quantity 参数怎么填？ v2.3.1 是否支持批量导入？

这类问题里，错误码、接口路径、参数名、版本号非常关键。

单纯向量检索可能会把语义相似但编号不同的内容召回来。

比如用户问ERR_1024，系统却召回ERR_1025，从语义上看很接近，但业务上完全错误。

这时 Embedding 模型再好，也不一定适合单独承担检索任务。

需要配合关键词检索、metadata 过滤、Hybrid Search 或精确匹配策略。

所以评估 Embedding 时，也要区分文档类型。

不要只用自然语言问题测试，也要测试：

• 编号类问题。
• 代码类问题。
• 参数类问题。
• 表格字段类问题。
• 产品型号类问题。
• 缩写和别名问题。

如果你的知识库里这类内容很多，只看语义检索效果是不够的。

成本和速度不能忽略

Embedding 模型会出现在两个阶段。

第一个阶段是文档入库。

文档越多，切出来的 Chunk 越多，需要生成的向量就越多。

第二个阶段是用户提问。

每次用户提问，都要把 Query 转成向量，再进行检索。

所以 Embedding 的成本不是一次性的。

它会持续影响系统运行。

主要成本包括：

• 文档入库时的批量向量化成本。
• 增量文档更新时的向量化成本。
• 用户查询时的实时向量化延迟。
• 向量存储成本。
• 向量索引内存和计算成本。

如果 Embedding 调用很慢，用户每次提问都会被拖慢。

如果 Embedding 成本太高，知识库更新频繁时会带来明显开销。

如果向量维度很高，存储和检索成本也会上升。

所以模型选择不能只看质量，还要看工程约束。

一个实际可用的 Embedding 模型，需要在质量、成本、速度、稳定性之间平衡。

有些场景适合使用云服务 Embedding。

优点是接入简单、效果稳定、维护成本低。

有些场景适合本地部署 Embedding。

优点是数据更可控、批量处理成本可能更低、延迟更稳定。

具体怎么选，要看业务对成本、隐私、并发和部署复杂度的要求。

不要只靠公开榜单

公开榜单有参考价值，但不能替代自己的评测。

因为榜单测试集不一定和你的业务文档一致。

一个模型在公开数据集上表现很好，不代表它能处理你的内部制度、产品文档、接口说明、项目资料。

RAG 的 Embedding 评估应该尽量贴近真实场景。

一个简单可行的方法是构建小型测试集。

比如准备 50 到 200 个真实问题，每个问题标注应该召回的文档片段。

测试时关注：

• 正确片段是否出现在 Top1。
• 正确片段是否出现在 Top3。
• 正确片段是否出现在 Top5。
• 召回内容是否足够完整。
• 是否混入大量相似但错误的片段。

例如：

问题：试用期员工能不能申请年假？ 期望召回：员工手册 > 请假制度 > 年假规则

问题：ERR_1024 表示什么？ 期望召回：接口错误码说明 > ERR_1024

问题：生产环境数据库多久备份一次？ 期望召回：运维规范 > 数据库备份策略

有了这样的测试集，就可以对比不同 Embedding 模型。

如果一个模型在榜单上很强，但在你的测试集中经常召回错误文档，它就不是合适的选择。

反过来，一个模型榜单排名不是最高，但在你的业务场景里稳定召回正确内容，也可能更适合。

模型选择最终要回到业务数据。

评估时不要只看召回率

Embedding 评估当然要看召回率。

但只看召回率还不够。

因为 RAG 最终要回答问题，而不是只返回文档。

可以从几个角度综合判断。

第一，召回是否准确。

正确片段能不能进入 TopK。

第二，召回是否干净。

TopK 里是不是混入大量看起来相似但不相关的内容。

第三，召回是否完整。

一个问题是否需要多个 Chunk 才能回答完整。

第四，召回是否稳定。

同类问题换一种问法，是否还能召回正确内容。

第五，召回是否可解释。

开发者能不能理解为什么这个片段被召回。

第六，后续生成是否受益。

把召回结果交给模型后，最终答案是否更准确、更有依据。

所以 Embedding 评估最好不要只停留在向量检索层面。

更好的做法是把它放进完整 RAG 链路里测试。

也就是：

问题 ↓ Embedding ↓ Retriever ↓ Generator ↓ 最终答案

最终要看的是用户看到的答案有没有变好。

切换 Embedding 模型不是小改动

很多人会低估 Embedding 模型切换的影响。

在 RAG 系统里，文档向量和问题向量必须处在同一个向量空间。

如果你用模型 A 给文档生成向量，又用模型 B 给用户问题生成向量，它们之间的相似度通常没有意义。

即使两个模型输出维度一样，也不能直接混用。

所以一旦切换 Embedding 模型，通常意味着：

• 需要重新生成所有文档向量。
• 需要重建或更新向量索引。
• 需要重新评估召回效果。
• 需要重新检查 TopK、阈值、Rerank 策略。
• 可能需要重新调整切分策略。

如果知识库规模很大，这就是一个不小的迁移任务。

所以在项目早期选择 Embedding 模型时，不要太随意。

可以先用小规模数据做验证，再决定是否大规模入库。

如果系统需要支持模型切换，也应该在数据结构里记录：

embedding_model embedding_version embedding_dimension created_at

这样后续排查和迁移会清楚很多。

否则几个月后系统出现问题，很可能连某批向量到底是哪个模型生成的都说不清。

是否需要微调 Embedding？

有些团队会问：Embedding 效果不好，是不是要微调？

答案是：不一定。

在考虑微调之前，先检查几个更基础的问题。

第一，文档切分是否合理。

如果 Chunk 本身就破碎或混乱，微调 Embedding 也很难救。

第二，测试集是否真实。

如果没有真实问题和标注片段，就很难判断微调是否有效。

第三，是否需要 Hybrid Search。

很多编号、参数、代码、产品型号问题，不适合只靠向量检索。

第四，是否有足够高质量的训练数据。

微调不是把一堆文档丢进去就行，而是需要问题和正负样本。

第五，是否能维护微调后的模型。

模型更新、数据变化、评测回归、部署成本，都要考虑。

所以更稳妥的路径通常是：

先选成熟通用模型 ↓ 构建真实评测集 ↓ 优化文档切分和检索策略 ↓ 加入关键词检索和 Rerank ↓ 仍然无法满足时，再考虑微调

微调可以是后续选项，但不应该是第一反应。

一个实用的 Embedding 选择清单

实际选型时，可以用下面这份清单。

第一，语言是否匹配？

中文、英文、中英混合、代码、表格，是否都在测试范围内。

第二，领域是否匹配？

是否能理解业务术语、缩写、部门名、产品名、接口名。

第三，召回是否准确？

真实问题下，正确 Chunk 能否进入 TopK。

第四，召回是否稳定？

同一问题换不同问法，结果是否稳定。

第五，是否容易误召回？

相似流程、相似产品、相似编号是否容易混淆。

第六，成本是否可接受？

入库成本、查询成本、存储成本、索引成本是否可控。

第七，延迟是否可接受？

用户实时提问时，Embedding 调用是否会拖慢响应。

第八，部署方式是否合适？

云服务、本地部署、私有化部署，各自是否符合团队要求。

第九，模型切换是否有记录？

是否记录 embedding_model、version、dimension 等信息。

第十，是否经过完整链路验证？

不要只测向量相似度，要看最终答案质量。

这份清单比单纯看向量维度更有用。

总结

Embedding 是 RAG 系统里的基础能力，它决定了用户问题和文档片段能否在语义空间里正确匹配。

但 Embedding 模型不是越大越好，向量维度也不是越高越好。

真正重要的是，它能不能在你的文档、你的问题、你的业务表达里稳定召回正确内容。

选择 Embedding 模型时，需要同时考虑中文效果、领域术语、内容类型、召回质量、成本、速度、部署方式和后续迁移风险。

公开榜单可以参考，但不能替代真实业务评测。

最稳妥的方法，是用自己的文档和真实问题构建小型评测集，再对比不同模型的召回效果和最终回答质量。

同时要记住，切换 Embedding 模型不是简单换一个配置。

它通常意味着重新生成向量、重建索引、重新评测效果。

所以在 RAG 项目里，Embedding 选型要尽早认真做，但也不要过度迷信模型参数。

模型只是链路中的一环。

只有文档切分、Embedding、Retriever、Rerank、Prompt 和评测体系一起配合，RAG 才能从 Demo 走向真正可用。

下一篇文章，可以继续讨论向量数据库到底解决什么问题。

因为有了 Embedding 向量之后，我们还需要一个可靠的方式来存储、索引和检索这些向量。