大模型入门到实战：从Transformer原理到Agent开发全景图

1. 先搞清楚大模型到底是个什么东西1.1 一次带团队后的重新出发——为什么需要系统性的学习资料两年前我刚开始接触大模型的时候完全靠碎片化学习今天看一篇讲 Transformer 的文章明天刷一个 LoRA 的教程后天再试一个 vLLM 部署的 demo。当时感觉什么都懂一点可真到做项目时发现自己连“KV Cache 为什么要省显存”都说不清楚更别提给团队搭一套完整的技术方案了。后来一次内部技术分享需要我带几个零基础的同学入门我不得不把脑子里所有关于大模型的知识重新整理成一套系统性资料。那段时间我最大的感受是大模型入门最大的门槛不是模型本身而是资料太散。官方的论文偏理论博客偏零碎教程偏工具操作缺的是一张能把原理、微调、部署、开发串起来的地图。所以这篇文章本质上是一份“整理过的学习地图”。它不打算让你从数学公式推导开始啃也不会只教你某个工具的默认参数。我会从大模型的底层本质说起一路聊到提示词工程、上下文工程、微调、本地部署、Agent 框架和评估指标路上还会穿插不少我实际踩过的坑。适合想系统进入大模型方向、但还缺一张全景图的开发者和技术管理者。1.2 大模型的三句话本质不管外面怎么包装大模型的技术本质可以用三句话讲清楚。第一句话它是一个“根据前文预测下一个词”的概率模型。你给它一段文本它内部计算的是在已出现内容的前提下下一个词表中每个词出现的概率然后选一个出来拼进去再继续预测下一个。这看起来很简单但所有看似神奇的能力——写代码、做翻译、逻辑推理——都建立在这个朴素的“自回归生成”机制之上。第二句话它的知识来自海量语料的预训练。大模型不是在推理时去查数据库而是在预训练阶段把互联网级别的文本数据“消化”进了参数里。你问它“法国的首都是哪里”它能回答不是因为它联网了而是因为“法国的首都巴黎”这个模式在训练数据里出现了无数次被模型以参数的形式记住了。第三句话它的能力边界由数据、参数规模和对齐方式共同决定。参数规模越大模型能容纳的模式就越复杂数据质量越高模型推理的上限就越高对齐方式则决定了模型是否愿意“听你的话”、是否用容易理解的方式输出。过去很多人只盯着参数数量实际做项目后发现数据和对齐的影响往往更直接。理解这三句话之后再去看那些热搜词里的“大模型微调”“大模型部署”“Agent 框架”就不会觉得是一个个孤立的知识点了。微调是在强化某一类行为部署是把模型变成服务Agent 是把模型的生成能力和外部工具接起来。底座都是那个“预测下一个词”的概率模型。1.3 为什么“大”是一个量变引起质变的问题“大模型”的“大”指的不只是参数量大。更关键的是当模型规模跨过某个阈值之后会出现一些小型模型不具备的能力业内叫“涌现能力”。比如几十亿参数的小模型可能连简单的多步推理都做不好但几百亿参数的模型能自己拆解问题、分步求解连解释都写得很清楚。我习惯用“学开车”来类比这件事。你学到某个阶段对油离配合、方向盘角度、后视镜观察都各有理解但就是没法把它们顺畅地串起来。直到练习量足够大各个能力模块突然被“缝合”到一起你才真正会开车。大模型也是类似——规模变大后模型不再满足于死记硬背语句而是能在注意力机制下捕捉到更长距离的语义关系把语法、常识、推理交织成一套更完整的表示。这个“量变引起质变”的规律直接影响了工程决策。比如你在本地部署时纠结“到底买多大的显卡、能不能跑 7B 模型”如果你做的任务是简单分类或摘要7B 完全够用但如果要做复杂 Agent 推理可能就得上 70B 量级或者用高质量小模型加外部知识库来补足。2. 核心基础从 Transformer 到预训练与对齐2.1 Transformer 的四个关键部件想做一个合格的大模型工程师Transformer 的基本结构绕不开。但别怕不需要你把每个矩阵运算都手推一遍关键是把四个部件的作用记清楚。第一是注意力机制。它让模型在处理当前词时能同时“回看”前文所有词并按重要程度分配权重。你可以理解成我们在读一段材料时眼睛会重点停留在几个关键词上注意力做的事情就是让模型学会“哪些地方更重要”。第二是前馈网络。注意力负责从上下文里提取信息前馈网络则对每个位置的信息做进一步加工和变换相当于把“提取到的特征”做一次非线性映射。很多论文里的 FFN 层就是干这个的。第三是层归一化。它负责稳定每一层的输出分布防止深层网络训练时出现数值爆炸或梯度异常。实际训练大模型时层归一化的位置和方式都会影响收敛速度这也是很多研究关注“Pre-Norm 还是 Post-Norm”的原因。第四是位置编码。注意力机制本身不区分词序打乱一句话里的词它看到的还是同一批向量所以必须额外把位置信息加进去。经典的有正弦位置编码和可学习位置编码后来有了旋转位置编码RoPE它也是当前很多大模型处理长上下文的关键基础。把这四个部件拼起来再堆叠几十层就是绝大多数大模型的骨架。后面那些五花八门的模型变体很多只是在结构细节上做调整比如换一下归一化位置、把注意力换个稀疏版本、改一下位置编码方式。理解了共通骨架就不会被新模型的宣传话术带偏。2.2 预训练阶段到底学到了什么预训练是一个“干苦力”的阶段。模型拿到的数据往往有数十亿到数万亿个 token任务只有一个反复预测下一个词。训练过程中没有人工标注数据本身既是输入又是答案所以这种范式也叫自监督学习。但模型在这个枯燥任务里无形中学到了三样东西。第一是语言本身的结构语法、句法、常见搭配。第二是世界知识因为语料里包含了百科、新闻、书籍、代码模型把大量事实性信息压缩进了参数。第三是推理的雏形模型在补全大量逻辑连贯文本时逐渐学会了“既然前提是这样那结论大概是什么”这类模式。有一个经常被误解的点预训练阶段不求模型“答对问题”求的是“预测得尽可能准”。这个目标看起来简单实际训练时会遇到很多工程问题比如数据配比、学习率调度、loss 震荡、梯度裁剪。当年我试训一个小模型时最直观的感受是你可能训了几天loss 曲线看起来还行但一测生成质量就是“不说人话”。后来才意识到预训练的好坏高度依赖数据多样性和数据清洗而不只是堆算力。现在的模型动辄几万亿 token单纯靠个人机器去预训练一个像样的模型已经不太现实所以对大多数工程师而言更重要的任务是学会在开源基座模型上做微调、对齐、部署和二次开发。2.3 从预训练到对齐ChatGPT 这类助手是怎么来的预训练让模型学会“续写”但续写出来的内容可能是事实错误、有毒言论或者答非所问。因为互联网语料本身就鱼龙混杂。所以要把它变成“听话的助手”还需要对齐阶段。对齐最常见的方式分两步走。第一步是指令微调SFT我们准备大量“问题—标准回答”这样的对话数据让模型学着按指令要求来输出。这一步解决了“模型不知道你要干嘛”的问题。第二步是基于人类偏好做强化学习经典的是 RLHF先训练一个奖励模型来给回答打分再用强化学习让模型朝着“人类更喜欢的答案”优化。另一个流行的简化版是 DPO不需要单独训奖励模型直接从偏好数据里学。我个人在项目里的体会是SFT 阶段的效果提升最明显而 RLHF/DPO 更像“锦上添花”。如果你的场景是固定的客服问答或信息抽取专注把 SFT 数据做好性价比往往最高。要在通用对话能力上更进一步再考虑偏好优化。2.4 多模态模型的边界在扩展现在的“大模型”已经不局限于文本了。多模态模型把图像、音频、视频和文本统一映射到一个向量空间里模型既能看图也能理解语音还能按你的要求生成输出。这个能力在真实场景里非常实用比如“给一张复杂曲线图让模型直接解读趋势并生成分析文本”“给一段会议录音让模型总结行动项”。从实现原理上看多模态模型通常保留一个文本大模型作为“大脑”再训练一个视觉编码器把图片切成 patch 向量通过投影层接入文本向量序列。这样模型以后看到的就是一段“图文”混合序列照样做注意力计算。音频也是类似思路。所以你现在看到的一些所谓多模态模型骨架仍然是大语言模型只是把输入侧的“感觉器官”接进来了。我在实际项目里试过用多模态模型做图像版式解析效果确实比单模型流快了不少但也要注意多模态模型的输入侧编码往往更消耗显存图片分辨率稍高一些KV Cache 就蹭蹭往上涨。如果做批处理最好先在预处理阶段压缩图片尺寸否则服务端容易被显存打满。3. 提示词工程与上下文工程数据进出的第一道闸门3.1 提示词工程不是“咒语”是接口设计很多初学者喜欢把提示词工程当成“念咒语”觉得只要在 Prompt 里加上“请你认真思考”模型就会变聪明这其实是一种误读。提示词工程的本质是接口设计你在跟一个概率模型描述任务边界、输入格式、输出约束和判断标准。写提示词时最重要的是明确性。我在团队里反复强调一个原则如果一段需求你自己都说不清楚那模型肯定更不明白。比如“帮我总结这段话”就是个很模糊的提示词改成“用不超过三句话总结这段文本并标出文本里涉及的风险点”模型输出的可用性会高一个量级。其次是角色设定。给模型一个明确的身份相当于给任务定了一个“信息筛选器”。比如“你是一位具有十年经验的数据库管理员”模型在生成时会更倾向于使用技术语言和标准术语减少无关发挥。不过角色设定也不是万能的它本质上是给注意力机制一个倾向性信号效果大小取决于模型是否在训练阶段见过足够多的类似角色数据。第三是少样本示例。最可靠的提示词优化方式是给 1-3 个输入输出对让模型照着示例的模式来。这比在系统提示里写一百字要求都管用。我常用“给正例不给反例”的方式把理想输出完整写出来模型很快能模仿格式比单纯说“不要输出多余内容”有效。3.2 上下文工程的三个维度和长文本策略提示词只是一次性输入但真实项目里的上下文往往是动态变化的涉及上下文工程。它有三个重要维度。第一个维度是上下文窗口的管理。模型的上下文窗口是有限的要把最重要的信息放在最前面和最后面中间部分容易被“稀释”。这个是注意力分布导致的客观现象不是玄学。实际写作 Prompt 时系统指令放开头关键数据放结尾中间放背景材料。第二个维度是内容的组织与引用。当上下文里包含大量文档时不要一股脑全塞进去。先做检索再按相关度排序然后把检索结果压缩或改写再拼到上下文里。理想情况下你给模型的不是“原文”而是“把问题相关的关键信息提取并整理后的材料”。第三个维度是结构化输出。让模型输出纯 JSON 或 Markdown 表格能极大方便下游程序解析。主流模型都支持在指令里声明输出格式配合“JSON mode”或函数调用接口会更稳定。我见过很多项目在上下文工程上偷懒把整本书塞进上下文结果模型生成的回答越来越“飘”。正确做法是把文档做切片、过滤、摘要控制进到模型里的 token 数。说实话上下文工程的 ROI 比很多花哨的微调方案高得多。3.3 提示词模板与最佳实践速查下面是一个我自己常用的提示词模板基本适用大多数文本任务。你是【角色描述】擅长【技能范围】。 任务【一句话说清楚要做什么】。 要求 1. 输出格式Markdown / JSON / 表格 2. 约束条件字数限制、不要编造、引用原文时标注来源 3. 处理边界如果信息不足明确说“无法判断”不要猜测 输入内容 【具体待处理数据】 请开始处理。这个模板的核心逻辑是“角色先入、任务明确、约束清晰、数据独立”。它不一定完美但至少保证模型的注意力焦点不会被杂讯带偏。写提示词时有几个常见误区要避免。一是把提示词写得过长大量重复且无关的“原则”反而会稀释关键信息。二是过度使用否定句式模型对“不要如何如何”的遵从度不如“必须如何如何”。三是忘记给模型退路任务信息不够时模型也会硬着头皮编一个答案所以最好在约束里显式允许它说“不知道”。4. 微调不改变模型灵魂只调整它的行为习惯4.1 什么时候该微调什么时候不该微调微调是我被问得最多的话题之一但很多问题的答案其实是“不该微调”。在动手前先做一道选择题。如果你的目标是让模型改变回答风格、遵守一套固定的输出格式、或者适应一个定义明确的专业任务先试提示词。如果需要把最新的内部知识引入先做检索增强生成RAG。只有在提示词和 RAG 都解决不了比如你的任务有独特的输入输出映射规则、领域术语密集、且你有一定量的高质量标注数据时才考虑微调。我见过不少团队一上来就微调结果把 7B 模型微调得连通用对话能力都丢了。原因是微调阶段的数据分布太单一模型只记住了你给的那几百条样本的模式原本预训练时建立的能力反而被覆盖。所以微调不是“越做越强”它本质上是一种“能力转移”。你想让模型更擅长 A 任务就得接受它在 B 任务上可能略有退化。4.2 常用微调方案对比全参、LoRA、QLoRA微调方案主要分两类全参微调和参数高效微调。参数高效微调里最有代表性的是 LoRA 和 QLoRA。它们的区别直接决定了你需要多少显存。全参微调要更新模型所有参数显存占用最大训练出的效果通常也最上限但对个人开发者的小机器来说基本不现实。LoRA 的做法是在模型的线性层旁挂一个低秩矩阵只训练这部分新增的少量参数原模型参数冻结不变。这样效果往往能逼近全参微调而可训练参数量通常是原模型的 1% 以内。QLoRA 更进一步先把模型量化成 4-bit 来压缩显存再做 LoRA 训练让单卡跑大模型微调成为可能。我整理过一个对比表格供做硬件选型时参考。方案可训练参数量显存需求7B 模型速度适用场景全参微调全部参数约 80GB 以上取决于批次最慢数据量大、算力充足LoRA约 1%约 20-30GB较快单卡 24GB 可跑效果稳定QLoRA约 1%约 8-12GB快单卡 12GB 可跑效果略逊这里的显存数值只是估测实际会因序列长度、批量大小、优化器而浮动。但至少能帮你在项目规划阶段快速判断硬件够不够用。4.3 一个基于LoRA的微调流程和显存估算我拿一个 7B 模型的 QLoRA 微调流程举例。流程本身不复杂重点是环境准备和参数选择。第一步准备数据集。Hugging Face 的datasets库可以直接加载也可以把自己的 JSON 文件整理成统一格式。from datasets import load_dataset dataset load_dataset(json, data_filestrain.json)[train] print(dataset[0])每条样本建议带上instruction、input、output三个字段便于套用模板。别小看这一步数据格式统一了后面处理函数才能写得简单。第二步加载模型和分词器做 4-bit 量化配置。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( your-org/your-7b-model, quantization_configquant_config, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(your-org/your-7b-model)第三步配置 LoRA 参数。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05 ) model get_peft_model(model, lora_config) model.print_trainable_parameters()r和lora_alpha是 LoRA 里最重要的两个超参。简单理解r控制低秩矩阵的宽度r越大可学习参数越多但并不是越大越好8 到 16 是常见起点。lora_alpha是缩放系数一般设置为r的两倍。第四步创建训练器并开始训练。这里的关键参数是学习率、批次大小和最大长度。我一般用学习率 2e-4 到 5e-4批次大小根据显存调整到 1 或 2配合梯度累积达到等效批次 16。关于显存估算有一个通用公式思路模型权重大小 梯度 优化器状态 激活值。7B 模型如果全用 bf16 加载权重约 14GBLoRA 训练时优化器状态只维护低秩参数所以额外占得不多激活值和 KV Cache 随序列长度增加而增加。用 QLoRA 的情况下4-bit 模型权重约 3.5GB训练时实际占用通常可以压到 10GB 上下。这也是为什么很多人说“消费级显卡也能微调”。4.4 微调数据质量与常见翻车点微调项目的成败数据质量占七成模型和代码只占三成。以下三条是我反复踩过的坑值得拿出来反复说。第一条数据要“均匀”。如果你的训练集里 80% 是“闲聊问答”只有 20% 是“专业任务问答”模型微调后会倾向于把一切输入都往闲聊上带。解决方式是按任务类型做均衡采样或者给不同类型数据分配不同权重。第二条数据要“去污染”。我在一个项目里把网络抓取的问答数据直接拿去微调结果里面混了大量已有模型生成的文本模型学了一堆自问自答的套话真实场景表现很差。现在宁愿多花时间做人工清洗也不愿意图省事直接灌数据。第三条警惕“微调后变傻”。很多人在微调后用几个样例测试觉得效果不错就以为万事大吉。实际上一旦测试集也被微调数据“污染”了指标会有幻觉般的提升到线上才发现模型对通用问题的回答质量陡降。正确的做法是建立一份与训练集不重叠的评测集并且评测集最好从真实业务请求里采样。5. 本地部署与推理加速从模型参数到可用服务5.1 本地部署的取舍与典型硬件配备本地部署大模型这几年热度一直很高。大家想把它跑在自己电脑上的原因各有不同有的是因为数据敏感不敢把业务数据发送到外部 API有的是想省下按 token 付费的钱还有的就是想折腾一下把个人电脑变成一台“随身 AI 工作站”。本地部署的取舍核心是“三权衡量”效果、成本和隐私。想效果好得用大参数模型就需要堆更多显存想把成本压到最低就得接受量化带来的效果损失。我的建议是先明确你的任务难度再倒推模型尺寸和硬件需求而不是反过来先买了显卡再去找模型。粗略估算显存有个简单办法模型权重 GB 数 ≈ 参数量B× 精度字节数。7B 模型用 FP16/BF16 是 14GB 左右用 INT4 量化后能压到 4-5GB。推理时还得叠加上下文占用的 KV Cache长对话时这部分增长很快。所以运行 7B INT4 模型实际推荐显存至少 6GB跑长上下文建议 12GB。我把自己试过的一些档位整理成了表格模型规模精度显存需求可用硬件示例体验描述1-3BINT42-4GB办公笔记本简单问答够用7-8BINT45-8GB主流游戏显卡多数任务可用13-14BINT410-14GB24GB 显卡质量明显提升14BBF1628GB专业卡或双卡保真效果好70BINT440GB多卡或多机复杂推理能力强以上数值都是经验值实际请以运行日志为准。5.2 量化把大象装进冰箱的三个压缩档位量化是本地部署最核心的优化手段本质上是用更少的比特数来近似表示模型权重。模型参数原本用 16 位浮点存现在用 8 位或 4 位整数存大幅缩小体积代价是精度下降。当前主流的量化路线大概有三种。第一种是训练后量化代表有 GPTQ、AWQ适用 GPU 推理能把模型压到 4-bit且效果损失较小。第二种是 GGUF 格式主要配合 llama.cpp 使用可以在 CPU 上跑也支持 GPU 加速适合消费级设备。第三种是主流的“动态量化”思路比如 vLLM 支持的 FP8/INT8它们在推理引擎层面兼顾吞吐和效果。选量化方案时我一般建议先试低精度但效果损失最小的方案。如果你有一张 24GB 显存跑 7B 模型完全不需要量化保留 BF16 精度效果最好如果显卡只有 6-8GB再考虑 INT4 量化。另一个经验是量化对“逻辑推理类任务”的影响比对“简单分类任务”更大所以如果你做的是复杂 Agent别把量化档位压得太狠。5.3 推理引擎的选择vLLM 与 llama.cpp 等模型选好、量化做完下一步就是选推理引擎。推理引擎决定你服务的吞吐、延迟和显存效率。我用得最多的是 vLLM 和 llama.cpp 系工具它们各有所长。vLLM 主打高吞吐 GPU 推理核心优势是 PagedAttention 和连续批处理。PagedAttention 把 KV Cache 切成小块按需管理显存利用率高连续批处理则让多个请求穿插执行空闲的 GPU 资源能被充分填满。我用 vLLM 在单卡上部署 7B 模型实测并发 20 路请求时吞吐比普通原生生成高了数倍。llama.cpp 则更适合轻量部署和边缘设备它把模型量化成 GGUF 格式后可以 CPU 推理也能把一部分层卸载到 GPU 加速。优点是环境约束小缺点是并发能力弱不适合做高吞吐服务。如果你只是个人电脑里用推荐 Ollama。它封装了模型管理、下载、启动服务这些琐事一条命令就能跑起一个 Chat 服务底层用 llama.cpp 或自带兼容层。我在本地把 7B 模型通过 Ollama 跑起来后配合一个 Web UI 就能给团队做演示非常方便。下面是一张对比表方便按场景选型。引擎适用场景硬件要求并发能力上手难度vLLM线上服务、高并发NVIDIA GPU 效果最好极强中等llama.cppCPU/边缘/移动端可仅 CPU较弱中等Ollama个人本地随手用消费级显卡或 CPU弱很低Hugging Face TGI企业服务NVIDIA GPU强中等5.4 完整部署流程速览这里给一套我常用的 vLLM 部署流程适合快速把一个 Hugging Face 模型变成 OpenAI 兼容接口。第一步安装依赖。建议用独立的虚拟环境。pip install vllm第二步启动服务。注意模型格式要能被 vLLM 识别。vllm serve your-org/your-7b-model \ --served-model-name test-model \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9这里的max-model-len控制最大上下文长度设得太高会占用大量显存建议按实际需求来。gpu-memory-utilization表示允许 vLLM 使用显卡显存的比例调高能缓存更多 KV但别顶到 1.0容易把其他显存需求挤爆。第三步测试接口。curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: test-model, messages: [{role: user, content: 你好介绍一下你自己}], temperature: 0.7 }返回正常就说明服务起好了。后续接 LangChain 或者 Spring AI 这类框架时只需把接口地址指到http://localhost:8000/v1即可。部署阶段还有两个容易踩的坑一是模型路径写错vLLM 对模型文件结构要求比较严格缺少config.json或格式不是最新版会直接报错二是并发高时 OOM这时候优先减小max-model-len其次是调低gpu-memory-utilization。6. Agent 与开发落地把大模型接进真实业务流程6.1 Agent 基本结构与主流框架如果说部署是把大模型变成一台“发动机”Agent 就是给它装上“方向盘、后视镜和工具箱”。一个完整的 Agent 至少要包含四个部分大模型作为决策中枢、工具调用能力、记忆系统、任务规划机制。大模型负责理解用户目标并拆解成子任务工具让它可以查数据库、调 API、操作文件记忆分短期当前会话上下文和长期向量库等外部存储规划机制则解决“多步任务怎么拆、顺序怎么定、失败怎么重试”的问题。这四个部分组合起来才让模型从“回答问题”升级为“完成任务”。主流框架方面我简单列几个常用的。LangChain 生态最全适合快速搭原型LlamaIndex 专注于数据检索和 RAG 场景AutoGen 主打多智能体协作让多个 Agent 互相讨论CrewAI 把 Agent 组织成“角色团队”适合模拟工作流Spring AI 是 Java 生态的接入层我在做 Java 后端项目时用过和 Spring Boot 集成很顺。选框架没有绝对标准我一般看两点社区活跃度和自定义灵活性。框架只是骨架真到了生产环境定制逻辑往往比默认组件更重要。6.2 RAG先检索再生成缓解幻觉的关键策略Agent 系统里最常用的外挂记忆就是 RAG全称是“检索增强生成”。它的思路很简单在让模型回答问题前先从外部知识库检索相关文档片段把检索结果拼进上下文再让模型基于这些材料生成回答。RAG 能有效缓解幻觉因为模型不再硬凭参数里的记忆回答而是有“参考资料”可以依赖。同时知识库是独立维护的业务文档更新后不需要重新微调模型只要把新文档切块入库模型就能用到最新知识。这个特性让 RAG 在企业私有化部署中特别受欢迎。一个完整 RAG 链路通常包括文档解析、分块、向量化、向量检索、重排序、生成。文档先按标题或语义切块每块切得不长不短太短丢失上下文太长给嵌入模型带来噪音再用嵌入模型把每块转成向量存入向量数据库查询时把用户问题也转成向量检索 Top-K 相关块最后用重排序模型把召回结果精排一遍把最相关的片段拼进 Prompt。我在一个企业知识库项目里用 RAG 替换了纯模型回答之后引用准确性大幅上升用户也不再轻易“撞见幻觉”。但要注意RAG 不是银弹文档质量差、检索召回不准、分块策略不对都会让最终回答质量打折。6.3 评估没有指标就没有优化的方向盘做大模型项目最容易陷入“感觉还行”的状态。没有评估指标你就不知道这次改 Prompt 到底变好了还是变坏了也不知道微调后的模型该不该上线。我强烈建议任何项目从一开始就建立一套轻量级评测集。评测集不用很大先收集 100-300 条代表性业务问题就行覆盖不同难度和不同场景。每次改动后把这些问题统一跑一遍再按统一标准打分。打分方式分几种规则类指标适合看格式比如 JSON 解析成功率传统文本指标适合看相似度比如 ROUGE/BLEU对开放问答任务我比较推荐“LLM-as-Judge”用一个更强的大模型给输出打分效率和一致性都很好。这里也有个陷阱让模型给自己打分时必须给它明确的评分维度比如“内容准确性”“逻辑连贯性”“是否遵循格式”否则评分标准会漂移。另一个常见问题是线上指标和测试集指标不一致因为线上问题分布跟手工构造的评测集差距很大。所以评测集要持续从真实日志中补充甚至做定期“盲测”才能让指标真正服务于优化。7. 学习路径与避坑手册7.1 三个月路线图参考系统性入门不用追求面面俱到而是要有节奏地建立“原理—提示词—微调—部署—开发”这条完整链路。我给自己带过的同学排过一份三个月路线图放在这里供参考。第 1-2 周重点是原理和上手体验。先花时间把 Transformer、预训练、对齐这三大概念搞清楚不需要看完整数学推导但要知道每个模块负责解决什么问题。同时找一个大模型 chat 页面或本地 Ollama 环境每天做提示词实验感受温度、系统提示、少样本这些变量对输出的影响。第 3-6 周切入提示词工程和上下文工程并开始做项目练习。可以选一个真实场景比如“从客户工单里抽取结构化信息”把提示词、JSON 输出、错误处理都做成一个小闭环。这个阶段的目标是能产出稳定可用的 Prompt。第 7-8 周学习微调和数据。建议拿一个小模型完整跑一遍 QLoRA 微调流程重点理解数据格式、训练参数和评测方法。不求一次调出完美模型而是把“微调为什么会变好/变坏”的感觉建立起来。第 9-10 周学习本地部署和推理加速。用 vLLM 或者 Ollama 在本地部署一个模型跑通 OpenAI 兼容接口再试着用量化把模型压小记录不同量化档位的效果差异。第 11-12 周做 Agent 综合项目。把前面用到的模型、RAG、结构化输出串起来搭建一个能解决实际问题的智能体比如“企业内部文档问答机器人”或者“智能客服助手”。7.2 常见问题速查表我整理了项目实战中最常遇到的问题和排查思路做成速查表方便没有任何排查头绪的时候先翻一翻。问题典型表现排查方向显存不足进程启动直接 OOM减小max-model-len、降低批次、启用量化生成速度慢单请求耗时好几秒换 vLLM 这类高吞吐引擎、缩短上下文长度微调后变笨通用能力下降、回答僵硬检查数据分布和样本量、降低学习率、评测集是否泄漏上下文被截断回答忘了前文信息确认上下文窗口大小、查看模型的 tokenizer 截断行为幻觉严重输出中出现不存在的实体和数字引入 RAG、增加引用来源约束、调低 temperatureAPI 连不上服务启动成功但客户端超时检查防火墙/端口映射、确认请求路径和模型名这张表只能给一个入口级别的思路。真到线上环境还需要配合日志、监控和链路追踪来看但至少能在踩坑时快速定位方向。7.3 我踩过的几个坑实操心得最后分享几条我在实操过程中真正摔过的跟头。第一太迷信“大参数模型”。早期做项目时总想上 70B结果部署和推理成本都压不住。后来换了 7B 模型配合 RAG 和精心设计的 Prompt任务效果反而更稳定成本和延迟还大幅下降。模型大小只是手段不是目标。第二忽略上下文窗口的静默截断。有次排查线上问答效果差发现历史会话很长之后模型开始“失忆”翻日志才看到长文本被 tokenizer 截断。后来我在接入层主动检测输入长度超过阈值就做历史摘要压缩问题解决得很快。第三在评测上省时间。早期微调完一个模型凭几组样例感觉不错就部署上线结果线上问题跟样例分布完全不是一回事被迫回滚。现在我把评测集当成工程的一部分每次改动必跑评测把“感觉”换成“数据”。第四用量化一刀切。有一版为了压显存把模型从 BF16 直接压到 INT4复杂 Agent 任务立刻出现推理逻辑断裂。后来针对性做混合精度部署只对某些层做低比特量化才恢复稳定。做这个系统性入门资料整理的过程中我自己最大的收获是大模型方向是个“宽而深”的领域真正重要的不是记住某个模型的名字或某个库的参数而是建立一套“从原理到落地的因果链”。资料可以散但认知不能散。如果你顺着这篇文章的顺序把每一条链路都摸一遍再遇到各种新模型和新工具你看到的不再是孤立的碎片而是一个大体系里各自分工的零件。到那时你就真正入门了。