快速理解熱門 LLM 大語言模型
作者 | masonpy
本文盡量用最簡單的方式, 幫讀者理解 LLM，Transformer, Prompt, Function calling, MCP, Agent, A2A 等這些基本概念。 表述時不追求絕對準確，盡量通俗易懂，部分內容有個人理解的成份，內容難免疏漏, 歡迎指正。
注意：本文需要你有基本的代碼閱讀能力，當然非開發閱讀也不會很困難。
一、LLM (大語言模型)
本質就是文字接龍
把問題當成輸入, 把大模型當成函數, 把回答當成輸出。
大模型回答問題的過程, 就是一個循環執行函數的過程。
另外有必要了解一下, AI技術爆發于2023年, ChatGPT經過了幾次迭代才嶄露頭角。
- Transformer架構
- 參數爆發增長
- 人工干預獎勵模型
思考題: 語言能代表智能嗎?
二、Transformer (自注意力機制)
自注意力機制就是動態關聯上下文的能力. 如何實現的呢?
(1) 每個分詞就是一個 token
(2) 每個token 都有一個 Q, K, V 向量 (參數)
- Q 是查詢向量
- K 是線索向量
- V 是答案向量
(3) 推理的過程:
- 當前token 的Q 與 前面所有的 K 計算權重
- 每個 token 的V加權相加得到一個 token預測值
- 選擇 N 個與預測值最接近的 token, 擲骰子選擇
最簡化示例：小明吃完冰淇淋，結果 => 肚子疼
首先分詞及每個token的 Q, K, V向量：
token | Q（查詢） | K（鍵） | V（值） | 語義解釋 |
小明 | [0.2, 0.3] | [0.5, -0.1] | [0.1, 0.4] | 人物主體 |
吃完 | [-0.4, 0.6] | [0.3, 0.8] | [-0.2, 0.5] | 動作（吃完） |
冰淇淋 | [0.7, -0.5] | [-0.6, 0.9] | [0.9, -0.3] | 食物（冷飲，可能致腹瀉） |
結果 | [0.8, 0.2] | [0.2, -0.7] | [0.4, 0.1] | 結果（需關聯原因） |
接著開始推理：
1. 使用最后一個 token 的 Q（“結果”的 Q 向量）
Q_current = [0.8, 0.2]
2. 計算 Q_current 與所有 K 的點積（相似度）
點積公式：Q·K = q?*k? + q?*k?
Token | K向量 | 點積計算 | 結果 |
小明 | [0.5, -0.1] | 0.8 * 0.5 + 0.2*(-0.1) = 0.4 - 0.02 | 0.38 |
吃完 | [0.3, 0.8] | 0.8 * 0.3 + 0.2 * 0.8 = 0.24 + 0.16 | 0.40 |
冰淇淋 | [-0.6, 0.9] | 0.8*(-0.6) + 0.2 * 0.9 = -0.48 + 0.18 | -0.30 |
結果 | [0.2, -0.7] | 0.8 * 0.2 + 0.2*(-0.7) = 0.16 - 0.14 | 0.02 |
3. Softmax 歸一化得到注意力權重
將點積結果輸入 Softmax 函數
Token | 點積 | 指數值（e^x） | 權重 |
小明 | 0.38 | e^0.38 ≈ 1.46 | 1.46 / 2.74 ≈ 0.53 |
吃完 | 0.4 | e^0.40 ≈ 1.49 | 1.49 / 2.74 ≈ 0.54 |
冰淇淋 | -0.3 | e^-0.30 ≈ 0.74 | 0.74 / 2.74 ≈ 0.27 |
結果 | 0.02 | e^0.02 ≈ 1.02 | 1.02 / 2.74 ≈ 0.37 |
4. 加權求和 V 向量生成上下文向量
將權重與對應 V 向量相乘后相加：
Token | 權重 | V向量 | 加權 V 向量 |
小明 | 0.53 | [0.1, 0.4] | 0.53*[0.1, 0.4] ≈ [0.053, 0.212] |
吃完 | 0.54 | [-0.2, 0.5] | 0.54*[-0.2, 0.5] ≈ [-0.108, 0.27] |
冰淇淋 | 0.27 | [0.9, -0.3] | 0.27*[0.9, -0.3] ≈ [0.243, -0.081] |
結果 | 0.37 | [0.4, 0.1] | 0.37*[0.4, 0.1] ≈ [0.148, 0.037] |
最終上下文向量：
[0.053?0.108+0.243+0.148,0.212+0.27?0.081+0.037]=[0.336,0.438]
5. 預測下一個 token
模型將上下文向量 [0.336, 0.438] 與候選 token 的嵌入向量對比：
嵌入向量不作過多解釋, 只要知道QKV三個向量可從嵌入向量計算得到即可
候選詞 | 嵌入向量 | 相似度（點積） | 概率 |
肚子疼 | [0.3, 0.5] | 0.336 * 0.3 + 0.438 * 0.5 ≈ 0.101 + 0.219 = 0.320 | 最大概率（例如 65%） |
頭疼 | [0.2, 0.1] | 0.336 * 0.2 + 0.438 * 0.1 ≈ 0.067 + 0.044 = 0.111 | 次之（例如 20%） |
開心 | [-0.5, 0.8] | 0.336*(-0.5) + 0.438 * 0.8 ≈ -0.168 + 0.350 = 0.182 | 較低（例如 15%） |
最終模型選擇最高概率的 “肚子疼” 作為下一個 token。
注意在實際場景中, 預測的下一個token是不確定的, 是因為有一個擲骰子的操作, 大模型會在概率最大的幾個token中隨機挑選一個作為最終輸出。
三、Prompt (提示詞)
對于這個詞大家并不陌生. 我們用chatGPT時經常會用到, "你是一個......."
但你真的理解它嗎?
與ai對話時的這種預設角色, 其實并不是嚴格意義上的 prompt
為什么這么說呢? 先看一下API
四、理解API
我們前面提到過大語言模型的 本質就是文字接龍 , 相對應的使用大模型也比較簡單. 可以參見deepseek的文字接龍 api 請求:
https://api-docs.deepseek.com/zh-cn/api/create-chat-completion
這里比較重要的幾個部分, 需要理解：
1. temperature 溫度
Temperature（溫度） 是一個控制生成文本隨機性和多樣性的關鍵參數。它通過調整模型輸出的概率分布，直接影響生成內容的“保守”或“冒險”程度. 看幾個典型場景:
場景 | 溫度 |
代碼生成/數學解題 | 0 |
數據抽取/分析 | 1 |
通用對話 | 1.3 |
翻譯 | 1.3 |
創意類寫作/詩歌創作 | 1.5 |
2. tools 工具支持
大模型對 function calling 的支持, 后面再詳細介紹。
3. 角色和信息
這一部分是ai對話的主體. 其中role 定義了四個角色：
- system 系統設定
- user 用戶回復
- assistant 模型回答
- tool 是配合function call工作的角色, 可以調用外部工具
回到前一章的問題, ai對話時其實是user部分輸入的內容, 所以system角色的設定內容才應該是嚴格意義上的Prompt。
這有啥區別呢? (user 與 system?)
個人一個合理的猜測: system的內容在Transformer推理中擁有較高的權重，所以擁有較高的響應優先級。
4. 關于多輪對話
因為LLM是無狀態的. 我們要時刻記得文字接龍的游戲, 因此在實際操作中也是這樣的：
(1) 在第一輪請求時，傳遞給 API 的 messages 為
(2) 大模型回答
(3) 當用戶發起第二輪問題時, 請求變成了這樣
五、Function Calling (函數調用)
僅僅一個可以回答問題的機器人, 作用并不太大。
要完成復雜的任務, 就需要大模型的輸出是穩定的, 而且是可編程的。
因此OpenAI 推出了 function calling的支持. 也就是前面提到的 tools參數相關內容。
1. 基本流程
(1) 工具聲明及用戶輸入
(2) 模型檢測到需要使用工具, 返回相關工具參數
(3) 開發者根據方法名和參數, 調用相關工具方法
(4) 將工具方法的返回值, 附加到請求中, 再次請求大模型
(5) 得出最終結果
"The current temperature in Paris is 14°C (57.2°F)."(6) 總結一下
2. 實現原理(猜測)
(1) 實現方式一: prompt 遵循 (示例)
提前設置規則:
(2) 實現方式二: 模型訓練特定優化
對結構化輸出有特定要求, 可能需要特定訓練吧. 這個不太確定?
六、Agent (智能體)
包含: 大模型, 任務規劃, 上下文記憶, 工具調用. 它是大模型能力的拓展. 其實只要對API進行簡單的封裝, 只要能完成特定任務, 都可以稱為智能體. 比如下面的例子:
1. 創建AI客服系統
這個智能體, 主要包括:
- 配置了一個 prompt: "你是一個電商客服, 可查詢訂單狀態"
- 引入 query_order 工具
2. 其它創建方式
服務商開放接口, 供用戶創建, 比如騰訊元器：https://yuanqi.tencent.com/my-creation/agent
一個簡單的提示詞都可以創建智能體：
七、MCP (模型上下文協議)
通過上面的智能體調用工具的示例我們可以看到, 每接入一個工具, 都需要編寫相應的接入代碼. 經常寫代碼的我們都知道, 這不是好的架構設計. 好的設計應該把動態改變的部分 ( tools的聲名和調用分離出來 ), 做為一個獨立的模塊來拓展. 這就有了大眾追捧的 MCP: -----(哪有這么玄, 都是程序員的常規操作啊....)
MCP是工具接入的標準化協議：https://modelcontextprotocol.io/introduction
遵循這套協議, 可以實現工具與Agent的解耦. 你的Agent 接入MCP協議的client sdk后. 接入工具不再需要編寫工具調用代碼, 只需要注冊 MCP Server就可以了. 而MCP Server可由各個服務商獨立提供.
MCP Server做什么呢?
- 聲明提供的能力 ListTools
- 調用能力的方式 CallTool
來看一下MCP Server的部分代碼 (紅框中就是做上面兩個事, 不難理解) :
八、A2A (Agent通信協議)
A2A本質是對 MCP協議的拓展, 按字面意思就是 Agent to Agent. 有興趣的自己詳細看吧。
智能體與智能體之間通信的標準化協議：https://github.com/google/A2A?tab=readme-ov-file#agent2agent-a2a-protocol
在這套協議下, 一個智能體要引入其它的智能體的能力, 也變得可插拔了。
九、未來假想
如同蒸汽機, 電, 計算機這些偉大的技術一樣. AI會成為下一個徹底改變人類生活工作方式的新技術.
1. 現在AI編程能力越來越強, 程序員是不是要失業了?
職業不會消失, 消失的只有人. 但是AI編程的確會重塑整個行業。
我預想幾年后, 純粹的業務代碼工程師可能會消失. 而會增加更多的AI編程工程師。
AI編程工程師的職責是解決AI模糊性的問題. 而工具的引入就是增加確定性的手段。
我們程序員可以把自己的積累通過 mcp server的方式, 掛載到項目agent 上去. 這樣我們就可以解放雙手, 去解決更多有挑戰性的問題。
2. 當前我們有哪些工作可以由AI來處理?
理論上一切重復性的工作都可以交由AI完成. 保險起見, 創造性的工作暫時可以只作為參考：
- 日常的反饋分析.
- 團隊知識庫
- 個人知識庫
