前言

时至今日，很多传统公司的大部分的数据依然使用office文件去管理，，把excel和图片当做数据库去管控是一个很常见的现象。

Excel、CSV、PDF、Word、邮件正文、聊天记录、扫描件、截图、各种系统导出的半结构化表。它们每天在业务人员之间流转，被下载、转发、改名、复制，再上传到另一个系统。文件很多，数据以一种极低效率的方式在企业中运转。而且这些数据往往有时效性，所以自然会有“过期”无用的数据。

可以说文件只是信息的载体。它还不是数据。

文件只是信息的载体，还不是数据。真正的数据，至少要能被查询、关联、复用，也要能解释它从哪里来。否则它只是一个看起来很完整的 JSON，出了错却没人敢用。

我最开始做这类文件解析时，也很自然地想过：能不能直接把文件扔给大模型，让大模型直接输出业务需要的JSON？

后来发现这个想法太轻了。

难点不在于模型能不能识别几个字段。难点在于系统敢不敢相信这些字段。企业文件有一个很现实的特点：他们最初是给人看的，不是给机器看的。

人看得懂标题、备注、合并单元格、上下文、颜色、空行、缩写、附件说明。机器不懂。机器看到的是行、列、段落、文本块、坐标、页码，还有一堆不稳定的表格：

同一个字段，在不同文件里可能叫不同名字。

同一个表格，今天从第 3 行开始，明天从第 7 行开始。

同一个业务对象，可能被拆在多个 sheet、多个段落、多个附件里。

有些数字是金额，有些数字是数量，有些数字只是备注里的编号。

所以想要引入AI去解决文件导入的问题，一开始如果就想着怎么引入大模型，然后使用大模型去把数据“转成JSON”，那这个问题开始就已经偏了。

所以一上来就问“怎么让大模型把文件转成 JSON”，问题已经偏了。更应该先问的是：哪些内容可以稳定识别？哪些内容必须结合上下文？哪些字段即使识别出来，也不能直接入库？哪些地方必须保留来源，方便后面复查？

企业更想要的是一条能解释、能复查、能修正的数据生产线。

先看整体流程

这张图看着长，其实核心就几件事：先认识文件，再拆开处理，再保留来源，再检查有没有漏，最后再决定能不能入库。

Excel 文件解析技术分析

阶段一 试图使用大模型去解析Excel/CSV数据

我们最开始试过一条很直接的路：把 Excel / CSV 转成 Markdown，再交给大模型理解，让模型输出符合业务 schema 的结果。

这个方案上手很快，非标准文本也能覆盖一些。但大表一来，问题就很明显：等待时间长、输出太大、容易触发 context window 或 max tokens，金额事实也不可控。

更麻烦的是，一旦字段错位，很难追溯到底是哪个单元格导致的。

阶段二 使用大模型去做layout处理

我们尝试过让 LLM 做 Layout detector，也尝试过轻量 Layout hint。

这个方向比“LLM 直接输出金额”更安全，因为模型只判断结构，不给事实金额。并且在这个过程中也尝试过引入MarkItDown。MarkItDown 可以把 Excel 转成更容易阅读的 Markdown。它适合：人工快速理解文件内容，离线分析某些文件的文本表达，给模型提供较友好的文本上下文。

但是它不适合作为正式解析主链路的原因主要在于：

Markdown 可能丢失合并单元格语义。

横向块和空表头列的坐标语义会变弱。

模型读 Markdown 后仍可能生成事实。

解析结果不容易回到 workbook row/column。

所以这个阶段我们都是考虑如何处理数据才能让大模型得以解析，但是慢慢发现一个问题，那就是如果后端已经能稳定识别结构，调用 LLM 只会增加等待。并且如果 LLM 输出完整 LayoutPlan，仍然有 schema 重和超时问题。如果只输出 hint，后端还需要负责 section 展开、坐标校验和 executor。

方案结论：

1. LLM layout 能力可以作为低置信复杂结构的辅助。
2. 生产主链路仍应优先后端 resolver 和 executor。
3. 当前 Local Fee 主链路不依赖 Layout Detector，LLM 只保留为后端解析结果校验器。

阶段三 后端规则 + 通用布局层 + LLM 校验器(当前方案)

对于Excel文件而言，不同的企业里面有着截然不同的使用方式，Excel不再是纯数据文件，同时承载着数据、布局、视觉表达和人工填写习惯。在真实的业务文件里，关键信息不是常来自某个固定字段，它可能来自sheet名，可能来自文件名，或者它可能来自标题行、表头甚至子表头。并且出现很多场景会合并单元格，有的列有的行又可能是空。所以Excel解析的目标不是“把所有文本读出来”，而是：把带布局语义的表格,转成业务可消费/可追溯/可复核的结构化事实。

这句话里有三个关键要求：

可消费：输出必须符合业务schema

可追溯：重要字段最好能回到sheet、row、column或原文片段

可复核:不确定的地方要进入missing / warning / confidence，不能静默编造

实际业务结合

这是一个真实的需求，在海运报价的场景中，我们需要把报价文件的数据转变成运价的一个routes，关键的信息可能包含：船公司、币种，还要重要的数据比如起运港、目的港、中转港等，除此之外还要航线柜型对应的价格的信息，一条route对应包含有效期，除此之外还有其他数据就不在这里过多罗列。

而在另一个local费用的场景中，解析的目标不是routes，而是本地费用的模版，包含的信息则为船公司、起运港、费用项（各类的附加费和计费规则）、币种等。

消费方往往是上游查询的应用，解析结果最终会进入报价池，用于后续报价匹配。两个业务都在“解析excel”，但它们不是同一个解析任务，维度不同关注的数据也不一样。但是对于AI应用而言，数据又需要保持跟业务相关，且需要保证数据的准确性。

但是两者又有本质行为的相似之处，输入源都是Excel，底层文件读取模型调用或者是trace、token usage又可以复用。但是又需要将业务的schema、prompt、归一化、校验、失败策略拆开。

解决思路

做 Excel 解析时，我现在不会先问“用哪个 OCR / LLM / 库”。我会先问几个更业务的问题。

第一，先定义业务对象。

最重要的入库对象是什么？它的业务主键是什么？哪些字段必填？哪些字段可以后续补？哪些字段绝对不能推断？它会不会直接参与金额计算或业务决策？

报价解析里的港口和柜型金额不能乱猜。Local Fee 里的金额也不能被模型结合常识补齐。很多解析问题，都是因为一开始没有把这个边界说清楚，最后把“读到了文本”误认为“解析成功”。

第二，再定义消费方。

同一份解析结果，给后台入库、给业务人员预览、给上游报价匹配系统使用，设计都不一样。哪些字段入库，哪些字段展示，哪些字段只作为 trace 保留，需要提前想清楚。

第三，再判断 Excel 的结构类型。

不要按客户名或文件名堆判断。真实 Excel 更适合先归纳成结构原语：标准表、分段表、宽表、横向块、文本块、混合表。

这一步要回答：业务实体在行上还是列上？金额是单列还是拆列？信息来自显示列，还是来自标题、sheet 名、文件名？备注和条件是不是混在某个单元格里？

第四，区分结构判断和事实读取。

LayoutPlan 只告诉系统“去哪里读”，不能代替事实本身。关键金额、柜型、费用项，最终应该由 executor 回读 workbook 原始单元格。

第五，设计观测字段。

至少要有 parseTrace、timings、missing、warning、confidence、source。否则解析失败时，只能靠人肉看文件，很快就会变成玄学。

实现路径

我现在把链路拆成了几部分

1. 文件预处理只保留信息

文件预处理不应该过早去做业务解释，它更重要的职责在于：识别文件类型、读取workbook bytes、sheet文本和对Excel做必要内容的提取

可以说，它不应该决定哪个是业务模版，哪一列是金额，然后哪一行对应什么数据，模板是否覆盖这样的业务问题。

对于业务解释，应该交还给后面的parser、LayoutPlan、normalizer和人工确认

2. 高确定性规则先走规则parser

规则parser适合处理稳定、明确、可重复的格式，它不是大模型解析器，更多时候它是用工具进行解析的函数。这类规则特别适合处理：显示表头完整、列角色明确、section标题清晰、列表达固定等场景。

好处是，规则parser提供快路径：解析速度快、可测试、不消耗token、不依赖模型稳定性、出错时容易定位。但坏处是没法覆盖全部情况。

3. 复杂Excel引入布局中间层

真实的文件越来越以后，你会发现企业的数据是多样的，不可能每个文件都要写一个parser。企图处理所以场景，然后用枚举的方式去兼容是不现实的。更可维护的方式是引入布局中间层，我把这个层成为LayoutPlan。这个中间层主要描述sheet范围、行列范围、header行、数据起止行，还有meta数据的映射。

这样做的好处是新的Excel先归类为结构原语，不安客户名和文件名堆判断，并且executor 可以统一回读 workbook，validator 可以统一校验越界和缺轴。

4. Executor必须回读workbook

布局中间层只告诉后端“去哪里读”，但是不能代替后端读取事实，最终模版还是应该由executor从workbook原始单元格读取

这样做边界可以避免很多风险，比如模型看错数、模型补齐不存在的数据、markdown转换丢失坐标无法追溯。

5. LLM应该怎么用

大模型不是不能用，而是应该放在正确的位置：我更推荐使用LLM去做低置信解析结果的风险校验，或者去校验疑似错位字段，还有在 schema 很小的情况下输出 layout hint。最不推荐做的就是使用LLM 直接输出完整 workbook 解析结果并作为事实。

6. 输出必须经过schema和normalizer

无论结果来自规则还是 LLM，都应该经过统一输出层。输出层负责： 缺失字段进入missing。 不确定内容进入warnings。风险费用标记needsReview或displayOnly。这样可以避免每个 parser 都各自输出一套字段习惯。

最终我们的方案职责拆分如下：

这个组合的好处是：

标准文件快。

非标准文件可以扩展结构原语。

关键金额来自原始单元格。

LLM 有价值，但不控制事实。

trace 能解释每一步为什么这样解析。

工程化保障

schema隔离

不同业务必须有不同 schema。报价解析和 Local Fee 解析如果共用一套 schema，短期看起来省事，长期一定会互相污染。

正确的做法是：底层能力复用，业务 schema、normalizer、测试样本分开。这样出问题时，才能知道是哪个业务、哪个模板、哪个规则出了问题。

Trace和Timings

真实样本回归

图片解析技术分析

Instructor 是什么

Instructor 不是一个大模型，也不是 Agent 框架。它是一个围绕大模型调用的结构化输出工具。

更准确地说：

它把“请模型输出 JSON”变成“请模型输出符合 Pydantic schema 的对象”。

它会把模型原始输出解析成 Python 类型对象。

它会用 Pydantic 校验字段是否存在、类型是否正确、枚举值是否合法。

它可以在校验失败时自动重试，但本项目报价解析默认不建议开启重试。

from pydantic import BaseModel, Fieldfrom langchain_openai import ChatOpenAIimport instructor
classBusiness(BaseModel):# 模型定义

llm = ChatOpenAI(model="gpt-3.5-turbo",   api_key="你的openai密钥")instructor_llm = instructor.patch(llm)

# invoke 直接返回校验后的结构化对象，无需手动解析JSONresult = instructor_llm.invoke(    input=prompt, response_model=Business)# 关键：强制模型输出匹配该模型结构

它解决什么问题

在当前涉及大模型解析的业务场景中，模型经常需要返回 JSON。只靠 Prompt 约束会遇到这些问题：

返回半截 JSON。

字段名漂移，例如routes写成route_list

类型错误，例如价格应该是数字却输出"USD 3050"

嵌套结构缺字段，例如某条 route 没有pod_raw

枚举值不受控，例如status输出成“解析完成”而不是success。

Instructor 可以把这些问题前置为 schema 校验问题。

它不能解决什么问题

Instructor 不能替代 OCR、不能替代业务规则，也不能自动理解业务逻辑。它就像一个输出约束，它不能替代业务解析的能力，更不知道每个字段代表了什么含义，它只知道哪些字段应该存在。

所以它应该放在“结构化输出校验层”，不能被误用成“报价解析能力本身”。

推荐接入方式

当前边界是：

单轮模型调用优先。成功就是返回完整 JSON。失败就是返回失败状态和错误信息。不开放同步人工复核中间态。默认不做“失败后二次模型修复”。

因此 Instructor 的默认策略应该是：

这能避免为了修复 JSON 格式而额外调用模型，导致成本和耗时不可控。

文本解析技术分析

总结

最后附上我完整项目的时序图，这篇文章分享就到这里，感谢阅读。