目錄

1?輸入：從用戶提問到模型"看得懂"的矩陣

2?Transformer架構與自注意力機制：模型如何“理解”上下文

3?輸出：從logits到人類語言的“翻譯”

4?位置編碼和長文本外推

5?實踐與思考

6 寫在最后

本文介紹了AI大語言模型的完整工作流程，從文本輸入的預處理到最終輸出的生成過程。文章系統性地介紹了分詞與嵌入、Transformer架構、自注意力機制、位置編碼、長文本外推等核心技術概念，并結合DeepSeek V3等實際案例進行詳細說明。同時，本文還提供了豐富的工程實踐指導，包括上下文優化、耗時控制、多Agent協同等實用策略關注騰訊云開發者，一手技術干貨提前解鎖

在 ai 時代，也許我們應該先了解大模型是如何解答我們的問題的，了解大模型能做什么或者擅長做什么，如此才能更好的利用它。本文盡量以非技術的方式來解釋 ai 大語言模型的工作原理，以及在工程實踐中如何更好的使用。

01輸入：從用戶提問到模型"看得懂"的矩陣

1.1?輸入實際是文本

首先我們要知道的是，輸入給到大語言模型的是一個組合文本（稱之為上下文），包括：

系統提示詞（對應"你是個智能助手，回答時要可愛些"這種）

可用工具列表描述（對應Function Call能力）

歷史對話（包括之前的問題和回答）

用戶最新提問

如下為目前共識的OpenAI API協議輸入示例，這些都將合并作為大模型調用的一次輸入（省略了部分工具描述信息，僅做理解）：

messages = [? ? {"role":?"system",?"content":?"你是個智能助手，回答時要可愛些"}, ? ?// 系統提示詞? ? {"role":?"user",?"content":?"你好"}, ? ? ? ? ? ? ? ? ? ? ? ? ??// 歷史提問? ? {"role":?"assistant",?"content":?"你好，有什么能幫到你呀"}, ? ? ? ?// 歷史回答? ? {"role":?"user",?"content":?"查詢下今日天氣"}, ? ? ? ? ? ? ? ??// 最新提問]tools = [{"type":"function","function":{"name":"get_weather","description":"Get current weather information"}}]

敲黑板：這部分需要理解的是輸入實際是個文本，并且每次調用大模型都是獨立的，能夠與用戶互動是因為工程上在每次調用時將歷史對話加了進去。因此在一輪對話中每次調用時輸入的組合文本（即上下文）會越來越長，這點很重要。

1.2?文本如何變成數字：分詞與嵌入

理解了輸入文本，那么文本如何實際轉換為大模型計算時需要的矩陣呢（這里需要知道的是，大模型核心是進行大量的數學運算，主要是矩陣乘法），這里主要是分詞和嵌入兩步。

分詞

相當于把文本"切碎"成更小的單元token。比如：

中文文本中，"北京"可能被切分為1個token，"的"也是1個token

英文，單詞"unhappy"可能被拆成"un"和"happy"兩個token

每個符號、數字都會單獨處理作為一個token

需要注意的是這里分詞的規則在不同的大模型里是不一樣的，有的模型可能一個漢字平均1 token，有的可能平均要0.5 token。

分詞完成后，每個token會通過預訓練的詞匯表映射為對應的數字ID，可以理解為token對應在詞表中的位置，一般大模型對應的詞表長度為幾萬甚至幾十萬。

嵌入

嵌入過程則更加精妙。模型通過一個可學習的嵌入矩陣，將每個token的數字ID轉換為固定維度的向量。比如，ID為100的token可能變成一個512維的向量?[0.1, -0.3, ..., 0.8]?這些向量不僅包含詞匯的語義信息，還能在數學空間中表示詞與詞之間的關系，舉例來說"貓"和"狗"對應的向量在這512維空間里更接近或者說更相似。

如此，輸入文本開始先轉換為n個token，經過嵌入后轉換為n個512維的向量，合并即為n×512的輸入矩陣。

敲黑板：這部分需要理解的是文本在給到模型計算之前會轉換為token序列，這里對應token的長度n就是文本中“詞”的數量，這里n就是最終輸入的上下文長度。

1.3?上下文長度的限制

需要注意的是，目前大模型都會對上下文長度有嚴格限制，當給到的上下文長度超過限制大小時會直接報錯（這里是對應DeepSeek V3開源代碼的實現），不過大部分工程實踐上在累計內容超過上下文窗口時，會自動丟棄最早的數據，保留最新的內容，確保總長度不超過模型的處理能力。

敲黑板：上下文長度有限制，不能無限增加，而且需要注意的是這里上下文長度限制是包含輸出長度的，即理論上最大的輸入上下文長度為128k - 4k = 124k（以DeepSeek-Chat默認為例），為什么后面會解釋。

通過這一系列精密的轉換過程，人類的自然語言最終變成了模型能夠進行數學計算的矩陣形式，為后續的理解和生成奠定了基礎。

02Transformer架構與自注意力機制：模型如何“理解”上下文

現在我們已經有了一個包含詞義的輸入矩陣，接下來就要進入大模型的核心計算環節——Transformer架構。這個架構的精髓在于自注意力機制，它讓模型能夠真正“理解”文本中各個詞語之間的復雜關系。

2.1?自注意力：模型如何“聚焦”重要信息

想象一下你閱讀一段文字時，大腦會自動關注與當前理解最相關的詞語，自注意力機制就是讓模型實現類似的能力。在實現上，每個自注意力模塊都包含三個不同的權重矩陣：Wq、Wk、Wv，對應的值是通過大量訓練得到的。

Q、K、V矩陣：信息的三種角色

每個輸入token經過與上述三個不同的權重矩陣相乘，分別生成三個矩陣：

Query（Q）矩陣：代表"我想要什么信息"，用于主動詢問其他token

Key（K）矩陣：可以理解為"該token擁有什么信息"，用于回應其他token的詢問

Value（V）矩陣：可以理解為該token的包含內容信息的多少

這三個矩陣可以理解為信息交流的三個角色：Q是提問者，K是應答者，V是實際要傳遞的內容。有了上述矩陣，接下來會對每個token計算它與之前所有token的關聯信息。

計算注意力分數：用當前token的Query和之前所有token的Key內積計算得到對應注意力分數，可以理解為當前token與之前token在這個注意力模塊下的關聯程度。分數越高，代表該部分信息越重要。

生成加權平均輸出：最后，用上一步得到的注意力分數作為權重，分別與之前所有token的Value相乘并求和得到最終的注意力信息（注：實際計算要復雜些，這里不做展開），這里可以理解為融合了之前所有序列上下文信息的新的向量。

經過上面的計算后，得到了每個token與上下文關聯的信息，這個過程確保了模型的回復是基于整個上下文生成的，而不僅僅是孤立的最新問題。

敲黑板：簡單來講，自注意力機制就是將每個token與之前所有token通過計算得到相關信息，需要著重理解的是最后一個token的注意力信息包含了整個上下文所有信息。

2.2?多頭注意力：多角度理解文本

單一注意力機制可能不夠全面，因此Transformer采用了多頭注意力設計。可以理解為多個相同結構、但不同權重矩陣的自注意力模塊共同組成，這些模塊并行計算，并在最終輸出時合并。

不同注意力頭就像不同的“專家”，各自關注文本的不同方面，所有頭的計算結果最終拼接在一起，通過線性變換融合成完整的輸出。這種設計讓模型能夠同時從多個角度理解文本，大大增強了表達能力。

2.3?前饋網絡層

上面提到了Transformer架構的核心是自注意力模塊，但又不止于此，一個完整的Transformer層主要包括多頭自注意力層以及前饋網絡層（還有別的模塊，偏技術細節不影響理解這里不做展開）。

如果說自注意力機制的作用是“聚合信息”——將序列中所有位置的信息通過注意力權重整合到一起，那么前饋網絡層的作用就是"加工和提煉這些聚合后的信息"。

您可以將其類比于人類的理解過程：

自注意力層：相當于你聽取了一場討論，了解了每個人（每個詞）的觀點以及它們之間的關聯。

前饋網絡層：相當于你回到自己的辦公室，獨自消化和深入思考剛才聽到的所有信息，形成自己更深刻、更抽象的理解。

如此，一個 transformer 層結構可以簡略表示為下圖：

敲黑板：實際上可以簡單理解，通過注意力機制讓模型能夠學到利用并關聯上下文信息，通過前饋網絡層讓模型能學到特征的進一步提取和轉換。

2.4?大模型之“大”

都說大模型，大模型到底大在何處？

參數量

參數量是衡量模型復雜度的核心指標，Transformer架構的大模型通常擁有數百億甚至數千億參數，這么多參數都體現在哪？前面介紹了Transformer層包括多頭注意力層和前饋網絡層，在實際我們使用的大模型中都會對這兩部分進行優化調整，同時通過對Transformer層進行堆疊來增加模型的表現力。

以DeepSeek V3為例，其注意力層為潛在多頭注意力層（MLA，這個是為了減少緩存的使用，不展開介紹），頭數為128，對應有128個自注意力模塊，前饋網絡層包括257個專家（包括一個共享專家，256個可選專家，這里可以理解為257個前饋網絡層并行，這跟多頭很類似，區別是這里專家是選擇使用的），然后這樣的Transformer層在DeepSeek V3中有58層，還有3層無專家的Transformer層，共61層。

其中參數量主要由專家組成，一共14906個專家，每個專家有7168×2048×3 = 44,040,192個參數，一共有6564.6億個參數，算上其他的參數，總共是6710億。當然由于DeepSeek的專家是可選的，每次計算只使用256中的8個，實際計算使用的參數約為370億。

訓練量

大模型這么大的參數量，每個參數的取值都是通過一次次訓練來逐漸調整的，訓練數據要求非常大。同樣以DeepSeek V3為例，其預訓練階段就使用了14.8萬億token的數據集進行預訓練，需要知道的是，大模型在訓練時每條數據都不會只用來訓練1次，而是訓練多次。

03輸出：從logits到人類語言的“翻譯”

經過前兩章的介紹，我們已經知道模型如何將用戶提問轉換為矩陣輸入，以及如何通過自注意力機制理解上下文關系。現在，模型手中已經有了一個包含豐富語義信息的“隱藏狀態矩陣”（即上面的輸出矩陣，可以理解為經過了多層Transformer后，對每個token位置都生成了一個包含所有上下文信息的高維向量），接下來需要完成最關鍵的一步：將這些抽象的高維向量“翻譯”回人類能夠理解的自然語言。

3.1?線性層：從隱藏狀態到詞匯表映射

隱藏狀態矩陣中的每個向量都濃縮了對應token的上下文信息，但這些向量仍然處于模型內部的表示空間。為了生成人類可讀的文字，模型需要通過線性層將這些向量映射到詞匯表空間。

線性層的作用相當于一個"翻譯官"，它將每個token對應的高維向量轉換為一個長度等于詞匯表大小的新向量。如果詞匯表包含5萬個詞，那么線性層的輸出就是一個5萬維的向量，每個維度對應詞匯表中一個特定詞的可能性得分。因為我們輸入時n個token，所以這里會得到n個向量，分別對應該位置下一個詞的得分向量，在最終輸出時使用最后一個。

3.2?Softmax：將得分轉換為概率分布

線性層輸出的向量包含的是原始得分（raw scores），這些得分被稱為logits。每個logits數組看起來可能像這樣：[2.1, -0.3, 1.8, ..., 0.02]，其中每個數值代表對應詞匯的"傾向程度"。

然而，這些logits還不能直接用于選擇輸出詞匯，因為它們的數值范圍不確定，而且總和不為1。這時就需要Softmax函數登場：

Softmax的核心作用是將logits轉換為標準的概率分布：

將所有logits值映射到0到1之間

確保所有概率值的總和恰好等于1

保持數值間的相對大小關系（得分高的詞概率仍然高）

經過Softmax處理后，原來的logits數組變成了類似[0.15, 0.02, 0.25, ..., 0.001]的概率分布，每個數值明確表示對應詞匯被選中的概率。好的，到這里我們的大模型終于能返回一個詞了，具體輸出哪個呢，一般是根據上面的概率分布來隨機抽取，每個位置的值對應輸出詞表中這個位置的詞的概率。需要注意的是，一般情況這個概率分布會比較集中，即某個詞或某幾個詞的概率很大，其他很小。

3.3?自回歸生成：逐詞構建完整回答

經過上面那么復雜的計算，我們發現大模型只輸出了一個詞，那么完整輸出對應的后面的詞是怎么來的呢。

這里大模型生成文本的過程是自回歸的，這意味著模型不是一次性生成整個回答，而是像人類思考一樣，一個詞一個詞地逐步構建：

初始預測：基于完整的輸入上下文，模型預測第一個詞的概率分布（即上面的過程）

詞選擇：根據概率分布選擇一個詞（可能是概率最高的詞，也有可能是概率低的詞）

迭代擴展：將已生成的詞作為新的輸入的一部分，預測下一個詞

重復直到結束：持續這個過程，直到生成完整的回答或達到長度限制

這種“滾雪球”式的生成方式確保了前后文的連貫性，每個新詞的產生都基于之前所有已生成的內容。

敲黑板：大模型經過Transformer層提取的特征在經過計算后最終輸出的是詞表中每個詞的概率分布，根據相應概率抽取最終輸出的詞。接下來將生成的詞添加到輸入后繼續上述流程接著預測輸出，整體上是一個一個token輸出。這也是為什么上下文限制要包括輸出長度的原因。

3.4?生成策略：如何從概率中選擇詞匯

對于概率分布，模型有多種選擇策略，一般是按照概率分布進行抽取。在創造性的場景中可能體現為每次的輸出結果不同，這對詩詞創造等比較有用。但在一些場景中我們希望模型輸出的結果更可靠、更穩定，這里有什么方法嗎。

目前來說，模型一般會提供兩個參數來給用戶用以調整，這在我們平時使用的元寶等平臺都會開放給用戶修改。對應temperature（溫度）和top-p（又稱核采樣），它們協同工作，共同決定了模型在“想象力”與“可靠性”之間的平衡。

temperature：調整模型原始輸出的概率分布（logits）的"尖銳"或"平滑"程度，通過改變概率分布的形狀來控制隨機性。可以理解為值小于1時原本概率高的調整后會更高，進而更容易被選擇，等于0時就變成了只選擇概率最高的詞

top-p：像一個動態的候選詞篩選器，從概率最高的詞開始累加，僅從累積概率達到閾值p的最小候選集合中采樣。可以理解為在抽取時只從概率較高的前幾個詞中抽取

在實際應用中可以結合使用場景來調整參數以達到我們期望的性能，這里不做展開。

注：這里在DeepSeek V3的代碼中只看到了temperature參數的支持。

04位置編碼和長文本外推

到這里我們已經談得上大致理解了大模型從輸入到輸出的基本工作原理，不過在介紹中刻意忽略了一個細節，斟酌再三還是決定單獨介紹這部分，因為這個非常重要！

4.1 位置編碼

上面我們提到了Transformer架構核心在自注意力機制，通過計算每個token和其他token的相關性得分來獲取相關信息，其中核心計算是token之間的矩陣運算，然而這種計算方式丟失了位置信息，要知道"我咬狗"和"狗咬我"這種相同詞組成的短句含義是相差甚遠的。因此引入了位置編碼的概念，將位置信息添加在輸入矩陣中，一般分為絕對位置編碼和相對位置編碼。

絕對位置編碼：給每個位置一個"唯一身份證"，Transformer架構原版的實現。核心是通過編碼的方式將位置信息添加到每個token的輸入向量中，缺點是當輸入長度超過模型訓練長度時，模型沒見過對應位置編碼，會導致性能急劇下降。

相對位置編碼：關注的相對距離而不是絕對距離。在計算注意力分數時，注入兩個詞之間的相對距離信息。

這里只介紹目前主流方案RoPE（旋轉位置編碼），核心思想是將每個token的位置信息轉換為對應高維空間的角度信息，對應每個位置會對應一個旋轉角度，在注意力得分計算時會將兩個token對應的query和key矩陣進行對應角度的旋轉，這樣在計算注意力得分的結果會與他們的相對距離有關。具體原理這里不介紹了，不打職業不用學，需要知道的是在編碼具體實現上通過設計使得計算注意力時具備遠程衰減的特性，即距離越長，得分越低，這個特性使得模型天然能夠更關注附近的信息。

相比于絕對編碼，相對編碼中模型學到的是相對位置關系，即使輸入長度超過模型訓練長度時，模型也能復用訓練中學到的相對位置規律。

敲黑板：核心是通過巧妙的數學編碼將相對位置信息加在了自注意力得分的計算上，有個很重要的細節是，在編碼上通過設計使得相對位置越遠的token間注意力得分會相對較低。

4.2?長文本外推

但是，即使相對編碼比絕對編碼在長文本時更具優勢，但是其學到的相對位置關系的距離也是有限的，當輸入長度過長時，其性能也會下降，這時候就需要外推策略。

為了保證模型對長輸入文本也能有個較高的性能，研究人員相繼提出了多種方法。這里簡單介紹：

一種是基于插值的方式，基本思想是對于訓練時的0-4k這樣的距離，在實際使用時將0-32k壓縮到0-4k的表示（模型更熟悉這個范圍的距離）。當然這個方式不夠靈活，目前業界較優的方案是YaRN，可以理解為對不同長度的相對距離進行不同的插值策略。

一種是基于選擇策略的方式。基本思想是對超長文本，在計算時不再計算與全局所有token的注意力關系，避免超長文本計算的耗時過長。比較典型的方案是滑動窗口計算的方式，每個詞只關注固定窗口長度中相鄰詞的信息，也有通過某些策略從全局中挑選部分區間進行計算，整體方案是有損的，不過通過設計盡量降低對模型效果的影響。

4.3?長文本訓練

也許你會疑惑如果大模型學到了相對距離的概念，那理論上距離變長也應該可以的才對。這就要提到前面說的大模型的大在訓練量了，模型的性能直接取決于訓練量，在4k長度下訓練的模型即使學會了相對位置的概念，到了32k甚至更長的距離時表現也會變差，因為缺乏訓練。（這可以類比于，在人機模式打了很多把游戲，你的能力有了顯著提升，并且已經學會了技能的使用和對線的技巧，但接下來讓你跟真人高玩對線，用的技能和英雄還是那些，但就是打不過）

既然如此，為什么不直接用長文本進行訓練呢？這里主要有兩個原因：

計算復雜度與成本爆炸：基于前面的自注意力機制計算的原理，我們知道每個token都要和上下文中前面的所有token進行注意力計算，因此上下文越長，計算量和中間結果就會越多，這直接與長度的平方成正比。因此在大訓練量的需求下，直接對長文本進行訓練的資源和時間消耗都是非常大的。

訓練數據的稀缺性和質量難題：即使是互聯網時代，長文本的訓練數據仍然本身較少，大部分還是短文。并且高質量的可訓練數據更為稀缺。

短文本預訓練 + 長文本微調（主流方法）

目前主流方式都是在短文本下進行大量訓練得到基礎模型，然后通過少量的長文本數據進行微調。

階段一（基礎預訓練）：在大量高質量的較短文本（如2K、4K、8K）上完成核心的語言模型預訓練。這個階段讓模型學會基本的語言能力、常識和推理邏輯。成本相對可控。

階段二（長度擴展微調）：使用外推技術，在相對較少的長文本數據上對模型進行微調。這里DeepSeek V3是先擴展至32k，然后擴展至128k。

為什么有效？?因為模型在階段一已經學會了"如何思考"。階段二只是教它"如何在更長的上下文中運用這種思考能力"。這比從零開始學習所有東西要高效得多。

注：大模型的發展日新月異，目前有些模型已經支持了 1M 長度上下文了

敲黑板：針對長文本的支持，主流方式仍是采用大量短文本數據進行預訓練的方式，并在此基礎上通過少量長文本的訓練來提高模型對長文本輸入的支持。這里重點是什么，重點在于即使做了非常多的工作來增加長文本的支持，但是不可否認的是訓練的稀缺以及在外推方式上的有損設計，都會導致在長文本下模型的表現會劣于短文本。

05實踐與思考

到這里你已經大致了解大語言模型的工作原理和實現細節，那么知道了這些對我們實踐應用有哪些指導意義呢？

5.1?多模態輸入的實現原理

已知使用的DeepSeek V3輸入是文本，那猜測這里大概率的工程實現是對圖片做圖像識別，得到一個識別結果的文本，將這個文本和問題一起給到大模型作為輸入。不理解的是，按理來說圖像識別算法應該已經比較成熟了，準確率應該很高才對。自己測試后確實也還是不對，不過根據思考過程可以發現確實有額外的輸入文本給到大模型（大約23顆的計數）。

這里也測試了混元（已知混元是多模態的大模型，在輸入時是支持輸入圖像的，簡單理解應該是通過編碼器將圖片轉換成跟token類似的輸入向量給到Transformer架構），結果也是不對，而且看思考過程很難看出來是真的用了圖片特征token還是單純的在瞎說。已知大模型輸出是一個一個通過概率輸出的，因此在系統提示詞沒有嚴格限制的情況很容易出現編瞎話的問題。

這里想說的是，像DeepSeek這類大語言模型目前主要還是以輸入文本為主，對于非文本的需求大概率是通過特殊的工程方案來實現的。

5.2?通過上下文限制提高系統穩定性

我們知道模型在短文本（一般是4k）進行了大量訓練，理論上這個區間模型效果和穩定性都是最高的，那么在工程實踐中應盡量避免長上下文的情況。以Agent為例，關鍵就是他的prompt（系統提示詞）和可用工具列表描述，這部分不應過多（提示詞一般對應規則，工具描述對應能力）。

并且過多的規則和可用工具容易導致模型出現混亂，最終輸出的格式不符合預期，如下示例實際模型是想輸出的調用工具的能力，但是由于輸出時格式不對，導致解析失敗。

這只是不穩定的變現的一種，有時還會出現循環輸出的情況如下圖，看完文章你應該能理解這種問題出現的原因(輸出是概率預測）

5.3?耗時影響

每次調用的耗時由什么決定呢，以上理解我們知道第一個token的輸出需要將所有輸入上下文全部計算后得到，這個耗時完全取決于上下文長度，越長則耗時越高（并且是與長度的平方成正相關），隨后依次輸出，每個token輸出的間隔耗時取決于上下文長度（這里會利用之前計算過的緩存，但仍需要將新的token與上下文所有token進行計算），所有token輸出總耗時取決于輸出的字數。因此一次調用耗時的曲線近似可以理解為如下圖所示，其中t1與上下文長度平方成正比，直線斜率k與上下文長度成正比。

知道了耗時組成，那么在實踐中如果想每次調用耗時降低，我們能做什么呢？

還是減少上下文長度，因為總耗時與長度平方成正比

限制模型單詞輸出的長度，這里一般可以通過prompt規則或者接口參數限制，因為很多時候大模型會有啰里啰嗦的特性！

5.4?如何有效減少上下文

實踐中我們會發現很多時候模型不總會按預期輸出，因此我們會增加很多的規則來提醒模型怎么做，當我們就是有這么多要求怎么辦呢，也許你需要拆分了。

通過多Agent協同的方式將你期望的功能進行拆分，每個子Agent對應一部分能力，通過一個主Agent進行統籌規劃。

這里主Agent只需要知道每個子Agent能做什么，而不需要知道其對應prompt的具體規則，因此其上下文可以做到盡量的縮小，耗時也會有效降低。在使用時主Agent只需要將用戶提問拆分為不同子任務交由子Agent執行即可。同時每個子Agent的功能相對簡單，因此上下文也不會太長。

這種方案會相對增加調用大模型的次數，但是通過減少上下文又降低了每次調用上下文的長度，在調用耗時與上下文平方成正比的情況下，整體耗時反而會縮短。比如原12k的上下文，現在變成了4個3k上下文的子Agent，簡單計算下：122 = 144，四個子Agent對應 4 × 32 = 36。

5.5?歷史對話

歷史對話過多也會導致上下文的膨脹，不過很多時候用戶的問題并不需要歷史信息做參考，或者歷史信息里包含的有用信息很少，用戶很多時候單純是懶得清理上下文。

因此工程上可以通過一些方式減少歷史對話，一種可行的方案可能是，將歷史對話存儲起來，在用戶提問時，先檢索有沒有相關記錄，并僅將相關記錄附在歷史對話里。

06寫在最后

以上全文基于個人理解，歡迎批評指正。

Vaswani, A., et al. The Annotated Transformer. Harvard NLP. https://nlp.seas.harvard.edu/2018/04/03/attention.html

-End-原創作者｜顏培榮