3KProject Data Pipeline Notes

我怎麼把 RAG / ETL 做成一條真的能落地的資料生產線

很多人一提到 RAG，腦中想到的還是「向量搜尋 + LLM 回答問題」。但我在 3KProject 裡做的事情，其實更像一條資料製造線：先從原文抽材料，再把人物、關係、事件整理成可以審核、可以重跑、最後還能直接餵給 NPC brain 與 Cocos UI 的資產。

Grounded 每筆資料都盡量能回到 sourceRef、sourceQuote、chapterNo，不讓答案離開原文證據。

Deterministic 先讓腳本把結構和證據整理好，再讓 LLM 做 reviewer，而不是直接當 author。

Runtime-ready 最後不是停在文件，而是輸出成 runtime profile，供 NPC brain API 與 Cocos UI 直接消費。

先講一句最重要的話

這條管線的目標，不是讓模型直接講答案，而是把原始文本變成一批可追蹤、可回放、可重跑的知識工件。

如果用比較白話的方式說，這整套系統不是在做「問 AI 一個三國問題，讓它回答我」。它更像一間小工廠：原料是文言文本，製程是抽取、對齊、審核、修補，最後出貨的是可以進遊戲 runtime 的資料包。

我現在對這條管線的理解很簡單：RAG 負責把資料找對，ETL 負責把資料做穩，review loop 負責把品質補起來，runtime export 才負責把它送進遊戲。

整條流程其實長這樣

先不要急著看腳本名稱。先把它想成六個大步驟：原文進來、人物對齊、事件整理、review 分流、修補回圈、最後輸出給遊戲。只要先抓到這條主線，後面那些工具名就不會看起來那麼嚇人。

圖 1：如果先把這條總流程記住，後面每支腳本其實都只是這六個步驟裡的其中一個工位。

為什麼我一直強調 source-grounded？

因為一旦資料不能回原文，後面的 review 幾乎都會變得很虛。你會知道「模型好像講得通」，但你不知道它到底是從哪裡來的。對遊戲來說，這種資料一旦被寫進 runtime，後面會越修越亂。

圖 2：資料先回原文，再進 review。這樣 reviewer 和 LLM 才不是在對空氣講話。

這層真正解決什麼？

它在解決「同一個人有很多名字」和「一句話到底有沒有真的提到目標人物」這兩個最容易污染後續資料的問題。

為什麼值得先投資？

因為一旦 retrieval key 沒有先標準化，後面的事件、關係、人物 context 都會一起偏掉，最後整條管線都跟著失真。

真正最重的，其實是中間這段 ETL

我覺得這份文件最有價值的地方，不是在列很多腳本，而是在提醒我：Extract 只是把材料撈起來，真正花力氣的是 Transform。因為 Transform 要決定哪些資料先進 review、哪些可以進 staging、哪些應該丟進 repair queue。

圖 3：A 題不是結束，B 題也不是失敗。它只是告訴你這批資料下一步該去哪裡。

我很喜歡這個設計，因為它把 review 從單純的「看過就算」變成一個真正有出口的流程。A 題進 ready，B 題進 repair queue，整體就開始有閉環，而不是每次 review 完又散掉。

為什麼 LLM 只當 reviewer？

因為這樣它的不穩定性會被限制在 proposal 和 review 層，不會直接污染 canonical runtime data。

repair queue 有什麼價值？

它把「知道哪裡不好」進一步變成「下一輪要修哪一類問題」，像 fill location、repair relationship edges 這些都能被排程。

最後一段才是把資料送進遊戲

很多資料工程最後卡在 staging，做完看起來很漂亮，但沒有真的送到產品裡。我這條線最實際的一件事，是它最後真的會 export 成 runtime-general-profiles，再透過 NPC brain server 的 API 給 Cocos UI 用。

圖 4：對我來說，這條線真正「成形」的標誌，就是它最後不是留在 pipeline 報表，而是真的被 UI 用起來。

這一步很重要，因為它讓整條知識管線不是停在研究用途，而是變成遊戲 runtime 的 lookup layer。換句話說，它開始有產品價值，而不只是資料整理價值。

現在做到哪裡？有哪些明顯收穫？

如果只看目前數字，我會把它理解成「骨架已經站起來了，但 repair queue 還很重」。目前已有 20718 筆 resolved mentions、171 筆 ready events、1601 個 source event packets、1766 筆 repair tasks。這代表基礎產線已經跑起來，但把 backlog 消化乾淨還需要更多輪。

現在已經做對的事

不再只是向量搜尋加 LLM。資料現在會先回 source、走 review、進 staging，再 export 成 runtime profiles。這已經是正式的知識生產線，而不是聊天機器人。

接下來最該補的地方

真正的關鍵不是再叫更多模型，而是把 repair queue 一筆一筆消化掉，讓 B backlog 真的轉成 A 或可 publish 的資料。

我目前對這條線的判斷是：它已經不是概念驗證，而是可以穩定推進覆蓋率的正式 pipeline。下一步重點不在「有沒有方法」，而在「修補速度能不能跟上新增速度」。

最後的理解方式

如果要我用一句最不拗口的方式總結這篇文章，我會這樣說：這套系統是在把三國文本從「人看得懂的內容」轉成「遊戲 runtime 用得動的知識資產」。

它不是單純的 RAG，也不是單純的 ETL。它是 RAG 負責找對資料，ETL 負責做穩資料，review loop 負責修補資料，runtime export 負責把資料送進產品。

所以這篇第三篇文章真正想傳達的，不是腳本清單，而是一個更實際的觀念：當資料最終要進遊戲時，你需要的不是一個會回答問題的模型，而是一條能穩定製造知識資產的管線。