首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >跨页表格一旦被截断,RAG 就可能答非所问:文档解析这一步,才是知识库不胡说的前提

跨页表格一旦被截断,RAG 就可能答非所问:文档解析这一步,才是知识库不胡说的前提

原创
作者头像
克劳德2048
发布于 2026-09-22 14:35:04
发布于 2026-09-22 14:35:04
1330
举报

摘要:

跨页表格被拦腰截断,列名与数值就会失联,RAG 再怎么优化排序也会答非所问。整份解析入口与分页参数,是保住表格结构、让知识库不胡说的前提。

一、表格是文档里信息密度最高、也最容易碎的地方

一份财报、一份招股说明书、一份保险条款,真正被反复问到的内容,往往不在正文段落里,而在表格里:费率对照、责任免除清单、分年度指标。表格的特点是信息密度极高,一个单元格脱离表头就几乎没有意义——"12 个月"这个数值,只有配上"保障期间"这一列才知道它是什么。

问题在于,表格也是解析环节最容易碎掉的部分。正文段落被切断,读者还能靠上下文猜出大概;表格被切断,列名和数值就随之失联,剩下的数字没有任何语义。知识库在这种碎片上做检索,召回的往往是"看起来相关"的一串数字,模型据此生成的答案自然答非所问。

工程侧排查这类问题时常陷入误区:先怀疑 embedding 模型不行,再怀疑切分策略不合理,最后才发现入库的文本里根本没有表格结构——列名在上一页,数值在下一页,中间还隔着一个页眉。

二、表格结构在解析环节碎掉的三种典型情况

2.1 情况一:续表被当成两张独立的表

长表格跨页时,第二页通常会重复表头或者只保留数据行。如果解析按页独立处理,第二页的表格就成了一张没有表头的表。切块之后,第一块带着完整列名却只有前半段数据,第二块带着后半段数据却没有列名。

检索"某产品在第几年的费率是多少",命中的很可能是第二块——系统召回了数字,却不知道这些数字属于哪一列,答案会对不上号。

2.2 情况二:合并单元格塌陷

合并单元格在财务报表与合同条款里极为常见:一个跨三行的"保险责任"单元格,对应着下面三行不同的赔付比例。解析如果只按可见文本行输出,合并单元格的归属关系就会塌陷,三行数据全部丢失共同的行头。

这类错误的隐蔽之处在于,文本本身是完整的、字一个没错,但语义结构是错的。人工抽查不容易发现,只有用户问到具体条款时才会暴露。

2.3 情况三:无线表被读成散乱文本

没有边框线的表格靠对齐和留白表达结构。解析若不还原表格,只会输出一串用空格隔开的文字,列与列之间的边界全靠下游猜。这类内容进知识库后很难被准确召回,因为向量化时列名与数值的关联已经被稀释。

三种情况里,只有第一种与跨页直接相关,后两种在单页表格上同样会发生。但在真实的长文档里,它们通常是叠加出现的:一张带合并单元格的跨页续表,既要跨页续接表头,又要保住行头归属,任何一处没还原,检索拿到的数值都对不上列。这也是为什么排查工作不应该从检索端开始——问题的源头在解析输出里。

三、先选对入口:整份解析与按页抽取,落点不同

很多团队用的是单页识别接口,逐页调用再在业务侧拼接。这条路在纯文本段落上问题不大,在跨页表格上却行不通——拼接动作发生在页面之间,而表格的连续性判断需要跨页的上下文。

腾讯云文档智能在这件事上提供了两条不同的入口,选哪条取决于要处理的是整份文档还是指定页范围。

对比项

多模态解析(文档版)

文档抽取(Agent 版)

输入形态

整份文件,支持 PDF、Word、PPT、Excel、Markdown、TXT、图片、WPS 八类

图片或 PDF 单页,异步接口可指定起止页

单次页数上限

单次调用最多 300 页

支持最高 50 页

分页控制

PageRange 指定页码范围,参数格式形如 1-10

FileStartPageNumber、FileEndPageNumber 指定起止页

输出形态

Markdown、JSON、XML 或三者合并,zip 内含 .md、.json 与 images

按字段维度抽取的归一化结果

判断标准很直接:目标是"把整份文档变成可检索的结构化内容",走整份解析入口,跨页表格由解析过程统一处理;目标是"从多页非结构化文档里按字段把信息抽出来",走支持起止页的抽取入口,让模型在指定页范围内做上下文关联的推理。两种入口的计量单位都是页,成本模型一致,但能力落点不同。

四、保住表格结构的两个动作

4.1 让表格结构进得了切块流程

判断表格有没有被保住,看的不是文字有没有识别出来,而是续表的表头与数据行有没有被还原成同一张表。多模态解析(文档版)提供表格还原能力,跨页续表在输出里是一张完整的表,而不是按页切开的两张。

对知识库而言,Markdown 形态的表格保留了行列关系,切块时可以把整张表作为一个完整单元处理;对业务系统而言,JSON 形态便于按字段取值与落库。一次调用同时产出两种形态,下游各取所需,不必为了不同链路重复解析。

4.2 用页码范围控制解析粒度

PageRange 参数用于指定需要识别的页码范围。对超长文档,建议按章节切分页码范围分批调用,而不是按固定页数机械分段——按章节切分能保证一张跨页表格整体落在同一次调用内,从源头避免续表被拆成两半。

这一条对成本也有影响:按页计费的模式下,重复解析同一批页面的代价是实打实的页数消耗,粒度规划得越合理,返工越少。

五、成本、调用节奏与结果落盘

建库阶段的成本主要由页数决定,调用节奏则由并发与接口频率决定,两者都需要在开工前算清楚。

项目

多模态解析(文档版)

文档抽取(Agent 版)

后付费单价

0.08 元/页

自适应短文本 0.34 元/页、长文本 0.68 元/页;固定价格 0.4 元/页

预付费资源包

70 元/1000 页

自适应价格 430 元/1000 页;固定价格 470 元/1000 页

免费额度

1000 页/用户,首次开通一次性发放,一年内有效

1000 次/用户,首次开通一次性发放,一年内有效

调用节奏

默认 5 并发;并发买断包 3000 元/并发/月,单次下单最低 5 并发

异步创建任务 1 次/秒,查询任务 20 次/秒

结果返回方式也值得提前设计:多模态解析的结果以 zip 压缩包返回,ResultUrl 是临时下载地址,有效期 30 分钟。批量建库应在解析完成后立即下载落盘,把后续切分、向量化都建立在本地文件上,而不是依赖半小时后失效的链接。

六、总结

表格碎掉的问题,解法不在检索端,而在入库端。把入口选对、让表格以结构而非文本进入切块流程、把页码粒度规划好,这三步做完,知识库才有"不胡说"的基础;反过来,指望靠 rerank 或者换 embedding 模型去弥补丢失的表头,投入产出比极低。

判断标准也很简单:拿一份你最熟悉的长文档跑一轮解析,直接比对输出里的跨页表格是否表头完整、合并单元格是否保留了归属关系。多模态解析(文档版)首次开通即发放 1000 页免费额度、一年内有效,用免费额度就能把这一轮跨页表格验证跑完,不必一上来就付费;确认解析效果后再按需放量,可关注 文档智能特惠活动 的低折扣档位。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 摘要:
  • 一、表格是文档里信息密度最高、也最容易碎的地方
  • 二、表格结构在解析环节碎掉的三种典型情况
    • 2.1 情况一:续表被当成两张独立的表
    • 2.2 情况二:合并单元格塌陷
    • 2.3 情况三:无线表被读成散乱文本
  • 三、先选对入口:整份解析与按页抽取,落点不同
  • 四、保住表格结构的两个动作
    • 4.1 让表格结构进得了切块流程
    • 4.2 用页码范围控制解析粒度
  • 五、成本、调用节奏与结果落盘
  • 六、总结
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档