从需求到事故的时间线

第一阶段：业务方提出多模态 RAG 需求

某金融合规部门要求将 PDF 年报、扫描合同接入知识库，支持自然语言查询表格数据。技术团队评估后决定： - 使用开源 OCR 工具提取文字（含表格） - 按段落分 chunk 存入 Milvus - 用 DeepSeek-V4 作为生成模型

关键误判：认为 OCR 后的文本与普通文档等价，未处理版面结构和置信度标记。

第二阶段：上线首周暴露问题

监测发现 34% 的表格类查询返回错误数据，典型 case： 1. 用户问「今年年Q3净利润增长率」 2. OCR 将「5.8%」误识别为「S.8%」 3. 向量检索返回包含错误数字的 chunk 4. DeepSeek 基于错误上下文生成「增长率约为 8%」

根因分析： - 未清洗低置信度 OCR 结果（<90% 的字符未过滤） - 表格结构丢失导致跨单元格语义断裂 - 未标注数据来源类型（人工录入 vs OCR 识别）

第三阶段：改进方案实施

结构化预处理流水线

1. 文档分类：用 LayoutLM 区分正文/表格/页眉页脚
2. 表格处理：
3. 使用 Camelot 提取表格结构
4. 添加 `` 标记行列关系
5. 原始图片哈希值存入 metadata
6. OCR 质量控制：
7. 过滤置信度 <85% 的文本行
8. 可疑数字添加 `` 标记

检索优化

• 对表格类 query 启用混合检索：
• 50% 向量相似度（文本语义）
• 30% 表格结构匹配（行列标题）
• 20% 时间戳匹配（针对财务数据）
• 为 DeepSeek 添加 prompt 约束：

  当回答涉及表格数据时：
  1. 必须检查数据是否来自高置信度来源
  2. 若发现 `` 标记需声明「该数据可能存在识别误差」

第四阶段：效果验证

• 构建测试集：200 个含表格的 query
• 改进前后对比：

工程实现细节补充

OCR 处理优化方案

1. 预处理增强：
2. 对扫描文档先进行去噪、锐化处理
3. 针对财务表格使用特定区域 OCR 模型
4. 置信度分级策略：
5. 高置信度（>95%）：直接入库
6. 中置信度（85%-95%）：标记警告
7. 低置信度（<85%）：丢弃或转人工审核
8. 错误模式库：
9. 建立常见 OCR 错误映射表（如「S↔5」「1↔l」）
10. 对关键数字字段执行强制校正

检索策略深度优化

1. 多路召回机制：
2. 第一路：常规向量检索
3. 第二路：表格结构特征匹配
4. 第三路：关键数字精确匹配
5. 动态权重调整：
6. 检测到查询包含「增长率」「同比」等关键词时
7. 自动提高数字精确匹配的权重至 40%
8. 时效性处理：
9. 为财务数据添加年度/季度标记
10. 对时间敏感查询优先返回最近期数据

DeepSeek 生成控制

1. Prompt 工程进阶：

   你正在处理财务文档，请遵守：
   1. 所有百分比/金额数据必须追溯至原文位置
   2. 发现 `` 标记时需同时给出原始图片哈希值
   3. 对跨年度比较需验证时间范围一致性

2. 输出结构化：
3. 强制要求以 JSON 格式返回答案
4. 包含 data_source confidence_score 等字段
5. 错误熔断机制：
6. 当检测到连续 3 个低置信度标记时
7. 自动转人工审核流程

关键教训

1. 不要假设 OCR 输出可直接用于 RAG：必须经过置信度过滤和结构重建
2. 多模态需要多维度检索：纯文本向量搜索对表格数据召回率有限
3. 生成模型需要约束：DeepSeek 等模型会「脑补」缺失信息，需明确数据可信度边界
4. 数据血缘至关重要：必须保留原始文档、处理中间结果和修改记录

延伸建议

• 对财务/法律文档建立人工校验环节
• 在 Milvus 中为不同置信度数据设置独立 collection
• 定期用错题集微调 DeepSeek 的风险声明倾向
• 建立端到端追踪系统：
• 从用户 query 到最终答案的全链路溯源
• 每个处理环节的置信度打分可视化

成本与性能权衡

1. 预处理成本：
2. 结构化处理使单文档处理时间增加 3-5 倍
3. 但错误率下降可减少 60% 人工复核成本
4. 检索延迟：
5. 混合检索使 P99 延迟从 120ms 升至 210ms
6. 通过异步预加载关键表结构可降低至 170ms
7. 存储开销：
8. 元数据存储需求增长 40%
9. 采用列式压缩后实际容量增加 <15%