![[教學] Cloudflare Auto Rag 一起動手玩](/images/blogs/cloudflare-auto-rag-testing/cover.png)
前言：AI + LLM = 第二大腦？
前幾天在 FB 社團上意外看到有篇貼文是在講述說 AI + LLM 可以化作為第二大腦。
印象中作者的例子是將 Obsidian（筆記軟體）搭配 LLM 的套件做整合。讓過往的筆記軟體可以真正成為一個大腦，你可以透過和 LLM 對話的方式去探尋自己過往的筆記內容。
聽起來很酷！如果我沒誤會他的意思的話，聽起來很像是把所有筆記作為資料庫，套用 RAG 的機制去實作。
這就很像自己私人的 notebookLM 一樣，當時也只是看過以後就沒特別著墨。反正筆記軟體我已經選用 Anytype 作為我的私人筆記，沒必要為了 讓 AI 知道 我的一些機敏資訊而去研究。
背景：一個該死的錯誤出現在我的 side project 中
但世界上就是這麼巧的事情發生了。 在之前 WSJ sidep roject 裡頭的 script ，我發現了一個嚴重的摘要錯誤。
在 2025-10-25 的報導中，現實情況是說明 netflix 在過去一週下跌了近 10%，但是摘要內容卻誤認為是上升 10%。
這已經不是我可以睜一隻眼閉一隻眼忽略的錯誤。這會嚴重影響到我的電子報讀者們的認知。（雖說也只是親朋好友ＸＤ）
很顯然，單純的 prompt design, prompt engineering 已經無法解決現在我遇到的問題。
於是我著手開始找尋可能可以的優化方向，都朝向一個結論。
幫原始資料瘦身
我們目前的做法是直接上傳一份 10-18 MB 大小的 PDF 檔案至 GEMINI API，雖然說 gemini 有提供 file 的 api 提供支援過大的檔案。
但實際上 2.5 pro 模型對外宣稱的是 104 萬 token，但實際上我直接將整份 pdf file 上傳上去會大到 400 多萬 token。很明顯已經超出 model 所支援的 context 長度。
沒錯！就是標題提到的 RAG 裡頭的第一個步驟 Loading ，我們要將 PDF 順利地擷取文字內容出來。
是時候嘗試看看將我們的原始資料進行瘦身了。
細節：複雜排版的 PDF
在選用工具將 PDF 提取純文字內容出來的過程中，遇到了許多困難。因為報紙排版較為複雜的方式，所以簡單的 PDF Loader 無法滿足我們的需求。
我也嘗試過一些 OCR 辨識的 PDF Loader，雖然效果不錯，但 local 跑起來實在太花時間，光是在我筆電上執行就很慢了，何況我還打算直接跑在家用 nas 的小垃圾主機上…。
後來嘗試使用 PyMuPDF ，效果似乎還算不錯，速度也夠快。他有個 toMarkdown 的 function。出來的文本還算堪用，但仍然還是會有不少雜訊在其中。
心裡想著頓時覺得好麻煩，如果有 api 可以直接呼叫就好了。
但可惜這類需求似乎在各大廠都是要付費使用的 api。
剎那間，突然想起了免費仔開發者的好朋友 Cloudflare。印象中曾經看過他有類似 RAG 相關的文章，也許在其中挖寶可以找到我要的解決方案。
太好了，既然有 RAG 解決方案，那一定有前面有關 Loading 的解決方案吧！果然，被我發現到 markdown-conversion。
太美好了，幸福就在不遠處，原來就在我們熟悉的老朋友 cloudflare 身上。
是用了一下，他不單純只是轉化 markdown ，連原始檔案的 metadata 也會前綴在 markdown 文章之上。
且我嘗試拿原始 pdf 和產出的 markdown 放到 notebooklm 上去做比對，看起來完整度也非常高。
然後很讚的點是，不需要付費（或著該說免費的額度已經很夠我使用）。
順帶一提，經過瘦身後的文字 markdown 內容，也大約有 11-15 萬的 token。真的是蠻可怕的內容資訊量…
Auto RAG 實作：簡簡單單，手指點一點就完工了
既然我原本的問題有順利解決，那或許是時候來嘗試新東西了 auto RAG ，他本身介面很簡單，把 RAG 的幾個重要步驟濃縮在 web 操作上。
- 載入 (Loading)： 各種資料來源轉化為 markdown，就靠前面提到的 markdown-conversion，然後儲存在 cloudflare 上的 r2 bucket。
- 切割 (Splitting)： 在它的介面當中，並無提及此件事情。而是直接整併在
內嵌底下，去定義chunk 大小還有重疊的百分比。 - 嵌入 (Embedding)： 目前無法調整，是採用他們家的 model
@cf/baai/bge-m3。 - 儲存 (Storage)： 儲存在他們家的向量資料庫內
Vectorize。 - 檢索 (Retrieval)： 此處介面能設定的參數是
比對臨界值和結果數量上限。 - 生成 (Generation)： 這裡的查詢 model 可以選一些其他的，目前預設選項是這組
@cf/meta/llama-3.3-70b-instruct-fp8-fast
還有一些像是查詢改寫和系統提示就不一一介紹了，可以直接上去玩玩看就明白。
結論：很不錯的嘗試和體驗
auto RAG 這服務我覺得是一個很創新的做法，把 RAG 整套包好讓客戶可以很方便的使用，我覺得是一項聰明的產品方向。
以往要自幹 RAG 還有資料清洗，最後還要在終端使用者上驗證效果，前期的整個建置成本太龐大冗長了。會讓許多業主只停留在 再想想看 的階段，而不會真的投入下去建置整套系統。
cloudflare 直接幫你把前面的部分都整理好，甚至連資料轉換的工具也開好 api。（這點我其實認為也是相當困難的一個痛點）
所謂的第二大腦，就這樣點一點按一按就能獲得還不錯的效果出來。在這方面得付出和推廣，cloudflare 真的該給他好幾個大拇指！股票買起來支持一下！
雖然就實質應用來看，我認為還沒有辦法到產品階段的應用。
我的測試方式是將近兩個月的華爾街日報內容進行解析，並向它提出一個具體問題：告訴我最近十月下半部的 Netflix 發生了什麼事情？股價變化如何？。然而，結果似乎仍然不甚理想。
以下是他的回答：
根據 Wall Street Journal 報導，Netflix 在 月下半部發佈了季度財報，雖然該公司的季度利潤和銷售額有所增加，主要由於會員增長、價格上漲和廣告收入增加，但由於巴西稅務當局的爭議相關費用，該公司的盈利仍低於預期。因此，Netflix 的股價在 10 月 日的報導中提到在星期三下跌了 10%（根據 10 月 25-26 日的報導）。
當然，也可能是因為我模型、參數還調整的不夠到位，甚至最一開始的 markdown 轉換時，就有資訊上的遺失但是我沒有檢查到。
然而，為了更好地診斷問題，理解 RAG 的核心價值至關重要。值得注意的是，RAG 的巧妙之處在於，它透過「分割」（Splitting）與「檢索」（Retrieval），徹底繞開了 LLM 的上下文視窗限制。即使我的原始文件有好幾份 15 萬 Token 所組成，LLM 在回答問題時，也只會看到與問題最相關的那幾個文檔碎片。
它實際處理的資訊量可能只有幾千 Token，從而確保了回答的精準度和效率。
雖然 RAG 擅長回答上述那樣具體的、有事實依據的問題，但我得到的欠佳結果可能意味著檢索步驟（Retrieval）出了問題（例如，沒有找到正確的知識碎片），或是針對複雜文件需要更進階的 RAG 策略。
一般來說，廣泛的總結性任務對於基礎的 RAG 來說通常不是一個好的選擇，因為這需要從許多零散的碎片中綜合資訊，這是一個已知的挑戰。
但至少還是一次不錯的 tinkering！
最大收穫：markdown-conversion
我認為這次實驗對我來說最重要的收穫就是 markdown-conversion 了，這個發現讓我有更多可以玩的東西。
可以直接開 worker 做成 web api ，就可以提供一些我在其他事物上的運用了，雖然透明度不及自己撰寫 python 來實現轉檔。但反正原始文件的資料來源對我來說不是機敏資訊的話，也就沒什麼好疑慮的了。