非结构化数据解析与GenAI应用：新手入门到专家进阶实战完全指南

一、前言

展开的话题，从一组看似杂乱的数据入手——非结构化数据。

RAG结合大模型的技术路线走热后，大模型在文本处理上的表现确实令人印象深刻。但在实际企业应用里，大约80%的时间都在处理非结构化数据。从各类Office文档到图片、音频，格式繁多。正是大模型的出现，让这些过去难以被程序高效抓取和理解的数据真正“激活”，在内容检索、语义理解和二次利用上显著提升了效率。

本次分享重点覆盖三个板块：

• 第一，非结构化数据处理。做RAG产品，这条路基本从数据解析起步。这部分会聊技术中间件选型，以及PDF表格解析等实操细节。
• 第二，企业AI场景的落地应用。结合产品实践，分享我们的探索与思考。
• 第三，总结与个人体会。

二、非结构化数据的解析难点与细节

基于RAG进行技术栈开发时，首道难关就是非结构化数据的解析。需要将多种格式的数据转化为文本，再通过检索与Prompt设计，让大模型完成推理与生成，最终解决企业工作中的真实痛点。这个过程挑战不少：

• 文件种类极其繁杂，覆盖面广。
• 老旧文件的支持难题，例如DOC、XLS、PPT等历史格式。
• 表格解析是公认的“硬骨头”。
• OCR的触发时机，需在成本、效率、性能之间反复权衡。
• PDF中布局识别能力的突破。
• 文件字符编码问题等。

实际开发中，细节远不止这些。以PDF为例，仅1.7规范就接近800页，想全部啃完再完美解析，几乎不现实。

在TorchV的整个技术架构中，Java占比接近80%，包括文件解析与内容提取。这一点与市面上常见的开源方案有所不同。

在Java生态里，针对上述文件解析问题，三个Apache中间件表现抢眼，在RAG场景中扮演关键角色。

• Apache POI：2002年进入Apache基金会。初期主要处理Excel电子表格，后逐步支持Word、PPT、Visio等多种格式。POI最大的优势在于对老旧文件的友好支持，像DOC、XLS、PPT等，可以直接解析提取文本，无需依赖外部插件或中间件。相比之下，Python生态处理Office文件时，如解析docx，通常需要先将doc转为docx再提取，依赖较多。Java凭借多年积累，在这方面明显更扎实。实际对接大客户时，老旧文件的占比确实不低。
• Apache Tika：一个综合性文件解析项目。最初作为Apache Nutch的一部分，2007年独立成为顶级项目。Tika封装了POI、PDFBox等依赖，能通过识别文件的魔数自动判断文件类型，并提供标准输入流和转换方法。它还集成了OCR功能，解析文件时遇到图片资源会自动调用OCR提取。
• Apache PDFBox：开源领域相当成熟完善的PDF处理中间件。2008年进入Apache基金会，对PDF规范支持全面，提供高级抽象接口，方便开发者进行自定义扩展。

在整个非结构化数据提取过程中，这三个Apache项目基本能覆盖80%的业务场景。虽然直接用大模型识别文件听起来很酷，但在企业落地时，文件解析仍需从成本、性能、效率多个维度权衡。基于规则的提取在可解释性上往往更具优势。

从实际支持的格式来看，这三个中间件覆盖了HTML、Office、PDF、图片、音频、压缩包等，企业应用完全够用。

在所有文件格式中，PDF无疑是开发者最头疼的，表格提取尤为棘手。借助Apache PDFBox，目前有两种高效方法可以提取表格内容，还原表格结构。

第一种：Tabula组件。基于PDFBox文本坐标提取的开源算法。通过提取全部文本坐标，再经边界计算、文字边界连接等步骤，利用水平和垂直坐标系明确单元格边界，最终完整还原表格。这种方法对老式电子文件PDF非常有效，因为早期PDF规范中并未纳入表格的线、矩阵等元素。而在新规范中，内容流大多已存储这些坐标信息。

第二种：提取PDF内容流的线坐标与矩阵信息。基于PDFBox，提取所有矩形和线的坐标，再通过算法处理，包括空间去重、冗余排除、矩阵坐标连接等，即可像图示那样完整勾勒出表格。确定矩阵坐标后，再基于单元格坐标判断合并情况，明确是否需要纵向或横向合并。最终通过PDFBox按区域提取的方法，可精准抓取每个单元格的内容，实现表格的完整还原。

基于坐标信息，还能拓展很多内容，后续案例会提到。

基于上述表格提取方式，PDFBox的整体UML架构如下图所示：

最顶层是PDF的基础引擎类。PDF规范中包含大量Operator操作，而基于坐标、图片等信息的提取，都是通过扩展这些Operator实现的。第二个引擎类专门用于提取内容流中的线、矩阵、图片等信息。最后是按文本坐标区域提取的核心类，这个方法非常实用，尤其在处理论文型PDF的双排排版时，经过大量实验验证，对文本排版空间的计算提取都很高效。

三、应用探索与实践

场景一：知识库。这是大模型兴起后最普遍、也最容易落地的领域。借助大模型强大的文本理解能力，通过多种手段将非结构化数据解析提取后，结合向量KNN等新一代搜索技术，可以更精准地检索数据库中的文本内容。大模型作为“润滑剂”理解用户意图，最终输出符合预期的答案。在与客户深入交流过程中，感觉知识库有点像AI时代的数据中台——做好它，能让企业把AI能力真正用起来。这包括企业非结构化数据和知识的统一管理；通过PC、Web等不同途径促进知识协同与分享；让冷冰冰的数据从数据库中“活”起来，发挥再利用价值。

场景二：研报助手Assistant。

这本质是一个富文本编辑器。大模型在文本生成上已经很擅长，输出效率比过去提升了数倍。但在企业严谨的场景下，模型输出有时会产生幻觉。RAG正是目前控制幻觉输出的理想技术手段，让模型基于给定的文本内容进行总结。Assistant结合了非结构化文本解析、向量检索、大模型归纳和富文本编辑器等多种技术。用户上传文档后，系统在文档内检索生成，特别适合需要严谨引用报告或大量文档阅读的场景，能极大提升编写效率。生成的文本还可以快速转换成饼图、柱状图、表格等不同图表形式。

场景三：规则匹配场景Comparison。

这一场景主要依赖之前处理PDF表格的方法，可以根据区域信息无差别地提取关键字段。如果PDF是扫描版，会通过OCR进行区域信息提取，结合坐标空间相关算法将框定内容提取出来。此外，非结构化数据提取后，可以配合大模型的Agent能力，针对特定领域按规则提取关键信息。数据提取后，在应用层无论是校对还是总结，AI都能高效发挥作用，提升整体效率。

四、个人感想

第一个感想：AI技术栈很杂，是挑战，也是机遇。

要把RAG、大模型、向量检索这些技术栈真正落地，涉及的技术面非常广且杂。开发者不仅要关注数据处理，还要涉及检索、向量数据库、大模型Agent、Prompt、微调等多个领域。打造一个标准化产品并不容易，对企业和开发者都是不小的挑战。但正因为有了AI大模型，今天的工作场景中涌现出很多有趣的应用和产品，这其中蕴藏着巨大机遇。在AI的加持下，开发者可以更大胆地畅想，这对探索和创新很有帮助。

第二个感想：数据质量是基石，重剑无锋。

数据质量是文本类AI应用的基石。无论是做RAG还是微调模型，在构建开发TorchV的过程中，大约80%的时间都花在了“怎样把数据处理好”这件事上——幂等地将非结构化数据最大化提取和还原。这一步非常关键。RAG领域有句经典名言：Garbage in, Garbage out。所以，数据质量始终是必须着重关注的核心。

来源：互联网