Token
Token 是文本经分词(Tokenization)后生成的最小语义单元,可以是单词(如“apple”)、子词(如“un”+“happy”)、字符(如“A”)、标点符号(如“!”)或特殊符号(如“[CLS]”),以**整数ID序列(词表索引)**表示 分词策略:
- 词级分词 (Word-level):如“hello”作为1个Token,简单但词表庞大。
- 子词分词 (Subword-level):如BERT的WordPiece将“unhappy”拆为[“un”, “happy”],平衡罕见词处理与词表效率。
- 字符级分词 (Character-level):每个字符为1个Token,适用中文等无空格语言。
Tokenizer
大模型中的Tokenizer是将原始文本分割为模型可处理的基本单元(Token)的核心组件,直接影响模型输入质量和性能。
- WordPiece:基于贪心合并策略,优先合并高频相邻子词
- Byte-Pair Encoding (BPE) :迭代合并最高频字节对(如“e”+“r”→“er”),逐步构建子词表
- Unigram Language Model :基于统计概率删除对语料似然贡献最小的子词(如从基础词表[“h”,“ug”,“p”]中删除低概率单元)
- SentencePiece:直接处理原始字节流,无需预分词,支持Unicode和空格保留(用▁转义空格)。
- BPE模式 :同BPE合并策略;
- Unigram模式 :从大词表开始,迭代删除低概率子词
模型 分词方法 词表大小 中文压缩率 特殊设计 GPT-4o BPE (cl100k_base) ~100K 1.5–2 字符/Token 空格敏感、代码符号优化 Llama 3 SentencePiece 32K/128K 0.8→1.75 字符/Token 需扩展中文词表 Qwen BBPE 152K 1.5–1.8 字符/Token 字节级无 OOV、中文高频词合并 DeepSeek BPE(中英优化) ~100K ~1.6 字符/Token 数学问题适配、MoE 动态激活
Embedding
Embedding(嵌入)是一种将离散的、高维的复杂数据(如文本、图像、类别标签)转换为低维连续向量表示的核心技术。
- 降维压缩 :将高维稀疏数据(如百万级词汇表)转化为低维稠密向量,提升计算效率。
- 语义捕获 :使相似对象在向量空间中距离更近(如“国王-男人+女人≈女王”)。
类型 代表模型 特点 局限 静态Embedding Word2Vec 训练后向量固定,计算效率高 无法处理一词多义 动态Embedding BERT 上下文敏感,同一词在不同语境向量不同 计算开销大,需GPU支持
v.s. Token
| 维度 | Token | Embedding |
|---|---|---|
| 本质 | 离散符号(文本的最小单位) | 连续向量(Token的数学表示) |
| 是否含语义 | 无(如“苹果”仅作为符号) | 是(向量隐含语义关系) |
| 数据形式 | 整数ID(词表索引) | 浮点数向量(如768维) |
| 生成方式 | 分词器(Tokenizer)切割文本生成 | 嵌入层(Embedding Layer)映射ID到向量 |
| 可变性 | 固定(同一Token在不同语境ID不变) | 可动态(如BERT中“苹果”向量随上下文变化) |
文本处理 :分词 → 向量化 → 存储到向量数据库(如Faiss)
Transformer
2017年由Google在论文《Attention Is All You Need》提出,传统RNN/LSTM需顺序处理序列,存在长期依赖失效和训练低效问题,Transformer通过自注意力(Self-Attention) 并行处理所有词元(Token),直接建模任意两个词元的全局依赖关系
- 并行计算 :序列所有位置同时处理,大幅提升训练速度(如GPT-3训练效率比LSTM高10倍以上)。
- 长距离建模 :注意力机制无距离衰减,可捕捉跨千词依赖(如文档级语义)。
- 可扩展性 :支持堆叠百层网络,适配千亿参数大模型(如GPT-4)
位置编码(Positional Encoding):注入序列顺序信息(因注意力机制本身无序),使模型感知相对位置,经典公式包括正弦/余弦函数等。
多头注意力(Multi-Head Attention) :将Q/K/V拆分为h个头(如8头),独立计算注意力,从不同子空间学习多样特征(如语法结构、语义角色),拼接各头输出 → 线性投影回原维度
- Query(查询向量)
- 语义角色:表示当前需要关注的目标位置或“问题”。例如,在翻译任务中,Query 对应当前待生成的词,用于从上下文中检索相关信息。
- 功能:决定模型应从哪些位置提取信息。
- 类比:类似搜索引擎中的“搜索关键词”。
- Key(键向量)
- 语义角色:表示上下文中的候选位置或“答案标识”。每个输入位置都有一个 Key,用于与 Query 匹配相似度。
- 功能:衡量上下文位置与当前 Query 的相关性。匹配度越高,权重越大。
- 类比:类似数据库中的“索引键”。
- Value(值向量)
- 语义角色:表示实际的信息内容。当 Query 与 Key 匹配后,Value 提供需传递的具体数据。
- 功能:根据注意力权重加权求和,生成当前位置的输出表示。
- 类比:类似搜索引擎返回的“网页内容”。
训练阶段(并行计算)
- 输入处理 :
- 词嵌入(Word Embedding) + 位置编码 → 编码器输入。
- 解码器输入:目标序列右移(开头添加
「模拟推理行为,避免信息泄露 」),标签为原目标序列。
- 损失函数 : 交叉熵损失,计算解码器输出概率与标签的差异
推理阶段(自回归生成)
- 编码器处理输入序列(如“我爱你”),输出上下文矩阵C。
- 解码器以
为起点,循环生成 :- 第1步:输入
→ 输出“I” - 第2步:输入
, I → 输出“love” - 第3步:输入
, I, love → 输出“you”
- 第1步:输入
自回归生成(Autoregressive Generation): 模型基于已生成的部分,逐步预测下一个词,形成循环依赖的生成过程。其本质是 “用当前输出作为下一时刻的输入” 。
LLM
LM 主要基于 Transformer 架构,分为三类:
- Encoder-only (如 BERT):擅长理解任务(文本分类、问答)。
- Decoder-only (如 GPT 系列):专注文本生成(对话、创作)。
- Encoder-Decoder (如 T5):兼顾理解与生成(翻译、摘要)。
Decoder-Only
GPT-3以来主流大模型(如GPT系列、LLaMA、Claude等)普遍采用Decoder-only架构。 生成能力
- 自回归生成优势
Decoder-only模型通过因果注意力(Causal Attention) 实现自回归生成:每个词仅依赖上文信息预测下一个词,模拟人类语言生成过程。这种机制天然适配文本创作、对话、代码生成等任务,输出连贯性强。
- 对比:Encoder-Decoder架构需先编码完整输入再解码,生成延迟高;Encoder-only(如BERT)无生成能力。
- 长距离依赖建模 因果注意力的注意力矩阵为严格下三角矩阵(满秩),理论上比双向注意力(易退化至低秩)具备更强的复杂依赖建模能力,尤其在生成长文本时表现更优。
Self-Attention:序列中所有位置相互可见(如 BERT) Causal Attention:仅允许当前位置关注自身及之前位置,避免未来信息的干扰(如 GPT 系列)
训练与推理效率
- 训练并行化
Decoder-only支持Teacher Forcing训练:输入完整目标序列(右移添加
<BOS>),模型并行预测每个位置的下一词,极大加速训练过程。- 对比:Encoder-Decoder需串行处理编码-解码阶段,并行度低。
- 推理计算优化
- 参数效率:单一Decoder模块比Encoder-Decoder双模块参数更少,降低显存占用。
- KV缓存:自回归生成时可缓存历史Key/Value向量,避免重复计算,提升推理速度。
架构简洁性与泛化能力
- 统一任务处理范式
Decoder-only通过提示工程(Prompt Engineering) 统一各类任务:输入指令+示例,模型直接生成结果。无需为不同任务设计特定架构(如T5需为翻译/摘要定制结构)。
- 案例:GPT-3仅通过文本提示即可完成翻译、问答、编程等任务。
- 零样本/少样本泛化 自回归预训练(Next Token Prediction)迫使模型在信息受限下学习通用语言规律。当模型规模足够大时(如千亿参数),展现出强大的上下文学习(In-context Learning) 能力,仅需少量示例即可泛化至新任务。
Input & Output
Input
- 用户输入: 原始文本
- Tokenizer: → Token 序列
- Embedding 层:→ Embedding 向量
- Positional Encoding:叠加位置编码 output
- 输出层生成: 每个 Token 的概率分布 (形状:[序列长度 × 词表大小])
- 解码策略 :贪婪搜索,Top-P 采样等生产Token
- 贪婪搜索 :直接选最高概率 Token(如“苹果”)。
- 采样 :按概率随机选择(如 30% 选“苹果”,20% 选“香蕉”)。
- Tokenizer:解码为人类可读文本
训练
- 预训练(Pre-training):通过海量无标注数据学习语言的统计规律、语法结构和常识知识,构建基础语言表示能力
- 数据收集清理
- 分词
- 自回归语言建模
- 监督微调(Supervised Fine-Tuning, SFT) :使用标注数据优化模型,使其适应具体任务
- 数据构建:人工标注或模型生成「指令-响应」对
chat_history = [
{"role": "user", "content": "今天北京天气如何?"},
{"role": "assistant", "content": "北京晴,25°C。"}
]
<|begin_of_text|>
<|start_header_id|>user<|end_header_id|>今天北京天气如何?<|eot_id|>
<|start_header_id|>assistant<|end_header_id|>北京晴,25°C。<|eot_id|>
- 损失函数 :交叉熵损失,优化输出序列与标注的匹配度
- 基于人类反馈的强化学习(Reinforcement Learning from Human Feedback, RLHF):对齐人类偏好,提升输出安全性、有用性和流畅性
- 奖励模型(RM)训练 :人工对模型多个输出排序(如A > B > C),构建偏好数据集
- 强化学习优化(PPO) :以SFT模型为初始策略,RM提供奖励信号,生成多个候选回答,选择高奖励样本更新参数
推理
- 提示词(Prompt):用户向大模型提供的输入指令或问题,用于引导模型生成特定输出
- 补全(Completion):模型基于Prompt生成的后续内容,即模型对输入的延续响应
Prompt Engineering
通过结构化设计(如RTF框架)、少样本引导和分步推理,优化Prompt设计,桥接用户需求与模型能力,最大化模型性能
基础提示技术
- 零样本提示(Zero-Shot)
- 原理:仅通过任务描述直接引导模型生成结果,无需示例。要求指令包含 背景、角色、任务、输出格式 四要素。
- 少样本提示(Few-Shot)
- 原理:提供 1-5个高质量示例,教会模型任务模式(输入→输出映射)
- 角色提示(Role Playing)
- 原理:指定模型身份(如律师、医生),约束知识范围与语言风格
- 增效策略:叠加目标受众描述(如“向10岁小孩解释”)
高级推理技术
- 思维链(Chain-of-Thought, CoT)
- 原理:强制模型 分步展示推理过程(如“先计算成本,再评估风险”)
- 自一致性(Self-Consistency)
- 原理:生成 多条推理路径,投票选择最高票答案,显著降低错误率
- ReAct 提示
原理:结合 推理(Reason)与行动(Act),调用API/工具获取实时数据
工作流:
1. 推理:需查询天气API 2. 行动:调用天气API(北京) 3. 响应:今日北京25℃,建议携带雨具
结构化控制技术
- 格式约束 :强制输出为 JSON/表格/代码 等结构化格式
- 条件限制
- 长度控制:“总结文本在50字内”
- 风格限定:“用小红书爆款笔记风格写防晒文案”
- 情绪约束:“以积极语气描述产品缺陷”
- 上下文增强
- 方法:注入领域知识或实时数据(如“基于2024年Q2财报数据”)
- 效果:减少幻觉,提升专业性
自动化优化技术
自动提示工程(APE)
原理:用大模型生成Prompt变体,筛选最优解
流程:
数据收集 → 提示生成 → 评估迭代
参数调优
参数 原理 效果 Temperature 通过缩放 Softmax 输入的 logits 值,改变模型输出的概率分布 低值:输出稳定、保守(T=0.2)
高值:输出随机、创意(T=1.5)Top-K 每步生成时,仅保留概率最高的 K 个候选词,从中随机采样 低值:严谨性强(K=10)
高值:多样性高(K=50)Top-P 动态累积概率,仅保留概率总和达到阈值 P 的最小词集合
如:“喝茶”(0.6)、“看书”(0.3) 累积达 90%,则仅保留两者低值:聚焦高概率词(P=0.75)
高值:包容长尾词(P=0.95)
思维链(Chain-of-Thought,CoT)
通过引导大模型分步展示推理过程来提升复杂任务性能的提示工程技术。其核心在于将问题拆解为逻辑连贯的中间步骤,模拟人类逐步解决问题的方式。
- 传统方式 :输入→输出(易因任务复杂度高而错误)
- CoT方式 :输入→推理链→输出(通过中间步骤降低错误率) 主流策略 Few-Shot CoT(少样本引导):在提示中提供包含详细推理步骤的示例(如数学题的解题过程),引导模型模仿其逻辑 Zero-Shot CoT(零样本激活):仅添加触发词(如“Let’s think step by step”),即可激活模型的推理能力 思维树(Tree of Thoughts, ToT):将单一路径的 CoT 扩展为多路径搜索(如广度优先、深度优先),通过评估不同推理分支选择最优解
检索增强生成(Retrieval-Augmented Generation,RAG)
在生成答案前,先从外部知识库中检索相关证据,再基于检索结果生成更准确、可靠的回答。 RAG 分为 离线索引(Indexing) 和 在线查询(Query) 两阶段:
- 离线索引阶段 :
- 文档分块 :将长文本切割为语义段落(如按段落或固定字符数)。
- 向量化 :使用嵌入模型(如BERT、BGE)将文本转换为向量。
- 存储 :向量存入高效索引数据库(如FAISS、Milvus)。
- 在线查询阶段 :
- 用户提问向量化 :将问题编码为向量。
- 语义检索 :从向量库中匹配最相关的文本块(Top-K)。
- 增强生成 :将检索内容与原始问题拼接,输入大模型生成答案
模块 功能 技术工具 知识库(Knowledge Base) 存储结构化/非结构化数据(如维基百科、企业文档),可自建或依赖第三方 Elasticsearch、Pinecone 向量数据库 检索器(Retriever) 从知识库中筛选相关文档 DPR(双塔模型)、BM25 算法 生成器(Generator) 基于检索结果生成自然语言回答 BART、GPT-4、Llama 2
Prompt Engineering 解决“如何问”, RAG 解决“答什么”
智能体(Agent)
软件程序(如聊天机器人)、硬件设备(如工业机器人)或混合系统等具备自主性、反应性、主动性和学习能力,能够感知环境、自主决策并执行行动以实现特定目标的实体。
- 感知模块:计算机视觉(目标检测)、NLP(语义解析)、传感器网络等收集环境数据(视觉、语音、文本等)。
- 决策模块:大语言模型(如GPT-4、Claude 3)充当“大脑”,进行任务分解与推理。
- 记忆模块
- 短期记忆:存储会话上下文(如ChatGPT的对话历史)。
- 长期记忆:向量数据库(如Pinecone)存储历史数据,支持快速检索。
- 行动模块
- 工具调用:执行API操作(如支付接口调用)、控制硬件(如机械臂抓取)。
- 多模态能力:生成图像(DALL-E)、执行代码(Python脚本)。
- 通信模块:自然语言对话(客服Agent)、多Agent协作协议(如供应链协同)
MCP
MCP(Model Context Protocol,模型上下文协议)是由 Anthropic 提出的开放标准协议,旨在标准化LLM与工具交互接口,解决 AI 模型(如大语言模型 LLM)与外部工具、数据源和服务之间的无缝集成问题,被比喻为“AI 应用的 USB-C 接口”

- Host:the AI-powered app — Claude Desktop,Cursor 等智能体工具
- Client:lives inside host — 当智能体需要某种服务时,通过Client 连接 Server,Client 负责将自然语言指令转化为结构化请求(JSON-RPC 格式)。
- Server:smart adapter for a tool or app — 提供某种服务,如 GitHub MCP server 可以将 “list my open pull requests” 转化为 GitHub API call.
MCP 定义 Client 和 Server 如何通信(JSON-RPC 2.0 )
Sampling(采样) 是一种允许服务器通过客户端间接调用语言模型(LLM)生成内容的核心机制,旨在赋予服务端智能决策能力,同时保持用户对数据安全和模型使用的控制权
Tools
springAI
由 Spring 官方推出的 专为 Java 开发者设计的 AI 应用开发框架,旨在简化 AI 模型集成、统一接口调用,并与 Spring 生态系统深度整合
| 模块 | 功能 | 应用场景 |
|---|---|---|
| AI 模型集成 | 支持文本生成、图像生成、嵌入向量、语音识别等能力 | 调用 GPT-4 生成代码、DALL-E 生成图像 |
| 向量数据库支持 | 集成 Pinecone、Redis、PGVector 等 10+ 向量数据库,支持语义搜索与相似度计算 | 构建企业知识库问答(RAG) |
| 提示词工程 | 动态模板构建,支持变量替换(如 {userName}) | 定制客服机器人回复模板 |
| 函数调用 | AI 可调用本地 Java 方法(如查询数据库、API) | 实时获取天气数据并生成回答 |
| 对话记忆管理 | 存储聊天上下文(如 InMemoryChatMemory) | 实现多轮连贯对话的智能助手 |
| 检索增强生成(RAG) | 从文档(PDF/Markdown)提取知识,结合向量检索生成精准答案 | 医疗客服基于病历库回答患者问题 |
Ollama
Ollama 是一个开源的大型语言模型(LLM)本地运行框架,旨在简化在个人设备(如笔记本电脑、工作站)上部署和管理大模型的过程。用户无需依赖云端服务,即可通过命令行或 API 在本地运行模型(如 LLaMA、Mistral、DeepSeek 等)
Langchain
LangChain 是一个开源的大语言模型(LLM)应用开发框架,旨在简化将大型语言模型(如 GPT、Claude 等)集成到复杂应用中的过程。它通过模块化设计,帮助开发者连接模型、外部数据源、工具和记忆系统,构建端到端的智能应用。
| 组件 | 作用 | 示例场景 |
|---|---|---|
| Chains(链) | 将多步骤任务串联成工作流 | 用户提问 → 生成 SQL → 执行查询 → 结果转自然语言回答 |
| Agents(代理) | 动态调用外部工具(搜索、API、计算器) | 股票分析:搜索数据 → 计算趋势 → 生成报告 |
| Memory(记忆) | 管理上下文(短期/长期记忆) | 聊天机器人记住用户偏好,实现多轮个性化对话 |
| Indexes(索引) | 连接外部数据源(文档、数据库) | 从 PDF 中提取法律条款并生成摘要 |
| Tools(工具) | 集成第三方服务(Google 搜索、Wolfram Alpha) | 调用天气 API 回答“是否需要带伞” |
Dify
Dify 是一款开源的大语言模型(LLM)应用开发平台,融合了后端即服务(BaaS)与 LLMOps(大模型运维)理念,旨在帮助开发者与企业快速构建、部署和管理生成式 AI 应用。
| 层级 | 核心组件与技术栈 |
|---|---|
| 应用交互层 | React + Next.js 前端,支持可视化编排与调试。 |
| 服务编排层 | Flask API + Celery 异步任务队列,集成 RBAC 权限控制。 |
| 模型运算层 | 统一模型网关、RAG 管道、混合检索引擎。 |
| 数据基础层 | PostgreSQL(元数据)、Milvus/Weaviate(向量库)、Redis(缓存)、S3(文件存储)。 |