资讯详情

我把年报、招标文件和 14 年前的扫描件,分别喂给了裸 LLM 和 TextIn Xparse + LLM

📅 2026/11/3 19:24:14 | 华诺云谱 👁 阅读
我把年报、招标文件和 14 年前的扫描件,分别喂给了裸 LLM 和 TextIn Xparse + LLM
摘要起因是一个听了很多遍的说法Agent 的瓶颈不在智商在视力。我不太服气。现在的大模型连图片都能看了读书看报不在话下怎么会卡在视力上于是搞了个对照实验从公开渠道收了 7 份“地狱难度”的企业文档200 页的上市公司年报、政府采购招标文件、303 页的招股书、还有一份 2012 年的纯扫描件公告分别用两条链路喂给同一个 LLM一条是裸模型直接读 PDF 原生文本大多数 RAG 教程教你的默认做法另一条是先用合合信息 TextIn xParse 解析成结构化 Markdown再读。33 道固定问题跑下来裸读组可确定回答 61%xParse 组 79%。数字差距是一方面更刺激的是过程扫描件那一组裸读模型拿到的全部输入只有 36 个字符五个问题全灭而跨页表格、流程图、合并单元格这些场面两组的差距不是答得好不好是能不能答。文末顺便聊聊这套东西的终局形态合合信息在 QCon上刚发布的企业知识服务引擎解析只是第一层后面还有一整条把企业文档变成 Agent 共享记忆库的链路。一、开始之前先介绍一下 TextIn xParse按老规矩实验之前先介绍一下主角TextIn xParse。一句话定位合合信息旗下面向 LLM 与 Agent 的文档智能基础设施。这句话的重心在「基础设施」它不回答问题、不替你写报告做的是更底层的事把复杂文档转化为干净、一致、可用于 AI 的结构化数据给知识库、RAG、各种 AI 工作流当数据底座。上一期我搭错题工作台的时候打过比方它像水电煤Agent 这栋楼能盖多高取决于这层供给稳不稳。合合信息做文档智能做了 20 年xParse 是这套家底面向 AI 时代的产品化。官网上的几个数字全球 1,000 企业在用累计处理文档超 10 亿页大规模场景下日处理千万页级API 可用性 99.99%。生态位也很清楚Dify、RagFlow、LangChain、Milvus 这些主流 RAG 技术栈即插即用WorkBuddy、豆包工作这些 Agent 产品里有官方连接器每天还有 1,000 页免费额度。能力上挑几条和本文实验直接相关的说。格式层PDF电子档加扫描件、Word、Excel、PPT、图片等 16 种格式通吃识别层文本、表格、公式、手写体、印章、页眉页脚等 16 种内容元素结构层合并单元格、跨页表格、无线表格的还原是官方明着宣传的强项阅读顺序按版面还原输出层Markdown 和 JSONLLM 直接消费页码、段落、字符多级溯源。速度百页 PDF 最快 1.5 秒。入口在 TextIn xParse注册就能用。本次实验我全程走的是它的CLI。底牌交代完了。但官网上写的和 200 页年报、2012 年扫描件面前实际发生的永远是两回事。二、实验设计先交代清楚再开始实测先说一下我为什么要较这个真。这两年搭 RAG、写 Agent 的朋友都知道一个流程文档进来加载器一把梭转成文本切块入库检索生成。教程都这么教。但真实世界递给 Agent 的文档长什么样这里我准备了四份文件年报密表评分细则表招股书扫描件一份年报 200 页财务报表一页接一页续页连表头都不给你重复一份招标文件评分细则表里全是合并单元格分值藏在格子里招股书里塞着泳道流程图关键信息全在图里还有些老文档干脆就是一张扫描图片连文字层都没有。这些文档喂给裸 LLM到底会发生什么我把好奇心落成了实验。文档池7 份全部来自公开渠道年报来自巨潮资讯招标文件来自政府和高校官网招股书来自上交所扫描件是 2012 年的上市公告。每一份都截取了难点最集中的页段ID文档页数难点T1中材科技 2025 年报·三大报表10跨页表格、续页无表头、空值与零T2北京市政府采购招标示范文本8合并单元格评分表、勾选框、留白T3清华深圳国际研究生院招标文件9评分细则、符号标注T4上海市公安局招标文件5复杂评分细则T5长江存储招股书·经营模式章节5泳道流程图、图文混排T6长江存储招股书·三大报表5跨页财务表格T7苏交科 2012 上市公告2纯扫描零文本层两条链路唯一变量是输入形态A 组(裸读): PDF → PyMuPDF 提取原生文本层 → LLM 回答 B 组(解析): PDF → xParse 解析成结构化 Markdown → 同一 LLM 回答A 组走的是LangChain教程里最常见的那条路。B 组用的是 xParse合合信息做了 20 年文档智能沉淀出来的解析服务面向 LLM 和 Agent 的基础设施支持 PDF、Office、图片等十几种格式能识别 16 种内容元素百页 PDF 最快 1.5 秒解析结果直接输出 Markdown 和 JSON。答题模型两边完全一致都是干净上下文的 LLM问题清单固定谁也不许查外部资料答不上来就必须承认。标准答案我单独从 PDF 文本层独立提取加交叉校验比如资产总计必须等于流动资产合计加非流动资产合计对不上就回去重查不依赖任何一组的输出避免既当运动员又当裁判。另外我还加了个 A′ 组做辅助参照把 PDF 渲染成图片让视觉模型逐页直读模拟“多模态模型直接看文档”的路线后面会讲到它的尴尬之处。好了直接开始实测查看效果。三、解析前 vs 解析后先看原始画面对比在讲答题成绩之前先把两条链路“看到的东西”摆出来这个对比比分数更直观。第一张画面T1 年报的跨页表格。A 组PyMuPDF 提取原生文本层拿到的输入长这样货币资金那一块项目 期末余额 期初余额 流动资产: 货币资金 3,098,128,164.39 2,742,679,443.43 结算备付金 拆出资金 交易性金融资产 0.00 0.00普通方式解析出来基本没有结构这一说法表格没了。科目和数字变成一锅线性文本哪个数对应期末哪个对应期初全靠数数。更阴险的是“结算备付金”“拆出资金”这种空科目后面直接没有数字一数错位后面全错。而且这份报表有合并和母公司两套科目名一模一样只有数字不同文本层里你根本分不清现在读的是哪套。B 组TextInxP****arse解析的输入同一个位置table border1tr td货币资金/td td3,098,128,164.39/td td2,742,679,443.43/td /trtr td结算备付金/td td/td td/td /trtr td交易性金融资产/td td0.00/td td0.00/td /tr/table三列关系明明白白空值和 0.00 是两种不同的语义前者是“没这个科目”后者是“有但为零”。整张资产负债表跨了 4 页xParse 拆成 4 个连续的 table 块拼回来行序连贯中间还留着!-- 75 --到!-- 78 --的页码标记每个数据在哪一页可查。上面为 T1 跨页表格对比上边PDF 原件密表下边TextIn Xparse的 table 输出下面为导出md文件的效果甚至页面分页这种结构都解析的非常清晰。T1 跨页表格对比左边 PDF 原件密表右边 xParse 的 table 输出能够明显看出来TextIn Xparse解析的内容结构非常清晰、干净是一份非常适合 AI Agent开发 的结构化数据。第二张画面T5 招股书里的流程图。长江存储招股书里有一张研发流程泳道图研发阶段四个节点量产阶段两个上面挂着三个决策点下面吊着四个 TR 交付节点。这种图对文本层提取是彻底的黑洞一行都捞不到。A 组的输入里这段就是一段正文加一片虚无。xParse 的处理给了我一个惊喜图作为图片元素保留但图里的文字被单独 OCR 了出来挂在图旁边!-- 研发阶段 ←量产阶段→ 立项决策点 计划决策点 量产/可获得性决策点 (Charter) (PDCP) (ADCP) 立项阶段 计划阶段 开发阶段 产品验证阶段 可靠性验证阶段 量产阶段 产品需求及规格冻结 产品设计发布 产品设计冻结 产品量产准入 (TR1) (TR2) (TR3) (TR4) --决策点编号 Charter、PDCP、ADCP交付节点 TR1 到 TR4全部可检索。图的拓扑关系还是要看图但图里的信息不再是对模型隐身的。第三张画面T7那份 2012 年的扫描件。A 组从这 2 页 PDF 里提取到的全部文本36 个字符。俩页码。正文一个字都没有因为扫描件没有文本层那是图片。xParse 走OCR 加多模态识别整份公告全文识别出来股票简称苏交科、代码 300284、发行后总股本 24,000 万股、五家信息披露网站的域名一个不落连落款的签章都作为图片单独提了出来。扫描件对比原件扫描页 vs OCR 出的完整文本同一个世界两条链路看到的是两份完全不同的文档。这个前提下再去比答题结果其实已经有点注定了。四、33 道题跑完逐个单元看战报每个单元 4 到 7 道固定问题答案都能和原文逐字核对。按“翻车烈度”从低到高讲一个一个来。T6长江存储三大报表4 题两组全对。数字题科目和数字在文本层里是挨着的裸读组仔细数数也能数对。xParse 组同样全对顺手把资产负债表跨了 2 页、各科目在第几页都标了出来。这局平手但注意xParse 组的“对”是有结构保证的对裸读组的“对”是小心翼翼数出来的对前者敢写进报告后者得复查三遍。T1中材科技年报三大报表7 题两组全对但这局有意思。裸读组不但全对还自己做了交叉验证用资产总计等于负债加权益去验算。看起来很美但它答题时明说了科目与数字的对应是“按行序推断”的。这是在悬崖边上走对了路不是路不悬崖。10 页之内运气好换成 200 页全本、科目更密、合并与母公司报表混着来这种推断迟早出事。xParse 组同样全对而且每道题都带着页码出处第 75 页货币资金、第 76 页资产总计 65,590,977,996.41可回溯可抽查。而且 xParse 组 非常清晰定位位置非常精准左边体现小心翼翼数数右边体现带出处的底气。裸读组的推断式回答 vs xParse 组的带页码回答T3清华招标两组都是 2/5但成色不一样。有两道题的答案确实不在节选页范围内这怪我题目设计两组同等受限真正拉开质感的是另外的细节。裸读组的输入里商务评价表“诚信评价”那一行的序号文本层提取出来是 5它靠“1510530”的合计校验才发现这数字不对应该是 3出现了单元格错位。xParse组这边60/30/10 的总分构成连同九个评分项的每一档分值完整还原每一条还标着页码出处评标方法在第 23 页、综合得分公式在第 28 页想抽查随时一步到位。T2北京政采示范文本2/5 平局这锅得文档自己背。我拿到手才知道政府采购的“示范文本”是个空模板评分因素是留白的复选框是没有勾选的。两组都只能答出框架答不出内容。平局但这局证明了实验的另一面输入里没有的信息谁也变不出来模型不背锅解析也不背锅。T4上海公安招标又是表格截断但这次我验证了原因。两组都只看到评分细则的前 4 项分值上限加起来 44 分离 100 分的标题差着 56 分。我专门翻回原 PDF 查了第 28 页就是续表硬件产品选型 14 分、实施方案 14 分……是我节选的时候在 27 页末切了一刀两组同等挨刀公平。xParse 组在这局把可见部分的细节抠得更干净比如“软件系统设计 18 分”下面还分了三个 6 分的子项。T5长江存储经营模式3/5 对 5/5分水岭来了。裸读组答出了研发四阶段答出了销售模式和五项经销商考核但在“决策点编号”和“TR 节点对应关系”两道题上彻底抓瞎这些信息全在流程图里文本层一个字都没有。**xParse 组全对。**Charter、PDCP、ADCP产品需求及规格冻结对应 TR1、产品设计发布对应 TR2全靠图旁边那块被保留下来的 OCR 文字。图文混排文档里图内信息能不能捞出来直接决定这题是送分题还是绝命题。T7苏交科扫描件0/5 对 4/5没有悬念的碾压。裸读组输入 36 个字符五题全灭。不是它不会答是它什么都没看见。xParse 组效果优势明显简称、代码、上市日期、股本、五家网站全对一份 2012 年的纯图扫描件OCR 加多模态硬是把整页文字捞了回来。七组数据测完裸读组 20/33 约 61%xParse 组 26/33 约 79%。数字摆在这但我更想强调数字背后的两种失败。裸读组的失败是“看不见”扫描件全灭、图内信息全丢这是物理层面的无解。xParse 组的失败是“看不准”个别字符、个别符号这是工程层面可以继续磨的解。一个决定能不能答一个影响答得多好性质完全不同。对了还有 A′ 组**视觉模型逐页直读那条路。它单页能力其实不俗密表数字逐字符识别全对扫描件单页也读得干净。但它有个结构性尴尬一次只能看一页。跨页的“资产总计”它看不见得靠人翻页投喂无表头的续页列含义靠猜它把“其中应收利息”的父科目都猜错了。**一份 200 页的年报等于 200 张图token 成本先不说这个投喂流程本身就是个新的体力活。单片视力好没有全局结构感这条路适合单页问答不适合整档文档的工作流。五、为什么 xParse 能做到拆开看四个关键设计同样是解析差距为什么这么大。看了下 xParse 的技术资料几个关键设计值得单独说。第一按页选解析链路。电子件走原生解析扫描件走 OCR复杂视觉版面上多模态模型增强不是一刀切。所以 T7 那种 2012 年的扫描件和 T1 那种 2026 年的电子件走的是两条不同的路各自最优。第二表格当结构还原不当文字流。版面识别还原行列关系跨页表格拼接合并单元格用 rowspan 语义保留。T5 招股书里那张工艺流程表“晶圆制造”一个分类横跨 11 行、还跨了页xParse 输出的 table 里跨页后的续行首列为空、rowspan 延续这要靠纯文本提取神仙也还原不出来。第三保留位置和来源信息。解析结果带页码、坐标输出里那些!-- 76 --就是页码标记。这是“可追溯”的物理基础答案能定位到页质检、审计、回查才有抓手。企业场景里这条比准确率本身还值钱不可追溯的数字业务方是不敢用的。第四Agent 友好的输出形态。Markdown 加 JSONLLM 直接消费不用再写预处理。我这次全程用的是它的 CLI一条命令的事# 解析 PDF,输出结构化 Markdown(自动走免费额度) xparse-cli --profile workbuddy parse 节选1-年报财务报表跨页.pdf \ --api auto --output T1/10 页的节选解析用时 3.2 秒。四个设计叠在一起回答的其实是同一个问题怎么让机器「看懂」一页纸的结构而不只是「看到」一页纸的文字。实验里那些跨页表格、合并单元格、图内文字的胜局不是撞大运是这四层设计各司其职的结果。六、解析之上把企业文档变成 Agent 的共享记忆库实验做到这其实只回答了一半的问题。解析把文档变成了干净的结构化数据但企业里的真问题比“读一份文档”大得多。同一个客户CRM 里叫 A 公司合同里叫 A 有限公司ERP 里是编码 C1024AI 按字面匹配三条记录一条都对不上。合同在法务的共享盘订单在 ERP交付通知躺在邮箱每个 AI 应用各自建一套知识库口径对不上来源说不清。我在实验里撞到的“合并报表和母公司报表分不清”就是这个问题最温和的版本。这就是合合信息这次在QCon 全球软件开发大会上发布的新东西要解的题企业知识服务引擎。它的思路是把链路拉长三层递进。TextInxP****arse 做深度解析让文档可读保留结构、复杂内容和原文位置DocFlow 做语义结构化面向混合文档包拆套分类、字段抽取、规则校验、人工复核让字段可用知识服务引擎在这之上做可信知识组织实体、关系、规则、版本、来源让知识可信。一份供应商交付通知进来最后变成的是一条能用的业务事实订单 P-1042 预计 10 月 1 日到货置信度 92%原始邮件、时间、正文片段整条证据链一路能点回原文。而且这套知识是共享的。一套知识底座通过问答、API、MCP 协议、SDK 同时喂给多个 Agent不用每个 AI 应用重建一遍知识库。合同问答、标书检查、金融风控、生产运营四个场景读的是同一份知识口径天然一致。发布会 PPT 里那个生产运营的例子我印象挺深订单准备度 82%物料缺口、产能冲突、风险预警全是从订单、BOM、技术协议这些散落文档里攒出来的实时视图而且每条结论背后都挂着 Evidence 按钮。说真的这和我实验里感受是连贯的。解析层解决的是“看得见、看得准”知识服务引擎解决的是“记得住、说得清、查得到”。前者是后者的地基没有高质量的解析后面的知识组织就是沙上筑塔这也是为什么这次 QCon 的发布底层站的还是 xParse 这套磨了 20 年的文档能力。企业知识服务引擎目前还没正式上线已经开了预约试用感兴趣的可以提交申请抢先体验。预约入口写在最后回到开头那个说法Agent 的瓶颈不在智商在视力。这轮实验跑完我基本被说服了但想补一个更完整的版本。视力有两层一层是能不能看见扫描件、图内文字这层裸模型暂时无解解析层解决另一层是看见了能不能拼成结构跨页、合并单元格、层级归属这层纯识别不够要靠版面理解和结构化还原。再往上一层是看见并理解之后这些信息能不能沉淀成组织里所有 Agent 都能持续调用的记忆。那是另一场更大的仗刚刚在 QCon 上开场。文末照例交代可复现性。7 份文档全部来自公开渠道巨潮资讯、上交所、政府公开采购信息问题清单、两组输入、原始答案文件我都留着xParse 有每日免费解析额度想自己跑一遍的朋友一套脚本加一个下午就够。有不同结论欢迎来评论区打脸。以上既然看到这里了如果觉得不错随手点个赞、收藏、转发三连吧。
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑