RAG（检索增强生成）是目前大模型落地企业应用最主流的方案。它的核心逻辑很简单：把私有知识库“喂”给大模型，让它基于事实回答问题，而不是瞎编。
听起来简单，但真正做起来，很多团队会发现效果远不如预期：
• 检索回来的内容不相关； • 模型回答张冠李戴； • 文档一多，检索速度慢如蜗牛。
今天，我们就从工程落地的角度，拆解一个企业级 RAG 系统的完整构建路径，重点讲清楚三个核心环节：文档解析、分块策略和检索优化。
- 文档解析：Garbage In, Garbage Out
RAG 的第一步是把各种格式的文档（PDF, Word, PPT, Markdown, HTML）变成纯文本。这一步看似简单，实则坑最大。
常见痛点：
• PDF 乱码/断行：PDF 本质上是“画”出来的，直接提取文本往往会出现段落断裂、表格错乱、页眉页脚干扰。 • 多图多表：纯文本提取会丢失图片中的信息和表格的结构化数据。 • 格式噪音：大量无关的样式代码、广告、导航栏文字。
解决方案：
- 专用解析器：不要只用简单的 PyPDF2。尝试 Unstructured.io、LlamaParse 或 Marker。它们能更好地处理布局、表格和公式。
- OCR 补位：对于扫描件或图片型 PDF，必须上 OCR（如 PaddleOCR）。
- 清洗规则：建立一套清洗 pipeline，去除页眉页脚、无关链接、过短的行。
经验之谈：如果文档中表格很多，建议将表格单独提取并转换为 Markdown 或 JSON 格式存储，因为大模型对结构化数据的理解能力远强于纯文本表格。
- 分块策略（Chunking）：粒度决定成败
把长文档切成小块（Chunk），是为了让向量数据库能存下，也让检索更精准。切得太碎，丢失上下文；切得太大，噪音太多，且容易超出模型上下文窗口。
主流策略对比：
| 策略 | 描述 | 适用场景 |
|---|---|---|
| 固定字符/Token 切分 | 每 500/1000 个字符切一刀。 | 简单快速，但容易切断句子或段落。 |
| 递归字符切分 | 按段落、句子、单词优先级切分。 | 大多数通用场景，能保持语义完整性。 |
| 基于结构切分 | 按标题（H1, H2, H3）切分。 | 结构清晰的文档（如技术文档、书籍）。 |
| 滑动窗口（Overlap） | 相邻块之间保留部分重叠内容。 | 强烈推荐。能有效避免关键信息被切在边界上。 |
推荐配置：
• Chunk Size: 500-1000 tokens • Overlap: 50-100 tokens • 工具推荐: LangChain 的 RecursiveCharacterTextSplitter 是最常用的起点。
- 检索优化：从“搜得到”到“搜得准”
向量检索（Vector Search）是 RAG 的灵魂，但仅仅靠相似度匹配（Cosine Similarity）往往不够。
优化手段 1：混合检索（Hybrid Search）
• 向量检索：擅长语义匹配（如“怎么退钱”匹配“退款流程”）。 • 关键词检索（BM25）：擅长精确匹配（如“错误代码 503”）。 • 重排序（Rerank）：将两种检索结果合并，再用一个专门的 Rerank 模型（如 BGE-Reranker, Cohere Rerank）进行打分排序。 • 效果：混合检索 + Rerank 通常能将召回率提升 20%-30%。
优化手段 2：元数据过滤（Metadata Filtering）
• 在存入向量库时，给每个 Chunk 打上标签：doc_id, date, department, version。 • 检索时，先过滤（如“只查 2024 年的技术文档”），再向量匹配。 • 优势：大幅减少噪音，提高精准度。
优化手段 3：Query 改写与扩展
• 用户的问题往往很短或很模糊。 • 步骤：
-
用户问：“API 慢了怎么办？”
-
LLM 改写成：“API 响应延迟高的原因及优化方案”、“如何排查 API 性能瓶颈”。
-
用改写后的多个问题去检索，合并结果。
-
架构全景图
一个成熟的企业级 RAG 架构通常长这样：
-
数据接入层：连接器（Connextors）从 S3, Git, Confluence, DB 抓取数据。
-
处理层（ETL）：解析 -> 清洗 -> 分块 -> Embedding。
-
存储层： • 向量数据库：Milvus, Pgvector, Chroma, Pinecone。 • 原始存储：MinIO, S3（存原文，用于引用溯源）。
-
检索层：混合检索 + Rerank + 元数据过滤。
-
生成层：Prompt 组装（System Prompt + 检索内容 + 用户问题）-> LLM 生成 -> 流式输出。
-
避坑指南
-
不要迷信 Embedding 模型：BGE, M3E, text-embedding-3-large 差距没那么大，数据质量和检索策略的影响更大。
-
评估！评估！评估！：建立测试集（Golden Dataset），定期跑 RAGAS 或 TruLens 评估指标（上下文准确率、答案忠实度）。没有评估，优化就是盲人摸象。
-
处理“不知道”：如果检索内容相关性很低，让模型直接回答“知识库中未找到相关信息”，而不是强行回答。
结语
搭建 RAG 系统不难，难的是调优。它是一个典型的“数据驱动”工程，需要不断通过 Bad Case 分析，调整分块大小、优化解析规则、微调检索权重。
希望这篇实践指南能帮你少走弯路。如果你在 RAG 落地中遇到了具体难题，欢迎在评论区交流。
