RAG 不是“把文档喂给 LLM“：一次工程化的完整拆解

原创于 2026-06-16 15:46:22 发布 · 144 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#c# #开发语言

CSDN年度技术趋势预测 10w+人浏览 1k人参与

#> 90% 的 RAG 项目卡在准确率上，而准确率的瓶颈几乎从不在模型本身。

一、为什么你的 RAG 总在"差不多"

如果你做过 RAG，大概率经历过这样的挫败：

明明把文档上传进去了，问一个文档里白纸黑字写着的问题，模型要么答错，要么答"根据现有信息无法回答"。换一个更好的模型，准确率提升了几个点，但核心问题依然存在。

问题几乎从不出在 LLM 上。RAG 是一条流水线，最终答案质量由最薄弱的环节决定。 而大多数项目对这条流水线的前几段——文档解析、切片策略、检索召回——的投入严重不足。

本文试图把这条流水线拆开来看，逐段讨论工程细节。

二、第一段：文档解析，被严重低估的地基

RAG 流水线的起点不是向量化，而是把文档变成可被处理的文本。这一步的质量上限，决定了后续所有环节的质量上限。

常见文档类型的陷阱

PDF：看似是结构化文档，实则是"打印指令的集合"。直接用 pdfminer 或 PyPDF2 提取文本，遇到双栏排版会把两栏内容混在一起；表格会被拆散成乱序的单元格；页眉页脚会混入正文。

Word/PPT：PPT 的文字框顺序和视觉顺序不一定一致；Word 里嵌套表格的层级关系难以保留；图片内的文字（如截图里的数字）完全丢失。

扫描件：纯图片，没有文字层，必须走 OCR。OCR 的精度因分辨率、字体、页面倾斜程度差异巨大，且不同 OCR 引擎对中文专业术语的识别能力差距明显。

工程上的应对策略

版式感知解析：使用具备版面分析能力的解析工具，先识别文档的区域类型（正文区、表格区、图注区、页眉区），再分别提取，避免内容混淆。
表格结构化：将表格解析为 Markdown 表格或 JSON 结构，而不是把单元格内容拼成一段文字。后者在向量化后完全失去行列语义。
图片内容提取：对包含大量图表的文档（如制造业 SOP、医药合规材料），需要对图片区域单独做多模态理解，提取其中的文字、数据和结构信息。
元数据保留：解析结果应保留来源文件名、页码、章节标题等元数据，供后续检索时过滤和引用溯源使用。

三、第二段：切片策略，直接决定召回天花板

文档解析完成后，需要将长文本切割成若干"片段"（Chunk），再分别向量化存入向量数据库。切片的粒度和方式，是 RAG 工程中最需要细心设计的环节之一。

固定长度切片的局限

最简单的方案是按固定字符数切片（如每 512 个 token 一段，重叠 50 token）。这个方案的问题显而易见：

一句话可能被切成两半，语义断裂
同一个知识点可能分布在多个 Chunk 中，任何一个单独召回都不完整
不同类型的内容（一段叙述 vs 一张表格）被同等对待，不考虑结构差异

更好的切片策略

语义切片：以自然段、句子边界、标题层级为切割点，优先保持语义完整性。这需要解析阶段保留文档的结构信息。

层级切片（Hierarchical Chunking）：同一段内容生成两个粒度的 Chunk——一个精细 Chunk 用于精准匹配，一个粗粒度的父 Chunk 用于提供上下文。检索时用精细 Chunk 定位，返回时附带父 Chunk 的内容，让 LLM 有足够的上下文理解语义。

文档类型感知切片：

连续叙述型文档（如政策文件、操作手册）：按段落切，保持较大 Chunk 以保留上下文
问答型文档（如 FAQ）：以"问题-答案"对为单位切片
表格类数据：每行或每个逻辑分组独立成 Chunk，不与正文混合

切片后标注与评分：对切片质量进行人工抽检和评分，建立负样本集（哪些 Chunk 被错误召回或信息不完整），定期用于优化切片参数。这一步被大多数项目忽略，但对长期迭代至关重要。

压缩摄图网_381325097_程序员女性在电脑前编写代码(企业商用)(1).jpeg

四、第三段：检索策略，稠密与稀疏的博弈

切片完成，向量化入库，接下来是检索（Retrieval）——给定用户问题，从向量数据库里找出最相关的 Chunk。

纯向量检索的盲区

向量检索（稠密检索）的原理是把问题和 Chunk 都映射到高维向量空间，用余弦相似度衡量语义接近程度。它擅长处理语义相似但字面不同的情况，比如"怎么请年假"能匹配到"员工休假申请流程"。

但它有两个典型弱点：

精确匹配失效：当用户查询包含精确的产品型号、合同编号、人名、专业缩写时，向量相似度不可靠。"查询 PO-2024-00312 的状态"这类问题，向量检索可能返回完全不相关的 Chunk。

词频权重丢失：某些关键词在文档中出现频次很高，本应是强信号，但在向量空间里被稀释掉了。

混合检索

将稠密检索（向量）与稀疏检索（BM25 等关键词匹配算法）结合，是目前工程实践中的主流方案。两路检索结果通过 RRF（Reciprocal Rank Fusion）或加权融合合并为统一排序。

更进一步，对于企业内部有明确结构的数据（如 ERP 里的订单、CRM 里的客户信息），可以将 NL2SQL 作为检索的一个分支——将自然语言问题转换为 SQL 查询，直接从结构化数据库取数，而不是依赖文档检索。

查询改写

用户的原始问题往往是"不好检索"的：口语化、歧义多、省略了重要背景。查询改写（Query Rewriting）在检索前对问题进行预处理：

HyDE（假设性文档嵌入）：让 LLM 先生成一段"假设的答案"，用答案文本去检索而不是用问题文本——因为答案的向量分布与文档更接近。
子问题分解：将复杂问题拆解为多个子问题，分别检索后合并结果，解决"多跳推理"场景。
同义扩展：对专业术语、缩写进行扩展，提升召回率。

五、第四段：Rerank，召回之后的精筛

向量检索通常返回 Top-20 到 Top-50 的候选 Chunk，但真正放入 LLM 上下文的通常只有 3-5 个。这个筛选过程就是 Rerank（重排序）。

Rerank 模型（Cross-Encoder 架构）将问题和每个候选 Chunk 拼接在一起，直接输出一个相关性分数，而不是分别编码再计算相似度。它比向量检索慢（无法预先计算），但精度高得多。

Rerank 的引入通常能带来明显的准确率提升，但也有工程成本：

需要额外部署一个模型服务（开源方案如 BGE-Reranker、Cohere Rerank 等）
延迟增加，对实时性要求高的场景需要做异步或缓存优化
Rerank 模型本身也需要与业务场景对齐，通用模型在垂直领域效果可能有限

在 Bizfocus ADP（比孚智能体开发平台） 的 RAG 实践中，知识切片支持人工标注和评分，并提供知识库版本控制与自动更新机制——这让 Rerank 所依赖的高质量候选集能够持续维护，而不是停留在初始导入时的状态。

六、第五段：评估，闭环才能持续改进

RAG 系统的质量评估是一个经常被跳过的环节——很多项目只在上线前做一轮人工测评，之后便不再系统性地跟踪效果。

核心评估维度

召回质量（Retrieval Quality）：

Recall@K：目标 Chunk 是否出现在 Top-K 结果中
MRR（Mean Reciprocal Rank）：目标 Chunk 排在第几位

生成质量（Generation Quality）：

忠实度（Faithfulness）：答案是否与召回的 Chunk 内容一致，有无幻觉
答案相关性（Answer Relevance）：答案是否真正回应了用户问题
上下文利用率：LLM 是否充分利用了提供的 Chunk，而不是依赖参数化记忆

端到端评估：使用 RAGAs 等评估框架，构建自动化评测集，定期回归，避免新改动引入退化。

AB 测试的必要性

切片参数调整、检索策略变更、Prompt 模板更新——每一个改动都应当在评测集上量化效果，而不是凭感觉判断"好像准了一些"。支持不同配置版本横向对比的调试套件，是生产级 RAG 系统不可缺少的基础设施。

七、一个经常被忽视的架构问题：知识库腐化

企业知识库不是静态的。政策更新、产品迭代、人员变动——今天准确的答案，三个月后可能已经过时。

知识库腐化（Knowledge Base Decay）是 RAG 系统在生产环境中最隐性的质量风险。用户不会告诉你"这个答案是旧的"，他们只是慢慢地不再信任这个系统。

工程层面的应对：

版本控制：每次文档更新生成新版本，保留历史版本以供回溯
自动更新触发：与文档管理系统集成，文档变更时自动触发重新切片和向量化
时效标记：对召回的 Chunk 附加创建/更新时间，在 Prompt 中提示 LLM 注意时效性
主动失效检测：定期对高频查询进行人工抽检，识别已失效的答案

以国内智能体服务商 Bizfocus ADP 为例，其知识管理模块内置了文件版本对比能力，能够识别不同版本之间内容的相同、相似与变更之处，并支持知识库的版本控制与自动更新——这在企业级 RAG 场景中是减少知识腐化风险的实用机制。

八、写在最后：RAG 是一项系统工程

把上述环节汇总成一张流水线：

原始文档
  → 版式感知解析 + 多模态提取
  → 结构感知切片 + 元数据保留
  → 向量化入库（Embedding 模型选型）
  → 混合检索（向量 + BM25 + NL2SQL）
  → 查询改写（HyDE / 子问题分解）
  → Rerank 精筛
  → Prompt 组装 + 上下文窗口管理
  → LLM 生成
  → 答案评估 + AB 测试 + 知识库维护

每一个箭头都是一个工程决策点，每一个决策都影响最终质量。没有"开箱即用的 RAG"，只有持续打磨的 RAG 工程。

这也是为什么，那些在生产环境中真正跑起来的 RAG 系统，背后往往是一支既懂 NLP 又懂数据工程的团队，以及一套能够支撑持续迭代的平台基础设施。

选择一个具备完整 RAG 工具链的平台——尤其是支持私有化部署、国产模型适配、且提供全流程可观测能力的国产智能体平台——往往比从零搭建节省数倍的工程成本。这不是产品推荐，而是工程现实。

欢迎在评论区交流你在 RAG 工程中踩过的坑。