什么是 RAG
1. 一句话定义
RAG（Retrieval-Augmented Generation，检索增强生成） 是一种把「检索」和「生成」结合起来的问答技术。
它的大致过程是：
用户提问 → 先从知识库里检索出相关的资料 → 把资料作为上下文喂给大语言模型（LLM）→ LLM 基于这些资料生成答案。
用公式表示：
text
答案 = LLM( 用户问题 + 检索到的相关片段 )2. 为什么要用 RAG：先看纯 LLM 的痛点
只靠大模型（不使用 RAG）对话时，有四个明显问题：
| 痛点 | 说明 |
|---|---|
| 知识过时 | LLM 的训练数据有截止日期，无法知道企业/个人最新发生的事情 |
| 没有私有知识 | LLM 不知道你的公司制度、内部文档、个人笔记 |
| 会「一本正经地胡说八道」 | 不知道答案时，模型会编造（Hallucination，幻觉），且用户无法分辨 |
| 答案不可追溯 | 即使说对了，用户也无法知道依据来自哪里 |
RAG 正是为了解决这些问题而出现：它不依赖 LLM「背下来」的知识，而是现场从知识库中查资料，再让 LLM 基于资料回答。
3. RAG 解决问题的对照
| 痛点 | RAG 的解法 |
|---|---|
| 知识过时 | 知识放在外部数据库，随时更新，LLM 每次现查 |
| 没有私有知识 | 把私有文档（PDF / Word / Excel / Markdown…）切块、索引，变成可检索的知识库 |
| 幻觉 | 要求 LLM「只依据检索到的证据回答」，没有证据就明确说不知道 |
| 不可追溯 | 答案附带 Citation（引用），指出依据来自哪份文档的哪个章节 |
一个类比
普通 LLM 像「闭卷考试的学生」，只能靠背过的知识答题； RAG 像「开卷考试的学生」，可以随时翻阅资料再作答，还能标出「我这题的依据在第几页」。
4. 一个完整的 RAG 系统长什么样
一个完整可落地的 RAG 平台，通常由两条链路组成：
链路一：知识入库（Ingestion，也叫索引/摄取）
把原始文档变成可检索的形式：
text
上传文档
↓
解析（Parser） 把 PDF/Word/Markdown 变成统一结构
↓
切块（Chunker） 切成适合检索的小片段（Chunk）
↓
向量化（Embedding） 把文本转成向量（一串数字，表达语义）
↓
索引（VectorStore） 存入向量数据库，供检索链路二：问答（Query / Generation）
用户提问后，从库里召回资料并生成答案：
text
用户提问
↓
向量化问题 用同一个模型把问题转成向量
↓
检索（Retrieval） 在向量库里找最相似的 Chunk
↓
拼上下文 把召回的 Chunk 组织成带来源编号的 Prompt
↓
生成（Generation） LLM 基于上下文回答
↓
返回答案 + 引用 同时返回依据的文档/章节/页码理解建议
把「入库」和「问答」当作两条独立的流水线来理解。 入库做一次，问答做无数次；问答只使用入库产生的结果。 这正是本项目（UltimateRAG）组织代码的核心逻辑。
5. 关键术语表
在继续阅读之前，先建立这些词的直觉：
| 术语 | 直觉理解 | 在本项目中的体现 |
|---|---|---|
| Document | 一份上传的原始文档 | 含元数据和状态（PENDING / READY / FAILED） |
| Parser | 把各种格式解析成统一结构的「翻译官」 | MarkdownParser、PDFParser、WordParser… |
| Block | 解析后的最小语义块（标题、正文、表格…） | 领域模型 Block |
| Chunk | 真正送去向量化、检索的文本片段 | 领域模型 Chunk |
| Embedding | 把文本变成语义向量 | 百炼 text-embedding-v4，1024 维 |
| VectorStore | 存向量并支持相似度检索的数据库 | Milvus |
| Retrieval | 找出与问题最相关的片段 | RetrievalService |
| Context | 拼给 LLM 的证据文本 | ContextBuilder |
| Citation | 答案的依据引用 | 领域模型 Citation |
| Knowledge Base | 一组文档的容器，也是检索的隔离边界 | KnowledgeBase |