iT邦幫忙

2026 iThome 鐵人賽

DAY 8
0
IT Operation

當人、AI、系統開始一起工作系列 第 8

Day 08|四份資料都是真的,但沒有一份能單獨回答全部問題

  • 分享至 

  • xImage
  •  

一個 Automation Case 失敗後,群組裡很快貼出了四份東西。

第一份是 SOP。

上面寫著:

Step 3
Upload package

Step 4
Start execution

第二份是 Ticket。

裡面要求:

The new package should be used for this run.

第三份是 Source Code。

工程師找到一段 Function,看起來確實會先 Upload,再 Execute。

第四份是當次 Run Log。

Log 裡沒有看到 Upload 完成的紀錄,直接進了 Execution。

很快,討論變成:

「SOP 才是標準流程。」

「但 Code 明明有做。」

「Ticket 才是這次真正的 Requirement。」

「可是 Runtime 根本不是這樣跑。」

四份資料都是真的。

問題是,大家把「是真的」理解成了「可以證明全部事情」。


不同 Source 負責不同種類的真實性

很多企業 AI 做 Knowledge Search 時,會把各種來源放進同一個入口。

文件、Issue、Code、Log 都可以查。

這很方便。

但「都可以被查」很容易讓人下一步產生另一個假設:

它們都是同一種 Evidence。

其實不是。

在這個案例裡:

SOP
→ Intended procedure / prerequisite

Ticket
→ Requested change / scope / owner

Source Code
→ Implementation

Run Log
→ Actual execution evidence

SOP 可以證明團隊希望流程怎麼跑。

它不能證明昨晚那一次真的有走到 Step 3。

Source Code 可以證明某條 implementation path 存在。

它不能單獨證明 Runtime 當下真的走了那條 path。

Run Log 可以證明那次執行看到什麼。

但如果拿它去回答「設計上本來應該怎麼做」,它也不夠。


把所有 Source 混成一個「知識庫」後,Evidence 邊界很容易消失

如果 AI Search 只做一件事:

Query
→ Retrieve all relevant chunks
→ Summarize

它可能會得到一段很完整的回答:

系統依 SOP 與 Source Code 會先 Upload package,之後執行;本次 Ticket 也要求使用新 Package。

每一句都有來源。

但這段話仍然沒有回答真正的問題:

昨晚那一次,到底有沒有成功 Upload?

這題最有資格回答的是 Runtime Evidence。

如果 Log 沒有看到,不能拿 SOP 或 Code 來補成「應該有,所以有」。

這也是 Source Responsibility 的意義。

不是判斷哪個 Source 比較高級。

而是先問:

你現在要證明的是哪一種事情?


他們沒有建立一個全球 Evidence Ranking

事件後,團隊沒有訂一個簡單規則:

Log > Code > Ticket > SOP

因為這樣還是錯。

如果問題是「這次實際執行了什麼」,Log 最重要。

如果問題是「這次需求要改什麼」,Ticket 才是主要 Source。

如果問題是「現在 implementation 怎麼寫」,要看 Source Code。

如果問題是「正式操作前應有哪些 prerequisite」,SOP 仍然有自己的責任。

所以他們只留下了一張很小的對照:

Source              Responsible for
------------------------------------
Procedure           Intended process
Request / Issue     Requested work
Repository          Implementation
Run result / Log    Actual execution

之後 AI 回答時,也不只列「參考了哪些文件」。

還要能說:

這個 Claim 是由哪一類 Source 支持的。


最後,四份資料沒有互相淘汰

當天的 Case 最後查到:

Code 裡確實有 Upload path。

SOP 也沒有寫錯。

但那次 Runtime 因為當前條件走了另一條 Execution Path。

真正要修的不是把其中三份資料標成「過時」。

而是不能再拿它們互相代替。

隔天的 Review Board 上,原本只有一欄:

Evidence

後來被拆成:

Procedure Evidence
Requirement Evidence
Implementation Evidence
Runtime Evidence

資料沒有變多。

只是從那天開始,大家不再用「我找到一份相關文件」直接跳到「所以事情就是這樣」。


上一篇
Day 07|AI 沒找到證據,卻還是給了一個很像答案的答案
下一篇
Day 09|程式碼裡明明有這個 Function,Log 裡卻一次都沒走到
系列文
當人、AI、系統開始一起工作11
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言