面試新收獲-大模型學習

大模型原理

Transformer 架構與自注意力機制

????????Transformer 是當前大多數大模型采用的核心架構，由編碼器-解碼器組成，摒棄了傳統 RNN 的順序處理方式。Transformer 中關鍵在于多頭自注意力機制（Multi-Head Self-Attention）：對于序列中的每個詞（Token），模型通過計算與其他詞的相關性（注意力權重）來動態聚合信息，從而能夠在一次計算中關注輸入序列的不同位置。多頭注意力通過并行多個注意力“頭”來捕獲不同特征子空間的關聯，大幅提升了模型對長距離依賴的處理能力和并行計算效率。相比 RNN 循環網絡只能順序處理，Transformer 的自注意力機制使其能一次性處理整個序列，從而利用 GPU 并行加速訓練，并取得更好的全局語義建模效果。

預訓練-微調范式

????????大模型通常采用“預訓練 + 微調”的范式。首先在海量通用文本數據上進行無監督預訓練，學習通用語言表示能力；然后針對具體任務進行微調，讓模型適應特定應用場景。預訓練使用的目標通常是語言模型任務（如下一詞預測或填空），讓模型掌握語法、語義常識。而微調階段則在較小的標注數據上訓練，可以是分類、問答等任務的監督信號，使模型的輸出更貼近任務需求。通過預訓練獲取通用知識，再微調專業能力，可以極大提高數據利用效率，避免每個任務都從零訓練一個模型。這一范式已被證明在NLP各任務上效果顯著，也是 GPT 系列、BERT 等模型成功的基礎。現代 LLM 如 GPT-3 預訓練參數上千億（如1750億），而微調只需針對任務的較少數據，調節少量梯度，從而實現**“一次訓練，多次適用”**的高效開發模式。

指令微調（Instruction Tuning）

????????指令微調是一種特殊的監督微調技術，旨在讓大語言模型更好地“聽懂”人類指令。具體做法是收集一系列指令-響應示例（通常由人工編寫或模型生成后人工篩選），然后在預訓練模型上繼續以這些數據進行監督訓練。經過指令微調，模型能夠更遵循用戶意圖，給出更符合指令要求的回答。例如，OpenAI 的 InstructGPT 就是對 GPT-3 進行指令微調的產物，使之相比原始 GPT-3 更善于遵循人類給出的任務說明。類似地，Meta 發布的 LLaMA-2-chat 也是在基礎模型上指令調優而成。指令微調通常被視為對齊（Alignment）過程的第一步，可極大提升模型在人機交互中的實用性——模型不再僅完成句子續寫，而是能夠聽懂諸如“請總結上述文本”等明確指示并執行。

人類反饋強化學習（RLHF）

RLHF（Reinforcement Learning from Human Feedback，人類反饋強化學習）是進一步提升模型對人類偏好契合度的策略。其典型流程包括三步：

監督微調（SFT）：先用人工示范的高質量回答對預訓練模型進行一次微調，獲得初步具備指令遵循能力的模型（如 InstructGPT 的初始模型）。
訓練獎勵模型（Reward Model）：由人工對模型不同輸出進行偏好比較，收集大量偏好數據，然后訓練一個獎勵模型來預測人類偏好評分。獎勵模型以模型輸出為輸入，輸出一個分數來衡量該回答有多符合人類期望。
策略強化優化：將步驟2得到的獎勵模型作為“環境反饋”，使用強化學習算法（通常采用 PPO，Proximal Policy Optimization）來微調模型參數。策略梯度根據獎勵模型給出的“獎勵”信號調整語言模型，使其朝著人類偏好更高的方向優化。為了防止生成分布驟變，PPO 會限制每次更新的幅度，保證生成質量穩定。

通過RLHF，模型可以學會在遵循指令的同時，產出更讓用戶滿意的回答。OpenAI 的 ChatGPT（GPT-3.5 系列）以及 GPT-4 就應用了RLHF來訓練。值得注意的是，RLHF 的過程復雜、成本高昂，需要大量人工反饋數據和迭代訓練。但其效果顯著：可以糾正模型不良傾向，提升回答的有用性和安全性，使模型“更貼近人意”。

大模型開發與應用

模型微調方法：全量微調 vs LoRA/QLoRA

????????全量微調（Full Finetuning）需要在下游任務上調整模型的所有參數，但對于數十億參數的模型來說訓練開銷巨大且容易過擬合。為提高微調效率，業界提出了參數高效微調方法，其中最常用的是 LoRA（Low-Rank Adaptation）。LoRA 的做法是凍結預訓練模型的大部分權重，僅在每層加入小規模的低秩矩陣作為可訓練參數。訓練時只更新這些低秩適配矩陣，從而以極少的參數調節實現對模型的調優。據實驗，使用 LoRA 對 GPT-3 進行微調時，需訓練的參數量可從1750億降低到約1800萬，大幅降低約 2/3 的顯存占用。LoRA 微調后的模型在特定任務上的表現可媲美全量微調。

????????QLoRA 是 LoRA 的改進變種，全稱為量化 LoRA（Quantized LoRA）。它將基礎模型權重先量化到更低精度（如 4-bit）以減少內存占用，然后在此基礎上施加 LoRA 微調。通過低精度存儲+高精度計算，QLoRA 進一步降低了微調資源需求。例如，有研究使用 QLoRA 在單張 GPU 上成功微調了 65B 參數的模型，但性能幾乎沒有損失。總的來說，LoRA/QLoRA 等高效微調方法讓普通團隊也能在消費級 GPU 上微調大模型，大大降低了應用門檻。

推理加速（ONNX、TensorRT 等）

大模型落地應用時，推理速度和延遲往往是關鍵挑戰。針對推理階段的優化，常用手段包括：

模型格式優化：將模型轉換為優化的計算圖格式，如 ONNX (Open Neural Network Exchange)。通過 ONNX，可以利用高效的推理引擎（例如 onnxruntime）在不同硬件上加速執行。此外，NVIDIA 的 TensorRT 是針對 GPU 推理優化的庫，可以對模型進行算子融合、內存優化和半精度運算，加速Transformer推理。將模型導出為 TensorRT 引擎后，在支持硬件上常獲得數倍于原生 PyTorch 的推理速度提升。
算子級優化：利用高性能計算庫或自定義內核，實現 Transformer 中矩陣乘、softmax 等核心算子的優化版本。例如 FlashAttention 優化了長序列注意力計算，大幅減少顯存訪問；又如采用 fused kernel 一次完成多步運算，減少中間內存讀寫。硬件方面，充分利用 GPU 的 Tensor Core 進行 FP16/BF16 運算，也能提升吞吐。
批處理和并行：將多個輸入打包成批一起推理，以攤薄每次調用開銷。同時，如果有多張 GPU，可按需進行數據并行或流水線并行處理不同請求。此外對于 sequence sampling 這類生成過程，采用并行解碼策略也能一定程度提高效率。
高效推理服務：使用專門針對大模型優化的推理服務器。例如 Hugging Face 提供的 Text Generation Inference (TGI) 框架，它集成了高效批處理和緩存策略，可用于生產環境的高吞吐部署。又如 vLLM 等方案專門為加速大模型生成而設計（后文詳述）。

綜合運用以上手段，可將大模型的推理延遲和成本顯著降低，使其更適合實際業務部署。

分布式推理與 INT8 量化

當模型體積超出單機顯存時，就需要分布式推理技術。典型方案是 模型并行 或 ZeRO 分片：將模型權重拆分到多塊 GPU 顯存上，每塊負責一部分計算。以 Microsoft 的 DeepSpeed 框架為例，其 ZeRO-Inference 技術能將模型各層權重在多卡間分塊存儲，并在推理時按需交換，從而支持百億甚至千億參數模型的部署。雖然分布式推理會帶來一些通信開銷，但通過流水線并行、異步預取等優化，可以讓多 GPU 協同工作，達到近似單模型的性能。

另一方面，量化技術通過降低參數數值精度來縮減模型體積、加速運算。常用的是 INT8量化，即將權重從32位浮點縮減為8位整數存儲。Intel、NVIDIA 等都提供了高效的 INT8 矩陣乘單元，使得量化后推理速度提升顯著，且內存占用減少 3/4。為了盡量避免精度損失，業界采用“近似無損”的量化方案。例如 LLM.int8() 使用逐列量化并對離群值單獨16位存儲的方法，使模型幾乎不損失性能。實踐表明，對 Transformer 模型進行 INT8 量化后，其在語言理解任務上的困惑度(perplexity)幾乎不變。此外還有更激進的 4-bit 量化，也通過優化策略將性能損失降到可接受范圍。總之，量化是大模型落地的利器，使原本需要多卡部署的模型能夠在單卡甚至CPU上運行，為邊緣設備部署大模型提供了可能。

模型壓縮與蒸餾

為了進一步減小模型尺寸、提升推理速度，可以對大模型進行模型壓縮。常見壓縮技術包括：

知識蒸餾：利用大模型作為教師，訓練一個參數量更小的學生模型，讓學生模型去模仿教師模型對樣本的輸出分布。通過蒸餾，小模型能吸收大模型的知識，在較低復雜度下達到接近的性能。例如，用一個175B參數的模型指導一個7B模型回答問題，可使小模型性能顯著提升接近大模型水平。
網絡剪枝：分析模型中哪些權重對最終預測影響不大，將其系數置零（權重剪枝）或者移除相應的神經元/通道（結構剪枝）。剪枝后可減少模型計算量和存儲，但需要在剪枝后對模型進行一定程度微調來恢復性能。
矩陣因子分解：將模型中的大矩陣（如權重矩陣）近似分解為兩個更小的矩陣相乘，以降低參數數量。這實際上和 LoRA 的思想類似，只不過 LoRA是在保留原權重基礎上附加小矩陣，這里則是替換原權重為分解形式。
參數共享：讓模型的不同層共享參數（如 ALBERT 模型的做法），或使用循環的塊結構來減少獨立參數數量。
輕量模型架構：選擇更輕量的架構替代標準 Transformer，如采用更少的層、更小的隱藏維度，或引入高效注意力（sparse attention、線性注意力）來減少計算復雜度。

通過以上技術，可以在盡量保持模型精度的前提下，將模型壓縮到原始大小的一小部分，從而大幅提高推理速度、降低內存占用。這對于在移動端、Web 前端等受限環境中部署大模型尤其重要。不過壓縮往往會犧牲一定性能，需要權衡取舍并針對具體任務驗證效果。

主流大模型對比

當前大模型百花齊放，既有開源社區的成果，也有各大廠的旗艦模型。下面對幾款有代表性的模型進行對比：

模型名稱	參數規模	上下文長度	特點	開源情況
GPT-4 (OpenAI)	未公開（估計數千億）	8k tokens（32k 擴展版）	多模態能力（可處理圖像等），推理和代碼能力頂尖，使用RLHF對齊	? 非開源，需API調用
LLaMA 2(Meta)	7B/13B/70B	4k tokens	純文本模型，開源可商用，性能較上一代提升顯著	🔶 開源（附帶許可）
LLaMA 3(Meta)	8B/70B；計劃400B+	推測4k-8k（更長待公布）	新一代開放模型，訓練數據量比L2大7倍，8B/70B已超L2表現；據傳400B模型接近GPT-4水平	🔶 開源（2024發布，部分平臺提供）
Mistral 7B	7B	4k tokens (支持擴展到16k+)	法國初創公司模型，小參數下性能優異，訓練高效	? 開源（Apache 2.0）
Mixtral 8×7B	46.7B（8個專家，共7B×8）	32k tokens	Mistral 7B 的 MoE 稀疏專家版本，僅使用約12.9B參數/Token推理，推理速度比70B快6倍，性能超LLaMA2 70B并逼近GPT-3.5	? 開源（Apache 2.0）
Claude 3 (Anthropic)	未公開（估計數百億）	200k tokens（可擴展至>100萬）	注重安全性的對話模型，擅長長上下文處理，支持圖像輸入，有不同規模版本（Haiku/Sonnet/Opus）	? 非開源，需API調用
Gemini 1.5 (Google)	未公開（多專家架構）	128k tokens（實驗達100萬）	多模態下一代模型，采用全新 Mixture-of-Experts 架構?，訓練和推理更高效，長上下文能力強	? 非開源（云服務提供）

🔶 部分開源（需遵循發布許可，例如LLaMA 2需接受其社區許可證）。
? 完全開源（通常采用Apache 2.0等許可，無使用限制）。
? 非開源（權重不公開，只能通過API或平臺使用）。

上述模型各有側重。

OpenAI 的 GPT-4 目前在綜合能力上領先，但作為閉源模型使用需付費API且無法自行定制。

Meta 的 LLaMA 系列走開源路線，LLaMA 2 提供了高性能且可商用的基礎模型，已被廣泛用于下游微調；最新的 LLaMA 3 據報道進一步提升了規模和性能，試圖逼近GPT-4水平。

Mistral 7B 展示了小模型的大威力，在7B參數下利用更優的訓練策略達到接近30B模型的效果。其改進版 Mixtral 8×7B 更是采用稀疏專家（MoE）架構，將模型容量擴展至近47B但推理開銷仍似12.9B模型，性價比極高。

Anthropic 的 Claude 3 注重長文本處理和安全，對話風格穩健，提供了高達百萬級的超長上下文窗口。

谷歌的 Gemini 1.5 則代表多模態和稀疏專家結合的新方向，在圖像、文本等多模態理解以及推理效率上都有突破，是下一代通用大模型的雛形。

總體而言，如果追求最高性能和多模態能力，可考慮 GPT-4 或 Gemini 等；如果側重可控性、成本和定制，開源的 LLaMA 系列、Mistral 系列是很好的選擇；而 Claude 3 等提供了長上下文對話的新范式，適合需要超長文檔分析的應用。根據具體應用場景和資源約束，選擇合適的大模型可以事半功倍。

工具鏈與框架使用

大模型的開發和部署離不開完善的工具鏈。以下列出業界常用的庫和框架：

Hugging Face Transformers：最流行的深度學習模型庫，提供了上千種預訓練模型的接口，涵蓋Transformer加載、訓練、推理的全流程。開發者可以通過 from transformers import AutoModel, AutoTokenizer 等簡單命令獲取如 GPT-2、BERT、LLaMA-2 等模型。它支持 PyTorch 和 TensorFlow，并集成了Tokenizers快速分詞等工具，非常適合快速驗證和Fine-tuning模型。在 Hugging Face Hub 上還能找到豐富的社區微調模型和數據集資源。
DeepSpeed：由微軟推出的訓練加速庫，專注于大模型的分布式訓練和內存優化。其 ZeRO 技術將優化器狀態、梯度和模型參數切分到多GPU，極大降低單卡顯存占用，曾用于訓練高達數千億參數的模型。對于推理，DeepSpeed-Inference 也提供了異步流水線和張量并行方案，加速大模型推理。總之，當需要訓練/部署超大模型時，DeepSpeed 是重要利器。
vLLM：一種高性能的開源推理引擎，專為LLM服務優化。vLLM 的核心創新是 PagedAttention 方法，將注意力的KV緩存分頁管理，類似操作系統的虛擬內存機制?medium.com。這一機制顯著減少了長上下文時的內存浪費，使多請求并發處理更加高效?medium.com。實測顯示，vLLM 在實際基準中吞吐量比直接使用 Transformers 提升14～24倍，即使對比經過優化的TGI服務器也快約3.5倍?medium.com。因此，在需要同時處理大量生成請求的場景（如聊天機器人服務）中，vLLM 可在相同硬件下支撐數倍的并發用戶，提高性價比。
Text Generation Inference (TGI)：Hugging Face 提供的開源推理服務框架，專門針對文本生成模型部署。TGI用C++后端實現了高效的批量調度和推理，支持FP16量化、并行計算等優化，可大幅提升Transformer模型在服務端的吞吐，滿足生產級高并發需求。它還支持多模型托管和HTTP API接口，方便與現有系統集成。許多開源模型的Demo（包括LLaMA-2官方Demo）即基于TGI搭建。
OpenAI API：對于OpenAI提供的 GPT-3.5、GPT-4、DALLE 等模型，開發者可以使用其云端API。通過 RESTful 接口，后端服務器可以直接調用這些強大的模型生成內容，而無需自行部署模型。OpenAI API 提供流式輸出、參數調控等功能，使用便捷。但需要注意請求費用和速率限制。在敏感數據場景下也需考慮將提示經過脫敏處理后再發送，以保護隱私。總體來說，當不方便自行訓練或部署模型時，調用云服務API是快速集成大模型能力的方式。
LangChain：一個用于構建由LLM驅動的應用的編排框架。LangChain 提供了標準化接口來連接語言模型與外部工具/數據。開發者可以用 LangChain 將 LLM 同數據庫、互聯網搜索、計算引擎等組合，使模型具備調用工具的能力。例如，可以讓模型自動檢索知識庫以回答專業問題，或分步執行規劃任務。LangChain 還支持記憶機制和對話狀態管理，非常適合構建多輪對話代理、自動化助手等。此外，LangChain 對各大模型（OpenAI, HF Transformers 等）都提供兼容封裝，在實驗不同模型和提示模板時極其方便。總之，當需要開發復雜的鏈式Prompt流程或讓模型執行復雜操作時，LangChain 是首選框架。
LlamaIndex (GPT Index)：一個旨在將LLM與自有數據結合的數據框架。LlamaIndex 提供簡潔的接口來將文檔、數據庫等構建為索引，以便后續讓LLM檢索和利用。典型用法是：先用 LlamaIndex 將企業內部文檔解析成向量索引，然后通過一個檢索增強的Prompt，讓 LLM 在回答問題時先從索引中提取相關信息。這樣模型就能利用最新的或私有的知識，而不局限于訓練語料中固有的內容。LlamaIndex 支持多種向量數據庫和數據源插件（超過300種集成）。對于構建知識庫問答、企業搜索助手等應用，LlamaIndex 能極大簡化開發工作，免去繁瑣的手動切分文檔、向量搜索流程。

以上工具鏈覆蓋了模型層、服務層和應用層。在實際項目中，可以將它們組合使用：例如用 Hugging Face 提供預訓練模型 + LoRA 方法微調，然后借助 DeepSpeed 將模型部署在多卡集群上，推理時使用 vLLM/TGI 提升吞吐，應用端通過 LangChain 編排模型與業務數據交互。這套組合拳能夠加速大模型從開發到落地的全流程。

企業級落地趨勢：RAG、私有部署與多租戶架構

隨著大模型技術成熟，企業界正積極將其引入各類業務場景。然而，與消費級應用不同，企業落地需要考慮數據私密、部署成本、多用戶服務等特殊需求。以下是當前企業應用大模型的幾大技術趨勢：

1. 檢索增強生成（RAG）系統優化

企業中很多應用需要模型結合企業內部知識庫進行問答或分析。例如客服機器人要引用產品手冊內容回答客戶問題，法律檢索要引用法規條文。這些場景適合采用RAG架構：將企業知識以向量數據庫或全文檢索形式存儲，LLM每次根據用戶問題檢索相關內容，再基于這些內容生成回答。這樣既避免模型“胡編”公司內部數據，又可動態更新知識庫以確保時效性。當前重點在于優化RAG各環節以提升準確性和效率：

更好的檢索：針對企業領域，使用領域定制的embedding和語義搜索提升相關性。例如面向醫療領域的問題，采用專門微調的向量模型來獲取更準確的語義相似度。還可結合知識圖譜或結構化數據庫提高精確度。
檢索-生成融合：采用檢索-重排-閱讀三段式架構。檢索器先找若干候選文檔片段，然后通過一個小的重排序模型按照與問題的匹配度重新排序?databricks.com（可訓練），最后LLM閱讀排名靠前的片段作答。這樣能過濾掉部分不相關材料，減少模型負擔，提高答案質量。
減少上下文長度壓力：傳統RAG將檢索結果簡單拼接在Prompt中，長度過大時效果變差。為此有研究將檢索到的信息通過工具調用方式提供給模型，而非生硬拼接。例如，通過OpenAI函數調用，先把資料傳給模型一個tool函數，模型需要某段資料時才調用，這樣模型不會被過多無關信息干擾。此外，一些壓縮上下文的方法（摘要、知識三元組抽取等）也在應用，幫助模型更高效地利用檢索結果。
結果引用與可解釋：企業很看重輸出結果的可溯源性。因此RAG系統通常會讓模型給出回答同時附上引用來源（如文檔名或鏈接）。像微軟Bing Chat那樣，在答案句子后加上來源編號?arxiv.org。這要求模型在Prompt設計和后處理上進行引導。通過few-shot示例或特殊標記，引導模型將引用文檔整合到回答中。這增強了回答的可信度，也方便人工審核。

2. 私有化部署的新方法

許多企業出于數據安全和合規要求，傾向于在本地或專有云部署大模型，而非調用公共API。這就需要解決模型落地成本和性能問題。最新的趨勢有：

開源大模型定制：企業往往選擇開源模型（如LLaMA?2、Mistral等）作為基礎，在自己的數據上進行輕量微調或LoRA增量訓練。這樣模型權重完全可控，不存在數據外泄風險。例如，一家法律咨詢公司用LLaMA?2微調了內部法律問答數據，得到一個懂本地法規的對話模型，內部部署服務律師們使用。
高效微調方案：為降低私有數據微調成本，諸如LoRA、QP-Tuning等參數高效微調方法被廣泛采用。只需調優模型很小一部分參數，就能讓模型掌握企業專屬知識或風格。比如LoRA僅插入低秩權重，內存開銷很小，這使得在一臺普通GPU上也能微調數十億參數模型。
數據不出本地：一些云廠商提供把模型“帶到數據”而非“數據送上云”的方案。例如微軟Azure的認知服務支持在本地私有環境運行OpenAI模型推理，保證輸入輸出不經微軟服務器。OpenAI 也推出了ChatGPT Enterprise版，承諾不將客戶數據用于訓練模型，并提供專用隔離的推理實例。這樣企業可以用上強大模型，又滿足合規要求。
軟硬件一體優化：NVIDIA、Intel等紛紛推出針對本地大模型推理的解決方案。比如NVIDIA的NeMo框架與TensorRT優化，可將模型壓縮并充分利用GPU張量核心，實現本地最高效推理；Intel 則通過OneAPI和優化庫讓大模型在CPU上運行更快，方便部署在CPU服務器上。甚至有硬件創業公司推出“大模型推理加速卡”，企業將其插入現有服務器即可提升模型運行效率。這些降低了私有部署的硬件門檻。

總之，如今**“大模型私有化”**已成為熱門服務方向，從完整開源解決方案到廠商定制方案應有盡有。企業可以根據自身需求選擇：要絕對離線安全，可以用開源模型+自主部署；對模型能力要求極高，也可采購廠商私有云實例，總之靈活性顯著提高。

3. 多租戶推理架構： 企業經常需要讓一個模型服務多個應用或客戶，而這些用戶的會話彼此隔離、并發進行。這就需要支持多租戶（Multi-tenant）的推理架構，既高并發又無數據串擾。為此，開發高效的多會話調度和隔離技術非常關鍵。

如前文推理加速部分提到的，vLLM等引擎本身就是為多租戶場景設計的：通過PagedAttention和連續批處理，使得單機就可以高效處理眾多并發請求。這對企業內部服務多個部門、每部門都有各自的對話上下文，非常實用。在多租戶場景下，要確保：

數據隔離：每個會話的歷史和機密信息不會泄露到別的會話的上下文中。底層實現上KV緩存分頁等機制天然提供了隔離?。此外，服務端還需嚴格在軟件上隔離不同API調用者的身份和上下文。
資源公平與限流：防止某一租戶大量請求占滿全部算力。可以在架構上對每個租戶設定QPS上限或優先級調度。例如為付費更高的客戶保證更低延遲。像Transformer Serving框架（HuggingFace TGI等）都提供多隊列、多worker的設計，以支持多租戶服務。
伸縮性：當租戶增加，請求量猛漲時，架構可以水平擴展（加機器）或垂直擴展（上更強GPU）來應對。這需要無狀態或輕狀態的服務設計。許多企業將模型封裝成容器，由Kubernetes等編排，以便根據負載自動擴縮容，實現彈性服務。

目前的解決方案包括：開源的text-generation-inference（TGI）服務器，可高效批量調度多個生成請求；微軟的 ORTInference 加強版，能夠在CPU上并行多個推理；以及云廠商的托管服務（如AWS Bedrock、Azure OpenAI）本身為多租戶設計，開發者只需調用API即可。對于自行部署，vLLM是上佳選擇，其論文在SOSP?2023中詳細闡述了如何實現23倍吞吐提升同時降低P50延遲。通過這些技術，即使面對高并發訪問，企業也能讓模型保持穩定快速響應。

MCP

1. MCP是什么？

Model Context Protocol (MCP) 是由Anthropic開發的開放協議，用于標準化AI助手（如Claude）與外部數據源和工具之間的交互。它提供了一個統一的接口，讓AI能夠安全、高效地訪問各種資源。MCP協議通過標準化模型之間的上下文交換，使得不同的模型可以理解彼此的意圖、狀態以及所需的信息，達到更高效的協同工作。

2. MCP的主要組件

[AI Assistant]host <-> [MCP Client] <-> [MCP Server] <-> [External Resources]

MCP Server: 提供數據或功能的服務端
MCP Client: AI助手和服務器之間的通信橋梁
MCP Host: 托管AI助手的環境（如Claude Desktop應用）