异构文档 AI 整合的检索速度测试

上个月我们团队在做文档检索系统优化的时候，遇到了一个特别有意思的问题。公司内部同时存在着大量的 Word 文档、PDF 报告、Excel 数据表格，还有从老系统里导出来的 CSV 文件。这些文档格式各异，内容结构也完全不一样，以前我们都是分开处理、分库存储的。后来引入了 AI 技术，想做一个统一的智能检索入口，让用户不管存什么格式的文件，都能用自然语言快速找到想要的内容。

但理想和现实之间总是有差距的。测试初期我们发现，同一个问题用不同格式的文档来问，AI 返回结果的速度能相差十几倍。这篇文章就想聊聊，我们是怎么测试异构文档在 AI 整合环境下的检索速度的，以及测试过程中发现的一些有意思的规律。

什么是异构文档，为什么测试它这么麻烦

在说测试方法之前，先解释下什么叫异构文档。简单点讲，就是那些"长得不一样"的文档。Word 文档有段落、有标题层级、有插入的图片和表格；PDF 呢，有些是扫描件转的，根本没有文字图层，只有图像；Excel 每个格子都可能藏着数据，结构扁平但信息密度高；还有 JSON、XML 这种机器可读但人类看起来吃力的格式。

把这些不同格式的文档交给 AI 处理，相当于让一个翻译同时去翻译一本精装书、一张皱巴巴的手写纸条、一张满是数字的表格和一段加密的电报。翻译的速度和质量，肯定不可能一样对吧？我们做检索速度测试，本质上就是在测量这个"翻译 + 搜索"全过程的时间消耗。

测试环境的搭建

测试环境我们用的是 Raccoon - AI 智能助手这个平台，选择它的原因主要是可以灵活配置文档解析模块和向量数据库，方便控制变量。整个测试环境包括三个核心部分：文档预处理服务器负责把各种格式的文件转成统一的文本表示；向量引擎负责把文本转成数学向量并存入数据库；查询服务负责理解用户问题、匹配相关文档、返回结果。

我们准备了 500 份测试文档，涵盖五种常见格式。每种格式 100 份，内容包括技术手册、财务报表、会议纪要、产品说明和合同模板。文档大小从几十 KB 到几十 MB 不等，这样能测试出文件大小对检索速度的影响。测试用的查询语句有 50 条，混合了简单的事实类问题和复杂的多跳推理问题。

测试硬件配置

为了保证测试结果的可参考性，我们没有用特别高端的服务器配置，而是选择了一个中等水平的云主机，这在中小企业里算是比较典型的部署环境。

这个配置不算低，但对于需要同时处理大量文档解析和向量计算的场景来说，也算不上宽裕。我们刻意没有把配置拉满，就是想看看在资源有限的情况下，各类型文档的检索表现会是什么样。

测试方法论

测试方法这块我们花了不少心思。一开始想的就是简单测个平均响应时间，但后来发现这样不够，得把整个检索链路拆开来看，才能找到真正的瓶颈在哪里。

我们把一次完整的检索过程分成了四个阶段。第一阶段是文档解析，就是把 PDF、Word 这些文件读出来，提取出纯文本内容。第二阶段是文本分块，因为文档通常比较长，需要切成小块才能准确匹配用户问题。第三阶段是向量化，把文本块转成向量存进数据库。第四阶段是查询匹配，把用户问题转成向量，然后在一堆向量里找出最相似的那些。

测试的时候，我们用脚本分别记录了每个阶段的耗时，然后汇总分析。对于同一种文档格式，我们会做三次完整测试，取平均值，就是为了排除偶然因素的干扰。另外，我们还做了并发测试，模拟 10 个用户同时发起查询的情况，看看系统在负载下的表现。

核心测试结果

各格式文档的解析速度对比

测试结果出来之后，有些发现和我们之前想的不太一样。先说文档解析阶段，这个阶段最吃文档格式的"复杂程度"。

Word 文档的解析速度是最快的，平均每 MB 耗时 0.3 秒左右。这不难理解，毕竟 Word 就是微软亲儿子设计的格式，解析库成熟，结构也相对规范。PDF 就有点让人头疼了，普通版本的 PDF 解析速度还能接受，每 MB 大概 0.8 秒，但那些加了数字签名或者全是扫描件的 PDF，解析耗时能飙升到每 MB 3 秒以上。最离谱的是一个 50 页的扫描版合同，解析它整整用了 4 分钟。

Excel 表格的解析有点特殊。它解析起来不快，每 MB 差不多要 1.2 秒，但因为 Excel 的结构比较规整，解析完之后文本分块反而更省事。CSV 就是纯文本，解析速度介于 Word 和 PDF 之间，但它没有格式信息，有时候分块会出问题，把一个表格的单元格内容给切断了。

检索阶段的性能差异

文档解析完之后，后面的向量化步骤其实各格式差别不大，都是把文本转成向量，耗时主要和文本长度有关。但查询匹配阶段就体现出差异了，主要是因为不同格式解析出来的文本，在内容密度和信息结构上有区别。

举个具体的例子。我们问了一个问题："去年 Q3 的销售额是多少？"这个问题在财务 Excel 里的答案位置很明确，解析完整的话，匹配准确率能达到 96%，平均响应时间 0.8 秒。但同样的问题，如果是问一份混在 Word 报告里的财务小结，有时候 AI 找不到精确数字，会返回一段相关的描述文字，响应时间反而更长，因为要算更多的向量相似度。

扫描版 PDF 在这个阶段的表现最让人无语。OCR 解析偶尔会认错数字，比如把"3"看成"8"，把"100万"识别成"100万"——看起来差不多，但对机器来说是完全不同的向量。结果就是检索出来的结果看似相关，其实答非所问，用户得多看几条才能找到真正需要的答案。

并发场景下的表现

并发测试这块，我们模拟了 10 个用户同时发起查询的情况。测试前我们预计，系统性能会有所下降，但没想到各格式之间的差距在并发时会被放大。

Word 文档在并发时性能下降相对温和，响应时间从单用户的 0.8 秒上升到 1.4 秒，大概涨了 75%。PDF 的表现就不太稳定了，尤其是扫描版 PDF，因为 OCR 解析本身就很耗 CPU，并发一上来，CPU 使用率直接飙到 95% 以上，响应时间从单用户的 2.5 秒飙升到 6 秒多，用户体验明显变差。Excel 和 CSV 在并发时表现中规中矩，主要是内存占用会增加，但响应时间涨幅控制在可接受范围内。

影响检索速度的关键因素

测了一圈之后，我们总结出几个影响异构文档检索速度的关键因素，按重要性排个序。

• 文档格式复杂度：这绝对是第一位的。格式越复杂，解析阶段消耗的资源越多，扫描版 PDF 这种需要 OCR 的格式，解析耗时是原生文档的十倍以上。
• 文档大小：这里说的是内容大小，不是文件体积。一个 10MB 的图片型 PDF 和一个 10MB 的纯文字 PDF，解析时间能相差几十倍。图片越多，需要 OCR 的部分越多，速度就越慢。
• 内容结构规整度：这个因素被很多人忽略。Excel 这种结构化程度高的格式，解析出来再分块反而很快；Word 文档如果标题层级清晰，也有助于准确切分。最怕的是那种全文堆在一起，连分段都没有的文档，分块算法很容易失效。
• 向量数据库的选择：不同的向量数据库在处理大规模数据时的性能差异挺大的。有些数据库针对高维向量做了优化，查询速度能快好几倍。
• 模型推理效率：把用户问题转成向量，以及把文档 chunk 转成向量，这两个步骤的效率直接影响整体响应时间。有没有 GPU 加速，差别挺明显的。

优化建议和实战经验

基于这次测试，我们针对 Raccoon - AI 智能助手的异构文档检索能力做了几项优化，效果还挺明显的。

首先是文档预检机制。在用户上传文档的时候，系统会先快速扫描一遍，识别出那些可能是扫描版的 PDF 或者图片为主的文档，给用户一个提示，说明这类文档解析可能会比较慢，或者建议用户先做个 OCR 预处理。这个小功能上线之后，用户抱怨明显少了，因为有心理预期了。

然后是分块策略的动态调整。以前我们用统一的分块策略，所有文档都切成 512 字符的块。现在系统会根据文档类型自动调整：结构化的文档用较大的块，减少碎片化；非结构化的文档用较小的块，提高检索精度。调整之后，复杂格式文档的检索准确率提升了大概 12%。

还有就是缓存机制的引入。对于热门文档和高频查询，我们会把解析后的向量结果缓存起来。用户第二次查询同样问题的时候，直接从缓存里取，响应时间能从 2 秒降到 0.3 秒。当然缓存管理也需要成本，我们设置了一个 7 天的过期策略，平衡性能和资源消耗。

一些没想到的发现

测试过程中有几个发现，是一开始没预料到的。

一个是关于文档数量的临界点。我们在测试时发现，当文档总量超过 2000 份的时候，检索速度开始明显下降，尤其是复杂格式文档多了之后，向量数据库的查询延迟会非线性增长。这提示我们，在实际部署时需要做好数据分片或者索引优化，不能让数据量无限膨胀。

另一个是关于中文的特殊性。中文文档的分词是个老问题，但我们发现不同解析库对中文的处理差异挺大的。有些库能把中文句子切得很准确，有些库则会乱切一气，导致分块错误率高，进而影响检索质量。这个问题在英文文档测试中就没那么突出。

还有一个有意思的现象。用户上传文档的时间也有影响。下午三点上传的文档和凌晨两点上传的文档，在后续查询时表现有细微差异。分析了下原因，可能是系统负载的关系——白天高峰期资源紧张，文档解析的质量会稍微打点折扣。

写在最后

做这个测试最大的收获，是认识到异构文档的检索速度优化真的不是"调一个参数就能搞定"的事。它涉及到文档格式解析、内容结构理解、向量表示、数据库查询一整套链路的协同配合。每一个环节都可能成为瓶颈，每一个环节也都有优化空间。

如果你也在做类似的事情，我的建议是先别急着优化，先做好完整的测试，把各阶段的耗时都拆解清楚，知道瓶颈在哪里之后再针对性地下手。盲目调参数很容易调了个寂寞，把时间浪费在不重要的地方。

对了，测试用的这 500 份文档和 50 条查询语句，我们整理成了一个标准测试集，后续有需要的话可以复用。异构文档的 AI 整合这条路，大家都是在摸索中前进，多交流经验总是好的。