簡(jiǎn)介

本文整理了來(lái)自Daily Dose of Data Science最熱門或最新的文章，其中極具特色的動(dòng)圖以生動(dòng)形象的方式，幫助我們更好的理解AI中的一些核心技術(shù)，希望能夠幫助大家更好的理解和使用AI。

大模型

Transformer vs. Mixture of Experts

混合專家 (MoE) 是一種流行的架構(gòu)，它使用不同的“專家”來(lái)改進(jìn) Transformer 模型。
下圖解釋了它們與 Transformers 的區(qū)別。

Transformer 使用前饋網(wǎng)絡(luò)。

MoE 使用專家，它們是前饋網(wǎng)絡(luò)，但與 Transformer 中的網(wǎng)絡(luò)相比規(guī)模較小。在推理過(guò)程中，會(huì)選擇一部分專家。這使得 MoE 中的推理速度更快。

Fine-tuning LLMs

傳統(tǒng)的微調(diào)（如下圖所示）對(duì)于 LLM 來(lái)說(shuō)是不可行的，因?yàn)檫@些模型具有數(shù)十億個(gè)參數(shù)并且大小為數(shù)百 GB，并且并非每個(gè)人都可以使用這樣的計(jì)算基礎(chǔ)設(shè)施。

值得慶幸的是，今天我們有許多最佳方法來(lái)微調(diào) LLM，下面描述了五種流行的技術(shù)：

LoRA ：添加兩個(gè)低秩矩陣 A ，以及 B包含可訓(xùn)練參數(shù)的權(quán)重矩陣。無(wú)需進(jìn)行微調(diào)W，只需調(diào)整這些低秩矩陣中的更新即可。

LoRA-FA ：雖然 LoRA 顯著減少了可訓(xùn)練參數(shù)的總量，但它仍然需要大量的激活記憶來(lái)更新低秩權(quán)重。LoRA-FA（FA 代表 Frozen-A）會(huì)凍結(jié)矩陣，A并且僅更新矩陣B。

VeRA ：在 LoRA 中，每一層都有一對(duì)不同的低秩矩陣A和B，并且這兩個(gè)矩陣都經(jīng)過(guò)訓(xùn)練。然而，在 VeRA 中，矩陣A和B是凍結(jié)的、隨機(jī)的，并在所有模型層之間共享。VeRA 專注于學(xué)習(xí)較小的、特定于層的縮放向量，記為b和d，它們是此設(shè)置中唯一可訓(xùn)練的參數(shù)。

Delta-LoRA ：除了訓(xùn)練低秩矩陣之外，W還會(huì)對(duì)矩陣進(jìn)行調(diào)整，但不是以傳統(tǒng)方式。相反，將兩個(gè)連續(xù)訓(xùn)練步驟中低秩矩陣乘積與之間的差值（或增量）A添加B到W。

LoRA+ ：在 LoRA 中，矩陣A和B都以相同的學(xué)習(xí)率更新。作者發(fā)現(xiàn)，為矩陣設(shè)置更高的學(xué)習(xí)率B可以獲得更優(yōu)的收斂效果。

RAG（檢索增強(qiáng)生成）

傳統(tǒng)RAG

傳統(tǒng)RAG系統(tǒng)存在以下一些問(wèn)題：

這些系統(tǒng)檢索一次，生成一次。這意味著如果檢索到的上下文不夠，LLM就無(wú)法動(dòng)態(tài)搜索更多信息。

RAG 系統(tǒng)可以提供相關(guān)的上下文，但無(wú)法通過(guò)復(fù)雜的查詢進(jìn)行推理。如果查詢需要多個(gè)檢索步驟，傳統(tǒng)的 RAG 就顯得力不從心了。

適應(yīng)性較差。LLM 無(wú)法根據(jù)實(shí)際問(wèn)題調(diào)整策略。

Agentic RAG

Agentic RAG 的工作流程如下：

如上所示，我們的想法是在 RAG 的每個(gè)階段引入代理行為。

我們可以把智能體想象成能夠主動(dòng)思考任務(wù)的人——規(guī)劃、調(diào)整、迭代，直到找到最佳解決方案，而不僅僅是遵循既定的指令。LLM 的強(qiáng)大功能使這一切成為可能。

讓我們逐步理解這一點(diǎn)：

步驟 1-2）用戶輸入查詢，代理重寫它（刪除拼寫錯(cuò)誤，簡(jiǎn)化嵌入等）

步驟 3）另一個(gè)代理決定是否需要更多細(xì)節(jié)來(lái)回答查詢。

步驟4）如果不是，則將重寫的查詢作為提示發(fā)送給LLM。

步驟 5-8) 如果答案是肯定的，另一個(gè)代理會(huì)查看其可以訪問(wèn)的相關(guān)資源（矢量數(shù)據(jù)庫(kù)、工具和 API 以及互聯(lián)網(wǎng)），并決定哪個(gè)資源有用。檢索相關(guān)上下文并將其作為提示發(fā)送給 LLM。

步驟9）以上兩條路徑中的任意一條都會(huì)產(chǎn)生響應(yīng)。

步驟 10）最后一個(gè)代理檢查答案是否與查詢和上下文相關(guān)。

步驟11）如果是，則返回響應(yīng)。

步驟 12）如果不是，則返回步驟 1。此過(guò)程持續(xù)幾次迭代，直到系統(tǒng)承認(rèn)它無(wú)法回答查詢。

這使得 RAG 更加穩(wěn)健，因?yàn)樵诿恳徊街?，代理行為都能確保個(gè)體結(jié)果與最終目標(biāo)保持一致。

Corrective RAG

Corrective RAG（CRAG）是改進(jìn) RAG 系統(tǒng)的常用技術(shù)。它引入了對(duì)檢索到的文檔進(jìn)行自我評(píng)估的步驟，有助于保留生成的響應(yīng)的相關(guān)性。
以下是其工作原理的概述：

首先根據(jù)用戶查詢搜索文檔。

使用 LLM 評(píng)估檢索到的上下文是否相關(guān)。

僅保留相關(guān)上下文。

如果需要的話，進(jìn)行網(wǎng)絡(luò)搜索。

聚合上下文并生成響應(yīng)。

RAG 的 5 種分塊策略

智能體

5種智能體設(shè)計(jì)模式

Agentic behaviors允許 LLM 通過(guò)結(jié)合自我評(píng)估、規(guī)劃和協(xié)作來(lái)改進(jìn)他們的輸出！
下圖展示了構(gòu)建 AI 代理時(shí)采用的 5 種最流行的設(shè)計(jì)模式。

反射模式

LLM會(huì)審查其工作以發(fā)現(xiàn)錯(cuò)誤并不斷迭代直到產(chǎn)生最終的響應(yīng)。

工具使用模式

工具允許 LLM 通過(guò)以下方式收集更多信息：

查詢矢量數(shù)據(jù)庫(kù)

執(zhí)行 Python 腳本

調(diào)用API等

這很有幫助，因?yàn)?LLM 不僅僅依賴于其內(nèi)部知識(shí)。

ReAct（Reason and Action）模式

ReAct 結(jié)合了以上兩種模式：

代理可以反映生成的輸出。

它可以使用工具與世界互動(dòng)。

這使得它成為當(dāng)今使用最強(qiáng)大的模式之一。

規(guī)劃模式

AI 不會(huì)一次性解決請(qǐng)求，而是通過(guò)以下方式創(chuàng)建路線圖：

細(xì)分任務(wù)

概述目標(biāo)

這種戰(zhàn)略思維可以更有效地解決任務(wù)。

Multi-agent模式

在此設(shè)置中：

我們有幾個(gè)agent。

每個(gè)agent都被分配了專門的角色和任務(wù)。

每個(gè)agent還可以訪問(wèn)工具。

所有agent共同努力以交付最終結(jié)果，同時(shí)在需要時(shí)將任務(wù)委派給其他agent。

智能體系統(tǒng)的5個(gè)等級(jí)

Agentic AI 系統(tǒng)不僅僅生成文本；它們還可以做出決策、調(diào)用函數(shù)，甚至運(yùn)行自主工作流程。
該圖解釋了人工智能代理的 5 個(gè)級(jí)別——從簡(jiǎn)單的響應(yīng)者到完全自主的代理。

基本響應(yīng)器僅生成文本

路由器模式?jīng)Q定何時(shí)采取路徑

工具調(diào)用選擇并運(yùn)行工具

多代理模式管理多個(gè)代理

自主模式完全獨(dú)立運(yùn)作

MCP

Function calling & MCP

在 MCP 成為主流（或像現(xiàn)在這樣流行）之前，大多數(shù) AI 工作流程依賴于傳統(tǒng)的函數(shù)調(diào)用。
現(xiàn)在，MCP（模型上下文協(xié)議）正在改變開發(fā)人員為代理構(gòu)建工具訪問(wèn)和編排的方式。
以下是解釋函數(shù)調(diào)用和 MCP 的視覺(jué)說(shuō)明：

Function calling（函數(shù)調(diào)用）

函數(shù)調(diào)用是一種機(jī)制，它允許 LLM 根據(jù)用戶的輸入識(shí)別它需要什么工具以及何時(shí)調(diào)用它。
它通常的工作方式如下：

LLM 收到來(lái)自用戶的提示。

LLM 決定其所需的工具。

程序員實(shí)現(xiàn)程序來(lái)接受來(lái)自 LLM 的工具調(diào)用請(qǐng)求并準(zhǔn)備函數(shù)調(diào)用。

函數(shù)調(diào)用（帶有參數(shù)）被傳遞給處理實(shí)際執(zhí)行的后端服務(wù)。

MCP（模型上下文協(xié)議）

函數(shù)調(diào)用關(guān)注的是模型想要做什么，而 MCP 關(guān)注的是如何讓工具變得可發(fā)現(xiàn)和可用——尤其是跨多個(gè)代理、模型或平臺(tái)。
MCP 無(wú)需在每個(gè)應(yīng)用程序或代理中都安裝硬接線工具，而是：

標(biāo)準(zhǔn)化工具的定義、托管和向 LLM 公開的方式。

使 LLM 能夠輕松發(fā)現(xiàn)可用的工具、了解其模式并使用它們。

在調(diào)用工具之前提供批準(zhǔn)和審計(jì)工作流程。

將工具實(shí)施與消費(fèi)的關(guān)注點(diǎn)分開。

MCP & A2A

Agent2Agent (A2A) 協(xié)議讓 AI 代理可以連接到其他代理。

MCP 為代理提供訪問(wèn)工具的權(quán)限。

而 A2A 允許代理與其他代理連接并以團(tuán)隊(duì)形式協(xié)作。

Next thing

在代理領(lǐng)域：

MCP 標(biāo)準(zhǔn)化了代理到工具的通信。

Agent2Agent 協(xié)議標(biāo)準(zhǔn)化了 Agent 到 Agent 的通信。

但還缺少一件東西……

AG-UI（代理-用戶交互協(xié)議）標(biāo)準(zhǔn)化了后端代理和前端 UI 之間的交互層（下圖綠色層）。

審核編輯 黃宇