面向程序员 · LLM 工程基础课

RAG 和知识库：让 AI 基于资料回答

RAG 的核心很朴素：不要让模型凭记忆硬答。先从知识库、文档、接口说明和业务系统里找资料，再把资料放进上下文，让模型基于这些资料生成答案。

RAG 不是训练模型 它通常不改模型参数，而是在推理时把相关资料找出来，交给模型参考。

知识库质量决定上限 文档过期、切片混乱、权限不清，模型回答再漂亮也可能不可靠。

检索不是只看向量 企业系统常用向量、关键词、过滤器和重排一起做，避免查错资料。

答案要带来源 没有引用来源的回答很难审查。RAG 最好能让每条关键结论追到 sourceId。

rag.answer(question) grounded

Query

用户问题：商品导入失败怎么处理？

input

Retrieve

检索字段字典、历史 PRD、接口文档。

topK

Context

按来源、版本、权限组装上下文。

rank

Answer

模型基于资料回答，并标注 sourceId。

cite

01 · 先给定义

RAG 是检索增强生成

RAG 的英文是 Retrieval-Augmented Generation。直译不重要，理解方式很简单：先检索，再生成。模型不直接凭训练记忆回答，而是参考你给它找出来的资料。

Retrieval

检索

从知识库、文档库、数据库或接口里找和问题相关的资料。

Augmented

增强

把检索到的资料放进上下文，补足模型本次回答所需的事实。

Generation

生成

让模型基于问题和资料生成答案、摘要、结构化结果或草稿。

Grounding

有依据

关键结论最好能追到来源。没有资料依据的内容要标成待确认。

一句话记住 RAG 不是让模型“记住更多东西”，而是让系统在回答前先查资料。模型负责组织语言和推理，知识库负责提供可追溯的事实。

02 · 为什么需要 RAG

企业知识变化快，不能全靠模型记忆

模型训练完成后，不会自动知道你公司今天更新的字段、接口、价格策略和审批流程。企业应用如果要回答最新、准确、可审查的问题，必须接入外部知识来源。

不接 RAG

模型按常见模式回答

用户：商品导入失败后是否支持下载错误明细？
模型：支持，可通过错误明细接口下载失败行。

接口可能不存在。
权限规则可能不符合企业现状。
回答听起来完整，但无法追溯来源。

接入 RAG

先查资料再回答

检索结果：
sourceId: prd-import-v2
内容：导入失败后展示错误行数，暂不支持下载明细。

回答：
当前资料显示暂不支持下载错误明细。
依据：prd-import-v2。

答案更短，但更可靠。缺少资料时，也能明确说待确认。

03 · RAG 完整链路

RAG 不是一个向量库，而是一条工程链路

真正的 RAG 系统有两条链路：离线把知识整理进库，在线根据问题检索并回答。任何一步质量差，最终答案都会受影响。

1 采集文档 制度、PRD、接口、FAQ、代码说明。

2 清洗切片 去噪、分段、保留标题和来源。

3 建立索引 向量索引、关键词索引、元数据索引。

4 查询改写 把用户问题改成适合检索的查询。

5 检索重排 召回候选片段，再按相关性排序。

6 生成回答 组装上下文，引用来源，输出结果。

离线链路

负责把资料变成可检索的知识库。重点是文档质量、切片策略、权限、版本和增量更新。

在线链路

负责针对用户问题找资料并生成答案。重点是召回、排序、上下文预算、引用和失败处理。

04 · 知识库建设

知识库不是把文档丢进去就完了

知识库要服务检索。文档如果没有来源、版本、权限和结构，模型就很难基于它可靠回答。知识库越像一个有治理的数据产品，RAG 效果越稳。

应该入库什么

业务制度、操作手册、FAQ、培训材料。
PRD、需求评审记录、历史决策。
字段字典、枚举、权限配置说明。
接口文档、错误码、状态机。
产品公告、变更记录、上线说明。

sourceId 每个片段都要能追到原文和版本。

version 过期文档要标记，不要和最新文档混在一起。

permission 用户无权看的资料，不能被检索进上下文。

metadata 业务域、系统名、更新时间、文档类型都能帮助过滤。

知识库治理很重要 RAG 的问题经常不在模型，而在资料。旧文档没下线、权限没过滤、标题丢失、切片太碎，都会让回答变差。

05 · 切片和向量化

切片决定模型能不能拿到完整语义

向量化前要先切片。切得太碎，模型拿不到上下文；切得太大，检索不准又浪费 token。好的切片会保留标题、层级、来源和相邻上下文。

太碎

只剩零散句子

“支持导入。”这类片段缺少字段、权限和异常规则，模型很难判断适用范围。

太大

整章塞进去

一个片段包含多个主题，向量相似度可能被稀释，还会占用大量上下文。

合适

按语义块切

围绕一个规则、流程、接口或 FAQ 切片，同时保留标题和 sourceId。

一个切片示例

{
  "chunkId": "product-import-prd-v2#sec-3.2",
  "title": "商品批量导入：失败处理",
  "content": "导入失败时，系统展示失败行数和错误原因。当前版本不支持下载错误明细。",
  "sourceId": "product-import-prd-v2",
  "system": "product-center",
  "updatedAt": "2026-05-20",
  "permissions": ["product", "rd", "qa"]
}

06 · 检索和重排

检索要先召回，再挑最适合的资料

向量检索擅长语义相似，关键词检索擅长精确字段。企业问题经常同时需要两者。召回候选片段后，还可以用重排模型或规则按相关性、版本、权限和来源可信度排序。

检索方式	擅长什么	容易出什么问题	适合场景
向量检索	找语义相近内容	字段名、编号、接口路径可能不够准	FAQ、制度、需求说明
关键词检索	找精确词、字段、编号	同义表达召回弱	SKU、接口名、错误码、枚举
元数据过滤	按系统、权限、版本、时间过滤	元数据缺失会过滤错	多系统、多权限知识库
重排	从候选里挑最相关的片段	增加延迟和成本	高价值问答、复杂检索

混合检索更稳

candidates = [
  ...vectorSearch(query),
  ...keywordSearch(query),
  ...filterByMetadata(system, permission, version)
];

ranked = rerank(query, dedupe(candidates));

不要只看相似度分

相似度高不代表适用。旧版本文档、相邻系统文档、无权限文档，都可能和问题很像，但不能直接放进上下文。

07 · 上下文组装

把资料放进上下文时，要控制顺序和预算

检索到资料后，不是全塞给模型。要按任务组织上下文：先放任务和边界，再放最相关资料，最后说明引用规则和不确定项处理。

你是企业商品系统问答助手。

回答规则：
- 只能基于 <sources> 中的资料回答。
- 如果资料不足，回答“资料不足”，并列出需要补充的信息。
- 每个关键结论必须带 sourceId。
- 不要编造接口、字段、权限点。

<question>
商品导入失败后是否支持下载错误明细？
</question>

<sources>
[sourceId=product-import-prd-v2]
导入失败时，系统展示失败行数和错误原因。当前版本不支持下载错误明细。
</sources>

资料要有边界

用 sources 标签、sourceId 和标题把资料包起来，避免和用户指令混在一起。

关键规则靠近任务

“只能基于资料回答”“缺资料要说明”这类规则要放清楚。

给输出留空间

资料太多会挤占输出预算，也可能让模型忽略重点。

08 · 引用和可信度

RAG 答案最好能追到来源

企业场景里，引用不是装饰。引用让答案可审查、可纠错、可回放。没有来源的答案，出了问题很难判断是模型编的、资料错的，还是检索错的。

弱引用

只说“根据资料”

根据资料，当前版本不支持下载错误明细。

看起来有依据，但无法定位具体文档和版本。

强引用

带 sourceId 和结论

{
  "answer": "当前版本不支持下载错误明细。",
  "citations": [
    {
      "sourceId": "product-import-prd-v2#sec-3.2",
      "quote": "当前版本不支持下载错误明细"
    }
  ],
  "confidence": "high"
}

后续能定位、复查，也能把错误来源修回知识库。

引用也要校验 模型可能引用不存在的 sourceId。后端要检查 sourceId 是否来自本轮检索结果，不能让模型随便写。

09 · 评测和排查

RAG 要分别评测检索和生成

最终答案错了，不一定是模型生成错。可能是没检索到资料，检索到了旧资料，重排错了，权限过滤错了，或者 Prompt 没要求基于资料回答。

召回率 正确资料有没有被检索出来。

命中排名 正确资料是否排在前面，能进入上下文。

依据一致性 答案是否真的基于引用资料。

拒答质量 资料不足时是否能承认不足，而不是硬编。

问题现象	可能原因	排查方向
回答说法过期	旧文档被检索进上下文	检查版本元数据、更新时间过滤、文档下线流程。
答案没有引用	Prompt 没强制 sourceId，后端没校验	增加引用要求，校验 sourceId 来自本轮检索。
相关资料没召回	切片不好、查询改写差、关键词缺失	检查 chunk、embedding、关键词索引和 query rewrite。
无权限资料被使用	权限过滤在检索后缺失或失效	把权限作为检索过滤条件和后端校验条件。

10 · 企业案例

商品导入问答：让 AI 基于企业资料回答

假设用户问：“商品导入失败后，能不能下载错误明细？” 这个问题不能靠模型常识回答。要查企业知识库里的 PRD、接口文档和上线记录。

1 识别意图 问题属于商品导入失败处理。

2 检索资料 PRD、接口文档、FAQ、上线记录。

3 过滤版本 只保留当前版本和用户有权限资料。

4 组装上下文 按 sourceId 放入最相关片段。

5 生成答案 基于资料回答，不足则待确认。

6 校验引用 检查 sourceId 是否真实来自检索结果。

结构化答案示例

{
  "answer": "当前版本不支持下载错误明细，只展示失败行数和错误原因。",
  "citations": [
    {
      "sourceId": "product-import-prd-v2#sec-3.2",
      "evidence": "当前版本不支持下载错误明细"
    }
  ],
  "openQuestions": [
    "下一版本是否规划错误明细下载能力？"
  ],
  "confidence": "high"
}

11 · 面试问答

回答要讲清楚检索、资料和引用

RAG 的面试重点不是“会用向量库”，而是知道为什么要检索、怎么建知识库、怎么评测，以及如何处理权限和过期资料。

RAG 是什么？

RAG 是检索增强生成。系统先根据用户问题从知识库或业务系统里检索相关资料，再把资料放进上下文，让模型基于资料生成答案。

它通常不改模型参数，适合企业知识变化快、需要引用来源、需要贴合内部系统现状的场景。

RAG 能解决幻觉吗？

RAG 能降低幻觉，但不能彻底解决。它提供了外部事实来源，减少模型凭空回答的机会。

但如果检索错了、资料过期、上下文组装混乱，模型仍然会答错。所以还要做引用校验、版本过滤、权限过滤和人工审核。

向量检索和关键词检索有什么区别？

向量检索适合找语义相近的内容，关键词检索适合找精确字段、接口名、错误码和编号。

企业 RAG 往往用混合检索。比如用户问 SKU 校验规则，既要找“商品编码”的语义近义词，也要精确命中 SKU 这个字段。

如何评测 RAG？

要分两层评测。第一层看检索，正确资料有没有召回、是否排在前面、是否被权限过滤正确。第二层看生成，答案是否基于资料、引用是否正确、资料不足时是否拒答。

如果最终答案错，不能直接怪模型，要看链路里是哪一步出了问题。

知识库建设有哪些注意点？

知识库要有 sourceId、版本、更新时间、权限、业务域和文档类型。文档要清洗、切片、向量化，同时保留标题和来源。

旧文档要能下线或降权，敏感资料要做权限过滤。否则 RAG 会把错误资料放进上下文，模型就会基于错误资料回答。

12 · 练习和速查

判断一个 RAG 系统是否靠谱

做 RAG 不要只问“用了哪个向量库”。更应该问资料是否可靠、检索是否召回、上下文是否干净、答案是否有来源。

练习 A：识别问题

答案引用了旧版制度 检查版本元数据、文档下线和检索过滤。

回答没有任何 sourceId Prompt 和后端校验都要增加引用要求。

字段名总是查不准 增加关键词检索、字段别名和元数据过滤。

模型把无权限资料写进答案 检索前后都要做权限过滤，不能只靠 Prompt。

练习 B：用一句话说清楚

解释 RAG 和微调的区别。
解释为什么向量检索不够，还要关键词检索。
解释为什么 sourceId 很重要。
解释 RAG 为什么不能完全消除幻觉。
解释知识库权限过滤应该放在哪里。

RAG 速查表

环节	要问的问题	合格标准
资料入库	文档是否有来源、版本、权限、更新时间？	每个 chunk 都能追到 sourceId。
切片	是否保留完整语义和标题层级？	一个 chunk 围绕一个规则、流程或接口。
检索	是否能召回正确资料？	向量、关键词、元数据过滤结合使用。
重排	正确资料是否排在前面？	旧文档、无权限文档、相邻系统文档被降权或过滤。
上下文	资料是否按任务组织，并留出输出空间？	规则、资料、问题边界清楚，sourceId 完整。
答案	结论是否基于资料？	关键结论有引用，不足时能拒答或列待确认项。
评测	能否定位错在检索还是生成？	检索指标和生成指标分开记录。