AI应用开发：创新实现非结构化文档分析系统，避免传统方式的局限性

2025年7月5日
| 没有评论

作者：佘俊志，北京理工大学研究生

大数据时代的非结构化数据存储与分析挑战

大数据时代，非结构化数据存储需求增大，IDC 报告显示现有的非结构化数据占比超过92.9%，新的数据存储范式应运而生。

对于非结构化文档的存储和分析需要用到大模型的属性抽取能力。在实际业务场景中，企业会积累大量格式各异、内容复杂的产品开发文档、日志、报告、合同、病历等非结构化数据。这些数据直接存储和检索难度较大，而通过大模型进行属性抽取，将关键信息结构化后进行高效存储和检索，成为当前企业数据管理与智能化运营的迫切需求。例如，上述运维日志、产品开发文档、简历、病历、财报等典型场景，均属于非结构化文档，亟需结构化抽取和分析。

当前，非结构化文档存储与分析能力已成为AI应用在企业数据智能化场景下的重要基础支撑，直接关系到智能搜索、自动化报表、风险监控等下游应用的效果与效率。然而非结构化文档存储和分析正面临四个挑战：

  1. 组织和存储难。文档格式多样、分块边界模糊、元数据管理困难导致组织和存储困难。
  2. 需适应多种查询需求。过滤器中同时包含稀疏向量匹配、稠密向量匹配、标量过滤，多种混合检索需求难以满足。
  3. 难以高效分析。低延迟( LLM 算子)：复杂查询可能涉及基于 LLM 的语义操作符，效率和延迟的优化难以保障。
  4. 水平扩展和增量更新难度大。文档数量动态增长，增量维护索引困难。

面对上述挑战，现有的数据存储方式虽然在各自的应用场景中都具有优势，但也存在不足，难以支撑非结构化文档智能分析系统所需的能力。

  • 传统关系型数据库：应用于结构化数据的存储与管理，适用于业务表单、固定事务处理、电子发票等数据结构稳定、关系清晰的场景，优点是拥有较强的ACID事务支持，成熟稳定，但对非结构数据支持很弱。
  • 数据湖（Data Lake），应用于大规模原始数据资产化，存储原始非结构化数据，存储成本低、查询速度慢。
  • 分析功能少。
  • 数据仓（Data Warehouse），应用于利用预处理好的规范数据进行核心业务决策支持，存储处理后的（半）结构化数据，存储成本较高、查询速度较慢、分析功能较多。
  • 向量数据库（Vector Database），应用于AI实时推理场景，存储向量数据，存储成本高、查询速度快，且仅支持向量相似查询。

可见，要应对非结构化数据的存储与分析挑战，需要存储方式至少具备以下特性：

  • 较强的ACID事务支持；
  • 性能较高的SQL查询与分析；
  • 支持非结构化数据；
  • 高扩展性与灵活性；
  • 存储成本低；
  • 完善的索引和精确查询；
  • 丰富的AI生态集成；

基于OceanBase构建非结构文档智能分析系统——QUEST

目前市面上能够有效应对非结构化数据存储与分析挑战的存储方式并不多，OceanBase可谓其中之一，因此，我们基于OceanBase开发了AI数据库应用——QUEST。帮助企业自动完成非结构化数据的解析、结构化和分析，提升数据利用率，解决信息孤岛问题。

（一）传统方法的局限性

以产品开发文档为例，企业的数据湖中往往沉淀着大量长篇的非结构化文档。理论上，这些文档可以通过抽取形成一张“属性-文档”二维表，每行对应一个文档，每列对应一个属性。但在实际应用中，存在如下挑战：

  • 海量数据，查询聚焦：每次用户查询往往只关注文档集合中的极少部分文档，并且感兴趣的属性通常只出现在文档的少量文本块中。即“needle in the sea”式的需求。
  • 属性需求动态变化：用户的查询属性难以一次性预定义，且随着业务演变不断变化。

因此，如何高效应对属性和文档的动态筛选、快速在线抽取，成为传统系统难以克服的技术瓶颈。

当前主流的属性抽取系统，通常采用全量抽取的方式：每当遇到新的查询属性时，系统会针对文档集合中的每一份文档进行一次全面的属性抽取。这种做法带来了如下局限：

  • LLM Token成本高：大规模的全量抽取极大消耗LLM的token资源，运算与运营成本居高不下。
  • 过滤机制低效：用户的查询往往只关心少量文档，但全量抽取无法充分利用filter（如SQL where子句）带来的聚焦效果，浪费大量计算资源在无关文档上。
  • 应对动态查询的能力不足：用户对属性和分析需求经常发生变化，传统全量抽取方法难以及时响应，每次新增属性都要重复扫描全体文档，效率极低。

（二）新兴研究的局限性

近年来，DocETL、Evaporate等系统尝试改进传统做法，提出了“先filter再抽取属性”的优化路径和工作流设计方法，致力于减少无效抽取操作。

与传统数据库相比，非结构化文档属性抽取系统中的filter算子在实现和开销上有明显区别。

具体而言，在非结构化文档属性抽取系统中，filter的执行往往也依赖于属性值的抽取。也就是说，系统必须先从每个文档中抽取出相关属性的值，才能在SQL查询中进行关系代数的判断。

因此，对于复杂SQL语句，尤其是带有多个filter条件的场景，如果filter中涉及的新属性未能命中已有缓存，系统还需额外进行大量的在线抽取。这种“为过滤而抽取”的过程极大增加了LLM的消耗和整体处理成本；此外，join操作也可以视为filter的一种形式，其过程也涉及参与join的列的属性抽取，且join操作本身可以过滤掉表中的一些列。而新兴研究对filter和join等关键算子的协同排序和优化做得不够完善，所以在面对带有多个filter的复杂SQL查询时能力仍有不足。

（三）QUEST系统的创新优化

针对上述问题，QUEST系统做了全方位的优化，具体包括以下四点。

  • 基于采样的选择性评估：对采样文档进行抽取得到“采样表”，可用于估计任意filter的选择性，实现更智能的筛选策略。
  • LLM Token Cost预估：通过对RAG（Retrieval-Augmented Generation）方式获得的属性相关文本块长度统计，精准预估LLM处理成本，结合选择性指标合理排序filter优先级。
  • filter与join协同排序优化：QUEST将join操作转化为IN操作，与被join表中的filter一起进行排序，从而最大程度利用过滤机制，优先排除无关（非热点）文档，极大减少无效抽取操作。
  • 上下文精准定位与RAG加持：QUEST利用RAG技术，精准定位待抽取属性所在的上下文，不必将整个文档传给LLM，大幅缩短上下文长度，不仅提高了抽取准确率，也进一步降低了成本。

（四）QUEST系统的设计与实现

OceanBase for QUEST 系统的原型设计来源于我们在顶级国际会议上发表的论文，该论文获得了2025年 sigmod 的 strong accept 评价。首先我们来看一下系统的整体框架。

从上图可见，OceanBase 在系统中主要参与第一步、第二步中的二级索引建立与检索过程，也就是图中标出来的四个圆圈。 整体流程的第一步是离线构建文档级索引和分块级的索引，即对每一个原始文档进行分块处理，然后把分块存到对应的数据库表中。

第二步是在线 SQL 查询，一共包括5项流程：

  1. 采样部分文档。LLM 从中抽取用户查询 Q 中出现的属性来生成采样表 S，用于查询增强和优化。
  2. 文档检索。Q 文档主题+文档索引: 过滤无关文档。
  3. 分块检索。(Q 属性名,S-Evidence ) + 分块索引:，获得与属性相关的分块。
  4. 系统根据采样表 S 中属性的选择性和属性相关分块的 token 总数，生成优化的执行计划。
  5. 系统按照计划逐个处理文档，调用 LLM 从相关文本块中抽取出现在 Q 中的属性并缓存。

简单总结来说， QUEST 将对非结构化文档的查询转换为对查询相关属性的抽取和优化任务。

下面是我们利用 OceanBase 在处理流程中的操作细节，首先我们需要把文档的分块二级索引存储在 OceanBase 的二维表中。对于文档表，我们存储文档 ID、文档内容、文档总结、文档总结嵌入向量、文档标题；对于分块表，我们存储分块 ID、分块内容、分块嵌入向量、分块所属的文档 ID。

在二维表建立后，需要分别构建文档索引和分块索引。

  • 文档索引构建：documents 表。

    • 对 summary_embedding 建立稠密向量索引（hnsw 语义- 相似度)。
    • 对 content 建立稀疏向量索引（BM25 关键词匹配)。
    • 针对 title 等 metadata 建立标量索引。
  • 分块索引构建：text_chunks表。

    • 对 embedding 建立稠密向量索引（hnsw 语义相似度)。

    • 对 content 建立稀疏向量索引 ( BM25 关键词匹配)。

    • 针对 doc_id 等 metadata 建立标量索引。

举一个简单的例子，假设查询是 SELECT age, name, team FROM NBAPlayer WHERE age>30 系统要处理这个查询，就要先从文档中抽取出过滤器 WHERE age>30 中的 age 属性，再进一步从符合条件的文档中提取 name、team 属性。那么，如何用 OceanBase 找出每个文档中 age 相关的文本块，从而送给 LLM抽 取？

对于文档表，用单词”NBA”进行全文检索，再用表名 NBAPlayer 嵌入得到的 alpha 向量进行语义相似度检索，从而返回主题为 NBAPlayer 的文档，过滤掉无关文档。

对于分块表，限定 doc_id 进行标量检索，用单词“age”和“birthdate”进行全文检索，再用属性名 age和 age 附加的 Evidence 描述进行语义相似度检索，从而实现从一篇特定的文档中抽取与 age 相关的文本块的功能。

上述功能是 QUEST 系统的核心操作之一，OceanBase 帮助我们以优雅的方式实现了这一点。QUEST 系统的实验效果：

为了测试QUEST 系统的效果，我们在 WikiText、SWDE、LCR 几个数据集上进行了实验，其中 LCR 是法律数据集、SWDE 是影视相关的数据集，然后与其他领域内比较领先的非结构化文档分析系统进行了比较，发现 QUEST 系统在准确率、成本、延迟方面都明显优于其他系统。

为什么 OceanBase 能支撑AI应用准确率更高、成本更低、延迟较短？

那么，为什么 OceanBase能够应对非结构化文档存储与分析的挑战，帮助我们实现准确率更高、成本更低、延迟较短的 QUEST 系统呢？

1.一体化数据库 for AI。

相比于传统的单一存储范式，OceanBase 是一体化数据库，它将不同存储范式的优点集成在一起，较市面上独立的向量数据库能更好地应对非结构化文档存储和分析的挑战。

2.出色的向量检索性能。

对于 AI 应用开发而言，OceanBase 具备出色的向量检索性能，下图为向量数据库查询 Benchmark 压测的结果，来自于 OceanBase 2025开发者大会现场测试。从图中可以看出，OceanBase 每秒执行的向量查询次数远高于其他的主流向量数据库。

3.多模一体化混合检索：稠密向量+稀疏向量+标量。

OceanBase 支持多模一体化的混合检索，用户在一条查询语句中可以同时使用稠密向量、稀疏向量和标量三种过滤器。

4.SQL-Python 开发接口。

OceanBase 向量检索提供灵活的访问接口，不仅支持通过 MySQL 协议的各种语言客户端使用 SQL 访问，也可以使用 SDK 访问（例如 Python），带来简单高效的 AI 应用开发体验。

5.主流 AI 框架集成。

OceanBase 集成了主流的 AI 框架和服务，例如 LangChain、Llamalndex、Dify、Fast-GPT 等，同时兼容标准的 MCP 协议，可以在 AI 应用开发的各种场景中为开发者提供较好的平台和框架，打通开发流程。

6.强大的开源社区支持。

OceanBase 社区拥有活跃的共建氛围和强大的官方支持。而且社区成员积极参与不同细分领域的特别兴趣组 OceanBase SIG（Special Interest Group）进行技术共建，甚至每周开会讨论开发需求与计划，促进成员之间的交流、提升开发效率。

总结与展望

QUEST系统特别适用于企业级大规模数据湖、知识管理、合规文档抽查、产品研发资料整理、合同审核等复杂场景，帮助用户在“只关心少量文档和属性”的动态需求下，低成本、高效率、智能化地完成在线属性抽取与分析。

后续，我们将在QUEST 系统增加对带有图片的多模态文档的查询支持，这就要求我们将图片存储到 OceanBase中。由于 OceanBase 良好的多模一体化接口设计，我们针对图片的存储和索引预期设计与针对文本的设计差不多，这充分体现了 OceanBase 在 AI 应用开发中的优势。

经过我们的试验，基于 OceanBase 开发AI应用的优点主要有三点：支持一体化数据库范式、原生支持分布式扩展，具有良好的产品生态。此外， OceanBase 能实现存算一体的查询和存储操作，无需开发者编写额外的查询引擎，大大加速了我们的应用开发。

OceanBase 作为 AI 时代的数据底座，为 RAG 和 Agent 的应用提供高质量、可扩展、易查询的数据源。我们相信 OceanBase 未来能在 AI 应用领域发挥出更大的价值。

老纪的技术唠嗑局 不仅希望能持续给大家带来有价值的技术分享，也希望能和大家一起为开源社区贡献力量。如果你对 OceanBase 开源社区认可，点亮一颗小星星 吧！你的每一个Star，都是我们努力的动力～

https://github.com/oceanbase/oceanbase

flask, python, tornado, 人工智能AI