AI大模型概念梳理1
目标读者：希望系统了解大模型核心概念的开发者、产品经理和技术管理者。本文档以"扫盲"为定位，用通俗语言解释LLM、Transformer、Agent、多模态等关键概念，帮助你快速建立完整的知识框架。
一、LLM（大语言模型）
1.1 什么是LLM
LLM（Large Language Model）是一种基于深度学习的大规模语言模型，通过学习海量文本数据中的语言规律，获得理解和生成人类语言的能力。核心能力：文本生成、逻辑推理、代码编写、翻译、摘要、对话等。
1.2 LLM的演进历程
|
阶段 |
代表模型 |
核心突破 |
|---|---|---|
|
2017 |
Transformer论文 |
提出Self-Attention机制，奠定LLM架构基础 |
|
2018 |
BERT（Google）、GPT-1（OpenAI） |
BERT：双向编码，理解上下文；GPT：单向解码，预测下一个词 |
|
2019-2020 |
GPT-2、GPT-3（175B参数） |
涌现能力(Emergence)，In-Context Learning，Few-shot |
|
2022 |
ChatGPT、GPT-3.5、LLaMA |
RLHF对齐训练，指令遵循能力，ChatGPT引爆行业 |
|
2023-2024 |
GPT-4、Claude、Gemini、LLaMA3 |
多模态、长上下文窗口、推理增强、Agent能力 |
1.3 LLM的核心能力
- 语言理解与生成：理解复杂指令，生成连贯、有逻辑的文本
- 上下文学习(In-Context Learning)：通过在prompt中提供几个示例，无需微调即可完成特定任务
- 思维链推理(Chain-of-Thought)：通过prompt引导模型逐步推理，解决复杂逻辑问题
- 工具使用(Tool Use)：调用外部API、执行代码、搜索数据库（Agent的基础能力）
- 代码生成：理解需求并生成可用代码，支持几十种编程语言
1.4 主流LLM一览
|
模型 |
公司 |
特点 |
|---|---|---|
|
GPT-4o/4.5 |
OpenAI |
综合能力最强，多模态，生态完善 |
|
Claude 4 (Opus/Sonnet) |
Anthropic |
安全性、长上下文(200K)、推理能力强 |
|
Gemini 2.5 |
|
原生多模态，最大上下文窗口(1M+) |
|
LLaMA 3/4 |
Meta |
开源最强，社区生态丰富 |
|
DeepSeek V3/R1 |
DeepSeek |
开源，MoE架构，性价比极高，推理能力强 |
|
Qwen 2.5/3 |
阿里 |
中文能力突出，多尺寸选择 |
二、Token
2.1 Token是什么
Token是大模型处理文本的最小语义单元，不是单词，也不是字符。一个Token大约是0.75个英文单词或1.5个中文字符。模型按Token计费和限制上下文长度。
2.2 Token化（Tokenization）过程
- 文本 → Token序列："今天天气很好" → ["今天", "天气", "很好"] 或 ["今", "天", "天气", "很好"]
- Token → Token ID：每个Token映射为词汇表中的数字ID → [1234, 5678, 9012]
- Token ID → Embedding：ID通过Embedding层转换为稠密向量 → 模型可计算的数值表示
2.3 BPE分词算法
BPE（Byte Pair Encoding）是目前主流分词算法。核心思想：从字符级别开始，统计最高频的相邻字符对，合并为新Token，不断迭代直到预设的词汇表大小（如GPT-4约10万Token）。
- 优势：平衡了词汇表大小(不会过大)和语义完整性(不会过碎)；未登录词自动回退到子词或字符级别，不会产生UNK
2.4 Token关键指标
|
概念 |
说明 |
|---|---|
|
上下文窗口 |
模型一次能处理的最大Token数（如128K=约9万中文字或一篇中篇小说）。GPT-4 Turbo 128K，Gemini 1M+，Claude 200K |
|
输入Token |
Prompt消耗的Token数，通常按量计费（如$3/百万Token） |
|
输出Token |
模型生成的Token数，通常比输入贵（如$15/百万Token） |
|
Token速度 |
每秒生成Token数（TPS）。Opus HPC模式可达400+ TPS；普通模型50-100 TPS |
三、Transformer架构
3.1 为什么Transformer是革命性的
2017年Google发表《Attention Is All You Need》，提出Transformer架构。它彻底抛弃了RNN/LSTM的循环结构，用Self-Attention（自注意力）机制实现并行计算，训练效率大幅提升，且能捕捉长距离依赖关系。
3.2 核心组成
Transformer由Encoder（编码器）和Decoder（解码器）两部分堆叠组成。GPT只用Decoder（生成模型），BERT只用Encoder（理解模型），T5两者都用。
Encoder（编码器）：将输入序列编码为上下文表示
- Self-Attention：每个词关注序列中所有其他词（包括自己），计算相关性权重。允许模型理解"My car is old. It is blue"中"It"指"car"
- Feed-Forward Network（前馈网络）：两层全连接，引入非线性变换，增强表达能力
- Add & Norm（残差连接+层归一化）：稳定深层网络训练，防止梯度消失
Decoder（解码器）：根据编码表示自回归生成输出
- Masked Self-Attention：生成第N个词时，只能看到前N-1个词（掩码遮住后面的词），保证自回归生成
- Cross-Attention：Decoder关注Encoder输出的上下文表示，将输入信息融入生成过程
3.3 Self-Attention 详解
这是Transformer最核心的机制。每个Token产生三个向量：Q（Query，查询）、K（Key，键）、V（Value，值）。Q与所有K做点积得到注意力权重 → Softmax归一化 → 与V加权求和 → 输出。
Multi-Head Attention（多头注意力）：并行走多组Q/K/V（如8个头），每组关注不同的语义关系（语法、指代、语义关联等），最后拼接。类比：多个人从不同角度观察同一事物。
3.4 位置编码（Positional Encoding）
- 问题：Self-Attention并行计算，不知道词的先后顺序。相比RNN天然有时序信息
- 解决：在每个Token的Embedding上叠加位置信息。方法有：正弦位置编码（原始论文）、可学习位置编码（BERT/GPT）、旋转位置编码RoPE（LLaMA/Qwen，目前主流）
3.5 Transformer变体
|
变体 |
说明 |
|---|---|
|
仅Encoder（BERT系列） |
适合理解任务：分类、NER、问答。预训练：MLM（随机遮住一些词，预测它们） |
|
仅Decoder（GPT系列，主流LLM） |
适合生成任务：对话、写作、代码。预训练：自回归预测Next Token |
|
Encoder-Decoder（T5/BART） |
适合转换任务：翻译、摘要。用于特定应用 |
|
MoE（Mixture of Experts） |
每个Token只激活部分参数（如Mixtral 8×7B，每次只用13B）。DeepSeek V3用MoE实现高参数低激活，降低成本 |
四、Agent
4.1 什么是AI Agent
AI Agent（智能体）是一个能够自主感知环境、制定计划、使用工具、执行操作来完成复杂目标的AI系统。可以理解为"能够自主思考和行动的AI"，而不只是"一问一答的聊天机器人"。
4.2 Agent vs 普通LLM对话
|
对比维度 |
普通LLM对话 |
Agent |
|---|---|---|
|
交互模式 |
被动问答（一问一答） |
主动规划-执行-观察-反思循环 |
|
能力边界 |
仅靠训练数据中的知识回答 |
可调用外部工具(API/代码/数据库)扩展 |
|
记忆能力 |
单轮/多轮对话记忆（有限） |
短期记忆(上下文) + 长期记忆(向量数据库) |
|
任务复杂度 |
单步任务 |
多步规划与执行（拆分子任务，编排工具调用） |
|
自主性 |
完全依赖用户指令 |
可根据目标自主决定行动路径 |
4.3 Agent的核心组件
- 大脑（LLM）：负责理解任务、推理规划、决策判断
- 规划（Planning）：将复杂目标拆解为可执行的子任务序列（Task Decomposition + 子目标规划）
- 工具（Tools）：API调用、代码执行、网络搜索、数据库查询、文件操作等。工具定义需描述名称、参数、功能
- 记忆（Memory）：短期记忆（对话上下文，多轮对话窗口内）+ 长期记忆（向量数据库/RAG存储，跨对话持久化）
- 反思（Reflection）：检查执行结果，判断是否达成目标。未达成则调整策略重试（Self-Correction）
4.4 Agent的工作流程
五、ReAct
5.1 ReAct是什么
ReAct（Reasoning + Acting）是2022年提出的Agent推理框架。核心思想：让LLM交替进行推理（Thought）和行动（Action），每步行动后观察结果，再决定下一步推理。将思考和执行紧密结合。
5.2 ReAct vs Chain-of-Thought vs 纯Action
|
模式 |
核心做法 |
局限 |
|---|---|---|
|
Chain-of-Thought（CoT） |
只推理不行动。逐步思考，最终给出结果 |
无法获取外部信息，推理可能基于错误事实 |
|
纯Action（Act-only） |
只有动不思。直接调用工具获取信息 |
缺乏高层次规划，容易盲目执行 |
|
ReAct（推荐） |
推理+行动交替。思考→行动→观察→再思考 |
需要多种工具支持 |
5.3 ReAct执行示例
5.4 ReAct在工程中的应用
- LangChain Agent：ReAct是最核心的Agent模式，通过create_react_agent()实现
- OpenAI Function Calling：本质上是ReAct的变体——Thought(模型内部) → Action(生成function_call) → Observation(函数返回) → 继续生成
- Claude Tool Use：同样遵循ReAct范式，tool_use → tool_result循环
六、A2A（Agent-to-Agent）
6.1 什么是A2A
A2A（Agent-to-Agent）是指多个AI Agent之间直接通信和协作的协议/框架。Google在2025年正式发布了A2A开放协议，旨在让不同厂商、不同框架构建的Agent能够互相发现、通信和协作。
6.2 A2A核心概念
|
概念 |
说明 |
|---|---|
|
Agent Card |
每个Agent的能力描述文档（JSON），声明自己能做什么、支持什么输入输出 |
|
Task |
Agent间传递的任务单元，包含目标、参数、状态 |
|
Message |
Agent间通信的消息格式（文本、结构化数据、Artifact引用） |
|
Artifact |
Agent产出的结构化产物（文档、图片、代码、数据），可在Agent间传递和引用 |
6.3 A2A vs MCP
A2A是Agent之间的协议（Agent如何找Agent、如何协作），解决"Agent与Agent"的通信问题。MCP（Model Context Protocol）是Agent与工具之间的协议（Agent如何发现和使用工具/数据源），解决"Agent与外部资源"的交互问题。两者互补。
6.4 A2A的典型应用场景
- 专业分工：代码Agent + 测试Agent + 文档Agent，各司其职，互传产物
- 跨系统编排：客服Agent发现问题需要升级 → 自动联系后台技术Agent → 技术Agent查日志后返回方案
- 多厂商协作：企业内部使用不同厂商的Agent，通过A2A统一协作
七、多Agent架构
7.1 什么是多Agent架构
多Agent架构是将复杂任务分解给多个专业Agent协作完成的系统设计模式。相比单一Agent（能力有限、上下文容易溢出），多Agent通过分工协作，处理更大规模和更复杂的任务。
7.2 架构模式
|
模式 |
结构 |
适用场景 |
|---|---|---|
|
层次式(Hierarchical) |
一个管理者Agent分配任务给下属Agent，汇总结果 |
任务可分层的场景，如项目管理、多模块开发 |
|
流水线式(Sequential/Pipeline) |
A→B→C顺序执行，后一个以前一个的输出为输入 |
固定的多阶段流程，如代码生成→审查→测试 |
|
辩论式(Debate) |
多个Agent各出方案，互相质疑，综合输出最优解 |
需要多角度考虑的决策，如方案评审、内容质量控制 |
|
投票式(Voting) |
多Agent独立完成任务，投票/择优选出最终结果 |
对准确性要求极高的场景，如代码生成+验证 |
|
去中心化(Decentralized) |
Agent自由通信协作，无中央控制者 |
复杂的开放任务，如科研探索、创意头脑风暴 |
7.3 多Agent的关键挑战
- 通信协议：Agent之间用什么格式交互（A2A正在解决）
- 上下文传递：如何高效传递中间产物而不让上下文膨胀
- 任务分配/调度：如何自动判断该分配给哪个Agent
- 错误传播：上游Agent的错误可能被下游放大
- 成本控制：多Agent意味着多次LLM调用，Token消耗倍增
7.4 落地框架
- LangGraph：基于有向图编排Agent协作流程
- CrewAI：基于角色(Role)的多Agent编排，每个Agent有明确角色定义
- AutoGen（微软）：支持复杂多Agent对话和代码生成
- Swarm（OpenAI，实验性）：轻量级Agent编排，强调handoff（转交）机制
八、多模态
8.1 什么是多模态
多模态（Multi-modal）指模型能够同时处理和理解多种类型的数据输入：文本、图片、音频、视频、代码等。人类天生就是多模态的，多模态AI更接近人类感知世界的方式。
8.2 多模态的实现方式
统一Embedding空间（主流）
- 文本通过Tokenizer → Token Embedding
- 图片通过Vision Encoder（如ViT/CLIP）→ Image Embedding
- 两者对齐到同一向量空间 → LLM统一处理
- 代表模型：GPT-4V/4o、Gemini、Claude 3.5、LLaVA、Qwen-VL
原生多模态（趋势）
- 训练阶段就包含多模态数据，而非后期拼接
- 代表模型：GPT-4o（omni=全模态，文本+视觉+音频输入输出）、Gemini（原生多模态设计）
8.3 多模态的典型能力
|
能力 |
示例 |
|---|---|
|
图片理解 |
描述图片内容、识别物体、OCR文字提取、"这张图有什么问题？" |
|
视觉推理 |
分析图表数据趋势、看懂UI截图并给出代码、理解梗图 |
|
视频理解 |
总结视频内容、分析动作流程、提取关键帧信息 |
|
音频处理 |
语音转文字(ASR)、音频内容分析、语气情感识别 |
|
图文生成 |
根据描述生成图片(DALL-E/Midjourney)、视频(Sora) |
九、上下文工程
9.1 什么是上下文工程
上下文工程（Context Engineering）是系统性设计和管理LLM输入上下文的技术体系。在提示词之外，还包括：信息检索(RAG)、记忆管理、上下文压缩、结构化组织等。提示词工程关注"说什么"，上下文工程关注"给模型什么样的信息环境"。
9.2 上下文工程的核心组成
|
模块 |
要点 |
|---|---|
|
信息检索（RAG） |
从知识库检索相关信息注入上下文。挑战：检索质量(召回率+准确率)、Query Rewriting、HyDE生成假想答案检索 |
|
上下文窗口管理 |
Token有限制，需要合理分配：System Prompt(规则/角色) + 检索信息 + 对话历史 + 当前Query |
|
上下文压缩 |
长期对话需压缩历史：摘要式（关键信息提炼）、滑动窗口式（保留最近N轮）、重要性评估式（保留关键对话轮次） |
|
记忆系统 |
短期记忆(当前会话)、长期记忆(跨会话持久化，用户画像/偏好/知识)、工作记忆(当前任务中间状态) |
|
结构化组织 |
用XML/JSON/特殊分隔符标记不同信息区。让模型清楚区分"指令"、"参考知识"、"对话历史"、"当前问题" |
9.3 上下文工程 vs 提示词工程
提示词工程是上下文工程的子集。写好Prompt很重要，但不给模型提供正确的信息（上下文），再好的Prompt也无用。在RAG和Agent场景中，上下文工程比提示词工程更重要。
十、提示词工程
10.1 什么是提示词工程
提示词工程（Prompt Engineering）是设计和优化LLM输入指令的方法论，通过精心构造Prompt引导模型输出高质量、符合预期的结果。它是与大模型交互的最直接手段。
10.2 核心技巧
|
技巧 |
做法 |
为什么有效 |
|---|---|---|
|
角色设定 |
"你是一个资深Java架构师" |
激活特定领域知识分布 |
|
Few-shot |
给2-3个输入→输出示例 |
In-Context Learning，格式锚定 |
|
Chain-of-Thought |
"让我们一步一步思考" |
引导中间推理步骤，减少跳跃错误 |
|
结构化输出 |
"请用JSON格式输出" |
约束格式，便于下游程序解析 |
|
分步指令 |
"首先...然后...最后..." |
明确执行顺序，避免遗漏步骤 |
|
负面约束 |
"不要包含...不要使用..." |
明确排除不良输出 |
|
思维树(Tree-of-Thought) |
生成多个方案，评估选择最优 |
探索性推理，适合难度大的问题 |
10.3 提示词框架示例
10.4 提示词工程进阶：System Prompt与User Prompt的区分
- System Prompt：设定角色、规则、行为约束、输出格式要求。权重高，适合放持久化设定
- User Prompt：具体的当前问题和上下文（文档、代码、数据）。动态变化
- 原则：System Prompt放不变的规则，User Prompt放变化的数据。两者协作形成完整指令
十一、微调（Fine-tuning）
11.1 什么是微调
微调（Fine-tuning）是在预训练好的大模型基础上，用特定领域的数据继续训练模型的过程。目的是让模型更好地适应特定任务、领域风格或指令格式。类比：通才本科生（预训练）→ 专业研究生（微调）。
11.2 微调 vs 提示词工程 vs RAG
|
对比 |
提示词工程 |
RAG |
微调 |
|---|---|---|---|
|
核心 |
优化输入指令 |
检索外部知识注入 |
调整模型参数 |
|
知识更新 |
无 |
实时更新知识库 |
需重新训练 |
|
成本 |
几无成本 |
中（基础设施） |
高（GPU算力） |
|
适用 |
常规任务、格式控制 |
需要最新知识、海量文档 |
特定风格、领域术语、任务 |
|
幻觉控制 |
弱 |
强（有外部事实约束） |
中（学习了但可能遗忘） |
11.3 微调方法对比
|
方法 |
做法 |
特点 |
|---|---|---|
|
全量微调(Full FT) |
更新所有参数 |
效果最好，计算最贵（需大量GPU）。大模型几乎不可行 |
|
LoRA（Low-Rank Adaptation） |
只训练低秩矩阵增量，冻结原模型参数 |
目前最主流。参数量极少(原模型的0.1%-1%)，可插拔。训练快，多LoRA可共存 |
|
QLoRA |
LoRA + 4-bit量化 |
可在单张消费级GPU上微调70B+模型 |
|
Prefix-Tuning / P-Tuning |
学习可训练的"前缀向量"拼接到输入前 |
更轻量，效果略逊LoRA |
|
指令微调(Instruction FT) |
用大量的(指令→回复)数据对训练 |
提升模型指令遵循能力，ChatGPT的关键技术之一 |
|
RLHF/DPO |
基于人类反馈的强化学习 / 直接偏好优化 |
对齐人类偏好，让输出更有用、更安全。ChatGPT成功的核心 |
11.4 什么时候该微调（决策树）
问自己：提示词工程够吗 → 不够 → RAG够吗 → 不够 → 微调。微调适用于：需要特定风格（医学/法律术语）、任务边界清晰且高频（客服话术）、需要模型内化知识（非检索式）的场景。
学习路线建议：
- 入门：理解Token→Transformer→LLM的基础链路
- 上手：精通提示词工程 + 上下文工程，这是使用LLM的核心能力
- 实战：掌握Agent(ReAct)+RAG，这是目前工程应用最广泛的模式
- 进阶：多Agent架构设计 + 微调(LoRA)，解决复杂场景和领域特化问题
- 前沿：关注多模态、A2A协议，这是AI应用的下一个方向