資料核驗

一種沒人及時發現的失誤 請 AI 總結一條 CI pipeline，你會得到一段很整齊的話：lint 階段 42 秒、build 3.5 分鐘、整條 pipeline 16.4 分鐘、比上週快 18%。讀起來像一份報告。兩小時後才有人發現 build 從來沒花過 3.5 分鐘，而失敗率是從另一週抄來的。 這段話看起來沒有任何可疑之處。問題就在這裡：編造的數字和真實的數字，排版上完全一樣。 為什麼模型會這樣 AI 寫摘要時並不是在查你匯出檔裡的行，而是在生成「最像下一個詞」的內容——而「像」不等於「有出處」。兩種失誤最常見： 編造：那個位置需要一個數字，於是就生了一個。「失敗率 2.4%」會出現，是因為 pipeline 摘要裡通常有失敗率，而不是因為 2.4% 真的存在。 漂移：數字本身是真的，但在流轉中變了樣——被四捨五入兩次、秒與分鐘換算錯、從相鄰的行／週／專案串了行。 這兩種都能通過人工審閱，因為審閱看的是文字邏輯，不是算術。 五分鐘核驗流程 1. 留原始匯出，不要只留摘要。 把 CSV、日誌、SQL 查詢結果交給 AI。如果來源本身就是摘要，就沒有東西可以核對了。 2. 把每個數字都當成需要出處的斷言。 一條實用規則：沒有來源行號，就不進報告。 這跟新聞業要求引用出處是同一個道理，只是用在算術上。 3. 先對單位，再對數值。 1500 ms、1.5 s、0.025 min 是同一個時長。AI 摘要裡大量「看起來錯」的數字其實是單位或四捨五入造成的，而真正編造的數字就藏在這片雜訊裡。 4. 留出容差。 摘要裡保留三位有效數字的數值不可能和原始的 4183000 完全相等。設一個小的相對容差（1% 是合理預設值），超出容差的判定為「待核實」，而不是直接判錯。 5. 把「待核實」和「錯誤」分開。 待核實代表你貼的來源裡找不到它——它可能是對的，只是來自你還沒提供的資料；但在找到那個來源之前，它不能進報告。 AI 數字核驗器 把第 3～5 步自動化了：把 AI 回答和來源一起貼進去，它會抽出每個數字、正規化單位與倍數量詞、逐一比對，並把找不到出處的標紅，同時給出對應的來源行號作為證據。 標紅之後要做什麼 按影響從大到小處理，並替每個數字歸類： 現象 常見原因 處理方式 完全找不到，但量級合理 編造 刪掉，或要求提出出處 差幾個百分點 四捨五入、口徑不同、週期不同 確認統計週期再用 只在單位換算後才相符 摘要造成的偏差 可以用，但要寫清單位 對到相鄰但不同的行 串行 更正，並複查相鄰數字 這套方法的邊界 比宣傳更重要的是講清楚限制：核驗工具確認的是可追溯性，不是真實性。 ...