跳到主要内容

第 2.1.3 节：把资料契约、检索、生成和引用接成回答链路

资料契约、检索、生成与引用不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够把资料契约、检索、生成与引用落成字段表、校验规则、错误处理和验收样例。

实现步骤或决策流程​

推荐技术流​

本章推荐的 RAG（检索增强生成）技术流如下：

步骤做什么为什么
1定义问题边界先确定哪些问题走 RAG，避免把所有客服任务都塞进知识库。
2盘点资料来源明确售后政策、产品说明、FAQ（常见问题）、话术和内部流程从哪里来。
3设计资料状态和权限区分草稿、待审核、已发布、已失效，以及外部客户和内部客服的可见范围。
4解析和清洗资料把文档、网页、表格和手册转成可处理内容。
5分块和写入元数据让每个知识片段都有来源、版本、权限、标题和生效时间。
6生成 Embedding（嵌入向量）并建立索引支持语义检索和相似问题召回。
7查询改写和检索把用户问题转成适合检索的查询，并召回候选片段。
8重排序和阈值判断过滤低质量命中，判断是否有足够依据。
9生成带引用回答基于片段回答，不编造资料外承诺。
10记录日志和收集反馈支持质检、复盘、资料修正和持续优化。

这条技术流不是为了堆组件，而是为了保证一个核心结果：每个企业知识回答都能说清楚依据、版本、权限和置信边界。

字段契约​

本节不写代码，只用字段契约表说明系统要对齐哪些信息。字段契约的作用是让前端、后端、模型调用、知识库管理和日志审计都说同一种语言。

读图重点：读表时抓住三条线：document_id 管资料版本，chunk_id 管证据定位，trace_id 管一次请求从检索到回答与复盘。

资料文档契约​

每份进入知识库的资料都应该有稳定字段。

字段含义来源是否必填验收要求
document_id（资料编号）唯一标识一份资料系统生成是同一资料不同版本能关联。
title（标题）资料名称上传者填写或系统提取是用户和客服能看懂。
source_type（来源类型）文档、网页、FAQ（常见问题）、手册、运营配置等上传入口是方便按类型管理。
owner（负责人）谁负责资料准确性管理员指定是出错后能找到责任人。
version（版本）资料版本上传或发布流程是回答引用必须能追溯版本。
status（状态）草稿、待审核、已发布、已失效资料治理模块是只有已发布资料能进入正式问答。
effective_at（生效时间）资料从何时生效运营或审核设置视情况防止提前引用未生效政策。
expired_at（失效时间）资料何时失效运营或审核设置视情况防止引用过期资料。
visibility（可见范围）外部客户、客服、主管、内部管理等权限配置是控制检索和引用展示。
department（适用部门）售前、售后、物流、投诉等管理员指定否支持部门级知识库。

知识片段契约​

RAG 真正检索的通常不是整份文档，而是知识片段。

字段含义为什么重要
chunk_id（分块编号）唯一标识一个片段引用和日志需要精确到片段。
document_id（资料编号）片段属于哪份资料方便追溯原文。
chunk_text（片段正文）可用于生成回答的正文模型回答的主要依据。
heading_path（标题路径）片段所在章节层级帮助用户理解上下文。
version（版本）片段对应资料版本防止新旧政策混用。
visibility（可见范围）谁能检索和查看权限控制基础。
effective_range（生效范围）生效和失效时间政策问答尤其重要。
embedding_status（向量状态）未生成、已生成、失败、需更新判断索引是否可用。
quality_flags（质量标记）内容过短、重复、疑似冲突、缺少标题等辅助运营修正资料。

检索请求契约​

用户每问一个问题，系统都应该形成一次检索请求。

字段含义来源验收要求
trace_id（追踪编号）串联一次请求系统生成能从用户问题追到检索、回答和日志。
user_id（用户编号）当前用户身份登录系统匿名用户也要有会话标识。
role（角色）外部客户、客服、管理员等权限系统影响资料可见范围。
question（原始问题）用户输入用户入口日志中可脱敏保存。
intent_type（意图类型）资料问答、订单查询、投诉、闲聊等问题分流层决定是否进入 RAG。
retrieval_scope（检索范围）产品、售后、FAQ（常见问题）、内部流程等系统判断或用户选择避免全库乱搜。
permission_filter（权限过滤）当前用户可看的资料范围权限系统必须强制执行。
top_k（召回数量）召回多少候选片段系统配置太少容易漏，太多容易噪声。

检索结果契约​

检索结果不能只有文本。它必须带上足够的依据和判断字段。

字段含义给谁使用
chunk_id（分块编号）命中的知识片段引用、日志、质检。
document_title（资料标题）来源资料名称用户、客服、质检。
version（版本）来源资料版本判断资料是否最新。
score（相关性分数）检索相关程度重排序和阈值判断。
rerank_score（重排序分数）重排序后的可信程度决定是否进入生成。
matched_text（命中内容摘要）片段摘要模型和引用展示。
visibility（可见范围）引用能否展示给当前用户前端和权限模块。
citation_label（引用标签）用户看到的引用名称回答展示。

回答契约​

最终回答也要有结构，不只是自然语言。

字段含义验收要求
answer（回答正文）给用户看的回复必须基于检索依据，不夸大承诺。
answer_type（回答类型）直接回答、带引用回答、拒答、转人工建议便于前端展示和统计。
citations（引用列表）资料标题、版本、片段编号和可展示摘要每个关键结论应能追溯。
confidence_level（置信等级）高、中、低或不足低置信度不能装作确定。
missing_info（缺失信息）需要用户补充什么用于追问。
handoff_reason（转人工原因）为什么需要人工质检和客服接管。
trace_id（追踪编号）关联请求链路方便复盘。

字段契约的核心价值是：让 RAG 从“模型随便答”变成“系统有证据地答”。

制作步骤​

下面是把本章落成作品集项目的推荐制作步骤。它不讲代码语法，只讲工程顺序和交付物。

第 1 步：定义 RAG（检索增强生成）问题边界​

先列出客服系统里的问题类型，并明确处理方式。

问题处理方式边界说明
产品功能介绍RAG依据产品说明书和 FAQ（常见问题）。
售后政策说明RAG必须引用最新已发布政策。
通用概念解释普通模型回答或 RAG如果涉及公司承诺，必须走 RAG。
订单物流查询工具调用需要实时订单数据。
创建投诉工单工具调用 + 用户确认会写入业务系统。
退款、补偿、赔付工具调用 + 人工审批不能由 RAG 直接决定。

这一步要产出一张分流表。它会成为后续系统设计、验收和面试讲法的基础。

第 2 步：盘点资料来源​

不要直接上传一堆文件。先盘点资料。

资料类型示例负责人可见范围
售后政策退换货、保修、维修流程售后运营外部客户和客服。
产品资料产品说明书、参数、适用人群产品运营外部客户和客服。
客服话术标准回复、安抚话术客服主管仅内部客服。
投诉流程升级规则、证据要求质检负责人客服和主管。
FAQ（常见问题）高频问题和标准答案运营人员视问题决定。

每类资料都要明确负责人。没有负责人的资料，后续出错没人能改。

第 3 步：设计资料发布流程​

推荐最小发布流程如下：

阶段做什么验收标准
上传管理员上传资料或录入 FAQ（常见问题）有标题、来源、负责人和可见范围。
解析系统提取正文、标题、段落和表格能预览解析结果。
审核负责人确认内容准确未审核资料不能用于正式回答。
发布设置版本和生效时间只有已发布资料进入检索。
索引分块并生成 Embedding（嵌入向量）索引状态成功。
复盘根据问答日志修正资料错误回答能追到资料或检索问题。

这个流程看起来比“上传即问答”麻烦，但它是企业知识库可上线的基础。

第 4 步：设计分块和元数据​

分块的详细策略会在后续章节展开。本章先强调：每个片段都要带元数据。

至少要保留：

  • 资料编号。
  • 资料标题。
  • 章节路径。
  • 版本。
  • 生效时间。
  • 可见范围。
  • 负责人。
  • 片段质量标记。

没有这些元数据，后面就无法做权限过滤、版本判断、引用展示和错误复盘。

第 5 步：设计检索与重排序​

检索不是“搜出来几个片段就交给模型”。推荐处理顺序是：

  1. 根据用户角色过滤资料范围。
  2. 根据问题类型缩小资料类型。
  3. 召回候选片段。
  4. 用重排序判断片段和问题的匹配程度。
  5. 检查是否达到回答阈值。
  6. 检查资料是否冲突或过期。
  7. 决定生成回答、追问、拒答或转人工。

这一步要产出检索验收样例。例如同一个问题在外部客户和内部客服角色下，能看到的资料和引用应该不同。

第 6 步：设计生成和引用​

生成阶段要遵守 5 条规则：

  • 只基于可见资料回答。
  • 关键结论必须有引用。
  • 不把内部资料泄露给外部用户。
  • 资料没有说明时要明确说不知道。
  • 涉及订单、退款、审批时切到工具或人工。

引用展示也要分角色。客服内部可以看到资料标题、版本、片段摘要和负责人；外部客户可能只看到公开政策标题和更新时间。

第 7 步：设计反馈闭环​

RAG 不是一次上线就结束。你要设计反馈入口：

反馈来源可能问题后续动作
用户点“没帮助”回答不相关或不完整进入质检队列。
客服标记错误引用错资料或政策过期修正资料或索引。
系统拒答过多资料覆盖不足补充 FAQ（常见问题）和政策资料。
转人工过多分流或检索阈值不合理调整策略。
引用冲突新旧资料并存清理版本和失效资料。

反馈闭环是作品集里很加分的部分。它说明你不是只做演示，而是理解知识库需要运营。

第 8 步：设计验收问题集​

验收不能只让业务方随便问。要准备问题集。

验收类型示例期望行为
正常命中“A 产品保修多久？”回答并引用产品保修资料。
无资料命中“你们明年会不会涨价？”不猜测，说明没有依据。
资料过期“旧版政策里的条款还有效吗？”引用最新有效资料或转人工。
权限控制外部客户问内部升级规则不泄露内部资料。
工具分流“我的订单到哪了？”不走 RAG，转工具调用。
人工兜底“我这个争议赔多少？”不直接承诺，转人工。

验收问题集要覆盖成功、失败、权限、过期、冲突、工具分流和人工兜底。只测成功路径没有意义。

和后续章节的关系​

本章是第 2 卷工程能力的起点。后续章节会沿着本章边界继续深入。

后续章节和本章的关系
文档解析与资料治理解决资料从哪里来、如何清洗、如何发布。
分块、Embedding（嵌入向量）、索引与重排解决检索效果为什么好或不好。
向量数据库与混合检索解决如何存储和召回知识片段。
RAG 评估解决如何验收命中率、引用准确率和拒答质量。
MCP（模型上下文协议）基础与工具生态解决知识、工具和上下文如何标准化暴露。
LangGraph（智能体状态图框架）状态图解决 RAG、工具调用和人工流程如何编排。
权限、安全和可观测性解决资料泄露、日志审计和线上排查。

如果说本章是在画边界，后续章节就是把边界里的每个模块做扎实。

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

面试里，面试官通常不会只问“RAG 是什么”，而是看你能不能把知识库项目讲成可交付系统。本章可以对应到这些岗位能力。

JD（职位描述）常见要求本章对应能力面试证据
设计 RAG 或 Agent（智能体）应用架构能把普通回答、RAG、Tool Calling（工具调用）和人工处理分流画出客服工作台问题分流图，并说明哪些问题不能走 RAG。
建设企业知识库问答系统能设计资料来源、发布状态、权限、引用和日志展示资料文档、知识片段、检索请求和回答契约。
处理幻觉、无依据回答和权限风险能定义拒答、转人工、低置信度和权限不足兜底用失败场景表说明系统什么时候必须停下来。
与业务方沟通需求和验收标准能把客服问题转成验收问题集准备成功、无命中、过期、冲突、工具分流和人工兜底样例。

版本与资料来源​

本节聚焦 RAG 的问题边界、系统结构、字段契约、权限状态、失败兜底和面试表达。

过时风险：Embedding（嵌入向量）模型、向量数据库能力、检索重排序方法和模型供应商的文件检索接口都会持续变化。进入真实项目开发前，必须重新核对官方文档、当前模型能力和企业内部安全要求。

继续学习​