【2026 最新】RAG 網頁擷取怎麼驗？四路同頁比較與入庫前五格檢查（新手教學）

你問 RAG 助理「競品每月多少錢」，它卻回答「Accept all cookies」。這不是模型真的把 Cookie 當貨幣，而是RAG 網頁擷取時把橫幅文字送進索引，真正的價格表可能還沒被讀到。想讓答案可靠，該先檢查進庫前的內容。

這篇寫給第一次替 RAG 接網頁資料、也看得懂複製貼上指令的讀者。我們用同一套人工真值，教你比較 raw HTML、Jina Reader、Context.dev、Firecrawl 四條路的輸出，做一個會擋住壞資料的入庫門檻。這是依官方文件設計的可重做驗收方法；下文的示意頁與判準不是四家服務的實測勝負。

先說結論：RAG 網頁擷取先驗內容，再比工具

一句話記住：可信的 RAG 網頁資料＝可追溯來源 × 完整關鍵欄位 × 排除介面雜訊 × 可重跑。任何一項是零，漂亮的 Markdown 也不該直接進索引。把索引想成圖書館的書架：搜尋員再熟練，也找不出一本尚未入館的價目表；把門口的 Cookie 告示當成內文，則可能找出錯的「證據」。

四條路先回答同一題：在同一個 URL、同一時間、同一地區條件下，抓回來的文字能否支持指定答案？等單頁比完，再另測「能否自行找到相關頁」；這是另一項能力。

RAG 網頁擷取為什麼會在入庫前出錯？

RAG 是先找資料、再讓模型根據找到的片段回答。若抓取器收進導覽列、Cookie 橫幅和頁尾，這些字也可能被切成片段；若價格靠 JavaScript 在瀏覽器裡補上，只取初始 HTTP HTML 的流程可能漏掉它。後續調整 embedding 或排序，無法補回從未抓到的欄位。想先釐清整體流程，可讀 RAG 是什麼；已掌握擷取之後，再讀 BM25、向量與混合檢索。

這正是抽取品質需要獨立驗收的原因。WebMainBench 原始專案用人工標註的網頁內容建立評估資料與工具；它提醒我們「主內容抽取」可以和後段問答分開測量。該專案的樣本與任務，不能直接推成本文四條路在你的網站上的名次。

先做人工真值：一頁三個陷阱，三個必答欄位

挑一個你有權抓取、公開可瀏覽的測試頁。最好有一條當前價格、一條過期價格、以及讀者一眼就能認出與價格無關的 Cookie 文字；如果頁面含 JavaScript 載入表格，再記下瀏覽器實際顯示的值。不要拿一個未經人工核對的工具輸出，充當其他工具的「標準答案」。

• 固定頁面：記錄原始 URL、最後跳轉 URL、擷取時刻、地區／語言、登入與 Cookie 狀態；不要讓某條路看到登入頁，另一條路看到公開頁。
• 人工真值：逐欄抄下方案名、月付價格、幣別、計價週期與生效日期，附上頁面所在位置或可核對截圖。舊價單列為「應排除」，不是可接受的另一個答案。
• 三道陷阱：Cookie 句子是否混進主內容？JavaScript 表格是否完整？舊價是否與新價混在同一段？

示意真值可以寫成 {"plan":"Pro","price":"$29","period":"month","source_url":"https://example.com/pricing","observed_at":"2026-10-06"}。這裡的 29 美元只是教你設計欄位的虛構數字，不代表任何真實產品價格。人工核對的是欄位與來源位置，不是「Markdown 看起來乾淨」。

四條路各抓什麼？先把測試範圍對齊

① raw HTML：保留原始回應，當基線

用 curl -L 取得原始回應並保存。優點是可保留 HTTP 層與原始 HTML，方便事後追查；缺點是你還得自己挑主內容、處理動態載入與去除噪音。要確認是否漏掉 JavaScript 生成的價格，對照瀏覽器渲染後畫面。raw HTML 的「原始」是輸入基線，不是保證比較準的答案。

curl -L --fail 'https://example.com/pricing' -o raw.html

② Jina Reader：把 URL 轉成可讀文字

Jina Reader 官方 README說明可把目標 URL 接在 https://r.jina.ai/ 後，取得適合閱讀的內容；官方也列出 x-engine、x-wait-for-selector、x-no-cache 等控制。第一次先用預設設定，若某張表遺失，再記錄你何時改用瀏覽器引擎或等待選擇器；調參後的結果要另存，不要混成同一次基線。

curl -L 'https://r.jina.ai/https://example.com/pricing' -o jina.txt

③ Context.dev：用單頁 Scrape 比，跨頁查找另測

Context.dev 的 Scrape 文件給的是單一 URL 的 POST /v1/web/scrape，能要求 Markdown，回應裡每種格式各有 success、data；也有 isPartial 標記。這次四路單頁比較，用這個 Scrape 路徑。它的 JSON 抽取說明與跨頁查找可在第二輪測，但不能與「只抓已知 URL」的呼叫混算。

curl 'https://api.context.dev/v1/web/scrape' -H 'Authorization: Bearer YOUR_CONTEXT_KEY' -H 'Content-Type: application/json' -d '{"url":"https://example.com/pricing","formats":{"markdown":true},"sharedParams":{"mainContentOnly":true}}' -o context.json

④ Firecrawl：同頁 Scrape，留意頁面狀態

Firecrawl 官方 Scrape 文件展示 POST /v2/scrape、Markdown 與 HTML 輸出，以及 metadata.sourceURL。它特別區分 API 請求成功與目標頁面的 metadata.statusCode：收到 API 200 仍可能拿到來源頁 403 或 404。把兩層狀態都寫進驗收紀錄。

curl 'https://api.firecrawl.dev/v2/scrape' -H 'Content-Type: application/json' -d '{"url":"https://example.com/pricing","formats":["markdown","html"]}' -o firecrawl.json

上面四行是照官方目前文件整理的起手式；執行前把 https://example.com/pricing 換成你有權測試的真實頁面網址。如果網站有登入、機器人阻擋、地區價格或特別的同意流程，先固定合法存取條件，再比較內容；不要把四種不同頁面狀態當成擷取品質差。

RAG 網頁擷取的五格驗收表，怎麼填才有用？

每條路同一 URL 至少保存原始輸出、HTTP／工具狀態、擷取時刻、最終 URL 和設定。下面五格是人工核對欄位；可以記「通過／失敗／無法判斷」，並留下證據片段，不用先發明一個綜合分數。

• 關鍵欄位：方案名、價格、幣別、週期、生效日期是否都在？缺一項就不要讓模型猜。
• 雜訊：Cookie、導航、頁尾是否被放到與價錢相鄰的可檢索段落？只看文字長短不夠。
• 回指位置：輸出能否回指到正確的最終 URL 與頁面位置？同名方案如果出現在舊公告，來源日期尤其重要。
• 一致性：在頁面沒有改動的條件下重跑，關鍵欄位是否相同？文字格式小差異可另外記錄。
• 失敗訊號：429、來源頁 403、部分輸出、空白表格或等待逾時，是否被明確標成失敗？安靜回傳半頁最容易進索引。

如果要算成本，請用每筆「通過上述檢查、可核對來源」的答案成本：本批總 API 費＋重試費＋必要人工複核時間成本，再除以通過筆數。分母是可用答案，不是成功回 HTTP 200 的請求數。四家方案、免費額度、加價項目都可能變；要填實際帳單前，分別看 Context.dev 價格頁、Firecrawl 價格頁和 Jina Reader 頁面，並用自己的任務量換算。raw HTML 也要算工程維護與失敗重抓成本。

入庫前加一道閘門：一筆價格怎麼走完？

假設人工真值是「Pro／每月 29 美元」，頁面上還有「接受所有 Cookie」與去年 19 美元的公告。四條路各自回傳後，先從結果中找出「Pro」、「29」、「每月」和對應來源；再檢查 Cookie 字樣是否落在價格段附近、19 美元是否被明確標為舊資訊。這是示範驗收流程，不是我們從四家服務取得的觀測結果。

一筆結果可用這段語言無關的偽程式表示：

for result in extractor_outputs:
    if result.request_failed or result.page_status_failed or result.partial:
        quarantine(result, reason='fetch_or_partial')
    elif not has_fields(result, ['plan', 'price', 'currency', 'period', 'source_url']):
        quarantine(result, reason='missing_required_field')
    elif contains_noise_near_answer(result, ['accept all cookies']):
        quarantine(result, reason='noise_near_answer')
    elif not human_or_rule_verified_against_page(result):
        quarantine(result, reason='unverified_value')
    else:
        index_with_provenance(result)

偽程式省略了網站授權、重試上限、資料型別、去重與人工複核佇列；這些必須由實際系統補上。若你用 Firecrawl，照它的 狀態欄位文件同時讀 API 與目標頁狀態；若用 Context.dev，按 格式回應文件逐項檢查 success 與 isPartial。

入庫時把來源 URL、擷取時間、工具與設定、文字版本雜湊和人工真值版本一起存。回答時能回指原頁；更新價格時也知道要刪除哪個過期片段。這一關與 Agent 搜尋 API 的可信度驗收互補：搜尋先找到候選頁，擷取再決定候選頁能否成為可靠材料。

怎麼選路線？依你的任務，而非一張價格表

• 自己掌握 HTML 管線：你能維護選擇器、渲染和重試，而且需要完整原始材料供稽核；先保留 raw HTML 作基線。
• 快速把已知 URL 變成可讀文字：從 Jina Reader 的預設輸出開始，對缺欄位的頁面再試官方提供的等待與引擎選項。
• 需要單頁多種輸出及部分失敗訊號：以 Context.dev Scrape 做同頁驗收，再決定是否要擴到跨頁查找。
• 需要同頁 Markdown、HTML 與明確來源頁狀態：用 Firecrawl Scrape 對照人工真值，再看是否需要它的其他格式或流程。

四條路也可以一起用：先用成本可控的路線處理一般頁，把缺欄位或來源狀態異常的頁隔離，另一路只處理異常樣本。決策依據應是你自己的頁面通過率與每筆可核對答案成本，不是某一家宣稱「網頁都能抓」。

常見問題：入庫品質的八個快答

抓到 Markdown 就可以直接做 embedding 嗎？

不一定。先檢查必需欄位、來源、雜訊與部分失敗；格式漂亮不等於答案完整。

HTTP 200 代表價格表抓到了嗎？

不代表。工具請求成功、來源頁成功與關鍵欄位完整是三件事，Firecrawl 的兩層狀態尤其要分開看。

Cookie 文字一定要全部刪掉嗎？

看任務。回答價格時，Cookie 文案不該和價格被視為同一段證據；若你研究 Cookie 政策，它本身就是主內容。

JavaScript 表格空白，要立刻換服務嗎？

先核對瀏覽器實際頁面及擷取設定；某些工具有等待或瀏覽器模式。每次改動都保留設定與結果。

Context.dev 的跨頁查找能放進四路同頁比較嗎？

應分輪。單頁 Scrape 比抓取品質；跨頁找資料比頁面發現與抽取，工作量與成本分母不同。

哪一家最便宜？

用你的通過筆數算。請求價、免費額度與重試成本會變，便宜的空白頁無法產生可核對答案。

過期價格該怎麼處理？

在真值中明列生效日期與舊價排除規則；入庫時保留版本，更新後撤下過期片段。

沒有工程團隊也能開始嗎？

可以。先人工選三個公開頁、寫真值與五格清單，用官方 Playground 或簡單指令比對；量變大再自動化。

給新手的三個重點

• 先寫真值：沒有人工核對的價格、日期與來源，四條路只能比字數，不能比答案。
• 同任務比較：raw HTML、Jina Reader、Context.dev Scrape、Firecrawl Scrape 先對同一個 URL；跨頁發現另開一輪。
• 擋在索引前：缺欄位、部分回應、來源錯位或 Cookie 雜訊靠近答案，先隔離，再重抓或人工複核。