Happy-LLM 学习笔记 09：RAG 的关键不是接个向量库，而是把知识流转设计清楚

第七章开始进入大模型应用，RAG 是其中最容易被低估的一块。很多教程会把它讲成"文档切块、向量化、相似度检索、塞进 prompt"，流程看起来很顺，但真正落到工程里，问题往往不在能不能跑通，而在检索到的知识是否完整、是否相关、是否能被模型稳定使用。

Happy-LLM 的 Tiny-RAG 实现很适合作为入门骨架：它把系统拆成文档加载与切分、Embedding、向量存储、检索和 LLM 生成几个模块。读完之后我对 RAG 的理解更清楚了：它不是给模型外挂一个数据库，而是设计一条知识从原始文档流向最终回答的链路。

RAG 先解决的是知识来源问题

大模型参数里有大量通用知识，但它有几个天然限制：训练数据会过期，垂直领域知识不一定充分，生成时也不会自动知道答案来自哪里。RAG 的核心价值，就是把回答建立在可更新、可追踪的外部材料上。

这件事听起来像是在"补知识"，但我觉得更准确的说法是"约束生成"。检索结果进入上下文后，模型应该围绕给定资料回答；如果资料里没有答案，就应当承认不知道。业务系统需要的不是一段流畅文本，而是能被追溯、能解释、能更新的答案。

切分不是小细节

Tiny-RAG 里的文档切分采用最大 token 长度和重叠内容的思路。这个设计很朴素，但背后有两个关键判断。

第一，块太大，检索相似度会被稀释。一个长段落里可能只有几句话和问题相关，但整块向量会混入大量无关信息。第二，块太小，语义会断裂。模型拿到的是碎片，缺少上下文，很容易把局部句子理解错。因此重叠内容不是浪费，而是给跨边界知识留缓冲。

这也提醒我，RAG 的效果很大程度上取决于知识库建模，而不是只取决于模型本身。同样的文档，用标题层级切、按段落切、按 token 切，召回结果可能完全不同。生产系统里应该把切分策略当成可评估的参数，而不是一次写死。

Embedding 和向量库只是中间表示

教程里先定义 Embedding 基类，再实现具体的在线或本地向量模型，这种抽象很有工程价值。因为 RAG 系统经常会换 embedding 模型、换向量库、换相似度算法，如果接口没有隔离，后续实验会很痛苦。

但我也不应该把向量检索神化。向量相似度捕捉的是语义接近，不等于事实可用。比如用户问"某个施工规范是否允许某种做法"，最相似的文本未必就是最能支持结论的条文。检索阶段最好保留分数、来源、片段位置和原文结构，否则证据链会很薄。

Prompt 是检索和生成之间的协议

Tiny-RAG 的提示词强调：根据上下文回答，不知道就说不知道，始终使用中文。这个提示词虽然简单，但它定义了系统行为边界。RAG 应用里的 prompt 不只是问模型一个问题，而是在告诉模型如何使用检索材料。

我现在会把 RAG prompt 分成三层来看：第一层是任务边界，例如只能基于资料回答；第二层是证据使用方式，例如需要引用来源或说明依据；第三层是失败策略，例如资料不足时不要编造。很多问题不是没有检索结果，而是 prompt 没有把"如何处理检索结果"说清楚。

从 Tiny-RAG 到领域 RAG

CDDRS 建筑文档审查的额外章节把 RAG 往专业场景推进了一步。建筑施工交底这类文档并不适合只靠固定长度切块和整句查询嵌入，因为合规性问题往往藏在术语、限制条件、工艺步骤和数值要求里。系统需要先理解待审文档的核心事件，再生成审查问题，随后用知识引导的检索方式找到更匹配的规范依据。

这个思路对我启发很大：垂直领域 RAG 不只是换一个知识库，而是要把领域里的"判断方式"显式建进流程。建筑审查关注安全、质量、操作程序和限制条件；法律问答关注条款、适用场景和例外；医疗问答关注症状、禁忌和证据等级。

CDDRS 里动态语义分块、关键信息提取、知识级评分、LLM 重排序和查询增强，本质上都在做同一件事：让检索从"语义上像"进一步走向"证据上有用"。这比简单 top-k 相似度更贴近真实业务。

工程上我会优先检查什么

如果我要实现一个 RAG 原型，我会先做四件事。

第一，保留原文来源。每个 chunk 都要能回到文件名、标题层级和位置，否则回答无法追溯。

第二，给检索做可观察性。至少记录 query、召回片段、相似度、重排序结果和最终进入 prompt 的上下文。没有这些日志，就很难定位问题。

第三，构造失败样例。不要只测试答案在知识库里的问题，还要测试资料缺失、问题含糊、多个片段冲突、命中无关片段的情况。RAG 的可靠性，往往是在这些边界场景里体现出来。

第四，单独评估检索质量。生成结果好坏会掩盖召回问题，模型有时能靠常识补齐答案，让系统看起来有效。先看 top-k 是否真的包含证据，再看模型是否正确使用证据，这样排查会清楚很多。

这篇让我把 RAG 从一个工具链重新看成知识工程问题。向量库、Embedding 和 LLM 都只是组件，真正决定质量的是：知识如何被切分，问题如何被改写，证据如何被召回，模型如何被约束，以及系统如何在不知道时停下来。

参考项目：https://github.com/datawhalechina/happy-llm
在线阅读：https://datawhalechina.github.io/happy-llm/