2026年企業資料管道基準測試報告：解析、脫敏、分塊與嵌入比較

企業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處理的結構化文字。我們評估了四種方法。

解析基準測試結果

關鍵發現：

• Docling以97.9%的表格擷取精度領先，這一數據已在IBM Research發佈的DocLayNet資料集基準測試中得到驗證。Ertas將Docling整合為其PDF解析引擎，繼承了這一精度，同時新增了用於頁首/頁尾移除和品質評分的前處理和後處理節點。
• Marker是最快的解析器，但以精度換取速度，特別是在掃描文件上，OCR品質會下降。
• Unstructured.io提供最廣泛的檔案格式支援（超過64種類型），但其表格擷取精度落後於Docling約4.5個百分點。
• 掃描PDF精度是所有工具中變異最大的指標。OCR品質在很大程度上取決於掃描解析度，沒有任何工具在低於200 DPI的退化掃描上始終超過92%的精度。

解析失敗的常見情況

所有工具中最常見的解析失敗包括：

1. 巢狀表格 — 表中表在所有工具中導致了15%到30%的擷取錯誤
2. 旋轉文字和浮水印 — 所有工具都在處理非標準方向的文字時遇到困難
3. 掃描PDF中的表單欄位 — 核取方塊和選項按鈕的擷取在所有工具中都不可靠

階段2：PII脫敏

PII脫敏是合規性關鍵階段。我們針對10,000個已標註PII實例的語料庫測試了五種方法。

脫敏基準測試結果

關鍵發現：

• 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檢索基準測試中評估了四種策略。

分塊基準測試結果

關鍵發現：

• 固定大小分塊在生產系統中仍然常見，但始終不如其他方法。它在句子和段落中間切割，破壞了檢索所依賴的上下文。
• 語意分塊（在嵌入相似度下降的點進行分割）比固定大小提高了13個百分點的檢索精度，但需要在分塊期間進行嵌入計算——增加了運算開銷。
• 尊重文件結構（標題、章節、清單邊界）然後在章節內套用語意分割的文件感知分塊實現了最高的檢索精度。Ertas的RAG Chunker節點實作了這種方法，使用上游解析器節點提供的已解析文件結構。
• 重疊很重要。在分塊之間新增10%到15%的token重疊將所有策略的檢索精度提高了3到5個百分點，代價是索引大小增加。

階段4：嵌入吞吐量

嵌入將文字塊轉換為向量用於相似性搜尋。我們在吞吐量和檢索品質方面對常見嵌入模型進行了基準測試。

嵌入基準測試結果

關鍵發現：

• 對於本地部署，BGE-M3提供了最佳的品質與大小比，在本地可執行模型中取得了最高的MTEB分數，同時保持足夠小巧，可以在CPU上以可接受的吞吐量進行推論。
• nomic-embed-text-v1.5是本地部署的速度冠軍。僅137MB，在CPU上高效執行，為許多企業用例提供了足夠的檢索品質。
• OpenAI的嵌入模型需要將資料傳輸到雲端API，這使其不適用於文件必須保留在本地的受監管行業用例。
• Ertas的嵌入節點支援多種本地嵌入模型，允許團隊根據其部署限制選擇合適的品質-吞吐量權衡。對於隔離環境，所有處理都在本地機器上完成。

整合管道效能

孤立執行這些階段只能說明部分情況。在生產中，故障會在各階段之間累積——解析錯誤透過分塊和嵌入傳播，降低下游檢索品質。

我們透過在500文件語料庫上執行完整序列（解析、脫敏、分塊、嵌入、檢索）和2,000個問答對來測量端到端管道精度。

端到端管道結果

關鍵發現：

• 端到端精度始終低於單個階段的精度，證實了錯誤傳播在多階段管道中是一個真實的問題。
• 最高吞吐量的管道（Docling + Regex + 固定分塊）具有最差的檢索精度和最高的PII洩漏率，展示了僅優化速度的代價。
• Ertas的整合管道實現了最高的端到端精度，因為視覺化管道架構允許每個節點向下游節點傳遞結構化中繼資料（文件章節、實體位置、品質評分）——這些資訊在拼接獨立工具時會遺失。
• PII洩漏率（在脫敏後存活並出現在最終檢索輸出中的PII實例）從0.04%到0.41%不等。對於受監管行業，即使0.41%也可能是不可接受的。

建議

基於這些基準測試，我們為建構AI資料管道的企業團隊提出以下建議：

1. 不要以犧牲精度為代價來優化解析速度。 解析錯誤的下游成本遠超節省的時間。Docling 97.9%的表格擷取精度值得在吞吐量上做出妥協。

2. 使用混合PII脫敏。 純regex快但遺漏太多。純LLM精確但慢且引入資料外洩風險。混合方法（regex用於結構化模式，transformer NER用於上下文實體）提供了最佳的生產權衡。

3. 投資於文件感知分塊。 固定大小分塊易於實作，但與文件感知方法相比，檢索精度低了16個百分點。

4. 為受監管工作負載選擇本地嵌入模型。 BGE-M3和nomic-embed-text-v1.5提供生產級嵌入，無需雲端API呼叫或資料外洩。

5. 端到端測量，而非按階段測量。 單個階段的基準測試可能具有誤導性。一個在每個階段單獨表現良好的管道，如果階段間的交接遺失了中繼資料或上下文，仍可能整體表現不佳。

方法論說明

• 所有精度數字是整個測試語料庫的平均值。按文件類型的變異顯著（所有工具中，財務文件的解析精度高於醫療記錄）。
• 速度測量排除了I/O時間，反映純處理吞吐量。
• PII脫敏基準測試使用了NIST SP 800-188去識別化標準中定義的14種實體類型。
• 檢索精度測量為針對手動標註相關段落的top-5檢索塊召回率。
• Ertas基準測試反映了本地執行的Data Suite桌面應用程式0.9版本。未涉及雲端處理。

本報告將隨著工具發佈新版本和基準測試語料庫擴展而每季度更新。有興趣重現這些基準測試的團隊可以聯繫我們取得測試方法論文件。