車用研發 AI 知識系統:法規、測試報告、DFMEA 文件的 RAG 落地

一台原型車在高溫測試場跑出一組異常數據。工程主管想知道:這個煞車模組的 DFMEA 裡,當初有沒有把這個失效模式列進去?對應的測試報告是哪一版?那份報告引用的法規條文,是 UN R13-H 還是國內等效版本?

三個問題,分屬三份文件、三個部門、三個檔案系統。在多數車廠與 Tier 1 供應商裡,回答這三個問題要花掉一位資深工程師半天,而且答案的可信度取決於他記不記得檔案放在哪個資料夾的哪一版。

車用研發的知識,不是「多」的問題,是「規範化又互相牽連」的問題。這正是一般的企業搜尋或通用聊天機器人會翻車的地方。

為什麼車用研發 AI 不能只是「接個 ChatGPT」

先講清楚一件事。把研發文件全部丟進向量資料庫、前面接一個大模型,這種做法在 Demo 場合很好看,拿到生產環境會出事。

車用研發文件有三個特性,決定了它的檢索系統必須被特別設計:

第一,強結構化。DFMEA 是表格,每一列是「失效模式 — 影響 — 嚴重度 S — 發生度 O — 偵測度 D — RPN — 對策」的固定欄位;測試報告有測項、判定基準、量測值、Pass/Fail;法規文件有條、款、項的階層編號。把這些切成一段一段的純文字塊,結構就碎了,模型會把 A 失效模式的嚴重度接到 B 對策上,給你一個看起來通順、實際錯誤的答案。

第二,版本即生命。一份 2021 年的測試報告引用的是舊版法規,拿它來回答 2024 年的設計問題,不是「不夠新」,是直接錯。車用文件的每一次工程變更(ECN/ECR)都會讓一整串關聯文件失效。

第三,答案要能上法庭。當一個失效真的釀成召回或訴訟,「AI 說可以」不是答辯。你需要指出:這個結論來自哪一份文件、哪一版、哪一頁、哪一列,以及當時是誰簽核的。可追溯,不是加分項,是及格線。

把可稽核性設計進檢索層,而不是事後補

我們在車用研發 AI 的專案裡,做法和一般 RAG 有幾個關鍵差異,核心只有一句:讓每一個答案都能反查到它的來源證據。

用結構感知的切分,而不是固定長度切分。 DFMEA 以「一列失效模式」為最小檢索單元,連同它的 S/O/D 值與 RPN 一起保留;測試報告以「一個測項」為單元;法規以「一款」為單元。這樣模型拿到的每一塊都是語意完整的,不會把嚴重度和對策拆散。

每一塊都掛上結構化的中繼資料(metadata)。 這是可稽核性的地基。每個知識塊至少帶著:文件編號、版本號、生效日期、車型平台、系統零件層級、簽核人、以及它引用與被引用的文件關聯。檢索時可以用這些欄位做硬性過濾——「只查現行版、只查這個平台、只查煞車系統」——而不是讓語意相似度自己亂猜。

答案強制附帶引用,查不到就說查不到。 系統回傳的每一句結論後面,綁定它所依據的文件塊 ID。工程師點下去,直接跳到原始 DFMEA 的那一列、那份報告的那一頁。如果檢索的信心分數低於門檻,系統回「現有文件中查無對應依據」,而不是硬掰一個。在研發場景,一個誠實的「查不到」遠比一個流暢的錯誤有價值。

下面這張表,是我們評估車用研發知識系統時,實際會逐項對照的差異:

一個真實會發生的劇本

回到開頭那組高溫異常數據。在設計好的系統裡,工程師的操作是這樣的。

他輸入:「這個平台的前煞車模組,DFMEA 有沒有涵蓋高溫下的煞車衰退失效?」系統先用中繼資料把範圍鎖定在「此車型平台、煞車系統、現行版 DFMEA」,再做語意檢索,回傳兩列相關失效模式,並附上 RPN 值與已規劃對策,每一列都可點回原表。

他追問:「這兩個失效模式對應的測試報告,最新一版的判定結果是什麼?」系統沿著文件關聯,找到現行版報告的對應測項,回報 Pass/Fail 與量測值,並標明報告版本與生效日。

他再問:「這份報告引用的法規,現在還是最新的嗎?」系統比對法規文件的版本中繼資料,指出報告引用的是前一版,並提示現行版的差異條款。

三個問題,兩分鐘,而且每一個答案都能被工程主管、稽核、甚至外部審驗機構逐條反查。這不是把人換掉,是讓資深工程師的半天,變成他確認判斷的兩分鐘。

難的從來不是模型

需要誠實承認的是:這類系統做得成不成,九成不在模型選型,在文件本身。DFMEA 的欄位有沒有填完整、測試報告的版號規則亂不亂、法規對照表有沒有人維護——這些現場的真實狀況,決定了檢索的天花板。我們踩過的最大的雷,就是低估了「把既有文件整理到可被機器可靠解析」這件事的工作量,它往往比建檢索管線還久。

所以我們的做法,是工程師直接進到客戶的研發現場,和 PLM、文件管理系統對接,把資料治理和檢索設計綁在一起做,一路扛到工程師願意在日常設計評審裡真的打開它來用。Demo 那天能答對三題不算數;半年後它還在被工程團隊當成第一個查詢入口,才算數。