為什麼你的 RAG 管道會在客戶上傳的資料上失效（以及如何修復）

RAG 檢索上游的資料品質問題是這樣的：你的管道是在乾淨、格式規範的文件上建構和測試的——而你的客戶上傳的是其他所有東西。格式錯誤的 PDF、編碼錯誤、含有 PII 的文字、重複內容和格式不一致會靜默降低檢索品質，而不會拋出錯誤。RAG 系統看起來在運作；只是返回了更差的答案，引用了被污染或冗餘的來源，卻沒有任何跡象表明有什麼問題。

客戶資料破壞 RAG 的五種方式

1. 格式錯誤的 PDF

並非所有 PDF 都是平等的。常見的失效模式：

• 零位元組或截斷檔案：在上傳或傳輸過程中損毀的 PDF。解析器靜默失敗或返回空的擷取內容。
• 受密碼保護的 PDF：需要解密才能解析的檔案。沒有預先篩查，這些檔案在沒有提供資訊性錯誤的情況下就會失敗。
• 內容串流損毀的 PDF：看起來有效但包含格式錯誤內部結構的檔案。解析器可能擷取部分內容，產生出現在檢索中但無法回答任何真實問題的片段。
• 僅有圖像內容且沒有 OCR 層的 PDF：在傳統掃描檔案中很常見。沒有 OCR，就不會擷取文字——文件以零長度或近零長度的塊進入向量存儲，能被檢索到但不提供任何資訊。

一個沒有預先篩查就攝取 50,000 份客戶文件的 RAG 系統，可能有 5–15% 的文件處於損毀狀態。這些失敗都不會以系統錯誤的形式出現；它們以降低的檢索品質出現。

2. 編碼問題

企業文件檔案在多年的系統遷移過程中積累了編碼不一致性。常見問題：

• 單批次中的混合編碼：UTF-8、Windows-1252 和 ISO-8859-1 檔案在同一次上傳中共存。在 UTF-8 文字上訓練的嵌入模型對非 UTF-8 輸入產生降級的嵌入。
• 亂碼：錯誤編碼的字元顯示為亂碼文字（’ 替代 '，é 替代 é）。這些會破壞文件的語意內容，導致嵌入模型產生無法準確代表文件含義的嵌入。
• 空位元組和不可列印字元：傳統資料庫匯出或某些文件轉換工具引入空位元組和控制字元。這些以不可預測的方式破壞文字分塊邏輯。

編碼問題特別有害，因為它們看起來像內容。一個到處都是 é 的文件會被嵌入、分塊和檢索——但嵌入與使用正確字元的查詢不會對齊。

3. 重複內容

客戶文件檔案包含的重複內容遠超大多數從業者的預期。來源包括：

• 同一文件歸檔在多個目錄位置
• 同一合約的多個版本，有細微的修訂差異
• 轉發的電子郵件，嵌入了完整的執行緒歷史，顯示為獨立文件
• 在數百份文件中逐字出現的樣板部分（標準條款和條件、免責聲明）

在 RAG 系統中，重複表現為檢索從多個來源返回相同內容，為基於該內容的回應人為地提高了信心度評分。主要基於樣板文字訓練的系統會用樣板文字來回應。擁有十份同一過時政策文件副本的系統會自信地反覆檢索那份過時的政策。

4. PII 污染

客戶文件常規性地包含 PII：支援工單中的客戶姓名和聯絡資訊、臨床記錄中的患者識別碼、HR 文件中的員工社會安全號碼、帳單記錄中的金融帳戶號碼。當這些資料進入向量存儲時，它們變得可檢索：

• 關於客戶投訴的查詢可能檢索到包含特定客戶聯絡方式的文件
• 關於員工績效的查詢可能檢索到包含該員工社會安全號碼的文件
• 關於帳單歷史的查詢可能檢索到包含支付卡號碼的文件

這不是假設性風險。這是將未篩查的客戶資料攝取到可被不應存取該 PII 的使用者存取的檢索系統中的直接後果。對於受 GDPR 保護的資料，這可能構成資料外洩。對於受 HIPAA 保護的資料，這是具有直接監管後果的違規行為。

5. 格式不一致

客戶上傳跨越多個文件世代和系統來源。一個「文件檔案」可能包含：

• 文字密度差異很大的 PDF（200 詞的單頁文件和 50,000 詞的技術手冊）
• 需要不同分塊策略的混合文件類型（結構化表單 vs. 敘事文字）
• 具有非標準章節結構的文件，導致分塊在語意錯誤的位置進行拆分
• 表格在擷取為線性化文字時失去賦予其意義的結構關係

格式不一致不會阻止攝取——它會降低檢索精度。來自擷取效果差的表格的塊可能以語意表示較弱的方式嵌入。來自在錯誤邊界拆分的文件的塊可能在單一嵌入中結合不相關的概念。

為什麼「只是添加錯誤處理」在規模上會失敗

對這些問題的直覺反應是在攝取管道中添加錯誤處理：捕獲解析失敗、跳過零長度文件、記錄編碼錯誤。這對於明顯的失敗是有效的——管道停止大聲報錯。它並不能修復靜默失敗。

編碼亂碼不會拋出錯誤。它產生系統成功處理的字串。近重複文件不會拋出錯誤。它們正常嵌入、分塊和檢索。文件文字中的 PII 不會拋出錯誤。它與周圍內容一起嵌入並變得可檢索。

錯誤處理捕獲以例外形式出現的失敗。大多數文件品質問題以管道無投訴地處理的有效但降級的輸入形式出現。在規模上——10,000 份文件、100,000 份文件——這些靜默降級的累積效應是顯著的，且事後難以診斷。

正確的解決方案是攝取上游的品質閘控，而不是攝取管道內部的錯誤處理。

解決方案：RAG 攝取前的資料品質管道

解決方案是在文件進入向量資料庫之前執行的四節點品質層。

異常偵測器：捕獲損毀檔案

異常偵測器節點篩查傳入文件的結構完整性問題：

• 檔案大小異常（零位元組檔案、太小無法包含有效內容的檔案）
• PDF 結構驗證（內容串流完整性、頁數一致性）
• 受密碼保護檔案偵測
• 編碼偵測和非 UTF-8 檔案標記
• 空位元組和不可列印字元偵測

異常偵測失敗的文件被路由到隔離佇列，而不是繼續進行解析。隔離日誌記錄每份文件的具體失敗原因，實現有針對性的糾正。

PII 去識別化器：防止 PII 進入向量存儲

PII 去識別化器節點在解析後、分塊前執行。它偵測並移除：

• 電子郵件地址、電話號碼、社會安全號碼
• 街道地址和地理識別碼
• 醫療記錄 ID 和患者識別碼
• 金融帳戶號碼和卡號

PII 被標記的 token 替換（[EMAIL]、[PHONE]、[MEDICAL_ID]），在移除敏感資料的同時保留文件的語意結構。結果是一份準確代表其內容和情境的文件——而不會將可檢索的 PII 嵌入向量存儲。

為滿足 GDPR 和 HIPAA 合規，每次去識別化都會被記錄：偵測到哪些實體類型、應用了哪種去識別化方法以及每次偵測的信心度評分。

品質評分器：標記低信心度擷取

品質評分器根據可配置的品質標準評估每份解析的文件：

• OCR 信心度（對於掃描文件）
• 擷取完整性（成功解析頁面的百分比）
• 內容密度（每頁最低詞數，低於此值的頁面可能是解析失敗）
• 編碼有效性（亂碼指標和替換字元的存在）

評分高於接受閾值的文件進入分塊。低於閾值的文件保留在審核佇列中。這確保只有經過驗證擷取品質的文件才向向量存儲貢獻嵌入。

實際上，第一次對客戶檔案執行品質評分器通常會發現 8–20% 的文件存在品質問題，這些問題會靜默降低檢索品質。

去重器：防止檢索冗餘塊

去重器在分塊前移除近重複內容：

• 精確重複（相同內容，不同檔案路徑）被減少為一個代表性文件
• 近似重複（相似度高於可配置閾值，預設 0.95）被減少為一個代表性文件
• 樣板偵測標記在文件中高頻出現的內容（標準條款、免責聲明、頁首）以供選擇性從塊集中排除

分塊前的去重意味著向量存儲包含不同的內容。檢索返回多樣化、非冗餘的結果。信心度評分不會因同一段落的十份相同副本的存在而被人為提高。

對比：RAG 攝取品質方法

客製化腳本列代表大多數團隊第一次遇到這些問題時建構的內容：一個捕獲解析錯誤的腳本，也許是一個用於電子郵件的正則表達式，手動記錄。這處理了明顯的情況。Ertas 管道處理完整的範圍——包括客製化腳本遺漏的靜默失敗。

常見問題

如何在文件進入 RAG 之前偵測格式錯誤的文件？

在檔案匯入後將異常偵測器節點部署為第一個處理步驟。將其配置為檢查：零位元組檔案、PDF 結構完整性、密碼保護和編碼異常。節點將失敗的文件路由到隔離佇列而非解析器，因此它們永遠不會產生進入下游品質管道的格式錯誤擷取。隔離日誌列出每份失敗文件及其具體失敗原因，為你提供可操作的糾正資訊。

我可以為 RAG 攝取設定品質閾值嗎？

可以。品質評分器節點允許你為每個品質維度配置接受閾值：OCR 信心度（對於掃描文件）、擷取完整性、內容密度和編碼有效性。文件的總體評分是這些維度的加權平均值；你可以根據哪些品質因素對你的用例最重要來調整權重。低於總體閾值的文件保留在審核佇列中。閾值可以按管道執行進行調整——你可能在初始攝取通過時使用較低的閾值，並在生產時收緊它。

這與現有的向量資料庫配合使用嗎？

可以。品質管道以你選擇的輸出格式產生乾淨、去重、PII 去識別化的文件——JSONL、RAG 就緒分塊格式或純文字。無論你使用哪個向量存儲（Pinecone、Weaviate、Chroma、Qdrant、pgvector 或其他），這些輸出都會饋入你現有的向量資料庫攝取工作流程。Data Suite 處理資料準備層；你現有的向量資料庫和檢索堆疊處理其餘部分。品質管道位於你的文件來源和攝取管道之間，而不是在其內部。