車廠售後維修知識庫 RAG 怎麼建?維修手冊、TSB、故障碼一次檢索

維修技師舉手問一個問題,平均要翻幾份文件才找得到答案?我們在一家車廠售後中心蹲點時數過:維修手冊、TSB(技術服務公告)、故障碼定義、召回通知、料件相容表,一個「引擎警示燈間歇亮起」的案子,老師傅平均開了四份 PDF、切換兩套系統,花了十一分鐘。年輕技師更慘,他們根本不知道那份關鍵 TSB 存在。

這就是車廠售後 RAG 要解的事。不是做一個會聊天的機器人,而是讓技師在維修工位上,用一句自然語言問句,把散落在多來源技術文件裡的正確答案撈出來,而且撈得準、撈得敢用。

車廠售後 RAG 的難點不在「檢索」,在「檢索品質」

一句話說清楚:車廠售後 RAG,是把維修手冊、TSB、故障碼、召回與料件文件統一向量化與索引,讓技師以問句檢索、系統回傳帶出處的答案的知識系統。難的地方不是把文件塞進向量庫,是這些文件天生互相矛盾。

同一個故障碼,2021 年式和 2023 年式的排查步驟不一樣;一份 TSB 可能推翻原廠手冊的舊做法;召回通知會讓某個維修動作直接作廢。如果你只是把所有 PDF 切塊丟進去,RAG 會很開心地把三份互相打架的段落一起回給技師,而技師沒有時間去判斷哪份才是現行版本。

所以第一件事是「文件治理」,不是模型。每一份文件進庫前,要標上車型、年式、生效日、文件類型、是否被取代。檢索時這些不是選配,是硬過濾條件。

多來源文件,要分開處理而不是一鍋煮

不同文件的結構天差地遠,用同一種切塊策略必然出事。我們實務上會這樣拆:

故障碼那一列特別想強調。DTC 是編碼,不是文意,純向量檢索會被「語意相似」害死——P0300 系列的碼彼此描述幾乎一樣。這裡要走混合檢索:碼號用精確比對命中,排查邏輯才交給語意檢索補上下文。純 RAG 教科書不會告訴你這件事,是被回錯碼投訴過才學到的。

權限:副廠師傅不該看到原廠內部公告

售後知識庫的權限比一般企業 RAG 更敏感。原廠工程師、授權經銷商技師、副廠合作點,能看的文件範圍完全不同。有些 TSB 標記「僅限授權據點」,有些召回細節在正式公告前是機密。

權限不能只做在前端介面。我們的做法是把權限標籤寫進每個文件切塊的 metadata,檢索當下就過濾——使用者無權存取的內容,連進到模型的上下文都不該出現。因為只要那段文字進了 prompt,模型就可能在回答裡「引用」到,等於變相洩漏。這是很多團隊上線後才踩到的坑:UI 藏起來了,但 API 回應裡答案已經漏出去。

驗收要盯的是幻覺,不是準確率

Demo 那天問十題答對九題,老闆很滿意。但售後場景裡,答錯一題的代價是拆錯引擎、用錯扭力、漏掉召回。所以我們的驗收標準只有一條核心:寧可說「我查不到」,也不准編。

具體怎麼驗?我們會建一組「陷阱題」:問庫裡根本沒有的車型故障、問已被 TSB 取代的舊做法、問跨車型混淆的料號。合格的系統要能拒答或明確標示不確定,而不是硬湊一個像模像樣的答案。同時每則回答都必須附文件出處與生效日,讓技師三秒內能點回原文核對——沒有可回溯出處的答案,一律視為不合格。

我們也會量「引用忠實度」:回答裡的每一句技術陳述,是否真的能對應到被檢索的段落。這比整體準確率更能抓出幻覺,因為一個答案可以「大致對」但夾帶一句憑空生成的扭力值,而那一句就足以毀掉整台車。

上線才是真正的開始

系統建好只是起點。技師願不願意在忙碌的工位上多問這一句、問到的答案信不信得過,才決定這套 RAG 是變成日常工具,還是又一個 4% 使用率的擺設。我們在 Tenten 做車廠售後這類案子,通常會派工程師直接進維修現場,跟著技師跑幾週真實工單,把陷阱題、權限矩陣、出處驗收一條條調到技師敢照著做——因為 Demo 很美不算數,老師傅願意收起他那疊翻爛的手冊,才算真的上線了。