Production RAG 为什么在 LLM 生成前就已失败：检索管道修复指南

当检索增强生成（RAG）系统输出错误或不完整的答案时，开发者通常首先归咎于大语言模型（LLM）。我们习惯于不断调整 Prompt 提示词、修改上下文窗口配置，或者更换推理模型（比如在 DeepSeek-V3、Claude 3.5 Sonnet 与 OpenAI o3 之间切换）。

然而在生产环境中，绝大多数 RAG 系统的故障早在 Prompt 抵达 LLM API 之前就已经发生了。LLM 之所以回答错误，不是因为它缺乏逻辑推理能力，而是因为前面的检索管道（Retrieval Pipeline）喂给它的是被扭曲的信息：被格式化损坏的 PDF 表格、过期的政策文档、丢失了上下文关系的孤立切片（Chunk），或是因为大量近乎重复的段落挤占了检索 Top-k 名额。

检索管道绝不是一个中立的搜索透传层，它直接决定了模型被允许感知怎样的世界。要构建高可用的企业级 RAG 架构（尤其是在使用类似 n1n.ai 这样高速、多模型集成的 API 基础设施时），你必须对从文档解析入库到上下文注入的全流程进行精准排查。

1. 源数据解析损坏：被结构化“压扁”的文档

许多团队在搭建 RAG 入库层（Ingestion Layer）时犯的第一个错误，就是将文档解析视为简单的纯文本提取：读取文本、按字数切碎、计算 Embedding、存入向量数据库。

但是，普通的文本提取器会抹平标题层级、表格列关系、图片说明和脚注，从而彻底摧毁文档的语义结构。

典型失败场景

假设你的企业政策文档中包含一张关于员工福利的 PDF 表格：

如果使用普通的纯文本提取器，该表格可能会被展开成如下单行字符串： 方案级别 月度补贴 年度最高限额 自费上限 Tier A $100 $1,200 $500 Tier B $200 $2,400 $1,000

当用户询问 “Tier B 方案的年度最高限额是多少？” 时，虽然向量检索能够匹配到包含这些词汇的切片，但当文本送入 LLM 后，表格的行列对应关系已完全丢失，模型只能靠概率乱猜。

生产级解决方案：感知结构的文档解析

入库层必须输出结构化的数据块（Block），而不是一摊无序的字符。针对表格数据，应将其转换为 Markdown 表格、CSV 格式或 JSON 结构。

from dataclasses import dataclass
from typing import List, Optional

@dataclass
class ParsedBlock:
    block_id: str
    doc_id: str
    kind: str  # "heading