「从零到 AI 应用工程师」专栏 · 第 9 篇
阶段 2 · 储能 RAG 开篇
chat-api 阶段解决的是：会说话的后端。
但一问到「我们手册第几页怎么写的」「这个故障码怎么处置」，通用大模型就容易开始编——它训练语料里未必有你的私有文档。
RAG（Retrieval-Augmented Generation，检索增强生成）干的事很朴素：
先从你的资料里找出相关段落，再让模型只根据这些段落回答。
今天不写长代码，先把地图画清。后面九篇都站在这张图上。
一、为什么「直接问大模型」不够
| 场景 | 只靠大模型 | 加上 RAG |
|---|---|---|
| 问通识概念 | 通常够用 | 可选 |
| 问私有手册 / 内部规范 | 易幻觉、无出处 | 先检索再答 |
| 知识常更新 | 要微调或换模型 | 改文档再入库即可 |
| 要审计、要追责 | 很难说清依据 | 可带引用（citations） |
工业运维、客服知识库、制度问答——都是 RAG 的主战场。本专栏演示场景用脱敏后的设备手册 / 故障码 / 工单样例，不绑定任何真实公司文档。
二、一张图看懂 RAG
【入库（离线或异步）】
PDF/MD 文档
→ 解析抽文本
→ 切成小片（chunk）
→ Embedding 变成向量
→ 写入向量库
【问答（在线）】
用户问题
→ 同样 Embedding
→ 向量库 TopN 相似片段
→（可选）Rerank 精排
→ 拼进 Prompt
→ 大模型生成答案
→ 返回答案 + 出处
两句话记住：
- 入库把资料变成「可算距离的数字」；
- 问答先找近邻，再生成——生成不是自由创作，是有依据的复述与归纳。
三、和微调、和「把 PDF 塞进对话框」的区别
| 做法 | 适合 | 不适合 |
|---|---|---|
| RAG | 知识更新快、要溯源 | 要改模型说话风格本身 |
| 微调 | 固化语气、格式、领域习惯 | 每周改一版手册（成本高） |
| 整份 PDF 塞进 Prompt | 极短文档演示 | 长手册会超上下文、贵、噪声大 |
多数业务：RAG 做知识，微调（或好 Prompt）做行为。 本专栏主线是 RAG。
四、你后面会依次搞定的能力
| 篇 | 主题 |
|---|---|
| 10 | 解析 + 分块：从 PDF/MD 到可检索切片 |
| 11 | Embedding + 向量库：怎么「找得着」 |
| 12 | POST /rag/query：全链路问答接口 |
| 13 | citations：答案里的【1】【2】从哪来 |
| 14 | 拒答与幻觉治理：没依据就别编 |
| 15 | Rerank：粗召回后再精排 |
| 16 | 评估集：用题目证明好不好 |
| 17 | 成本：token 日志 + FAQ 缓存 |
| 18 | pytest：三条测试底线 |
阶段 1 的 FastAPI、统一响应、Docker，会原样复用——RAG 是新模块，不是推倒重来。
五、一个最小心智模型（面试也能用）
问你「RAG 是什么」时，可以这样答：
RAG 是检索增强生成：把私有文档切分并向量化后存进向量库；用户提问时先检索相关片段，再交给大模型基于片段生成答案，从而降低幻觉、支持知识更新与出处追溯。
再补半句工程现实：
效果取决于解析质量、分块策略、检索阈值、Prompt 约束和评估迭代——不是装一个向量库就结束。
六、带走这三条
- RAG = 检索 + 生成；私有知识靠检索喂给模型，不是靠模型「背下来」。
- 入库与问答是两条链路；问句和文档必须用同一套 Embedding 空间。
- 工业场景要出处、要拒答、要评估——后面几篇逐个落地。
下一篇动手：从 PDF/Markdown 解析到分块，让资料变成一条条带元数据的切片。
这是专栏第 9 篇，阶段 2 开篇。两到三天一更，解析分块见。
