RAG 的完整流程是什么？文档解析、切分、检索、生成分别做什么？
RAG 就是"先查后写"——让大模型先从文档库找到相关资料，再基于真实内容生成答案。这道题考的是你对 RAG 全流程的理解，从原始文档进来到最终答案出来，每个环节在干什么、有什么挑战。
板块1：先搞懂 RAG 是什么——为什么需要它
大模型有个致命问题：幻觉。它会一本正经地胡说八道，因为它的知识是训练时固化的，无法实时更新。
RAG 就是来解决这个的。它的核心思路很简单：
像写论文一样——先查文献，再写正文。
用户提问 → 系统去文档库检索相关片段 → 把片段和问题一起喂给大模型 → 大模型基于真实资料生成答案。
这样一来，答案有据可查，知识可以实时更新，不用每次都重新训练模型。
板块2：文档解析与切分——从乱七八糟的文件到整齐的语义块
这一环节的目标是：把各种格式的文档，变成大模型能理解的"知识点"。
文档解析：处理28+种格式
用户上传的可能是 PDF、Word、Excel、PPT、网页、扫描件……解析器要把这些全部转成统一格式。
核心挑战有三个：
- PDF多栏布局——很多技术文档是双栏排版，顺序读下来会乱
- 表格结构丢失——Excel 转成文本后，表格行列关系没了
- 扫描件/图片——需要 OCR 识别文字
解决方案是用 Layout 解析 识别页面结构，区分正文、标题、表格、图片区域，保持阅读顺序正确。
文档切分：按语义边界拆成 Chunk
解析完后，要切成小块（Chunk），方便检索时只取最相关的部分。
关键原则：保证每个 Chunk 讲一件事。
常见切分策略：
- 固定长度：按 Token 数硬切，比如每 512 Token 一切。简单但可能把一句话劈成两半
- 语义切分：按段落、章节切，保持语义完整。效果好但实现复杂
- 滑动窗口 + 重叠：相邻 Chunk 重复一部分，避免边界处语义断裂
400-512 Token 是通用文本的黄金块大小——太小丢失上下文，太大引入噪声。
板块3：检索环节——如何在大海里捞针
用户问一句话，系统要从成千上万的 Chunk 里找到最相关的几个。
检索的核心：混合检索
没有单一方法能搞定所有场景，所以用 混合检索：
| 检索方式 | 原理 | 权重 | 适合场景 |
|---|---|---|---|
| 向量检索 | 把文字变成向量，问句和文档比较"像不像" | 0.6 | 语义相似但用词不同 |
| BM25关键词检索 | 统计词频，看"关键词对不对得上" | 0.3 | 专业术语、专有名词 |
| 元数据过滤 | 按文件类型、时间、作者过滤 | 0.1 | 限定搜索范围 |
类比一下：向量检索看"意思像不像"，BM25 看"词对不对"。两个都要参考，权重相加。
精排：检索后还要再筛选
初筛出来的候选片段可能有几十个，要再用 重排序模型（Reranker） 精挑细选，最终输出 3-8 个最相关的 Chunk 给生成环节。
重排序模型能理解更深层的语义关联，比向量相似度判断更准，但计算量大，所以一般用它做二次筛选而不是初筛。
板块4：生成环节——大模型如何"看图说话"
拿到检索结果后，大模型要生成最终回答。
组装提示词：把资料整理成"考纲"
把检索到的 Chunk + 用户问题 + 系统指令组装成结构化提示词：
【问题】
用户的问题是什么
【参考内容】
1. [来源1标题] ...相关段落...
2. [来源2标题] ...相关段落...
【要求】
基于上述内容回答，不要编造，如果资料不够就说不知道大模型生成：有据可查的回答
大模型基于提示词中的真实文档片段生成回答。关键点：
- 低置信度时降级：如果检索结果和用户问题不相关，系统可以触发"拒答"或"转人工"
- 来源标注：生成的回答要标注来自哪个文档，方便用户溯源
面试怎么答
基础版（100-150字）：
RAG 完整流程分10个环节：采集→解析→切分→向量化→索引→查询理解→检索→重排序→组装→生成。
文档解析要处理多格式、PDF多栏、表格结构问题；切分按语义边界切成400-512 Token的Chunk；检索用混合检索（向量0.6+BM250.3+元数据0.1）加重排序；生成环节把检索片段组装成提示词，大模型基于真实资料生成可溯源的回答。
加分版（额外提）：
每个环节都有降级策略——解析失败用OCR兜底，切分异常用固定长度兜底。关键指标要关注：召回率≥85%、准确率≥90%、P95延迟<5s。如果问到 RAG vs 微调的选择：RAG 适合知识实时更新、有据可查的场景；微调适合改风格、需要模型记忆大量知识的场景。
一句话总结
RAG 就是"查资料再答题"——文档解析把各种文件变成可处理的文本，切分按语义切成小块，检索用混合搜索找到相关片段，生成阶段把真实资料喂给大模型产出有据可查的回答。