大模型技术栈必修：14个核心概念一次讲透

1. 为什么你需要搞懂这14个概念？——先聊聊大模型技术栈的底层逻辑

如果你最近开始接触大模型，大概率会被一串名词搞得头疼：Token、Embedding、Transformer、注意力机制、预训练、微调、Prompt、上下文窗口、RAG、Agent、多模态、量化、蒸馏、推理优化……每个词单独看好像都能搜到解释，但拼在一起就像天书。更难受的是，很多教程只讲单个概念，不讲概念和概念之间怎么串起来，结果你学完还是不知道：模型为什么“懂”人话？微调和RAG到底怎么选？部署一个能用的应用到底要动哪些环节？

我之前带过不少新人，也帮几个团队做过大模型落地项目，最大的体会是：大模型从来不是“一个模型”那么简单，而是一整条从数据处理、模型训练到推理部署的技术栈。标题里的14个核心概念，基本覆盖了这条链路上最常被提到、也最容易混淆的节点。把它们拆开看，每一个其实都不难；难的是先建立一张“地图”，知道自己站在哪儿，前面还有哪些站。

这篇指南就是干这个用的。我会按实际工作中接触到的顺序来讲：先讲输入侧（Token、上下文窗口、Embedding），再讲模型内部和训练侧（注意力机制、Transformer、预训练、微调、对齐），然后是应用侧（Prompt、RAG、Agent、多模态），最后是优化部署侧（量化、蒸馏、推理优化）。每个概念我都会说清楚四件事：它是什么、要解决什么问题、和其他概念怎么连接、实操中最容易踩什么坑。

这套内容适合谁？如果你刚入门大模型，只有模糊的概念，看不懂技术文章里的术语，那你可以把它当“导航地图”。如果你已经能调接口、能写Prompt，但对底层原理和工程选型还一知半解，这里面的对比表和踩坑经验也能帮你补上结构。不管你是做开发、做产品，还是单纯想搞清楚大模型到底怎么工作，花半小时过一遍，后面再去看代码和论文都会顺很多。

2. 从输入到输出的第一站：分词、Token与上下文窗口

2.1 Token：大模型读文本的最小单位

大模型读的不是完整的文字，而是切成一个个小片段的Token。你可以把Token理解成“字词积木”：英文里一个Token可能是一个单词，也可能是一个词根；中文里可能是一个字，也可能是一个词，还可能是半个字。模型在做推理时，其实是在一个Token一个Token地预测下一个Token是什么。

我第一次接触这个概念时，最大的误区是以为Token和“字符”差不多。后来用分词器一测才发现，一个英文单词可能被拆成两三个Token，一个中文字也可能对应0.5个左右的Token。这直接影响成本计算，因为无论是训练还是调用API，基本都是按Token计费的。比如你写了一段2000字的文章，换算成Token可能比直接用字数估算高出不少，月底核算成本时就容易翻车。

分词器（Tokenizer）的作用就是把原始文本转换成一串Token对应的ID。不同的模型有不同的分词器，分词规则也有差异。比如有些分词器对空格、标点、数字的处理方式和你想的不一样，“GPT-4”这种带连字符的文本，可能会被拆成好几个Token。如果你在做中文场景的项目，一定要专门做一次分词测试，别照搬英文经验。

2.2 分词器怎么工作？中文场景的几个坑

分词器通常先用Byte-Pair Encoding（BPE）这类算法，把词频统计和字节级编码结合起来。简单说，它会先看语料里哪些字符组合出现得最频繁，然后逐步合并成更大的Token。这样既能覆盖常见词，又能处理没见过的词。

中文场景有几个实际坑。第一，中文分词没有一个绝对正确的标准，“南京市长江大桥”这种歧义句，模型不关心它到底怎么切，它只需要把字符片段编码成ID。第二，中文字符和英文字母混排时，Token数量会膨胀，比如“我今天去了Beijing”看起来很短，实际转换后Token可能比纯中文还多。第三，特殊符号和表情符号会占用额外Token，有些表情甚至一个就顶四五个汉字。

我建议所有做中文NLP项目的人，开工第一天就把你常用的文本段跑一遍分词，把Token数量记录下来，心里有个底。否则后面做上下文管理、成本预估、性能压测时，总感觉哪里对不上。

2.3 上下文窗口：模型的“工作记忆”边界

上下文窗口（Context Window）指的是模型一次能“记住”的Token总数，包括输入文本和模型生成的输出。当前主流模型的上下文窗口从几千Token到几万Token不等，有些已经到百万级。但窗口大不代表模型真的会“重点关注”所有内容，后面我会讲到注意力机制，它决定了模型在长文本里如何分配注意力。

上下文窗口是硬约束。你给模型发的Prompt加上历史对话，总Token数不能超过窗口上限，否则会被截断。很多人在做长文档问答时会发现，明明把几万字都塞进去了，模型还是答错。这是因为当窗口非常大时，注意力会被稀释，模型可能“忘掉”中间部分的内容，或者过度关注开头和结尾。这叫“大海捞针”问题，后面在推理优化里还会遇到。

所以实践中的第一原则不是“能不能塞下”，而是“怎么塞得合理”。把关键信息放到Prompt的开头和结尾附近，对长文档做分段检索而不是全文灌入，都是更可靠的做法。

2.4 为什么说Token直接决定你的成本与上限

Token这个概念看起来简单，但它决定了三件事：成本、速度、效果上限。

成本很好理解，现在主流的商业大模型API基本都是按输入Token和输出Token分别计费。输出Token通常更贵，如果你让模型生成长篇内容，成本会肉眼可见地涨。速度方面，模型生成的速度单位是“每秒多少Token”，输出越长，用户等待越久，并发能力也会被拉低。效果方面，如果某个任务需要长上下文，你的Token预算就会吃紧，可能不得不牺牲历史对话长度或文档细节。

我做过一个真实对比：同一套客服系统，调整Prompt压缩历史对话后，API费用下降了约四成，响应速度也快了不少。Token管理不是“省字”那么简单，它是一道贯穿数据准备、Prompt设计和推理部署的全局优化题。

3. 模型“理解”世界的基础：Embedding与注意力机制

3.1 Embedding：把文字变成向量

Embedding是把文字、图片、音频等离散信息映射成稠密向量的过程。你输入一段话，模型会把它转换成一个几十到几千维的浮点数数组。向量的几何意义很奇妙：语义相近的文本，它们的向量在空间里也更靠近。比如“猫”和“猫咪”的向量距离，通常比“猫”和“汽车”的距离近得多。

我第一次直观感受到这个特性，是用一个现成的Embedding接口做语义搜索。我给“我今天心情不好，想辞职”和“工作中遇到挫折怎么办”这两句话算相似度，结果分数很高。这说明Embedding不是真正理解语义，而是把“共现模式”压缩成了空间关系。但正是这种压缩能力，让很多应用变得可行，比如推荐系统、知识库检索、聚类分析。

在Transformer架构里，Embedding还会叠加位置编码，用来表示Token在句子里的先后顺序。没有位置信息，模型就会把“我打你”和“你打我”当成同一个意思，这在逻辑上没法接受。

3.2 注意力机制：模型如何抓取重点信息

注意力机制（Attention）是Transformer的核心创新。它的思路很直白：给定一个查询（Query），模型要在所有“候选信息”（Key-Value）里，有选择地提取高相关部分。你可以把它想象成开会时做笔记：你不可能把每个人说的每个字都记下来，只能根据当前话题，重点记录相关发言，忽略无关内容。

注意力机制通过计算Query和每个Key的相关性分数，再用Softmax把分数变成概率权重，最后用权重加权求和Value，得到关注后的信息表示。这样模型在处理“小明因为迟到，错过了重要的考试”时，能知道“小明”和“错过考试”强相关，而不是机械地把每个词等量处理。

注意力机制的出现，解决了两大问题。一个是长距离依赖：循环神经网络处理长句时，越早的信息越容易被“遗忘”，注意力机制让任意两个位置的Token可以直接建立关联。另一个是并行计算：注意力计算可以矩阵化，不需要像循环网络那样一步一步串行执行，这让训练速度大幅提升。

3.3 Self-Attention与Transformer的关系

Self-Attention（自注意力）指的是序列内部的Token互相计算注意力，让每个Token的表示都融合整个序列信息。Transformer则是使用自注意力作为基础模块的神经网络架构，最初用于机器翻译，后来成为几乎所有大模型的底座。

很多人混淆“Transformer”和“大模型”，其实大模型通常指在超大规模数据集上预训练出来的Transformer模型。Transformer由编码器（Encoder）和解码器（Decoder）两部分组成，早期模型有的只用编码器（如BERT），有的只用解码器（如GPT）。现在主流的对话式大模型大多采用解码器架构，因为它在“逐个Token生成”的推理场景里更自然。

为什么说解码器架构更受欢迎？因为大模型的核心能力是“续写”：给定前面的Token序列，预测下一个Token的概率分布，然后把新Token拼回去继续预测。这个自回归过程天然适合对话和文本生成。Transformer把“预测下一个Token”这件事做到了极致，所以成了技术栈的地基。

3.4 实操中怎么利用Embedding做语义检索

Embedding在实际中最常用的场景是语义检索。传统关键词搜索匹配的是字面，语义检索匹配的是“意思”。比如用户搜“车胎没气了”，关键词搜索可能匹配不到“轮胎漏气”，但语义检索能通过向量距离找到相关内容。

我搭过一个简单的知识库问答系统，流程是这样的：先把文档切成小段，每段用Embedding接口转成向量，存进向量数据库；用户提问时，把问题也转成向量，然后在库里做相似度搜索，找出最相关的几段；最后把这些片段作为上下文，连同Prompt一起发给大模型生成答案。

这里面有几个细节要特别注意。第一，文本切片的粒度非常关键，切太短会丢失上下文，切太长又容易混入无关内容，我一般按语义段落切，控制在几百字以内。第二，Embedding模型的选择会影响检索质量，通用模型和垂直领域微调过的模型差距可能很大。第三，向量数据库的索引类型和距离函数也要选对，余弦相似度是最常用的，但在某些业务里内积或欧氏距离效果更好。这些细节看起来小，但它们决定了整个RAG系统的上限，后面讲RAG时还会展开。

4. 三大训练范式：预训练、微调与对齐

4.1 预训练：让模型学会语言规律

预训练（Pre-training）是在海量文本上，通过预测下一个Token等自监督任务，让模型掌握语言规律和世界知识的过程。你可以把它理解成“通识教育”：学生读了很多很多书，虽然没有专门学某个专业，但已经具备了阅读、推理和常识判断的基础。

预训练的目标函数看起来很简单：给定前面的Token，最大化下一个Token的概率。但把它用到几十万亿Token的数据上之后，模型会出现很多意想不到的能力，比如上下文学习、代码理解、多步推理。这些能力不是刻意设计的，而是数据规模带来的“涌现效应”。这也是为什么很多人说大模型“神奇”的原因之一。

预训练的工程挑战非常大。为了高效训练，研究人员会把数据切成长序列，采用混合精度训练、梯度累积、分布式并行等技巧。数据质量更是重中之重，如果数据里混入大量重复、低质或有害内容，模型就会学到错误模式。业界有一句话叫“数据决定上限”，预训练阶段尤其成立。普通从业者很少需要从零预训练大模型，但理解这一点对后面选型微调很有帮助：模型本身的“底子”决定了它后续的能力上限。

4.2 微调：让模型变成领域专家

微调（Fine-tuning）是在预训练模型的基础上，用特定领域数据继续训练，让模型在某个任务或知识领域表现更好。比如你有一个医疗问答模型，基础模型虽然懂很多，但医疗术语和病例表达不够专，你收集一批医疗QA数据，在预训练权重上继续做监督训练，模型就会“偏科”到医疗方向。

微调在实操里最关心两件事：数据和超参数。数据方面，微调数据通常需要人工标注，质量比数量更关键。我见过有人准备了一万条低质量数据，效果反而不如一千条高质量数据。超参数方面，学习率是最容易出问题的点，设置太大容易破坏预训练权重，设置太小又微调不充分，一般建议从较小的值开始试，比如1e-5到5e-5。

现在还有一种“参数高效微调”的玩法，比如LoRA，它不更新全部模型参数，只训练一小部分低秩矩阵。这样做的好处是用极少的显存和训练时间，就能达到接近全量微调的效果。我现在的项目几乎默认用LoRA，适配不同业务场景时特别方便，后期切换任务只需要换一个LoRA权重文件，不用备份完整模型。

4.3 对齐：让模型“说人话”

预训练和微调解决的是“能力”问题，对齐（Alignment）解决的是“意愿”问题。基础模型只知道续写最可能的文本，但它不会考虑用户想听什么，也不关心答案是否安全。对齐的目标是让模型遵循人类意图、价值观和安全规范。

目前最经典的对齐方法是RLHF（基于人类反馈的强化学习），流程大致分三步：先训练一个奖励模型，学习判断哪些回答更符合人类偏好；然后让大模型生成回答，用奖励模型打分，再用强化学习算法（如PPO）更新策略，让模型越来越倾向于生成高奖励的回答。后来还出现了DPO等简化方法，直接基于偏好数据优化，不用单独训练奖励模型。

对齐不是修修补补，而是整个产品能不能安全落地的关键。我记得有个项目在测试时没做充分的对齐，模型被用户用几句“角色扮演”就带偏，输出了不该输出的内容。后来我们重新组织了对齐数据，专门覆盖这些恶意场景，才把风险压下来。这块内容涉及的数据质量和安全测试，比模型本身更值得投入精力。

4.4 选预训练、微调还是RAG？一张表说清楚

经常有人问我：业务上线到底要不要微调？其实应该先问另一个问题：你的需求是“让模型知道新知识”，还是“让模型学会某种风格/能力”？前者优先考虑RAG，后者才适合微调。两者也可以结合，先用RAG检索事实性信息，再通过微调让模型掌握特定任务的输出格式或语气。

如果业务数据只有几千条，且内容经常更新，RAG几乎总是更优选择，因为微调后的模型知识是“固定”的，想改知识还得重新训练。但如果你发现模型生成内容的“味道”不对，风格始终调不过来，那微调就是最直接的手段。

5. 让大模型“接上地气”的三板斧：RAG、Agent与多模态

5.1 RAG：检索增强生成，把知识库装进答案

RAG（Retrieval-Augmented Generation，检索增强生成）是我目前最推荐企业优先落地的技术方向。它的核心思想很简单：大模型不是万能的，但你可以先从一个外部知识库里检索到相关内容，再把这些内容附加到Prompt里，让模型基于这些参考信息生成答案。

RAG的价值在于解决“幻觉”和“知识过时”问题。基础模型训练数据有截止时间，新政策、内部制度、产品手册都覆盖不了。RAG相当于给模型配了一个可以随时更新的“外置大脑”，只要换检索库里的文档，不需要重新训练，回答就会跟着变化。

一个标准的RAG流程包含五个环节：文档加载、文本切分、向量化、向量检索、生成回答。最容易翻车的两个点是切分和检索召回。切分如果破坏句子完整性，检索质量就会下降；检索如果召回到不相关的片段，答案就会“一本正经地胡说八道”。我踩过的坑是，一开始直接用固定长度切分，导致很多段落被腰斩，后来改成按标题和段落结构切分，再辅以一定重叠，效果立刻好了很多。

检索之后的重排（Rerank）也值得加。第一轮向量检索返回比如20个候选片段，用一个重排模型对它们和问题的相关性重新排序，只把Top5喂给大模型，这样可以有效减少噪声。加了重排之后，我实测问答准确率能提高五到十个百分点。

5.2 Agent：让模型学会调用工具和规划

Agent（智能体）是把大模型从“聊天机器人”升级成“能干活的小助手”的关键。它的核心是让模型掌握两种能力：一是根据用户目标拆解成多步计划，二是调用外部工具（比如搜索、计算器、API、数据库）来完成任务。

举个例子，用户问“帮我统计上个月北京地区所有门店的销售总额，并生成一份分析报告”。如果只有大模型，它只能给你一个通用回答模板。但有了Agent，模型会先决定要调用数据接口，拿到销售明细后，再用代码解释器做聚合计算，最后用模板生成报告。整个过程不是我们预先写死的规则，而是模型基于Prompt和工具描述动态决策出来的。

Agent的工程难点在“规划可靠”和“错误恢复”。模型偶尔会自作聪明调用错误的工具，或者陷入循环。我的经验是，给每个工具写非常清晰的描述，并在Prompt里明确告诉模型“不确定时不要瞎猜”。同时，外部流程要设置最大调用轮次和超时机制，防止Agent在一个任务上“空转”十分钟。现在很多框架（比如某开源Agent框架）帮我们封装了工具调用循环、记忆管理和多智能体协作，但底层概念是相通的：模型为主，工具为辅，流程兜底。

5.3 多模态：图像、声音、视频一把抓

多模态大模型指的是能同时处理文本、图像、音频、视频等不同类型数据的模型。传统上，每个模态都有自己的模型和管道，多模态模型则用统一的Transformer结构把这些模态拉到一个空间里处理。

普及率最高的能力是“看图说话”和“图文理解”。你可以让模型识别一张截图里的表格，提取关键数值，也可以让它根据一张产品图片生成文案。多模态模型通常先把图像分割成小块（Patch），再通过视觉编码器转成Token一样的向量序列，和文本Token拼在一起送给Transformer处理。所以多模态模型本质上还是Token的接龙游戏，只是把“词”扩展成了“图像块”和“声音片段”。

实操中有个容易忽略的问题：多模态模型虽然能看图，但对低分辨率、小字体、复杂图表的理解仍然有限。我在处理财务报表截图时，经常需要先把图片放大或切分，再让模型逐块识别，最后合并结果。另外，多模态推理的Token消耗比纯文本高很多，因为一张图可能被编码成几百个视觉Token，你做成本预算时要留足余量。

5.4 三者的组合拳：一个真实的客服项目是如何落地的

我们之前给某企业做一个售后客服助手，需求是要能回答产品使用问题，还要能根据用户描述识别故障原因，并给出处理建议。单靠一个模型很难干活，最终方案是RAG、Agent和多模态组合起来。

流程是这样的：用户先发一张设备故障照片和文字描述。多模态模型先识别照片里异常的部分，生成结构化的“图像描述”。RAG系统根据文字描述+图像描述，在企业维修手册里检索相关内容。Agent负责判断用户的问题属于“咨询”还是“报修”，如果是报修，再调用CRM接口创建一个工单，并把维修建议整理成标准话术返回。整个流程看起来复杂，但在Agent框架里只需要把各模块包装成工具，让模型根据用户输入动态调度。

落地之后我最大的体会是：多模态负责“看懂”，RAG负责“找到”，Agent负责“做对”，三者不是竞争关系，而是各司其职。如果只用一个模型硬扛所有需求，效果大概率是一团乱麻。把任务拆解到合适的技术组件上，才是做应用的正确姿势。

6. 性能与部署关键词：量化、蒸馏与推理优化

6.1 量化：压缩模型，换GPU内存

量化（Quantization）通俗讲就是降低模型参数的数值精度。神经网络参数原本用16位浮点数甚至32位存储，量化后改成8位、4位整数，模型体积和内存占用会大幅下降。比如一个70B的模型，FP16权重就需要约140GB显存，单张顶级GPU都放不下；量化到4位后，体积缩小到约35GB，消费级显卡也能勉强跑起来。

量化的原理是“用更少的比特近似原来的数值”。最直接的做法是把权重数值映射到整数范围，推理时再还原。实际操作中，有训练后量化（PTQ）和量化感知训练（QAT）两条路。PTQ不需要训练，方便快捷，但可能带来明显精度损失；QAT在训练阶段就模拟量化误差，精度更好，但成本高。

我的建议是：对效果要求高的场景，优先选8位量化，精度损失通常很小；4位量化适合本地部署或中小并发业务，但一定要用真实数据做效果评测，不要只看模型大小。不同框架的量化实现有差异，同类模型在不同框架下跑相同的精度测试，结果可能差不少。

6.2 蒸馏：用小模型模仿大模型的“脑回路”

知识蒸馏（Distillation）的目标是让一个小模型学会大模型的输出规律，甚至在某些场景里达到接近大模型的效果。它比量化的思路更“柔”：不是压缩参数，而是“师徒传承”。

具体做法是拿大模型对大量样本生成答案，把这些答案（包括概率分布）作为软标签，训练一个小模型去拟合。大模型输出的概率分布里包含了比硬标签更丰富的信息，比如“猫”和“老虎”的相似度高于“猫”和“汽车”，小模型学到这层关系后，泛化能力会更强。

蒸馏在推理场景里非常实用。7B的模型经过蒸馏之后，也许能达到70B模型七八成的效果，但推理成本可能只有十分之一。我做线上服务时经常这样组合：白天高峰流量用蒸馏后的小模型应付大部分普通问题，遇到复杂问题再请求大模型，这样既省钱又保证质量。

不过蒸馏也有前提：你没有那个“大模型老师”不行。通常我们会先用商用API生成蒸馏数据集，但这涉及数据安全和成本问题。合规的做法是自建足够强大的模型做老师，生成的样本再清洗过滤。

6.3 推理优化：从KV Cache到vLLM

推理优化是部署环节的重头戏。大模型生成是逐个Token自回归的，每次计算新Token时，都需要用到前面所有Token的注意力信息。如果每次全部重算，浪费巨大。KV Cache就是把前序Token的Key和Value缓存下来，避免重复计算。

KV Cache听着简单，但显存消耗非常可观。长对话和历史很长时，KV Cache甚至可能占到显存一半以上。后来出现了PagedAttention，思路类似操作系统的虚拟内存分页，把KV Cache按块管理，减少碎片和显存浪费。基于这个技术的推理框架（比如vLLM）在场景长文本、高并发的服务中，吞吐量提升非常明显。

再往后，还有各种量化加速、连续批处理、前缀复用等手段。我在压测时发现，同一模型在不同推理框架下的吞吐量可以相差好几倍。所以做部署选型时，不能只看模型本身，还要把推理引擎考虑进去。我的建议是先用真实业务流量做压测，再决定用哪个框架。不要盲目追求“最强”，够用、稳定、好排查才是关键。

6.4 部署时如何平衡速度、精度和成本

部署大模型本质上是在做一道多目标优化题。效果、速度、成本三者互相制约，你需要根据业务场景确定优先级。

我给出一个比较务实的平衡策略表，是根据多个项目经验总结出来的，可以参考：

还有一个经常被忽略的维度是“冷启动”。如果业务流量是波动的，你可以把服务配置成自动扩缩容，闲时缩容到零，忙时再拉起实例。现在很多云平台支持弹性GPU实例，按秒计费，能省下一大笔成本。部署不是“一次配完”，而是要持续观察监控指标，随时调整策略。

7. 从概念到实践：一条完整的学习路线与踩坑记录

7.1 三个月的进阶路线怎么安排

只看概念不动手，等于白学。我给你一条亲测有效的三个月进阶路线，前四周打基础，中间四周做应用，后四周做部署。

第一个月：先理解Token和上下文窗口，下一个人能跑的分词器，把你常用的文本都拆一遍。接着跑通一个大模型本地部署，8B量级就好，用官方推理脚本生成几句话，感受一下什么叫做“自回归”。同时把注意力机制在草稿纸上画一遍，不需要推公式，但要知道Q、K、V分别代表什么。

第二个月：开始做RAG。选一个你熟悉的领域，比如产品手册，准备几十篇文档，搭建一个离线问答系统。这个阶段重点练“文本切分”和“检索效果评估”，你可以用100道自己出的题目做评测，看检索Top5的命中率有多少。然后再试着用Agent框架包装一个“查询天气”或“查数据库”的小工具，体会模型如何调用API。

第三个月：做量化和推理优化。把第二个月的模型做8位量化或4位量化，对比回答效果和推理速度。然后换一个支持连续批处理的推理框架，压测并发数和每秒吞吐量。如果条件允许，再用LoRA微调一个特定风格的问答模型，记录训练集大小、Loss、生成效果之间的关系。

三个月后，你再看那些之前觉得高深的概念，会发现它们都变成了工具箱里的零件。

7.2 理论学习之外，动手复现必须盯住的细节

动手复现时有很多细节是教程不会写的。第一个是随机种子一致性。每次跑模型前固定随机种子，否则两次训练结果会差很多，根本没法调试。第二个是数据格式，不同模型对训练数据格式的要求非常严格，对话模板、分隔符、特殊Token都要保持一致，差一个标签效果就会“断崖式下跌”。第三个是显存监控，训练时不要只盯着Loss，还要看显存占用是否稳定，一旦显存溢出，说明序列长度或Batch Size要调小。

评估也是不能省的一步。很多人跑完微调只看了Loss值就说“效果不错”，但实际上Loss下降不代表答案正确。我一般会在训练集之外专门保留一个百级别的评测集，从准确性、完整性、格式规范性三个维度人工打分。这个评测集在整个项目周期里保持不变，才能量化对比不同版本的效果。

还有一个小建议：任何改动都要做“对照实验”。如果你想试一个新的切分策略，先在同一个数据集和同样的模型上，只改切分逻辑，跑一遍对比，不要同时换Prompt、换Embedding、换向量库，否则出了问题根本定位不到。

7.3 最后分享几个我实际踩过才发现的大坑

第一个坑：上下文窗口不是越大越好。我们曾有一个长文档问答项目，客户非要把整本书塞进上下文，结果模型经常“断片”。后来我们改成利用RAG分段检索，效果反而更好。上下文大只是“可能性”，不是“保证”，关键信息要出现在注意力足够覆盖的位置。

第二个坑：Embedding模型和生成模型不是绑定关系，但选型错误会让RAG系统脆弱不堪。我们一开始用了一个通用Embedding模型，在专业术语很多的场景里，检索召回一团糟。后来换成在这个领域语料上微调过的Embedding模型，同样的查询和文档库，命中率直接翻倍。

第三个坑：量化后的精度评测不能只看单条样例。我试过一个模型量化后抽查几条对话觉得没问题，一压测才发现，在长文本和复杂指令场景里，答案稳定性下降很明显。后来我们的量化上线流程固定为：先跑100题评测集，再跑一轮长上下文压力测试，全过才允许上生产。

第四个坑：推理框架的兼容性。不同框架支持的操作符不完全一致，模型量化后某些算子可能不被支持，导致推理报错。建议在上线前，用完整的测试脚本跑一遍，包括正常文本、超长文本和并发请求，而不是只跑个Hello World。

说了这么多，其实大模型技术栈并不神秘。你不需要先啃完所有论文再动手，反而应该先动手，遇到问题再回头补概念。那14个概念就是你的地图，把地图拿在手边，一个一个去验证，很快你就能从“听过名词”变成“能讲明白、能搭起来、能排错”的人。这也是我写这篇指南最想看到的结果。