Embedding 与语义检索

3.1 为什么关键词检索不够#

关键词检索适合规则清晰、词面稳定的场景。例如用户搜索“iPhone 15 手机壳”，商品标题里也写了“iPhone 15 手机壳”，匹配很直接。

但真实业务里的问题通常更复杂：

如果系统只做关键词匹配，会出现几个问题：

• 用户必须学会系统语言，体验差。

• 文档写法稍有不同就搜不到。

• 同义词、口语、缩写、错别字影响结果。

• 搜索结果有词但不一定有用。

• 新人不懂业务术语，很难找到资料。

AI 产品常说“让用户用自然语言提问”，但自然语言提问要真正可用，底层必须能处理语义差异。Embedding 就是这层能力的基础。

3.2 Embedding 是什么#

Embedding 可以理解为：把一个对象转成一串数字，这串数字代表它在语义空间里的位置。

对象可以是：

• 一句话。

• 一段文档。

• 一个商品标题。

• 一张图片。

• 一条用户反馈。

• 一段客服对话。

• 一个用户画像。

• 一段代码。

例如：

1
用户问题：酒店超标能报销吗？
2
文档片段：住宿费用超过城市标准时，需在出差前提交审批。

这两句话字面不同，但经过 Embedding 模型后，它们在向量空间里的距离可能很近。系统就可以判断：这段文档可能能回答这个问题。

产品经理不需要掌握向量公式，但要理解三个事实：

1. Embedding 表示的是相似度，不是事实正确性。 找到相似资料不等于答案正确。

2. Embedding 依赖模型和数据。 不同模型对中文、行业术语、长文本、代码、图片的效果不同。

3. Embedding 只是召回的一环。 真正可靠的问答还需要分块、重排、权限、生成、引用和评估。

3.3 向量和相似度的白话解释#

可以把语义空间想象成一张很大的地图。意思相近的内容会靠得更近，意思不同的内容会离得更远。

1
“住宿超标能报销吗”
2
“酒店超过标准怎么处理”
3
“差旅住宿费用超出城市标准”

这些内容会比较近。

1
“怎么申请年假”
2
“电脑坏了如何报修”
3
“客户合同什么时候盖章”

这些内容会离得远一些。

系统检索时通常会做：

1
用户问题 -> 生成问题向量
2
文档片段 -> 预先生成文档向量
3
计算问题向量和文档向量的相似度
4
返回最相似的若干片段

这里的“相似”不等于“包含同一个词”。这就是语义检索相对关键词检索的核心提升。

3.4 向量库是什么#

当文档量很小时，可以直接逐条比较相似度。但企业知识库可能有几万、几十万、几百万个片段，逐条比较成本太高。向量库就是专门存储向量并快速检索相似向量的系统。

向量库通常保存：

• 文档片段 ID。

• 向量。

• 原文内容。

• 来源文档。

• 版本号。

• 权限标签。

• 更新时间。

• 业务标签。

产品经理要关注的不是向量库品牌，而是它是否支持业务需要：

3.5 召回与重排：先找一批，再精排#

语义检索通常分两步：

1
召回：快速找出可能相关的一批资料
2
重排：对这一批资料重新排序，挑出最能回答问题的片段

召回追求“别漏掉”，重排追求“排得准”。

例如用户问：

1
我出差住宿超标，但领导同意了，报销要补什么材料？

召回阶段可能找出：

• 差旅住宿标准。

• 超标审批规则。

• 报销材料清单。

• 领导审批权限。

• 发票要求。

重排阶段要判断哪几个片段最关键。可能“超标审批规则”和“报销材料清单”更重要，“发票要求”只是次要。

如果没有重排，模型可能拿到一堆相关但不关键的片段，回答就会模糊甚至错误。产品上常见问题是：知识库问答“搜到了资料”，但回答不对。很多时候不是模型生成差，而是检索上下文给错了。

3.6 文档分块：RAG 成败的基础#

企业文档通常很长，不能整篇塞给模型，也不适合整篇生成一个向量。必须先把文档拆成片段，也就是分块。

分块太大：

• 检索不够精确。

• Token 成本高。

• 模型注意力被稀释。

• 引用不够具体。

分块太小：

• 条款上下文被切断。

• 片段无法独立回答问题。

• 召回到半句话，模型容易补。

好的分块要尊重文档结构：

• 标题。

• 章节。

• 条款。

• 表格。

• 附件。

• 生效日期。

• 适用对象。

• 例外条件。

例如差旅制度不能机械按 500 字切。更合理的是按“住宿标准”“超标审批”“报销材料”“不予报销情形”等业务段落切，并保留父级标题和版本信息。

3.7 语义检索如何降低幻觉#

Day 4 讲过，模型幻觉的重要原因是缺少事实依据。语义检索能把相关资料找出来，让模型基于资料回答。

基本链路是：

1
用户问题
2
-> 问题向量化
3
-> 向量库召回相关片段
4
-> 重排
5
-> 拼接上下文
6
-> 大模型生成回答
7
-> 引用来源

这就是 RAG 的核心思路。它把“模型记忆”变成“外部知识检索 + 模型表达”。

但要明确：语义检索降低幻觉，不等于消灭幻觉。它仍然可能出错：

• 没搜到正确资料。

• 搜到旧版本资料。

• 搜到相似但不适用的资料。

• 模型引用了资料但结论超出资料。

• 用户问题需要订单、权限、审批记录，而知识库没有。

所以可靠的 RAG 需要评估“检索”和“生成”两层。

3.8 权限和版本是企业检索的硬边界#

很多产品方案只写“接入知识库”，但企业知识库不是公共百科。它有权限、版本和责任边界。

典型问题：

• 普通员工不能查看高管薪酬制度。

• 销售不能查看其他大区客户合同。

• 旧制度不能继续回答新问题。

• 草稿制度不能被当成正式制度。

• 不同国家、地区、事业部规则不同。

因此检索系统必须支持元数据过滤：

1
用户身份
2
-> 部门/角色/地区/职级
3
-> 可见文档范围
4
-> 当前有效版本
5
-> 再进入向量检索

不要先检索所有资料再让模型判断是否能说。权限必须在系统层做，而不是依赖模型自觉。

3.9 语义检索的产品指标#

语义检索上线后，不要只看“用户满意度”。至少要看：

• 检索命中率：正确资料是否在候选结果里。

• Top 1 准确率：第一条是否就是正确资料。

• Top K 召回率：前 K 条是否包含正确资料。

• 重排准确率：关键资料是否排到前面。

• 引用准确率：回答引用是否来自正确片段。

• 引用支持率：引用是否真的支持结论。

• 无结果率：系统找不到资料的比例。

• 拒答正确率：资料不足时是否正确拒答。

• 人工接管率：需要人工处理的问题比例。

• 用户二次追问率：用户是否还要继续问同一件事。

如果产品只看“回答率”，系统会倾向于硬答；如果只看“满意度”，短期可能被流畅话术掩盖风险。知识问答必须把检索质量、答案质量和业务风险一起看。

3.10 什么时候不该用语义检索#

语义检索不是万能。

不适合或不能单独使用的场景包括：

• 结果必须完全确定的交易规则，例如库存扣减、优惠券是否可用。

• 需要实时业务状态的问题，例如“我的订单现在在哪”。

• 需要复杂计算的问题，例如佣金、税费、动态价格。

• 需要权限审批的问题，例如是否可以报销、是否批准退款。

• 资料本身质量很差，未清洗、过期、互相矛盾。

这些场景不是不能用 AI，而是不能只靠语义检索。更合理的方式是：

1
语义检索负责找规则解释
2
业务系统负责确定性判断
3
大模型负责自然语言解释
4
人工负责高风险复核

3.11 产品经理如何推进语义检索项目#

一个可落地的语义检索项目，至少分 8 步：

1. 确定场景。 先选高频、资料可得、风险可控的问题。

2. 整理资料。 清理旧版、重复、扫描件、权限不明文档。

3. 设计分块。 按业务结构切，而不是机械切字数。

4. 建立样本集。 收集真实用户问法和标准答案资料。

5. 选 Embedding 模型。 关注中文、行业术语、长文本、成本。

6. 搭建检索链路。 向量化、向量库、召回、重排、元数据过滤。

7. 接入生成。 让模型基于片段回答，并显示引用。

8. 评估迭代。 用样本集评估召回、引用、幻觉、拒答。

产品经理不能把这件事完全交给研发。因为检索效果很大程度取决于资料治理、业务标签、问法样本、风险边界和验收标准，这些都是产品和业务必须参与的工作。

业务背景#

一家国内中型企业有大量制度文档：差旅、报销、采购、合同、请假、信息安全、行政流程。员工原来通过企业网盘或 OA 搜索制度，但搜索体验差。

员工常问：

1
酒店超过标准一点还能报吗？
2
供应商合同盖章要走哪个流程？
3
客户送礼有没有金额限制？
4
年假没休完会清零吗？

制度文档里却写着：

1
住宿费用超出城市分级标准的，应在出差申请阶段完成例外审批。
2
合同用印须通过法务审核后提交印章管理员处理。
3
商务馈赠应遵守廉洁合规管理办法。

用户问法和制度表达不一致，关键词搜索难以命中。

相关角色#

• 员工：需要快速找到制度答案。

• HR/行政/财务/法务：负责制度维护和解释。

• IT：负责文档系统、权限和集成。

• 产品经理：负责问答范围、检索体验、指标和风险。

• AI 工程：负责 Embedding、向量库、重排、回答生成。

• 内控/合规：关注权限、版本、错误解释和审计。

原始流程#

1
员工输入关键词
2
-> 搜索文档标题或正文
3
-> 打开多个 PDF/Word
4
-> 人工查找条款
5
-> 看不懂时问 HR/财务/法务
6
-> 等人工回复

痛点：

• 搜索词和制度词不一致。

• 文档版本混乱。

• PDF、Word、表格格式不统一。

• 员工不知道该搜哪个部门的制度。

• 管理部门重复答疑。

AI 改造流程#

1
制度文档接入
2
-> 清洗格式和版本
3
-> 按制度结构分块
4
-> 添加元数据：部门、权限、版本、生效日期
5
-> 生成 Embedding
6
-> 存入向量库
7
-> 员工自然语言提问
8
-> 权限过滤 + 语义召回 + 重排
9
-> 基于引用生成回答
10
-> 反馈是否有用

数据与系统依赖#

• 制度文档库。

• 文档版本和生效日期。

• 组织架构与权限。

• 文档分类标签。

• 历史咨询问题。

• 人工标准答案。

• 企业 IM 或 OA 入口。

• 日志与评估系统。

方案架构#

1
文档源
2
  -> 文档清洗
3
      -> 去重
4
      -> 识别标题/表格/附件
5
      -> 版本标记
6
  -> 分块策略
7
      -> 按章节/条款/表格切分
8
      -> 保留父级标题
9
  -> Embedding
10
  -> 向量库
11
      -> 权限标签
12
      -> 生效日期
13
      -> 来源链接
14
  -> 检索服务
15
      -> 权限过滤
16
      -> 语义召回
17
      -> 重排
18
  -> 回答生成
19
      -> 引用
20
      -> 拒答
21
      -> 转人工

关键指标#

• Top 5 召回率。

• 引用准确率。

• 引用支持率。

• 员工自助解决率。

• 管理部门咨询量下降。

• 无依据回答率。

• 旧版本误召回率。

• 平均响应时间。

• 员工二次追问率。

主要风险#

• 旧制度被召回。

• 权限过滤不严导致资料泄露。

• 表格被错误切分，标准金额丢失。

• 模型引用正确但结论越界。

• 员工把解释当成审批承诺。

• 资料维护不持续，系统上线后逐渐失准。

复盘结论#

企业制度问答的核心不是“模型会不会回答”，而是“资料能不能被正确找到、正确引用、正确拒答”。Embedding 解决的是用户问法和制度表达不一致的问题，但制度治理、权限、版本和评估才决定系统能否长期可靠。

业务背景#

一个电商平台发现，用户搜索越来越场景化。用户不只搜“连衣裙”，还会搜：

1
适合海边拍照的裙子
2
夏天通勤不闷脚的小皮鞋
3
送男朋友的实用生日礼物
4
小户型不占地方的餐桌

商品标题和属性往往不能完全覆盖这些说法。传统搜索会漏掉大量相关商品。

相关角色#

• 用户：希望用自然语言找到合适商品。

• 搜索产品经理：负责召回、排序、转化和体验。

• 商品运营：负责商品标题、属性、标签和类目。

• 算法工程师：负责向量召回、排序模型。

• 商家：负责商品信息质量。

• 数据分析师：负责搜索指标和实验评估。

原始流程#

1
用户输入关键词
2
-> 分词
3
-> 匹配标题/类目/属性
4
-> 返回商品列表
5
-> 用户筛选或换词

问题：

• “海边拍照”不一定出现在商品标题里。

• “不闷脚”可能对应透气材质、网面、真皮内里。

• “小户型”可能对应尺寸、折叠、可伸缩。

• “送男朋友”涉及人群、价格、礼品属性。

AI 改造流程#

1
商品标题/属性/图片/评价
2
-> 商品语义向量
3
-> 用户 Query 向量
4
-> 语义召回候选商品
5
-> 关键词召回补充
6
-> 排序模型融合点击、转化、相关性、价格、库存
7
-> 搜索结果页
8
-> 用户行为反馈

数据与系统依赖#

• 商品标题、类目、属性、价格、库存。

• 商品图片和图像标签。

• 商品评价和问答。

• 搜索 Query 日志。

• 点击、加购、成交、退货数据。

• 用户画像和场景标签。

• 实验平台。

方案架构#

1
离线侧
2
  -> 商品数据清洗
3
  -> 文本/图片 Embedding
4
  -> 商品向量库
5

6
在线侧
7
  -> Query 理解
8
  -> Query Embedding
9
  -> 向量召回
10
  -> 关键词召回
11
  -> 业务过滤
12
  -> 排序
13
  -> 展示与反馈

关键指标#

• 搜索无结果率。

• 首屏点击率。

• 搜索转化率。

• 二次搜索率。

• 语义召回贡献率。

• 相关性人工标注分。

• 长尾商品曝光。

• 退货率和差评率。

主要风险#

• 语义召回过宽，出现看似相关但实际不合适的商品。

• 热门商品因点击数据强而压制语义相关商品。

• 商品信息质量差导致向量表示不准。

• Query 场景理解错误。

• 只优化点击率，牺牲长期满意度。

复盘结论#

电商搜索中的 Embedding 主要解决“用户自然语言需求”和“商品结构化信息”之间的语义鸿沟。它应该和关键词召回、规则过滤、排序模型一起工作。产品经理不能只问“语义召回准不准”，还要看它是否提升搜索任务完成率、转化率和用户满意度。

任务：设计 20 条知识库问答样本#

选择一个你熟悉的知识库场景，例如：

• 企业制度问答。

• 客服售后知识库。

• 商品运营 SOP。

• 合同条款问答。

• 研发文档助手。

设计 20 条样本，每条包含：

• 用户自然语言问法。

• 标准资料片段。

• 所属主题。

• 是否需要权限。

• 是否可直接回答。

• 期望处理方式。

模板如下：

验收标准#

合格：

1. 至少 20 条样本。

2. 用户问法必须口语化，不能照抄文档标题。

3. 每条样本都要对应明确资料片段。

4. 至少包含 3 类主题。

优秀：

1. 包含同义问法、模糊问法、错误问法和高风险问法。

2. 能标注哪些问题应拒答或转人工。

3. 能用这些样本评估 Top 5 召回率、引用准确率和引用支持率。

理解题#

1. Embedding 是什么？ 参考答案：Embedding 是把文本、图片、商品、用户问题等对象转成向量表示，使系统可以计算它们在语义空间中的相似度。

2. 语义检索和关键词检索的核心区别是什么？ 参考答案：关键词检索主要看词面是否匹配；语义检索看意思是否相近，因此能处理同义词、口语表达和隐含需求。

3. 为什么找到相似资料不等于答案正确？ 参考答案：相似度只说明资料可能相关，不保证资料适用、版本正确、权限允许，也不保证模型生成的结论忠实于资料。

4. RAG 中为什么要做文档分块？ 参考答案：长文档不能整篇塞给模型，也不适合整篇生成向量。合理分块能提升检索精度、降低 Token 成本，并让引用更具体。

5. 为什么企业语义检索必须考虑权限和版本？ 参考答案：企业文档有可见范围和生效日期。没有权限过滤和版本管理，系统可能泄露资料或用旧制度回答新问题。

应用题#

6. 企业制度问答如何评估语义检索效果？ 参考答案：建立真实问题和标准资料片段样本集，评估 Top K 召回率、Top 1 准确率、重排准确率、引用准确率、引用支持率、拒答正确率和无依据回答率。

7. 电商搜索中，语义召回为什么不能单独决定最终排序？ 参考答案：语义相近只是候选相关。最终排序还需要考虑库存、价格、销量、点击率、转化率、个性化、多样性、合规和用户满意度。

8.1 知识问答样本集#

8.2 语义检索方案评估表#

8.3 RAG 检索链路草图#

1
文档源
2
-> 清洗
3
-> 分块
4
-> 添加元数据：来源/版本/权限/主题
5
-> Embedding
6
-> 向量库
7
-> 用户问题向量化
8
-> 权限过滤
9
-> 语义召回
10
-> 重排
11
-> 大模型基于片段回答
12
-> 引用与拒答
13
-> 用户反馈与评估集更新