
PDF到RAG管道的最佳工具:解析多欄、掃描和混合格式文件
PDF解析是大多數RAG管道首先失敗的地方。多欄版面、掃描頁面、嵌入式表格和混合格式會產生垃圾分塊,破壞檢索品質。以下是處理方法。
大多數建構RAG管道的團隊花數週時間研究嵌入模型、向量資料庫和檢索策略。然後他們發現這一切都不重要,因為PDF解析步驟產生了垃圾。饋入向量儲存的分塊包含來自兩個不同欄目合併成一個段落的句子、被壓平為無意義字串的表格資料,或因為是掃描影像而非原生文字而完全缺失的整頁內容。
PDF解析是任何文件攝取管道的第一步,也是大多數RAG品質問題的發源地。如果解析器產生了低品質的文字,每個下游元件——分塊、嵌入、檢索、生成——都會繼承這種損壞。再多的提示工程或重排序也無法恢復在擷取過程中遺失或打亂的資訊。
本文涵蓋了五種最常見的PDF故障模式,它們會破壞RAG管道,並解釋最佳的RAG文件攝取工具需要處理什麼才能在規模化場景下產生可靠的結果。
為什麼PDF解析是最薄弱的環節
PDF不是為文字擷取設計的文件格式。它是為視覺呈現設計的格式。檔案儲存的是將字形放置在頁面特定座標上的指令。PDF規範中沒有「段落」、「欄」或「表格」的語義概念。人類讀者看到兩欄文字。PDF檔案包含數百個散布在頁面上的獨立文字放置命令,沒有明確指示哪些命令屬於哪一欄。
這意味著每個PDF解析器都必須從空間座標重建文件結構。簡單的解析器按照文字放置命令在檔案中出現的順序讀取,這通常與視覺閱讀順序不匹配。更複雜的解析器使用啟發式方法來偵測欄、表格和閱讀流。但啟發式方法會失敗,當它們在PDF到RAG管道中失敗時,產生的分塊在語義上是不連貫的。
以下五種故障模式大約佔我們在企業文件攝取工作流中看到的解析問題的80%。
故障模式一:多欄版面
學術論文、年度報告、新聞通訊和許多監管文件使用兩欄或三欄版面。當一個樸素的解析器遇到兩欄頁面時,它從左到右直接橫跨頁面讀取,將每行上A欄的文字與B欄的文字合併。結果是在兩個完全無關的段落之間交替的句子。
考慮一份財務報告,左欄討論第三季營收,右欄討論人員變動。一個跨欄讀取的解析器會產生這樣的分塊:「營收較上一季增長12%,同時公司將其歐洲業務的人員減少了大約。」這不是文件中的一個句子,而是來自不同部分的兩個半句拼接在一起。當這個分塊被嵌入和檢索時,生成的回答會自信地呈現營收和人員之間並不存在於來源資料中的虛假關聯。
修復方法需要在文字擷取之前進行版面偵測。解析器必須識別欄邊界,確定每欄內的閱讀順序,並逐欄而非逐行擷取文字。對於乾淨的兩欄版面來說這很簡單,但當欄寬不同、圖形跨越兩欄,或側邊欄和標註框打破欄結構時,就會變得更加困難。
故障模式二:掃描文件和OCR
企業文件庫中充滿了掃描的PDF——簽 署後列印再掃描回來的合約、數位化工作流之前的遺留文件、作為實體郵件接收的監管提交文件。這些PDF包含頁面影像,而非文字。標準文字擷取不會回傳任何內容。
OCR(光學字元辨識)將頁面影像轉換為文字,但OCR品質因掃描解析度、頁面傾斜度、字型清晰度和背景雜訊而差異巨大。300 DPI的清晰雷射列印文件掃描件可產生接近完美的OCR。150 DPI的帶咖啡漬傳真文件掃描件產生的文字充滿字元級錯誤:「l」變成「1」,「rn」變成「m」,「cl」變成「d」。
這些字元級錯誤對RAG特別有害,因為它們影響關鍵字匹配和嵌入品質。如果來源文件寫的是「compliance」(合規)但OCR讀取為「cornpliance」,當使用者詢問合規要求時,該分塊將不會被檢索到。資訊存在於語料庫中,但對檢索系統來說實際上是不可見的。
一個穩健的PDF到RAG管道需要OCR能夠優雅地處理低品質掃描件,對擷取的文字應用信心度評分,並標記OCR品質低於可接受閾值的頁面,而不是靜默地攝取損壞的文字。
故障模式三:嵌入式表格
表格是商業文件中資訊密度最高的結構之一,也是最難正確解析的結構之一。對人類讀者來說視覺上清晰的表格——具有對齊的欄、標題列和儲存格邊框——在PDF中儲存為數十個獨立的文字片段,定位在特定座標上。解析器必須從這些 座標重建表格網格,然後將表格序列化為保留標題和值之間關係的文字格式。
大多數解析器在其中一個步驟上失敗。它們要麼未能偵測到表格的存在(將每個儲存格視為獨立段落),要麼未能正確重建網格(標題與值錯位),要麼以破壞結構的方式序列化表格(輸出所有標題後跟所有值,無法將它們匹配起來)。
當表格資料以純文字段落形式進入向量儲存時,任何需要查找特定值的查詢的檢索品質都會崩潰。使用者問「第二季的毛利率是多少」,檢索到的分塊包含正確的數字但格式使得無法判斷哪個數字對應哪個指標和哪個季度。LLM要麼編造一個答案,要麼承認無法確定值——兩種結果對企業用例來說都是不可接受的。
最佳的RAG文件攝取工具必須偵測表格、重建其網格結構,並以保留標題到值關係的格式(如Markdown表格或結構化鍵值對)輸出,使其在分塊和嵌入過程中得以保持。
故障模式四:頁首、頁尾和頁面偽影
頁碼、執行頁首、保密聲明、文件ID和浮水印出現在許多商業文件的每一頁上。當解析器從每頁擷取文字並串接時,這些重複的偽影散布在整個擷取文字中。一份50頁的文件可能有「機密——禁止散布」50次插入到原本連貫的段落中間。
這造成兩個問題 。首先,包含這些偽影的分塊將嵌入維度浪費在語義無意義的文字上,降低了相似性搜尋的品質。其次,當一個段落跨越分頁符時,解析器在兩半之間插入頁首和頁尾,將段落打斷成孤立時失去意義的片段。
去除頁首和頁尾聽起來簡單但實際並非如此。它們在PDF結構中沒有被標記為頁首或頁尾。解析器必須透過識別在多個連續頁面相同位置出現的文字來偵測它們。這種偵測必須容忍輕微的位置變化(不是每頁都有完全相同的邊距),並且不能意外去除合法出現在相似位置的內容,例如續頁上的重複表格標題。
故障模式五:混合編碼和混合文件
真實的企業文件經常在單個PDF中組合多種內容類型。一份監管文件可能包含敘述部分的原生數位文字、帶手寫簽名的掃描附錄、呈現為影像的嵌入式Excel圖表,以及帶編碼值的表單欄位。每種內容類型需要不同的擷取策略。
許多解析器對整個文件應用單一擷取方法。如果使用文字擷取,掃描頁面回傳空白。如果到處使用OCR,原生文字頁面得到的是品質較低的OCR輸出,而非PDF中已有的完美文字。如果跳過影像,包含關鍵資料的圖表和圖解就會遺失。
當編碼在頁面內變化時,失敗會加劇。一些PDF使用不常見的字元編碼、自訂字型對映或連字,導致標準文字擷取回傳亂碼字元或Unicode替換符號。一個解析器可能完美擷取文件95%的內容,但對包含最關鍵技術規格的5%產生不可用的輸出,僅僅因為那些頁面使用了不同的字型編碼。
生產級的PDF到RAG管道必須逐頁或逐區域偵測內容類型,並對每個區域獨立應用適當的擷取方法。
生產級解析器必須做什麼
上述五種故障模式有一個共同的根本原因:解析器以相同方式對待所有PDF。生產文件並不統一。它們包含混合版面、混合內容類型和混合品質水準,通常在單個檔案中就是如此。最佳的PDF到RAG管道工具必須自動處理這種異質性。
Ertas PDF解析器專門為這個問題而建構。它在文字擷取之前執行版面分析,偵測每頁的欄、表格、頁首、頁尾和內容區域。對於掃描頁面,它應用帶信心度評分的OCR,讓你知道哪些頁面產生了可靠文字,哪些需要審查。對於表格,它重建網格結構並輸出在分塊過程中保留標題到值關係的Markdown表格。
解析之後,Ertas的Quality Scorer在輸出進入分塊管道之前進行驗證。它標記OCR信心度低的頁面,偵測殘留的頁首和頁尾汙染,並識別可能發生多欄合併的分塊。這意味著你在解析失敗損壞向量儲存之前就能捕獲它們——而不是在使用者開始得到錯誤答案之後。
視覺化管道儀表板準確顯示多少文件成功解析、多少有部分失敗,以及哪些特定頁面需要關注。對於企業級規模的文件攝取——數千個混合格式、混合品質和混合版面的PDF——這種可見性是你能信任的RAG管道與靜默退化的管道之間的區別。
總結
PDF解析不是一個已解決的問題。它是一個大多數RAG管道忽視的問題,直到檢索品質開始下降而沒人能找出原因。解決方案不是更好的嵌入或更好的提示。解決方案是更好的解析——感知版面、具備OCR能力、保留表格、去除偽影的解析,能夠處理真實企業文件的全部多樣性。
做好解析,你RAG管道中的每個下游元件都會運作得更好。做錯了,下游再多的工程也無法補償。
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

Multi-Format Document RAG: Building a Retrieval Pipeline Across PDFs, Word, Excel, and Audio
Enterprise knowledge lives in PDFs, Word documents, spreadsheets, presentations, and even audio recordings. A RAG pipeline that only handles one format misses most of the organisation's knowledge.

Why Your RAG Pipeline Fails Silently — And How to Make It Observable
Most RAG pipelines are invisible glue code. When retrieval quality drops, there is no logging, no node-level metrics, and no way to trace which document caused the bad answer. Here is how to build observable RAG infrastructure.

Best Visual RAG Pipeline Builder: From Documents to Retrieval Endpoint Without Writing Code
Building RAG pipelines typically requires Python expertise across five or more libraries. A visual pipeline builder lets domain experts and engineers alike build production RAG by dragging and connecting nodes on a canvas.