當資料不再只是批次：用 Pathway 建立可持續更新的即時 RAG 管線

我認為，RAG 系統真正難的地方，通常不是把一個模型接到向量資料庫，而是讓資料在第二天、第二週、甚至每一分鐘改變時，答案仍然跟得上。許多團隊第一次做 RAG，會先完成一條很漂亮的離線流程：讀取 PDF、切割文字、產生 embedding、寫入向量資料庫，最後讓聊天機器人查詢。Demo 當然可以成功，但一旦產品文件、客服知識、庫存資料或權限狀態開始變動，更新索引就變成另一套容易失控的批次工作。

Pathway 值得注意的地方，在於它不是單純再包一層向量資料庫，而是把 stream processing、real time analytics、LLM pipelines 與 RAG 放到同一個 Python ETL framework 裡。這個定位帶來的核心想法很簡單：不要把「資料更新」當成 RAG 之外的維運補丁，而是把資料來源、轉換、索引與查詢視為一張會持續運算的資料流圖。當上游資料改變，下游結果便可以依賴關係重新計算。

這篇文章不把 Pathway 當成萬能的 RAG 解答。我會從它解決的問題開始，走過一個可驗證的上手路徑，再談它的架構取捨、適用場景與不適合的地方。我的判斷是：如果你的 RAG 需要接住持續變動的來源，Pathway 比單次匯入工具更值得評估；如果你的需求只是每晚重建一次小型索引，它可能反而增加不必要的複雜度。

先講結論：Pathway 解的是「索引之後還會變」

一條傳統的離線 RAG 管線大致如下：

定期掃描資料來源。
找出新增或修改的文件。
重新切割內容並產生 embedding。
更新向量資料庫。
重新整理快取與查詢服務。

問題不在這五步本身，而在每一步之間都需要自行處理狀態、重試、重複事件、刪除事件與依賴關係。當資料來源從一個資料夾增加到雲端儲存、資料庫、訊息佇列或多個 API，批次腳本很快就會變成一個沒有明確資料模型的排程系統。

Pathway 的思路是以表格與資料流運算來描述這些步驟。資料來源被讀成持續更新的 table，清洗、切割、轉換與索引是對這些 table 的運算。這讓「新增一份文件」和「修改一份文件」不必被寫成兩條完全不同的流程，而是同一張資料流圖在新輸入下產生新的結果。

這裡有一個重要的界線：即時更新不等於每個 token 都能毫秒級完成，也不等於所有來源都自動具備完美的變更追蹤。真正的延遲會受到來源 connector、檔案大小、embedding 服務、模型推論、向量索引與部署資源影響。因此，Pathway 的價值比較接近「把增量資料處理的語意放進框架」，而不是承諾一個脫離環境的固定延遲數字。

它的核心模型：把 RAG 看成一張持續運算的圖

我會用四個層次理解 Pathway。

第一層：輸入來源

來源可以是持續變動的檔案、資料表、事件流或其他 connector。對 RAG 來說，這一層決定系統能不能正確觀察新增、修改與刪除。若來源只提供一次性的匯出檔，後面的管線再即時，也只能在下一次匯出後才看到變化。

第二層：資料轉換

原始資料通常不能直接送進 embedding 模型。你需要處理編碼、欄位標準化、文件切割、metadata、權限標記與版本資訊。這些轉換最好保持可測試、可重跑，並且把來源識別碼一路帶到最後，否則查到內容時很難回溯原始文件。

第三層：LLM 與索引運算

在這一層，管線可以接 embedding、摘要、分類或其他 LLM 運算，再把結果寫進向量索引。Pathway 官方定位包含 LLM pipelines 與 RAG，但這不代表你可以忽略模型本身的限制。Embedding 模型換版、chunk size 改變或 metadata schema 改變，都可能讓既有索引需要重新評估。

第四層：查詢與服務

使用者問題進入後，需要完成 query embedding、相似度搜尋、metadata filter、上下文組裝與回答生成。這條查詢路徑和資料更新路徑可以互相配合，但不應混為一談。資料更新速度快，不表示回答一定正確；回答品質仍取決於召回、權限、提示詞、模型與引用策略。

這種分層方式也提醒我們：Pathway 主要幫忙處理資料流與管線協作，並不會替你決定什麼內容可以被回答、如何執行租戶隔離、怎麼做 prompt injection 防護，或如何為高風險答案建立人工審核。

如何開始：先做一個能驗證更新的最小管線

我建議不要一開始就把企業所有來源接進來。先建立一個最小實驗，驗證三件事：資料能否被讀取、內容變更是否能傳到索引、查詢是否能拿到可追溯的上下文。

1. 準備環境與依賴

Pathway 是 Python framework。實際部署前，先依官方文件確認支援的 Python 版本、資料來源 connector、模型供應商與向量索引方式。專案本身的 README 提供安裝與 quickstart 入口；正式環境則應使用 uv、容器或團隊既有的依賴管理方式固定版本，避免本機能跑、部署環境卻因依賴漂移而失敗。

最小安裝可從 Python 套件開始：

pip install pathway

這行指令只代表安裝套件，不代表 RAG 已經完成。接著你需要準備一個小型資料來源，例如包含數份 Markdown 或純文字文件的目錄，並在文件中保留標題、來源 URI、修改時間與權限等 metadata。

2. 先驗證來源與更新事件

第一個可驗證任務不是問模型問題，而是確認資料變更確實被管線看見。啟動最小資料流後，先放入一份文件，觀察輸出是否出現；接著修改文件內容，再確認下游資料是否只更新受影響的紀錄。最後移除文件，檢查索引或輸出是否有對應的刪除語意。

這個測試很重要，因為很多「即時 RAG」其實只驗證了新增，沒有驗證修改與刪除。若刪除事件無法傳遞，系統就可能繼續引用早已撤下的政策；若修改事件被當成新增，則會出現重複片段與舊版本競爭。

3. 再接上 embedding 與查詢

來源事件穩定後，再加入文件切割與 embedding。切割策略不要只用固定字數：程式碼、表格、規章條款與 FAQ 的結構不同，應至少比較段落切割、標題感知切割與 metadata filter 對召回品質的影響。

查詢結果也要能回到來源。每個 chunk 至少保留文件識別碼、來源連結、版本或修改時間，並在回答中提供引用。沒有追溯資訊的 RAG，即使答案看起來流暢，也很難讓使用者判斷它是否使用了最新內容。

4. 把觀測性放在第一版

對即時管線，我會在第一版就記錄事件時間、處理延遲、失敗重試、embedding 請求耗時、索引更新時間與查詢召回結果。若只記錄最後的回答文字，你看不到問題究竟發生在 connector、切割、模型、索引還是權限過濾。

最低限度的驗證清單可以是：

新增文件是否在預期時間內可被查詢。
修改文件後，舊片段是否不再被召回。
刪除文件後，回答是否停止引用它。
同一事件重送時，是否造成重複資料。
embedding 或 LLM 暫時失敗時，是否能重試且不破壞既有索引。
權限欄位是否一路傳到召回與回答階段。

Pathway 真正有價值的地方

1. 更新邏輯和資料邏輯放在一起

批次腳本常把「同步」當成外部排程，把「索引」當成另一個服務。Pathway 讓資料來源、轉換與下游輸出以同一個資料流模型描述，團隊比較容易看清楚一筆資料如何一路流動。這對需要持續接資料的知識庫、監控摘要與文件問答尤其有幫助。

2. Python 入口降低實驗門檻

對已經使用 Python 做資料工程或 LLM 應用的團隊，直接在熟悉的語言中組合來源、轉換與模型呼叫，比重新學一套完全不同的 DSL 容易開始。這不代表 Python 自動解決生產環境的併發、資源與部署問題，但它能讓概念驗證更靠近最後的程式碼。

3. 同一套思路可延伸到非 RAG 場景

Pathway 的定位不只包含文件問答，也包含串流處理與即時分析。這表示同一套增量計算思路，可以用在資料清洗、事件聚合、監控、推薦前處理或需要持續更新的 LLM workflow。對不想把每個 AI 功能都包成一次性腳本的團隊，這種一致性是長期價值。

限制與常見誤區

第一個誤區是把框架當成資料品質保證。Pathway 能幫你組織資料流，但來源資料是否完整、時間戳是否可信、文件刪除是否真的可觀察，仍然是你的責任。上游沒有提供可靠變更資訊時，框架只能採用掃描或重算等替代策略。

第二個誤區是只用 Demo 的召回效果評估系統。RAG 上線後，最常見的問題不是「完全找不到」，而是找到舊版本、越權內容、相似但不適用的段落，或在資料更新期間同時看到新舊版本。因此，評估集要包含修改、刪除、權限變更與相互矛盾的文件。

第三個誤區是忽略成本。每次文件變更都可能觸發切割、embedding、索引與快取更新。高頻資料來源若沒有去重、批次合併、背壓與失敗重試策略，雲端 API 成本和運算資源會隨事件量上升。即時不應被理解成「所有工作都立刻做」，而是要根據業務新鮮度設計合理的處理窗口。

第四個誤區是沒有處理安全邊界。文件內容可能包含惡意 prompt、偽造的系統訊息或不應暴露的資料。RAG 應用需要把文件當成不可信資料，對來源、租戶、權限與引用做明確控制，並且在回答層加入拒答與人工覆核策略。框架的資料流能力不能取代安全設計。

誰適合先試，誰不必急著換

我會優先推薦以下團隊做小規模試點：

文件、政策、FAQ 或產品資料每天都在變動。
已經有 Python 資料工程能力，希望把批次同步逐步改成增量管線。
需要把多個資料來源整理成可追溯的 LLM 上下文。
願意先建立事件、索引與回答品質的觀測指標，而不是只看 Demo。

以下情況則不必急著採用：

資料量很小、每天重建一次索引已經足夠。
團隊沒有維護長時間執行服務、connector 與模型 API 的能力。
需求主要是一次性文件轉換，而不是持續更新的資料流。
目前連資料權限、來源識別與刪除語意都還沒有定義。

我的建議是先用一個低風險、可回滾的資料集做試點，並把離線批次版本保留作為基準線。只有當 Pathway 的增量更新真的降低延遲、減少同步腳本或改善資料新鮮度，才值得把更多來源搬上去。

最後的判斷

Pathway 最值得看的不是「它也能做 RAG」，而是它把 RAG 背後常被忽略的資料生命週期拉到前景：來源如何變動、轉換如何重算、索引如何同步、刪除如何傳遞，以及查詢如何取得可追溯上下文。這個視角比單純比較向量資料庫功能更接近實際產品問題。

如果你的系統需要持續吸收變動中的資料，Pathway 提供了一條值得驗證的 Python 路徑：先用最小資料流驗證新增、修改、刪除，再接 embedding、索引、查詢與觀測性。反過來說，如果需求只是低頻、靜態、小規模的文件問答，成熟的批次工具可能更簡單，也更容易維護。

我會把 Pathway 的導入判斷濃縮成一句話：當「最新資料」是產品需求，而不是 Demo 加分項時，才值得用持續運算的方式重新設計 RAG。

參考資料