~/blogenterprise-ai-context-platforms.md
cchu@nycu:~/blog$ cat enterprise-ai-context-platforms.md
2026.06.305 min[enterprise-ai][rag][data-platform][plm]

企業 GenAI 的系統題：Context Platform

整理一份企業 GenAI 研究報告後，我對資料平台、CAD/BOM/PLM、RAG、治理和 POC 順序的筆記。

我最近整理了一份關於企業 GenAI、資料平台、CAD/CAM/CAE/PLM 與企業系統整合的研究報告。報告很長，大約兩百頁，涵蓋資料庫、warehouse、lakehouse、ETL/ELT、Text-to-SQL、vector database、CAD/BOM/PLM、ERP/MES/CRM，以及 POC 與治理框架。

讀完後，我覺得最有用的是一個判斷：企業 AI 的主戰場會回到既有系統。難點在資料、權限、版本、流程和人類審核，這些東西要被整理成模型可以使用、也能被人驗證的 context。

從模型中心，移到系統中心

第一波企業 GenAI prototype 常見的做法很直接：選一個 LLM，接一個 vector database，做一個聊天介面，展示幾個問答。這種 demo 很快，也很容易讓人看到想像空間。

但企業裡的問題通常不會停在 demo。你需要知道哪個系統是 source of truth，哪個資料版本已經 release，誰可以看哪張圖、哪個 BOM、哪筆變更紀錄。你還要處理資料更新、刪除、權限變更、稽核、成本、延遲，以及錯誤答案出現後誰負責修。

報告反覆指向同一個核心：企業 GenAI 需要一種新的系統介面，讓人用自然語言、檢索、摘要和草稿，操作原本分散在資料庫、文件、工程系統和 workflow 裡的知識。

我會把它叫做 Context Platform

報告裡有一個詞我很喜歡：context platform。

這個詞把設計問題講得比較準：模型怎麼拿到可信的上下文。這個上下文必須滿足幾個條件：跟問題相關、夠新、符合權限、有來源、能追溯、能評估。

一個合格的 context platform 至少要處理這些工作：

  • 登記 source system：資料庫、warehouse、PLM、CAD vault、ERP、MES、CRM、文件庫。
  • 抽取與同步：透過 API、connector、CDC、file export 或事件，把資料帶進可處理的區域。
  • 解析與正規化：把 PDF、CAD derivative、BOM、規格書、change order、表格和 log 轉成可搜尋的 evidence。
  • 補 metadata：part number、revision、owner、lifecycle state、permission、source URL、extraction time。
  • 建索引：SQL、keyword、vector、graph 都可能需要，單靠 embedding 通常不夠。
  • 做 retrieval orchestration：先判斷問題類型，再選擇 SQL、全文搜尋、向量搜尋、metadata filter 或 graph traversal。
  • 產生回答與 citation：答案要能指出來源，不該只給一段流暢文字。
  • 評估與監控：retrieval quality、answer correctness、citation correctness、latency、cost、policy violation 都要留下紀錄。
  • 控制 action boundary：初期讓 AI 讀取、分析、產生草稿，不要直接提交工程、採購、生產或客戶承諾。

這裡的重點是組合。Vector database 是一個 component。SQL 也沒有消失，它會跟 semantic layer、keyword search、vector search、graph、workflow tool 一起出現在同一個 query plan 裡。

CAD/BOM/PLM 是一級 context source

報告最該留下的提醒：CAD/CAM/CAE/PLM 不能被放進資料平台故事的附錄。對製造和工程團隊來說，這些系統就是高價值知識本體。

CAD 檔有幾何、feature、drawing、annotation。BOM 有結構、數量、替代料、上下游關係。PLM 有 lifecycle state、release status、effectivity、change order、owner、permission。MES、QMS、ERP、service system 又補上製造、品質、供應和客戶現場回饋。

這些資料如果只被切成文字 chunk，很多重要資訊會不見。舉例來說，同一個零件號可能有不同 revision；一張 PDF drawing 可能只是 supporting evidence，真正決定 release state 的是 PLM；一個 material substitution 也不能只看 ERP 庫存，還要看 PLM 規格與 approved supplier。

所以我會把工程 AI 的起點放在 evidence package。每次回答都應該帶著來源物件、版本、權限、假設、缺口和 reviewer 可以打開檢查的引用。對工程和製造來說，這比回答漂不漂亮重要。

POC 順序要先學會查證，再靠近行動

報告建議的 POC portfolio 很務實，我會保留這個順序：

  1. CAD/BOM engineering knowledge RAG：先用 drawing、BOM、spec、change record 做一個能回答工程問題、能引用來源的 retrieval system。
  2. PLM change-impact assistant：再加入 product structure、lifecycle state、change order 和 permission，產生 change review packet。
  3. Existing-database vector search：測試既有 Postgres/SQL/Oracle/MySQL 類平台能不能承擔 bounded RAG，不急著多養一套 retrieval infra。
  4. Warehouse-native AI SQL：測試 Snowflake、BigQuery、Databricks 或 Fabric 類平台上的 summarization、classification、Text-to-SQL、governed analytics。
  5. CAM knowledge assistant：等前面的 retrieval、citation、permission、evaluation 比較穩，再碰 machining strategy、tooling、process plan 這種風險較高的知識輔助。

這個順序的好處是每一步都產生 reusable asset。第一個 POC 產生 corpus schema、metadata schema、citation format、gold questions、failure taxonomy。第二個 POC 加上 PLM lifecycle 和 product graph。後面的 platform benchmark 可以用同一批問題和 evidence，比較結果才有意義。

治理要進到系統設計

企業 AI governance 很容易變成文件夾：risk register、policy、approval checklist。這些東西需要有，但不能只停在文件。

對 RAG 和 agent system 來說，治理在 retrieval 前後就發生了。權限要在 context assembly 前套用，restricted evidence 不該先進模型再靠 prompt 約束。source authority 要出現在回答裡，讓使用者知道這段話來自 PLM、drawing、warehouse table，還是 derived index。錯誤答案要留下 trace：question、retrieved context、model version、prompt、tool call、answer、reviewer feedback。

評估資料集也要提早做。不要等 demo 漂亮了才問準不準。比較好的 POC 會包含 known-answer cases、known-evidence cases、adversarial cases、ambiguous questions、no-answer questions、permission tests。工程場景還要測 stale revision、相似 part number、restricted document、obsolete drawing、missing lifecycle state。

我也喜歡報告裡的 action level：

  • Level 1：read only，讀取並引用 evidence。
  • Level 2：analyze，摘要、比較、標記風險。
  • Level 3：draft，產生 ECR、review packet、ticket draft。
  • Level 4：route，把草稿送進既有 workflow。
  • Level 5：execute，真正改資料、下單、排程或釋出。

早期 POC 最好停在 Level 1 到 Level 3。系統要先學會說清楚它看到了什麼、沒看到什麼、憑什麼這樣回答。

我會怎麼開始

如果只給九十天，我會做一件窄但有判斷力的事：CAD/BOM engineering knowledge RAG。

資料包不用一開始就很大。50 到 200 張 drawing/spec、5 到 20 份 BOM、一些 change summary、part metadata、revision metadata 就足夠開始。重點是資料要有壞例子：過期版本、缺 metadata、相似料號、權限受限文件、找不到答案的問題。

前十五天先定 use case、source owner、data sensitivity、POC charter。接著做 corpus、metadata、baseline retrieval。第三階段建立 gold questions 和 scoring rubric。第四階段做 hybrid retrieval、citation、permission filter。最後補 audit log、cost telemetry、red-team cases 和 decision package。

最後的輸出不該只是一個 demo。它應該是一份決策資料包：哪種問題能答，哪種不能答；citation 到什麼細度才夠；permission 有沒有真的生效；latency 和 cost 是否能接受；domain expert 給幾分；下一步該 harden、pivot、pause，還是改找 vendor 或 partner。

這篇筆記先停在這裡。對我來說，企業 GenAI 接下來最該做的，是把 context、權限、source authority、evaluation 和 workflow boundary 做成工程資產。模型會換，embedding 會換，vendor 會換；留下來的是你怎麼把企業裡真正有價值的知識整理到可查、可信、可追蹤。