AI 報表會說兩次謊：查詢欄位是假的，解讀數字也可能是假的

AI 報表最難察覺的狀況，往往是有一個外觀看起來很精準的數字，但背後缺少可追溯的來源。

當系統產出一份排版整齊、推論流暢的業務分析時，查詢回傳成功很容易讓人直接相信報表上的結論。但實際拆開執行過程，查詢可能引用根本不存在的欄位；模型也可能在解讀資料時把數字抄錯，甚至自行填補未經證實的數字。

報表可信度要拆成三層看

評估一份 AI 報表是否可信，必須把檢查責任拆成查詢層、證據層與敘事層。

查詢層負責確認查詢語法使用的欄位與資料集，在這個版本裡是否真的存在。證據層負責確認模型提出的「發現」有沒有明確指向該次查詢實際回傳的資料列。本文把模型提出的每個分析項目統稱為「發現」；進入文字前，每個指標數字都要先建立成可追溯的事實項。敘事層則負責限制可辨識的指標型數字，只能來自已對位的事實，或是標示清楚的推導。

這三件事各自對應不同的驗證機制。單一的查詢成功回應，沒辦法替後續的資料列與文字數字提供背書。整條鏈可以簡化成：查詢取得資料列，發現引用資料列，事實項指向其中的儲存格，分析文字只能引用這些事實，或使用保留輸入來源的推導結果。

查詢層的第一個坑是欄位根本不存在

在這類 AI 報表流程裡，查詢層先要處理的問題，是欄位是否存在。

在 ShopifyQL 查詢裡，程式曾用了看似合理、實際不存在的欄位。例如查詢折扣碼時，程式寫出 order_discount_code，但官方結構定義裡實際存在的是 discount_code。

如果查詢直接送出，底層介面會回傳錯誤。更棘手的情況在於，如果流程把這類錯誤當成「該商店查無資料」，模型就會順著空結果寫出一段看似合理的解釋，把一個語法錯誤包裝成有意義的業務結論🤣

要修正這個問題，欄位與資料集是否存在，要以對應版本的官方結構定義為準；商店是否有權限、查詢能否執行，仍要看實際回應。離線檢查器掃描程式裡固定寫出的查詢欄位與資料集；查詢定義清單決定要跑哪些查詢，資料解析器則負責把回傳內容整理成報表。三者必須同步更新，避免修了查詢字串，卻在選查詢或整理資料時再次拋錯。

離線檢查通過不代表商店一定能查

離線檢查只回答「名稱是否存在於這個版本」。商店是否有權限、API 是否接受並執行查詢，以及指定條件下是否回傳資料列，都必須查看實際回應。即使查詢成功但結果為空，也只能說這次查詢沒有命中，不能擴張成商店沒有相關資料。

把文件準據、商店權限與實際資料分開看待，查詢層的防線才算完整。

查詢修好後資料變多反而引出第二種錯

當查詢層的問題修復、查詢開始能順利帶回大量資料後，第二層問題才跟著浮現出來。

一開始，模型會把查詢回傳的資料列直接複製到結構化輸出。資料一多，輸出就可能膨脹，甚至在生成中途被截斷。另一個問題是，模型自行寫進輸出的資料列看起來可能很真，程式卻無法確認它們是不是剛才查詢的結果。

真正的問題是，副本沒有保留程式管理的來源對位。模型一旦改寫或截斷內容，程式就無法可靠地把副本對回原始查詢。

證據層改由程式接管來源登錄

為了解決資料膨脹與虛構資料列的狀況，這套流程改由程式統一建立查詢登錄表。

每次執行查詢時，程式建立一張只屬於這次執行的查詢登錄表，保存實際回傳的資料列、筆數與這次查詢要回答的分析問題。同一份回傳內容會交給模型判讀；sourceId 由程式產生，模型在提出發現時不能重寫資料列，只能填寫 sourceId 以及資料列索引清單 rowIndexes，指出自己引用哪些資料。這是發現層級的資料列引用；文字裡的單一數字之後會再用 rowIndex 與 field 對應儲存格。

在進入證據檢查前，程式會拿著 sourceId 回到登錄表，依引用取回真正的資料列，補回這個發現的來源。如果來源識別碼在這次登錄表裡找不到，代表引用無效；如果識別碼存在但查詢沒有回傳資料列，代表這次執行沒有可支撐主張的資料。兩種情況都不會進入後續可引用的事實清單。來源對位只是必要條件，不單獨證明資料支持主張；資料列是否真的支持這個發現，仍要另外做語意判讀。

敘事層把文字裡的數字拉回儲存格

即使程式已把發現重新對回原始資料列，模型在把資料轉化為分析文字時，依然可能發生數字抄錯或張冠李戴的情況。

因此在敘事層，程式要求單一事實必須包含 sourceId、資料列索引 rowIndex 以及欄位名稱 field（遇到巢狀物件時則使用點號路徑）。如果數字由多個儲存格推導，還要保留輸入儲存格與推導依據。程式會依照這組定位資訊直接讀取實際儲存格的值，覆寫模型自己寫出的數字；如果指定的欄位根本不存在，該項事實就會直接被丟棄。這一步只能修正數值的抄寫錯誤，不能保證選到的儲存格語意正確或整句解讀成立。

針對重點洞察這類由模型產生的文字，程式再透過命名事實目錄來約束文字中允許出現的數字來源。這份目錄只收已對位的事實，供文字引用；沒有進入目錄的數字，不能直接供重點洞察使用。提案參數則是折扣門檻或點數這類設計值，不是商店現況的資料事實。這層守門主要針對可辨識的指標型數字。這裡的裸整數，是只出現數值、沒有可供程式對回的指標欄位或事實引用；這類數字目前無法被同一層規則全面攔截，依然需要搭配 prompt 與格式驗證器把關。

檢視 AI 報表的檢查清單

這三層防線主要處理四類來源問題：未定義的欄位、找不到的來源識別碼、沒有資料列的來源，以及模型偽造的資料列。對數字則只能處理部分未對位情況；它無法保證所有商店的權限可用性，也無法替模型完成所有的語意判讀。

要確認一套 AI 報表流程是否健全，可以從三個問題來檢視：

第一，查詢使用的欄位與資料集，在對應版本的文件中是否有正式準據？

第二，報表提出的主張，是否能精確回到該次查詢實際回傳的資料列與儲存格？

第三，解讀文字裡的數字，是否受到已對位事實的約束，或是能清楚追溯推導過程？

把可機械檢查的結構與來源問題交給程式，讓模型在可追溯的資料上進行解讀，才能降低整齊文字掩蓋錯誤的風險。