AI 有意識嗎?為什麼 ChatGPT 這麼好用卻常一本正經地出錯

AI 有意識嗎?為什麼 ChatGPT 這麼好用卻常一本正經地出錯

最近跟周遭的人聊天,發現大家對 AI 的想像落差大得驚人:有人受電影影響,擔憂 AI 哪天會毀滅人類 (覺得它快要有意識了),有人覺得它只是高級一點的搜尋引擎或聊天機器人。本篇嘗試回答一個更為實際的問題:我們手上的 AI 究竟是什麼?它為什麼有時非常有用,又為什麼常在關鍵時刻很笨?

之前在 ChatGPT 越用越焦慮?AI 時代知識工作者的心理健康指南 談過 AI 帶給知識工作者的焦慮,這篇想退一步,回到更根本的問題。

結論在前:把當前主流的聊天式 AI 拆開來看,它不是單一的神祕黑盒,而是 Transformer 語言模型、大規模預訓練、指令微調、檢索與工具呼叫,再加上外層工作流程與安全機制的組合。它能產生出驚人的結果,不是因為它有「意識」,而是因為它能從龐大的語言與程式語料中學到高度壓縮的統計規律,並在對的 prompt、工具與驗證配合下,把這些規律變成可用的輸出。

TL;DR:四個核心判斷

作為我個人的閱讀與消化筆記,本篇討論以下內容:

  • 主流 AI 本質上是機率式生成系統,不是數位意識:流暢的對話能力很容易觸發擬人化想像與過度信任。
  • 它常常「看起來很準」,靠的是三件事:規模化學到的統計規律、對使用者意圖的後訓練,以及工具與檢索帶來的外部 grounding。
  • Agent 不是魔法:通常只是把模型、工具、狀態、路由、重試與人類審核組成可執行的編排,而且不是每個任務都值得上 multi-agent。
  • 成熟 AI 使用不是迷信 prompt 咒語,認為 AI 所有事情都能做到:而是把任務定義清楚、給對上下文、要求來源、做交叉驗證。

LLM 大語言模型的基礎:Transformer

讓我們簡單回顧一下歷史。2017 年之前,主流的語言模型(RNN、LSTM)讀文字的方式,有點像被規定「一次只能看一個字,看完才能看下一個」:句子一長,前面的資訊就容易淡掉,訓練速度也快不起來,因為整個過程很難平行化。2017 年,Google 的研究團隊發表了一篇標題很有自信的論文 Attention Is All You Need 1,提出 Transformer 架構,讓模型不必只靠循環一步步傳遞記憶,而是能用 attention 直接找出句子裡彼此相關的位置。後面的故事發展得非常快:2018 年出現 BERT 與初代 GPT,2020 年 GPT-3 用規模證明了這條路走得通,2022 年底 ChatGPT 把它推到每個人面前。今天幾乎所有主流大語言模型 (Large Language Model, LLM)(GPT 系列、Claude、Gemini…)都建立在 Transformer 或其變體上。

timeline
    title Transformer 簡易發展史
    2017 以前 : RNN / LSTM
              : 一次讀一個字,句子一長就容易失憶
    2017 : Transformer 誕生
         : Attention Is All You Need
    2018 : BERT 與初代 GPT 分頭發展
    2020 : GPT-3 證明規模的威力
    2022 : ChatGPT 讓大眾第一次直接用上它

那 Transformer 到底是什麼?可以把它想成一台「很會抓重點的閱讀機器」。它在讀一段文字時,不是像以前的模型那樣主要靠從左到右慢慢記,而是讓句子裡的每個字(更準確說是 token)同時發問:「我現在最該注意哪些其他 token?」比方說讀到「小明把球丟給小華,然後他就跑走了」,機器在處理「他」這個位置時,會回頭衡量「小明」與「小華」哪一個更可能被指涉。這種「自己決定要看哪裡、看多用力」的能力叫 attention(注意力),正是 Transformer 的核心。

你不需要背任何數學式,只要抓住一個直覺:Transformer 會為句子裡的每個位置算出一張「注意力地圖」,標出該看哪裡、各看多重,再把看到的資訊混合起來,變成下一步要用的理解。也因為每個位置可以同時計算,它天生適合用大量 GPU 平行訓練,這正是後來模型能一路長大的工程原因。

flowchart LR
    A[輸入文字
「小明把球丟給小華」] --> B[切成 tokens]
    B --> C[Embedding
把每個 token 變成向量]
    C --> D[Self-Attention
每個位置都問:
我現在要注意誰?]
    D --> E[FFN
小腦袋再加工一次]
    E --> F[重複很多層
Layer 1..N]
    F --> G[輸出
下一個 token 的機率]

    D -.-> H[注意力地圖(概念)
「丟」會特別看「球」與「給誰」]

如果用更生活化的比喻:你在寫閱讀測驗時,看到題目「誰把球丟出去?」你的眼睛會自動回去掃描「誰」「丟」「球」「給誰」這幾個關鍵字,而不是把整段每個字都同等用力地記住。Transformer 做的就是把這種「回頭掃關鍵字」的行為,變成可以大規模訓練的計算。

也因此,當我們說「LLM 很聰明」時,背後其實是:它用 Transformer 在大量文本裡學會了『哪些詞通常一起出現、哪些句型常接在一起、哪些上下文暗示下一句該往哪裡走』這些統計規律,然後在生成時用這些規律一步步猜下一個 token。

這些詞在大語言模型的處理中經過 Embedding (更準確說,是將每個 token 轉換成一串向量空間的表示方式),所有的運算將變成數學問題進行機率預測:

如果想用一個簡單的數學比喻來理解,這些模型面對的問題比較像這樣:

x + y < 100,請找出 x 與 y 是多少

第一眼看起來沒什麼,但注意:這道題沒有唯一解。x = 10、y = 20 可以,x = 66、y = 33 也可以,符合條件的組合有無限多組。通常我們熟悉「x + 3 = 10,求 x」這種只有一個正確答案的問題;大語言模型解的卻比較像是「在一大堆可能答案裡,依照上下文挑一個看起來最合理的下一步」。

對應回文字生成:你給的上下文就像限制條件(x + y < 100),而模型從大量文本學到的統計規律,則告訴它哪些組合比較「像人會寫的」。所以同一個問題問它兩次,在系統允許隨機性的設定下,它可能一次回 x = 10、y = 20,另一次回 x = 66、y = 33:兩個答案都符合限制,但不相同。這個畫面值得先記住,因為它同時解釋了兩件事:為什麼 LLM 的回答有時不完全一樣,以及為什麼它偶爾會一本正經地答錯(「語言上合理」不等於「事實上正確」)。後面談到 decoding 與拉霸機的比喻時,我們會再回到這個直覺。

我們是否真正理解 AI?

基於現在 AI 大語言模型發展的結果,我自己的觀察是:科學界知道怎麼訓練這些模型,卻還沒有完整理解為什麼某些能力會在規模化後如此有效。我們對「怎麼做」的部分很清楚:訓練流程通常是用梯度下降,不斷降低「猜錯下一個 token」的損失,訓練程式與優化目標都是人設計的,沒有任何神祕成分。但對「為什麼有效」的部分,理解就薄弱得多:為什麼一個只被要求「猜下一個字」的系統,會順便學會文法、翻譯、寫程式,甚至一定程度的推理?為什麼參數多到理論上足以死背大量訓練資料的模型,卻能在沒看過的問題上泛化,而不是單純背答案?這些問題,目前的深度學習理論都還沒有完整的答案。

所以比較誠實的描述是:我們像是拿到了一份「照著做就會成功」的食譜,但還沒完全搞懂背後的化學反應。也因此出現了 mechanistic interpretability(機制可解釋性)這樣的研究領域:研究者像做神經科學一樣,把模型打開,在裡面尋找負責特定概念的迴路與特徵,試著回答「它到底學到了什麼」,但這門學問還非常年輕。這件事對一般使用者的意義很實際:模型的能力邊界是被「測出來」的,不是被「設計出來」的,所以連開發它的實驗室,也得靠大量評測才知道它哪裡強、哪裡弱。

一個我們尚未完全理解的系統,自然不該被當成保證正確的真理機器。

語言模型變成了一種通用文字介面

如果把近年 LLM 的發展壓縮成一句話:2017 年之後,語言模型不只是變大,而是變成了一種通用的文字介面。Transformer 提供了可平行化、可大規模訓練的注意力架構;BERT 2 把 encoder-only 路線推上理解任務的高峰;GPT-3 讓 few-shot 能力進入主流視野 3;InstructGPT 與後續的聊天模型則證明,後訓練與人類回饋往往比單純把模型做大,更能改善「照使用者的意思做事」的能力。

下面這條時間線嘗試勾勒出今天 LLM 與 agentic system 的骨架:

timeline
    title LLM 與 Agentic AI 的選擇性里程碑
    2017 : Transformer
    2018 : BERT
         : SentencePiece
    2019 : T5
         : BART
         : Sentence-BERT
    2020 : GPT-3
         : Scaling Laws
         : DPR
         : RAG
    2022 : InstructGPT
         : ReAct
         : Emergent Abilities
    2023 : GPT-4
         : Toolformer
         : AutoGen
         : CAMEL
         : Emergence Mirage Debate
    2024-2026 : 簡單可組合 agent patterns 成熟
         : 圖狀工作流與多代理編排文件化

把 Transformer 家族的主流骨架分開來看,會更容易理解「不同模型其實不是同一種工具」這件事:

類型 代表 主要運作方式 強項 常見限制
Encoder-only BERT 雙向讀取上下文,偏理解 分類、抽取、判斷、表示學習 不擅長自然生成長文本
Decoder-only GPT 類 自回歸地逐 token 生成 對話、寫作、程式生成、通用 completion 容易幻覺;事實更新仰賴工具或外部資料
Encoder-decoder T5 / BART 先編碼輸入,再解碼輸出 摘要、翻譯、問答、seq2seq 任務 較任務導向,不一定是最佳通用聊天骨幹

LLM 到底怎麼產生一句話

一個聊天式 LLM 生成回答時,最樸素的流程是:把文字切成 token、映射成向量、加上位置資訊,經過多層 self-attention 與前饋網路後,輸出「下一個 token 的機率分布」,再用 decoding 方法選出下一步,然後不斷重複直到結束。

這裡有三個需要注意的部分:

  1. token 不是字,也不是詞,而是模型字彙表中的切分單位。子詞化之所以重要,是因為自然語言是開放字彙:新詞、縮寫、專有名詞與拼法變形會不斷冒出。因此有很多進行切分的方式及研究,例如 BPE 的核心是用固定大小的詞彙表表示可變長度的子字串 4;SentencePiece 進一步做成語言無關、可直接從原始句子訓練的 tokenizer,對中文這種沒有空格斷詞的語言尤其重要 5
  2. 訓練資料不是知識庫,而是讓模型學習條件分布的語料。GPT-3 論文中提到,它是 1750 億參數的自回歸模型,訓練資料以 Common Crawl 為主,也包含書籍與 Wikipedia 3;OpenAI 對 GPT-4 的公開說法則是:base model 使用公開資料與授權資料預訓練,之後再以 RLHF 對齊使用者意圖 6。覆蓋面驚人,但網路世界的偏誤、冗餘與品質不均也一併被帶進模型。資料越多,不等於對世界的理解越完整
  3. 可用性主要來自後訓練。BERT 是雙向表徵模型,GPT-3 展示了 few-shot transfer,但真正讓「跟你說人話、照你的意思做事」變得可用的轉捩點,是 InstructGPT 這類以示範資料與人類偏好排序做後訓練的方法。OpenAI 在論文裡展示:一個 1.3B 的 InstructGPT,在人類偏好評分上可以勝過 175B 的原始 GPT-3 7。AI 好不好用,經常是訓練目標與介面設計的問題,不只是參數量的問題。

到了輸出階段,差別最大的往往不是模型知道多少,而是你怎麼從那個機率分布中抽樣 8。下面這張表,是理解「AI 為什麼有時很像拉霸機」的關鍵:

解碼方式 怎麼選下一個 token 優點 典型問題
Greedy 每一步都選最高機率 穩定、可重現、便宜 容易早早走入錯誤路徑
Beam Search 同時保留多條高機率候選序列 對結構化生成有時有效 追求模型機率,不等於追求真實或自然
Top-k / Top-p 只在高機率子集合中抽樣 平衡多樣性與流暢度 參數不好調時會發散或保守
Self-consistency 取樣多條思路再投票 對推理題常更準 成本更高,且仍可能集體錯誤

高準確率的拉霸機

世界上存在大量可壓縮的規律,而語言恰好把許多規律留下了痕跡。隨著模型、資料與算力增長,語言模型的能力會呈現可預期的改善 9;GPT-3 則展示了在大規模資料集訓練下,從 zero-shot 到 few-shot 的轉移能力 3。這不保證模型「理解」得像人,但只要任務與訓練分布之間有足夠重疊,它就可能非常好用。

準確度還有另一個來源:外部記憶與工具 (例如 RAG 方法, Retrieval-Augmented Generation)。RAG 的論文中強調參數式記憶存了很多知識,但在知識密集任務上,存取與更新仍然有限;然而,把模型接上向量索引之後,生成結果通常會更具體,也更貼近事實 10

因此,很多「看起來更聰明」的 agent,其實不是腦子突然長出來,而是多了外部工具與更好的控制流。

更精準地說,模型每一步會先算出下一個 token 的機率分布;系統再用 greedy、top-p、temperature 等 decoding 策略從中選出下一步。temperature 參數調高時 (在大語言模型中通常會增加輸出的隨機性創造力),回答更有創意、也更不穩定;同時,它也並非毫無規則地亂吐字,表現仍深深依賴已學到的統計結構、上下文與工具可用性。

flowchart LR
    A[低溫 / Greedy
單次命中率高、多樣性低
穩定保守,適合事實性任務] -->|調高隨機性| B[中溫 / Top-p
命中率與多樣性折衷
日常任務的平衡點]
    B -->|繼續調高| C[高溫 / 高採樣
單次命中率低、多樣性高
創意發散,驚喜與翻車並存]
    B -. 多次取樣再投票 .-> D[多路取樣後投票
命中率高、多樣性高
用成本與延遲換品質]
    C -. 多次取樣再投票 .-> D

Agentic 不是魔法,是編排

如果把 LLM 比喻成一顆很強但不夠穩定的文字推理核心,agent 就是把它接上現實世界的外殼。Anthropic 在〈Building effective agents〉裡的註解提到:工作流是讓 LLM 與工具沿著預先定義的 code path 被編排;agent 則是讓模型自己動態決定流程與工具的使用方式 11

Consistently, the most successful implementations weren’t using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns. — Anthropic

從工程實作的角度看,agent 的基本堆疊其實就是將人類的可執行步驟拆解 (模型、工具定義、狀態、路由、人類審核、紀錄與追蹤):

  1. 你把工具的框架告知大語言模型,最終由模型依照中間判斷決定是否呼叫
  2. 應用端執行工具拿回結果,再把 tool output 回送給模型產生最終回答

真正增加能力的,不是「Agent」這個字,而是把外部資料與動作安全地接進系統。

flowchart TD
    A[使用者需求] --> B[Router 或 Planner]
    B --> C[單一 LLM 判斷是否足夠]
    C -->|足夠| D[直接回答]
    C -->|不足| E[檢索或工具呼叫]
    E --> F[搜尋 / 資料庫 / API / 計算器]
    F --> G[專家代理或子任務]
    G --> H[Reviewer / Verifier]
    H --> I[帶來源或可執行結果的最終輸出]
    H -->|高風險或不確定| J[Human-in-the-loop]
    J --> I

上面這張圖,是把 ReAct 12、Toolformer 13、function calling、圖狀 workflow 與 human-in-the-loop 幾種思路,壓縮成同一張工程視角的流程圖。

當然,不是每個複雜任務都需要 multi-agent,有時候,許多任務靠一個 agent 配上對的工具與 prompt,就能達到相似的結果。我個人認為這點在 2025 到 2026 年的 AI Agent 狂熱裡特別重要,最大的風險之一,就是把「增加模型呼叫次數」誤當成「增加系統智慧」。

方式 代表脈絡 適合什麼 主要優點 主要代價
單一 agent + tools Function calling / skills 任務邊界明確、需要少量工具 成本低、除錯容易 上下文太多時容易混亂
Planner-executor ReAct 類 需要分步推理與外部查證 軌跡可檢查、較能減少幻覺 延遲增加
Multi-agent AutoGen / CAMEL / multi-agent frameworks 多領域、多人協作樣式、並行子任務 模組化、可分工 coordination 成本高、失敗面更多
Graph workflow LangGraph / workflow engines 長流程、狀態持久、人類審核 顯式控制、可觀測、可靠性較高 設計成本較高

AI 是否有意識?

綜觀圍繞人工智能相關電影的敘事,AI 幾乎總是被拍成兩種東西:要嘛像人,要嘛比人更像人,甚至帶來毀滅或負面結果,某種程度上挑起人類對於 AI 的恐懼。這些角色之所以迷人,正是因為它們被賦予了欲望、意圖、情感與自我。那是好的戲劇敘事,卻不是今天多數 LLM 系統的工程描述。

問題在於,當聊天模型越來越像在「與你對話」,人就越容易把它當成有內在主體的存在。更有意思的是,《Neuroscience of Consciousness》一項調查發現:一般大眾中多數受試者願意將「某種程度的意識可能性」歸給 LLM,而且使用頻率越高,這種傾向越強 14

所以比較嚴謹的說法,不是「AI 顯然已經有意識」,而是今天的公共討論,遠比科學判準成熟得更快。至少對當前主流部署系統來說,我們能確定的是:它們是為 token 預測、遵循指令、工具使用與 workflow 編排而設計的系統。至於它們是否具備主觀經驗,目前沒有公認的科學證據或測試能證成;工程上也不需要假設它們有自我、欲望或內在意圖,才能解釋其主要行為。

正在擴散的 AI Slop:AI 是否真的有用還是只是讓我們更累?

在這些 AI 工具普及下,我們也許需要想想另一個更迫切的問題:AI Slop。AI slop 指的是在低人類監督、低責任承擔、低品質門檻下大量製造的內容。

它可以是直接從 chatbot 回答複製貼上的低品質內容。問題不只在幻覺本身,更在數量:當整個網站、整串討論、整個 feed 都被低成本內容灌滿,SEO 農場與無人看管的內容農場,就會把資訊環境的信噪比一路往下拉。

Noy 與 Zhang 的實驗顯示,在 444 名受試者的中階專業寫作任務中,ChatGPT 讓平均完成時間下降約 40%、品質提高約 18% 15;Brynjolfsson、Li 與 Raymond 的客服研究則顯示,AI 輔助讓平均生產力提升約 14%,對新手與低技能工作者的幫助特別大,最高可達 34% 16。至少在「可文字化、可拆解、可評分」的任務上,LLM 是貨真價實的生產力工具。

但 AI slop 的擴散,提醒我們:「單次任務效率提升」不等於「整體資訊環境變好」。當每個人都能用極低成本生成大量「看起來合理」的內容時,內容的供給曲線會爆炸式右移,而人的注意力與審核能力卻不會等比例增加。結果往往是:

  • 你更快完成一篇稿,但讀者更難在海量內容裡找到真正有價值的那一篇
  • 你更快做出一份報告,但組織內部開始充斥大量互相引用、互相幻覺的「二手生成物」
  • 你更快得到一個答案,但你更難判斷它是否可信

Harvard 與 BCG 合作的「Jagged Technological Frontier」 研究則提醒我們:AI 帶來的不是一條平滑的能力曲線,而是一道鋸齒狀的前沿。對於落在前沿之內的顧問任務,使用 GPT-4 的參與者平均完成更多任務、速度快 25.1%、品質高出超過 40%;但對於落在前沿之外的任務,使用 AI 的人正確率反而比控制組低了 19 個百分點 17

也許,今天的 AI 最適合扮演的角色,比較像下面這樣:

任務類型 使用 AI 的適配度 為什麼
草稿、摘要、改寫、翻譯、格式整理 任務可文字化、容錯高、收益即時
企業內知識問答 中高 搭配檢索、權限與來源引用後很實用
程式輔助、測試樣板、文件生成 中高 對局部模式與 boilerplate 很強,但需 code review
多步驟流程自動化 要有工具、狀態管理與 human approval 才較可靠
醫療、法律、財務等高風險判斷 低到中 可當輔助,不宜當終審,必須外部驗證

寫到這裡,「prompt engineering」也許能更加去行銷化。Prompt 不是咒語,而是介面規格。它的重要性不在於某句神祕模板,而在於你是否把任務、上下文、限制與評分方式講清楚。

但問題在於,現今許多人相信 AI 工具能快速總結與摘要想知道的內容,因此往往跳過必要的領域知識學習與獨立思考,結果在解決特定領域問題時,反而寫不出好的 prompt。在軟體工程中,這就像無法把規格定義清楚,自然做不出有品質的應用程式。

是的,也許 AI 工具能讓不懂寫程式的人更快做出應用;但要審查程式碼結構、進行系統優化,乃至長期的維護,仍需要大量的領域知識與訓練。這也容易造就一種「外行已跨入特定領域」的假象,忽略了在下 prompt 時其實無法精準界定問題,最後只能得到模稜兩可、看似有道理的結論。

相對地,對於已具備專業知識的人而言,這些工具能精簡繁瑣的構思與整理流程,讓人把更多精力與時間投入最終的審查與調校。

結語

如果要用一句話收尾:今天的 AI 不是神,也不是玩具;它是一套高能力、機率式、可被工具增強、但仍需要設計與約束的系統。目前它最有價值的用法,不是取代思考,而是把重複、搜尋、草稿、重組、比較與初步推理等工作壓縮掉;相對地,則是在尚未建立驗證的認知前,就把它誤認成一切的真理。

下次再看到「AI 快要有意識了」這類標題時,不妨回到第一性原理,檢視 AI 背後實際的技術底層架構,讓我們能更理性地看待 AI 的發展趨勢。

參考資源

Eason Cao
Eason Cao Eason is an engineer working at FANNG and living in Europe. He was accredited as AWS Professional Solution Architect, AWS Professional DevOps Engineer and CNCF Certified Kubernetes Administrator. He started his Kubernetes journey in 2017 and enjoys solving real-world business problems.
comments powered by Disqus