从RAG出发

从RAG出发

1. RAG的概念和背景

1.1 什么是RAG

RAG（Retrieval-Augmented Generation，检索增强生成）是一种将 信息检索 与 大语言模型生成 融合的技术架构。

其核心思想是：在模型生成前，通过检索外部知识库获取相关信息，再将这些信息与用户问题一同输入生成模型，从而生成更加准确、可解释的回答。

相较于传统大语言模型（LLM）：

• 知识截止：模型训练数据有时间限制，无法覆盖最新信息；
• 幻觉问题：模型可能生成表面合理但错误的信息；
• 领域知识不足：对特定业务或企业内部信息掌握有限；
• 个性化缺失：无法基于用户特定知识库生成回答。

RAG 通过引入外部知识库和检索机制，有效缓解以上问题，使生成内容可追溯、可验证，同时支持企业定制化知识。

1.2 为什么 AI 平台需要 RAG

在企业级 AI 平台中，RAG 的价值主要体现在以下几方面：

1. 知识实时性
   • 企业内部知识、政策、市场信息不断更新。
   • 仅依赖 LLM 的静态训练语料无法满足实时信息需求，RAG 可以动态接入知识库。
2. 私有化知识管理
   • 企业数据通常是私有的，不在公开语料中。
   • RAG 能直接使用企业文档、报表、数据库，满足内部业务场景。
3. 可解释性与可信度
   • RAG 能提供答案来源（Reference），用户可验证。
   • 增强业务场景中的可靠性，降低风险。
4. 可控性与个性化
   • 可以通过设计知识库结构、检索策略和提示词模板来控制输出风格和内容。
   • 支持多行业、多场景、多用户的定制化应用。
5. 平台化扩展性
   • 支持多模态文件解析（PDF、Excel、图片、Markdown）。
   • 支持多存储后端（向量库、ES、关系型数据库、图数据库）。
   • 支持统一服务能力（embedding、reranker、query 改写），模块化可复用。

2. RAG 解决的问题

2.1 大模型的知识局限

• 静态语料：训练完成后无法获取最新知识。
• 领域适配不足：无法针对企业内部知识或专业领域进行有效回答。

2.2 幻觉与不可靠输出

• LLM 生成看似合理但错误的回答，无法提供文档来源。
• 在金融、医疗、法律等高要求场景不可接受。

2.3 可溯源与可解释性

• 通过 RAG，生成回答时可插入文档引用。
• 支撑企业对知识源管理、内容验证和合规性需求。

2.4 平台化的扩展性需求

企业级 AI 平台对 RAG 的需求不仅是“答案更准”，还涉及：

• 多模态支持：文本、表格、图片等。
• 大规模检索与计算：需要高并发、高吞吐的向量检索和模型推理。
• 模块化能力：embedding、reranker、query 改写可复用、可扩展。
• 可维护性：模型升级、知识库更新、算力扩展要低风险。

3. RAG 的通用流程

RAG 的执行流程可分为 离线知识库构建阶段 和 在线查询生成阶段。在企业 AI 平台中，每个阶段不仅关注功能正确，还涉及 性能优化、模块复用、可扩展性和可维护性。

---

3.1 知识库构建阶段（离线处理）

3.1.1 文档收集与预处理

• 目标：将原始企业文档标准化为可处理格式。
• 处理策略：
  1. 文件类型识别：文本、PDF、Markdown、Excel、图片等。
  2. 格式标准化：
     • PDF → minerU JSON → Block 级结构化信息
     • Excel → HTML 或 Key-Value 对象
     • 图片 → OCR 或多模态模型解析文字/图表
  3. 噪声过滤：去除无实际意义的图标、二维码等内容。
• 设计 rationale：不同文件类型采用策略模式（BlockProcessorStrategy），保证 易扩展、低耦合。

3.1.2 文本切分与元数据标注

• 目标：生成语义完整的 chunk，以适应模型上下文窗口。
• 处理策略：
  • 长文档按段落/标题切分，保证上下文完整性。
  • 对每个 chunk 添加元数据：标题、来源、时间、文件 ID 等。
• 设计 rationale：确保后续向量化检索的精度，同时支持溯源和引用标注。

3.1.3 向量化 Embedding

• 目标：将每个 chunk 转换为高维向量，捕捉语义信息。
• 处理策略：
  • 使用专用 embedding 模型（如 bge-large-zh）。
  • 批量处理，支持 GPU 并行，提高计算效率。
  • 向量归一化，便于后续余弦相似度计算。
• 设计 rationale：通过向量化，支持 快速语义检索，避免仅依赖关键词匹配的局限。

3.1.4 向量存储与索引

• 目标：将向量及元数据存储到数据库，支持高效检索。
• 处理策略：
  • 向量库（Milvus / VectorDB）：存储 embedding，支持高并发检索。
  • ES / MySQL：存储原始文本、元数据和关键词索引。
  • 异步任务队列（Kafka）：解耦文档解析、向量生成、存储任务。
• 设计 rationale：混合存储兼顾性能和灵活性；异步队列提高吞吐量并保证任务可靠性。

3.2 查询生成阶段（在线处理）

3.2.1 Query 改写与优化

• 目标：增强用户查询与知识库匹配度，提高检索精度。
• 处理策略：
  • 问题扩展：添加同义词、上下文提示。
  • 语义增强：使用小型 LLM 或规则模型进行 query rewrite。
• 设计 rationale：减少检索噪声，提高 top-k 候选片段的相关性。

3.2.2 候选召回（Recall）

• 目标：从向量库和关键词索引中获取相关 chunk。
• 处理策略：
  • 向量召回：使用余弦相似度或欧氏距离，返回 top-k 向量片段。
  • 关键词检索：利用 BM25 或 ES 查询，补充精确匹配片段。
  • 混合召回：结合向量和关键词得分，加权生成候选列表。
• 设计 rationale：向量检索捕捉语义，关键词保证精确性，二者互补。

3.2.3 重排序（Reranker）

• 目标：提高召回片段与用户问题的相关性，剔除噪声。
• 处理策略：
  • 输入 query 与候选片段，使用 reranker 模型计算匹配分数。
  • 按得分排序，保留 top-n 用于生成。
• 设计 rationale：向量检索存在噪声，reranker 提升召回质量，尤其对长尾问题效果明显。

3.2.4 内容生成（LLM）

• 目标：基于候选片段生成最终回答。
• 处理策略：
  • 将 top-n chunk 与用户问题拼接，构造 LLM 输入。
  • 使用大模型（如 Qwen2.5-VL）生成回答。
• 设计 rationale：通过拼接上下文，增强回答事实性，减少 hallucination。

3.2.5 溯源与引用标注

• 目标：在回答中插入来源，保证可溯源性。
• 处理策略：
  • 计算答案片段与参考块的 关键词相似度 + 向量相似度，加权计算综合得分。
  • 综合得分超过阈值则插入引用。
• 设计 rationale：提供答案来源，增强可信度，同时支持审计和业务合规。

3.3 流程图示意

用户问题│▼
Query 改写 ──► 候选召回 ──► 重排序 ──► LLM 生成回答 ──► 溯源标注 ──► 返回用户▲│向量库 + ES + MySQL▲│文档解析切分 & Embedding

3.4 工程要点总结

1. 模块化设计：每一步都是独立服务或函数模块，方便扩展与替换。
2. 异步与批量处理：文档解析、向量化使用队列和批量操作，支持高吞吐。
3. 多存储策略：向量库 + ES + SQL 混合存储，兼顾速度与灵活性。
4. 资源分配优化：不同任务类型分配 GPU / CPU，提升性能并节约算力成本。
5. 可观测性：各阶段可统计吞吐量、响应时间、召回准确率、LLM 生成质量。