Box 开始把表格、图表和整页 PDF 直接塞进同一个向量空间：传统 RAG 的“先转纯文本”正在过时

昨天 Google Cloud 和 Box 公布了 Gemini Multimodal Embeddings 2 在 Box Agentic Platform 里的一个企业级落地方向。

这篇材料里有一句话我很赞同：

企业数据本来就是多模态的。

但我们过去做 RAG 时，常常先把它们全部强行变成文本：

PDF → OCR → Text
Excel → CSV → Text
PPT → Text
Chart → Caption
Image → OCR

最后再：

Chunk
→ Embedding
→ Vector DB

这套方法能用，也仍然会长期存在。

但它有一个非常明显的代价：

文件里很多“位置关系”在转成纯文本时已经丢了。

最容易出问题的是财务表格

看一个表：

          2025Q4   2026Q1   2026Q2
Revenue    120      135      150
Cost        80       92      103
Margin      40       43       47

如果 PDF Parser 最后输出：

2025Q4 2026Q1 2026Q2 Revenue 120 135 150 Cost 80 92 103 Margin 40 43 47

模型也许能猜回来。

但更复杂一点：

  • 多层表头；
  • 合并单元格；
  • 脚注；
  • 同比箭头；
  • 颜色标记；
  • 图表；
  • 多栏布局；

纯文本很容易把结构拆散。

Google 和 Box 这次强调的一个能力，就是把文档页面、渲染后的 Spreadsheet Table、Chart、Image 和 Text 放进统一的多模态向量空间。

换句话说：

检索单位
不一定再只是文字 Chunk

它可以是一整页。

“整页 Embedding”解决的不是 OCR 准不准

OCR 解决：

图片里写了什么字？

Layout-aware Embedding 更关心：

这些内容在页面上是什么关系？

例如：

47%

单独 OCR 出来没有意义。

它可能属于：

APAC Revenue Growth

也可能属于：

Churn Rate

列、行、标题、图例和位置共同决定语义。

我觉得多模态 RAG 现在应该从“两路索引”开始

不要一上来把旧 Text RAG 全删掉。

我更建议：

Document
├─ Text Index
└─ Visual/Page Index

查询时按问题路由。

例如：

“合同的终止条件是什么？”
→ Text Retrieval

“第12页流程图里审批从哪个节点进入？”
→ Page/Visual Retrieval

“Q2 毛利率和图表中的趋势有没有矛盾？”
→ Hybrid Retrieval

一个简单的 Query Router

def choose_retrieval_mode(query: str):
    visual_keywords = [
        "图表", "表格", "流程图", "截图",
        "哪一页", "布局", "颜色", "趋势"
    ]

    if any(k in query for k in visual_keywords):
        return "MULTIMODAL"

    return "TEXT_FIRST"

真正生产可以用小模型分类，但没必要每次都用旗舰模型。

跨模态检索最有价值的地方：Text → Visual

用户输入：

“找出所有显示库存下降，但文字说明仍然写‘库存充足’的报告。”

这是非常典型的企业问题。

需要：

文本理解
＋图表理解
＋跨文档对比

传统 RAG 如果图表只被 OCR 成几个数字，几乎做不好。

统一多模态 Embedding 的价值就在这里：自然语言 Query 可以召回真正相关的图、表、页面。

Box 给出的三个方向都很实际

第一类是复杂财务和分析报告。

需要保持：

row-column semantics
chart trend
footnote

第二类是跨模态专业资料，例如临床照片、病理图和风险矩阵。

这里安全要求极高，不能把检索结果直接当诊断结论，但从搜索角度看，跨模态关联非常有价值。

第三类我觉得对普通企业最现实：

跨文档数据对账

例如：

PDF会议纪要
Excel最新价格
PNG宣传图
邮件确认

Agent 找出：

宣传图仍然是旧价格

这类任务非常适合企业内容 Agent。

传统 Chunking 在多模态里要重新定义

Text RAG 常见：

500 Token 一个 Chunk
Overlap 50

页面级多模态检索不能这么想。

可能的检索对象变成：

Page
Table
Chart
Image Region
Slide
Spreadsheet Range

每一种都有自己的粒度。

例如财务表：

整张表

可能比：

每 500 Token 切一次

更合理。

我会给 Evidence 加一个 Geometry

传统 Evidence：

public record Evidence(
        String documentId,
        String text,
        int page) {
}

多模态以后：

public record MultimodalEvidence(
        String documentId,
        int page,
        EvidenceType type,
        BoundingBox region,
        String text,
        String imageRef,
        String contentHash) {
}

其中：

public record BoundingBox(
        double x,
        double y,
        double width,
        double height) {
}

这样回答里不只是引用：

第 12 页

而可以高亮：

第 12 页右下角表格第 3 行

这会明显改善引用体验

用户问：

“毛利率是多少？”

回答：

47%

旁边可以直接显示：

来源：Q2-Report.pdf / Page 18
[高亮对应表格单元区域]

用户不用打开 PDF 再 Ctrl+F。

这就是多模态 Evidence 的真正产品价值。

但多模态 Embedding 也会带来一个新坑：你很难肉眼 Debug Vector

Text Chunk 召回错了，可以直接看文字。

Page Embedding 召回错了，需要同时看：

  • 页面截图；
  • OCR；
  • Layout；
  • Embedding Model；
  • Query；
  • Similarity；
  • Reranker。

所以 Retrieval Trace 必须升级。

我希望能看到：

{
  "query": "Q2利润率趋势",
  "retrieval_mode": "MULTIMODAL",
  "candidates": [
    {
      "doc": "report-q2.pdf",
      "page": 18,
      "type": "TABLE",
      "score": 0.91,
      "thumbnail": "artifact://..."
    }
  ]
}

评测也不能再只有文本答案

至少增加几类 Dataset：

Text → Text
Text → Table
Text → Chart
Image → Text
Cross-file Conflict
Layout-sensitive QA

其中最值得测的是：

数字正确
＋位置正确
＋来源正确

因为多模态 RAG 最大风险之一，是模型看懂了图，但引用错页面。

我会专门做一个表格压力集

比如 100 张真实风格但脱敏的复杂表格：

  • 合并单元格；
  • 多层表头；
  • 横向页面；
  • 脚注；
  • 百分比；
  • 负数；
  • 颜色；
  • 同比箭头；
  • 缺失值。

评测：

Cell Retrieval Accuracy
Header Binding Accuracy
Numeric Accuracy
Citation Accuracy

没有这套评测，Demo 看起来非常惊艳，上生产很容易数字串列。

成本也会变化

Page/Image Embedding 通常意味着更多预处理和存储。

你要重新算：

页面渲染
OCR
多模态 Embedding
向量存储
Thumbnail
Rerank
视觉模型生成

所以不是“全部文档都多模态”一定最好。

更现实的是分级：

纯文本文件
→ Text Index

复杂 PDF / PPT / XLSX
→ Text + Multimodal

高价值文档
→ Layout + Region Index

权限问题比以前更复杂

如果一张 PDF 页面里同时出现：

普通内容
＋敏感表格

页面级向量可能把整个页面召回。

所以 ACL 不能只在 Document 层。

高敏环境需要考虑：

Document ACL
Page ACL
Region Redaction
Field Classification

否则模型虽然“检索正确”，却可能把不该看的区域一起拿进 Context。

一个现实的迁移路线

我不建议重建全部知识库。

第一阶段先挑：

PDF
PPT
财务Excel

这些最容易从多模态获益。

第二阶段建立：

Text Baseline
vs
Multimodal Candidate

比较：

  • Recall@K；
  • 数字准确；
  • 引用准确；
  • 延迟；
  • 成本。

第三阶段只把优势明显的文档类型切过去。

最后一个判断

传统 RAG 过去有一个默认假设：

文档的主要语义可以被文本完整表达

这个假设对 FAQ、Wiki、合同正文仍然成立。

但对：

财报
PPT
流程图
技术图纸
表格
扫描文档

越来越不够。

Box 和 Google 这次的方向让我更确定一件事：下一阶段企业 RAG 的升级，不只是“换一个更强 Embedding Model”，而是重新定义什么叫一个可检索的知识单元。

它可能不是 500 Token。

可能是一张表、一张图、一页 Slide，甚至一个带坐标的页面区域。

当 RAG 能保留这些结构，Agent 才真正开始理解企业文件本来的样子，而不是理解一份被 Flatten 过的文本残影。

多模态索引的数据模型最好一开始就分层

我不会把所有向量都塞进一张表，然后靠一个 type 字段勉强区分。

至少要能表达：

Document
Page
Region
Modality
Parent-Child

例如：

create table multimodal_unit (
    unit_id varchar(128) primary key,
    document_id varchar(128) not null,
    parent_unit_id varchar(128),
    page_no integer,
    unit_type varchar(32) not null,
    content_hash varchar(128) not null,
    text_content text,
    visual_ref varchar(512),
    geometry jsonb,
    acl_ref varchar(128),
    embedding_version varchar(64) not null
);

unit_type 可以是：

PAGE
TEXT_BLOCK
TABLE
CHART
IMAGE
REGION

这样检索后还可以沿 Parent 回到完整页面。

Page Recall 和 Region Recall 可以做两阶段

第一阶段：

召回相关页面

第二阶段：

在页面内部定位表格/区域

这比把一个复杂页面切成 50 个小视觉区域全部放入全局向量库更容易控制规模。

流程：

Query
→ Page Candidate Top 20
→ Region Search / Rerank
→ Evidence Top 5

不要忘记文本 Baseline

多模态方案演示很漂亮，但生产评测一定要保留 Text Baseline。

例如同样 500 个问题跑：

指标 Text RAG Multimodal RAG
Text QA 92% 92%
Table QA 63% 87%
Chart QA 41% 82%
Citation 88% 90%
P95 1.2s 2.8s

这里的数据必须来自自己的实测，我不会替项目虚构数字；这张表只是告诉你应该怎么比较。

真正上线时，很可能不是全量替换，而是：

Text QA → 继续旧链路
Table / Chart → 多模态链路

Embedding Version 变化要考虑双索引迁移

多模态 Embedding 模型升级后，不建议直接原地覆盖向量。

用：

index_v1
index_v2

双写或离线重建，再拿真实 Query 对比 Recall。

因为向量模型变化后，即使维度相同：

相似度分布也可能完全改变

原来的阈值 0.78 未必还能用。

所以版本升级必须重新校准：

TopK
Similarity Threshold
Reranker
Fallback

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/