CAN-QA 論文閱讀分析：很多車載偵測真正缺的，不是再多一個 classifier，而是先逼模型回答它到底看到了什麼

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：CAN-QA: A Question-Answering Benchmark for Reasoning over In-Vehicle CAN Traffic
• 作者：Jing Chen、Abhijay Deevi、Onat Gungor、Tajana Rosing
• 年份：2026
• 來源：arXiv:2604.24935
• 論文連結：https://arxiv.org/abs/2604.24935
• DOI：10.48550/arXiv.2604.24935
• 主題：Automotive Security、CAN Bus、LLM Evaluation、Reasoning Benchmark、Cyber-Physical Systems、Intrusion Detection

這篇最值得看的，不是它又做了一個新的車載 IDS benchmark，而是它直接挑戰一個很少人肯承認的老問題：

很多車載入侵偵測真正缺的，不是再多一個會把流量分成 normal / attack 的 classifier，而是把「為什麼可疑、哪一段可疑、它比較像哪種異常行為」問成模型真的得回答的題目。

如果只用一句話講這篇 CAN-QA 的 framing，我會這樣下：

很多 automotive AI 真正卡住的，不是模型看不見 CAN 流量，而是我們長期把本來應該像調查一樣做的事，硬壓成單一分類答案。

這也是這篇 paper 最聰明的地方：它沒有再問「這筆流量像不像攻擊」，而是把問題改寫成更像分析師真的會問的樣子：

• 哪個 CAN ID 最異常？
• 這段 timing pattern 比較像 flooding、suppression，還是混合訊號？
• payload 變化是正常少見，還是不合理狀態轉移？
• 這些信號加總起來，該被理解成單點雜訊，還是 coordinated anomalous behavior？

它在補哪個洞？不是 detection score，而是 forensic usefulness

論文一開頭就點得很準。現在多數 CAN intrusion detection 研究，雖然能把流量做成 anomaly detection 或 attack classification，但這些做法常有一個共同問題：

• 能報警，不代表能解釋。
• 能分類，不代表能調查。
• 能在 benchmark 上高分，不代表能支援真實 incident triage。

而真實車載調查不是只要一個 label。分析師通常是在看：

• message identity participation 有沒有突然變形
• frame rate、gap、burst pattern 有沒有失真
• payload 是否出現 baseline 很少見的轉移
• safety-critical ID 是否缺席、延遲、或被不合理放大
• 多種弱信號湊在一起時，該怎麼判讀整體意義

這篇的基本立場我很買：如果 benchmark 只要求模型吐出 binary anomaly label，你最後得到的也只會是對 binary label 最優化的系統，而不是對調查工作最有幫助的系統。

CAN-QA 在做什麼？把原始 CAN log 變成可重現的問答題

作者提出的 CAN-QA，本質上是一個自動化 benchmark construction pipeline。做法不是人工手寫題，而是：

1. 先把異質 CAN logs 正規化成統一 schema：timestamp、identifier、DLC、8-byte payload、flag
2. 按時間切成固定長度 windows
3. 把每個 window 轉成保留語意與時間順序的 textual context
4. 再用 deterministic rule-based templates，把 window-level statistics 轉成自然語言問題與 ground truth

這個設計的價值有兩個：

• 可重現：答案不是 annotator 主觀判斷，而是由可計算的 window properties 直接導出
• 可擴充：換資料集、換車型、換攻擊場景，只要重算 baseline statistics，就能重新產生新題庫

論文裡的 benchmark 最後做成 33,128 個 QA pairs，橫跨 10 種問題類別。這不是把 CAN traffic 文本化而已，而是把它切成一組可系統性測試模型 reasoning 的任務。

十類題目的設計，其實就是十種「你到底有沒有在分析」

CAN-QA 最有意思的地方，不是 dataset 大小，而是它怎麼拆題。作者把問題分成十類，我覺得這個拆法很有工程感，因為每一類都對應到一種實際調查能力：

• Category 1：Anomalous Behavior Identification and Localization
• Category 2：CAN Message Identity and Role Structure
• Category 3：Traffic Volume and Distribution Characteristics
• Category 4：Temporal Behavior of CAN Communication
• Category 5：Payload Value Patterns and Regularities
• Category 6：Frame Format and Protocol-Level Integrity
• Category 7：Expected and Safety-Critical Message Behavior
• Category 8：Payload Dynamics and Baseline Plausibility
• Category 9：Data Consistency and Logging Artifacts
• Category 10：Attack Interpretation and Decision Signals

我特別喜歡 Category 8、9、10，因為這幾類已經不是單純數一數 frames 而已，而是要模型處理：

• baseline-relative reasoning
• multi-condition inference
• 多個弱訊號的聚合解釋
• logging artifact 與 genuine anomaly 的邊界

這才比較像現場真的難的地方。很多模型會做的是「看起來怪」，但現場真正在意的是：它怪在哪、怪成哪一型、要不要當作攻擊、還是先當資料品質問題。

這篇最值得記住的一句：LLM 很會抓表面統計，但不太會真的推理

作者用 CAN-QA 去測七個開源模型，主要落在 7B–9B 的 practical range，包括 Qwen、Llama、InternLM、Ministral、GLM，還有一個 cyber-oriented 的 Foundation-Sec-1.1-8B。

結果其實很誠實，也很有警示意味：

• True/False 準確率大約 47%–59%
• Multiple-choice 準確率大約 25%–40%
• 從 TF 換到 MCQ，整體大約再掉 20 個百分點

這個結果背後最重要的訊息不是「模型不夠大」，而是：

一旦問題從「你有沒有看到一個大概的 pattern」變成「請你在幾個看似都合理的解釋裡，選出最精確的那一個」，很多模型就開始露餡。

論文明講：模型對 surface-level statistical cues 還行，但碰到：

• temporal reasoning
• multi-condition inference
• higher-level behavioral interpretation

就明顯吃力。

這其實很值得整個 AI-for-security 社群記住。因為很多 demo 看起來像會分析，常常只是它很會抓語境裡最醒目的統計暗示，而不是真的有能力做嚴格條件判斷。

最難的不是看見異常，而是把異常放回 baseline 與邏輯邊界裡

論文的 category-level 結果很有意思。

在 True/False 設定下，一些比較明確、偏計數和閾值驗證的類別表現相對不錯，像是：

• Category 1：異常是否存在、能不能粗定位
• Category 2：哪些 CAN ID 參與、角色結構有沒有異動
• Category 3：traffic volume 與 distribution 是否偏斜

但一旦題目要模型去做：

• 對 baseline 分布的相對判讀
• payload dynamics 的合理性判斷
• logging artifacts 與 attack symptom 的區分
• 多個條件同時成立時的整體解釋

表現就明顯掉下來。

尤其 Category 8: Payload Dynamics and Baseline Plausibility 幾乎一路都很難，MCQ 對多數模型接近只有 12%。這件事其實很有代表性，因為它說明：現在模型不是完全不會看車載流量，而是它不擅長把觀察值放回「正常系統應該怎麼動」的背景模型裡推理。

而這件事偏偏就是 cyber-physical security 最重要的部分。你不是只看單點數字，而是要看那個數字在這個系統、這個時間、這個控制狀態下合不合理。

這篇 error analysis 很實在：模型常不是完全看不懂，而是卡死在「差不多」

我很喜歡作者做的 error analysis，因為它沒有只停在「某模型高幾分、某模型低幾分」，而是去拆模型怎麼錯。

其中一個典型錯法，是模型抓得到方向，但守不住邊界。例如：

• 知道 CAN IDs 很多，但無法精準驗證「有沒有超過 30」
• 知道某種 ID concentration 偏高，但在相鄰區間裡選錯答案
• 知道 timing 有異常，但分不清 flooding、suppression、mixed ambiguity 的精確定義

這點很重要，因為它說明很多 LLM 在這類題目上的常見失敗，不是完全沒看見訊號，而是：

它會辨認趨勢，但不擅長做嚴格、可追責、邊界清楚的條件判斷。

放到安全場景，這就很危險。因為 incident triage、車載調查、工控分析這些工作，不是「大概像」就夠。你常常就是要分清楚 20% 跟 21%、rare once 跟 repeated rare transition、單一 signal 跟 coordinated anomaly 之間的差異。

Prompting 的結果也很值得記：few-shot 比空泛 CoT 更有用

論文另一個很實務的觀察，是 prompting strategy 對結果有影響，但不是大家想像的那種「只要叫模型一步一步想就好了」。

作者發現：

• few-shot 能幫助模型更好對齊這種結構化推理任務
• zero-shot CoT 對 TF 有些幫助，但對 MCQ 反而可能掉分
• few-shot + CoT 不是穩定碾壓，反而未必比單純 few-shot 更好

這個訊息我會翻成更白話的版本：

在 rule-oriented security reasoning 裡，給模型幾個長得對的例子，常常比叫它自由發揮「深呼吸慢慢想」更有效。

因為這種任務的本質不是 open-ended creativity，而是 structured checking：數事件、看順序、驗條件、套區間、做組合判讀。這類事情比較像遵守一套分析手法，而不是拼靈感。

這篇對 AI × automotive security 的真正價值

我覺得 CAN-QA 真正有價值的地方，不只是它證明目前模型還不夠強，而是它幫這條線把 benchmark 問題問對了。

它在做的其實是把車載流量分析，從：

• 單一分數
• 單一分類
• 單一 anomaly label

改寫成：

• 多維 reasoning task
• 可解釋的 analyst-facing questions
• 更接近 investigation workflow 的 evaluation interface

這個轉向很重要。因為如果未來真的要把 LLM 或 agent 放進 automotive SOC、車隊監控、事故後鑑識、或 edge-side CAN triage，你要知道的不是它會不會喊「有異常」，而是它能不能回答下面這種問題：

• 哪一種異常？
• 證據在哪裡？
• 哪個 ID、哪段 timing、哪組 payload transition 支撐這個判斷？
• 這是攻擊、資料品質問題、還是正常但罕見的 operational state？

換句話說，CAN-QA 不只是 benchmark，它其實是在定義「什麼才叫做對 CAN traffic 有用的 AI 推理能力」。

限制也要講清楚

當然，這篇也不是沒有邊界。

• 它是 benchmark，不是 defense。 它不直接提高防禦能力，而是改進你測模型的方式。
• 題目是 rule-based 生成。 這帶來一致性，但也可能讓問題空間偏向作者定義得出的 reasoning style。
• textualized CAN window 仍是轉譯表示法，不等於模型真的原生理解時序訊號。
• 目前測的是 open-source 7B–9B practical range。 對更大模型、tool-augmented agent、hybrid symbolic pipeline 的結論仍可再擴。

但我反而覺得這些限制不會削弱它的價值。因為它最重要的任務，本來就不是證明「這套東西已經能上車」，而是把整個社群從錯的 benchmark 問題，拉回比較對的 benchmark 問題。

重點整理

• 這篇核心主張是：CAN 流量分析不該只被做成 anomaly classification，而應該被改寫成可解釋、可調查的 QA reasoning 任務。
• 作者把原始 CAN logs 正規化、切窗、文本化，再用 deterministic templates 產生 33,128 個 QA pairs。
• 整個 benchmark 橫跨 10 類 reasoning tasks，涵蓋 identity、timing、payload、protocol、safety-critical behavior、logging artifact 與高階攻擊解釋。
• 模型在 表面統計線索 上還行，但對 temporal reasoning、multi-condition inference、higher-level behavioral interpretation 明顯較弱。
• 從 TF 到 MCQ 平均大幅掉分，表示「選出最精確解釋」比「判斷一句話大概對不對」難得多。
• few-shot 往往比空泛的 zero-shot CoT 更有效，說明這類 security reasoning 更需要結構化示範，而不是泛用式思考提示。

Takeaway

CAN-QA 真正重要的，不是它又證明一次模型在車載安全上還不夠可靠，而是它把問題重新問對了：很多 automotive AI 真正缺的，不是再多一個會報警的分類器，而是先逼模型回答那些分析師本來就要問、而且答錯會出事的問題。當 benchmark 從「像不像攻擊」升級成「到底怪在哪、憑什麼這樣判、這些信號要怎麼合併解釋」，我們才比較可能測出一個系統是否真的值得進入 safety-critical workflow。

更白話一點：不是每個會喊「有異常」的模型，都真的會分析。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。