簡介

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

大模型

Transformer vs. Mixture of Experts

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

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

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

Fine-tuning LLMs

傳統(tǒng)的微調（如下圖所示）對于 LLM 來說是不可行的，因為這些模型具有數(shù)十億個參數(shù)并且大小為數(shù)百 GB，并且并非每個人都可以使用這樣的計算基礎設施。

值得慶幸的是，今天我們有許多最佳方法來微調 LLM，下面描述了五種流行的技術：

LoRA ：添加兩個低秩矩陣 A ，以及 B包含可訓練參數(shù)的權重矩陣。無需進行微調W，只需調整這些低秩矩陣中的更新即可。

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

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

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

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

RAG（檢索增強生成）

傳統(tǒng)RAG

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

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

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

適應性較差。LLM 無法根據(jù)實際問題調整策略。

Agentic RAG

Agentic RAG 的工作流程如下：

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

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

讓我們逐步理解這一點：

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

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

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

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

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

步驟 10）最后一個代理檢查答案是否與查詢和上下文相關。

步驟11）如果是，則返回響應。

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

這使得 RAG 更加穩(wěn)健，因為在每一步中，代理行為都能確保個體結果與最終目標保持一致。

Corrective RAG

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

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

使用 LLM 評估檢索到的上下文是否相關。

僅保留相關上下文。

如果需要的話，進行網(wǎng)絡搜索。

聚合上下文并生成響應。

RAG 的 5 種分塊策略

智能體

5種智能體設計模式

Agentic behaviors允許 LLM 通過結合自我評估、規(guī)劃和協(xié)作來改進他們的輸出！
下圖展示了構建 AI 代理時采用的 5 種最流行的設計模式。

反射模式

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

工具使用模式

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

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

執(zhí)行 Python 腳本

調用API等

這很有幫助，因為 LLM 不僅僅依賴于其內部知識。

ReAct（Reason and Action）模式

ReAct 結合了以上兩種模式：

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

它可以使用工具與世界互動。

這使得它成為當今使用最強大的模式之一。

規(guī)劃模式

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

細分任務

概述目標

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

Multi-agent模式

在此設置中：

我們有幾個agent。

每個agent都被分配了專門的角色和任務。

每個agent還可以訪問工具。

所有agent共同努力以交付最終結果，同時在需要時將任務委派給其他agent。

智能體系統(tǒng)的5個等級

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

基本響應器僅生成文本

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

工具調用選擇并運行工具

多代理模式管理多個代理

自主模式完全獨立運作

MCP

Function calling & MCP

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

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

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

LLM 收到來自用戶的提示。

LLM 決定其所需的工具。

程序員實現(xiàn)程序來接受來自 LLM 的工具調用請求并準備函數(shù)調用。

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

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

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

標準化工具的定義、托管和向 LLM 公開的方式。

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

在調用工具之前提供批準和審計工作流程。

將工具實施與消費的關注點分開。

MCP & A2A

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

MCP 為代理提供訪問工具的權限。

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

Next thing

在代理領域：

MCP 標準化了代理到工具的通信。

Agent2Agent 協(xié)議標準化了 Agent 到 Agent 的通信。

但還缺少一件東西……

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

審核編輯 黃宇