從文字接龍到工作助理

一、LLM 是什麼？從文字接龍開始

大家好，今天想跟各位聊聊，我們平常使用的 AI 聊天工具，究竟是怎麼運作的。

我們先從一個小例子開始。

假設你看到：

Hello

接下來會想到什麼？

有人想到「Hello World」，有人想到「Hello everyone」，也有人會接上一個人的名字。

如果前面正在介紹程式設計的入門範例，「Hello World」就很合理；如果前面是在準備演講，「Hello everyone」就更適合。

根據前面的內容，預測接下來要出現什麼，這就是大型語言模型，也就是 LLM，生成文字的基本方式。

我們可以把它想成一個經過大量訓練的文字接龍機器人。

它先讀取前面的內容，產生下一個文字片段，再把剛剛產生的內容接回去，繼續預測。這個過程反覆進行，就形成了我們看到的句子、文章，或一整段對話。

模型處理的文字片段叫作 token。有時候是一個字，有時候是一個詞，也可能是某個詞的一部分。今天只要先把它理解成「模型處理文字時使用的單位」就好。^[1]

那麼，回答問題是怎麼回事？

我們可以把對話想成這樣：

使用者：請幫我寫一封活動邀請信。
助理：

模型要接下去的，就是「助理」後面的內容。

經過學習和訓練，它會逐漸學會：在這種對話裡，接下來應該是一封符合要求的邀請信；使用者要求修改語氣時，接下來應該是修改後的版本；需要更多資料時，接下來可以是一個詢問。

所以，從回答問題到修改文章，背後都可以沿著同一條主線理解：讀取目前的內容，判斷適合的後續，再逐步生成。

二、什麼決定模型的能力？

接龍的方式看起來很簡單，難度在於：要接得合理，模型需要掌握多少事情？

例如，寫一封活動邀請信，它需要掌握邀請信的格式、對象與語氣，還要把活動時間、地點、目的安排進適合的位置。

如果使用者補上一句「這是給已經很熟的合作夥伴」，整封信的表達方式又會改變。

模型的能力，就體現在它能學到多少規律，以及能把這些規律運用得多好。

它過去學到了什麼

訓練時，模型會從大量資料中學習。

有些是語言的規律，例如句子怎麼組成、正式和輕鬆的語氣有什麼差別；有些是概念與事實之間的關係，例如什麼是訂單、什麼是出貨、延誤通常需要向客戶說明哪些事情。

這些學習會反映在模型內部的參數中，影響它之後怎麼接續文字。^[1]

我們可以用「Hello」的例子來理解。

模型在訓練時接觸過許多「Hello World」的程式範例，就比較容易在類似情境裡接出這個組合。它也接觸過演講開場、日常問候和書信，因此能依照情境，選擇不同的後續內容。

這些規律還能組合使用。

假設公司今天才決定，把年度活動命名為「青禾計畫」。你把這項資訊交給模型：

今年的活動名稱是「青禾計畫」，主題是鼓勵同仁提出改善工作流程的建議。

接著請它寫邀請信，它就能結合現在收到的活動資訊，以及過去學到的寫作方式，完成一封新的信。

這裡有兩種資訊共同發揮作用：

過去的訓練，提供能力；現在收到的內容，提供這次工作的依據。

它怎麼運用眼前的資訊

我們來看一份簡單的生活紀錄：

昨天的晚餐是水餃。
今天的午餐是炒飯。
今天的晚餐是牛肉麵。
明天預計吃火鍋。

問題是：

今天的晚餐是什麼？

各位很快就能找到「牛肉麵」。

這個過程裡，你其實同時對上了兩個條件：「今天」和「晚餐」。其他句子雖然也提到食物，但時間或餐別不同。

模型也需要把問題與前文裡相關的資訊連結起來。

常見語言模型裡的「注意力機制」，就是讓不同位置的資訊彼此參照的一種計算方式。處理「今天的晚餐」這個問題時，相關的日期、餐別和食物名稱，就需要對後續回答產生適當的影響。^[2]

現在把紀錄改成：

今天晚餐原本打算吃牛肉麵，後來店家休息，最後改吃咖哩飯。

再問：

今天晚餐最後吃了什麼？

答案變成咖哩飯。

這一次，模型還需要處理「原本」「後來」「最後」之間的關係，才能從多個食物名稱中選出正確答案。

換成工作情境，也是同樣的道理：

原訂週五出貨，後來因為供貨延誤，改成下週一出貨。

整理這段資訊時，模型需要分清楚原始安排和最新安排。

因此，我們觀察模型能力時，可以看它是否抓得到相關資訊、是否分得清楚條件，以及是否能處理轉折、先後順序和例外。這些表現，是模型設計、訓練與整體計算共同作用的結果。

三、模型為什麼有時候答不出來，或者答錯？

前面談到的是模型本身的能力。實際使用時，還有一個很重要的環節：

這次工作需要的資料，有沒有真的交到模型手上？

各位可以把它想成一位正在處理工作的同事。

他的專業經驗，是過去已經學會的能力；他桌上攤開的資料，則是這次工作的依據。

你請他整理會議結論，他需要拿到會議紀錄。你請他確認訂單狀態，他需要取得那張訂單的資料。

模型也是根據這一次收到的內容作答，而應用程式會負責整理哪些資料要送給它。

例如，你上傳一份一百頁的員工手冊，詢問：

出差住宿費怎麼申請？

有些系統會先搜尋文件，找出與「出差」「住宿」「申請」相關的段落，再把這些段落交給模型。^[3]

假設搜尋找到的是一般申請流程，特殊情況的補充規則放在附錄，而附錄這次沒有被取出，模型收到的資料就會缺少那部分。

最後的回答，也就可能漏掉特殊情況。

這時候，改善的方向就很具體：讓系統找到那份附錄，再把完整的適用條件交給模型。

另外一種情況，是模型在資料有缺口時，依照訓練中學到的常見模式，繼續產生一段完整的回答。這時候，就容易出現看起來合理、實際卻缺乏根據的內容，也就是常說的「幻覺」。模型也可能在資料已經提供的情況下，因為解讀或推論出錯而產生錯誤答案。^[4]

我們用一個假設例子來看。

你問：

我們公司的出差住宿上限是多少？

模型手上缺少你們公司的規定，卻回答：

每晚住宿上限為三千元，超過部分須事先申請。

這段話有金額、有條件、有程序，讀起來很像一份完整制度。

問題就在於，它使用了「公司規定通常怎麼寫」的模式，填補了「這家公司實際規定什麼」的資料缺口。

文字的完整程度，和資料的完整程度，是兩件事。

因此，工作上可以把「找出缺少的資料」也納入交辦。例如：

請依照提供的員工手冊，整理住宿費申請規則，並附上對應段落。資料不足的項目，列入待確認事項。

這樣，任務就包含三件事：找到規定、整理內容，以及標示目前還缺哪些資訊。

使用者也有明確的檢查方式：回到它引用的段落，核對金額、適用對象和例外條件。

四、接龍怎麼變成寫程式、操作電腦？

先從寫程式談起。

程式碼是一種有明確語法的文字，用來描述電腦要執行的步驟。

例如，我們用日常語言說：

把所有訂單的金額加總，再列出還沒付款的訂單。

程式就是把這個要求，轉成電腦能執行的格式。

模型透過學習程式碼與需求之間的關係，就能根據你的要求，逐步生成對應的程式。程式產生後，再透過執行與測試取得結果，進一步修改。

接著，我們來看「操作電腦」。

假設你問：

我的電腦還剩多少儲存空間？

在純文字對話裡，模型可以提出下一步：

請打開儲存空間設定，把畫面上的剩餘容量告訴我。

你查完之後回覆：

剩下 128 GB。

模型取得資訊，就能繼續回答：

目前剩餘空間是 128 GB。

這個流程裡，模型負責判斷需要什麼資料；你負責查詢，再把結果傳回去。

現在，我們把中間的查詢工作交給軟體。

先替軟體準備一個工具，例如「查詢磁碟空間」，並把工具用途和呼叫格式告訴模型。

當使用者詢問剩餘容量時，模型就能產生一份給軟體處理的請求。概念上，像這張工作單：

工具：查詢磁碟空間
對象：使用者電腦的系統磁碟

軟體收到請求，執行查詢，再把結果交回模型：

查詢成功。剩餘空間：128 GB。

模型根據結果，整理成我們看到的回答：

你的系統磁碟目前還剩下 128 GB。

模型提出工具請求，軟體執行，結果回傳，再由模型接著處理。這就是工具呼叫的基本流程。實際實作時，模型會使用軟體約定好的格式，填入工具名稱和所需資料，讓軟體可以辨識和執行。^[5]

原本模型向使用者詢問「請你幫我查一下」，現在則可以把這個請求交給工具。

從使用者的角度看，就是 AI 自己查了電腦。

把內部拆開來看，則是幾個部分合作：模型判斷接下來要做什麼，外部軟體安排執行，工具取得資料或完成操作，再把結果送回來。

這個負責組織對話、安排工具執行、把資料交給模型的外部軟體，常被稱為 harness。今天可以把它理解成 AI 的「工作協調系統」。^[8]

從一次查詢，到連續完成一項工作

同樣的流程可以反覆進行。

例如，你交辦：

幫我找出這個月尚未出貨的訂單，依延誤天數排序，整理成一份報表。

系統可以先讓模型呼叫訂單查詢工具，取得本月訂單。

模型看到結果後，選出尚未出貨的項目；接著透過計算工具算出延誤天數，再把整理好的資料交給報表工具，產生檔案。

如果查詢時發現有訂單缺少預計出貨日期，它也可以把這些訂單整理成待確認項目。

每一步都沿用相同的循環：

取得資料 → 判斷下一步 → 使用工具 → 查看結果 → 繼續處理。

這就是許多 AI 代理系統的基本工作方式。^[5]

它能完成的工作範圍，取決於模型能力、提供的工具，以及工具所具備的權限。

只有查詢權限，工作就停在查詢和整理；有建立檔案的工具，就能產生報表；有寄信工具與相應授權，就能進一步寄送。

我們也可以把確認程序放進流程。例如，系統先完成收件人清單和信件草稿，由負責人核准後，再執行寄送。

工具結果則提供了檢查工作的依據：查詢有回傳資料、報表有實際檔案、寄信有寄送紀錄。每個步驟都能對應到可確認的結果。

五、LLM 的限制

工作進行到這裡，模型已經收到問題、提出工具請求，也取得查詢結果。

隨著工作繼續，這些內容會逐漸累積。接下來就會遇到兩個特性：一次能處理的資料有容量限制，而每一輪作答都需要系統提供當次要使用的資訊。

5.1 一次能處理的資料，有長度上限

我們可以把模型每次收到的內容，想成一份「工作資料包」。

這份資料包有容量限制，也就是通常所說的上下文長度。計算容量時，會包含角色設定、工具說明、對話內容和工具結果等資訊，系統也需要為接下來產生的回答安排空間。這些內容的長度，以前面介紹的 token 為單位計算。^[6]

我們沿用查詢電腦空間的例子。

你在畫面上只問了一句：

我的電腦還剩多少儲存空間？

當模型已經提出查詢請求，工具也回傳結果後，下一次交給模型的工作資料包，可能長這樣：

角色設定：
你是一位協助使用者處理電腦問題的助理。

工具說明：
你可以使用「查詢磁碟空間」工具，指定要查詢的磁碟。

使用者問題：
我的電腦還剩多少儲存空間？

模型提出的工具請求：
請查詢這台電腦的系統磁碟。

工具回傳的結果：
查詢成功，剩餘空間為 128 GB。

模型根據這一整份內容，接著產生我們看到的回答。

如果你繼續問「哪些資料夾占用最多空間」，這個新問題、前面的回答、接下來的工具請求，以及工具查到的資料，也可能一起加入工作資料包。

因此，你在聊天框裡輸入的問題可能很短，模型實際收到的內容卻可能很長。歷次問答、工具操作與查詢結果，都可能累積成下一次作答的上下文。^[6]

想像你請 AI 整理訂單。你只打了「幫我整理這個月的延誤訂單」，工具卻查回幾百筆訂單資料。這次主要占用空間的，就是那些查詢結果。

隨著工作持續進行，資料包會越來越大。要讓模型在原有容量裡繼續工作，協調系統就需要安排取捨，例如保留近期對話、縮短舊資料，或將一部分內容整理成摘要。^[8]

這就像工作桌上已經堆滿文件，接下來要決定：哪些繼續攤在桌上，哪些整理成筆記，哪些收進資料櫃，等需要時再拿出來。

5.2 每一次回答，都根據當次取得的資料生成

另一個重要特性是：模型每次被呼叫，都根據當次取得的資料作答。對話之間的連續性，靠系統把需要的內容延續到下一輪。^[7]

例如，假設你在某個聊天裡說：

我在台積電工作。

接著在同一個聊天裡問：

我在哪一家公司工作？

協調系統把前面的對話一起提供給模型，模型就能從裡面找到「台積電」。

現在換個情況。你開了一個新聊天，系統這次提供的內容只有：

角色設定：
協助使用者回答問題。

使用者問題：
我在哪一家公司工作？

這份資料包裡缺少你的工作資訊，模型就缺少回答公司名稱的依據。

同樣的道理也適用於正在進行中的工作。

假設你先請 AI 寫一封信，接著說：

把第二段改得客氣一點。

為了完成修改，模型這一次取得的資料裡，需要包含前面那封信。協調系統會把需要延續的內容帶到這一輪，讓模型接著處理。^[7]

從使用者的角度，這是一段持續進行的對話；從模型的角度，則是一輪又一輪取得資料、產生回答的過程。

於是，接下來就有兩個很實際的問題：

聊得越來越長時，資料要怎麼整理？開了新聊天之後，重要資訊又要怎麼帶過去？

六、怎麼延續長對話，以及跨聊天保留資訊？

6.1 壓縮：把長對話整理成交接摘要

第一種做法叫作「壓縮」。

其中一種常見方式，是在上下文接近上限時，請模型整理目前的對話，再用這份摘要替換較早的內容。協調系統也可以另外保留最近幾輪原文，讓工作從整理過的上下文繼續進行。^[8]

我們可以把它想成工作交接。

你和同事討論了一整個下午，內容包含需求、查詢結果、不同方案，以及最後的決定。接手的人需要一份交接紀錄，知道目前做到哪裡、有哪些條件、下一步要做什麼。

對話壓縮做的就是類似的事情。

協調系統可以請模型整理：

目前的工作目標是什麼？
已經確認哪些條件？
做過哪些查詢，得到什麼結果？
還有哪些事情待處理？

模型依照這些要求，挑選它判斷值得保留的內容，整理成較短的摘要。之後，系統把摘要與需要保留的其他資料一起交回模型。

原本的資料包是：

角色設定與工具說明
完整的歷次對話
完整的工具請求與查詢結果
最新問題

整理後，可以變成：

角色設定與工具說明
先前工作的交接摘要
最近幾輪對話
最新問題

使用者仍然在同一個聊天畫面裡繼續操作，模型則改用這份縮短後的資料接續工作。^[8]

6.1.1 為什麼聊到一半，會感覺它突然忘東忘西？

我們來看一個活動規劃的例子。

假設一開始，你的要求是：

幫我規劃一場 60 人的公司活動，總預算十萬元。
場地要有電梯，因為有同事行動不便。
活動必須在下午五點前結束。

接下來，你和 AI 討論了場地、餐點、交通，也查了很多資料。

對話變長後，系統啟動摘要。模型整理出：

正在規劃一場 60 人的公司活動，預算十萬元。已比較 A、B 兩個場地，接下來需要推薦適合的方案。

各位看看，少了什麼？

「場地要有電梯」和「下午五點前結束」都消失了。

摘要保留了活動主題、人數和預算，卻遺漏了兩個會影響選擇的重要條件。

這種摘要遺漏，是長對話接續時可能出現的資訊損失。摘要的選擇與保留方式，會影響模型後面取得的工作依據。^[8]

接下來，我們設計兩種交接方式，看看差異。

第一種：主要靠摘要接續。

角色設定與工具說明

對話摘要：
正在規劃 60 人的公司活動，預算十萬元。
已比較 A、B 兩個場地，接下來需要推薦方案。

使用者最新問題：
你推薦哪個場地？

在這個例子裡，模型收到的條件只剩下人數和預算。它接下來可能推薦價格合適、空間也足夠，但只有樓梯的場地。

你看了就會覺得：

我前面明明講過要有電梯，怎麼又忘了？

問題可以一路追到交接的那一刻：原本存在的條件，在摘要時被漏掉，而新的資料包也沒有補回來。

第二種：重新附上原始要求，再接續摘要。

角色設定與工具說明

使用者原始要求：
60 人，總預算十萬元。
場地要有電梯。
活動必須在下午五點前結束。

對話摘要：
已比較 A、B 兩個場地，接下來需要推薦方案。

使用者最新問題：
你推薦哪個場地？

這次，即使摘要漏寫了電梯和結束時間，模型仍然能在原始要求裡找到這兩個條件，重新拿它們來評估場地。

所以，這個例子的交接品質，受到兩個環節影響：

模型把摘要寫得如何，以及協調系統另外保留了哪些資料。

再把情境往前推一步。

假設討論到一半，你又說：

人數改成 50 人，預算也調整成八萬元。

那麼，我們在設計交接資料時，就可以把「最新確認條件」獨立列出：

原始需求：
規劃公司活動，場地有電梯，下午五點前結束。

最新確認條件：
人數已由 60 人改成 50 人。
預算已由十萬元改成八萬元。

目前進度：
已比較 A、B 兩個場地。

接下來的工作：
依照最新條件重新比較，提出推薦方案。

這樣，原始目標、中途修改和目前進度，都有各自的位置。

也就呼應了前面談過的那個問題：

模型這一次，實際拿到了什麼？

當你發現它突然回到舊方案、重新詢問已經確認的事情，或忽略早先的重要條件，交接資料是否完整，就是一個值得檢查的環節。

6.2 記憶：把重要資訊存起來，在之後的聊天取用

第二種做法，是記憶。

我們沿用剛才的例子。假設你在舊聊天裡說：

我在台積電工作，請記住這件事。

在具備記憶工具的系統裡，模型可以提出儲存請求，由外部軟體把資料寫入持續保存的記錄。之後的聊天，再透過系統載入或工具讀取，將需要的資訊帶回模型的上下文。^[9]

概念上，這個儲存請求可以寫成：

請儲存以下使用者資訊：
使用者曾表示，他在台積電工作。

協調系統執行儲存後，這項資訊就像一張放進資料櫃的備忘錄。

等到下一個聊天，你問：

我在哪一家公司工作？

系統把相關記憶取出來，這次送給模型的資料包就變成：

角色設定：
協助使用者回答問題。

工具說明：
目前可以使用的工具與操作方式。

相關使用者記憶：
使用者曾表示，他在台積電工作。

使用者問題：
我在哪一家公司工作？

模型這次有了依據，就可以回答：

你之前提過，你在台積電工作。

從使用者的角度看，AI 記得上一次聊天的事情；從流程來看，則是系統先保存資訊，再在新的作答過程中把它取回來。

記憶也可以依照問題需要再查詢。例如，系統先收到「我在哪裡工作」，再透過記憶工具尋找相關紀錄，把查詢結果交給模型。

這讓系統能將大量資訊放在外部儲存，需要哪一部分，就取用哪一部分。^[9]

在工作上，同樣的方式可以用來保留專案背景、已確認的決策，以及需要跨次使用的偏好。

資訊有變動時，記憶也需要跟著更新。例如，專案負責人已經更換，就要讓後續取用的紀錄反映新的狀態。我們可以在工作流程裡安排：重要資訊確認後儲存，變更時更新，過期時標示或移除。

6.3 壓縮與記憶，分別在處理什麼？

我們再用剛才的工作桌，整理這兩個概念。

壓縮，是把桌上累積的大量文件，整理成一份較短的交接紀錄。

它著重的是：這項工作已經進行了一段時間，接下來要留下哪些資訊，才能繼續做。

記憶，是把值得日後使用的資訊，存進可以再次調閱的資料櫃。

它著重的是：離開目前這一輪工作之後，哪些資訊還需要在之後取用。

兩種方式可以一起使用：先把工作進度整理成摘要，再把重要決策保存起來；下次繼續時，取回相關紀錄，放進新的工作資料包。

外部保存的資訊可以很多，而每次取回、交給模型處理的內容，仍然需要安排在當次的上下文容量裡。^[8][9]

到這裡，我們就能看出，AI 能否把一項工作持續做好，除了模型本身的能力，還有一整套資料交接流程在發揮作用。

每一輪交給它什麼、哪些內容整理成摘要、哪些決定長期保存，以及下一輪又取回哪些資訊，都會影響它接下來的表現。

七、非科技工作者，可以怎麼把這些觀念用在日常工作？

理解前面的原理後，我們可以把 AI 的使用方式，放回日常的工作交辦。

以客戶回信為例。

一句：

幫我處理這個客戶的抱怨。

裡面還有很多需要補上的資訊：客戶遇到什麼事情？哪些事實已經確認？公司目前核准哪些處理方式？最後要產出草稿，還是執行寄送？

我們可以把交辦寫成這樣：

請幫我撰寫一封客戶回信草稿。

已確認的情況是：這筆訂單原訂週五出貨，因供貨延誤，確定需要延期。目前正在向供應商確認新的出貨日期。

回信請先致歉，再說明目前進度，最後告知客戶，出貨日期確認後會另行通知。

補償方案仍待主管核准，先列為內部待確認事項。

語氣誠懇，完成後交給我審閱。

模型現在拿到了這次工作的事實、目的、語氣，以及處理到哪個階段。

它可以據此產生：

您好，很抱歉此次訂單因供貨延誤，需要調整原訂週五的出貨安排，造成您的不便。

我們正在向供應商確認後續進度，新的出貨日期確認後，會再通知您。

對於此次延誤，再次向您致歉，也謝謝您的耐心。

審閱時，我們就能對照原始交辦，確認它有沒有忠實使用已知資訊、語氣是否合適，以及需要核准的事項是否留在正確的處理階段。

如果這項工作持續了好幾天，中間又有多次更新，我們可以把最新狀態整理出來：

目前確認下週一出貨。
主管已核准免除本次運費。
客戶尚未收到更新通知。
下一步是修改回信草稿，審閱後寄出。

這份紀錄就能成為後續交接的依據。即使對話經過摘要，或換到新的工作階段，也有一份清楚的最新狀態可以取用。

未來，這項工作還可以逐步擴充。

先由人提供訂單資訊，讓模型寫草稿；接著串接訂單系統，讓它取得最新進度；再接上寄送工具，完成核准後寄信。

每增加一個環節，就清楚定義它需要的資料、可以執行的動作，以及完成後的檢查方式。

這樣，前面談過的幾個概念就串起來了：模型運用語言能力完成文字工作，工具提供查詢與執行能力，摘要協助延續長流程，記憶則保存之後還會用到的重要資訊。

八、結語

今天我們從文字接龍開始，走到了能夠連續處理工作的 AI 助理。

整個過程可以串成一條線：

模型透過訓練學會規律，利用當次取得的資料生成內容，再透過外部工具取得新資訊或執行動作，根據結果繼續推進工作。

當資料逐漸累積，協調系統透過摘要與取捨整理上下文；需要跨次延續的資訊，則透過記憶保存，再於之後取用。

這也給了我們一套很實際的使用方式。

交辦之前，準備好工作目的和必要資料；處理過程中，確認它實際取得哪些資訊、有哪些工具可以使用；工作延續時，保留重要條件和最新決定；工作完成後，按照原始資料和執行紀錄檢查成果。

當它回答出錯，就沿著這條流程找原因：資料是否完整、解讀是否正確、交接是否遺漏，以及工具是否完成操作。

把資料交清楚，把工作範圍說清楚，把重要決定留清楚，把成果的檢查方式定清楚，AI 就更容易成為一位能協助我們完成工作的助理。

謝謝大家。