AI 原生开放教材

外观

Easy-Vibe（Datawhale：从零做出真实产品）课时教程·中英混排原文 ↗原件 ↓仓库 ↗

8. 检索增强与知识层（Retrieval & Knowledge） ​

在前面的视觉与理解层中，模型主要依赖“自身参数里学到的知识”来理解和生成内容。但在真实业务里，很多问题并不能只靠“记忆”解决：企业内部制度每天在变、法规和行业标准持续更新、某个客户的历史记录只存在于内部数据库。这时，仅靠模型“背过”的知识远远不够，更关键的是能否在 外部知识库、结构化数据和图谱上进行高效检索与推理 。

可以把这一层理解为：在模型能力之上，再加一层“会查资料、会用数据库的外脑”。当用户提出问题时，系统不再直接生成答案，而是先去合适的数据源里“翻资料”：文档库、数据库、搜索引擎、知识图谱、日志与业务系统……然后再让模型基于真实检索到的内容来给出回答与决策。这样不仅能显著提升准确性和时效性，还能在很大程度上提升可解释性和合规性（例如可引用出处、保留执行 SQL 记录等）。

围绕这一层，常见能力大致可以分为两个方向：一是 检索增强生成（RAG） ，主要面向“自然语言问答 + 文档/知识库检索”；二是 结构化数据与知识图谱（Structured Data & KG） ，负责对数据库、图数据库和领域知识中台进行更精准、可控的访问与推理。下面分别展开。

8.1 检索增强生成（RAG） ​

RAG（Retrieval‑Augmented Generation）可以看作是“会查资料的 LLM”。与纯粹依赖模型内部参数不同，RAG 在回答每一个问题前，都会先去外部知识库做检索，把与问题最相关的若干段文档片段（chunk）找出来，然后再把这些检索到的内容作为“上下文”喂给 LLM，让它在“看过资料”的基础上生成答案。对于企业知识库问答、行业报告搜索、法律/医疗/金融专业问答、内部文档搜索机器人等场景，RAG 已经成为默认范式。

在系统架构上，典型 RAG 可以拆解为三层： 索引构建层、检索层、生成层 。前两层主要是“查得准”，后一层则负责“说得清”。下面从这三层来展开，并在二级小节中进一步细化核心设计与实践。

  • 场景
    • 企业内部知识问答：员工用自然语言提问制度流程、技术文档、项目资料，系统基于内部文档与 Wiki 检索相关内容后，由 LLM 生成清晰回答并附带引用。
    • 行业报告与研究搜索：在大量 PDF、报告和论文中检索某个行业问题的相关内容（如“新能源车补贴政策变化”），并自动总结、对比和列出处。
    • 法律 / 医疗 / 金融领域问答：基于法规条文、判决文书、临床指南、产品说明书等权威材料进行检索增强，降低“胡编乱造”的风险。
    • 内部文档 / 工单搜索机器人：帮助运营、客服、研发快速在知识库、工单和变更记录中定位答案，并以自然语言总结结果。
  • 原理 RAG 的核心思想是把“知识存贮在外部，推理交给模型”：
    • 将非结构化文档（PDF、网页、Word、技术文档等）拆成适合检索的文档块（chunk），用 Embedding 模型将其映射到向量空间，并构建向量索引（如 FAISS、Milvus、PGVector 等）。
    • 在用户查询时，同时利用语义向量检索与关键词检索（Hybrid Search），找到与问题最相关的若干文档块，并根据相关性和覆盖度做重排序（Re‑ranking）。
    • 将检索到的上下文、用户提问、以及必要的系统指令/格式约束一起输入 LLM，由模型在“可见证据”的约束下进行回答，并在输出中引用出处（source citation），以提升可解释性和可审计性。
  • 模型 典型 RAG 系统往往是一个 模型组合架构 ：
    • Embedding 模型：用于将查询和文档块编码到同一个语义空间，是向量检索效果的关键（包括通用 Embedding 和领域定制 Embedding）。
    • 检索与重排模型：Hybrid Search（如 BM25 + Vector）负责第一轮召回，Cross‑Encoder Re‑ranker 或 LLM 本身用于对召回结果做更精细的重排序。
    • 生成模型：LLM 在给定检索上下文的前提下进行回答；在更复杂的 RAG / HyDE / ReAct + RAG 中，LLM 还会参与“伪文档生成”“多轮工具调用”“思考 + 检索交替”等过程，以提高召回、减少遗忘和增强推理能力。

8.1.1 索引构建与知识资产整理 ​

在任何 RAG 系统中，索引构建都是基础。没有高质量的索引，后续再强大的 LLM 也只是“巧妇难为无米之炊”。索引构建的目标，是把杂乱无章的文档资源转化为“可检索、可维护、可扩展的知识资产”。

从流程上看，典型索引构建包括以下几个关键步骤：

  1. 文档分块与预处理 文档往往是长篇 PDF、PPT、Word 或网页，如果直接对整篇文档做向量化，既容易造成“稀释”（一篇文档包含多个主题），也不利于高效检索。因此需要：
    1. 按段落、标题、页码、章节结构进行分块，平衡“语义完整度”和“块大小”；
    2. 处理格式问题（表格、公式、图片中的文字 OCR）、去噪（页眉页脚、目录、版权信息等）；
    3. 为每个块生成“上下文标签”（如所属文档、章节标题、页码），为后续解释与引用做好准备。
  2. Embedding 与向量索引 在分块基础上，对每个文档块生成语义向量：
    1. 选择合适的 Embedding 模型（如通用语义 Embedding、领域微调模型），确保对目标语言和领域术语有良好表达能力；
    2. 使用 FAISS、Milvus、PGVector 等构建高维向量索引，支持大规模数据下的近似最近邻检索；
    3. 处理多版本与增量更新：当文档更新时，需要支持增量重建索引、版本记录和旧版本清理策略。
  3. 元信息索引与过滤 单纯的语义向量并不足以应对复杂过滤需求，通常还需要构建 元信息索引 ：
    1. 为每个文档块补充时间、作者、来源、文档类型、业务线、敏感级别等元数据；
    2. 支持在检索时基于元信息进行预过滤（如时间范围、部门、权限等级），减少无关结果；
    3. 为权限控制与审计打下基础，避免 RAG 在回答中泄露用户无权访问的内容。

8.1.2 检索与重排序：从“召回相关”到“找到最合适的证据” ​

在索引构建完成后，当用户发起查询，就进入检索与重排序阶段。这里的关键不只是“找一些相关文档”，而是要尽可能找到 既相关又覆盖充分、且支持推理的证据组合 。

  1. Hybrid 检索：向量 + 关键词的互补 纯向量检索擅长捕捉语义相似度，但对于精确术语、代号、表格字段等，关键词检索（如 BM25）往往更稳健。因此工程实践中普遍采用 Hybrid Search：
    1. 首先对查询分别进行向量检索和关键词检索，得到两组候选文档块；
    2. 使用加权打分或学习到的融合策略，将两路候选合并；
    3. 在一些场景中，可根据查询类型（FAQ 问答 vs. 法条定位）动态调节向量与关键词检索的权重。
  2. 重排序（Re‑ranking）：更精细地挑选“证据集” 初始检索结果往往包含不少“边缘相关”或“冗余”文档块，需要重排序来提升最终 Top‑K 的质量：
    1. 使用 Cross‑Encoder（交叉编码器）对“查询–文档块”对进行双向编码和相关性打分，相比双塔 Embedding 模型精度更高，但开销较大，适合作为二阶段重排；
    2. 在性能允许时，引入 LLM 进行轻量级重排，让模型基于更丰富的语义和上下文信息来判断哪些块真正“有用”；
    3. 同时考虑覆盖度与多样性，避免所有检索块都集中在同一文档或同一段落，从而导致回答视野过窄。
  3. 检索–生成闭环优化 更高级的实践中，检索和生成不再是单向流程，而是形成闭环：
    1. 利用 LLM 对检索结果的“使用情况”进行分析（哪些块被引用、哪些块总是被忽略），反向指导索引和分块策略的优化；
    2. 利用对话日志中的“追问/纠错”信号，对召回失败、误召回的样本进行标注和再训练，提高系统对模糊查询、长尾问题的鲁棒性。

8.1.3 生成与引用：在“证据约束下”回答问题 ​

最后一环是生成层，它直接决定了用户体验。这里的目标不是让模型“随心所欲”地发挥，而是让它在 检索证据的约束下，给出清晰、有边界、有引用的回答 。

  1. 基于检索上下文的受控生成 在 RAG 架构中，LLM 接收到的不只是用户问题，还包括多段检索到的文档块以及系统指令。系统通常会：
    1. 通过 Prompt 约束模型“只根据给定文档回答”“如果文档中找不到答案就明确说明缺失”；
    2. 对检索上下文进行结构化组织（分段、编号、标注来源），方便模型理解与引用；
    3. 控制输出格式（列表、表格、分点说明等），适配下游系统或前端展示。
  2. 引用与可解释性（Source Citation） 为了便于审计与追溯，尤其在法律、医疗、金融、企业内部制度等高风险领域，回答中往往需要附带明确引用：
    1. 在输出中标注引用来源，如“[文档 A，第 3 章，第 2 节]”“[法规 X 第 12 条]”；
    2. 在前端界面中支持一键跳转到原文位置，便于用户核查和进一步阅读；
    3. 在后台保存“问题–检索结果–引用块–最终回答”的完整链路日志，为后续风控和模型改进提供数据。
  3. 先进 RAG 变体：HyDE / ReAct + RAG 等 为进一步提升难题场景下的效果，实践中还会使用更复杂的 RAG 变体：
    1. HyDE：由 LLM 先根据问题生成一个“假想答案文档”，再用该文档向量去检索真实文档，从而提高召回质量；
    2. ReAct + RAG：LLM 以“思考（Reasoning）+ 行动（Action）”的方式，在推理中多次调用检索工具，逐步细化问题、补充证据，类似“边思考边查资料”；
    3. 多轮 RAG：在对话过程中，保留历史检索结果和回答，形成上下文感知的长期知识会话，而不仅是“单问单检索”。

8.2 结构化数据与知识图谱（Structured Data & KG） ​

如果说 RAG 主要解决“如何在大规模非结构化文档中查资料”，那么结构化数据与知识图谱这一层，则更多面向“如何优雅地用好数据库、报表系统和图数据库中的结构化知识”。

在企业环境中，真正关键的业务数据——订单、客户、合同、库存、行为日志——往往以关系数据库、数据仓库、OLAP 引擎或图数据库的形式存在。这些系统在查询能力、计算效率和审计方面已经非常成熟，但对于业务人员而言，直接写 SQL / DSL 仍然门槛较高。Text‑to‑SQL / Text‑to‑DSL 与 知识图谱问答与推理 ，就是要让 LLM 在不破坏这些系统稳定性的前提下，作为“自然语言界面”和“推理协作伙伴”插入进来。

  • 场景
    • BI 智能问答与自助分析：业务人员用自然语言发问（如“帮我看看最近 3 个月华东地区新客的复购率趋势”），系统自动生成 SQL，查询数据仓库，然后用自然语言和可视化图表返回结果。
    • 运营 / 销售分析助手：运营同学可以用对话的方式探索数据（“这个活动转化率为什么下降”“哪些渠道贡献了最多高价值用户”），在多轮对话中逐步细化条件和维度。
    • 领域知识中台：将实体、概念、规则和案例组织为知识图谱，支持围绕某个实体进行上下游关系探索和合规性检查。
    • 图数据库问答与推理系统：在风险控制、反洗钱、供应链分析等场景中，通过图数据库与 LLM 联合，对“关系链条”和“多跳推理”类问题进行回答与解释。
  • 原理 这一层的核心，是把 LLM 从“直接给答案的人”变成“会调用数据库与图数据库的助手”：
    • 在数据库问答中，模型需要理解用户的自然语言意图，结合数据库 schema（表结构、字段含义、约束等），生成正确的 SQL / GraphQL / 内部 DSL，再对执行结果进行解释与可视化。
    • 在知识图谱场景中，系统需要先从文档和日志中抽取实体和关系，构建结构化图谱；然后在问答时由 LLM 负责把自然语言问题转译为图查询（如 Cypher），并基于查询结果进行多跳推理和解释。
    • 与 RAG 不同，这里强调的是 对结构化数据与图结构的精确访问 ，一方面要保证语义正确、语法严谨，另一方面要控制侧写攻击、敏感数据暴露和高成本查询。
  • 模型 典型方案通常是“LLM + 专用组件”的多模块架构：
    • Text‑to‑SQL 模型：在大规模 SQL 语料上预训练或微调的模型（如 PICARD、DIN‑SQL 等），侧重语法正确性与 schema 对齐，有时会搭配执行反馈进行自我修正。
    • 信息抽取与图谱构建 pipeline：通过实体识别（NER）、关系抽取、事件抽取等模块，从文本和日志中构建和更新知识图谱；LLM 可以参与难例抽取、边界模糊关系的辅助判断。
    • LLM + 图数据库联合问答：LLM 负责问题解析、查询生成与结果解释，图数据库（如 Neo4j 等）负责高效执行与多跳关系搜索，两者通过工具调用协议或中间 DSL 对接。

8.2.1 数据库问答（Text‑to‑SQL / DSL）实践 ​

数据库问答的目标，是让业务人员“用自然语言问数据”，而系统在背后自动完成查询语句生成、执行与解释。要把这件事做好，关键在于兼顾 语义准确性、语法正确性和执行安全性 。

  1. 自然语言到 SQL / DSL 的转换 在最基础的链路中，系统需要：
    1. 解析用户意图：识别出查询对象（如“华东地区新客”）、过滤条件（时间、地区、渠道）、聚合方式（总数、平均值、同比/环比）和展示需求（趋势、排行、Top‑N）；
    2. 结合数据库 schema：理解哪些表与字段可以表达上述概念，如何进行关联（join）、分组（group by）和排序；
    3. 生成可执行的 SQL / GraphQL / 内部 DSL，并通过语法校验器或专门的 Text2SQL 模型（PICARD、DIN‑SQL 等）确保结构合法。
  2. 执行结果的自然语言解释与可视化 查询执行后，系统还需把“冷冰冰的结果集”变成“可理解的洞察”：
    1. 对简单结果进行文本解释，如“过去 3 个月华东地区新客的复购率整体呈上升趋势，从 15% 提升到 21%”；
    2. 对复杂结果选择合适的可视化形式（折线图、柱状图、饼图、分布图等），并给出简要分析；
    3. 支持用户基于当前结果继续追问（如“这波增长主要来自哪些渠道？”），自动在历史 SQL 和上下文的基础上构造新的查询。
  3. 安全与控制：防止“乱查”和“越权” 由于 LLM 生成的 SQL 具有高度灵活性，必须有一层安全与治理机制：
    1. 基于用户角色与权限，对可查询的库、表、字段和时间范围做严格限制；
    2. 为模型生成的 SQL 配备静态/动态审查规则，过滤危险操作（如大范围扫描、高成本 join、跨租户查询等）；
    3. 将“自然语言问题–生成 SQL–执行结果–最终回答”完整记录，用于审计与异常分析。

8.2.2 知识图谱构建与查询 ​

知识图谱试图把散落在文本、表格、日志中的知识，组织成“实体–关系–属性–事件”的结构化网络，从而更好地支持 关系探索、多跳推理和复杂问答 。在这一方向上，LLM 与传统信息抽取、图数据库形成了良好的互补。

  1. 从文档中抽取实体和关系构建图谱 构建知识图谱通常采用多阶段 pipeline：
    1. 信息抽取：利用 NER、关系抽取、事件抽取等模型，从文本中识别实体（人、机构、产品、地名、概念等）、它们之间的关系（隶属、合作、依赖、因果）以及关键事件（交易、风险、变更）；
    2. 规范化与对齐：将同一实体的不同表述（简称、别名、拼写变体）进行归一，对齐到统一 ID；
    3. 图谱更新与版本管理：支持增量更新、冲突解决和错误纠正，确保图谱在长期演化中保持质量与一致性。LLM 可以在歧义消解、关系类型细化、规则归纳等环节辅助传统算法。
  2. LLM + 图数据库（Neo4j 等）的查询与推理 当图谱构建完毕，图数据库负责高效存储和检索，而 LLM 则可以扮演“自然语言入口 + 推理控制器”的角色：
    1. 问题解析与图查询生成：将自然语言问题转译为图查询语句（如 Neo4j 的 Cypher），包括确定起点实体、关系类型、路径长度与过滤条件；
    2. 多跳推理：通过图查询得到的路径和局部子图，再由 LLM 进行解释与归纳，如“客户 A 与高风险实体 B 之间通过三家公司间接相连”；
    3. 结果可视化与可解释性：将图查询结果以可视化网络形式呈现，同时由 LLM 给出口头说明，帮助用户理解复杂关系结构。
  3. 领域知识中台与统一服务 在更大规模的企业或行业级应用中，知识图谱往往作为“领域知识中台”存在：
    1. 为上层业务系统（风控、合规、客户 360 视图、供应链分析等）提供统一的实体和关系视角；
    2. 与 RAG、数据库问答共同构成统一的知识服务层，由统一的 LLM 编排逻辑决定当前问题该访问文档索引、关系数据库还是图数据库；
    3. 在安全和合规要求下，通过图谱层面的访问控制和脱敏策略，进一步降低敏感信息泄露的风险。

这一层的共同目标，是把“模型会说话”升级为“模型既会说话，又真正接上了企业的真实数据与知识资产”。当 RAG、Text‑to‑SQL、知识图谱与传统数据基础设施有效结合之后，AI 系统才能在复杂业务环境中既保持智能和灵活性，又具备可控性、可解释性和长期演化能力。