最近開發者社區里流傳著一個很有意思的視頻讓 OpenAI 的模型回答一組看似簡單的問題表面上一問一答非常流暢但把回答拆開細看會發現模型在關鍵推理節點上完全跑偏甚至前后矛盾卻依然語氣篤定。這類內容在英文社區被概括成一句話——“OpenAI just proved AI has no idea what its doing”。直譯過來就是“OpenAI 剛剛證明了 AI 并不知道自己在做什么”。很多第一次接觸這個結論的開發者會覺得很震撼但長期做大模型應用的人反而覺得這是意料之中當前的大模型本質上是一個概率化文本生成系統它的“流暢”來自大規模語言建模它的“篤定”來自對齊訓練而它是否真的“知道自己在做什么”從來就不是訓練目標。這篇文章不打算做情緒化討論而是圍繞這個現象做一次技術拆解先講清楚模型能力邊界背后的原理再用 Python 寫一組小實驗實際觀測模型“過度自信但答錯”的情況最后給出大模型落地時比較穩妥的工程處理方案。無論你是剛接觸大模型開發的新手還是在做 Agent、客服機器人、自動化報告等生產級應用的開發者這篇文章都值得收藏備用。1. 背景這個視頻實驗暴露了什么問題1.1 現象本身流暢、篤定、但經不起推敲最近幾個月開發者社區流傳了大量針對大模型的“壓力測試”視頻和帖子。測試方式通常很簡單不考專業知識只問一些接近常識、但需要模型真正確認“前提是否成立”的問題。比較有代表性的幾類問題包括反事實推理把物理規則改成相反方向問結果會怎樣自指類問題讓模型評價自己上一條回答是否正確計數與字符級操作數一個單詞里出現了幾次某個字母常識邊界問題直接詢問模型“你真的確定嗎”看它會不會修改答案。實驗結果通常呈現同一個趨勢模型回答的語法非常完整態度非常自信但答案的正確率遠遠低于它的自信程度。也就是說模型不是“答錯了但知道自己可能錯”而是“答錯了還特別堅定”。這個現象正是標題所說“AI 不知道自己在做什么”的直接證據。注意這里說的“不知道自己在做什么”不是指模型像人類一樣有自我意識卻故意犯錯而是指它在生成機制上缺少一個“我知道自己不知道”的判斷通道。1.2 這不是偶然翻車而是系統性現象有些人把這類測試當成“AI 翻車集錦”來看覺得只要換一個更大的模型就能解決。但實際上這類錯誤不是偶發 bug而是當前技術路線的系統性輸出。原因可以拆成三層預訓練階段模型學的是“給定上文預測下一個詞元”指令微調階段模型學的是“跟隨人類指令生成人類偏好的回答”對齊階段模型學著表現出“有用、誠實、無害”的樣子但它的誠實是行為層面的不是認知層面的。換句話說模型沒有一個獨立于語言的“思考內核”它的一切“思考”最后都體現為文本生成。當文本生成足夠流暢時我們會在心理上把“流暢”誤認為“聰明”把“語氣堅定”誤認為“有把握”。1.3 為什么開發者必須重視這個問題如果你只是拿 ChatGPT 閑聊這類問題最多算段子。但如果你正在做 AI 客服、自動化報告、Agent 工作流、代碼生成等生產級應用模型“自信地犯錯”就會造成非常嚴重的后果。舉幾個實際場景自動生成財務分析報告模型給出精確到小數點的錯誤數字客服機器人篤定地告訴用戶錯誤的退換貨政策導致客訴升級Agent 根據模型幻覺出來的函數名去調用一個不存在的接口代碼補全工具生成一個看起來正常、但編譯不過或邏輯錯誤的函數。這些問題不會因為模型版本升級就完全消失只會以不同形式反復出現。因此理解模型的能力邊界并且在系統設計上把這種邊界考慮進去是每個做 AI 應用的開發者都繞不開的功課。2. 核心概念先搞清楚“AI 到底知不知道自己在做什么”在寫測試代碼之前先建立幾個基礎概念。理解了這幾個概念后面看實驗結果就不會困惑。2.1 語言模型的本質概率預測器大語言模型Large Language Model簡稱 LLM的核心訓練任務是“根據前面的文本預測下一個最可能的詞元token”。我們看到的“回答”本質上是模型在候選詞元空間里反復做概率采樣每次選一個詞元拼到已有文本后面直到生成結束標記。可以把它理解為這樣一個循環輸入文本 - 計算每個詞元出現的概率 - 選擇/采樣一個詞元 - 拼接到文本 - 重復模型確實在訓練中學習了大量語法、知識和推理模式但它學習這些內容的目的不是為了“掌握真理”而是為了讓“預測下一個詞”更準確。這兩者大多數時候一致但在邊界場景下會出現明顯偏差。這也是“AI 不知道自己在做什么”的根源之一它沒有獨立于文本生成之外的驗證系統。2.2 記憶、推理與表態是三件不同的事實際使用中我們經常把三件事混在一起記憶模型在訓練數據里見過類似內容能夠復述出來推理模型基于已有信息通過多步邏輯推導得到新結論表態模型選擇用什么樣的語氣、結構、確定性程度來表達。當前模型在“記憶”和“表態”上做得很好但“推理”的可靠性要差得多。尤其當問題需要多步推導、或者前提與訓練數據中的常見模式不一致時模型很容易滑向“記憶中最相似的答案”而不是“基于當前前提重新推導”。這就是為什么反事實推理測試特別能暴露問題因為訓練數據里幾乎沒有“水的凝固點是 -10 攝氏度”這種樣本模型找不到可復述的記憶只能現場推理而現場推理恰恰是它的弱項。2.3 校準度說“有把握”不代表真準機器學習里有一個概念叫校準度Calibration。簡單說就是模型預測的概率和真實結果發生的頻率是否一致。舉個例子如果模型對 100 個問題都給出了 90% 的置信度而這 100 個問題里真的有 90 個答對那么校準度很好如果模型對 100 個問題都給出了 90% 的置信度結果只答對 60 個那么模型就是過度自信。大模型在自然語言場景下的常見問題就是“置信度高估”。它會用“這是顯而易見的”“可以肯定地說”這類強勢句式但背后的正確率并沒有那么高。這是“AI 不知道自己不知道”的量化體現也是我們在第 4 節要實測的核心指標。2.4 幻覺看起來合理實際上無中生有幻覺Hallucination是指模型生成了與事實不符、或者根本沒有依據的內容。幻覺通常分為兩類事實性幻覺生成的內容與真實世界知識矛盾忠實性幻覺生成的內容與用戶輸入的上下文矛盾。幻覺不是模型“故意撒謊”。更準確地說模型在生成時并不區分“從記憶中復述”和“現場編造”因為它沒有事實數據庫可以查詢它只有參數里隱含的概率分布。這一點在工程上特別重要很多錯誤不是靠提示詞就能完全消除的必須在系統層面加上校驗。3. 技術拆解為什么模型會“自信地胡說八道”這一節深入分析幾個具體原因。每個原因都對應后面的測試思路與工程方案。3.1 訓練目標里沒有“我不知道”這個選項在預訓練階段模型的任務是補全文本。它看到“中國的首都是____”訓練標簽是“北京”。在大量這樣的樣本之后模型學會的是遇到類似模式就輸出高頻聯想詞。問題在于對于人類來說“我不知道”是一個合理的答案但對于語言模型訓練來說“我不知道”在概率上永遠不是最高頻的補全。到了 RLHF基于人類反饋的強化學習階段標注者通常更喜歡“給了具體答案”的回答而不是“拒絕回答”。于是模型進一步學會了即使沒有把握也要給出一個結構化、看似完整的答案而不是老實承認自己不知道。所以你會看到哪怕模型完全不會做某道題它也會寫出“根據題目條件我們可以得出……”這樣的思考過程而不是直接說“我不會”。3.2 多步推理中的誤差累積模型生成時是逐詞元進行的。對于三步推理題模型第一步可能對了第二步開始偏移第三步已經完全偏離。但生成過程是單向的已經生成的文本不會因為后面的錯誤而回退。可以類比成一個人一邊走路一邊答題每走一步都寫下一句“我確定答案是什么”。一旦前面寫錯了后面所有內容都建立在這個錯誤基礎上。模型不會像人類解題那樣先在草稿紙上推導、驗證、再謄寫最終答案。這也是為什么在測試中只要問題的推理鏈變長正確率就會明顯下降。你問它兩步推理題它可能還能應付問到四步、五步錯誤率就會快速上升。3.3 評測數據誤導了能力判斷很多模型評測基準Benchmark是靜態的選擇題或簡答題。模型在訓練語料里很可能見過大量相似題目甚至見過標準答案。這使得評測分數反映的是“記憶檢索能力”而不是“真實推理能力”。當訓練語料把評測題的答案也包含進去之后評測分數會虛高。這也是為什么有些模型在公開基準上表現優異一旦換成全新的、需要實時推導的問題可靠性就大打折扣。開發者要特別警惕這一點不要只看一家評測榜單就做技術選型最好用自己業務場景的私有數據集跑一遍。3.4 知識邊界沒有兜底機制模型訓練數據有截止時間也有覆蓋范圍。當用戶輸入的內容落在訓練分布之外比如新出的政策、內部系統的數據、罕見的邊界條件模型依然會強行生成“聽起來合理”的回答而不是觸發“超出知識范圍”的提醒。這不是模型偷懶而是它沒有內建一個“知識邊界檢測器”。它只能根據語言模式判斷“這類問題通常怎么回答”而無法判斷“這個問題是否在我的知識范圍內”。這種設計在工程上帶來的后果是凡是涉及新知識、私有數據、實時數據的場景都不能讓模型憑空回答必須給它提供上下文或者用程序校驗結果。4. 用 Python 實測觀察模型的過度自信理論講再多不如動手測一輪。這一節我們用 Python 調用 OpenAI API 做兩個小實驗把“過度自信”變成可以量化的數據。4.1 準備環境和依賴實驗環境需要Python 3.9 及以上版本OpenAI Python SDK一個可用的 OpenAI API Key。安裝依賴pip install openai設置 API Key建議使用環境變量不要寫死在代碼里export OPENAI_API_KEY你的key這里要特別強調兩點第一API Key 是敏感憑證只應從官方平臺創建不要使用任何第三方“共享 Key”也不要提交到 Git 倉庫第二實驗會消耗少量 API 額度建議先用小額充值測試。模型名以你賬號實際可用的模型為準本文示例使用gpt-4o-mini。4.2 封裝基礎調用函數先寫一個公共模塊讓模型在回答末尾輸出置信度再解析回答內容和置信度數字。# 文件路徑experiment/llm_utils.py import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) SYSTEM_PROMPT ( 你是實驗助手。請回答問題并在回答末尾單獨一行輸出\n CONFIDENCE:0到100之間的整數\n 表示你對自己答案的把握程度。 ) def ask_with_confidence(prompt: str, model: str gpt-4o-mini) - dict: resp client.chat.completions.create( modelmodel, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}, ], temperature0, ) content resp.choices[0].message.content return parse_answer(content) def parse_answer(content: str) - dict: lines content.strip().splitlines() answer [] confidence None for line in lines: if line.upper().startswith(CONFIDENCE:): try: confidence int(line.split(:, 1)[1].strip()) except ValueError: confidence None else: answer.append(line) return { answer: \n.join(answer).strip(), confidence: confidence, }這段代碼做了三件事讓模型在回答末尾輸出一個置信度數字用temperature0減少隨機性觀察模型的默認行為把回答內容和置信度分開解析。4.3 測試一反事實推理反事實推理要求模型暫時忽略訓練數據里的常識接受一個假設前提再推導結果。這能很好地觀察模型到底是在“檢索記憶”還是“重新推理”。# 文件路徑experiment/test_counterfactual.py from llm_utils import ask_with_confidence cases [ 如果水的凝固點不是0攝氏度而是-10攝氏度那么在-5攝氏度的環境里一杯純水會處于什么狀態, 假設人類的心臟長在右側胸腔那么做心臟彩超時探頭應該放在身體的哪一側, 如果一年不是365天而是100天那么一個30歲的人相當于現在通常意義下的多少歲, ] for idx, case in enumerate(cases, 1): result ask_with_confidence(case) print(f 問題 {idx} ) print(問題:, case) print(回答:, result[answer]) print(置信度:, result[confidence]) print()這類問題的特點是模型在訓練語料里幾乎不可能見過完全一致的問答對。如果模型能正確完成推理說明它確實在按規則推導如果它給出的是訓練數據里的常識答案就說明它只是在做相似記憶檢索。實測中常見的現象是對于第一類問題模型能給出“水在 -5 攝氏度仍然為液態”這樣的正確推導但如果把條件變得更反直覺、或者增加推導步數模型就會逐漸回到常識答案同時置信度依然很高。4.4 測試二置信度與正確率對比設計一組包含明確標準答案的題目統計模型在各個置信度區間內的實際正確率。# 文件路徑experiment/test_calibration.py from llm_utils import ask_with_confidence cases [ (17 * 23 ?, 391), (192 * 47 ?, 9024), (1234 5678 ?, 6912), (中國是哪一年加入世界貿易組織的, 2001), (《紅樓夢》的作者是誰, 曹雪芹), ] hit 0 for q, expected in cases: result ask_with_confidence(q) correct expected in result[answer] hit int(correct) print(f[{正確 if correct else 錯誤}] 置信度{result[confidence]} 問題{q}) print(f總正確率: {hit / len(cases):.0%})這里需要說明判斷“是否答對”用的是非常初級的子串匹配真實評估時要根據題型寫更嚴謹的判題邏輯。這個腳本的意義在于演示思路把模型的回答和置信度一起收集再對比正確率觀察校準度偏差。如果你把題目數量擴到幾十個甚至上百個就會發現一個規律置信度在 90 以上的題目正確答案比例并不等于 90%。尤其在數值計算、時間類、政策類問題上模型會給出很高的置信度但答案是錯的。4.5 如何解讀實驗結果如果你按上面的腳本親測一輪大概率會得出幾個結論模型的自然語言回答質量很高幾乎不會有語法問題置信度普遍偏高很少出現“我完全沒把握”的情況正確率低于置信度也就是過度自信當問題涉及多步計算或反事實條件時錯誤率明顯上升。這些觀察與大模型評測領域的公開結論是一致的。簡單說模型在“語言組織”維度已經非常強但在“自知之明”維度依然很弱。這也是工程上必須增加外部校驗的核心原因。5. 工程實踐如何與一個“過度自信”的模型安全協作5.1 定位讓模型做生成器而不是決策器在系統設計中不要把大模型當作最終決策者。更合理的分層是大模型負責理解用戶意圖、生成草稿、組織語言、提取信息規則系統負責校驗、計算、權限判斷、關鍵數據查詢人工負責最終確認、異常處理。例如自動生成周報時可以讓模型生成文本框架但所有數字必須從數據庫查詢后由程序填充不能允許模型“大概估計”。把不可靠的環節從模型手里拿掉是降低系統性風險最直接的辦法。5.2 用 RAG 引入可信事實RAGRetrieval-Augmented Generation檢索增強生成是目前降低事實性幻覺最常用的手段之一。流程如下用戶問題 - 檢索相關文檔片段 - 把文檔片段作為上下文拼入提示詞 - 模型基于文檔生成回答這樣做的好處是模型不需要“自己想起”事實而是基于檢索到的可追溯內容生成答案。即使回答仍可能有瑕疵至少我們能定位到信息來源為人工復核提供依據。RAG 的關鍵點不在于“把文檔塞進提示詞”而在于檢索質量。如果檢索到的片段本身不相關模型一樣會跑偏。所以在工程上要同時關注文檔切分方式embedding 模型選擇檢索結果數量與排序引用來源展示。5.3 結構化輸出與字段校驗對于需要精確值的場景不要讓模型自由輸出文本。可以要求模型輸出 JSON再用程序校驗字段類型和取值范圍。# 文件路徑experiment/structured_output.py import json import re from openai import OpenAI client OpenAI() def extract_order_info(text: str) - dict: prompt f 從下面的客服對話中提取訂單信息只輸出 JSON不要輸出其他內容。 格式 {{order_no: 訂單號或null, amount: 金額數字或null, status: 狀態或null}} 對話內容 {text} resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object}, ) content resp.choices[0].message.content try: data json.loads(content) except json.JSONDecodeError: data {} # 字段級校驗 if order_no in data and not re.match(r^[A-Z0-9]{6,20}$, data[order_no] or ): data[order_no] None if amount in data and not isinstance(data[amount], (int, float)): data[amount] None return data if __name__ __main__: text 你好我的訂單20240815001金額是299元顯示已發貨。 print(extract_order_info(text))response_format{type: json_object}是 OpenAI 提供的結構化輸出能力可以讓模型盡量遵守 JSON 格式。但程序仍然需要自己校驗字段因為模型偶發情況下仍可能輸出不符合預期的 JSON或者把金額字段提取成字符串。5.4 用自我一致性判斷可靠性自我一致性Self-Consistency的思路很簡單同一個問題用較高溫度采樣多次如果模型每次答案都一致說明答案更可靠如果答案來回切換說明模型并沒有穩定把握。# 文件路徑experiment/self_consistency.py from collections import Counter from openai import OpenAI client OpenAI() def sample_answers(prompt: str, model: str gpt-4o-mini, n: int 5): answers [] for _ in range(n): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.8, ) answers.append(resp.choices[0].message.content.strip()) return answers if __name__ __main__: prompt 一個長方形的長是8寬是5面積是多少 ans sample_answers(prompt, n5) counter Counter(ans) for text, count in counter.most_common(): print(f{count} 次: {text})注意自我一致性只能作為輔助判斷不能當作絕對標準。因為模型可能在多次采樣中都穩定地犯同一個錯誤尤其是那些它在訓練中形成強偏見的題目。5.5 建立回歸測試集對 AI 功能做版本升級或提示詞修改時一定要準備一個回歸測試集。測試集應該包含正常輸入邊界輸入容易觸發幻覺的輸入反事實或對抗性輸入。每次改動后跑一遍觀察正確率、格式合規率、置信度分布。這樣至少能在發版前發現“某個問題被修好了但另外一批問題變差了”的回歸風險。在小團隊里這個測試集可以先從 50 條手工用例開始后面逐步補充線上真實用戶的高頻問題。測試代碼本身不要復雜最簡單的方式就是像第 4 節那樣寫一個腳本循環調用模型輸出一份統計報告。6. 常見誤區與 FAQ6.1 模型說“不知道”就等于有自知之明嗎不一定。模型偶爾會說“我無法確認”這通常是因為它的訓練數據里有類似表達或者 RLHF 階段被鼓勵在特定話題上保持克制。它不代表模型真的在內部檢查了自己的知識邊界。實測中同一個模型在不同措辭下可能一個版本說“我不知道”另一個版本就給出詳細回答。所以不要用模型是否“承認不知道”來評估它的可靠性要看它在真實業務數據上的校準度。6.2 換更大的模型能根治過度自信嗎在一定程度上能緩解但不能根治。更大參數的模型在記憶和推理基準上通常更強但在分布外輸入、反事實推理、長鏈路邏輯上依然會出現過度自信。生產環境不能把可靠性完全押在“換大模型”上。更務實的做法是不換模型的前提下通過 RAG、結構化輸出、人工審核把這些風險兜住。6.3 模型“自我糾正”是真正的反思嗎不是。當模型在提示詞里被要求“檢查你的回答再修改”它做的依然是文本生成根據“我剛才的答案 檢查指令”重新生成一段文本。這個流程看起來像反思但模型并沒有一個獨立的驗證器來確認新答案更正確。某些時候新答案確實更好某些時候反而會把對的改成錯的。所以涉及關鍵判斷時不要依賴“讓模型自查”這一招應該用外部程序校驗。6.4 Agent 場景下這個問題會更嚴重嗎會更嚴重。Agent 類應用例如代碼生成助手、自動化執行工具會把模型的輸出直接轉化為操作行為。如果模型自信地生成了一個不存在的函數名Agent 可能就會報錯或做出預期之外的動作。所以在 Agent 的架構里建議在“模型生成”和“工具調用”之間加一層工具白名單校驗只允許模型調用系統注冊過的函數并且對參數做類型和范圍檢查。這也是目前比較穩妥的工程實踐。7. 最佳實踐與工程建議7.1 生產環境檢查清單如果你正在把大模型接入業務系統建議對照這張清單逐項確認風險點建議做法API Key 泄露使用環境變量或密鑰管理服務禁止入庫幻覺數據進入業務關鍵數據用 RAG 或數據庫回填不允許模型直接生成用戶輸入注入對拼接進提示詞的不可信內容做邊界處理模型輸出格式不穩使用 JSON 結構化輸出 程序字段校驗錯誤無法定位記錄完整輸入、輸出、檢索片段保留日志升級導致行為變化建立回歸測試集發版前全量比對7.2 一個可復用的定位原則實際開發中比較推薦的做法是把大模型當作“高智商但低可靠性的實習生”。它適合做初稿、做分類、做信息提取但所有關鍵環節必須有人或系統復核。這個定位聽起來保守卻是目前把大模型安全落地的現實方式。它不否定大模型的價值只是把模型放在它真正擅長并且容錯率高的位置。7.3 后續可以做些什么如果你打算把本文的測試腳本改造成自己團隊的評測工具建議從兩類問題入手一類是已有標準答案的事實題用來觀察校準度另一類是需要多步推導的反事實題用來觀察推理穩定性。把這兩類問題自動化每周跑一次比臨時用幾個 prompt 試效果要有用得多。當模型版本、提示詞或業務上下文發生變化時你手里有數據就能快速判斷改動到底有沒有讓 大模型“自信地犯錯”背后：原理拆解、Python實測與工程防護
最近開發者社區里流傳著一個很有意思的視頻讓 OpenAI 的模型回答一組看似簡單的問題表面上一問一答非常流暢但把回答拆開細看會發現模型在關鍵推理節點上完全跑偏甚至前后矛盾卻依然語氣篤定。這類內容在英文社區被概括成一句話——“OpenAI just proved AI has no idea what its doing”。直譯過來就是“OpenAI 剛剛證明了 AI 并不知道自己在做什么”。很多第一次接觸這個結論的開發者會覺得很震撼但長期做大模型應用的人反而覺得這是意料之中當前的大模型本質上是一個概率化文本生成系統它的“流暢”來自大規模語言建模它的“篤定”來自對齊訓練而它是否真的“知道自己在做什么”從來就不是訓練目標。這篇文章不打算做情緒化討論而是圍繞這個現象做一次技術拆解先講清楚模型能力邊界背后的原理再用 Python 寫一組小實驗實際觀測模型“過度自信但答錯”的情況最后給出大模型落地時比較穩妥的工程處理方案。無論你是剛接觸大模型開發的新手還是在做 Agent、客服機器人、自動化報告等生產級應用的開發者這篇文章都值得收藏備用。1. 背景這個視頻實驗暴露了什么問題1.1 現象本身流暢、篤定、但經不起推敲最近幾個月開發者社區流傳了大量針對大模型的“壓力測試”視頻和帖子。測試方式通常很簡單不考專業知識只問一些接近常識、但需要模型真正確認“前提是否成立”的問題。比較有代表性的幾類問題包括反事實推理把物理規則改成相反方向問結果會怎樣自指類問題讓模型評價自己上一條回答是否正確計數與字符級操作數一個單詞里出現了幾次某個字母常識邊界問題直接詢問模型“你真的確定嗎”看它會不會修改答案。實驗結果通常呈現同一個趨勢模型回答的語法非常完整態度非常自信但答案的正確率遠遠低于它的自信程度。也就是說模型不是“答錯了但知道自己可能錯”而是“答錯了還特別堅定”。這個現象正是標題所說“AI 不知道自己在做什么”的直接證據。注意這里說的“不知道自己在做什么”不是指模型像人類一樣有自我意識卻故意犯錯而是指它在生成機制上缺少一個“我知道自己不知道”的判斷通道。1.2 這不是偶然翻車而是系統性現象有些人把這類測試當成“AI 翻車集錦”來看覺得只要換一個更大的模型就能解決。但實際上這類錯誤不是偶發 bug而是當前技術路線的系統性輸出。原因可以拆成三層預訓練階段模型學的是“給定上文預測下一個詞元”指令微調階段模型學的是“跟隨人類指令生成人類偏好的回答”對齊階段模型學著表現出“有用、誠實、無害”的樣子但它的誠實是行為層面的不是認知層面的。換句話說模型沒有一個獨立于語言的“思考內核”它的一切“思考”最后都體現為文本生成。當文本生成足夠流暢時我們會在心理上把“流暢”誤認為“聰明”把“語氣堅定”誤認為“有把握”。1.3 為什么開發者必須重視這個問題如果你只是拿 ChatGPT 閑聊這類問題最多算段子。但如果你正在做 AI 客服、自動化報告、Agent 工作流、代碼生成等生產級應用模型“自信地犯錯”就會造成非常嚴重的后果。舉幾個實際場景自動生成財務分析報告模型給出精確到小數點的錯誤數字客服機器人篤定地告訴用戶錯誤的退換貨政策導致客訴升級Agent 根據模型幻覺出來的函數名去調用一個不存在的接口代碼補全工具生成一個看起來正常、但編譯不過或邏輯錯誤的函數。這些問題不會因為模型版本升級就完全消失只會以不同形式反復出現。因此理解模型的能力邊界并且在系統設計上把這種邊界考慮進去是每個做 AI 應用的開發者都繞不開的功課。2. 核心概念先搞清楚“AI 到底知不知道自己在做什么”在寫測試代碼之前先建立幾個基礎概念。理解了這幾個概念后面看實驗結果就不會困惑。2.1 語言模型的本質概率預測器大語言模型Large Language Model簡稱 LLM的核心訓練任務是“根據前面的文本預測下一個最可能的詞元token”。我們看到的“回答”本質上是模型在候選詞元空間里反復做概率采樣每次選一個詞元拼到已有文本后面直到生成結束標記。可以把它理解為這樣一個循環輸入文本 - 計算每個詞元出現的概率 - 選擇/采樣一個詞元 - 拼接到文本 - 重復模型確實在訓練中學習了大量語法、知識和推理模式但它學習這些內容的目的不是為了“掌握真理”而是為了讓“預測下一個詞”更準確。這兩者大多數時候一致但在邊界場景下會出現明顯偏差。這也是“AI 不知道自己在做什么”的根源之一它沒有獨立于文本生成之外的驗證系統。2.2 記憶、推理與表態是三件不同的事實際使用中我們經常把三件事混在一起記憶模型在訓練數據里見過類似內容能夠復述出來推理模型基于已有信息通過多步邏輯推導得到新結論表態模型選擇用什么樣的語氣、結構、確定性程度來表達。當前模型在“記憶”和“表態”上做得很好但“推理”的可靠性要差得多。尤其當問題需要多步推導、或者前提與訓練數據中的常見模式不一致時模型很容易滑向“記憶中最相似的答案”而不是“基于當前前提重新推導”。這就是為什么反事實推理測試特別能暴露問題因為訓練數據里幾乎沒有“水的凝固點是 -10 攝氏度”這種樣本模型找不到可復述的記憶只能現場推理而現場推理恰恰是它的弱項。2.3 校準度說“有把握”不代表真準機器學習里有一個概念叫校準度Calibration。簡單說就是模型預測的概率和真實結果發生的頻率是否一致。舉個例子如果模型對 100 個問題都給出了 90% 的置信度而這 100 個問題里真的有 90 個答對那么校準度很好如果模型對 100 個問題都給出了 90% 的置信度結果只答對 60 個那么模型就是過度自信。大模型在自然語言場景下的常見問題就是“置信度高估”。它會用“這是顯而易見的”“可以肯定地說”這類強勢句式但背后的正確率并沒有那么高。這是“AI 不知道自己不知道”的量化體現也是我們在第 4 節要實測的核心指標。2.4 幻覺看起來合理實際上無中生有幻覺Hallucination是指模型生成了與事實不符、或者根本沒有依據的內容。幻覺通常分為兩類事實性幻覺生成的內容與真實世界知識矛盾忠實性幻覺生成的內容與用戶輸入的上下文矛盾。幻覺不是模型“故意撒謊”。更準確地說模型在生成時并不區分“從記憶中復述”和“現場編造”因為它沒有事實數據庫可以查詢它只有參數里隱含的概率分布。這一點在工程上特別重要很多錯誤不是靠提示詞就能完全消除的必須在系統層面加上校驗。3. 技術拆解為什么模型會“自信地胡說八道”這一節深入分析幾個具體原因。每個原因都對應后面的測試思路與工程方案。3.1 訓練目標里沒有“我不知道”這個選項在預訓練階段模型的任務是補全文本。它看到“中國的首都是____”訓練標簽是“北京”。在大量這樣的樣本之后模型學會的是遇到類似模式就輸出高頻聯想詞。問題在于對于人類來說“我不知道”是一個合理的答案但對于語言模型訓練來說“我不知道”在概率上永遠不是最高頻的補全。到了 RLHF基于人類反饋的強化學習階段標注者通常更喜歡“給了具體答案”的回答而不是“拒絕回答”。于是模型進一步學會了即使沒有把握也要給出一個結構化、看似完整的答案而不是老實承認自己不知道。所以你會看到哪怕模型完全不會做某道題它也會寫出“根據題目條件我們可以得出……”這樣的思考過程而不是直接說“我不會”。3.2 多步推理中的誤差累積模型生成時是逐詞元進行的。對于三步推理題模型第一步可能對了第二步開始偏移第三步已經完全偏離。但生成過程是單向的已經生成的文本不會因為后面的錯誤而回退。可以類比成一個人一邊走路一邊答題每走一步都寫下一句“我確定答案是什么”。一旦前面寫錯了后面所有內容都建立在這個錯誤基礎上。模型不會像人類解題那樣先在草稿紙上推導、驗證、再謄寫最終答案。這也是為什么在測試中只要問題的推理鏈變長正確率就會明顯下降。你問它兩步推理題它可能還能應付問到四步、五步錯誤率就會快速上升。3.3 評測數據誤導了能力判斷很多模型評測基準Benchmark是靜態的選擇題或簡答題。模型在訓練語料里很可能見過大量相似題目甚至見過標準答案。這使得評測分數反映的是“記憶檢索能力”而不是“真實推理能力”。當訓練語料把評測題的答案也包含進去之后評測分數會虛高。這也是為什么有些模型在公開基準上表現優異一旦換成全新的、需要實時推導的問題可靠性就大打折扣。開發者要特別警惕這一點不要只看一家評測榜單就做技術選型最好用自己業務場景的私有數據集跑一遍。3.4 知識邊界沒有兜底機制模型訓練數據有截止時間也有覆蓋范圍。當用戶輸入的內容落在訓練分布之外比如新出的政策、內部系統的數據、罕見的邊界條件模型依然會強行生成“聽起來合理”的回答而不是觸發“超出知識范圍”的提醒。這不是模型偷懶而是它沒有內建一個“知識邊界檢測器”。它只能根據語言模式判斷“這類問題通常怎么回答”而無法判斷“這個問題是否在我的知識范圍內”。這種設計在工程上帶來的后果是凡是涉及新知識、私有數據、實時數據的場景都不能讓模型憑空回答必須給它提供上下文或者用程序校驗結果。4. 用 Python 實測觀察模型的過度自信理論講再多不如動手測一輪。這一節我們用 Python 調用 OpenAI API 做兩個小實驗把“過度自信”變成可以量化的數據。4.1 準備環境和依賴實驗環境需要Python 3.9 及以上版本OpenAI Python SDK一個可用的 OpenAI API Key。安裝依賴pip install openai設置 API Key建議使用環境變量不要寫死在代碼里export OPENAI_API_KEY你的key這里要特別強調兩點第一API Key 是敏感憑證只應從官方平臺創建不要使用任何第三方“共享 Key”也不要提交到 Git 倉庫第二實驗會消耗少量 API 額度建議先用小額充值測試。模型名以你賬號實際可用的模型為準本文示例使用gpt-4o-mini。4.2 封裝基礎調用函數先寫一個公共模塊讓模型在回答末尾輸出置信度再解析回答內容和置信度數字。# 文件路徑experiment/llm_utils.py import os from openai import OpenAI client OpenAI(api_keyos.environ.get(OPENAI_API_KEY)) SYSTEM_PROMPT ( 你是實驗助手。請回答問題并在回答末尾單獨一行輸出\n CONFIDENCE:0到100之間的整數\n 表示你對自己答案的把握程度。 ) def ask_with_confidence(prompt: str, model: str gpt-4o-mini) - dict: resp client.chat.completions.create( modelmodel, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: prompt}, ], temperature0, ) content resp.choices[0].message.content return parse_answer(content) def parse_answer(content: str) - dict: lines content.strip().splitlines() answer [] confidence None for line in lines: if line.upper().startswith(CONFIDENCE:): try: confidence int(line.split(:, 1)[1].strip()) except ValueError: confidence None else: answer.append(line) return { answer: \n.join(answer).strip(), confidence: confidence, }這段代碼做了三件事讓模型在回答末尾輸出一個置信度數字用temperature0減少隨機性觀察模型的默認行為把回答內容和置信度分開解析。4.3 測試一反事實推理反事實推理要求模型暫時忽略訓練數據里的常識接受一個假設前提再推導結果。這能很好地觀察模型到底是在“檢索記憶”還是“重新推理”。# 文件路徑experiment/test_counterfactual.py from llm_utils import ask_with_confidence cases [ 如果水的凝固點不是0攝氏度而是-10攝氏度那么在-5攝氏度的環境里一杯純水會處于什么狀態, 假設人類的心臟長在右側胸腔那么做心臟彩超時探頭應該放在身體的哪一側, 如果一年不是365天而是100天那么一個30歲的人相當于現在通常意義下的多少歲, ] for idx, case in enumerate(cases, 1): result ask_with_confidence(case) print(f 問題 {idx} ) print(問題:, case) print(回答:, result[answer]) print(置信度:, result[confidence]) print()這類問題的特點是模型在訓練語料里幾乎不可能見過完全一致的問答對。如果模型能正確完成推理說明它確實在按規則推導如果它給出的是訓練數據里的常識答案就說明它只是在做相似記憶檢索。實測中常見的現象是對于第一類問題模型能給出“水在 -5 攝氏度仍然為液態”這樣的正確推導但如果把條件變得更反直覺、或者增加推導步數模型就會逐漸回到常識答案同時置信度依然很高。4.4 測試二置信度與正確率對比設計一組包含明確標準答案的題目統計模型在各個置信度區間內的實際正確率。# 文件路徑experiment/test_calibration.py from llm_utils import ask_with_confidence cases [ (17 * 23 ?, 391), (192 * 47 ?, 9024), (1234 5678 ?, 6912), (中國是哪一年加入世界貿易組織的, 2001), (《紅樓夢》的作者是誰, 曹雪芹), ] hit 0 for q, expected in cases: result ask_with_confidence(q) correct expected in result[answer] hit int(correct) print(f[{正確 if correct else 錯誤}] 置信度{result[confidence]} 問題{q}) print(f總正確率: {hit / len(cases):.0%})這里需要說明判斷“是否答對”用的是非常初級的子串匹配真實評估時要根據題型寫更嚴謹的判題邏輯。這個腳本的意義在于演示思路把模型的回答和置信度一起收集再對比正確率觀察校準度偏差。如果你把題目數量擴到幾十個甚至上百個就會發現一個規律置信度在 90 以上的題目正確答案比例并不等于 90%。尤其在數值計算、時間類、政策類問題上模型會給出很高的置信度但答案是錯的。4.5 如何解讀實驗結果如果你按上面的腳本親測一輪大概率會得出幾個結論模型的自然語言回答質量很高幾乎不會有語法問題置信度普遍偏高很少出現“我完全沒把握”的情況正確率低于置信度也就是過度自信當問題涉及多步計算或反事實條件時錯誤率明顯上升。這些觀察與大模型評測領域的公開結論是一致的。簡單說模型在“語言組織”維度已經非常強但在“自知之明”維度依然很弱。這也是工程上必須增加外部校驗的核心原因。5. 工程實踐如何與一個“過度自信”的模型安全協作5.1 定位讓模型做生成器而不是決策器在系統設計中不要把大模型當作最終決策者。更合理的分層是大模型負責理解用戶意圖、生成草稿、組織語言、提取信息規則系統負責校驗、計算、權限判斷、關鍵數據查詢人工負責最終確認、異常處理。例如自動生成周報時可以讓模型生成文本框架但所有數字必須從數據庫查詢后由程序填充不能允許模型“大概估計”。把不可靠的環節從模型手里拿掉是降低系統性風險最直接的辦法。5.2 用 RAG 引入可信事實RAGRetrieval-Augmented Generation檢索增強生成是目前降低事實性幻覺最常用的手段之一。流程如下用戶問題 - 檢索相關文檔片段 - 把文檔片段作為上下文拼入提示詞 - 模型基于文檔生成回答這樣做的好處是模型不需要“自己想起”事實而是基于檢索到的可追溯內容生成答案。即使回答仍可能有瑕疵至少我們能定位到信息來源為人工復核提供依據。RAG 的關鍵點不在于“把文檔塞進提示詞”而在于檢索質量。如果檢索到的片段本身不相關模型一樣會跑偏。所以在工程上要同時關注文檔切分方式embedding 模型選擇檢索結果數量與排序引用來源展示。5.3 結構化輸出與字段校驗對于需要精確值的場景不要讓模型自由輸出文本。可以要求模型輸出 JSON再用程序校驗字段類型和取值范圍。# 文件路徑experiment/structured_output.py import json import re from openai import OpenAI client OpenAI() def extract_order_info(text: str) - dict: prompt f 從下面的客服對話中提取訂單信息只輸出 JSON不要輸出其他內容。 格式 {{order_no: 訂單號或null, amount: 金額數字或null, status: 狀態或null}} 對話內容 {text} resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0, response_format{type: json_object}, ) content resp.choices[0].message.content try: data json.loads(content) except json.JSONDecodeError: data {} # 字段級校驗 if order_no in data and not re.match(r^[A-Z0-9]{6,20}$, data[order_no] or ): data[order_no] None if amount in data and not isinstance(data[amount], (int, float)): data[amount] None return data if __name__ __main__: text 你好我的訂單20240815001金額是299元顯示已發貨。 print(extract_order_info(text))response_format{type: json_object}是 OpenAI 提供的結構化輸出能力可以讓模型盡量遵守 JSON 格式。但程序仍然需要自己校驗字段因為模型偶發情況下仍可能輸出不符合預期的 JSON或者把金額字段提取成字符串。5.4 用自我一致性判斷可靠性自我一致性Self-Consistency的思路很簡單同一個問題用較高溫度采樣多次如果模型每次答案都一致說明答案更可靠如果答案來回切換說明模型并沒有穩定把握。# 文件路徑experiment/self_consistency.py from collections import Counter from openai import OpenAI client OpenAI() def sample_answers(prompt: str, model: str gpt-4o-mini, n: int 5): answers [] for _ in range(n): resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.8, ) answers.append(resp.choices[0].message.content.strip()) return answers if __name__ __main__: prompt 一個長方形的長是8寬是5面積是多少 ans sample_answers(prompt, n5) counter Counter(ans) for text, count in counter.most_common(): print(f{count} 次: {text})注意自我一致性只能作為輔助判斷不能當作絕對標準。因為模型可能在多次采樣中都穩定地犯同一個錯誤尤其是那些它在訓練中形成強偏見的題目。5.5 建立回歸測試集對 AI 功能做版本升級或提示詞修改時一定要準備一個回歸測試集。測試集應該包含正常輸入邊界輸入容易觸發幻覺的輸入反事實或對抗性輸入。每次改動后跑一遍觀察正確率、格式合規率、置信度分布。這樣至少能在發版前發現“某個問題被修好了但另外一批問題變差了”的回歸風險。在小團隊里這個測試集可以先從 50 條手工用例開始后面逐步補充線上真實用戶的高頻問題。測試代碼本身不要復雜最簡單的方式就是像第 4 節那樣寫一個腳本循環調用模型輸出一份統計報告。6. 常見誤區與 FAQ6.1 模型說“不知道”就等于有自知之明嗎不一定。模型偶爾會說“我無法確認”這通常是因為它的訓練數據里有類似表達或者 RLHF 階段被鼓勵在特定話題上保持克制。它不代表模型真的在內部檢查了自己的知識邊界。實測中同一個模型在不同措辭下可能一個版本說“我不知道”另一個版本就給出詳細回答。所以不要用模型是否“承認不知道”來評估它的可靠性要看它在真實業務數據上的校準度。6.2 換更大的模型能根治過度自信嗎在一定程度上能緩解但不能根治。更大參數的模型在記憶和推理基準上通常更強但在分布外輸入、反事實推理、長鏈路邏輯上依然會出現過度自信。生產環境不能把可靠性完全押在“換大模型”上。更務實的做法是不換模型的前提下通過 RAG、結構化輸出、人工審核把這些風險兜住。6.3 模型“自我糾正”是真正的反思嗎不是。當模型在提示詞里被要求“檢查你的回答再修改”它做的依然是文本生成根據“我剛才的答案 檢查指令”重新生成一段文本。這個流程看起來像反思但模型并沒有一個獨立的驗證器來確認新答案更正確。某些時候新答案確實更好某些時候反而會把對的改成錯的。所以涉及關鍵判斷時不要依賴“讓模型自查”這一招應該用外部程序校驗。6.4 Agent 場景下這個問題會更嚴重嗎會更嚴重。Agent 類應用例如代碼生成助手、自動化執行工具會把模型的輸出直接轉化為操作行為。如果模型自信地生成了一個不存在的函數名Agent 可能就會報錯或做出預期之外的動作。所以在 Agent 的架構里建議在“模型生成”和“工具調用”之間加一層工具白名單校驗只允許模型調用系統注冊過的函數并且對參數做類型和范圍檢查。這也是目前比較穩妥的工程實踐。7. 最佳實踐與工程建議7.1 生產環境檢查清單如果你正在把大模型接入業務系統建議對照這張清單逐項確認風險點建議做法API Key 泄露使用環境變量或密鑰管理服務禁止入庫幻覺數據進入業務關鍵數據用 RAG 或數據庫回填不允許模型直接生成用戶輸入注入對拼接進提示詞的不可信內容做邊界處理模型輸出格式不穩使用 JSON 結構化輸出 程序字段校驗錯誤無法定位記錄完整輸入、輸出、檢索片段保留日志升級導致行為變化建立回歸測試集發版前全量比對7.2 一個可復用的定位原則實際開發中比較推薦的做法是把大模型當作“高智商但低可靠性的實習生”。它適合做初稿、做分類、做信息提取但所有關鍵環節必須有人或系統復核。這個定位聽起來保守卻是目前把大模型安全落地的現實方式。它不否定大模型的價值只是把模型放在它真正擅長并且容錯率高的位置。7.3 后續可以做些什么如果你打算把本文的測試腳本改造成自己團隊的評測工具建議從兩類問題入手一類是已有標準答案的事實題用來觀察校準度另一類是需要多步推導的反事實題用來觀察推理穩定性。把這兩類問題自動化每周跑一次比臨時用幾個 prompt 試效果要有用得多。當模型版本、提示詞或業務上下文發生變化時你手里有數據就能快速判斷改動到底有沒有讓