
2026年企业数据管道基准测试报告:解析、脱敏、分块与嵌入对比
一份全面的基准测试报告,比较企业数据管道在文档解析精度、PII脱敏可靠性、分块策略和嵌入吞吐量方面的各种方法,包含方法论、结果和ML工程团队的关键发现。
企业AI团队将60%到80%的项目时间花在数据准备上。管道各阶段(解析、脱敏、分块和嵌入)的工具生态已经显 著成熟,但目前没有单一的参考标准将这些阶段作为集成工作流进行基准测试。
本报告填补了这一空白。我们使用标准化的文档语料库,在四个管道阶段评估了领先的工具和方法,测量了在生产环境中重要的精度、吞吐量和故障模式。
方法论
我们独立测试了每个管道阶段,然后作为集成管道进行测试。测试语料库包括:
- 500份企业PDF,涵盖财务报告、法律合同、医疗记录和技术文档
- 200份扫描文档,质量不等(从300 DPI清晰扫描到150 DPI退化副本)
- 150组多格式文档集(Word、PowerPoint、Excel、HTML),来自真实的企业档案
- 10,000条合成PII记录,涵盖14种实体类型(SSN、电子邮件、电话、地址、医疗ID等)
所有基准测试在单台工作站(Intel i9-13900K、64GB RAM、NVIDIA RTX 4090)上运行,以提供一致的基线。吞吐量数据反映单机性能,而非分布式处理。
阶段1:文档解析
文档解析将原始文件转换为适合下游AI处理的结构化文本。我们评估了四种方法。
解析基准测试结果
| 工具 | 表格提取 | 多栏布局 | 扫描PDF(OCR) | 页眉/页脚去除 | 速度(页/秒) | 许可证 |
|---|---|---|---|---|---|---|
| Docling (IBM) | 97.9% | 94.2% | 89.1% | 91.3% | 3.2 | MIT |
| Unstructured.io | 93.4% | 91.8% | 86.7% | 88.5% | 4.8 | Apache 2.0 |
| Marker (Datalab) | 91.7% | 96.1% | 84.3% | 85.9% | 6.1 | GPL-3.0 |
| Visual Pipeline (Ertas) | 97.9% | 94.2% | 91.4% | 93.7% | 2.9 | 专有 |
关键发现:
- Docling以97.9%的表格提取精度领先,这一数据已在IBM Research发布的DocLayNet数据集基准测试中得到验证。Ertas将Docling集成为其PDF解析引擎,继承了这一精度,同时添加了用于页眉/页脚去除和质量评分的前处理和后处理节点。
- Marker是最快的解析器,但以精度换取速度,特别是在扫描文档上,OCR质量会下降 。
- Unstructured.io提供最广泛的文件格式支持(超过64种类型),但其表格提取精度落后于Docling约4.5个百分点。
- 扫描PDF精度是所有工具中变化最大的指标。OCR质量在很大程度上取决于扫描分辨率,没有任何工具在低于200 DPI的退化扫描上始终超过92%的精度。
解析失败的常见情况
所有工具中最常见的解析失败包括:
- 嵌套表格 — 表中表在所有工具中导致了15%到30%的提取错误
- 旋转文字和水印 — 所有工具都在处理非标准方向的文字时遇到困难
- 扫描PDF中的表单字段 — 复选框和单选按钮的提取在所有工具中都不可靠
阶段2:PII脱敏
PII脱敏是合规性关键阶段。我们针对10,000个已标注PII实例的语料库测试了五种方法。
脱敏基准测试结果
| 方法 | 精确率 | 召回率 | F1分数 | 速度(文档/秒) | 误报率 |
|---|---|---|---|---|---|
| Regex模式 | 99.1% | 72.4% | 83.9% | 145 | 0.9% |
| spaCy NER (en_core_web_trf) | 91.3% | 88.7% | 89.9% | 42 | 8.7% |
| Transformer NER (GLiNER) | 94.8% | 93.1% | 93.9% | 18 | 5.2% |
| 基于LLM(GPT-4级别) | 96.2% | 95.8% | 96.0% | 2.1 | 3.8% |
| 混合管道 (Ertas) | 97.4% | 96.1% | 96.7% | 28 | 2.6% |
关键发现:
- Regex是最快且最精确的方法,但其召回率对企业使用来说不可接受——它遗漏了近28%的PII实例,主要是姓名、上下文引用和非标准格式。
- 基于LLM的脱敏达到了最高的单项精度,但比transformer NER慢14倍,且在使用云托管模型时引入了数据外泄担忧。
- 将regex用于结构化模式(SSN、电话、电子邮件)与transformer NER用于上下文实体(姓名、地址、医疗术语)相结合的混合方法,实现了精度和吞吐量的最佳平衡。Ertas使用这种混合方法,先运行确定性regex,然后对剩余实体类型运行transformer NER。
- 误报率在生产中很重要。8.7% 的误报率(spaCy)意味着近十一分之一被标记的项目实际上不是PII,给合规团队带来审查负担。
有关每种脱敏方法的详细分析,请参阅我们关于PII脱敏精度基准测试的配套文章。
阶段3:分块策略
分块决定了已解析文档如何被分割用于嵌入和检索。我们使用500份企业文档和2,000个手动标注的问答对,在RAG检索基准测试中评估了四种策略。
分块基准测试结果
| 策略 | 检索精度(Top-5) | 平均分块大小 | 上下文连贯性 | 实现复杂度 |
|---|---|---|---|---|
| 固定大小(512 tokens) | 71.3% | 512 tokens | 低 | 简单 |
| 递归字符 | 78.9% | 380 tokens | 中 | 低 |
| 语义(基于嵌入) | 84.2% | 290 tokens | 高 | 中 |
| 文档感知(标题+语义) | 87.6% | 340 tokens | 高 | 高 |
关键发现:
- 固定大小分块在生产系统中仍然常见,但始终不如其他方法。它在句子和段落中间切割,破坏了检索所依赖的上下文。
- 语义分块(在嵌入相似度下降的点进行分割)比固定大小提高了13个百分点的检索精度,但需要在分块期间进行嵌入计算——增加了计算开销。
- 尊重文档结构(标题、章节、列表边界)然后在章节内应用语义分割的文档感知分块实现了最高的检索精度。Ertas的RAG Chunker节点实现了这种方法,使用上游解析器节点提供的已解析文档结构。
- 重叠很重要。在分块之间添加10%到15%的token重叠将所有策略的检索精度提高了3到5个百分点,代价是索引大小增加。
阶段4:嵌入吞吐量
嵌入将文本块转换为向量用于相似性搜索。我们在吞吐量和检索质量方面对常见嵌入模型进行了基准测试。
嵌入基准测试结果
| 模型 | 维度 | MTEB分数 | 吞吐量(块/秒,GPU) | 吞吐量(块/秒,CPU) | 模型大小 |
|---|---|---|---|---|---|
| text-embedding-3-small (OpenAI) | 1536 | 62.3 | N/A(API) | N/A(API) | 云端 |
| text-embedding-3-large (OpenAI) | 3072 | 64.6 | N/A(API) | N/A(API) | 云端 |
| BGE-M3 (BAAI) | 1024 | 68.2 | 320 | 24 | 567MB |
| E5-Mistral-7B-Instruct | 4096 | 66.6 | 85 | 3.1 | 14GB |
| nomic-embed-text-v1.5 | 768 | 62.3 | 480 | 38 | 137MB |
关键发现:
- 对于本地部署,BGE-M3提供了最佳的质量与大小比,在本地可运行模型中取得了最高的MTEB分数,同时保持足够小巧,可以在CPU上以可接受的吞吐量进行推理。
- nomic-embed-text-v1.5是本地部署的速度冠军。仅137MB,在CPU上高效运行,为许多企业用例提供了足够的检索质量。
- OpenAI的嵌入模型需要将数据传输到云API,这使其不适用于文档必须保留在本地的受监管行业用例。
- Ertas的嵌入节点支持多种本地嵌入模型,允许团队根据其部署限制选择合适的质量-吞吐量权衡。对于隔离环境,所有处理都在本地机器上完成。
集成管道性能
孤立运行这些阶段只能说明部分情况。在生产中,故障会在各阶段之间累积——解析错误通过分块和嵌入传播,降低下游检索质量。
我们通过在500文档语料库上运行完整序列(解析、脱敏、分块、嵌入、检索)和2,000个问答对来测量 端到端管道精度。
端到端管道结果
| 管道配置 | 端到端检索精度 | PII泄漏率 | 吞吐量(文档/小时) |
|---|---|---|---|
| Docling + Regex + 固定分块 + BGE-M3 | 63.8% | 0.41% | 890 |
| Unstructured + spaCy + 递归 + nomic | 68.2% | 0.18% | 720 |
| Marker + GLiNER + 语义 + BGE-M3 | 72.1% | 0.09% | 410 |
| Ertas Visual Pipeline (Docling + 混合 + 文档感知 + BGE-M3) | 79.4% | 0.04% | 520 |
关键发现:
- 端到端精度始终低于单个阶段的精度,证实了错误传播在多阶段管道中是一个真实的问题。
- 最高吞吐量的管道(Docling + Regex + 固定分块)具有最差的检索精度和最高的PII泄漏率,展示了仅优化速度的代价。
- Ertas的集成管道实现了最高的端到端精度,因为可视化管道架构允许每个节点向下游节点传递结构化元数据(文档章节、实体位置、质量评分)——这些信息在拼接独立工具时会丢失。
- PII泄漏率(在脱敏后存活并出现在最终检索输出中的PII实例)从0.04%到0.41%不等。对于受监管行业,即使0.41%也可能是不可接受的。
建议
基于这些基准测试,我们为构建AI数据管道的企业团队提出以下建议:
-
不要以牺牲精度为代价来优化解析速度。 解析错误的下游成本远超节省的时间。Docling 97.9%的表格提取精度值得在吞吐量上做出妥协。
-
使用混合PII脱敏。 纯regex快但遗漏太多。纯LLM精确但慢且引入数据外泄风险。混合方法(regex用于结构化模式,transformer NER用于上下文实体)提供了最佳的生产权衡。
-
投资于文档感知分块。 固定大小分块易于实现,但与文档感知方法相比,检索精度低了16个百分点。
-
为受监管工作负载选择本地嵌入模型。 BGE-M3和nomic-embed-text-v1.5提供生产级嵌入,无需云API调用或数据外泄。
-
端到端测量,而非按阶段测量。 单个阶段的基准测试可能具有误导性。一个在每个阶段单独表现良好的管道,如果阶段间的交接丢失了元数据或上下文,仍可能整体表现不佳。
方法论说明
- 所有精度数字是整个测试语料库的平均值。按文档类型的方差显著(所有工具中,财务文档的解析精度高于医疗记录)。
- 速度测量排除了I/O时间,反映纯处理吞吐量。
- PII脱敏基准测试使用了NIST SP 800-188去标识化标准中定义的14种实体类型。
- 检索精度测量为针对手动标注相关段落的top-5检索块召回率。
- Ertas基准测试反映了本地运行的Data Suite桌面应用程序0.9版本。未涉及云处理。
本报告将随着工具发布新版本和基准测试语料库扩展而每季度更新。有兴趣复现这些基准测试的团队可以联系我们获取测试方法论文档。
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

PII Redaction Accuracy Benchmark: Regex vs NER vs LLM vs Hybrid Pipeline
Benchmark comparing five PII redaction approaches — regex patterns, spaCy NER, transformer NER, LLM-based, and hybrid pipeline — measuring precision, recall, F1 score, speed, and false positive rates across 14 entity types.

PDF Parsing Accuracy Benchmark: Docling vs Unstructured vs Marker vs Visual Pipeline
Head-to-head benchmark comparing PDF parsing tools for AI training data — Docling (IBM), Unstructured.io, Marker (Datalab), and Ertas's visual pipeline approach — across table extraction, multi-column layout, scanned PDFs, and processing speed.

RAG Chunking Strategy Benchmark: Fixed-Size vs Semantic vs Document-Aware
Controlled benchmark comparing five RAG chunking strategies — fixed-size, recursive, semantic, document-aware, and sliding window — across retrieval accuracy, latency, token efficiency, and best-fit use cases.