015 · 本地優先的混合 RAG 全流程
從切塊策略、混合搜尋到守門邏輯，示範一套不靠額外框架、只用本地小模型撐起來的 RAG 聊天機器人架構。
原標題：Bypassing the Multimodal Tax: Hybrid RAG, SQL RRF & UI Telemetry - Abed Matini, Ogilvy
重點摘要
- 文件別急著整包上傳一股腦把 PDF 丟給聊天機器人，會先燒掉一批 token，還看不到切塊之後的樣子；先在本機轉成 markdown 再上傳，成本更低也更容易掌控。
- 切塊策略要挑對場合依標題、依段落、固定字數、依句子這四種切法各有適合的資料型態，員工手冊適合用標題切，雜亂資料才需要固定字數搭配重疊。
- 能寫死的邏輯就別交給 LLM查日期這類確定性任務直接寫成 Python function，不必讓 agent 多繞幾圈，換來更快的回應與可測試的行為。
- 混合搜尋兩者缺一不可向量搜尋找語意相近的內容，BM25 抓精確的關鍵字（型號、藥名），兩邊結果再用 RRF 合併排序，才不會該精準的地方也只給出「差不多」的答案。
- 守門邏輯要寫進程式碼把該擋的問題（例如醫療建議）在送進 LLM 之前就用程式碼邏輯攔下來，結果穩定又能寫測試，不會像純靠提示詞那樣時靈時不靈。
- 資料乾淨，小模型也夠用從 7B 換成 0.5B 的 Qwen 2.5 之後速度變快，只要先把資料處理乾淨，小模型一樣能給出準確答案，沒把握時也會老實說不知道。
時間軸
時碼點下去會跳到影片的那一段。
| 時碼 | 段落 | 重點 |
|---|---|---|
| 00:00 | 開場：講者與主題 | Abed Matini 是 Ogilvy 的資深後端工程師，這場要示範免框架的 hybrid RAG 架構，搭配右側的即時 demo。 |
| 01:04 | 兩個核心問題 | 上傳文件就先燒掉一批 token；正式環境的聊天機器人工具愈疊愈多，難以維護。 |
| 02:28 | 三段式架構規劃 | 整場拆成上傳文件、切塊、搜尋、觀測性三大段，並展示一個 FAQ 助理 demo 的介面。 |
| 05:05 | 技術棧總覽 | 後端用 Python、FastAPI，前端 React，資料庫 PostgreSQL，Docker 容器化，模型全部跑在 Ollama 本地，用 Langfuse 追蹤延遲。 |
| 08:07 | 兩種資料前處理方式 | 直接丟文件進聊天機器人會燒 token，也看不清切塊結果；另一種是先在本機轉成結構化資料再上傳，成本更低。 |
| 10:39 | 四種切塊策略開篇 | 進入後台展示，文件會先轉成 markdown，再依不同策略切塊，共有四種切法。 |
| 12:13 | 整份文件不切塊的代價 | 直接上傳整份 28 頁員工手冊，簽名、日期這類沒有意義的片段也會被切進去，拖慢速度又降低準確率。 |
| 15:50 | 依標題切塊的實測效果 | 依標題切成一問一答的 chunk 後，員工保費問題能準確答出 90%／75% 的數字，還能追溯到對應段落。 |
| 17:54 | 依段落切塊 | 不看標題，單純以段落為單位切塊，資料一樣乾淨，只是切分邏輯換成段落。 |
| 19:24 | 固定字數切塊 | 針對沒有結構的雜亂資料，改用 512 字元一段、重疊 64 字元的做法，避免斷點遺漏語意。 |
| 21:40 | 依句子切塊與即時案例 | 以句數為單位切塊，適合維修公告這類要馬上上線的短訊息，截圖也能先轉文字再直接索引。 |
| 26:00 | 用 Python 函式取代 agent 迴圈 | 查日期這類確定性任務直接寫成 Python function 呼叫，不讓 LLM 重複推理，換取速度與可測試性。 |
| 29:34 | 混合搜尋：向量加關鍵字 | 語意相近的內容會在向量資料庫裡靠在一起，但遇到型號、藥名這類必須完全命中的情境，還是要靠關鍵字比對。 |
| 31:21 | BM25 與 RRF 排序 | 向量負責找語意最近的內容，BM25 負責抓精確關鍵字，兩者結果再合併排序，只取最相關的前幾筆。 |
| 34:20 | Direct RAG 與 agent 模式的取捨 | Direct RAG 走固定管線、路徑清楚，適合重合規的場景；agent 模式能呼叫更多工具，但較不可控也比較慢。 |
| 37:20 | 用程式碼把關，擋在 LLM 之前 | 醫療建議之類的問題在送進 LLM 前就用程式碼邏輯攔下來，系統提示看起來很短，是因為規則寫進了程式碼而不是提示詞。 |
| 42:16 | 換小模型反而更穩 | 從 7B 模型換成 0.5B 的 Qwen 2.5 後速度變快，資料先清理過的話，小模型反而更少產生幻覺，沒把握時會直接說不知道。 |
| 44:16 | 總結重點 | 核心是先把文件轉成結構化 markdown，全程沒用付費框架，只靠 Ollama 加 Langfuse，未來可延伸到其他資料來源。 |
值得記的話
名詞與人物
| Ogilvy | 講者任職的廣告集團，這場只提到他任職於此，沒有進一步說明 |
|---|---|
| Docling | 把 PDF、PowerPoint、Word 等文件轉成 markdown 的工具，是這套流程的第一步 |
| Ollama | 讓聊天模型與嵌入模型都能在本機執行的工具，這場的示範全程沒有呼叫外部 API |
| Qwen 2.5（0.5B） | 講者實際展示中使用的聊天模型，參數量小、體積約 400MB，也拿來跑 agent 模式 |
| BGE-M3 | 講者用來把文件內容轉成向量、存進資料庫的嵌入模型 |
| BM25 | 用來做關鍵字比對的稀疏檢索演算法，負責抓完全命中的詞，例如商品編號或藥名 |
| RRF | 把向量搜尋與 BM25 關鍵字搜尋的結果合併排序的方法，是這場標題提到的技術之一 |
| Langfuse | 講者用來追蹤每次對話用了什麼模型、回傳哪些片段、花多少延遲與成本的觀測工具 |
延伸
- 講者提到未來想把這套架構延伸到客服情境，處理商品資訊與價格計算，但沒有展開說明。
- 提到 reranker 會對混合搜尋的結果再評分，但沒有細講實際怎麼實作。
- 結尾提到這套架構之後也可以延伸到型錄或串接其他資料庫，但沒有進一步說明做法。