Claude Fable 5.2 能寫更複雜的 SQL，銷售週報該讓它算哪些數字？

公開動態與原創分析 · 消息日期: 2026-11-09 · 消息來源

Anthropic 在 11 月 9 日推出 Claude Fable 5.2，並在發布文章轉述 Oracle 一位機器學習主管的試用結果。其中一題需要查詢各國債務彙總、還款紀錄與區域基準。根據這位主管的說法，Fable 5.2 得出預期結果，另外兩款模型寫出的 SQL 也順利執行，卻把國家層級的彙總金額重複加了進去。這是廠商公布的一道測試，公開資料不足以獨立重跑。它說明了報表可能遇到的麻煩：資料庫能算出數字，卻無從得知團隊原本想算的是什麼。

Fable 5.2 已可透過 Claude API 使用，AWS 也在同一天公告自家平台已開放。Anthropic 公布的標準價格是每百萬輸入 token 8 美元、每百萬輸出 token 40 美元。值不值得換模型，還要看原本核對週報要花多久，以及換模型之後可以省下多少核對工作。如果財務或資料團隊早已確認週報中的數字該怎麼算，讓模型每週從頭計算一次，就等於把已經定案的問題再問一次。

銷售額要按訂單算，還是按品項算？

以一份虛構的零售週報為例。銷售主管想看上週各通路的淨銷售額，以及新品貢獻多少。訂單表每筆訂單一列，品項明細則每個訂單品項一列。假設有一筆 300 元的訂單，裡面有 200 元的新品和 100 元的舊款。把兩張表合併查詢後，兩個品項旁都會出現同一筆 300 元訂單總額。直接加總訂單金額會得到 600 元。先篩出新品再加訂單金額，結果仍是 300 元。這是「含新品的訂單一共賣了多少」。在這個簡化的例子中，「新品本身賣了多少」的答案是 200 元。兩個問題都能拿來做營運分析，但用錯數字，可能改變新品預算的判斷。

退款日期也會改變淨銷售額的意思。上週成交、本週退款，可以在退款發生的那一週沖減，也可以回到原成交週重新計算。前者方便追蹤本週金額怎麼變動，後者便於分析同一批成交最後留下多少。如果財務採前一種定義，行銷用後一種來看新品活動成效，週報應分別標明。讓模型猜一張舊試算表用了哪種定義，容易把分歧藏進很少有人會回頭看的查詢裡。

固定週報與臨時查詢分開做

週報的常用指標，可以先採用已核准的資料檢視、查詢或既有報表。把統計對象、退款處理規則和更新時間隨結果交給模型，讓它說明變化、整理需要查證的問題。假如本週淨銷售額下滑，但訂單數沒減少，可以接著看客單價、退款和通路占比。週報列出相關數字，主管就能循著線索往下查。如果每週只要收到一張固定表格，沿用現有 BI 報表訂閱即可。

從不同系統取數時，還要防止把資料延遲寫成營運變化。例如週一上午讀週報，網路商店的數字已更新，門市週日的交易還在同步。如果兩週採用不同的截點，模型可能把資料未到齊解釋為門市銷售下滑。報表應列出各通路最後更新的時間，並標明尚未到齊的數字。等資料補齊後再比較，或只比較兩邊都已到齊的區間。

臨時問題更適合拿來試用 Fable 5.2。例如通路主管想知道同一波活動帶來哪些首購客群，團隊手上沒有現成查詢。可以先請模型說明要用訂單、顧客還是品項為單位，再建議需要的欄位與排除條件，由分析人員在唯讀環境用歷史樣本比對。如果還不知道跨通路的同一位顧客該怎麼合併，就先把定義說清楚。這類問題反覆出現、查詢也已複核之後，再考慮存成團隊可重複使用的查詢。

對於需要從多套系統取數的企業，墨客雲的系統串接方案可協助評估如何透過既有介面、檔案或已授權的資料檢視，取得經核准的訂單、退款與通路結果。企業資料團隊負責定義指標，數位員工可以定期彙整、說明變化，並追蹤尚待確認的差異。資料來源、模型使用管道與可用權限仍要依部署環境核實。接入實際營運資料之前，可以先用去識別化的歷史樣本確認這樣分工能否節省時間。

第一次比較可以做得很小。先用多品項訂單、跨週退款和通路資料缺漏的樣本，確認固定報表是否都符合核准定義。再讓現有工具與新模型回答同一批臨時問題，記下可接受的答案比例、分析人員花了幾分鐘核對，以及模型呼叫成本。如果錯誤主要出自指標定義不清，應先修正報表。定義清楚後，若困難的追問仍占用大量人力，再為能力更強的模型安排獨立入口。

• 墨客雲企業系統串接

墨客雲編輯部 · neo@mokyun.com