發佈日期： 2026-01-17 主題： AI 可解釋性（Explainability） 時長： 約 12 分鐘

開場

嗨大家好，這週其實是一個「可解釋性的一週」。

我的題目其實都是圍繞在所謂的相關的可解釋性。那其實我在做這個相關的題目時候，我也發現到就是，在目前學術界、然後從流程界、然後或是在最後的就是 IT 界、或是最後的那個法遵界，其實大家對可解釋性的要求其實都很大。

那所以我在這週，針對這個各個不同面相來進行一個剖析。

披薩指數：FDE 落地的最佳詮釋

📖 延伸閱讀：披薩指數：為什麼 FDE 模式 50 年後依然有效

在 2026 年剛開始，美國五角大廈有兩次軍事活動——一次對葉門、一次對伊朗。

那在這兩次的軍事活動的前一天晚上，那個五角大廈的著名的數據分析指數「披薩指數」，依舊如約而至的亮起。

那這其實就反映了，就算時過境遷 50 年，這個由當初冷戰時代 KGB 所發明出來的披薩指數依舊管用。

它管用原因，其實不是因為那個就是他們的數據分析是有多厲害，而是因為 KGB 對那個就是美國五角大廈的人，他們的就是現場的一些流程以及的理解。

當我們就是有軍事活動的前一天，我們要做大量的沙盤推演，所以需要加班。這些幕僚需要加班、他們就要吃東西、需要吃東西、附近的披薩店就得訂單量就會比較多。

那這個這個在整個邏輯鏈條，其實是基於人性，而不是基於那個其他的所謂的企業的 SOP。

所以只要裡面的幕僚那個都還是人、不是 AI Agent 的話，那我相信再過十年再過 20 年，這披薩指數依舊有用。

這跟 AI 轉型有什麼關係？

那這其實也會反映到我們的在做 AI 轉型的時候一直強調的點，就是：

我們需要像 FDE 這樣的角色，深入現場、進入現場，理解他們的相關的現場的一些流程。

然後我們才會知道說，什麼東西是真正有用的、然後什麼東西什麼流程是真正真正有意義的。

那像這樣子，現場團隊要把它負責挖出來，變成一個正確的「披薩指數」。這樣子的話，我們就是在這個企業做的 AI 轉型，這樣子才會有真正落地的可能性。

學界趨勢：Kalman Filter × Transformer

📖 延伸閱讀：Kalman Filter × Transformer：可解釋 AI 的工程突破

那在這週在講一些可解釋性部分的時候，我注意到的目前學界的一些趨勢。

現在發現到一個趨勢就是說，學界其實最近喜歡把 Transformer 的架構跟套到就是物理界一個非常非常就是管用的一個老架構 Kalman Filter 把它混合在一起。

為什麼要這樣做？

我們知道 Transformer 很會抓相關的趨勢，它很會利用數據來做相關趨勢。但是它問題就是它在於它是一個黑箱，它的可解釋性是差的。

那 Kalman Filter，它其實已經被驗證它是非常非常好用的一個技術。原因是因為它有那個人可以自由的去調控：

  • 我現在我要相信現場的 signal？
  • 還是要相信就是那個預測的趨勢？

那它也根據現場 signal 的好壞，來決定說我是要用現在預測、還是要用現場的 signal。

Kalman Filter 的問題

但是問題就在，Kalman Filter 裡面有一些就是關鍵的參數，那這參數其實是很仰賴就是現場工程師的一種直覺來做調整的。

那調的不好的話，那 Kalman Filter 也就是也也不會很準。

Transformer + Kalman Filter 的混搭

那所以就有人想說：Transformer 很會抓趨勢，那能不能讓 Transformer 直接取代這個人的直覺部分？然後來讓它去挑 Kalman Filter 的這個參數。

呃這兩個混搭之後就發現到了，就就是那個效果非常的好：

  • Transformer 可以取代人很仰賴經驗的去挑這些參數的部分
  • 但是又能夠保留 Kalman Filter 大家最喜歡的部分——人可以很輕鬆知道說「現在是抓現場的 signal 還是抓之前的趨勢的部分」
  • 這個可信度也有一個詮釋方法的方式，做出一個很好的一個調整的方式

所以在很多的不同的論文都發現到，它其實對就是調優現在的一些工程的場景上面是是很有奇效的。

這其實我覺得這就是現在的學界，對於 Transformer 這技術如何就是能夠落地、而且增加它可解釋性的上面的一大突破、一個思維上面的一個轉變。

IT 架構：Langfuse V3 的治理困境

📖 延伸閱讀：Langfuse V3 架構分析：PostgreSQL 與 RLS 的治理取捨

然後再來就是講到了，就是相關的那個保證很無聊的 IT 架構。

那這週講到的，其實也是跟可解釋性有關的。我們就是深入去講那 Langfuse 這樣子這個這個一個架構。

這架構其實是目前大語言模型或者 AI Agent 界，就是來做一些相關的 log、以及相關的提取裡面可解釋性、還有做一些集合的一個就是蠻 popular 的框架。

V2 到 V3 的架構膨脹

但是當大家在架設的時候，都會發現到唉，當它 V2 到 V3 的的那個階段：

  • V2 本來就是一個 PostgreSQL 就能夠做了
  • V3 這邊居然用到了大量的不同的技術，像是用到 Redis、用到 ClickHouse，然後也保留到那個 PostgreSQL

那所以就變成說，其實大家很多人就是用大語言模型、就會用 AI Agent，其實他並沒有那麼的複雜。他沒有那麼的高的高吞吐量的 log，但是他又要就是架設了那麼多的就是相關的軟體。

尤其是可以看到這些相對比較新，它裡面還有一些分布式元件，像 Zookeeper 的部分。所以說就增加了很多就是維運的成本。

大家就要想說：我真的要只是為了一個可解釋性，然後多加那麼多的元件嗎？

PostgreSQL 的優勢

那就會反過來說，就是我們也也我也討論了說是，PostgreSQL 就是如果用 PostgreSQL 來做全部的這樣子的可解釋性的話，那它有什麼好處跟什麼樣的的的缺點。

那其實好處其實蠻明顯，就是說：

  1. 架構非常簡潔
  2. Robust Security — 它還是比 ClickHouse Redis 好的。它能夠就是在各個場景下面都能夠保持 Robust Security。但 ClickHouse 只能在 Read Only 的時候保持 Robust Security

所以它在治理這邊其實是比較好的。

所以這邊的話其實就就發現到，就是 Langfuse V3 雖然它已經有進步、讓它的效能是變得更好。但某種程度來說，它可能在治理這邊的架構反而是比較弱，而且它可解釋性這邊比較弱。

所以這邊就是主要看說未來有沒有人，就是把這個把這個架構把它再把改回去那個 PostgreSQL，然後洗過、然後讓它變得比較簡單、比較比較可用一點。

可解釋性的核心價值：從合規到信任

📖 延伸閱讀：AI Agent 可解釋性：三層工程鏈路設計

然後在週六的時候，在治理的議題的時候，我們總結到這週的一些相關的可解釋性的相關的議題。

那我們提出來說，我們為什麼要做一個可解釋性的那個就是 AI。

那原因是，之前我們提到可解釋性，我們都想到說「我們要治理、我們要合規、我們要 GDPR 啊」。

但是其實後來最近都發現到，可解釋性它的帶來的重要性，其實不只是治理跟合規。

信任才是關鍵

它其實帶來重要性最重要的一件事情，是能夠給現場帶來一些信賴。

舉個例子：你在工作的時候，你不會想要跟一個就是不解釋你為什麼這麼做的員工合作吧？這因為你無法信賴他、你不知道他為什麼這樣子做、他做錯了你又無法糾合。

那後但是我們現在在做 AI Agent 導入的時候，我們都說它是「數位員工」。但是我們基本上我們都默許它不會跟你解釋。

那這樣子不是一個很奇怪的行為嗎？

所以我們既然要跟這樣子 AI Agent 的數位員工來合作，我們就需要它提供一個比較好的可解釋性。

三層可解釋性架構

那從我從這邊來看的話，我們可解釋性可能會提供為三層：

第一層：Log Level

當你做一些 AI Agent 框架，我舉例像 n8n 的時候，你這邊的話就是在每一次的 action，你都能提供一個比較好的 input 跟 output，然後把它記錄起來。

那你把它點進去的時候你會知道說，當下的就是在一個 Agent 內這一個 step 的那個它的 input 是什麼樣子的。

那這是第一層，那比較低的 Log Level。

第二層：Session / State Level

第二層的話，其實就是所謂的那個就是整個 session、或是整個 state，然後的就是它的前後、它的它的決策是什麼。

從你的相關的用戶的 user 的 input，然後就是去 call 那個大語言模型，然後再去扣相關的 RAG 回傳的相關的資料，或者扣一些那個 tool use 然後回傳那些相關資料，最後拿大語言模型怎麼去做出這決策、然後最後怎麼樣子那個可能經過一些 Guardrail，然後最後吐發吐回來給那個客戶。

那在這整個 session，其實就是如同我們之前治理講的，它其實是一個 stateful 的、它不是一個 stateless。它每一個動作其實都是有相關的關係的。

那我們要知道它為什麼做這個決策，我們就是要把它的所有的環節都把它記錄下來，那並且能夠把它用一個 trace 把它串起來。

這時候就是那個 Langfuse 那個它的相關的範疇。那我們可以用一個相關的就是一個統一的統一平台來整合這個東西。

第三層：Aggregation Level（時間維度）

那在第三層的話，其實就是在把時間、所有的相關的那個 session，對應到這個這個 Agent 它的 KPI。

那我們做一個比較好的 evaluation，就是說在這段時間、有這段時間這個 Agent 它表現可能 performance 不是很好、或是它的 performance 是是很 OK 的，那原因是什麼。

那是一個時間維度作為更就是更高維度的一個 aggregation。

那這個其實大家都蠻熟悉，可能就是把我們剛剛講到這相關的 Log Level 或 Session Level 的，然後變到 BI 裡面，做一個比較好的相關的一些分析。

三層架構的價值

那有了這三層的這個 level 的就是的分析，然後獲得這樣的可解釋性的話，我們就可以就是更加理解這個數位員工，它為什麼當初做了、為什麼要做這樣的事情。

那以及我們就更加清楚的說，它為什麼做這樣的決策。

那當然當然就是更好，就是我們有了治理、就是有治理要做糾合、或是我們要糾錯它當做的事情的時候，我們可以很輕鬆的在不同的 level 都能夠跟那個就是相關的法遵單位來做解釋。

所以，這個是我認為可解釋性的一個最大的的用處：

就是能夠讓現場相信它，並且讓稽核的人也能夠信賴它。

結語：可解釋性不只是治理

這就是這週我對可解釋性的一些經驗相關的分享。

那老實說我在做這個題目之前，我以為它可解釋性只是一個治理的一個子分類。

但是我現在不這麼想了。

它當然有治理的一個很強的需求，然後像法規或 GDPR 啊都要求可解釋性的 AI Agent。

但是現在我也發現到，除了做可解釋那個可解釋性除了治理這這些議題以外，它也充分的影響到現場人員對 AI Agent 的信任度。

那就是你會想要跟一個可解釋的就是 AI Agent 的數位員工合作，而不是想要跟那個黑箱來做合作。

所以我個人認為，在未來的一些 AI Agent 的落地當中，可解釋性可能會越來扮演越來越重要的角色。

下週預告

然後在下週的話，我會把題目右轉到就是 AI Coding 這個這個範疇。

那我也會講到這目前就是 AI Coding 的一些前沿的一些研究，以及未來就是可能在我們這邊遇到一些問題、或是我最近的一些感悟。

請大家期待，謝謝！

本週相關文章

這是 Weekly Vlog 的逐字稿版本，保留了口語化的表達方式。如果你更喜歡閱讀文字，這個版本可以讓你快速掌握本週的核心觀點。