第 2.3.2 节:把 Embedding 和向量索引接入召回链路
Embedding 和向量索引只有拆成可执行步骤,才容易复核、排错和交接。完成本节后,你应该能够按顺序说明 Embedding 和向量索引的触发、处理、复核、记录和兜底步骤。
核心概念(四层解释法)
下面这些概念会反复出现在 RAG(检索增强生成)项目中。本章按四层解释:人话解释、项目位置、工程动作、面试说法。
文档分块
文档分块 是把原始文档切成适合检索的小片段。分块不是简单切字数,而是决定模型未来能看到什么上下文。
| 层级 | 解释 |
|---|---|
| 人话解释 | 把一份长文档拆成一张张“知识卡片”。每张卡片要足够短,方便检索;也要足够完整,不能把条件和结论拆开。 |
| 项目位置 | 客服知识库导入时,售后政策、产品手册、FAQ(常见问题)和 SOP(标准作业流程)都会先被解析,再分成可检索片段。 |
| 工程动作 | 设计分块规则、重叠范围、标题路径、表格保留方式、问答对切分方式和片段编号。 |
| 面试说法 | 分块质量直接影响召回质量。分块太大噪声多,太小上下文断裂,所以我会按文档结构切分,并保留标题、版本和引用位置。 |
Embedding(嵌入向量)
Embedding(嵌入向量) 是把文本转成一组数字表示,让系统可以计算语义相似度。
| 层级 | 解释 |
|---|---|
| 人话解释 | 它像给每段知识做语义坐标。意思相近的文本在坐标空间里距离更近。 |
| 项目位置 | 每个知识片段都会生成 Embedding(嵌入向量),用户问题也会生成 Embedding(嵌入向量),系统用它们寻找语义相近的片段。 |
| 工程动作 | 选择嵌入模型,记录模型版本,处理重新生成向量的任务,评估中英文、行业词和短问句效果。 |
| 面试说法 | Embedding(嵌入向量)解决语义召回,不解决权限、版本、精确规则和业务判断,所以必须配合元数据过滤、重排和评估样例。 |
向量索引
向量索引 是让系统快速从大量向量中找相似片段的检索结构。
| 层级 | 解释 |
|---|---|
| 人话解释 | 如果没有索引,每次都要把问题和所有片段逐个比较;有了索引,就像给语义空间建了导航系统。 |
| 项目位置 | 客服知识库的所有已发布片段会写入向量数据库或支持向量检索的数据库扩展,供问答和工单辅助使用。 |
| 工程动作 | 选择向量数据库,设置索引策略,规划增量更新、删除、版本切换、租户隔离和查询延迟目标。 |
| 面试说法 | 向量索引要在召回率、延迟、成本和更新频率之间取舍。业务上不能只看速度,还要看是否能稳定命中正确片段。 |
召回
召回是从知识库中先找出一批可能相关的候选片段。它追求“别漏掉正确答案”,但不保证所有结果都排得最好。
| 层级 | 解释 |
|---|---|
| 人话解释 | 召回像先从资料库里捞出一篮子可能有用的材料,宁可多一点,也不能把真正答案漏掉。 |
| 项目位置 | 客户提问后,系统会根据问题向量、关键词、元数据和查询改写结果召回候选片段。 |
| 工程动作 | 设计 top_k(召回数量)、关键词补充、混合检索、查询改写、过滤顺序和召回日志。 |
| 面试说法 | 召回阶段重点是覆盖正确答案,重排阶段才重点处理排序质量。要通过评估样例看正确片段是否进入候选集。 |
重排
Reranker(重排序器) 是对初步召回的候选片段再次打分,把更适合回答当前问题的片段排到前面。
| 层级 | 解释 |
|---|---|
| 人话解释 | 召回先把可能相关的资料找出来,重排再像质检员一样重新排序,挑出最该给模型看的几段。 |
| 项目位置 | 客服 Agent(智能体)在构造回答上下文前,会把候选片段交给重排序器,选出最相关、最可引用的片段。 |
| 工程动作 | 设计重排候选数量、最终上下文数量、分数阈值、降级策略和重排日志。 |
| 面试说法 | 重排常用于资料量大、语义相近但规则不同的场景。它能减少噪声,但前提是召回阶段已经把正确片段找进来了。 |
引用片段
引用片段是回答中可追溯的依据。它告诉用户和客服:这句话来自哪份文档、哪个章节、哪段内容。
| 层级 | 解释 |
|---|---|
| 人话解释 | 引用片段就是“我为什么这么回答”的证据。没有引用,RAG 回答很难被信任。 |
| 项目位置 | 工作台回答售后政策时,要展示政策名称、章节路径、更新时间和相关原文摘要。 |
| 工程动作 | 保存 source_id(来源编号)、chunk_id(分块编号)、heading_path(标题路径)、page_number(页码)、quote_text(引用文本)和可展示权限。 |
| 面试说法 | 我会把引用当成产品能力,而不是调试信息。客服和用户都需要看到依据,质检也要能回放当时引用了哪些片段。 |
元数据
元数据 是描述知识片段的业务信息。它不一定参与语义相似度计算,但决定片段是否适用。
| 层级 | 解释 |
|---|---|
| 人话解释 | 元数据像每张知识卡片的标签:属于哪个产品、哪个版本、哪个部门、能给谁看、什么时候有效。 |
| 项目位置 | 售后政策片段会带产品线、地区、版本、有效期、资料状态和可见范围,防止命中不适用资料。 |
| 工程动作 | 设计元数据字段,写入索引,检索时过滤,回答时展示必要来源,日志中记录过滤条件。 |
| 面试说法 | 向量相似只能说明语义相关,不能说明业务适用。企业 RAG 必须用元数据控制权限、版本和范围。 |
权限过滤
权限过滤是确保用户只能检索和看到自己有权访问的片段。
| 层级 | 解释 |
|---|---|
| 人话解释 | 不是知识库里有的资料都能给所有人看。权限过滤就是在检索前后把不该看的资料挡住。 |
| 项目位置 | 客户只能看到公开说明和自己的工单资料;客服能看到内部 SOP(标准作业流程);主管能看质检和跨团队复盘。 |
| 工程动作 | 设计租户、角色、部门、资料状态、客户归属和脱敏规则,并在召回、重排和引用展示阶段持续校验。 |
| 面试说法 | 权限不能只靠 Prompt(提示词)。检索系统必须在数据层和服务层做过滤,否则模型可能引用到用户不该看到的资料。 |
评估样例
评估样例是用来验证检索链路是否正确的一组问题和期望结果。
| 层级 | 解释 |
|---|---|
| 人话解释 | 它像 RAG 的考试题。每道题都写清应该命中哪些资料,不应该命中哪些资料。 |
| 项目位置 | 客服团队会准备售后、产品、投诉、工单材料等问题,定期测试知识库检索质量。 |
| 工程动作 | 设计问题、期望 chunk_id(分块编号)、不应命中片段、权限角色、版本条件、通过标准和回归记录。 |
| 面试说法 | 没有评估样例就无法判断优化是否有效。我会用样例集区分召回问题、重排问题、过滤问题和生成问题。 |
本章在客服 Agent(智能体)工作台中的位置
在完整客服工作台中,本章属于“知识库检索工程层”。它位于文档解析之后、回答生成之前,也是后续权限、安全、可观测性和工单流程的基础。
| 层级 | 作用 | 本章关注点 |
|---|---|---|
| 资料接入层 | 上传政策、手册、FAQ(常见问题)、工单复盘 | 接收上一章解析后的结构化文档。 |
| 分块与元数据层 | 生成可检索知识片段 | 本章核心:分块、标题路径、版本、权限、引用位置。 |
| 向量化与索引层 | 为片段生成 Embedding(嵌入向量)并写入索引 | 本章核心:嵌入模型、索引、增量更新。 |
| 检索与重排层 | 根据用户问题找出最相关片段 | 本章核心:召回、过滤、重排、上下文构造。 |
| Agent 回答层 | 基于片段生成回答 | 使用本章输出的引用片段和上下文。 |
| 工具与工单层 | 查订单、建工单、转人工 | 当知识库回答不足时接手。 |
| 日志与评估层 | 记录检索、回答、引用和失败 | 本章核心:检索日志和评估样例。 |
从系统边界看,本章不负责“上传文件的界面长什么样”,也不负责“模型最终怎么组织语气”。本章负责的是:让正确资料以正确权限、正确顺序、正确引用形式进入 Agent 的上下文。
系统流程图
这张图要抓住四个关键点:
读图重点:上半链把资料处理成已发布索引;下半链只让通过权限、版本和有效期检查的候选进入重排。相关性不足时停止生成并转入追问或人工兜底。
- 分块和元数据发生在入库前,决定片段质量。
- 权限过滤不能只做一次,预过滤和后过滤都需要。
- 召回只是找到候选,重排才决定哪些片段真正进入模型上下文。
- 引用片段和检索日志必须被记录,否则无法复盘为什么这么回答。
模块拆分
一个可交付的客服知识库 RAG 能力,可以拆成这些模块:
| 模块 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 资料源管理模块 | 管理文档来源、版本、发布状态和业务归属 | 原始文档、上传人、所属部门 | source_id(来源编号)、版本、状态。 |
| 文档结构解析模块 | 识别标题、正文、列表、表格和问答对 | 原始文档 | 结构化文档节点。 |
| 分块模块 | 把结构化文档切成知识片段 | 文档节点、分块规则 | chunk_id(分块编号)、正文、标题路径。 |
| 元数据补齐模块 | 给片段打业务标签 | 资料属性、人工标注、系统规则 | 产品线、权限、有效期、资料状态。 |
| 嵌入任务模块 | 批量生成和更新 Embedding(嵌入向量) | 知识片段、模型配置 | 向量、模型版本、任务状态。 |
| 索引写入模块 | 写入向量索引和关键词索引 | 片段、向量、元数据 | 可检索索引记录。 |
| 查询理解模块 | 识别用户问题中的产品、时间、问题类型和角色 | 用户问题、会话上下文 | 检索查询、过滤条件。 |
| 检索召回模块 | 找到候选片段 | 查询向量、关键词、过滤条件 | 候选片段列表和初始分数。 |
| 重排序模块 | 对候选片段重新打分 | 用户问题、候选片段 | 排序后的片段和重排分数。 |
| 引用构造模块 | 选择可展示的依据 | 片段、权限、引用位置 | 引用片段、来源路径、展示摘要。 |
| 评估模块 | 用样例验证检索质量 | 测试问题、期望命中 | 命中率、失败原因、回归记录。 |
| 检索日志模块 | 记录一次检索全过程 | 查询、候选、过滤、重排、引用 | trace_id(追踪编号)和审计日志。 |
模块拆分不是为了显得复杂,而是为了让问题能定位。例如回答错了,你可以判断是文档解析错、分块错、元数据错、召回没命中、重排没排上来,还是生成阶段误读了引用片段。