Excel表格扔给ChatGPT直接问“算一下每个季度的总销售额”大概率的结局就是两个它一本正经地给你一个错误的数字或者干脆说自己处理不了。我这两年跟表格数据打交道的时间不少试过各种姿势之后得出了一个比较扎心的结论——在“算数”这件事上你不能把大模型当成计算器用而是要把RAG系统的架构彻底改造成适合表格数据的形态让模型去调度计算而不是去心算。这篇东西的定位不是科普是一份可以直接照做的实战记录。适合的人群很明确手里捏着大量Excel报表、每天做重复统计的数据分析、运营和项目经理以及想在企业内部搭一个“能对话的表格助手”的开发者。我会把整个系统的架构、为什么这么设计、关键代码逻辑、以及实际测试中的翻车记录都写清楚建议先收藏再慢慢看。1. 直接用ChatGPT处理Excel到底难在哪先泼一盆冷水。如果你只是偶尔拿一个几十行的Excel让ChatGPT看一眼它确实能应付因为那本质上不是“计算”是“复述”。一旦数据量上去、问题带条件、列名不统一问题就全都暴露了。拆开来看难点集中在三块。1.1 大模型的数字处理逻辑和你想的不一样大模型本质上是个基于概率的文本生成器它看到“12345 67890”的时候并不是在脑内运行加法电路而是在预测“这段文本后面最可能接什么样的token序列”。数字被分词器切碎之后它们之间的运算关系对模型来说只是一种语料中的统计规律。所以你会看到一种很诡异的现象问ChatGPT“250000乘以4”它可能算得对因为它见过太多类似算式但如果你的Excel里有几十个互相关联的字段要算“2023年华东区A类客户的平均账期天数”它就开始自由发挥了。这种“自由发挥”在报表场景里就是灾难因为财务数据不允许模糊。1.2 常规RAG在表格数据上会结构性地失效RAG的标准流程是把文档切块、向量化、存库、检索、拼上下文、让模型作答。这套流程处理PDF、Word、网页文本时表现不错但套到Excel上就会出大事。问题出在“切块”这一步。一个Excel表格切开之后切成的是各行碎片表头和列名跟数据行被拆散了。检索系统可能命中了第157行的数据但完全不知道这一行对应的是“哪个地区、哪个月的、什么指标”。换句话说常规RAG切碎的是一张有结构关系的表而不是一段连续的散文。你当然可以增加块的大小让每个块包含表头但这又带来第二个问题——Excel的宽度往往远大于长度。一个宽表有40列只保留表头加几行数据一个块就爆了向量化之后语义信息互相干扰检索出来的结果可能牛头不对马嘴。1.3 表格解析本身就是一道坎Excel的结构远比看起来复杂。一个sheet可能有合并单元格、多层表头、行列转置、公式单元格、宏表格甚至一个sheet里存了多张相互独立的报表。我见过最离谱的一个业务表同一个sheet里上面是“月度销售概览”下面隔两行又贴了一个“库存周转明细”共享同一列但语义完全无关。这种表解析出来以后要是不做区域识别后面的检索和计算全都会错。这也是为什么有些人试了市面上的通用RAG工具来处理Excel效果奇差无比——管线底层根本不理解表格。2. 给表格单独设计RAG架构四层分工别有玄机把问题拆清楚之后我开始动手改造系统。核心思路只有一句话让大模型干它擅长的事把计算任务甩给确定性的代码去执行。传统RAG把“理解-检索-计算-回答”全压在一个模型身上。表格场景不行。我最后落地的架构是四层各司其职结构解析层负责把Excel读成结构化对象识别sheet、列名、合并单元格、数据类型生成每个sheet的schema模式摘要。混合索引层对表格内容做“自包含切片”后同时建立向量索引和关键词索引。向量负责语义召回关键词负责精确命中列名和专有名词。计算引擎层内嵌一个Python代码解释器环境当用户问题涉及聚合、计算、筛选时由模型生成Pandas代码在受控环境里执行拿到精确结果。调度与生成层最后的Orchestrator编排器负责判断当前问题应该走检索还是走计算还是两者结合并组织最终的用户可读答案。这么设计的原因是吸取了我之前一个失败项目的教训。一开始我试图让大模型直接从检索出来的表格片段里“提炼”答案结果它把求和都能算错。后来我调整策略把它当成一个“会写代码的分析师”而不是“会算数的计算器”正确率一下就上去了。打个比方吧这就跟你让一个实习生去处理报表一样。你不该指望他心算能力过人而应该让他用Excel的SUM函数做汇总把公式和截图交给你核验。代码执行器就是这个“实习生手里的SUM函数”。3. “算数”的关键让模型写代码而不是给你答案很多教程讲表格RAG讲完检索就结束了对“算数”这个核心需求基本是一笔带过。但恰恰这才是实战里最花时间的部分。3.1 为什么代码执行方案比模型直接回答可靠确定性是第一位的。Pandas算出来的数字只要代码逻辑正确那结果就是数学上的精确值不存在“可能错了但表面看起来像是对的”。这一点在日常报表场景里是生死线。其次是可追溯性。代码是可以回看的每一步对数据做了什么处理有迹可循。前面提到的系统里每次调用计算引擎都会记录三样东西用户原始问题、模型生成的代码、执行后的返回结果。出现争议的时候直接把代码拿出来看是哪一步的问题而不是对着一个幻觉数字干瞪眼。第三它能处理超大表。Excel动辄几十万行你不可能把全表塞进大模型上下文。但代码执行器不一样它是直接加载原始文件做处理表多大都不影响。3.2 设计一个大模型能“读懂”的计算调度Prompt模型要正确生成代码前提是它得先知道表格里有什么。所以我会在调用计算引擎之前把结构化schema和检索到的数据样例喂给模型。Prompt的大致结构是任务说明你是数据分析师根据用户的自然语言问题生成Python代码。数据上下文列名、数据类型、每列的含义说明、分隔符。受限条件只能使用给定的数据文件路径和Pandas不能访问网络路径。输出格式只输出可执行的Python代码块。这里有个容易忽略的细节如果你把几十列全塞进Prompt模型生成代码时反而容易用错列名。所以我只注入经过检索筛选后相关的列信息无关列直接扔掉既省token又提高准确率。3.3 执行安全别在你的真实环境里跑模型生成的代码这一步必须慎重讲。模型生成的代码本质上是动态执行的安全性不可控。你总不能让业务人员拿着这个工具结果模型生成了删除文件的代码。我的做法是把它关进一个沙箱环境。常见实现方案有好几种轻重程度不同。个人开发者阶段可以用Docker容器限制文件系统和CPU内存把数据文件以只读方式挂载进去代码执行完只允许输出结果和日志文件不允许写回原始数据。也可以在进程级别用权限隔离。企业场景下可以上一个跨平台的函数计算平台跑隔离任务。环境准备阶段给你的代码执行器单独建一个基础镜像预装Pandas、NumPy等库然后用定时任务自动拉取需要分析的业务表跑完就丢这样最省心。4. 完整搭建路径从表格解析到检索再到计算验证理论讲完下面是可以直接照着搭的实操链路。我这里用Python生态做示范核心库是pandas、openpyxl、langchain、以及一个兼容OpenAI格式的embedding接口。4.1 第一步解析Excel并生成结构化schema这一步的目标不是把Excel全文切碎而是先把“骨架”提出来。包括文件里有哪些sheet每个sheet的列名、行数、列类型以及识别出合并单元格和多级表头。from openpyxl import load_workbook def parse_workbook_schema(file_path): wb load_workbook(file_path, data_onlyTrue, read_onlyTrue) result [] for sheet_name in wb.sheetnames: ws wb[sheet_name] headers [] for row in ws.iter_rows(min_row1, max_row2, values_onlyTrue): headers.append([str(c) if c is not None else for c in row]) merged_regions list(ws.merged_cells.ranges) result.append({ sheet_name: sheet_name, headers: headers, merged_cells: [str(r) for r in merged_regions], max_row: ws.max_row, max_column: ws.max_column }) return result注意data_onlyTrue这个参数很重要它拿的是公式计算后的缓存值否则你读出来的可能是公式字符串而不是数值。多级表头这里先保留前两行后面生成自包含切片时会用到。解析出来后的每个sheet我会额外用Pandas读一次全量数据生成每列的统计摘要非空值数量、唯一值前20个、数值列的最小最大值。这个摘要不是给用户看的是给后续检索和计算调度用的上下文。4.2 第二步设计“自包含切片”而不是“文本切片”表格切片的单位不能是一个500字的文本块而应该是一个“带上下文的记录单元”。我的做法是一个切片 该行的数据 该行的表头关联信息。最朴素的方式是把每行数据格式化成一段自然语言描述把表头读出来拼接进去。比如一行数据有两个字段“销量”和“月份”切片文本就是“销量12345月份2024年3月所属sheet月度销售表”。def make_row_chunk(df, sheet_name, headers, row): pair_parts [] for col, value in zip(headers, row): if value is not None: pair_parts.append(f{col}: {value}) text f[{sheet_name}] | .join(pair_parts) return {text: text, sheet: sheet_name, row_index: row_index}这么切的好处是检索系统命中任何一个切片都能拿到完整的“这一行是什么”的信息。缺点是每个切片的embedding会稍微大一些但数据量在几万行级别时完全可接受。4.3 第三步混合索引向量和关键词一个都不能少表格场景里用户的提问方式分成两类一类是语义模糊的比如“哪个区域卖得最差”一类指代精确的比如“华北区2024年1月”。前者要靠向量检索因为“卖得最差”和“销量、负增长、亏损”这些词在语义上是近邻。后者则靠关键词检索效果更好因为“华北区”和“2024年1月”这些字段值是精确字面匹配向量化反而会模糊掉边界。所以我在索引层同时挂了Embedding向量数据库和BM25关键词索引。检索时分两路进行再做一个简单的分数归一化融合def hybrid_search(query, top_k8): token_res bm25_index.search(query, ktop_k) vec_res vector_index.search(query, ktop_k) merged {} for item in token_res: merged[item[id]] merged.get(item[id], 0) item[score] * 0.6 for item in vec_res: merged[item[id]] merged.get(item[id], 0) item[score] * 0.4 ranked sorted(merged.items(), keylambda x: x[1], reverseTrue)[:top_k] return ranked权重的选择我这里给的是0.6/0.4的初始值。经过多轮实测关键词权重要稍微高一点因为表格里的列名和唯一标识符基本都是精确词汇向量召回容易跑偏。不过这个比例不是固定的如果你的数据表里语义模糊的描述字段占多数可以把它调成0.5/0.5再测。4.4 第四步计算执行器与结果回传当用户的问题包含“求和、平均、对比、占比、增长率”这类计算意图时检索本身解决不了问题必须走代码执行路径。流程是这样的用户的自然语言问题 前面生成的schema摘要 检索到的相关样例行一起发给大模型让它生成一段Pandas代码。代码放进沙箱执行返回结果再把结果连同计算过程短代码一起丢回给模型让它组织成一段自然的文字回答。一开始我把这一步简化成“模型直接返回代码执行结果”就是单纯把数字暴露给用户结果反馈很不好。后来改成“结论关键计算逻辑原始数据抽样”三段式输出用户才真正觉得工具可信。这个改法源于一个实际场景测算月度环比增长率时模型直接给了个百分比数值用户拿不准这是怎么算出来的审计的时候又过来问口径相当折腾。后来每输出一个问题都在后面加一行“计算逻辑说明”矛盾就消失了。4.5 第五步采样核对别让模型蒙混过关这是很多人忽略的一环。检索可能召回干扰数据模型也可能写错代码生成假结果。我的做法是在计算引擎执行完代码之后加一个自动核对步骤从计算涉及的数据源随机抽取5-10条原始记录人工或半自动地验证关键数值是否与原始表一致。你可能会觉得这一步多余但我负责任地说没有这个验证机制的表格RAG系统上线之后一定会被业务人员挑出毛病。他们随便翻开Excel看一眼就能发现你系统算的和表里的不一样这会极大消耗信任。抽样核对的具体实现可以很简单def verify_sample(df_sample_path, result_values, problem_columns): raw_df pd.read_excel(df_sample_path) mismatches {} for col, expected_value in problem_columns.items(): actual_value raw_df.loc[0, col] if abs(actual_value - expected_value) 1e-6: mismatches[col] {expected: expected_value, actual: actual_value} return mismatches当然全自动核对很难覆盖所有场景所以这个机制更多是兜底让你在早期调参和验证时能快速发现系统性问题而不是盲目相信端到端效果。5. 实测效果、翻车记录跟几个必须聊的取舍理论归理论这系统能不能用还得看实测数据。我用一份模拟某零售公司销售数据的Excel做了对比测试。表结构大概有近10万行、30列包含区域、城市、门店、商品类目、销售额、成本、日期等信息。5.1 不同方案的准确率对比我在同样一组问题上分别测了三种方案直接问大模型原始表格截断版常规文档型RAG管道本文的四层表格RAG系统方案数值精确率条件筛选正确率召回相关度可追溯性直接把数据塞给模型约2成很低中等无常规RAG约3成低低无四层表格RAG接近9成高高完整数值精确率这块主要体现在求和、均值、环比增长这类问题上。常规RAG的问题在于检索出来的片段经常带着表头噪声模型要么读了重复行要么漏读关键行而四层架构用代码执行器从根源上避免了这种“数错行”的问题。5.2 踩坑记录切片缺上下文和列名歧义第一坑切片缺少关联表头。早期我在做自包含切片时只保留了当前行数据拼的文本没带上层表头信息。结果检索“哪个门店毛利率最低”时按向量召回命中的几行里有的行没有毛利率字段模型只能瞎猜。后来在切片文本里强制加上了sheet名、一级表头、二级表头拼接出的“列全名”问题才改善。如果你也遇到检索到的片段看起来“还行”但模型就是答不准的情况优先检查是不是切片上下文不够完整。特别是多层表头场景光有列名还不够要有“列路径”。比如“销量”在表里其实是“2024年上半年销量”如果切片里只保留“销量”检索时信息损耗会很严重。第二坑列名歧义。同一列在原始Excel里叫“销售额”但在另一份关联表里叫“收入”。如果两章表被一起塞进索引模型生成的代码可能会搞混。我的解决方案是在schema摘要里设置同义词组让调度层在做计算前把用户问题里的词汇映射到正确的列名上。SYNONYM_MAP { 销售额: [收入, 销售额, total_sales], 成本: [成本金额, 成本价, cost], }这个映射表需要跟业务方一起维护成本不小但确实有效。5.3 关于本地小模型能不能干这活的思考有些团队因为数据敏感不能用云API一定要本地部署大模型。我也试过。结论是效果取决于模型写Pandas代码的能力而不是模型“聪明不聪明”。一个在代码推理测试上表现不错的本地模型配合结构清晰的schema和严格的代码沙箱在“生成计算代码”这个环节基本够用。但在“组织自然语言回答”和“复杂问题意图拆分”上跟云端大模型差距还是明显的。如果你的场景是内部报表问答本地小模型可以接受如果要面向不太懂数据的业务用户那就得在调度层多写一些规则兜底或者用云端模型做前期意图理解。还有一个折中方案把embedding和意图识别放云端但实际的数据文件始终留在本地代码执行也在本地完成。这样几乎没有数据外泄风险因为原始数据根本不会离开你的环境。具体能不能实现取决于你的合规要求但这个思路值得考虑。5.4 多sheet协同别让模型在迷宫里迷路一份Excel经常几十个sheet有些sheet之间还有联动关系。最典型的场景是“把销售汇总和库存明细关联起来算库存周转天数”。这时候你不能让模型自己大海捞针去找sheet名必须在调度层就给出一个明确的sheet索引地图。我的做法是每个sheet有一个带描述的角色标签比如“sheet_01: 销售明细_订单级数据_包含退换货标记”。调度模型在拿到问题后第一步先决定需要哪些sheet参与计算。如果这个问题涉及两张表计算引擎会先分别取出需要的数据再交给Pandas做连接。加了这个环节以后之前那些“它自己找错sheet导致数字完全对不上”的案子少了很多。本质上是因为大模型在没有导航的情况下处理多表关系时跟人类面对几十个标签不清的Excel文件一样容易懵。写在最后前阵子一个做数据运营的朋友跑来问我说他有个同事每次统计数据都要手动翻Excel能不能用AI自动替代。我说你直接给AI一张表让它干活它大概率给你提供情绪价值和一堆错误数字但如果你给它一套“会看表、会查数、会写代码验算”的管道它反而能顶一个初级的分析师。这话糙理不糙也是我做完这套表格RAG系统后最大的感触。最后再分享一个只有踩过坑才会懂的小技巧不要一上来就追求全自动化。哪怕你的检索和计算环节都已经稳定在上线初期也保留一个“人工复核”按钮把每个回答对应的计算代码和取数范围展示给用户。等信任建立起来以后再逐步放开自动化这样既不会让业务部门天天来投诉也能让你有充分时间调优底层参数。我就是这么一步步把准确率从“见不得人”磨到能交付的。
