前言
企业知识库的第一版通常不难搭：上传 PDF，提取内容，切分入库，接上检索和问答。现成工具就能把这条流程跑通。麻烦出在开始问具体业务问题之后。
文件明明上传完整，回答却漏了限制条件；数字找到了，设备型号对不上；文字读着顺畅，翻回原文才发现引用的是另一张表。调整提示词可能救回一道题，却解释不了下一份文件为什么又出错。
不妨先回到输入：Agent实际读到的内容，还保留着原始文档的意思吗？
拿设备技术规范来说，一张参数表可能横跨两页，几个型号共用一个合并单元格，表格下方还有一条脚注，限定某项参数的适用范围。要回答"这台设备能不能用在当前项目里"，型号、数值、单位和条件得一起读明白。
对人来说，这不过是往上看一眼表头、往后翻一页；对文档处理系统来说，却牵扯到表格结构、阅读顺序和内容关联。哪一处关系丢了，后面的检索和回答都可能跟着出错。
企业 AI 读文档，难在哪里？从一张跨页表格说起
一、 文档里的结构，本身就是信息
读文档时，我们一直在靠版面理解内容。一个数字写在"额定功率"下面还是"峰值功率"下面，意思不一样；一段说明挂在哪个小节下，就约束哪一部分内容。"同上""见下表""仅适用于以下型号"这类说法，也都要靠上下文才解释得清。
文档转成纯文本之后，这些信息未必还留得住。表格可能变成一串数字，双栏正文可能交错着排，页眉页脚也可能插进段落中间。单看文字识别率，查不出这些问题：字本身往往没错，错的是它们之间的关系。
这种损失会顺着流程往下传。表格在解析时散开，切分程序就可能把数值和表头分到不同片段；限制条件落在另一个片段，检索时又没一起取回。模型最后拿到的材料虽然都出自原文，却撑不起一个完整判断。
排查时，把原文、解析结果、检索片段和最终回答摆在一起看。少了表头，先查解析；脚注已经提取出来却没进回答，再查切分和检索。问题出在哪一步，就改哪一步。
在目前的背景下，单纯只靠Agent去完成文档、表格等解析还是会存在挺多难以很好解决的问题。 针对这种问题，我使用过多种产品去解决它，下面介绍一个使用下来效果很不错的产品 TextIn xParse 。 TextIn xParse 负责的是解析这一步：把 PDF、Office 文档、扫描件和图片转成 Markdown、JSON 等结构化数据，交给知识库、RAG 或 Agent 继续处理。
二、 TextIn xParse ：让Agent稳定理解复杂文档
TextIn xParse 是合合信息旗下面向 LLM 与 Agent 的文档智能基础设施，可以将复杂文档转化为干净、一致、可用于 AI 的结构化数据，适用于知识库、RAG 或其他 AI 工作流下游应用。
从产品定位看，xParse 不是单纯的 OCR，而是面向 LLM 的文档解析服务。输入支持 PDF、图片等常见格式，输出提供 HTML、Markdown、JSON 等多种结构化格式。
官方地址：www.textin.com/register/co...
官方文档地址： docs.textin.com/xparse/over...
2.1 表格：数值与行列要对得上
企业文档里的表格往往既有数据，也有说明。多级表头用来区分同一指标的不同工况，合并单元格表达一组型号的共同属性，跨页续表则靠前面的表头解释后面的数据。
TextIn xParse 支持多级表头、合并单元格和跨页表格的结构还原。下游程序读取一项参数，需要同时找到它的行标题、列标题和单位。对应关系留住了，数据才有含义。
这些关系也直接影响抽取。要把设备参数写进数据库，光提取出一个"2.0"不够：它是功率还是重量，什么单位，属于哪个型号，都得交代清楚。表格结构正是判断这些含义的依据之一。
2.2 章节与阅读顺序：给切分留下依据
一份长报告里，同样的词会反复出现。"维护要求"可能是章节标题，也可能出现在正文、目录和页眉里。标题层级留住，后续程序才能分清内容的位置和归属。
阅读顺序同理。双栏正文、图片旁的说明、表格下方的注释，都要排得合理，否则句子虽然完整，前后却接不上。
TextIn xParse 输出的标题层级和阅读顺序，可以用来安排切分：给段落保留所属章节，把表格和相关说明放在一起。长章节可能还是要拆，短表格更适合整块保留，分到什么程度，取决于文档和问题的范围。
2.3 混合 PDF：按页面处理
企业收到的 PDF 经常混着好几种来源：正文是电子导出，附件是扫描件，中间还夹着拍照上传的签字页。一律用同一种方式读，未必能把每页的信息都用上。
电子页可能保留原生文字，扫描页则要靠视觉识别。TextIn xParse 结合电子解析、OCR 和多模态解析，支持按页选择解析链路；对图纸、公式和复杂视觉版面，还提供多模态增强解析。
测试图纸或公式，先分清任务做到哪一步：是提取标注、保留表达，还是要作工程判断。前两项属于输入处理；工程结论还得结合专业规则和实际业务信息，检查标准也不一样。
混合 PDF 很适合检验完整流程，不过最初几轮最好先把页面类型分开。这样某页漏项时，才分得清是图像质量、页面结构，还是后续处理出了问题。
可以先用清晰的电子页查标题和表格，再把内容相同的页面转成扫描件，看文字、结构和位置还能不能用。两种输入内容一致，比较起来差异才看得清。之后再逐个加变量：轻微旋转、低对比度，各自记录。别一次把条件全改了。
复杂视觉页面也要先说清任务。一页图纸，可以先检查标注文字和位置，再检查参数与对象对不对得上；至于能不能据此得出工程结论，那是另一回事，还需要专业信息。把输入提取和业务判断分开验证，才不会把一层做对了当成整件事做成了。
样本里也别漏掉普通页面：空白页、分隔页、重复页眉都可能混进正文，打断段落，或者给检索添噪声。光挑复杂页面展示能力不够，还得看每天真收到的文件能不能处理妥当。 
三、 用三份样本检查解析与问答
"请总结全文"适合快速浏览，却不容易暴露结构错误：漏掉一句脚注，摘要照样读得很顺。下面三份小样本答案明确，分别检查跨页表格、条件限制和混合页面。
型号、数值和文字都是构造样本用的示例。先把预期答案按原文定下来，再开始测。
3.1 测试场景一：跨页长表格
企业文档里的长表常常一跨就是好几页，续页大多没有重复表头，只能靠"续表"这类很弱的标识来分辨。 系统得先判断这一页是上一张表的延续，还是另一张新表；拼接时还要把表头和列宽一并继承下来。这一步判断错了，长表容易被拆散，不相干的表格也可能被错拼到一起；表头一乱，数据匹配也跟着偏移。要是再遇上跨页合并单元格，难度还要往上加。
问题的根源不在 OCR 文字识别，而在缺少文档全局建模、分页状态管理这类架构能力。跨页解析需要的，是具备全局表格理解能力的模型。
下面是一个小区车位管理的长表格，我用几个别的产品测试过都没有能够正常解析到一个表格中，而TextIn xParse则正常识别解析为了一张表格。 
而且TextIn xParse 在解析时支持多种设置，可以根据自己文档类型选择更准确的类型以便有更合适的解析效果。 
3.2 测试场景二：多行单元格+密集小字
有种情况则是在一些表格文档中会有大量行数的单元格以及很密集的小字，会在一些产品多量且复杂的采购清单中或者订单订货代码文档中使用。
这种情况下由于数量很多且字很小，可能会出现文字解析错误的情况，这个就比较考验产品的基本功了。
下面是一个电源连接订单的文档，在企业文档中有大量的这种订单表格，可以看到解析的没有任何问题，这对于有大量文档需求来说是一个很棒的体验。
3.3 测试场景三：无框线表格+表头嵌套
下图是某招股说明书中一张表格，这是一个较为复杂的表，里面有表格无线（不连续）、表头嵌套、繁体字、黑色下划线格等各种干扰因素。 
使用TextIn xParse 解析之后可以看到表头和内容都解析的都没有问题，文本、数值和换行和单元格都较为准确可以正常使用。
还可以解析成 Markdown、JSON、表格等格式，功能也比较齐全，让Agent分析时可以理解到具体单元格数据的正确对应关系。
四、 解析之后，怎样把结构带进知识库
解析结果看着整齐，不代表已经入好库。切分、转换和存储都可能再把信息弄丢一次：标题识别出来了，入库后只剩正文；表格还原完整，切分时又被拦腰截断。这几步要和解析输出一起查。
先看章节。一个段落可能只写"应在安装前完成检查"，检查什么却由上一级标题交代，切分时只留下段落，检索回来就少了对象。所以给片段附上所属章节路径，让程序知道它来自哪一章哪一节。标题层级只是组织依据，切多细，还得看业务问题通常需要多大范围的上下文。
表格单独处理。小表可以整体保留，大表可能得分段，但拆开后仍要知道列标题、单位和必要注释。任务不同，需要也不同：回答一个型号的参数，围绕那一行组织就够了；比较几个型号，就得取回一组相关记录。固定长度切分很容易把这些差别抹平。
原文位置要一路带下去。一个片段可能对应原文里好几个区域，一个回答也可能综合几页材料；整段只存一个页码，展示时未必指得准每项依据。集成时按实际接口返回保住来源和内容之间的映射，别在转成业务字段之后只剩下字段值。
文件还得分得清。同名文件内容可能不同，改了名字也不代表业务内容变了。在资料管理层记下来源、版本和处理批次，事后才说得清某次输出用的是哪份输入。
验收时挑一个字段从头跟到尾：原文位置对不对，解析全不全，入库后结构还在不在，回答时又取回了什么。一个字段走完，链路哪里漏了就看得见。
五、 从文档解析走到企业知识服务
到这里，单份文档的内容、结构和位置已经有了检查办法。可采购订单、收货单和发票散在不同文件里，还得把相关信息对上。不同单据的字段名和格式不一样，订单、金额和交付日期却得对得上。
在 TextIn 的产品链路里，DocFlow 管的是混合文档包：拆套分类、字段抽取、结构归一、校验审核、人工复核，最后把内容整理成可以继续处理的业务信息。
再往后，问题就跨出单次文档处理了。客户换了简称，订单进度变了，供应商又发来一封新邮件，Agent 用的知识也得跟着维护。各应用各自接入、整理和更新资料，同一个问题就可能拿到不同时间、不同口径的答案。
10 月 22 日，在 QCon 全球软件开发大会上，合合信息旗下 TextIn 推出企业知识服务引擎。它依托 xParse 与 DocFlow 的文档处理积累，把文档、表格和业务系统里的信息加工、关联起来，形成 Agent 能持续使用的上下文，为多个 Agent 提供共享的企业知识。
TextIn 企业知识服务引擎已开启预约试用。有企业知识管理或 Agent 应用需求的团队，可前往 b.intsig.com/solution-ap... 提交申请。
5.1 新品的三部分能力
企业知识服务引擎包含知识建设、知识运营和知识服务三部分，分别管组织资料、维护变化和向应用提供知识。
**知识建设管接入和组织。**信息可能来自文档、数据库、API 或其他资料源，进来之后要做解析、抽取、清洗和质量检查，再按业务定义把对象、属性、关系和规则组织起来。订单关联哪个客户、引用哪份合同、涉及哪些物料，都属于需要表达的业务关系。
问一笔订单的交付情况，应用得取回这笔订单的合同、进度和通知。订单和资料的关系事先组织清楚了，才不会只按"交付"两个字搜出别的项目的片段。
**知识运营管变化和可信度。**企业信息一直在变，系统要跟踪版本，管理新增、修改和待确认的内容，处理来源之间的冲突。来源证据、人工确认和质量监控也在这部分。
比如两个系统给了不同的交期，不能随手挑一个当最终事实。它们可能分别代表合同约定、内部计划和供应商预计，含义本就不同；也可能确实是待确认的冲突。把这些区别维护住，Agent 才有可能用上合适的信息。
**知识服务把知识提供给应用。**对象、上下文和证据三类接口分别对应不同的调用需求，通过 API、MCP 等方式集成。对象服务面向业务对象及其属性和关系，上下文服务围绕当前任务提供相关信息，证据服务负责返回来源依据。
开发者按任务选用：读订单属性、为交付判断准备材料，或者把引用依据展示给用户。要的数据不同，调用方式也跟着变。
5.2 补入新资料，再验证一次
知识服务跑起来之后，可以用一条简单的业务关系验证更新：先录入客户、合同和订单，再补一份带新预计日期的通知。
不只要查通知能不能被找到，还要看它有没有关联到正确的订单、原有约定是否还在、应用分不分得清记录的新旧和含义。
可以围绕同一个对象分别问："合同要求是什么""目前预计是什么""这次变了什么"。三个问题要的材料组合不一样；答案如果都是同一个日期，那就要去看业务字段、版本或上下文选择方式了。
遇到两份来源矛盾的材料，看系统怎么呈现待确认状态。业务人员还没核实，就不该让应用把其中一个值包装成已确认事实；确认之后，要能查到依据哪份记录、由哪个流程处理。这几步能把知识建设、运营和服务放进同一条实际任务里看。
多 Agent 复用也可以沿着这条关系展开：客服查交期，生产助手读准备条件，分别看它们拿到的信息符不符合各自的任务和权限。共享知识要的是相关且受管理的记录，并不要求所有应用看到一模一样的内容。
总结
回到开头那张跨页表格：答错的常常不是字没认出来，而是字与字之间的关系没带进来。
解析这一层把表格、章节、页面类型和原文位置留住，后面的切分、检索和回答才有依据。验证也不必从大工程开始，几份答案明确的小样本，把中间结果留下来，就能看清问题卡在哪一步。
尤其是处理多批量文档时许多企业已经开始使用AIAgent，这个时候选用一个优秀的产品就显得尤为重要。
目前 TextIn xParse 已经在常用Agent中都有布局，比如豆包、WorkBuddy等都有官方提供的对应插件，在使用时可以直接搜索并添加插件使用，对普通用户来说也是非常方便了。