开始前先说明一个背景判断Agent 方向的面试题很少只考记忆型知识点更多是拿真实项目细节来验证候选人的工程判断。表格解析就是典型题目。RAG 项目里PDF、Word 转出来的表格如果不做专门处理直接按文本切片存入向量库问答阶段大概率出现“答非所问”或“数据串行”。这篇文章把三种表格处理解析方案拆开讲清楚适用场景、代码思路、技术选型、常见坑和面试回答路径。面试时可以按这套逻辑回答实际搭 RAG 项目时也可以直接参考。1. 表格为什么是 RAG 项目的分水岭1.1 表格不是“几行文本”而是二维结构普通文本是线性结构切分之后语义仍然基本完整。表格不一样。表格通过行、列、表头、单元格之间的相对位置来表达关系。例如一张订单表单独取出“10086”“华东区”“已发货”这三个单元格谁都无法判断它们之间的关系只有保留“订单号”“区域”“状态”这些列名同时保持同一行的对应关系才是一条可理解的记录。在 RAG 项目里文档解析的目标不是“把内容变成字符串”而是“把内容变成可用于检索和回答的信息单元”。表格处理之所以让很多人头疼就是因为表格天然是二维的而向量检索和文本切分普遍面向一维文本。两种结构之间存在转换损耗。1.2 直接切分文本会丢哪些信息很多初版 RAG 项目会把 PDF 或 Word 转成纯文本然后用固定字符数切分再交给 embedding 模型。遇到表格时这种做法的典型结果是表格中列与列的横向关系被打乱嵌入向量无法表达“某行某列”的语义。表头信息可能被切到上一个 chunk 或下一个 chunk导致该 chunk 内的内容无法被理解。单元格里的数字或短文本本身语义太弱向量检索时和问题相关性不明显。回答阶段LLM 看到的是散落文本无法还原“哪一列对应哪个字段”。从面试角度看这个现象是整道题目的起点。面试官想知道候选人是否清楚“表格 ≠ 纯文本”这个前提。如果候选人一上来就说“用 pandoc 转成 Markdown 表格就行”说明没有深入考虑过结构化与检索之间的关系。1.3 面试官真正想考察的三层能力围绕这道题面试官通常是在验证三层能力第一层是否理解 RAG 的完整链路解析、清洗、结构化、切分、向量化、检索、重排、生成。第二层是否知道表格在链路中的特殊性能提出至少一种可落地方案而不只是说“用 OCR”。第三层是否有工程取舍能力知道哪种方案成本高、哪种方案适合小规模、哪种方案需要评估和回退。所以这篇文章给出的不是“标准答案”而是三条可执行路线。实际项目中可以按表格类型、数据量、准确率要求做组合。2. 方案一表格转 Markdown 文本后按行切分2.1 方案思路与适用场景第一种方案最简单也最容易理解把表格转换成 Markdown 格式得到带管道符分隔的文本然后再做切分。适用场景表格结构相对规范列数在 10 列以内。表格行数较多每行内容不复杂。问答主要用于查询“某一行的完整信息”或“某个字段的取值”。对实现成本要求不高希望先跑通流程。这种方案的本质是“把二维结构压缩成一维文本”尽量保住行关系但列关系只能依靠 Markdown 语法维持。后续向量化时embedding 模型到底能从 Markdown 管道符中捕获多少结构语义取决于模型能力所以效果有一定上限。2.2 核心代码pandas 读取并转 Markdown以 Excel 表格为例。使用 pandas 读取再通过to_markdown输出 Markdown。注意to_markdown依赖tabulate如果没有安装需要先安装。pip install pandas openpyxl tabulate读取并转换import pandas as pd def excel_to_markdown(file_path: str, sheet_name: str Sheet1) - str: df pd.read_excel(file_path, sheet_namesheet_name, dtypestr) # 去除完全为空的列 df df.dropna(axis1, howall) # 去除完全为空的行 df df.dropna(axis0, howall) md df.to_markdown(indexFalse, tablefmtgithub) return md if __name__ __main__: result excel_to_markdown(orders.xlsx) print(result[:2000])输出示例| 订单号 | 区域 | 客户名称 | 状态 | 金额 | |--------|--------|----------|--------|------| | 10086 | 华东区 | 某公司 | 已发货 | 1200 | | 10087 | 华南区 | 某工厂 | 已签收 | 980 |关键点用dtypestr转成字符串避免手机号、订单号被当作数值丢失精度。dropna是为了去掉全空行和全空列否则后续切分会混入大量换行符。tablefmtgithub生成的表格更简洁管道符较少token 消耗相对低。2.3 切分策略按行分组而不是按字符硬切把整张表转成 Markdown 后如果直接按字符长度切分一个 chunk 可能落在表格中间把表头切掉。推荐策略是“先转 Markdown再按行分组”。def split_markdown_table(md_text: str, group_size: int 10) - list[str]: lines md_text.strip().split(\n) if not lines: return [] # 前两行是表头和分隔行 header lines[:2] body_lines lines[2:] chunks [] for i in range(0, len(body_lines), group_size): group body_lines[i:i group_size] chunk \n.join(header group) chunks.append(chunk) return chunks chunks split_markdown_table(result, group_size15) for idx, chunk in enumerate(chunks[:3], start1): print(f chunk {idx} ) print(chunk)这个做法的核心是每个 chunk 都保留表头。表头回答了“这一行每个值代表什么”没有表头的行切分片段基本没有检索价值。2.4 这个方案的主要缺点和踩坑点虽然简单但坑不少。第一个坑是宽表。如果表格有 30 列每行转成 Markdown 后就会变成很长的单行文本embedding 模型对长文本的语义捕捉能力会下降。列数越多管道符越多真正有语义的内容占比越小检索效果越差。所以列数很多的宽表不适合方案一。第二个坑是单元格内部换行。Excel 单元格里可能包含换行符转成 Markdown 后会把表格结构破坏行数变多甚至让后续按行切分失效。处理时要先把单元格内换行替换成空格或中文逗号。df df.applymap(lambda x: str(x).replace(\n, ) if pd.notna(x) else x)第三个坑是to_markdown依赖 tabulate 版本。某些环境缺少这个包运行时直接报错ModuleNotFoundError: No module named tabulate排查方式很简单先确认依赖是否安装。如果项目使用锁文件管理依赖要在 requirements.txt 或 pyproject.toml 中显式声明。3. 方案二表格转键值对描述文本3.1 方案思路与适用场景第二种方案是把表格的每一行转成“字段名值”的键值对描述文本。例如订单号10086区域华东区客户名称某公司状态已发货金额1200这种文本比 Markdown 表格更接近自然语言embedding 模型更容易理解。因为“字段名值”本质上把列名和单元格内容绑定在一起避免模型去理解管道符。适用场景字段型表格例如人员花名册、配置表、参数表、订单表。列名本身有明确业务含义能够直接表达语义。问答场景偏“按条件查字段”例如“华东区已发货的订单有哪些”。行数不多列数较多的宽表也可以处理因为每行是独立描述文本。3.2 核心代码按行构造描述文本import pandas as pd def excel_to_key_value_description(file_path: str, sheet_name: str Sheet1) - list[str]: df pd.read_excel(file_path, sheet_namesheet_name, dtypestr) df df.dropna(axis0, howall) rows_desc [] for _, row in df.iterrows(): pairs [] for col in df.columns: value row[col] if pd.isna(value) or str(value).strip() : continue pairs.append(f{col}{value}) if pairs: rows_desc.append(.join(pairs)) return rows_desc descs excel_to_key_value_description(employees.xlsx) for desc in descs[:5]: print(desc)输出示例姓名张三部门技术部职级P6城市上海 姓名李四部门产品部职级P7城市北京这里把col和value拼接成一个自然语言片段。“字段名值”的形式比 Markdown 管道符更有语义关联性因为字段名紧挨着值向量距离更近。3.3 如何结合切分与检索每一行描述可以作为一个向量化单元也可以按 10 到 20 行合并成一个 chunk 后向量化。建议分成两级行级描述写入独立列表用于精确查找。多个行描述合并成 chunk用于语义召回。检索阶段可以先用问题向量召回相关 chunk再在 chunk 内做关键词精排或者直接返回 TopK 的行描述交给 LLM。这样既保留语义检索能力又避免把无关行混入 prompt。from typing import List def batch_merge(descs: List[str], batch_size: int 15) - List[str]: return [ \n.join(descs[i:i batch_size]) for i in range(0, len(descs), batch_size) ] chunks batch_merge(descs, 15)3.4 这个方案的缺点和踩坑点这个方案最怕两类问题。第一类是列名质量差。列名如果叫“A”“B”“C”或者“备注1”“备注2”构造出的文本就是“AxxxBxxx”语义很弱。这种情况需要先做列名清洗和映射。column_alias { A: 姓名, B: 手机号, C: 入职时间, } df df.rename(columnscolumn_alias)第二类是空值和缺失。如果某个字段为空不要输出“字段名nan”或“字段名None”这种脏文本会污染向量。处理方式是跳过空值或者用“字段未知”代替但尽量不引入无效值。第三类是描述文本长度不一致。一个只有两个字段的行和一个有 30 个字段的行混合在一个 chunk 里会让向量化质量不稳定。建议按长度做一次过滤异常长的行单独处理避免影响整个 chunk。MAX_DESC_LEN 500 descs [d for d in descs if len(d) MAX_DESC_LEN]4. 方案三结构化 JSON 摘要 混合检索4.1 方案思路与适用场景第三种方案更接近生产级做法也是面试中能体现工程深度的一种方案。思路是分四步第一步把表格解析成结构化 JSON。第二步为每一行或多行生成语义摘要。第三步把摘要向量化原 JSON 结构存库或存文件。第四步检索时先命中摘要再根据摘要中的定位信息读取原 JSON 对应内容交给 LLM 回答。适用场景表格复杂列数多存在合并单元格或嵌套表头。需要回答跨行、跨列的综合问题例如“哪个区域的逾期订单最多”。回答需要保留数据原始结构便于后续复核。对准确率和可追溯性要求较高的生产项目。4.2 完整处理链路处理链路可以拆成五段。第一段是解析。用 Python 的pandas、openpyxl或 PDF 解析库读取表格尽量还原行列坐标。第二段是清洗。处理空行、全空列、单元格合并、重复表头。第三段是结构化。把清洗后的 DataFrame 转成 JSONJSON 的 key 使用列名value 使用单元格内容。{ table_name: 订单明细, columns: [订单号, 区域, 客户名称, 状态, 金额], rows: [ [10086, 华东区, 某公司, 已发货, 1200], [10087, 华南区, 某工厂, 已签收, 980] ] }第四段是摘要。对整张表生成一个表级摘要并可选地对每个批次行生成行级摘要。def generate_row_summary(row: dict) - str: parts [] for key, value in row.items(): parts.append(f{key}为{value}) return .join(parts)第五段是索引与检索。表级摘要用于全局召回行级摘要用于定位具体记录。命中后从原 JSON 读取对应行。4.3 用 LLM 做结构化时要注意稳定性实际项目中表格来源不一定是 Excel可能是 PDF 里带复杂排版的表格。此时直接读取会失败需要引入 LLM 做信息抽取。示例提示词如下任务是解析表格内容输出 JSON。要求 1. 保留所有列名列名作为 JSON 的 key。 2. 表格每一行作为 JSON 数组中的一个元素。 3. 单元格内容为空的字段不要输出。 4. 不要输出 Markdown 代码块标记。 5. 如果表格包含合并单元格重复表头要补齐到每一行。然后调用 LLM 获取 JSONimport json from openai import OpenAI client OpenAI() def llm_extract_json(table_text: str) - dict: prompt f任务是解析表格内容输出 JSON。表格内容\n{table_text}\n请输出 JSON。 resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是表格解析引擎只输出 JSON。}, {role: user, content: prompt}, ], temperature0, ) content resp.choices[0].message.content.strip() # 去掉可能的代码块标记 if content.startswith(): content content.strip() if content.startswith(json): content content[4:].strip() return json.loads(content)这里要特别注意两点。第一必须要求模型只输出 JSON不要输出解释文字否则json.loads会失败。第二temperature设置为 0降低输出随机性但不能完全消除。LLM 抽取不是百分百稳定建议加上校验和重试逻辑。解析失败时回退到规则抽取或手动处理通道。4.4 混合检索摘要召回 原表复核这种方案不建议只对 JSON 文本做向量化原因是 JSON 本身包含大量符号语义密度低。更好的做法是表级摘要向量进入向量库。行级摘要向量进入向量库。原 JSON 存放在文档数据库或对象存储中。检索命中行级摘要后用摘要中携带的定位信息读取原表。示例数据模型{ id: table_001_row_005, table_id: table_001, row_index: 5, summary: 订单号10086区域华东区客户名称为某公司状态已发货金额1200, raw_json: { 订单号: 10086, 区域: 华东区, 客户名称: 某公司, 状态: 已发货, 金额: 1200 } }检索流程问题 - 向量检索 - 命中 row_index - 读取 raw_json - 拼入 prompt - 生成回答这样做的最大好处是“检索与回答分离”。检索阶段只依赖摘要摘要里信息密度高回答阶段使用原始 JSON避免摘要丢失细节。同时还能给 LLM 提供可靠引用来源。4.5 这个方案的代价和常见问题代价是成本更高、链路更长。第一个问题是 LLM 解析失败。尤其表格列数多或单元格内容长时模型容易截断输出。建议在代码中捕获json.JSONDecodeError失败后重试一次再失败就手动转规则解析。try: data llm_extract_json(table_text) except json.JSONDecodeError: data llm_extract_json(table_text, retryTrue)第二个问题是摘要生成可能丢失细节。如果问题问的是表中某个非常具体的数字摘要中可能没写全。解决方式是在摘要里保留所有关键字段不要进一步概括数据本身只概括表格主题。第三个问题是存储成本。每行都存摘要和原始 JSON数据量会明显大于直接存文本。适合中间表存储定期清理历史版本。5. 三种方案对比与选型决策5.1 从五个维度做横向对比面试时能给出清晰对比表比直接背诵方案更能加分。对比维度方案一Markdown 文本方案二键值对描述方案三JSON 摘要实现复杂度低中高表格结构保留程度中中高对 embed模型 的语义友好度低到中中到高高Token 消耗低中高含摘要和 JSON定位与复核能力弱中强宽表适应性差较好好复杂问题回答质量取决于切分中等高适合表格类型简单规整表字段型表复杂表、重准确率场景生产维护成本低中高表里的评分不是绝对结论。实际选型时还要结合 embedding 模型能力、表格数据量、问题形态和回答质量要求来判断。5.2 选型判断路径建议按下面顺序判断先看表格结构。规整且列少选方案一或方案二列多但有明确列名选方案二列多且存在合并单元格、跨行列选方案三。再看问题形态。如果是“某订单发了没有”这类单行查询方案二性价比最高。如果是“统计各区域发货情况”这类需要跨行计算的问题必须保留结构化数据方案三更稳妥。再看数据量。数据量大时方案三的摘要生成成本很高需要抽帧或分批处理方案一和方案二可以直接批量跑。最后看可追溯性。如果回答结果需要证据链方案三最合适因为它能定位到原始行和字段。5.3 实际项目很少单用一个方案生产项目中的做法通常是路由。先用文档类型识别判断文件是什么再决定走哪种处理管道。文件进入 - 类型识别 - PDF/Word 简单表格 - 方案一 - Excel 字段表 - 方案二 - 复杂嵌套宽表 - 方案三 - 图片型表格 - OCR 方案三这样可以兼顾成本、速度和准确率。面试时主动提出“按表格类型路由到不同解析管道”比只说一个方案更能体现工程化思路。6. 面试回答组织与落地前检查清单6.1 面试时按这个顺序回答当被问到“RAG 项目中表格怎么处理”推荐按四步回答。第一步表明问题背景。先说明表格是二维结构直接文本切分会丢失行列关系。第二步给出简单方案兜底。说明接触的表格如果规整可以转 Markdown 或键值对描述成本低、好维护。第三步引出生产级方案。说明真正要解决复杂表格和准确率问题时可以走“结构化 JSON 摘要 混合检索”把检索和回答分离。第四步给出评估思路。说明不能只看“能跑通”要评估表格还原度、检索命中率、问答正确率和端到端效果并解释为什么需要这些指标。6.2 落地前检查清单表格解析方案在落地前最好按下面的清单过一遍避免上线后反复返工。检查项检查要点表格来源是 PDF、Word、Excel 还是图片解析库是否支持表头结构是否有两行表头、嵌套表头、重复表头合并单元格是否需要在还原时补齐内容单元格换行是否已替换成空格或中文标点编码问题中文、英文、特殊符号是否乱码空值和缺失是否统一处理是否允许略过字段列名质量列名是否可读是否需要清洗映射向量化粒度按行、按 chunk 还是按表格整体检索定位命中后能否回原表找到对应行LLM 解析重试是否处理 JSON 解析失败和模型截断存储成本JSON 和摘要的存储周期是否需要限制回答引用回答时是否展示引用来源6.3 常见问题排查路径实际运行中如果检索结果变差按下面的链路排查。问题现象可能原因检查方式处理建议回答答非所问表格内容没有进向量库检查是否走了解析管道确认文件进入后是否落到正确处理分支检索到大段无用文本切分时表头丢失查看向量库原始文本按行分组并重复表头数字和日期对不上读取时被转成数值打印读取后的 DataFrame使用 dtypestr 或设置 dtype 映射JSON 解析失败LLM 输出格式不稳定打印原始 LLM 输出加重试回退到规则抽取宽表检索效果差单行文本过长检查每个 chunk 的长度改用方案二或方案三新表格文档接入后质量下降没有做表格类型路由查看日志中文档类型识别结果增加类型识别与分类管道6.4 扩展方向如果这道题继续深挖面试官可能还会问三个延伸点。第一多模态表格识别。图片型表格需要 OCR 或直接使用多模态模型识别识别后再进入结构化管道。第二GraphRAG 与关系型表格。表格天然包含实体和关系订单表、人员表可以转成图结构用图检索处理跨表关系问题。第三表格问答专用评估集。只测“能回答问题”不够还要准备一组包含精确取数、条件筛选、统计汇总、跨行比对的多类型问题集才能客观评价方案效果。把这三个方向回答出来说明对表格解析已经不是“会转文本”的水平而是在思考数据结构和检索效率之间的关系。这才是在 RAG 项目里处理表格的正确深度。
RAG项目表格解析：三种高效处理方案与选型指南
开始前先说明一个背景判断Agent 方向的面试题很少只考记忆型知识点更多是拿真实项目细节来验证候选人的工程判断。表格解析就是典型题目。RAG 项目里PDF、Word 转出来的表格如果不做专门处理直接按文本切片存入向量库问答阶段大概率出现“答非所问”或“数据串行”。这篇文章把三种表格处理解析方案拆开讲清楚适用场景、代码思路、技术选型、常见坑和面试回答路径。面试时可以按这套逻辑回答实际搭 RAG 项目时也可以直接参考。1. 表格为什么是 RAG 项目的分水岭1.1 表格不是“几行文本”而是二维结构普通文本是线性结构切分之后语义仍然基本完整。表格不一样。表格通过行、列、表头、单元格之间的相对位置来表达关系。例如一张订单表单独取出“10086”“华东区”“已发货”这三个单元格谁都无法判断它们之间的关系只有保留“订单号”“区域”“状态”这些列名同时保持同一行的对应关系才是一条可理解的记录。在 RAG 项目里文档解析的目标不是“把内容变成字符串”而是“把内容变成可用于检索和回答的信息单元”。表格处理之所以让很多人头疼就是因为表格天然是二维的而向量检索和文本切分普遍面向一维文本。两种结构之间存在转换损耗。1.2 直接切分文本会丢哪些信息很多初版 RAG 项目会把 PDF 或 Word 转成纯文本然后用固定字符数切分再交给 embedding 模型。遇到表格时这种做法的典型结果是表格中列与列的横向关系被打乱嵌入向量无法表达“某行某列”的语义。表头信息可能被切到上一个 chunk 或下一个 chunk导致该 chunk 内的内容无法被理解。单元格里的数字或短文本本身语义太弱向量检索时和问题相关性不明显。回答阶段LLM 看到的是散落文本无法还原“哪一列对应哪个字段”。从面试角度看这个现象是整道题目的起点。面试官想知道候选人是否清楚“表格 ≠ 纯文本”这个前提。如果候选人一上来就说“用 pandoc 转成 Markdown 表格就行”说明没有深入考虑过结构化与检索之间的关系。1.3 面试官真正想考察的三层能力围绕这道题面试官通常是在验证三层能力第一层是否理解 RAG 的完整链路解析、清洗、结构化、切分、向量化、检索、重排、生成。第二层是否知道表格在链路中的特殊性能提出至少一种可落地方案而不只是说“用 OCR”。第三层是否有工程取舍能力知道哪种方案成本高、哪种方案适合小规模、哪种方案需要评估和回退。所以这篇文章给出的不是“标准答案”而是三条可执行路线。实际项目中可以按表格类型、数据量、准确率要求做组合。2. 方案一表格转 Markdown 文本后按行切分2.1 方案思路与适用场景第一种方案最简单也最容易理解把表格转换成 Markdown 格式得到带管道符分隔的文本然后再做切分。适用场景表格结构相对规范列数在 10 列以内。表格行数较多每行内容不复杂。问答主要用于查询“某一行的完整信息”或“某个字段的取值”。对实现成本要求不高希望先跑通流程。这种方案的本质是“把二维结构压缩成一维文本”尽量保住行关系但列关系只能依靠 Markdown 语法维持。后续向量化时embedding 模型到底能从 Markdown 管道符中捕获多少结构语义取决于模型能力所以效果有一定上限。2.2 核心代码pandas 读取并转 Markdown以 Excel 表格为例。使用 pandas 读取再通过to_markdown输出 Markdown。注意to_markdown依赖tabulate如果没有安装需要先安装。pip install pandas openpyxl tabulate读取并转换import pandas as pd def excel_to_markdown(file_path: str, sheet_name: str Sheet1) - str: df pd.read_excel(file_path, sheet_namesheet_name, dtypestr) # 去除完全为空的列 df df.dropna(axis1, howall) # 去除完全为空的行 df df.dropna(axis0, howall) md df.to_markdown(indexFalse, tablefmtgithub) return md if __name__ __main__: result excel_to_markdown(orders.xlsx) print(result[:2000])输出示例| 订单号 | 区域 | 客户名称 | 状态 | 金额 | |--------|--------|----------|--------|------| | 10086 | 华东区 | 某公司 | 已发货 | 1200 | | 10087 | 华南区 | 某工厂 | 已签收 | 980 |关键点用dtypestr转成字符串避免手机号、订单号被当作数值丢失精度。dropna是为了去掉全空行和全空列否则后续切分会混入大量换行符。tablefmtgithub生成的表格更简洁管道符较少token 消耗相对低。2.3 切分策略按行分组而不是按字符硬切把整张表转成 Markdown 后如果直接按字符长度切分一个 chunk 可能落在表格中间把表头切掉。推荐策略是“先转 Markdown再按行分组”。def split_markdown_table(md_text: str, group_size: int 10) - list[str]: lines md_text.strip().split(\n) if not lines: return [] # 前两行是表头和分隔行 header lines[:2] body_lines lines[2:] chunks [] for i in range(0, len(body_lines), group_size): group body_lines[i:i group_size] chunk \n.join(header group) chunks.append(chunk) return chunks chunks split_markdown_table(result, group_size15) for idx, chunk in enumerate(chunks[:3], start1): print(f chunk {idx} ) print(chunk)这个做法的核心是每个 chunk 都保留表头。表头回答了“这一行每个值代表什么”没有表头的行切分片段基本没有检索价值。2.4 这个方案的主要缺点和踩坑点虽然简单但坑不少。第一个坑是宽表。如果表格有 30 列每行转成 Markdown 后就会变成很长的单行文本embedding 模型对长文本的语义捕捉能力会下降。列数越多管道符越多真正有语义的内容占比越小检索效果越差。所以列数很多的宽表不适合方案一。第二个坑是单元格内部换行。Excel 单元格里可能包含换行符转成 Markdown 后会把表格结构破坏行数变多甚至让后续按行切分失效。处理时要先把单元格内换行替换成空格或中文逗号。df df.applymap(lambda x: str(x).replace(\n, ) if pd.notna(x) else x)第三个坑是to_markdown依赖 tabulate 版本。某些环境缺少这个包运行时直接报错ModuleNotFoundError: No module named tabulate排查方式很简单先确认依赖是否安装。如果项目使用锁文件管理依赖要在 requirements.txt 或 pyproject.toml 中显式声明。3. 方案二表格转键值对描述文本3.1 方案思路与适用场景第二种方案是把表格的每一行转成“字段名值”的键值对描述文本。例如订单号10086区域华东区客户名称某公司状态已发货金额1200这种文本比 Markdown 表格更接近自然语言embedding 模型更容易理解。因为“字段名值”本质上把列名和单元格内容绑定在一起避免模型去理解管道符。适用场景字段型表格例如人员花名册、配置表、参数表、订单表。列名本身有明确业务含义能够直接表达语义。问答场景偏“按条件查字段”例如“华东区已发货的订单有哪些”。行数不多列数较多的宽表也可以处理因为每行是独立描述文本。3.2 核心代码按行构造描述文本import pandas as pd def excel_to_key_value_description(file_path: str, sheet_name: str Sheet1) - list[str]: df pd.read_excel(file_path, sheet_namesheet_name, dtypestr) df df.dropna(axis0, howall) rows_desc [] for _, row in df.iterrows(): pairs [] for col in df.columns: value row[col] if pd.isna(value) or str(value).strip() : continue pairs.append(f{col}{value}) if pairs: rows_desc.append(.join(pairs)) return rows_desc descs excel_to_key_value_description(employees.xlsx) for desc in descs[:5]: print(desc)输出示例姓名张三部门技术部职级P6城市上海 姓名李四部门产品部职级P7城市北京这里把col和value拼接成一个自然语言片段。“字段名值”的形式比 Markdown 管道符更有语义关联性因为字段名紧挨着值向量距离更近。3.3 如何结合切分与检索每一行描述可以作为一个向量化单元也可以按 10 到 20 行合并成一个 chunk 后向量化。建议分成两级行级描述写入独立列表用于精确查找。多个行描述合并成 chunk用于语义召回。检索阶段可以先用问题向量召回相关 chunk再在 chunk 内做关键词精排或者直接返回 TopK 的行描述交给 LLM。这样既保留语义检索能力又避免把无关行混入 prompt。from typing import List def batch_merge(descs: List[str], batch_size: int 15) - List[str]: return [ \n.join(descs[i:i batch_size]) for i in range(0, len(descs), batch_size) ] chunks batch_merge(descs, 15)3.4 这个方案的缺点和踩坑点这个方案最怕两类问题。第一类是列名质量差。列名如果叫“A”“B”“C”或者“备注1”“备注2”构造出的文本就是“AxxxBxxx”语义很弱。这种情况需要先做列名清洗和映射。column_alias { A: 姓名, B: 手机号, C: 入职时间, } df df.rename(columnscolumn_alias)第二类是空值和缺失。如果某个字段为空不要输出“字段名nan”或“字段名None”这种脏文本会污染向量。处理方式是跳过空值或者用“字段未知”代替但尽量不引入无效值。第三类是描述文本长度不一致。一个只有两个字段的行和一个有 30 个字段的行混合在一个 chunk 里会让向量化质量不稳定。建议按长度做一次过滤异常长的行单独处理避免影响整个 chunk。MAX_DESC_LEN 500 descs [d for d in descs if len(d) MAX_DESC_LEN]4. 方案三结构化 JSON 摘要 混合检索4.1 方案思路与适用场景第三种方案更接近生产级做法也是面试中能体现工程深度的一种方案。思路是分四步第一步把表格解析成结构化 JSON。第二步为每一行或多行生成语义摘要。第三步把摘要向量化原 JSON 结构存库或存文件。第四步检索时先命中摘要再根据摘要中的定位信息读取原 JSON 对应内容交给 LLM 回答。适用场景表格复杂列数多存在合并单元格或嵌套表头。需要回答跨行、跨列的综合问题例如“哪个区域的逾期订单最多”。回答需要保留数据原始结构便于后续复核。对准确率和可追溯性要求较高的生产项目。4.2 完整处理链路处理链路可以拆成五段。第一段是解析。用 Python 的pandas、openpyxl或 PDF 解析库读取表格尽量还原行列坐标。第二段是清洗。处理空行、全空列、单元格合并、重复表头。第三段是结构化。把清洗后的 DataFrame 转成 JSONJSON 的 key 使用列名value 使用单元格内容。{ table_name: 订单明细, columns: [订单号, 区域, 客户名称, 状态, 金额], rows: [ [10086, 华东区, 某公司, 已发货, 1200], [10087, 华南区, 某工厂, 已签收, 980] ] }第四段是摘要。对整张表生成一个表级摘要并可选地对每个批次行生成行级摘要。def generate_row_summary(row: dict) - str: parts [] for key, value in row.items(): parts.append(f{key}为{value}) return .join(parts)第五段是索引与检索。表级摘要用于全局召回行级摘要用于定位具体记录。命中后从原 JSON 读取对应行。4.3 用 LLM 做结构化时要注意稳定性实际项目中表格来源不一定是 Excel可能是 PDF 里带复杂排版的表格。此时直接读取会失败需要引入 LLM 做信息抽取。示例提示词如下任务是解析表格内容输出 JSON。要求 1. 保留所有列名列名作为 JSON 的 key。 2. 表格每一行作为 JSON 数组中的一个元素。 3. 单元格内容为空的字段不要输出。 4. 不要输出 Markdown 代码块标记。 5. 如果表格包含合并单元格重复表头要补齐到每一行。然后调用 LLM 获取 JSONimport json from openai import OpenAI client OpenAI() def llm_extract_json(table_text: str) - dict: prompt f任务是解析表格内容输出 JSON。表格内容\n{table_text}\n请输出 JSON。 resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是表格解析引擎只输出 JSON。}, {role: user, content: prompt}, ], temperature0, ) content resp.choices[0].message.content.strip() # 去掉可能的代码块标记 if content.startswith(): content content.strip() if content.startswith(json): content content[4:].strip() return json.loads(content)这里要特别注意两点。第一必须要求模型只输出 JSON不要输出解释文字否则json.loads会失败。第二temperature设置为 0降低输出随机性但不能完全消除。LLM 抽取不是百分百稳定建议加上校验和重试逻辑。解析失败时回退到规则抽取或手动处理通道。4.4 混合检索摘要召回 原表复核这种方案不建议只对 JSON 文本做向量化原因是 JSON 本身包含大量符号语义密度低。更好的做法是表级摘要向量进入向量库。行级摘要向量进入向量库。原 JSON 存放在文档数据库或对象存储中。检索命中行级摘要后用摘要中携带的定位信息读取原表。示例数据模型{ id: table_001_row_005, table_id: table_001, row_index: 5, summary: 订单号10086区域华东区客户名称为某公司状态已发货金额1200, raw_json: { 订单号: 10086, 区域: 华东区, 客户名称: 某公司, 状态: 已发货, 金额: 1200 } }检索流程问题 - 向量检索 - 命中 row_index - 读取 raw_json - 拼入 prompt - 生成回答这样做的最大好处是“检索与回答分离”。检索阶段只依赖摘要摘要里信息密度高回答阶段使用原始 JSON避免摘要丢失细节。同时还能给 LLM 提供可靠引用来源。4.5 这个方案的代价和常见问题代价是成本更高、链路更长。第一个问题是 LLM 解析失败。尤其表格列数多或单元格内容长时模型容易截断输出。建议在代码中捕获json.JSONDecodeError失败后重试一次再失败就手动转规则解析。try: data llm_extract_json(table_text) except json.JSONDecodeError: data llm_extract_json(table_text, retryTrue)第二个问题是摘要生成可能丢失细节。如果问题问的是表中某个非常具体的数字摘要中可能没写全。解决方式是在摘要里保留所有关键字段不要进一步概括数据本身只概括表格主题。第三个问题是存储成本。每行都存摘要和原始 JSON数据量会明显大于直接存文本。适合中间表存储定期清理历史版本。5. 三种方案对比与选型决策5.1 从五个维度做横向对比面试时能给出清晰对比表比直接背诵方案更能加分。对比维度方案一Markdown 文本方案二键值对描述方案三JSON 摘要实现复杂度低中高表格结构保留程度中中高对 embed模型 的语义友好度低到中中到高高Token 消耗低中高含摘要和 JSON定位与复核能力弱中强宽表适应性差较好好复杂问题回答质量取决于切分中等高适合表格类型简单规整表字段型表复杂表、重准确率场景生产维护成本低中高表里的评分不是绝对结论。实际选型时还要结合 embedding 模型能力、表格数据量、问题形态和回答质量要求来判断。5.2 选型判断路径建议按下面顺序判断先看表格结构。规整且列少选方案一或方案二列多但有明确列名选方案二列多且存在合并单元格、跨行列选方案三。再看问题形态。如果是“某订单发了没有”这类单行查询方案二性价比最高。如果是“统计各区域发货情况”这类需要跨行计算的问题必须保留结构化数据方案三更稳妥。再看数据量。数据量大时方案三的摘要生成成本很高需要抽帧或分批处理方案一和方案二可以直接批量跑。最后看可追溯性。如果回答结果需要证据链方案三最合适因为它能定位到原始行和字段。5.3 实际项目很少单用一个方案生产项目中的做法通常是路由。先用文档类型识别判断文件是什么再决定走哪种处理管道。文件进入 - 类型识别 - PDF/Word 简单表格 - 方案一 - Excel 字段表 - 方案二 - 复杂嵌套宽表 - 方案三 - 图片型表格 - OCR 方案三这样可以兼顾成本、速度和准确率。面试时主动提出“按表格类型路由到不同解析管道”比只说一个方案更能体现工程化思路。6. 面试回答组织与落地前检查清单6.1 面试时按这个顺序回答当被问到“RAG 项目中表格怎么处理”推荐按四步回答。第一步表明问题背景。先说明表格是二维结构直接文本切分会丢失行列关系。第二步给出简单方案兜底。说明接触的表格如果规整可以转 Markdown 或键值对描述成本低、好维护。第三步引出生产级方案。说明真正要解决复杂表格和准确率问题时可以走“结构化 JSON 摘要 混合检索”把检索和回答分离。第四步给出评估思路。说明不能只看“能跑通”要评估表格还原度、检索命中率、问答正确率和端到端效果并解释为什么需要这些指标。6.2 落地前检查清单表格解析方案在落地前最好按下面的清单过一遍避免上线后反复返工。检查项检查要点表格来源是 PDF、Word、Excel 还是图片解析库是否支持表头结构是否有两行表头、嵌套表头、重复表头合并单元格是否需要在还原时补齐内容单元格换行是否已替换成空格或中文标点编码问题中文、英文、特殊符号是否乱码空值和缺失是否统一处理是否允许略过字段列名质量列名是否可读是否需要清洗映射向量化粒度按行、按 chunk 还是按表格整体检索定位命中后能否回原表找到对应行LLM 解析重试是否处理 JSON 解析失败和模型截断存储成本JSON 和摘要的存储周期是否需要限制回答引用回答时是否展示引用来源6.3 常见问题排查路径实际运行中如果检索结果变差按下面的链路排查。问题现象可能原因检查方式处理建议回答答非所问表格内容没有进向量库检查是否走了解析管道确认文件进入后是否落到正确处理分支检索到大段无用文本切分时表头丢失查看向量库原始文本按行分组并重复表头数字和日期对不上读取时被转成数值打印读取后的 DataFrame使用 dtypestr 或设置 dtype 映射JSON 解析失败LLM 输出格式不稳定打印原始 LLM 输出加重试回退到规则抽取宽表检索效果差单行文本过长检查每个 chunk 的长度改用方案二或方案三新表格文档接入后质量下降没有做表格类型路由查看日志中文档类型识别结果增加类型识别与分类管道6.4 扩展方向如果这道题继续深挖面试官可能还会问三个延伸点。第一多模态表格识别。图片型表格需要 OCR 或直接使用多模态模型识别识别后再进入结构化管道。第二GraphRAG 与关系型表格。表格天然包含实体和关系订单表、人员表可以转成图结构用图检索处理跨表关系问题。第三表格问答专用评估集。只测“能回答问题”不够还要准备一组包含精确取数、条件筛选、统计汇总、跨行比对的多类型问题集才能客观评价方案效果。把这三个方向回答出来说明对表格解析已经不是“会转文本”的水平而是在思考数据结构和检索效率之间的关系。这才是在 RAG 项目里处理表格的正确深度。
