标准回答
表格召回难，是因为 PDF 里的表格被纯文本抽取后，行列对齐关系丢失：单元格按坐标顺序被拉成一串，跨行跨列的语义被打散，向量化后既不像自然语言也对不上用户问句，召回基本失效。解决要从「结构化抽取 → 合适的可检索表示 → 按问题类型选检索方式」三步走。
1. 结构化抽取表格
先把表格当成结构而非文本来抽。用 Camelot、pdfplumber 这类基于线框/坐标的表格抽取器，或视觉/版面模型（表格结构识别 TSR）识别行列与合并单元格，还原成二维结构。扫描件需先 OCR 再识别表格。
2. 选择可检索表示
拿到结构化表后，转成更利于检索和 LLM 理解的形式：
- 转 Markdown / HTML 表：保留行列对齐，LLM 阅读友好，适合整表不大时整体入块。
- 每行一句自然语言：把每行展开成「列名是值，列名是值」的句子（如「2025 年 Q3 营收为 12 亿元，同比增长 18%」），让行级语义贴近用户自然语言问法，显著提升向量命中。
- 为表格生成摘要 / 标题：用 LLM 给整张表写一句摘要或标题（说明表讲什么、含哪些指标），作为检索锚点单独嵌入，先召回到「哪张表」，再定位行。
3. 保留表格元数据
给表格块带上：所属章节标题、表名/表号、来源页码、列名 schema。既能做上下文锚点，也支撑溯源和后续结构化查询。
4. 数值类问题走结构化查询
向量召回擅长语义匹配，但不擅长精确数值、聚合、比较（如「哪个季度营收最高」「同比增长多少」）。这类问题应把表落地成结构化数据（如 DataFrame/数据库表），走 Text2SQL 或工具调用做精确计算，而不是指望纯向量召回算数。
工程上常按「问题路由」组合：语义/查表类走向量召回 + 表格摘要锚点，数值聚合类路由到 Text2SQL，二者互补。
常见误区
⚠️ 常见踩坑
误以为把表格文本切进普通文本块、照常做向量召回就够了。展平后的表格行列错乱、数值散落，向量既难命中又会让 LLM 算错数。表格必须先结构化抽取、用行级自然语言/摘要做检索表示，数值聚合类还要交给 Text2SQL。
追问
追问 1：把每行表格转成一句自然语言，相比直接存 Markdown 表有什么优势？
行级自然语言把「列名 + 值」组合成完整语义句，和用户的自然语言问法分布一致，向量更容易命中具体某行；粒度也更细，召回时只取相关行而非整张大表，节省上下文。Markdown 表保结构、LLM 读着方便，但整表作为一个块时语义被稀释、对单行精确召回不利。实践中常两者结合：行级句子做检索、命中后回带整表或表头供 LLM 阅读。
追问 2：什么时候该用 Text2SQL 而不是向量召回来回答表格问题？
当问题涉及精确数值、聚合（求和/平均/最大）、跨行比较、按条件过滤或排序时，应走 Text2SQL/结构化查询。向量召回只能找「语义相近的片段」，无法保证算数正确，也容易漏行。把表落成数据库表后用 SQL 查，结果精确可验证。判断信号是问句里出现「最高/总计/同比/筛选出…」这类需要计算的意图。
追问 3：跨页表格或含合并单元格的复杂表格怎么处理？
跨页表要在版面分析阶段识别续表并把多页拼回一张逻辑表，避免被页边界切断；合并单元格要在表格结构识别（TSR）时还原其跨行/跨列的归属，把合并值正确填充到每个受影响的行列，否则展开成自然语言时会缺值或错位。复杂表建议用带表格结构识别的视觉模型，并保留原始 HTML 结构作为兜底。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习