问题一：多模态 chunk 边界如何划定才不会破坏语义？

• 文本与图像混合场景：当 PDF 或网页中图文混排时，按固定字符数切分会割裂「图注-图像」关联。DeepSeek 建议优先用版面分析工具（如 LayoutParser）获取物理区块，再对每个区块单独处理。实测表明，基于视觉分块的召回准确率比纯文本分块提升 28-35%。
• 表格的特殊性：直接按行拆分会导致列关系丢失。工程实践表明，将表格转为 Markdown 后应保留为独立 chunk，并添加表头元数据（如表格1-销售数据-今年）。对于复杂表格，可采用：
• 表头冻结：固定前两行作为上下文
• 列聚类：对相似列（如「Q1-Q4」）合并编码
• 数值归一化：统一单位与精度
• 反例警示：某电商客服系统曾因将商品规格表按 512 tokens 强制拆分，导致「颜色-尺寸」对应关系错乱，召回准确率下降 37%。事后分析显示，60%的错误源于跨 chunk 的键值对分离。

问题二：表格入向量库有哪些灾难性案例？

• 结构失真：OCR 识别表格时，若未处理合并单元格，会生成断裂的 markdown。曾观测到金融报告中的「年度累计」字段被分散到 3 个不相关 chunk。解决方法包括：
• 预处理阶段用 OpenCV 检测单元格边框
• 对不规则表格采用 HTML 格式保留跨行跨列属性
• 添加结构校验规则（如「每行列数必须一致」）
• 数值归一化缺失：货币单位（如¥/$）、百分比符号若未被显式标注，可能使向量相似度计算失效。某能源报表检索时因未统一「万吨」与「MT」导致相关文档漏召。建议方案：
• 建立单位转换词典（1吨=0.9842长吨）
• 对数值字段强制类型标注（type:currency/percentage）
• 在 embedding 前添加单位后缀（如「营收_亿元」）
• 元数据泄漏：某法律合同解析案例中，表格页码信息丢失导致关键条款无法定位。必须保留：
• 原始文档坐标（x,y,width,height）
• 上下文章节标题
• 时间戳与版本号

问题三：多模态 golden set 如何构造才不易泄漏？

• 测试数据污染：当验证集包含与训练数据同源的文档（如年报的不同章节），会导致评测虚高。应确保 golden set 来自独立数据源。具体操作：
• 按文档哈希值去重
• 检查发布时间间隔（>3个月）
• 人工抽样验证内容独立性
• 多模态对齐检查：人工标注时需验证「图像描述文本」与「实际图片内容」的一致性。某医疗数据集发现 12% 的 X 光片描述与影像实际病灶位置不符。改进方法：
• 使用 CLIP 计算图文相似度阈值
• 对关键区域（如签字栏）建立强制匹配规则
• 引入双人标注仲裁机制
• DeepSeek 实测方案：
• 文本链：用 BM25+embedding 混合检索初筛（权重 6:4）
• 视觉链：CLIP 模型过滤图文相关度 <0.7 的结果
• 重排阶段：cross-encoder 对 Top20 结果精排
• 最终精度提升 22% 但 GPU 成本增加 3 倍（需权衡）

工程落地检查清单

1. 预处理阶段
2. [ ] 验证 OCR 对特殊符号（如±°）的识别率
3. [ ] 检测表格合并单元格的还原度

4. [ ] 检查图像分辨率是否≥300dpi

5. 向量化阶段

6. [ ] 对数值字段添加单位元数据
7. [ ] 测试 chunk 大小对 recall@k 的影响曲线

8. [ ] 验证跨模态 chunk 的关联性（如图文余弦相似度）

9. 评测阶段

10. [ ] 构造包含 5% 对抗样本的测试集（如篡改表格）
11. [ ] 监控不同分块策略的 P99 延迟差异
12. [ ] 记录单位 token 的 embedding 计算成本

边界说明

• 不做 RAG 的情形：
• 高密度数值报表（如股票行情）→ 直接存关系库+SQL
• 频繁更新的日志流 → 用 Elasticsearch 前缀匹配

• 强结构化表单 → 解析成 JSON 字段查询

• 成本敏感场景：

• 纯文本链 P95 延迟 180ms（4vCPU），加入视觉链后升至 420ms（T4 GPU）
• 建议在网关层按 Content-Type 动态路由（application/json 走文本链）

• 对历史数据可预生成向量，实时数据走轻量化 pipeline

• 失败案例归因：

• 42% 源于不合理的分块策略
• 33% 因缺失元数据导致上下文断裂
• 25% 由多模态对齐误差引发