為什麼 Databricks 的 RAG 是平台戰，不是功能

Databricks 把 RAG 當成端到端平台問題，這不是包裝，而是正確的產品判斷。

Databricks 把 retrieval-augmented generation 當成基礎設施，而不是一個聰明的提示詞技巧，這個判斷是對的。因為 RAG 成敗不只在模型，而在資料管線、切塊品質、檢索準確度、評估、監控、治理與權限控制是否一起成立。上游資料一亂，檢索就亂；檢索一亂，回答就亂；沒有監控，漂移就會在上線後才爆炸。RAG 不是單點功能，它是一整套系統。

第一個論點：RAG 失敗，通常不是因為 prompt 不夠好

最常見的錯誤，是把 RAG 想成「把文件塞進 prompt」的升級版。這種想法會把注意力放在模板微調，卻忽略真正的難點：如何從混亂的企業資料中穩定找出正確證據，再把證據交給模型去生成答案。RAG 的基本流程雖然簡單，但簡單不等於容易，尤其當資料來源包含 PDF、wiki、圖片、SQL 表與 API 回傳時，問題根本不是 prompt，而是 ingestion、indexing 與治理。

具體來說，若文件版本過期、段落切分錯誤、表格轉文字失真，模型就會在看似合理的上下文裡產生自信錯誤。這也是為什麼 Databricks 的做法強調先有資料管線，再談 chain。你不能期待一個索引自混亂資料、又缺乏權限意識的系統，靠更長的 prompt 變得可靠。企業 RAG 的第一個瓶頸不是語言能力，而是資料工程能力。

第二個論點：評估與監控不是收尾，而是核心能力

Databricks 把 evaluation 和 monitoring 放在中心位置，這一點非常關鍵。RAG 的品質不是只由模型決定，而是由 retrieval quality、chunking strategy、prompt assembly 與 generation 一起決定。任何一個上游細節變動，例如文件格式調整、欄位名稱改寫、索引更新，都可能讓檢索結果改變，最後導致答案偏掉。只看「有沒有回應」，根本不能證明系統可用。

真正的產品現實是，demo 看起來正常，不代表 production 會正常。新文件進來、schema 改了、查詢量升高、使用者開始問更難的問題，RAG 的失真就會慢慢浮現。Databricks 把開發期評估與上線後監控分開，這不是流程潔癖，而是工程常識。開發期回答的是「設計對不對」，監控回答的是「資料變了之後還對不對」。少了這一層，RAG 只是一個會逐漸退化的聊天介面。

反方可能怎麼說

最強的反對意見是：這根本不需要平台，很多團隊用 vector database、LLM API，再加幾百行程式碼，就能做出可用的 RAG。這個說法對小型內部工具是真的。若只是快速驗證需求，或者資料量很小、權限要求也不高，平台化確實可能太重，會拖慢第一次上線。

另一個合理質疑是，Databricks 的敘事把企業級需求講得太滿，彷彿每個 RAG 都要治理、血緣、ACL、監控一次到位。對早期團隊來說，這會變成過度設計，甚至把產品速度壓垮。不是每個 use case 都值得先建一套完整平台，再去做應用。

但這些反對意見只成立在 demo 或低風險場景。只要 RAG 進入業務核心，問題就會從「能不能答」變成「答得是否正確、可追溯、可控管」。這時候缺的不是更花俏的 prompt，而是資料來源、索引、權限、評估與觀測能力。Databricks 並沒有說所有專案都要一開始就重裝平台，而是指出：只要 RAG 真的有價值，它遲早會變成系統問題，這不是偏見，是規模化後的必然。

你能做什麼

如果你是工程師，請把 RAG 設計成可測試的流水線：ingestion、indexing、retrieval、prompt assembly、generation、evaluation、monitoring，每一段都要能單獨驗證。如果你是 PM，請把成功指標定義成答案品質、資料新鮮度、延遲與權限正確性，而不是只看「有沒有回覆」。如果你是創辦人，優先選擇那些有專有資料、審計需求與權限邊界的場景，因為只有在這種場景裡，平台型 RAG 才會比薄薄一層聊天介面更有護城河。