RAG 系统在常规的短文问答上表现稳定，但遇到长文档、复杂表格、图片为主的内容时，检索和生成质量往往明显下降。这不是系统“坏了”，而是现有技术栈在面对这些特殊文件形态时，存在一些几乎无法绕开的瓶颈。理解这些限制，才能在方案设计阶段就做出合理取舍，避免用错场景。
1. 长文档：语义被稀释，关键信息沉底
长文档（如几十页的合同、上百页的技术规范、完整的研究报告）对 RAG 的挑战主要体现在两个层面：
- 切分（chunking）导致上下文断裂
文档必须被切分成固定大小（例如 512 token）的片段才能索引。但长文档中的论述往往是连续递进的，切片会切断段落之间的逻辑关系。比如一条免责声明横跨两个切片，检索时很可能只命中其中一半，另一半的限定条件丢失，导致生成误读。
- 检索信号的稀释效应
长文档中充斥着大量过渡、重复、背景信息，真正“关键”的几句可能只占全文的 1%。向量相似度检索容易被大段无关文本带偏，将关键碎片排到检索结果后面甚至直接漏掉。最终喂给模型的是外围描述，而核心条款没有进入上下文。
现实表现：用户问“这个合同里违约金怎么算？”系统可能只检索到“违约责任详见第七条第3款”这种指向性语句，而实际条款内容因为被切在了另一段里未被召回，回答变成“合同提到了违约责任，但未给出具体金额”，事实错误。
应对思路（非银弹）：
- 对长文档预先做结构性切分，即按章节、条款边界自然切块，而不是死板的固定长度。
- 引入检索后重排序，优先把完整条款文本而不是交叉引用送进生成器。
- 对特别重要的长文档保留一份“摘要索引”，先用摘要快速定位，再拉取对应原文完整区间。
2. 复杂表格：结构信息丢失，数值无法检索
PDF 或 Word 中的表格，经文本提取后往往变成混乱的字符串，行列对齐关系荡然无存。直接将这些混乱文本切片后做向量检索，效果通常很差：
- 语义单元破坏：一行的“产品A | 200W | 1.2kg”被提取成三个无关联的数字和单词，失去原本的“属性名—值”对应关系。检索“产品A的功率”时，向量可能匹配到其他产品的功率值。
- 数值不可比：表格中的数字在嵌入模型中被当作普通 token，模型并不真正理解 200W 与 300W 的大小关系。精确的数值比较（如“价格低于 500 元”）在语义检索中几乎是盲区，极易出错。
- 多级表头、合并单元格：这些结构在纯文本化后完全丢失，解读出来的信息碎片往往毫无意义。
现实表现：问“型号 XT-5 的待机功耗是多少？”系统可能检索到同样包含“XT-5”和“功耗”的但来自另一张表格（如测试条件表）的片段，给出错误数值。或者因为表格被拆乱，干脆检索不到。
应对思路：
- 对表格密集型文档采用专门的表格解析工具，将每行数据转成结构化 JSON 或 Markdown 表格保留列名行。
- 针对数值型查询建立结构化检索链路（例如同时使用全文搜索加数据库查询），用 RAG 处理叙述性部分，精确数值直接查表。
- 考虑使用支持表格理解的多模态模型直接对页面图片进行问答，绕过文本提取损失。
3. 图片内容：文本提不出来，多模态链路长
大量企业文档以扫描件、包含流程图、架构图、产品照片等形式存在。典型 RAG 流程依赖文本表征，图片直接成为盲区：
- OCR 质量不可靠：旧扫描件、手写批注、低分辨率图片的 OCR 准确率不高，嵌入向量所依赖的文本本身已经失真。
- 视觉信息完全丢失：架构图、流程图、趋势折线图传达的信息无法用文本替代。纯文本 RAG 对“系统包含几个模块”“销量从哪年超过 200 万”这类只能靠看图回答的问题无能为力。
- 图片与周围文本的关联断裂：图文并茂的文档中，图片说明（caption）有时被提取，但图片内容没有被索引，模型只能根据说明胡猜。
现实表现：用户询问某操作手册中“连接器接口定义”，手册里是一张带引脚标注的实物照片，经 OCR 后仅得到几个数字，无法形成有效检索和回答。最终系统返回“未找到相关信息”。
应对思路（仍在快速演进中）：
- 采用多模态大模型对图片单独生成描述文本，并将描述与图片一起索引入库，实现“以文搜图”的近似。
- 对结构性强的图表（如流程图）尝试转成结构化文本描述（如步骤链）再入库。
- 关键图片保留其原始文件链接，生成回答时如果涉及，则返回图片本身由用户自己查看——这已经不是严格意义上的 RAG 解答，而是退化为引用附件。
4. 大文件处理的底线认知
处理大文件、复杂表格、图片内容时，RAG 的效果天花板受当前技术条件制约明显。设计系统时需要有清晰预期：
- 不要指望纯文本 RAG 能处理好数值计算和多模态理解，这是任务类型错配。
- 文档预处理投入往往比模型调优更重要——解析得干净，后面才能检得到、问得出。
- 某些场景更适合“检索+人工查阅”而非全自动问答，强行要求系统给出最终答案反而会制造新的幻觉。
认清这些限制，在实践中就能更务实地划定应用边界，只在 RAG 优势最大的文本理解类任务上发力，对于其他形态的信息，则搭配工具或人机协同来弥补，让整个系统看起来“弱在某些点”，但整体真实可靠。