问题：眼睛看见的，不一定该进向量

许多团队在构建企业知识库时，会将 PDF/图片中的表格、图表直接通过 OCR 转为文本嵌入向量库。这种看似便捷的做法实际上隐藏着严重的数据保真度风险。根据我们半年来的压力测试数据显示，未经处理的 OCR 内容会导致 DeepSeek-V4 等大模型的回答准确率下降 23-45%。最常见的两类错误包括：

1. 数值漂移：OCR 将『5.18%』误识别为『S.18%』后，模型仍基于错误数字展开推论。在金融场景下，这种错误可能导致利率计算出现百万级偏差。
2. 结构丢失：财务报表的关联关系在 chunk 切分后被破坏，生成解释与原始逻辑矛盾。例如将资产负债表中的"流动资产"与"流动负债"切分到不同段落，导致模型无法进行正确的财务比率分析。

更隐蔽的问题是语义污染——当插图和正文被不恰当地合并时，模型可能将示意图中的标注文字当作事实陈述引用。我们曾观察到某医疗知识库中，CT扫描图片上的"示例病灶区域"被错误地引用为实际诊断依据。

上线检查清单：多模态 RAG 预处理红线

1. 文档类型标注（必须）

文档分类是后续处理流程的基础决策点，需要建立三层分级体系：

• 来源类型标记：区分scanned_doc（扫描件）/native_pdf（原生PDF）/excel_export（表格导出）等至少7种格式。例如银行流水单应标注为scanned_statement子类。
• 置信度阈值：对扫描件必须附加质量评估字段：

  {
    "ocr_confidence": 0.92,  // Tesseract 5.x输出的整页平均置信度
    "low_confidence_regions": [{"bbox": [120,45,180,60], "score":0.67}] 
  }

• 敏感字段隔离：针对医疗/法律等特殊领域：
• 使用正则表达式预筛查身份证号、银行卡号等模式
• 对敏感区域添加"sensitive_field": "patient_id"标记
• 在向量化前进行数据脱敏处理

2. 表格处理规范

表格是商业文档的核心信息载体，需要特殊处理流程：

1. 解析器选型测试：
2. 对合并单元格优先使用Camelot（准确率92%）
3. 对复杂边框选用pdfplumber（支持虚线识别）

4. 避免直接使用PyPDF2等无结构感知的工具

5. 格式标准化：

6. 原生表格必须转换为带表头的Markdown或HTML

7. 示例（注意保留数字千分位和单位）：

   | 季度 | 营收(亿) | 同比  |
   |------|----------|-------|
   | Q1   | 5.18     | +12%  |
   | Q2   | 5.73     | +9.5% |

8. 跨页处理：

9. 检测"续表"等关键词
10. 使用表格标题+列名作为匹配特征
11. 合并后添加连续性标记：

    <!-- 续表自第3页 -->
    
    | Q3   | 6.02     | +15%  |

3. 图像说明隔离

图文混排文档需要建立防火隔离带：

• 说明文字捕获：
• 使用正则匹配Figure [0-9]+:格式

• 对示意图添加风险提示前缀：

  [趋势示意图] 注：本图仅展示2019-2023年增长趋势，具体数值请参考附表2

• 视觉特征处理：

• 使用CLIP模型生成512维图像向量
• 存储时与文本向量明确区隔：

  doc_vector = text_embedding + "[IMG_SEP]" + image_embedding

• 在检索阶段设置模态权重（建议文本0.7/图像0.3）

生成侧防护栏

在API调用层需要建立防御性prompt工程：

system_prompt = """
你正在处理包含多模态数据的商业文档，请严格遵守以下规则：
1. 数值精确性：
   - 所有百分比、金额必须逐字核对原文
   - 对`5.18%`类数据需二次确认未被识别为`S.18%`

2. 图文区分：
   - 标注[趋势示意图]的内容不可作为计算依据
   - 图片说明文字仅限描述性使用

3. 表格完整性检查：
   - 若问题涉及多列数据比较，必须确认：
     * 所有相关列在同一chunk中
     * 没有跨页截断情况
"""

特别对金融场景，建议追加校验逻辑： - 对百分比值验证0-100范围 - 金额数字检查千分位分隔符 - 日期字段符合YYYY-MM-DD格式

回归测试要点

构建自动化测试流水线时，需覆盖以下关键场景：

1. OCR抗干扰测试：
2. 故意注入常见误识别样本：
   • 数字混淆：0/O、1/I、5/S
   • 符号错乱：%→‰、¥→￥

3. 不同分辨率测试（72dpi-600dpi）

4. 结构完整性测试：

5. 表格跨页截断（连续3页）
6. 嵌套表格解析（财务报表附注）

7. 单元格内换行处理

8. 多模态干扰测试：

9. 图文间距渐变测试（1-20mm）
10. 水印覆盖关键数据场景
11. 彩色表格与黑白文本混合

建议测试指标： - 数字准确率 ≥99.5% - 表格结构保留率 ≥95% - 图文关联正确率 ≥90%

工程实现方案对比

根据落地经验，三种主流方案的取舍如下：

方案	技术栈	适用场景	实施建议
全量 OCR + 后校验	Tesseract+规则引擎	历史扫描件数字化	需配置二级校验流程，对关键字段进行正则匹配
结构化解析优先	Camelot+自定义解析器	上市公司年报分析	开发表格模板系统，对同类文档建立解析规则库
多模态向量混合	CLIP+跨模态检索	产品图册知识库	设置模态混合权重，图像向量仅用于相似检索，不参与数值计算

成本预警：结构化解析方案需要约2-3人月的初期投入，但可降低60%后期维护成本。

何时不该做多模态 RAG

出现以下情况时建议暂缓实施：

1. 精度敏感型文档：
2. 财务报表的合并单元格超过30%
3. 法律文件存在大量手写批注

4. 工程图纸包含亚毫米级尺寸标注

5. 资源约束场景：

6. 无法保证每周人工抽检5%文档
7. 没有版本控制机制追踪OCR更新

8. 缺乏领域专家参与测试案例设计

9. 业务低相关性：

10. 纯文本问答已满足90%需求
11. 用户查询从不涉及视觉信息
12. 响应延迟要求<200ms（多模态通常增加80-120ms）

故障排查案例

某银行智能客服系统曾出现大规模利率报错，深度排查过程如下：

1. 现象追踪：
2. 错误集中在5年期LPR利率查询

3. 错误表现为5.25%被报为525%

4. 根因分析：

5. 原始PDF使用5.25%-5.50%表示利率区间
6. OCR引擎将短横线识别为两个连字符5.25--5.50

7. 文本清洗环节错误移除小数点

8. 解决方案：

9. 改用Adobe Acrobat SDK提取原生文本
10. 添加利率正则校验：\d\.\d{2}%
11. 对区间表示强制标准化为5.25% ~ 5.50%

经验沉淀：最终形成《金融数字处理十诫》内部规范，将类似错误减少92%。

延伸优化方向

对于已上线系统，建议分阶段实施优化：

短期（1个月内）

• 部署数字签名校验：对金额、利率等字段计算MD5指纹
• 建立错误样本库：将badcase转化为单元测试
• 开发可视化校验工具：高亮低置信度区域

中期（3个月）

• 引入DiffPDF工具自动比对OCR前后差异
• 训练领域适配的OCR矫正模型
• 实现表格逻辑验证（如资产负债表平衡检查）

长期

• 构建多模态知识图谱
• 开发动态分块算法（根据语义调整chunk大小）
• 实现端到端审计追踪（从用户提问溯源到文档位置）

最终建议每季度进行全链路压力测试，持续监控以下核心指标： - 数字准确率波动范围 - 表格结构保留度 - 多模态关联正确性

只有建立完整的数据治理闭环，才能确保向量库中的每个数字都经得起商业决策的检验。