你的 RAG 還在吃又髒又亂的 HTML 嗎？談 Ingestion Quality 如何決定系統天花板

RAG（檢索增強生成）系統的效能天花板，往往不是由最先進的檢索演算法或 Re-ranking 模型決定，而是取決於源頭資料的品質。許多團隊將優化重心錯放在系統後端，卻忽略了資料進入向量資料庫前，是否經過有效的標準化、去噪與結構化。將充滿雜訊的網頁原始碼轉換為乾淨、專為 LLM 設計的 Markdown，這不僅是基礎前處理，更是決定系統能否產生可靠、可溯源答案的關鍵工程。

為什麼直接餵給 RAG 原始網頁是個壞主意？

大型語言模型的運作遵循一個古老但至今依然有效的原則：Garbage In, Garbage Out。當我們試圖讓 RAG 系統從網路上獲取即時資訊時，「輸入」的通常是充滿雜訊的 HTML 原始碼。一個典型的網頁，其真正的內容可能只佔整個檔案大小的 10-20%。其餘部分則由導覽列、側邊欄、廣告腳本、CSS 樣式、不相關的 footer 連結以及大量的標籤屬性所填充。若不加處理直接將這些 HTML 進行切塊（Chunking）與向量化，會產生幾個嚴重的問題：

• 語義雜訊污染 Embedding： 向量嵌入（Vector Embedding）會將無關的導覽列文字（如「關於我們」、「聯絡我們」）與主要內容的語義混在一起，導致檢索時的語義相似度計算失準。當使用者查詢一個特定主題時，系統可能會因為導覽列的關鍵字匹配，而召回一個完全不相關的頁面。
• 降低檢索精準度： 大量無意義的 HTML 標籤與腳本，會稀釋文本中真正有價值的資訊密度。這不僅浪費了寶貴的 Context Window，也讓檢索演算法更難以精準地找到與查詢最相關的文本區塊，最終導致 LLM 在生成答案時引用錯誤的來源。
• 增加處理成本與延遲： 處理一個 150KB 的 HTML 頁面，可能遠比處理其 20KB 的純文字內容來得耗時且昂貴。從 Tokenization 到 Embedding，每一步的成本都與輸入的長度正相關。

許多 RAG 開發的常見痛點，例如幻覺（Hallucination）或引用錯誤，其根源往往可以追溯到這個看似簡單卻被普遍忽視的資料清理階段。

將網頁標準化為 Markdown：不只是轉換，更是結構化

解決上述問題的有效方法，是建立一個穩健的資料前處理管線（Ingestion Pipeline），其核心任務之一，就是將非結構化的網頁內容，轉換為半結構化的乾淨格式。而 Markdown 正是目前最適合 LLM 理解的格式之一。

Markdown 的價值不僅在於它移除了所有不必要的視覺樣式與腳本，更重要的是，它保留了內容的「語義結構」。例如：

• # 和 ## 標題，清晰地定義了文章的層次與章節。
• * 和 - 條列，明確了項目之間的並列關係。
• [text](url) 連結，保留了重要的引用來源。
• > 引用塊，突顯了引文或重點。

這種結構化的純文字，讓後續的 Chunking 策略變得更加智慧。我們可以輕易地按章節或標題進行切分，確保每個 Chunk 內部的語義連貫性，這遠比按照固定 token 數量暴力切分來得有效。

最近我注意到像 Jina AI 的 Reader 這類工具，它們專為這個目的而生。透過一個簡單的 API 端點（例如 r.jina.ai/[URL]），它能自動抓取指定網頁，並回傳一個為 LLM 優化過的 Markdown 版本。這類工具執行的不僅是簡單的 HTML-to-Markdown 轉換，更是一套複雜的去噪與內容提取演算法，它能識別並移除廣告、留言區、相關連結等非核心內容，只留下真正的主體文章。

在 RAG 的世界裡，高品質的資料擷取與轉換，其重要性不亞於任何一個花俏的檢索演算法。一個乾淨、結構化的資料來源，是所有後續優化的基礎。

如何建立一個高品質的 RAG Ingestion Pipeline？

從單一工具的選擇，我們可以拉高到整個 RAG 系統的架構層次來看。一個成熟的 Ingestion Pipeline，應該被視為與檢索、生成同等重要的系統模組。根據 對 RAG 的學術研究綜述，資料索引前的預處理（Pre-retrieval process）是決定系統表現的關鍵環節。

一個基本的 Ingestion Pipeline 至少應包含以下步驟：

1. 擷取 (Fetch)： 從各種來源（網頁、API、文件）獲取原始資料。
2. 清理與標準化 (Clean & Standardize)： 這是最關鍵的一步。使用 Jina Reader 或自建的 HTML 清理工具，將原始資料轉換為乾淨、結構化的 Markdown。這一步驟的品質，直接決定了後續所有步驟的上限。
3. 切塊 (Chunk)： 根據 Markdown 的語義結構（如標題、段落）進行智慧切分，而非固定長度切分。
4. 向量化 (Embed)： 將乾淨的文本塊轉換為向量表示。
5. 索引 (Index)： 將向量與其中繼資料（Metadata，如來源 URL、標題）存入向量資料庫。

優化 Ingestion Pipeline 能帶來哪些實質好處？

當我們將「清理與標準化」視為一個獨立且必要的步驟時，整個 RAG 系統的治理性與可觀測性也會隨之提升。我們可以對轉換後的 Markdown 品質進行評估，設定明確的驗收標準，確保進入向量資料庫的每一筆資料都是高品質的。

這不僅能顯著提升 RAG 系統的回應品質與引用的準確性，長期來看，更能降低因資料污染所導致的維護成本。

總結來說，與其不斷地在檢索端嘗試更複雜的 Query Transformation 或 Re-ranking 模型，我更傾向於回到源頭，確保進入系統的每一份文件都經過了最好的處理。因為一個建立在乾淨、結構化資料之上的 RAG 系統，即使使用最基礎的檢索演算法，其表現也可能遠勝於一個在充滿雜訊的資料上，使用最先進演算法的系統。

延伸閱讀

• Jina Reader の紹介（原日文資料）
• Jina Reader 官方網站
• Retrieval-Augmented Generation for Large Language Models: A Survey
• Data Preparation for RAG Systems and LLMs

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。