RAG学习笔记:让大模型先查资料再回答问题
好家伙,
这次我们来聊 RAG.
RAG 这个词最近出现得很多,但如果只是记住它的英文全称,其实没什么用.
我更关心的是:
它到底解决什么问题?
为什么一个普通大模型问答不够用?
文档是怎么变成知识库的?
用户提问时系统背后到底发生了什么?所以这篇文章不准备一上来堆概念.
还是从一个很实际的问题开始:
我有一堆项目文档,配置表,接口说明,设计笔记.
我想直接问它们问题.比如:
某个配置字段是什么意思?
有哪些文档提到了某个角色?
这个系统的部署流程是什么?
某个功能的设计依据在哪里?如果直接问普通大模型,它很可能不知道.
因为这些资料在我的本地,不在它的训练数据里.
那么问题来了:
我不希望模型瞎猜.
我希望它先查我的资料,再回答.
这就是 RAG 最核心的价值.
0.背景:为什么需要RAG
先看普通大模型问答.
它的流程大概是:
用户问题 -> 大模型 -> 答案这个流程很简单.
但它有几个问题.
0.1 大模型不知道我的私有资料
大模型知道很多通用知识.
但它不知道我电脑里的:
项目文档
策划案
配置表
部署笔记
内部接口说明
个人学习笔记如果这些资料没有被放进上下文,模型就只能靠已有知识猜.
这个时候它回答得越流畅,反而越危险.
因为你很难分辨它是在基于资料回答,还是在编.
0.2 文档太多,人工翻效率低
项目一大,资料会越来越多.
比如一个游戏项目里可能有:
文案文档
战斗配置表
技能配置表
装备配置表
后端部署文档
接口说明
测试记录人工一个个搜,效率很低.
而且有些问题不是关键词能直接搜出来的.
比如:
这个字段是不是和套装效果有关?
有没有哪个文档解释过战斗监控?
这个配置表里的 name 和 title 有什么区别?这些问题更偏语义.
传统搜索不一定好用.
0.3 我们想要的是先找证据
所以真正想要的流程应该是:
用户提问-> 系统先找相关资料-> 把资料交给大模型-> 大模型基于资料回答-> 最后给出来源这就是 RAG.
它不是让模型凭空变聪明.
而是给模型加了一个"查资料"的步骤.
1.RAG是什么
RAG 的全称是:
Retrieval-Augmented Generation拆开看:
Retrieval 检索
Augmented 增强
Generation 生成连起来就是:
检索增强生成我自己的理解更简单:
RAG = 先从知识库找资料,再让大模型基于资料回答.普通问答:
问题 -> 大模型 -> 答案RAG 问答:
问题-> 检索知识库-> 找到相关资料-> 资料 + 问题 一起给大模型-> 答案 + 来源噢,这样一看就清楚了.
RAG 不是替代大模型.
它是给大模型补上一个外部知识来源.
2.RAG整体流程
一个基础 RAG 系统,大概分两部分:
1. 建库阶段
2. 查询阶段2.1 建库阶段
建库阶段就是把资料整理成可以检索的形式.
流程大概是:
读取文档-> 清洗文本-> 切成片段-> 生成 embedding-> 写入向量数据库比如:
Markdown 文档
Word 文档
txt 文本
Excel 配置表都会被转成一条条知识记录.
每条记录一般包含:
文本内容
向量
来源文件
chunk 序号
额外元数据2.2 查询阶段
用户提问时,流程大概是:
用户问题-> 生成问题 embedding-> 去向量数据库检索相似内容-> 取 Top K 相关片段-> 拼成 Prompt-> 让大模型回答-> 返回答案和来源这里最关键的是:
大模型看到的不是空问题.
它看到的是问题 + 检索出来的资料.所以它的回答就有了依据.
3.文档怎么进入知识库
RAG 的第一步不是问答.
而是文档处理.
如果文档处理得很粗糙,后面模型再强也救不回来.
3.1 文本类文档
像 Markdown,txt,Word 这种文档,一般先提取文本.
然后按段落切块.
比如:
原文档-> chunk 0-> chunk 1-> chunk 2切块时要注意两个问题:
块太大,检索不精准
块太小,上下文容易断所以常见做法是:
按段落切块 + 保留一点 overlap也就是相邻片段之间保留一点重叠内容.
这样可以避免一句话刚好被切断.
3.2 Excel配置表
Excel 就不能完全按普通文本处理.
尤其是游戏项目里的配置表.
常见结构可能是:
第 1 行: 中文字段名
第 2 行: 字段 code
第 3 行以后: 数据记录这种表格更适合按行处理.
也就是说:
一行配置 = 一条知识记录并且要保存:
文件路径
Sheet 名
行号
中文字段名
字段 code否则后面回答时,只能说"查到了相关配置".
但说不清到底在哪个表,哪个 sheet,哪一行.
这就不够可用.
4.Embedding和向量是什么
RAG 里面经常会提到 embedding.
这个词听起来有点抽象.
我现在这样理解:
embedding = 把文本变成一组数字比如一句话:
RAG 适合做项目知识库问答经过 embedding 模型以后,会变成:
[0.12, -0.08, 0.33, ...]这一组数字就是向量.
它表示这段文本的语义位置.
如果两段文本意思接近,它们的向量距离也会比较接近.
比如:
RAG 适合做知识库问答
检索增强生成可以用于内部文档问答这两句话虽然字面不完全一样,但语义接近.
所以向量检索能把它们关联起来.
这就是 RAG 比普通关键词搜索更灵活的地方.
5.向量数据库负责什么
向量生成出来以后,要存到一个地方.
这个地方就是向量数据库.
常见的有:
Qdrant
Milvus
Chroma
Weaviate向量数据库主要做几件事:
1. 保存文档片段的向量
2. 保存文档片段的 payload
3. 根据问题向量检索相似片段
4. 返回相似度分数 score这里 payload 很重要.
不要只存向量.
一条比较完整的 payload 可能长这样:
{"text": "File: skill.xlsx\nSheet: Skill\nRow: 12\n名称(name): 火球术","source": "配置表/skill.xlsx","fileType": ".xlsx","sheet": "Skill","rowNumber": 12,"chunkIndex": 0
}向量负责:
找得准payload 负责:
说得清没有 payload,最后就很难展示来源.
6.用户提问时发生了什么
假设用户问:
套装描述的方法是什么?系统第一步不是直接调用大模型.
而是先把这个问题也变成向量:
问题文本 -> 问题向量然后拿问题向量去向量数据库里搜.
比如取前 6 条:
Top 1 score=0.72
Top 2 score=0.66
Top 3 score=0.51
Top 4 score=0.31
Top 5 score=0.28
Top 6 score=0.20这里要注意:
不是所有结果都应该给大模型.
如果 score 太低,说明它可能只是"看起来有点像",但并不能真正回答问题.
所以需要设置一个最低相关度.
比如:
score >= 0.48 才进入上下文如果没有任何片段达到阈值,系统应该回答:
根据当前资料无法确定。这句话很重要.
因为 RAG 系统最怕的不是回答少.
最怕的是资料不够还硬编.
7.Prompt怎么约束模型
检索到资料以后,还要把资料放进 prompt.
这里 prompt 不能太随便.
一个比较稳的 prompt 思路是:
你是一个项目内部知识库助手.
请使用中文回答.
只能使用提供的资料.
如果资料足够,直接回答.
如果资料只提供部分线索,说明"资料只提供了部分线索".
如果资料不足,说明"根据当前资料无法确定".
最后附上来源.这里的核心是:
限制模型不要脱离资料发挥.也就是说,模型可以负责组织语言.
但证据必须来自检索结果.
这就是 RAG 和普通聊天最大的区别.
8.RAG为什么一定要显示来源
我觉得 RAG 里"来源"不是附加功能.
它是核心功能.
如果系统只回答:
套装描述通过 desc 字段配置。这个答案看起来有用.
但用户还是会问:
你从哪看到的?
在哪个文件?
哪一行?所以更好的回答应该带来源:
来源:
配置表/equip.xlsx / Sheet: Equip / Row: 12 / score=0.6231这样用户可以回到原始资料验证.
对于项目知识库来说,能验证比会说更重要.
尤其是配置表,部署文档,接口说明这种内容.
答错了可能会直接影响开发和测试.
9.RAG适合什么场景
RAG 很适合这些场景:
1. 公司内部知识库
2. 项目文档问答
3. 游戏文案和配置表查询
4. 个人学习笔记检索
5. 客服知识库
6. 部署文档和故障排查这些场景有一个共同点:
资料很多
资料会变
需要基于资料回答
最好能给来源所以 RAG 很适合.
因为它不需要重新训练模型.
资料变了,重新导入知识库就行.
10.RAG不适合什么场景
RAG 也不是万能的.
有些场景不适合只靠 RAG.
10.1 精确数值筛选
比如:
找出攻击力大于 50 的装备这个问题更适合数据库查询.
因为它是结构化筛选.
RAG 可以帮你解释字段含义.
但真正筛选数值,数据库更稳定.
10.2 复杂计算
比如:
按照这套公式计算最终伤害这类问题应该走明确的计算逻辑.
不要让模型凭感觉算.
10.3 资料根本不存在
如果知识库里没有导入相关资料,RAG 也答不出来.
它不是凭空造知识.
它只是帮你更好地使用已有资料.
10.4 图片和扫描件
如果资料是图片或者扫描件,但没有 OCR,那系统读不到文字.
这种情况需要先做 OCR.
否则 RAG 根本不知道图片里写了什么.
11.本地RAG项目可以怎么搭
一个本地 RAG MVP 可以这样搭:
Ollama 跑本地模型
bge-m3 做 embedding
qwen 类模型 做回答
Qdrant 存向量
Node/Go/Python 提供 API
Web 页面 展示答案和来源流程大概是:
文档目录-> 解析 Markdown / txt / docx / xlsx-> 切块或按行处理-> 生成 embedding-> 写入 Qdrant-> Web 页面提问-> 返回答案和来源本地方案的好处:
1. 数据不出本机
2. 可以接内部资料
3. 成本低
4. 适合先做 MVP 验证限制也很明显:
1. 速度取决于本地模型
2. 大批量导入会比较慢
3. 没有鉴权时只能本机或内网用
4. 高并发能力有限所以一开始不要追求大而全.
先导入一小批真实资料.
然后准备 10 个真实问题去问.
如果答案能被来源验证,这个方向就有价值.
12.总结
这次整理 RAG,我最大的收获是:
RAG 的核心不是让模型记住资料.
而是让模型回答前先检索资料.它的核心链路是:
文档-> 切块-> embedding-> 向量数据库-> 检索-> prompt-> 回答和来源几个关键点:
1. 文档解析质量决定知识库质量
2. 切块策略会影响检索效果
3. payload 元数据决定答案能不能追溯
4. score 过滤可以减少低质量上下文
5. prompt 要限制模型只基于资料回答
6. 来源展示是 RAG 的核心能力踩坑点也很清楚:
1. 不要把所有文档粗暴拼成一大段
2. 不要只存文本不存来源
3. 不要把低相关度结果硬塞给模型
4. 不要指望 RAG 替代结构化数据库
5. 不要让模型在资料不足时强行回答最后一句话总结:
RAG 不是魔法.
它是一套让大模型先查资料,再回答问题的工程流程.把这条流程跑通以后,大模型才真正能服务我们的项目文档,配置表和内部知识库.