跳到主要内容

第 2.3.3 节：用元数据过滤、召回和重排提升检索质量

元数据过滤、召回和重排只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明元数据过滤、召回和重排的触发、处理、复核、记录和兜底步骤。

实现步骤或决策流程​

推荐技术流​

本章推荐的技术流可以分成“入库侧”和“查询侧”两条线。

阶段做什么为什么
1. 资料盘点列出售后政策、产品手册、FAQ（常见问题）、SOP（标准作业流程）、历史工单不同资料需要不同分块和权限策略。
2. 文档解析识别标题、段落、列表、表格、图片说明和附件分块必须依赖结构，不只看字数。
3. 分块策略设计按标题、问答对、规则条款、表格单元组合切分保证片段完整、可引用、噪声不过大。
4. 元数据补齐给片段加来源、版本、产品线、权限、有效期语义相似不代表业务适用。
5. Embedding（嵌入向量）生成为每个片段生成向量并记录模型版本后续模型升级时能重建和比较。
6. 索引写入写入向量索引，必要时同时写关键词索引兼顾语义召回和精确词命中。
7. 查询构造把用户问题转换成检索问题，补充产品、订单、角色等上下文用户原话常常不完整。
8. 召回与过滤用向量、关键词和元数据找到候选片段先保证正确资料进入候选集。
9. 重排与截断用重排序器选出最相关片段，控制上下文长度减少噪声，避免模型看到错误资料。
10. 引用与回答生成带来源的回答，并保留引用片段提升可信度，方便客服复盘。
11. 日志与评估记录查询、候选、分数、过滤原因和最终引用为调优、质检和面试提供证据。

这条技术流的核心思想是：先保证资料片段“可用、可控、可追溯”，再追求模型回答“好听”。

字段契约​

本节用字段契约替代代码语法。字段契约的作用是让前端、后端、数据处理、Agent（智能体）和评估人员对同一个对象有共同理解。

文档来源契约​

字段含义来源是否必填验收要求
source_id（来源编号）一份原始资料的唯一编号系统生成是能追溯到上传记录和原始文件。
source_title（来源标题）文档名称上传信息或文档标题是回答引用时可展示。
source_type（来源类型）售后政策、产品手册、FAQ（常见问题）、SOP（标准作业流程）、历史工单上传人选择或系统识别是影响分块策略和权限策略。
owner_department（归属部门）谁负责维护这份资料组织系统或人工选择是便于过期提醒和责任追踪。
product_line（产品线）适用的产品或业务线人工标注或资料属性视情况用于过滤相似但不适用资料。
version（版本）文档版本上传记录是避免命中旧版本。
publish_status（发布状态）草稿、待审核、已发布、已下线审核流程是未发布资料不能给客户使用。
effective_from（生效时间）规则开始生效时间文档或审核流程视情况处理政策切换。
effective_to（失效时间）规则结束时间文档或审核流程否过期资料需要降权或过滤。

知识片段契约​

字段含义来源是否必填验收要求
chunk_id（分块编号）一个知识片段的唯一编号分块模块生成是后续评估样例能精确引用。
source_id（来源编号）片段来自哪份文档文档来源是支持回到原始资料。
heading_path（标题路径）片段所在章节路径文档结构解析是例如“售后政策 / 退换货 / 7 天内故障”。
chunk_text（片段正文）用于检索和回答的正文分块模块是条件、结论和限制不能被无意义切断。
chunk_summary（片段摘要）可选的短摘要系统生成或人工维护否用于展示和日志，不替代原文。
token_count（文本数量）片段长度估算分块模块是控制上下文预算。
overlap_group（重叠组）与前后片段的重叠关系分块模块否帮助排查重复和上下文断裂。
page_number（页码）原文页码或位置文档解析视资料类型方便引用。
table_ref（表格引用）表格编号或表头信息文档解析视资料类型防止表格数据脱离列名。

元数据契约​

字段含义为什么重要
tenant_id（租户编号）当前企业或客户空间多租户系统必须隔离资料。
visibility（可见范围）客户可见、客服可见、主管可见、仅内部可见决定回答能否展示引用。
role_scope（角色范围）哪些角色可以检索防止客户看到内部 SOP（标准作业流程）。
department_scope（部门范围）哪些部门可以使用售后、销售、技术支持资料可能不同。
product_line（产品线）适用产品防止相似产品误命中。
region_scope（地区范围）适用地区售后、物流和合规规则可能不同。
policy_status（规则状态）草稿、审核中、已发布、已过期控制是否参与检索。
sensitivity_level（敏感等级）公开、内部、敏感、机密控制引用展示和日志脱敏。

检索请求契约​

字段含义来源验收要求
trace_id（追踪编号）串联一次检索和回答系统生成日志、回答、评估都能关联。
user_question（用户问题）用户原始提问会话入口保留原始语义，但日志要脱敏。
normalized_query（规范化查询）用于检索的问题表达查询理解模块能补全产品、时间、问题类型。
user_role（用户角色）客户、客服、主管、运营身份系统用于权限过滤。
tenant_id（租户编号）所属企业空间身份系统防止跨租户检索。
filters（过滤条件）产品线、版本、状态、权限、有效期会话上下文和业务规则必须可记录、可复盘。
retrieval_mode（检索模式）向量、关键词、混合检索检索策略方便对比效果。
top_k（召回数量）初步候选数量系统配置不能只调大，要结合质量评估。

召回结果契约​

字段含义用途
chunk_id（分块编号）命中的片段对照评估样例。
source_id（来源编号）片段来源引用和追溯。
initial_score（初始分数）向量或关键词召回分数判断召回阶段质量。
matched_by（命中方式）向量、关键词、混合、手工置顶排查为什么命中。
filter_passed（是否通过过滤）权限、版本、有效期是否通过防止不适用资料进入上下文。
filter_reason（过滤原因）被过滤或保留的理由调试和审计。
preview_text（片段预览）日志中的短摘要方便人工复盘，需脱敏。

重排与引用契约​

字段含义验收要求
rerank_score（重排分数）重排序器对候选片段的相关性判断用于观察排序是否合理。
final_rank（最终排名）进入上下文前的排序正确片段应进入前几名。
selected_for_context（是否进入上下文）是否给模型使用需要记录入选和未入选原因。
citation_id（引用编号）回答中展示的引用编号用户可以对应到片段。
citation_title（引用标题）展示给用户的来源标题不能暴露内部敏感标题。
citation_path（引用路径）标题路径、页码或章节能回到原文位置。
quote_text（引用文本）可展示的依据摘要要短、准确、可授权展示。
citation_visibility（引用可见范围）谁能看到这条引用客户端展示前仍需校验。

评估样例契约​

字段含义示例说明
case_id（样例编号）一条评估题的编号用于回归测试。
question（问题）模拟用户提问覆盖真实问法和口语表达。
user_role（用户角色）用哪个身份提问验证权限过滤。
expected_chunks（期望命中片段）应该进入候选或最终上下文的 chunk_id（分块编号）检查召回和重排。
forbidden_chunks（不应命中片段）旧版、越权或错误产品线资料检查过滤能力。
expected_citation（期望引用）最终回答应引用的资料检查可追溯性。
pass_rule（通过规则）什么情况算通过例如正确片段进入重排前 5，禁止片段不进入上下文。

字段契约的重点不是字段越多越好，而是让系统有能力回答三个问题：命中了什么、为什么命中、能不能给当前用户看。

制作步骤​

下面是一套不写代码也能落地的制作步骤。读者可以把它当作作品集项目的实施路线。

第 1 步：盘点知识资料​

先列出资料类型、来源部门、更新频率、可见范围和是否包含敏感信息。

资料来源部门更新频率可见范围风险
售后政策售后运营每月或临时更新客户和客服旧版政策误用。
产品手册产品团队随版本更新客户和客服相似产品混淆。
客服 SOP（标准作业流程）客服主管持续迭代内部客服不能直接给客户看。
历史工单复盘客服质检每周整理主管和授权客服涉及隐私和投诉。

第 2 步：确定分块规则​

不同资料不要共用一个粗暴规则。

资料类型推荐分块方式注意点
售后政策按章节、规则条款、条件和处理方式切分条件、结论、材料要求要放在同一片段或相邻片段。
FAQ（常见问题）一个问答对作为基本片段同义问法可以作为检索辅助，但答案必须可追溯。
产品手册按功能模块和限制说明切分不同套餐、版本、产品线要有元数据。
表格资料保留表头、行标题、单位和适用条件不能只切单元格。
历史工单按问题、处理过程、结果和复盘总结切分必须脱敏和权限限制。

第 3 步：设计片段长度和重叠​

片段长度没有固定答案。客服知识库通常要让片段短到能精准命中，又长到能包含完整业务判断。

判断方法：

  • 如果一个片段里包含多个不相关规则，说明太大。
  • 如果一个片段只有条件没有结论，说明太小。
  • 如果表格片段没有表头、单位或适用范围，说明切分破坏了结构。
  • 如果模型回答时需要连续引用多个相邻片段才能完整表达，可以考虑合并或增加重叠。

第 4 步：补齐元数据​

元数据不是后期再补的装饰，而是检索质量和权限安全的基础。

至少要补齐：

  • source_id（来源编号）。
  • version（版本）。
  • product_line（产品线）。
  • visibility（可见范围）。
  • publish_status（发布状态）。
  • effective_from（生效时间）和 effective_to（失效时间）。
  • owner_department（归属部门）。
  • sensitivity_level（敏感等级）。

第 5 步：选择 Embedding（嵌入向量）策略​

选择嵌入模型时，不要只看排行榜。客服知识库要关注：

  • 中文语义和行业术语表现。
  • 短问题对长片段的匹配能力。
  • 同义表达、口语表达和错别字容忍度。
  • 成本、延迟和批量重建能力。
  • 模型版本变化后是否能复现实验。

记录模型版本非常重要。否则过几个月后，你无法解释为什么同一批资料的检索结果变了。

第 6 步：设计索引与发布机制​

索引不是一次性写入就结束。知识库会持续更新。

推荐状态流：

  1. 新文档上传后进入待解析。
  2. 解析和分块完成后进入元数据补齐中。
  3. 元数据补齐后生成 Embedding（嵌入向量）。
  4. 索引写入完成后进入待审核。
  5. 业务人员确认后发布。
  6. 新版本发布时旧版本下线或降权。
  7. 过期资料进入不可检索或仅内部可查状态。

第 7 步：设计查询构造​

用户问题往往不完整。比如“这个还能退吗？”单看这句话无法判断产品、时间和订单状态。查询构造模块要从会话中补齐：

  • 用户正在看的订单或产品。
  • 问题类型是退货、换货、维修还是投诉。
  • 时间条件是下单时间、签收时间还是发现问题时间。
  • 当前用户角色是客户还是客服。
  • 是否需要结合工具调用查订单状态。

第 8 步：设计召回和重排​

不要把召回和重排混成一件事。

读图重点：从左上开始：身份与业务条件先做预过滤，再并行召回；候选合并后仍要检查版本、权限和有效期。重排后只把相关且可展示的引用送入模型，其余统一兜底并留日志。

  • 召回阶段：目标是让正确片段进入候选，常用向量检索、关键词检索、混合检索和元数据过滤。
  • 重排阶段：目标是把最适合当前问题的片段排到前面，减少噪声进入模型上下文。
  • 截断阶段：目标是在模型上下文预算内保留最关键引用，避免把相似但不适用的资料塞进去。

第 9 步：设计引用展示​

客服工作台中的回答最好不要只有自然语言答案，还要有依据。

引用展示可以包含：

  • 资料标题。
  • 章节路径。
  • 更新时间或版本。
  • 可展示的原文摘要。
  • 是否为内部引用。
  • 需要转人工确认的提示。

客户侧引用要简洁，客服侧引用可以更详细。内部敏感资料不能因为被检索命中就直接展示给客户。

第 10 步：建立评估样例​

每上线一批知识库，都要准备评估样例。最小样例集可以先覆盖：

  • 售后政策 10 条。
  • 产品手册 10 条。
  • FAQ10 条。
  • 投诉和工单流程 10 条。
  • 权限和旧版资料过滤 10 条。

每条样例至少写清：问题、用户角色、期望命中片段、不应命中片段、通过规则和失败备注。

第 11 步：用日志反向改进​

上线后不要只看用户点踩。要看检索日志：

  • 正确片段有没有进入召回候选。
  • 如果进入候选，重排有没有排到前面。
  • 如果排到前面，是否因为权限或引用策略被过滤。
  • 如果进入上下文，模型是否误读了片段。
  • 如果系统转人工，原因是否合理。

RAG（检索增强生成）优化不是盲目换模型，而是沿着日志找到最弱环节。

不适合这样做的场景​

RAG 检索链路很重要，但不是所有问题都适合用“分块 + Embedding（嵌入向量）+ 向量索引 + 重排”解决。

场景为什么不适合更合适的方式
纯结构化查询例如查订单状态、查余额、查库存用业务工具或数据库查询，不能用语义检索猜。
强计算问题例如费用精确计算、赔付金额计算用规则引擎、表格计算或业务工具。
极低资料量只有几页固定 FAQ（常见问题）直接规则匹配或人工维护问答可能更简单。
资料未治理文档冲突、过期、权限不清先做知识治理，否则检索会放大混乱。
高风险合规判断法务、医疗、金融审批等最终判断RAG 只能辅助，必须人工或合规流程确认。
实时状态问题物流、订单、工单进度用工具调用实时查询，知识库只能解释规则。
无法提供引用的问题资料来源不明确或不能展示依据不适合生成确定性回答。

能说清“不适合用”的边界，是工程能力的一部分。面试官通常不只关心你会不会搭 RAG，还关心你会不会避免错误使用它。

和后续章节的关系​

本章是第 2 卷后续工程章节的基础。

后续章节和本章的关系
第 2.4 章：向量数据库选型本章讲检索链路，下一章会比较 Qdrant（向量数据库产品）、Milvus（向量数据库产品）、pgvector（数据库向量扩展）等方案如何承载索引。
第 2.5 章：企业知识库治理本章已经引入版本、权限、有效期，后续会扩展成资料审核、发布、下线和责任人机制。
第 2.6 章：MCP（模型上下文协议）基础RAG 检索能力可以作为工具或资源暴露给 Agent 和外部客户端。
第 2.8 章：LangGraph（智能体状态图框架）多步骤客服流程会把检索、重排、工具调用、转人工做成状态节点。
第 2.12 章：可观测性、成本和限流本章日志会进入检索质量、延迟、成本和失败率监控。
第 2.13 章：安全权限与审批本章的权限过滤会扩展成完整安全策略和人工审批流程。
第 2.16 章：综合知识库 Agent 方法本章能力会和工具调用、状态图、前端工作台组合成完整项目。

岗位 JD（职位描述） 能力映射​

RAG 岗位常把“检索优化”“Embedding（嵌入向量）”“重排序”和“评估”写成一句话。本章要把这句话拆成可证明的工程能力。

JD（职位描述）常见要求本章对应能力面试证据
优化 RAG 召回和回答质量能区分分块、召回、过滤、重排和生成问题用检索日志判断正确片段卡在哪一环。
设计 Embedding（嵌入向量）和 Reranker（重排序器）方案能说明语义召回、关键词召回、重排和上下文截断的边界展示召回结果契约和重排与引用契约。
建设可评估的知识库检索链路能准备问题、期望 chunk_id（分块编号）、不应命中片段和通过规则用评估样例证明优化不是凭感觉。
处理权限、旧版资料和错误产品线命中能用元数据过滤和引用权限控制资料适用性展示产品线、版本、状态、有效期和可见范围字段。

版本与资料来源​

本节聚焦 RAG 检索链路的工程设计、字段契约、权限过滤、失败兜底和面试表达。

过时风险：Embedding（嵌入向量）模型、重排序模型、向量数据库索引能力和模型供应商检索接口更新较快。进入真实项目开发前，必须重新核对当前官方文档、模型版本、计费方式和向量数据库能力。

继续学习​