企業內部資料 AI 沒學過，要靠 RAG 接上本地數據庫；學過卻想不起的，讓它多想一步；再經生成、核查、審核三步把關，輸出才到位

協作者：張Sir與AI

叫 AI 介紹澳門大三巴牌坊，它說得頭頭是道；叫它介紹你公司去年做過的項目，它同樣說得頭頭是道，只是其中內容可能是編造出來的。兩段文字一樣流暢，前一段靠的是它學過的公開資料，後一段它根本沒有資料可依，只好自己補上。這就是常說的 AI 幻覺（hallucination），內容讀來可信，卻是錯的或憑空捏造的。個人使用時，這種錯最多令人多花時間核對；換成企業把這段介紹發給客戶，賠上的便是公司的信譽。

遇到這種情況，直覺的做法是換一個更強的模型，但 Google 研究院與以色列理工學院團隊今年發表的一項事實記憶研究顯示，單靠換一個更強的模型，未必解決得了，研究同時提供了一個清楚的分法。研究人員從維基百科抽出 2,150 項事實，每項用十種問法，測試了 13 個大語言模型（large language model，簡稱模型，LLM），也就是 ChatGPT、Gemini 這類 AI 背後的模型，收集了四百多萬個答案。他們想弄清楚，AI 答錯，到底是因為不知道，還是知道了卻一時想不起。

模型沒學過，還是想不起

該研究把 AI 答錯分成兩類，一類是模型根本沒學過這項資料；另一類是學過，提問時卻想不起來。從結果看，GPT-5、Gemini-3 這類前沿模型（frontier model），即各大公司最新、最強的模型，已經記住了 95% 至 98% 的事實。但要它們不假思索、直接作答時，仍有約四分之一到三分之一的事實想不起來。其中最容易想不起的，是冷門的事實，以及反過來問的問題，例如模型答得出某家公司的創辦人是誰，反過來問這個人創辦了哪家公司，它就可能「一本正經地胡說八道」。

放到企業裡，情況又不一樣，公司的項目名稱、最新的產品價格、今年剛換的口號，這些資料從來沒有進過任何模型的訓練數據中，對 AI 來說全屬沒學過。所以 AI 在這些資料上答錯，模型再強、想得再久，都補不回來。因此處理幻覺，先要分清眼前的錯屬於哪一種，兩種錯的處理方法不一樣。

沒學過的，靠本地數據庫補足

先說沒學過的一類，張Sir在上一篇《老闆嫌不夠快，同事怕做得太快》裡，介紹過團隊的 GVA 流程，先生成（Generate），再核查（Verify），最後由指定的人審核才行動（Act）。GVA 的第一步是生成，處理內部資料時，張Sir team在這一步就用上檢索增強生成（retrieval-augmented generation，簡稱 RAG），意思是 AI 動筆之前，先到機構自己的本地數據庫查找資料，再根據查到的內容撰寫。這類數據庫業界多稱知識庫（knowledge base），放的是機構自己整理的文件和數據。內部事實於是不靠模型回想，由知識庫供給。

問題是，知識庫本身也會出錯，數據明明在庫裡，檢索時漏掉了；調出來的是舊版本；或者數據已經放在 AI 面前，它仍然混進自己記憶裡的舊說法。第二種情況，張Sir team就遇過一次，業務文件已經更新，知識庫卻沒有同步，核查調出來的仍是去年的版本，那時公司的口號（slogan）還沒有換。所以知識庫能不能補足 AI 沒學過的部分，要看數據有沒有經過整理和標註、有沒有人審核、是不是每天更新。

想不起的，讓 AI 多想一步

知識庫補的是模型沒學過的資料，至於模型學過、只是一時想不起的那一類，該研究提出了另一個辦法，就是讓它先推理再回答。現在不少 AI 產品都有推理模式（reasoning mode），打開之後，模型會在回答前投入額外運算，嘗試找回相關資料，再給出答案，回答慢一些，但較周到。研究發現，前沿模型啟動了推理模式，能找回 40% 至 65% 原本想不起的事實，冷門事實和反向問題答錯的情況也明顯減少。論文作者把這比作人「話到嘴邊說不出」，多想一會，往往就想起來了。

推理模式卻不必每次都打開，在該研究的題目裡，只有一至兩成事實要靠推理才答得出，每題都打開，時間和運算成本都會上升。此外，效果也主要見於本身為推理而訓練的模型；一些未經專門推理訓練的模型沒有原生推理模式，研究改以在提問時加上一句「請一步步想」來測試，這種做法叫思維鏈提示（chain-of-thought prompting），結果顯示答案反而可能更不穩定。因此比較實際的做法，是遇到重要的、冷門的事實才啟動推理模式，並且從正反兩個方向各提問一次，兩次答案對不上，就要再核查。

核對時，讓 AI 逐句讀原文

AI多想一步能找回一部分，但仍會有想不起、想錯了的時候，所以稿件發出之前還要核對。該研究還有一個發現，對核對特別有用。反過來問時，模型自己寫不出答案，但把正確答案混在幾個選項裡，它通常認得出來。認出答案比自己寫出答案容易，所以核對時不必叫 AI 憑記憶再答一遍，可以把知識庫裡的原文放到它面前，讓它逐句比對初稿，指出哪句找不到出處、哪個數字對不上、引用的是哪個版本。這樣一來，GVA 的核查這一步，大部分可以交給系統自動完成，並留下紀錄。

系統核對得了事實，卻核對不了用法，一份計劃書該強調哪一點、對客戶說到哪個程度，這些要由人判斷，也要事先講明由誰負責。因此 GVA 的最後一步，是指定的人看過核對結果，再決定能不能行動。

用協作平台串起知識庫和日常工具

上面講的是一份稿件從生成到發出的流程，要讓它天天運作，還有一個現實問題要解決。如果同事每次都要另開一個頁面向知識庫發問，再把答案複製回 WhatsApp 或電郵，這種手工作業不用多久就無以為繼。比較穩妥有效的做法，是在中間設置一個協作平台，一邊連接知識庫，一邊連接同事每天在用的工具，例如客戶關係管理系統（CRM）、電郵和即時通訊軟件。在這個安排裡，業務系統記錄「正在發生甚麼」，知識庫提供「過去知道甚麼」，協作平台負責把兩者連接起來，並按 GVA 的步驟走完生成、核查和審核。至於推行步驟，起步時先對接一兩個常用工具試用，確定資料可用、同事願用，才逐步擴大。

張Sir team的做法大致如此，自己的協作平台一頭串起知識庫，一頭對接第三方系統，最常對接的是 WhatsApp 和企業電郵，有時也對接飛書。不過串聯時有三件事最容易出錯。第一是權限，誰能看哪份資料，要在檢索時就過濾，不能先全部調出來，再在畫面上隱藏。第二是更新，業務系統裡的文件修改了或作廢了，知識庫要同步更新和刪除；舊版本即使需要存檔，也不能再用來回答現行問題，前面說的舊口號，就是更新這一步沒做好。第三是背景資料，只傳一句問題過去，答案往往很泛；平台連同客戶、項目和當前進度一併傳給知識庫，檢索才找得準。

至於 AI 生成的回覆能不能經平台直接由 WhatsApp 或電郵發送給客戶，按 GVA 的做法，起步時只作參考，由人確認後才發出。同樣道理，哪些環節可以自動、哪些必須由人確認、哪些結果可以寫回系統，都要事先講明。

交給 AI 寫之前，可以先做的幾件事

• 先判斷問題屬於哪一類。公司內部的、最新的、冷門的資料，先查知識庫再生成，不讓 AI 憑記憶寫。
• 重要的事實打開推理模式，並且從正反兩個方向各提問一次。
• 答案拿不準時，給 AI 幾個候選答案讓它挑，往往比讓它自己寫可靠。
• 初稿裡每個數字和專有名詞，都要能追回知識庫裡的原文，寫明版本和日期。
• 知識庫與業務系統同步更新和刪除，權限在檢索時就過濾。
• 核對完成後，由指定的人決定能不能發出。

張Sir在上一篇說，校對可以交給系統，判斷和責任要由人承擔，這篇算補上校對那一層怎樣做。企業不必等一個不會出錯的模型，因為幻覺很難完全消除，但若能分清是哪一種錯，在具有GVA 三步處理機制的協作平台上操作，大部分都能在發出之前攔截下來。

後記：這篇文章怎樣寫成

這篇由張Sir和 AI 協作完成，起點是從媒體的一篇介紹這項研究的報道。報道說該研究建議企業採用「先生成、後驗證」的流程，張Sir和 AI 追查論文原文，發現作者並沒有這樣建議，這是媒體的延伸解讀。核查一節於是改以論文本身「AI 認出答案比寫出答案容易」的發現為依據。另一處修改是協作平台的架構，初稿寫成把知識庫直接接入 WhatsApp，經張Sir更正，才改為協作平台居中，串起知識庫和第三方系統。其他大部分修正都採用張Sir積累更新的skill協助完成。

@張Sir的AI養生館 – 創新智人

***

參考資料

張Sir.（2026年9月27日）。老闆嫌不夠快，同事怕做得太快。張Sir的AI養生館。

Calderon, N., Ben-David, E., Gekhman, Z., Ofek, E., & Yona, G. (2026). Empty shelves or lost keys? Recall is the bottleneck for parametric factuality (arXiv:2602.14080v2) \[Preprint]. arXiv.