從原始文件到可檢索知識，有哪些要考慮?

昨天提到，當 Baseline 缺少外部知識時，第一步不是直接建立 Vector Database，而是先找出真正的 Source of Truth，再依照資料型態與問題複雜度，決定要搜尋、查詢，還是透過工具取得所需脈絡。但如果 Source of Truth 是企業內部累積的大量文件，新的問題也會跟著出現：

企業文件通常不是一串乾淨且順序正確的文字，這些 PDF、PowerPoint、Word、Excel、掃描圖片與網頁，究竟要怎麼變成可以被系統穩定檢索的知識？

• PDF 可能有雙欄排版、頁首頁尾與跨頁表格
• 簡報的意義可能散落在標題、文字框、圖片與圖表裡
• 掃描文件甚至必須先經過 OCR

如果這些結構在進入流程的第一步就消失了，後面不管換多好的 Embedding Model、Vector Database 或 Reranker，都只是在更有效率地搜尋一份已經被解析錯誤的資料。

所以今天想討論的，是 RAG 架構的另一半：
在查詢發生以前，文件匯入與索引流程如何把原始資料轉換成可被檢索的知識。

文件匯入與索引，不只是把資料丟進 Vector Database

如果先把細節拿掉，一條常見的 RAG 文件匯入與索引流程可以整理成：

資料來源 → Connector → Adapter / Parser → 結構化表示 → Chunking → 內容增強 → Embedding / Index

每一層處理的問題不同：

• Connector 從 S3、SharePoint、網站或檔案系統取得資料；
• Adapter 將格式轉成共同介面；
• Parser 辨識版面、閱讀順序、表格、圖片與階層，再保存為結構化表示。
• Chunking 決定搜尋單位，內容增強補上必要脈絡
• 最後才進入向量、關鍵字或 Graph Index。

產品可能把多層包在同一個工具裡，但從架構角度仍應分開理解，才能定位 Retrieval 失敗發生在哪一層。

Adapter / Parser 真正要保存的不是文字，而是文件結構

最簡單的 Adapter / Parser，可能只是把檔案內容抽成純文字。但純文字很容易造成資訊損失。

例如規格表中很常會多個欄位共用合併標題，下一列才分成尺寸、重量與容量。Parser 若只按文字座標逐行抽取，最後可能得到看似完整、實際上已失去欄位關係的文字；多欄 PDF 也一樣，我們人類會知道先讀完左欄再讀右欄，Parser 卻可能把兩欄交錯串起；PPT 更是不一定，可能圖的設計本身就是一種資訊，不存在明確閱讀順序。

因此，結構化表示除了文字，還應視需求保留文件階層、章節路徑、表格儲存格、圖片、圖說、閱讀順序、頁碼、位置座標、來源位置、版本與 ACL。它們不一定都送進 Embedding Model，卻會影響 Chunking、資料篩選、引用、權限與增量更新。

Adapter / Parser 的價值，不只是把不同格式轉成文字，而是盡可能把文件原本的語意結構轉成機器可以繼續處理的表示法。

GitHub 上常見的 Adapter 與 Parser

目前 GitHub 上已經有不少熱門工具可以處理 PDF、Office、圖片與 OCR。它們常被放在一起比較，但定位並不完全相同。以下熱度是近期比較社群關注比較熱門的一些repo。

三大雲也有託管服務：AWS 的 Amazon Textract 與 Bedrock Data Automation、Azure AI Document Intelligence，以及 Google Cloud 的 Document AI Layout Parser。它們提供 OCR、版面與表格辨識、欄位擷取，部分服務也能產生適合 RAG 的 Chunk。

託管服務的優勢是 API、擴縮與治理整合；代價是費用、服務區域、資料邊界與 Vendor Lock-in。這是自建或採購的選擇，不是單純的功能競賽。

但實際上，最後都要回歸到處理內部的資料的資料特性，像是繁中掃描、多欄論文、跨頁表格與產品簡報建立代表性測試資料集，比較文字、閱讀順序、表格與標題階層是否正確。除此之外，能否回溯來源，以及速度、資源、失敗率與授權也是很重要的評估指標。

工具的 README 告訴我們它能處理什麼；自己的評估資料集才能告訴我們它能不能處理我們的資料。

Chunking 決定 Retrieval 看到的最小知識單位

文件完成解析後，下一步才是 Chunking。

Chunk 太大，可能同時代表多個主題；Chunk 太小，又可能失去標題、前後文與條件。例如「不得退貨」若被切掉前面的「已拆封商品」，就會從有條件規則變成錯誤的絕對規則。

因此 Chunk Size 並不存在對所有資料都適用的固定答案。切分、Metadata 與 Retrieval 階段的脈絡擴展等策略可以一起整理如下：

實務上可以組合多種方法。合理的預設策略是：

先依版面與章節保留自然邊界，再對過長章節使用 Recursive 與 Token 上限；表格、圖片與圖說、程式碼區塊及清單則視為不應任意拆散的完整物件。

大型表格可依資料列群組切割，但每一塊都要重複表格標題、欄位名稱與單位，並保存儲存格座標，否則模型可能找到數字卻不知道它屬於哪個欄位。

Embedding 之前，要不要先替 Chunk 補充 Context？

完成 Chunking 後，最直接的做法是把每個 Chunk 送進 Embedding Model。但 Chunk 一旦離開原始文件，常常會失去原本隱含的脈絡。

例如 Chunk 只有「保固期限為兩年」，沒有文件名稱、產品型號與章節路徑時，很難分辨它描述哪項產品。因此常會在 Embedding 前補上額外資訊。

不必讓每份資料都先經過 LLM 增強。穩健的順序是先加入固定且可驗證的 Metadata、文件標題與章節路徑，再觀察實際的 Retrieval 失敗。

口語問題與正式文件語言差異大時，再考慮替 Chunk 自動產生可能問題；常問整份文件主題時才增加摘要；跨文件 Entity 與 Relation 無法被局部 Chunk 表達時，才考慮 Knowledge Graph。

內容增強不應該因為可以生成就全部生成，而應該用來修復已經被觀察到的 Retrieval 缺口。

GraphRAG 不是單純把 Embedding 再增強一次

GraphRAG 常被理解成另一種內容增強。但 Microsoft GraphRAG 會從 Text Unit 抽取 Entity、Relationship 與 Claim，再做 Community Detection、產生社群報告（Community Report）並建立多種 Index。

這代表 GraphRAG 不是只替原本的 Chunk 多加幾個欄位，而是在向量表示之外，再建立一套描述知識關係的 Graph 表示。

一般 Vector RAG 擅長回答「某商品的保固期限是多久？」等局部事實。GraphRAG Local Search 適合從特定 Entity 尋找關係；Global Search 則利用社群報告，回答整個資料集的主要議題、風險或共同模式。

GraphRAG 的代價是額外的 Entity / Relation Extraction、Entity Resolution、Community Detection 與摘要生成；文件更新時也要維護 Graph。如果 Relation 抽取錯誤，影響還可能被圖結構放大。

因此，以下情況通常不需要急著建立 Graph：

• 問題大多是單一文件內的局部事實查詢
• Corpus 不大，而且內容經常更新
• Entity 名稱與 Alias 尚未整理
• 還沒有證據顯示 Vector、關鍵字、Metadata 篩選與 Reranker 無法處理目前問題
• 只是希望讓每個 Chunk 多一點背景資訊

如果問題天然具有關係網路結構，或答案需要跨文件 Multi-hop Reasoning 與全域綜整，GraphRAG 才可能值得投入。

是否需要 Graph，不是由資料裡有沒有 Entity 決定，而是由問題是否需要透過 Relation 與整體語料庫結構才能回答決定。

文件匯入與索引流程決定了系統最後能看見什麼

把今天的流程重新整理一次：

資料來源 → 文件結構 → Chunk → 內容增強 → Index

資料來源決定知識從哪裡來；Parser 決定保留多少結構；Chunking 決定最小知識單位；內容增強補足遺失的脈絡；Embedding、關鍵字或 Graph Index 最後才決定如何搜尋。

這些步驟彼此相依：沒有辨識標題與表格，就難以做 Structure-aware Chunking；沒有保存來源位置，就難以提供引用；只需局部事實時，過早加入摘要、自動產生可能問題與 Graph 反而增加成本。

所以成熟的文件匯入與索引流程不應從「用哪一個 Vector Database」開始，而要先問：原始資料有什麼結構、哪些資訊不能遺失、Retrieval 應找到多大的知識單位、Chunk 缺少哪些脈絡，以及問題是否真的需要 Entity Relation 與整體知識結構。

RAG 的 Retrieval 品質，很多時候在 Query 發生以前，就已經被文件匯入與索引流程決定了。

下一步，才是進一步討論這些 Chunk 要如何轉成 Embedding、放進什麼 Index，以及到了查詢階段，又該如何透過關鍵字、Vector、資料篩選、Reranking 與不同 Retrieval Strategy 找回真正需要的脈絡。

AI 你怎麼看?