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