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 EncodingBPE这类算法把词频统计和字节级编码结合起来。简单说它会先看语料里哪些字符组合出现得最频繁然后逐步合并成更大的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无需训练信息可随时换企业知识库问答、政策解读改变输出风格/格式微调让模型稳定遵循特定结构日报生成、法律文书起草强化特定任务能力微调大量任务示例提升专业度代码补全、学术摘要降低长期推理成本蒸馏用小模型模仿大模型线上高并发、端侧部署从零定制行业模型预训练微调数据量极大且方向特殊医疗、金融专属底座如果业务数据只有几千条且内容经常更新RAG几乎总是更优选择因为微调后的模型知识是“固定”的想改知识还得重新训练。但如果你发现模型生成内容的“味道”不对风格始终调不过来那微调就是最直接的手段。5. 让大模型“接上地气”的三板斧RAG、Agent与多模态5.1 RAG检索增强生成把知识库装进答案RAGRetrieval-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 部署时如何平衡速度、精度和成本部署大模型本质上是在做一道多目标优化题。效果、速度、成本三者互相制约你需要根据业务场景确定优先级。我给出一个比较务实的平衡策略表是根据多个项目经验总结出来的可以参考场景优先级推荐做法面向C端的高频对话速度成本精度小模型量化流式输出企业内部知识问答精度速度成本中大规模模型RAG重排离线批量文本处理成本精度速度蒸馏小模型批量推理个性化创作工具精度和风格最重要微调中规模模型适度量化还有一个经常被忽略的维度是“冷启动”。如果业务流量是波动的你可以把服务配置成自动扩缩容闲时缩容到零忙时再拉起实例。现在很多云平台支持弹性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个概念就是你的地图把地图拿在手边一个一个去验证很快你就能从“听过名词”变成“能讲明白、能搭起来、能排错”的人。这也是我写这篇指南最想看到的结果。 
长河君 · 2026/10/20 9:38:55 · 阅读 1.2k 大模型技术栈必修：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 EncodingBPE这类算法把词频统计和字节级编码结合起来。简单说它会先看语料里哪些字符组合出现得最频繁然后逐步合并成更大的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无需训练信息可随时换企业知识库问答、政策解读改变输出风格/格式微调让模型稳定遵循特定结构日报生成、法律文书起草强化特定任务能力微调大量任务示例提升专业度代码补全、学术摘要降低长期推理成本蒸馏用小模型模仿大模型线上高并发、端侧部署从零定制行业模型预训练微调数据量极大且方向特殊医疗、金融专属底座如果业务数据只有几千条且内容经常更新RAG几乎总是更优选择因为微调后的模型知识是“固定”的想改知识还得重新训练。但如果你发现模型生成内容的“味道”不对风格始终调不过来那微调就是最直接的手段。5. 让大模型“接上地气”的三板斧RAG、Agent与多模态5.1 RAG检索增强生成把知识库装进答案RAGRetrieval-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 部署时如何平衡速度、精度和成本部署大模型本质上是在做一道多目标优化题。效果、速度、成本三者互相制约你需要根据业务场景确定优先级。我给出一个比较务实的平衡策略表是根据多个项目经验总结出来的可以参考场景优先级推荐做法面向C端的高频对话速度成本精度小模型量化流式输出企业内部知识问答精度速度成本中大规模模型RAG重排离线批量文本处理成本精度速度蒸馏小模型批量推理个性化创作工具精度和风格最重要微调中规模模型适度量化还有一个经常被忽略的维度是“冷启动”。如果业务流量是波动的你可以把服务配置成自动扩缩容闲时缩容到零忙时再拉起实例。现在很多云平台支持弹性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个概念就是你的地图把地图拿在手边一个一个去验证很快你就能从“听过名词”变成“能讲明白、能搭起来、能排错”的人。这也是我写这篇指南最想看到的结果。