企业AI知识库建设里，最容易被低估的一步，往往不是大模型问答，也不是向量检索，而是“解析”。
一份企业文档进入知识系统之前，首先要从 PDF、Word、PPT、Excel、图片、音频、视频、OFD、XMind 等形态，变成系统能够理解、索引、治理和复用的标准内容。解析质量决定了后续切片质量，切片质量决定了检索质量，检索质量最终影响问答结果的准确性和可信度。
一、企业需求：文档解析不是“能不能识别文字”
企业AI知识库的第一道门槛，是让企业已有资料真正进入知识系统。但企业资料并不是统一、干净、结构化的数据。
在一个真实企业里，知识通常会同时具备几个特点。
第一，文件类型复杂。制度文件可能是 PDF，操作手册可能是 Word，产品材料可能是 PPT，业务台账可能是 Excel，现场记录可能是图片，培训内容可能是音频或视频，政企客户还可能有 OFD，研发和产品团队也可能有 XMind 这类结构化脑图。
第二，文档质量差异很大。同样是 PDF，有的是原生电子文档，有的是扫描件，有的包含复杂表格，有的包含公式，有的包含跨页表格，有的还需要识别图表、印章、页眉页脚和图片说明。单纯“抽文本”无法满足知识库使用要求。
第三，不同业务对解析结果的要求不同。财务制度更关注表格结构和条款层级；生产手册更关注图片、图表和步骤说明；客服知识更关注 Excel、问答对和高频反馈；培训材料则可能需要先做音频转写或视频理解。解析不是统一动作，而是业务策略的一部分。
第四，企业环境存在个性化约束。有些客户预算有限，希望能有一个基础的内置解析引擎能力，有些客户已经采购了 TextIn、百度 OCR 等外部服务希望能够集成，有些客户要求私有化部署 MinerU，有些客户希望接入自有多模态模型。解析能力必须支持厂商混用、租户隔离和私有化接入。
第五，解析结果需要可治理。企业知识不是一次性上传就结束，还要持续运营。解析质量异常、表格丢失、图片未理解、标题层级错误、切片质量不佳，都应该能被发现、调试、优化和重跑。解析能力如果只是一段后台代码，就很难进入知识治理闭环。
这些需求决定了一个结论：企业级文档解析的核心问题，不是“能不能解析 PDF”，而是不同文件、不同业务、不同客户环境下，如何用可配置、可解释、可恢复的方式获得合适的解析结果。
如果只在知识库上放一个字段，例如“当前知识库使用某个解析引擎”，系统很快会遇到边界：
- 同一个知识库里，PDF 适合 MinerU，图片可能适合图片 OCR，音频必须走语音识别，Word 可能本地默认解析更稳定。
- 同一个解析引擎可能有多套部署地址、密钥和模型，例如测试环境、生产环境、客户私有化环境。
- 同一个引擎的参数会因业务不同而变化，例如是否识别公式、是否开启表格识别、是否做图片理解、表格输出什么结构。
- 客户和运营团队需要调试、解释和回滚，而不是修改一个隐藏字段后等待结果。
因此，AIS 的解析设计要解决的不是一个能力点，而是一套企业知识生产的基础设施问题。
二、产品设计：从“选择引擎”到“解析编排”
AIS 的产品设计核心，是把解析能力拆成三层：解析引擎、解析实例、解析策略。
这三个对象分别回答三个问题：
- 解析引擎：系统有哪些解析能力？
- 解析实例：当前租户接入了哪套真实服务？
- 解析策略：某个知识库或业务场景，具体应该如何选择解析路径？
这种拆分看起来比一个下拉框更复杂，但它把企业个性化需求拆到了正确的位置。
1. 解析引擎：能力货架
解析引擎定义的是 AIS 当前支持哪些解析能力，以及这些能力适合处理什么类型的文件。
当前AIS系统支持的解析引擎如下：：
- TorchV：系统内置默认解析能力，覆盖 PDF、Word、PPT、Excel、OFD、XMind、TXT 等常见办公资料。
- MinerU：适合复杂 PDF、扫描件、公式、表格和图文混排资料，包括Word/PPT/Excel/图片等格式。
- TextIn、SoMark：适合企业级文档结构识别、表格结构、标题树、跨页内容处理等场景，包括Word/PPT/Excel/图片等格式。
- 百度 OCR：适合扫描件、图片文字识别、印章和坐标类识别场景。
- Qwen Vision、Qwen ASR：适合图片、视频理解和音频转写等非传统文档素材。
- Custom Vision：适合接入企业自有多模态模型，支持图片和视频。
引擎定义本身不直接代表某个客户已经可用，它更像一个能力货架：告诉用户系统能支持什么、适合什么文件、有哪些可配置参数。
解析引擎在这里是作为一个插件市场的缺口，解析引擎的技术会随着技术的发展，支持文件解析能力越来越强大。在AIS这里，主要包括开源/商业的解析引擎，可以以插件的方式，方便集成目前最流行的解析能力进行准入，解决企业里面的解析难题。
2. 解析实例：企业真实接入
解析实例解决的是“某个租户实际接入哪套服务”的问题。
同一个 MinerU 引擎，可以有集团内网实例、测试实例、客户私有化实例；同一个 TextIn 能力，也可能有不同账号、不同密钥、不同限流策略。解析实例保存的就是这些真实接入信息，包括服务地址、密钥、模型、限流、实例级配置等。
这层设计的价值在于，把“能力类型”和“真实服务接入”分开。产品上可以清晰表达：AIS 支持某种能力，但客户是否启用、启用哪一套、是否禁用、如何限流，都由实例管理。
对私有化客户来说，这一点尤其重要。客户可以接入自己的解析服务，而不需要改动知识库流程本身。
3. 解析策略：按文件类型编排
解析策略是这套设计最关键的产品层。
策略不是简单选择一个引擎，而是一个按文件类型组织的路由矩阵。一个策略可以规定：
- PDF 走 MinerU，并开启公式、表格、图片理解。
- Word 走 TorchV 默认解析。
- Excel 走 TextIn，以保留更好的表格结构。
- 图片走百度图片识别或多模态模型。
- 音频走 Qwen ASR。
- 视频走视觉理解能力。
- …
这样，一个知识库就可以根据文件类型选择不同解析路径，而不是被迫让所有文件使用同一个解析服务。
这对企业客户很重要。因为企业知识库通常不是单一资料库，而是多种知识素材混合进入。一个“生产手册知识库”可能同时包含 PDF、Word、图片和视频；一个“客服知识库”可能同时包含 Excel、FAQ 文档和用户反馈附件。
如果解析策略只能选一个引擎，系统会在某类文件上牺牲质量。
同时在解析策略中，考虑到不同的解析引擎会有不同的参数配置，那么在解析策略中，我们也可以对解析引擎进行参数的个性化配置。
解析策略还承担了运营管理价值：
- 可以被多个知识库复用。
- 可以查看覆盖了哪些常用文件类型。
- 可以看到被哪些知识库绑定。
- 可以在调试页面上传样例文件，验证解析效果。
- 可以对不同文件类型配置不同参数。
因此，解析策略不是技术配置项，而是知识准入和知识治理的一部分。
这样整个解析策略从文件路由 -> 配置解析引擎 -> **配置解析引擎参数 ->绑定知识库完整的解析链路完成整个企业解析文件的难题。
通过解析策略，我们呈现出来的产品理念：
- 不同的文件可以配置使用不同的解析引擎，在企业里面可以灵活准入最新的解析引擎的能力，提升解析质量
- 解析引擎作为基座，以插件可插拔的架构呈现，企业可以在此基础上扩展增强，提升文件解析能力
- 解析策略中的灵活解析参数，那么就保留了解析文件/解析引擎的双向灵活性，对下可以选择不同的解析引擎，对上，通过配合不同解析引擎提供的灵活参数，影响知识库的最终解析效果。
三、技术架构：用统一模型支撑灵活配置
从技术上看，AIS 的解析架构要同时满足两个目标：上层产品足够灵活，底层工程不能失控。
如果每接入一个解析厂商，就在知识库上传流程里写一套分支逻辑，系统会很快变得难维护。AIS 的技术方案，是把解析能力统一到几个关键抽象里：默认解析门面、外部解析服务、策略解析服务、配置合并服务、限流与恢复机制。
3.1. 默认解析能力：TorchV 默认解析器作为基础盘
解析策略再灵活，也不能要求客户一开始就接入外部服务。AIS 必须有一套默认解析能力，保证系统开箱即用。
TorchV 解析器承担的就是这个基础盘角色。它覆盖常见办公文档和知识素材，包括 PDF、Word、PPT、Excel、TXT、OFD、XMind 等。对普通客户来说，不做任何外部配置也能完成知识库构建；对高质量场景来说，默认解析也是外部增强失败后的回退路径。
这点很关键。外部解析引擎是增强能力，不应该成为系统单点风险。即使某个外部服务不可用，系统也应该尽可能回到默认解析链路，避免知识库构建完全失败。
TorchV AIS知识引擎系统基于Java语言开发，在Java生态中，开源的技术生态组件覆盖了当前企业里面常用的文件解析能力，Java生态组件的短板就是无法支撑多文件的多模态解析的诉求，这里面包括：图片理解、公式识别、版式识别、表格提取等几大难题，在实际的场景中都可能捉襟见肘，但是Java生态组件有另外一个特点就是解析速度极快，并且稳定（内存/CPU资源调度稳定）
目前TorchV AIS默认的解析引擎引入的技术组件能力解决不同文件的解析策略如下：
3.1.1 PDF文件
PDF文件作为企业内部最常用的格式，解析难度异常大，包括图片理解、公式、表格、排版等等各种问题，我们在PDF文件自研解析这条道路上也没少花时间投入，特别是表格的提取识别
上面两篇是当时的一些探索实践。
在AIS的PDF解析引擎中，默认有3种解析策略支撑，并且是逐渐降级的方案：
OpenDataLoader PDF-> Apache Tika -> PDFBox
这3个PDF解析引擎都能满足常规的企业PDF文件解析的诉求。而且针对OpenDataLoader PDF组件，还可以使用混合模式，配合OCR/VLM多模态引擎，实现混合模式的解析调用，大大提升整个解析的效果。
3.1.2 Word/PPT/Excel格式
这类格式，PPT/Excel是企业中最难处理的格式，PPT并没有版面的信息，而Excel的用法也是层次不齐（数据库/结构化/非结构化的场景知识内容都可以用Excel）
而AIS知识引擎在这类文件上做的支持
- Word格式在Apache POI的基础上做优化提升，主要解决表格还原的问题，这个组件我们也进行了开源《torchv-unstructured》，参考文章《企业AI知识库的文件解析痛点-Word格式解析优化（准确率95%）-100%开源》
- Excel文件做了格式上的适配支持，目前会把Excel解析拆解成为K/V的形式，最终进行索引向量化
- PPT复用Apache POI的文件读取能力，读取文件内容
在这些文件类型中，Java生态的解析组件，有一个好处就是，都可以支持03老文件，比如doc、ppt、xls格式的文件，特别是针对doc格式，很多Python生态并不支持直接解析这类老文件，而老文件格式一般在政府/银行/保险等客户领域是非常常见的，不可忽略
3.1.3 Xmind/OFD格式
Xmind本质上是一个Zip压缩包文件，和docx文件格式是差不多的类型，对于Xmind的文件类型解析并不困难，直接解压后，读取Xml的格式规范，即可得到一个标准的Markdown文本文件。
OFD格式是政府领域用的最多的文件格式，使用ofdrw项目进行支持，https://github.com/ofdrw/ofdrw
3.2. 解析门面模式的SDK封装：统一解析输入和输出
外部解析引擎之间差异很大。
有的引擎是同步识别，有的引擎是异步任务；有的返回标准内容文件，有的返回压缩包，有的需要通过 URL 下载结果；有的适合 PDF，有的适合图片，有的适合音频，有的适合视频；有的有提交限流，有的查询也有限流。
为了不把这些差异暴露给知识库上传、知识加工和策略调试流程，AIS 在运行时统一成“提交、等待、查询、返回标准结果”的模型。上层不需要关心具体厂商如何处理，只需要消费最终的标准内容文件。
外部引擎接入后，运行时大致经过以下过程：
- 文件上传触发解析。
- 系统根据知识库级或文件级配置找到解析策略。
- 策略根据文件类型找到对应解析路径。
- 系统合并默认配置、实例配置和路由配置，生成最终有效配置。
- 外部解析引擎执行提交、轮询、查询和结果下载。
- 成功后进入切片、向量化或后续知识加工节点。
- 未命中或失败时，尽可能回到默认解析链路。
这个链路的重点不是“接了多少个厂商”，而是不同厂商可以被纳入同一个运行模型。
3.3. 稳定性设计：限流、恢复与日志
外部解析服务通常不是无限资源。客户的私有化服务、第三方 OCR 账号、多模态模型服务，都可能有提交频率和查询频率限制。
AIS 在解析服务调用前加入了限流机制，且支持多副本共享配额。也就是说，系统扩容后不会因为多个服务实例同时提交任务，把客户的解析服务打挂。Redis 异常时，也会回退到进程内限流，确保调用链路仍有基本保护。
对于异步解析任务，AIS 会保存外部任务编号和心跳信息。如果文件已经提交成功，但 AIS 进程在等待结果时重启，系统不应该重新提交同一个文件，造成重复计费和重复任务。通过任务编号恢复机制，系统可以继续查询或等待已有任务结果。
此外，每个解析引擎提交前都会记录关键参数，例如文件名、文件大小、引擎参数、模型参数等。这些日志不是为了堆技术细节，而是为了在客户反馈“这个文件为什么解析成这样”时，有证据可查、有路径可复现、有参数可对比。
稳定性设计的目标是让解析策略不仅能配置，而且能在企业环境里长期运行。
四、思考总结：解析能力正在成为知识生产基础设施
AIS 解析引擎和解析策略的设计，本质上是在解决企业知识进入系统前的第一道质量问题。
企业知识系统不是把文件上传进来就结束。真正的问题是：不同来源、不同格式、不同质量、不同业务语义的资料，如何稳定地变成可检索、可问答、可治理的知识内容。
从这个角度看，解析能力不应该只是后台的一段工具代码，而应该成为知识生产基础设施的一部分。
- 默认能力保证系统可用。TorchV解析器作为基本盘，覆盖90%的文档格式解析能力，让客户不接入外部服务也能启动知识库建设，并在外部服务异常时提供回退路径。
- 外部引擎保证专项增强。复杂 PDF、扫描件、表格、图片、音频、视频等场景，可以选择更擅长的引擎，而不是用一个通用链路硬扛所有文件，AIS以插件市场的体系，可插拔架构增强产品的可扩展性，使用更灵活，扩展更聚焦和方便。
- 解析实例保证企业接入。客户自己的服务地址、密钥、模型和限流策略，可以在实例层管理，不污染知识库业务流程。
- 解析策略保证业务编排。知识库可以按文件类型、按业务场景选择解析路径；知识加工流程也可以把解析能力作为节点参与流程编排。
- 稳定性与调试能力保证可运营。限流、任务恢复、有效配置、调试预览和提交日志，让解析能力进入知识治理闭环，而不是停留在“后台跑一下”的阶段。
所以在 AIS 知识引擎里，我们没有把解析设计成一个简单的 OCR 开关，也没有把它做成“选择某个解析服务”的单一下拉框。我们把它设计成一套面向企业知识生产的解析编排架构：底层有稳定的默认解析能力，中间有可接入企业真实服务的解析实例，上层通过解析策略按文件类型和业务场景做路由，最终绑定到知识库、文件级配置和知识加工流程中。
最终，解析引擎与解析策略的价值，不是 TorchV AIS 多接了几个 OCR 或多模态模型，而是把文档解析从“固定能力”升级成了“可配置、可调试、可恢复、可运营”的知识生产基础设施。