0-RAG 介绍
一、介绍
RAG，Retrieval-Augmented Generation，也被称作检索增强生成技术，核心思想是借助一些文本检索策略，让大模型每次问答前都带入相关文本，以此来改善大模型回答时的准确性。
二、步骤
阶段一：离线阶段（数据准备）—— 只做一次
这个阶段的目标是把外部知识“翻译”成机器能快速检索的格式。
| 步骤 | 做什么？ | 技术细节 |
|---|---|---|
| ① 文档加载 | 接入各种数据源 | PDF、Word、Markdown、数据库、网页等，用 LangChain 的 DocumentLoader 统一读取 |
| ② 文本清洗 | 去掉噪音 | 去除页眉页脚、特殊字符、多余换行，保留纯文本内容 |
| ③ 文本分块（Chunking） | 切分成小段落 | 按固定大小（如 500 字符）或按语义（段落/标题）切分，块太小丢上下文，块太大检索不精准 |
| ④ 向量化（Embedding） | 把文本转成向量 | 用 Embedding 模型（如 text-embedding-3-small、BGE）将每块文本转为高维向量（比如 1536 维浮点数数组） |
| ⑤ 存入向量数据库 | 建立索引 | 存入 Milvus、Pinecone、Chroma、Qdrant 等，同时存储向量 + 原始文本 |
阶段二：在线阶段（问答推理）—— 每次提问都执行
这个阶段负责接收用户问题，检索资料，然后生成回答。
| 步骤 | 做什么？ | 技术细节 |
|---|---|---|
| ① 用户提问 | 接收问题 | 如：“RAG 和微调有什么区别？” |
| ② 问题向量化 | 把问题转为向量 | 使用与离线阶段相同的 Embedding 模型，保证向量空间一致 |
| ③ 相似度检索 | 从向量库找最相关的块 | 用余弦相似度或内积计算，召回 Top-K 个最相似的文档块（K 通常为 3-5） |
| ④ 构建 Prompt | 把资料和问题组装 | 形成结构：“基于以下参考资料回答问题：\n[文档块1]\n[文档块2]\n\n问题：xxx” |
| ⑤ 大模型生成 | 调用 LLM 生成答案 | 模型基于提供的上下文生成回答，不依赖内部记忆 |
| ⑥ 返回结果 | 输出答案 + 可选来源 | 最佳实践：同时返回引用的文档来源，增强可信度 |
三、核心要点与常见坑
成功的关键要素
| 要素 | 说明 |
|---|---|
| 分块策略 | 块太小 → 上下文缺失；块太大 → 检索噪声多。推荐 500-1000 字符 + 重叠（Overlap） |
| Embedding 模型 | 必须与检索场景匹配。中文场景用 BGE-M3 或 text-embedding-v3，英文用 OpenAI 系列 |
| Top-K 调优 | K=3~5 是黄金区间，太少可能漏关键信息，太多会塞入噪音干扰模型 |
| Prompt 设计 | 明确指令：“如果参考资料中没有答案，请直接说不知道，不要编造” |
| 向量数据库 | 小规模用 Chroma（本地），大规模用 Milvus（分布式） |
常见问题与解法
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 检索到的资料不相关 | Embedding 模型能力不足 | 换用更强的 Embedding 模型，或尝试 HyDE（让模型先假装生成答案，再用答案去检索） |
| 答案依然有幻觉 | 检索块内容不完整 | 增加 Top-K，或调整分块策略（如按段落切分） |
| 响应太慢 | 向量检索耗时 + LLM 生成慢 | 加缓存（Redis），或换用更快的 Embedding 模型 |
| 多轮对话时丢失上下文 | 只检索了最新问题 | 用 历史对话摘要 后再检索，或使用 RAG 与 Memory 结合 的方案 |
四、文档、PDF、课件是如何切分、入库、人工审核的？
4.1 文档处理的完整链路
整个过程可以拆成五个环节：格式识别 → 内容抽取 → 智能切分 → 质量预审 → 人工审核入库。每一步都在为下一步做准备，不能跳过，也不能颠倒顺序。
4.2 格式识别与内容抽取
不同格式的文档，解析策略完全不同。入库前先判断文档属于哪一类，再选择对应的抽取方式。
| 文档类型 | 典型特征 | 抽取策略 |
|---|---|---|
| 文本型 PDF | 可选择复制文字，排版规整 | 直接用解析库读取文字流，保留段落和标题 |
| 扫描型 PDF | 图片格式，无法选中文字 | 走 OCR 识别，先转图片再提取文字 |
| Word 文档 | 有标题层级、表格、图片 | 按段落和标题层级读取，保留结构信息 |
| PPT 课件 | 每页有标题和若干要点 | 逐页提取标题和要点列表，不拆分单页内的内容 |
| 网页文章 | 有 HTML 标签 | 用正文抽取工具剥离广告、导航、页脚 |
| Excel 表格 | 行列结构 | 按行转成"字段名 + 值"的自然语言描述 |
| Markdown 文档 | 有 # ## ### 标题标记 | 按标题层级切分，保留章节路径 |
这个阶段的三个常见坑：
- PDF 的双栏排版会导致文字读取顺序错乱，需要用基于坐标的解析方式，而不是按行顺序读
- OCR 识别率受图片质量影响很大，扫描件模糊时建议先做图像增强
- PPT 里的图片和图表中的文字无法自动抽取，需要人工补录或单独处理
4.3 智能切分策略
切分是整条链路中最容易被低估的环节。切得太碎，上下文断裂，检索时找不到完整信息；切得太粗，块内噪音太多，检索精度下降。
不同文档类型，切分策略完全不同，不能一刀切。
| 文档类型 | 首选切分方式 | 块的大致范围 | 重叠量 |
|---|---|---|---|
| Word 正式文档 | 按标题层级切，一级标题下的内容作为一个块 | 600-1000 字 | 100-150 字 |
| 学术论文 PDF | 按章节切，Introduction/方法/结论各为独立块 | 800-1200 字 | 100-200 字 |
| PPT 课件 | 一页一个块，保留标题加所有要点 | 300-500 字 | 50 字左右 |
| 扫描版 PDF | 按自然段落切，不跨段落合并 | 400-600 字 | 80 字左右 |
| FAQ 问答文档 | 问题和答案作为一个整体，不拆分 | 完整 QA 对 | 不重叠 |
| 法律条款 | 按条款编号切，一条一档 | 800-1200 字 | 150 字左右 |
| 技术 API 文档 | 按函数或接口切，一个接口一个块 | 300-500 字 | 50 字左右 |
| 多列杂志排版 | 按物理区域切，先分列再分段 | 400-600 字 | 80 字左右 |
对于没有明确结构的文档，兜底方案是按固定字数切分，同时保持相邻块之间有适当重叠，防止关键信息被切断。但兜底方案的效果永远不如针对性策略，所以入库前花时间判断文档类型非常值得。
PPT 课件是特殊案例，它和普通文档不同，每一页本身就是一个独立的知识单元，强行按字数切分会破坏"一页一个主题"的逻辑结构。正确做法是整页作为一个块，如果某一页内容确实过长，再考虑拆成两到三个块，但需要保留它们属于同一页的元数据关联。
4.4 元数据标注
每个知识块入库时必须携带足够的元数据，这决定了后续检索时能不能做精准过滤。
需要标注的元数据可以分为五类：
| 类别 | 具体字段 | 用途 |
|---|---|---|
| 来源信息 | 文档编号、文件名、文件类型、页码 | 定位原始出处，支持引用溯源 |
| 结构信息 | 章节路径、标题层级、块类型 | 保持文档层次，支持按章节检索 |
| 组织信息 | 部门、项目、租户标识 | 多租户隔离，权限控制 |
| 时间信息 | 发布时间、入库时间 | 时间范围过滤，时效性控制 |
| 标签信息 | 人工打标、自动提取的关键词 | 分类检索，主题过滤 |
元数据标注做得越细，后续检索时"分桶"的效果就越好。比如只搜索某个部门近三个月发布的文档，如果元数据里有部门和日期字段，向量检索前就能先把范围缩小到原来的十分之一甚至百分之一。
4.5 入库前的质量预审
在人工审核之前，先做一轮机器预审，把明显合格和明显不合格的筛出来，减少人工阅读量。
预审主要看四个维度：
| 评估维度 | 判断标准 | 处理方式 |
|---|---|---|
| 内容长度 | 太短（低于 20 字）或太长（超过 2000 字） | 过短直接丢弃或合并，过长标记复审 |
| 噪音比例 | 乱码、特殊字符、不可识别符号的占比 | 占比超过 30% 标记为低质量 |
| 语言统一性 | 中文混杂大量无关外文或无意义符号 | 严重混杂标记为待审核 |
| 语义完整性 | 是否在句中被截断，是否以完整句号或问号结尾 | 明显截断的标记为待合并 |
基于这四个维度的综合评分，可以把知识块分成三个等级：
| 质量等级 | 评分范围 | 审核策略 |
|---|---|---|
| 高 | 80 分及以上 | 自动化入库，免人工审核 |
| 中 | 60 到 79 分 | 抽样审核，覆盖比例 20% |
| 低 | 60 分以下 | 全量人工审核，逐条过 |
这样做的收益很明显：大多数高质量块可以直接入库，人工审核精力集中在"不确定"和"有问题"的块上，效率比逐条审核高出三到五倍。
4.6 人工审核机制
人工审核的核心原则是：不是让审核员逐字阅读所有内容，而是用分层抽样加异常追踪的方式，把精力花在刀刃上。
审核员的角色与职责
| 角色 | 职责 | 关注重点 |
|---|---|---|
| 业务审核员 | 判断内容准确性、适用性 | 表述是否准确、是否符合业务规范、是否有过时信息 |
| 格式审核员 | 判断切分合理性和元数据准确性 | 切分是否破坏了语义完整、元数据标签是否准确 |
| 终审人 | 处理争议、裁决是否入库 | 业务和格式审核意见不一致时的最终判断 |
抽样策略
不同质量等级采用不同的抽样比例：
| 质量等级 | 抽样比例 | 抽样方式 |
|---|---|---|
| 中等级（60-79分） | 20% | 随机抽取，覆盖所有文档来源 |
| 低等级（60分以下） | 100% | 逐条审核，全部过手 |
| 新文档类型首次入库 | 50% | 首次出现的新格式，多抽一些建立基线 |
抽样审核中发现的问题需要分类统计，用于指导后续的自动化改进：
| 问题类型 | 处理方式 | 改进方向 |
|---|---|---|
| 切分不当（上下文断裂） | 重新切分或合并相邻块 | 优化该类型文档的切分参数 |
| 元数据错误（标签不准、章节错位） | 修正元数据 | 优化自动标注逻辑或增加人工干预点 |
| 内容重复（不同块内容高度重叠） | 删除冗余块 | 提高去重阈值 |
| 业务信息过时 | 删除或标记为过期 | 建立文档时效性管理机制 |
审核流程的操作规则
正式上线后，推荐采用以下操作规则：
第一条，知识块进入审核队列后，机器预审的结果和评分要一并呈现给审核员，作为参考但不替代判断。
第二条，审核员有三种操作选项：直接通过、退回修改、拒绝入库。每种操作都需要填写简要原因。
第三条，退回修改的块，修改后重新进入审核队列，但审核员可以看到前一次被退回的原因，便于对照。
第四条，每周做一次问题汇总，统计本周最常见的问题类型，据此调整切分参数或预审规则。
第五条，每个月做一次抽样质量审计，随机抽取已入库的块做质量复检，发现问题追溯成因并修正流程。
4.7 常见问题与应对
| 问题现象 | 根本原因 | 应对方法 |
|---|---|---|
| 检索不到相关内容 | 切分太粗或太碎，语义单元偏离用户意图 | 调整该文档类型的切分粒度和策略 |
| 检索到的内容不相关 | 元数据标注不准确，或分块时跨主题混入噪音 | 加强人工审核中的格式检查，优化切分边界 |
| 知识块之间有大量重复 | 去重阈值设置过低 | 提高语义去重的相似度阈值 |
| PDF 解析乱码 | PDF 本身是扫描件或字体嵌入不完整 | 先做 OCR，再进行文字提取 |
| 课件检索效果差 | PPT 按字数切分破坏了每页的完整性 | 改为一页一块的策略 |
| 审核效率太低 | 审核流程设计不合理，高等级块也逐条过 | 实施分层审核，高等级免审，中等级抽样 |
| 新文档类型入库后效果差 | 没有针对该类型的切分策略 | 先用兜底策略入库，跑两轮后根据效果调优 |
浙公网安备 33010602011771号