【建议收藏】大模型技术术语通俗解读：Token、Embedding、微调等概念小白也能懂

EnjoyEDU

1599人浏览 · 2025-09-15 09:42:09

EnjoyEDU · 2025-09-15 09:42:09 发布

在大模型技术快速普及的今天，官网文档、技术讨论中频繁出现的专业术语常常让新手望而却步。本文将用生活化的语言拆解这些核心概念，不仅帮你理解“是什么”，更能搞懂“为什么用”“怎么用”，让你在使用大模型时更有底气，甚至能看懂技术方案背后的逻辑。

1、 Token（词元）：大模型“认字”的最小单位

不管是用ChatGPT聊天，还是调用大模型API做开发，“Token”都是绕不开的关键词——尤其是涉及费用时。几乎所有大模型厂商的API定价都遵循按Token数量计费的规则，常见单位是“1M Token”（即100万个Token）。比如OpenAI的API会细分不同类型的Token：处理文字的文本Token、生成图片的图像Token、转写语音的音频Token，调用时按实际消耗的对应Token数量扣费。

这里要特别注意：API按Token计费和ChatGPT订阅制是两回事。前者像“按用量付水费”，用多少算多少；后者像“包月会员”，固定费用内可不限次数使用（部分功能有上限），两者计费逻辑完全不同。

到底什么是Token？

简单说，Token就是大模型能理解的“最小语言单元”，相当于我们看书时的“一个个字或词”。当你输入一句话，模型不会直接处理完整文本，而是先让分词器（Tokenizer） 把文本拆成一个个Token。不过，不同语言的Token拆分规则不一样：

中文里，大多是一个汉字或一个常用词算一个Token，比如“苹果”就是1个Token，“人工智能”可能拆成“人工”“智能”两个Token；
英文里，Token常是单词的一部分，比如“ChatGPT”会拆成“Chat”“G”“PT”3个Token，“unhappiness”可能拆成“un”“happiness”——因为模型的“词表”里没有这些完整单词，只能拆成更小的“子词”来识别；
对大模型而言，分词是处理文本的“第一步”，拆出来的Token质量，直接影响后续理解和生成的准确性。

为了让你更直观理解，我们用表格展示文本拆分后的Token及对应的ID：

输入文本	Token拆分结果（含Token ID，与后续Embedding直接关联）	Token数量
我喜欢吃苹果	[“我”, “喜欢”, “吃”, “苹果”] → 对应ID [10534, 23512, 876, 4312]	4个
ChatGPT	[“Chat”, “G”, “PT”] → 对应ID [1234, 567, 890]	3个
机器学习很有趣	[“机器”, “学习”, “很”, “有趣”] → 对应ID [5210, 6389, 201, 9456]	4个

小提醒：表格里的Token ID是示例值，但真实场景中，每个Token的ID都是固定的——由模型的“词表（vocabulary）”提前定义，不会随机生成。就像字典里每个字都有固定页码，Token ID就是Token在“模型字典”里的“页码”。

Token ID：连接Token和Embedding的“桥梁”

很多人会疑惑：Token ID只是一串数字，有什么用？其实它是大模型处理文本的“关键中转站”：

每个Token都有唯一的ID，这些ID直接对应模型“Embedding表”里的某一行；
后续模型要把Token转换成计算机能计算的“向量”（也就是Embedding），全靠Token ID在Embedding表里“查找到对应的向量”；
简单说：Token→Token ID→Embedding向量，这是大模型“读懂”文本的核心流程，缺了Token ID，文本就没法转换成数值信号。

2、 Embedding（嵌入）：把文字“翻译成”计算机能懂的“数字密码”

如果说Token是大模型的“文字单元”，那Embedding就是把这些“文字单元”翻译成“计算机语言”的工具。毕竟计算机看不懂文字，只能处理数字，而Embedding的核心作用，就是给每个Token分配一串“有意义的数字”（即向量）。

什么是Embedding？

你可以把Embedding理解成一张“数字字典”：它是一个[N×M]的矩阵，N代表模型词表里所有Token的总数，M代表每个Token对应的“向量维度”（也就是这串数字有多长）。比如OpenAI的两款主流Embedding模型：

text-embedding-3-small：每个Token的向量是1536维（即一串1536个数字）；
text-embedding-3-large：向量维度是3072维，比前者更“细致”。

这串数字不是随便编的——模型通过训练，让语义相近的Token拥有“相似的向量”。比如“猫”和“狗”的向量会比较接近（都属于动物），“电脑”和“水杯”的向量则差距很大。而向量维度越高，能表达的语义细节就越多：3072维的向量能区分“金毛犬”和“萨摩耶”的差异，1536维可能只能笼统识别“狗”这一类别。

通过“t-SNE可视化”工具，我们能直观看到Embedding的效果：语义相似的Token会聚集在一起，形成一个个“语义簇”，就像兴趣相同的人会凑成小圈子一样。

Token和Embedding的关系：从文字到数字的“完整流程”

很多人搞不清Token和Embedding的关联，其实它们是“前后衔接”的两个步骤。我们用“今天天气如何”这句话举例，看文本如何变成模型能处理的数值：

第一步：拆分成Token
分词器把“今天天气如何”拆成[“今天”, “天气”, “如何”]，并分配Token ID：“今天”→10348，“天气”→21567，“如何”→3089；
第二步：通过Token ID查Embedding表
模型拿着这三个ID，去Embedding表里找对应的向量：10348→向量v1（1536个数字），21567→向量v2，3089→向量v3；
第三步：向量输入模型计算
这三个向量被传入大模型的神经网络，模型通过计算向量之间的关系，“读懂”“今天天气如何”的语义。

这个流程可以用一句话总结：Token是“原材料”，Token ID是“提货单”，Embedding是“最终产品”——没有Embedding，模型就没法把文字变成可计算的信号。
*

补充说明：模型训练前，会先确定分词器的词表，给每个Token分配固定ID；然后Embedding表会按词表顺序初始化向量（初期是随机值，后续通过训练不断优化）。所以Token ID和Embedding向量是“一一对应”的，不会出现“一个ID对应多个向量”的情况。

为什么按Token收费？和Embedding、模型参数有关

很多人好奇：为什么大模型API要按Token收费？其实背后是“计算成本”的逻辑：

大模型的“参数”（比如GPT-3的1750亿参数）是模型的“知识储备”，但这些参数不是每次都全用上。有些模型（比如MoE架构模型）会采用“激活参数”机制——只调用和当前输入Token相关的部分参数，不用全部参数；
传统的“稠密模型（Dense）”则相反，每次计算都会调用所有参数，比如GPT-3处理一个Token，就要动用全部1750亿参数，成本很高；
而计算成本的核心取决于“输入Token数量”和“被激活的参数规模”：Token越多，需要激活的参数可能越多，算力消耗就越大；
这就是为什么按Token收费——Token数量既能反映输入的“文本长度”，也能间接体现“实际算力消耗”，是最公平的计费依据。

我们用表格对比几款主流模型的参数情况，更直观理解成本差异：

模型名称	总参数量（Total Params）	激活参数量（Activated Params）	架构类型	单Token计算成本（相对值）
GPT-3	175B（1750亿）	175B（全激活）	Dense（稠密）	高（全参数计算）
LLaMA-2-70B	70B（700亿）	70B（全激活）	Dense（稠密）	中（全参数计算，但总量少）
DeepSeek-R1	671B（6710亿）	37B（仅激活370亿）	MoE（稀疏激活）	低（仅部分参数计算）

小科普：B代表“Billion”（十亿），175B就是1750亿。MoE模型（比如DeepSeek-R1）总参数量很大，但实际激活的参数少，所以处理单个Token的成本比稠密模型低——这也是很多厂商推出MoE模型的原因，能在保证效果的同时降低使用成本。

3、上下文长度（Context Length）：大模型的“记忆上限”

你有没有遇到过这种情况：和ChatGPT聊了十几轮后，它突然“忘记”之前说过的内容？这不是模型“失忆”，而是受限于“上下文长度”——也就是模型一次能“记住”的最大Token数量。

什么是上下文长度？

简单说，上下文长度是模型在一次对话或处理文本时，能“看到”的所有Token总数（包括你的输入和模型的输出）。比如：

GPT-3的上下文长度是2K Token（约1500个中文字符），意味着你和它的对话+模型回答，总长度不能超过2000个Token；
GPT-4支持8K、32K Token，GPT-4 Turbo甚至能到128K Token（约9万字），能处理一整篇长文档（比如小说、论文）。

当你向 ChatGPT 输入一句话，比如“帮我解释一下大模型。”时，这句话会被送入大模型进行处理。模型会根据输入生成第一个 token（比如“好”），然后将原始输入和已生成的 token 作为新的输入，再生成下一个 token（比如“的”）。这个过程会不断循环：每次模型都会把用户输入和之前生成的内容一并作为新的上下文，预测下一个 token，直到生成完整回答。

上下文长度的重要性：影响模型的“理解能力”

上下文长度越长，模型能参考的信息越多，处理长文本、多轮对话的能力就越强：

写短文案、简单问答：2K~8K Token足够用；
分析长文档（比如100页PDF）、写长篇小说：需要32K以上的上下文长度；
做客服多轮对话（比如用户聊了20轮需求）：长上下文能让模型记住每一轮的细节，避免重复提问。

现在很多厂商都在提升模型的上下文长度，比如阿里云的通义千问、字节跳动的豆包，都支持超长上下文，就是为了更好地处理复杂场景。

4、提示词工程（Prompt Engineering）：让大模型“听话”的技巧

如果把大模型比作“天才学生”，那Prompt（提示词）就是“老师的指令”——好的指令能让学生发挥实力，差的指令可能让学生答非所问。提示词工程，就是研究如何设计“清晰、精准的指令”，让大模型生成符合预期的结果。

什么是Prompt？

Prompt就是你给大模型的“输入内容”，可以是一句话、一个问题，甚至一段详细的任务说明。比如：

简单Prompt：“帮我写一段介绍春天的文字”；
复杂Prompt：“假设你是小学语文老师，写一段适合3年级学生的春天主题短文，要求150字以内，包含‘桃花’‘燕子’两个元素，语言口语化，不要用复杂成语”。

后者比前者更精准，模型生成的结果也更符合需求——这就是提示词工程的核心：通过补充细节、设定角色、明确格式，减少模型的“理解偏差”。

Prompt的核心作用：引导模型“做对事”

定方向：告诉模型“做什么”，比如“写文案”“做翻译”“分析数据”；
定风格：要求模型用特定语气输出，比如“正式商务风”“口语化”“幽默风趣”；
定规则：明确输出格式或禁忌，比如“用表格呈现结果”“不要出现网络用语”；
扩功能：结合函数调用（Function Call），让模型实现复杂操作，比如“调用天气API，查询北京明天的气温，并用自然语言说明”。

新手必学的Prompt技巧

很多人觉得“提示词工程很难”，其实掌握几个基础技巧就能大幅提升效果：

给角色：让模型代入特定身份，比如“假设你是资深产品经理”“作为儿科医生”，角色越具体，输出越专业；
给示例：如果任务复杂（比如分类、改写），可以给1~2个示例，比如“把‘开心’归为‘积极情绪’，‘难过’归为‘消极情绪’，请分类‘兴奋’‘愤怒’”；
分步骤：长任务拆成小步骤，比如“第一步总结文档核心观点，第二步提炼3个关键问题，第三步给出解决建议”；
避模糊：不用“写得好一点”“详细一点”这类模糊表述，改用“字数200字”“包含3个案例”等具体要求。

比如同样是“写产品介绍”，模糊Prompt可能得到泛泛而谈的内容，而精准Prompt能让模型写出“突出卖点、打动目标用户”的文案——这就是提示词工程的价值。

5、向量库与RAG：给大模型“装一个外挂知识库”

大模型有个缺点：训练数据有“时效性”（比如GPT-4训练数据截止到2023年），而且无法实时更新新信息。而RAG（检索增强生成）技术，就是给模型“加一个实时更新的外挂知识库”，让它能引用最新、最专业的信息回答问题。

什么是RAG？

RAG的全称是“Retrieval-Augmented Generation”，核心逻辑是“先检索，再生成”：

准备知识库：把需要的资料（比如公司文档、行业报告、最新新闻）转换成Embedding向量，存入“向量库”（专门存储和检索向量的数据库）；
用户提问：用户输入Prompt，比如“2024年人工智能领域有哪些新突破？”；
向量检索：系统把用户的Prompt转换成Embedding向量，去向量库中“找最相似的向量对应的文档片段”（比如2024年AI领域的新闻、论文摘要）；
增强生成：把检索到的片段和用户Prompt一起输入大模型，模型结合这些“新信息”生成回答，而不是只靠自己的“旧知识”。

简单说，RAG让大模型从“凭记忆答题”变成“先查资料再答题”，就像学生考试时可以翻阅参考书，答案自然更准确、更新颖。

向量库：RAG的“资料存放柜”

向量库是RAG的核心组件，它的作用是“快速找到和Prompt最相似的文档”。和传统数据库（比如MySQL）不同，向量库不按“关键词”检索，而是按“向量相似度”检索——比如Prompt“AI新突破”的向量，会和“2024年AI大模型进展”“AI在医疗领域的新应用”等文档的向量更相似，向量库能快速定位这些文档。

现在主流的向量库有Pinecone、Milvus、Chroma等，很多企业会把自己的内部文档（比如产品手册、客户案例）存入向量库，再结合RAG让大模型成为“企业专属客服”“内部知识库助手”，大幅提升工作效率。

6、模型微调（Fine-tuning）：让大模型“专精某一领域”

用Prompt和RAG能解决很多问题，但有些场景下，模型还是“不够专业”——比如让通用大模型处理法律合同审查、医学病例分析，即使给了提示词、加了知识库，输出结果还是会有偏差。这时就需要“模型微调”，让大模型在特定领域“深度学习”，成为“领域专家”。

为什么需要微调

在大模型应用中，通常我们会先尝试通过 Prompt 工程 和 RAG（检索增强生成） 来引导模型完成任务。

Prompt：通过设计合理的提示词，尽可能让模型理解和执行需求。
RAG：在模型回答时结合外部知识库，增强模型的知识范围和专业性。

但是在一些场景下，即便使用了 Prompt 和 RAG，模型的性能仍然达不到预期：

模型对某些领域的专业知识理解不够深入；
模型的表达风格与业务需求有差距；
任务需要模型掌握新的知识，而这些知识在训练语料中很少或不存在。

这时，就需要在现有大模型的基础上，进行 微调（Fine-tuning）。

什么是微调

微调的核心思想是：

在大模型已经学习了大量通用知识的前提下，
通过采集并构建一个 新的训练数据集（通常是垂直领域的数据），
对模型的部分参数进行再训练，
让模型学习新的模式、知识或任务。

相比从头训练一个模型，微调的计算成本和数据需求要低得多，同时又能显著提升模型在特定场景下的效果。

7 、模型路由

在大型模型应用中，往往会存在多个在基础大模型之上微调得到的 领域专用模型。为了让用户请求能够被分配到最合适的模型，需要一个 模型路由器 来负责调度。从工程角度看，模型路由器的主要职责包括：

解析输入

对用户请求进行语义解析、分类和关键词提取。
例如：“火车站排队情况” → 属于客流/交通领域。

选择目标模型

根据用户意图和置信度，选择对应的专家模型。
若置信度较低，则回退到 通用大模型 + RAG 兜底，以避免答非所问。

控制流转

将请求转发到目标模型，并记录路由日志，便于后续追踪与优化。

结果融合

对于需要多个领域模型协同的问题（如“地铁施工对火车站客流的影响” → 涉及交通模型和施工模型），路由器负责调用多个模型并融合结果。

总结：模型路由器就像“大脑的分配中心”，决定每一个问题应该交给哪位“专家模型”处理，同时在不确定时交给通用模型兜底。和路由器的功能类似，不过 模型路由器是纯软件逻辑，它并不是硬件设备，而是部署在系统里的一个组件，用来解析用户请求 → 判断归属 → 分配给合适的专家模型 → 返回结果。

如果能够把城市里的各类数据都汇聚并打通，就能构建起一个“数字孪生”的物理世界。例如：当你准备停车时，只需要问一句：**“附近哪里有空余的停车位？周边交通情况如何？”**系统就能即时调用：

停车场数据 → 返回最近的可用车位及余量；
交通监测数据 → 告诉你周边道路的拥堵情况；
视频监控流/传感器数据 → 生成一张实时的场景图，帮助你直观了解环境；
大模型分析能力 → 对交通态势和出行建议进行解释说明。

这样，AI 不仅是回答“文字上的问题”，而是真正调动物理世界里的实时数据、传感器和图像，把虚拟智能和现实世界打通。

这正是 OpenAI 的 Sam Altman 所说的“让大模型链接物理世界”：大模型不再只是“文本对话工具”，而是成为人和真实世界之间的智能接口。

8、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】