1. 先搞清楚你到底在学什么AI大模型的能力地图我带过不少刚入行的新人发现一个特别普遍的现象很多人一上来就问“怎么微调”“怎么部署”但连大模型到底能干什么、不能干什么都说不清楚。这就像还没学会走路就想跑摔跟头是必然的。所以我想先把这张能力地图摊开来讲清楚你才知道自己该往哪个方向使劲。1.1 大模型不是万能药先分清它擅长的三件事大模型最核心的能力其实就三块文本理解与生成、代码辅助、多模态识别。文本理解与生成是最基础的包括问答、摘要、翻译、改写这些代码辅助是这两年需求爆发最猛的从补全到debug再到整段逻辑生成多模态识别则是图像、视频、音频的理解与标注工业AI检测、服装检测这类场景就属于这个范畴。很多人问“像工业AI检测、服装检测这类AI用的是云联网还是单机的AI”这个问题本身就暴露了对架构的模糊。答案不是二选一而是看你的延迟要求、数据隐私要求和成本结构。产线上的缺陷检测延迟要求通常在毫秒级数据也不允许出工厂内网那就必须走本地部署路线。而一些非实时的报表分析、客服质检走云端API完全够用还省去了运维成本。提示不要一上来就追求“全本地化”先算清楚你的场景对延迟、隐私、成本的实际约束再决定部署形态。1.2 微调、提示词工程、部署三者的关系不是并列的很多教程把“大模型微调”“提示词工程”“模型部署”当成三个独立技能来讲这是很大的误导。它们实际上是一条流水线上的不同环节而且有优先级顺序。我的经验是先做提示词工程再做微调最后才考虑部署优化。为什么因为提示词工程成本最低、迭代最快。你花两天时间打磨一套提示词可能就能解决80%的问题。只有当提示词怎么调都达不到效果时才需要考虑微调。而部署是在你确定了模型方案之后才做的事不是一开始就要纠结的。举个实际例子我之前做一个合同关键信息抽取的项目一开始团队想直接微调一个7B模型。我让他们先花三天做提示词工程结果用few-shot加结构化输出约束准确率就到了92%根本不需要微调。省下来的GPU时间和标注成本够团队吃好几顿火锅了。1.3 不同基础的人学习路径完全不同如果你是完全零基础我建议的路径是Python基础 → API调用 → 提示词工程 → RAG应用开发 → 微调入门 → 部署优化。这条路径的好处是每一步都有正反馈你能很快做出一个能用的东西。如果你已经有后端开发经验可以跳过Python基础直接从API调用和提示词工程切入然后重点补RAG和微调。如果你是做算法的那重点应该放在微调技术和推理优化上提示词工程反而可以快速带过。我见过太多人卡在“学什么”这个问题上其实答案很简单先跑通一个最小闭环再根据需求补短板。不要试图把所有理论都学完再动手那样你永远动不了手。2. 提示词工程最被低估的核心技能提示词工程这个词听起来很虚但它是你和大模型交互的唯一接口。我敢说80%的“模型效果不好”问题本质上是提示词没写好。这一章我把提示词工程拆成可操作的几个层面来讲。2.1 提示词的结构化写法角色、任务、约束、示例一个高质量的提示词我通常按四段式来组织角色设定、任务描述、约束条件、示例。这四段缺一不可但很多人只写了任务描述就完事了。角色设定是让模型进入特定语境。比如“你是一名有十年经验的合同审核律师”和“你是一个助手”输出的专业度完全不一样。任务描述要具体到输出格式比如“提取以下合同中的甲方名称、乙方名称、合同金额、签署日期以JSON格式输出”。约束条件是最容易被忽略的比如“如果某项信息在原文中不存在输出null不要编造”。示例则是给模型一个参照通常给1到3个就够了。prompt_template 你是一名资深合同审核律师擅长从法律文书中提取关键信息。 任务从以下合同文本中提取甲方名称、乙方名称、合同金额、签署日期。 约束 1. 严格按照JSON格式输出不要添加任何解释 2. 如果某项信息不存在值设为null 3. 合同金额只保留数字单位统一为元 示例 输入甲方某某科技有限公司乙方张三合同金额伍万元整签署于2024年3月15日 输出{甲方: 某某科技有限公司, 乙方: 张三, 合同金额: 50000, 签署日期: 2024-03-15} 现在请处理以下文本 {contract_text} 这个模板看起来简单但每一段都有明确意图。角色设定提升专业度任务描述明确输出目标约束条件防止模型自由发挥示例给出格式参照。实测下来加了示例之后JSON格式的合规率从70%提升到98%以上。2.2 少样本提示与思维链什么时候用怎么用少样本提示就是在提示词里给几个输入输出示例让模型模仿。思维链则是让模型先输出推理过程再给结论。这两个技术不是万能的要看场景。少样本提示适合格式固定、任务明确的场景比如信息抽取、分类、改写。思维链适合需要推理的场景比如数学题、逻辑判断、多步决策。我试过在信息抽取任务上加思维链结果反而变差了因为模型开始“过度思考”把简单任务复杂化了。一个实用的判断标准是如果你的任务人类做的时候不需要“想一下”那就不要用思维链。信息抽取人类看一眼就能做不需要推理步骤。但如果是“根据这段财报判断公司是否存在财务风险”那就需要思维链来引导模型逐步分析。注意思维链会让输出token数增加2到5倍成本和延迟都会上升。在延迟敏感的场景要谨慎使用。2.3 提示词工程的常见坑与排查方法我整理了几个最常见的提示词问题以及对应的排查思路。问题现象可能原因排查方法输出格式不稳定约束不够明确加JSON schema约束加示例模型编造信息没有防幻觉约束加“如果不存在输出null”输出太啰嗦没有长度约束加“不超过100字”专业度不够角色设定缺失加具体角色描述中英文混杂语言约束缺失加“全部用中文输出”这些坑我都踩过。最典型的一次是做一个商品标题生成模型总是加一堆形容词后来在约束里加了“不超过20个字不加感叹号”问题就解决了。提示词工程就是这样大部分问题都能通过更精确的约束来解决不需要动模型本身。2.4 提示词版本管理别再用txt文件了这是一个很多人忽略的工程实践问题。提示词是要迭代的你今天改一版明天改一版如果没有版本管理很快就乱了。我建议用YAML文件加Git来管理提示词每个版本记录修改原因和效果指标。version: v3 date: 2024-03-15 author: me change: 增加JSON schema约束修复金额单位问题 metrics: accuracy: 0.96 format_compliance: 0.99 prompt: | 你是一名资深合同审核律师...这样做的好处是当线上效果下降时你可以快速回滚到上一个版本也能清楚地看到每次修改带来的效果变化。这个习惯我从两年前开始坚持帮我省了无数次“到底哪版提示词效果最好”的纠结。3. 大模型微调什么时候该做怎么做微调是很多人最感兴趣的部分但也是最容易走弯路的部分。我先说一个可能让你失望的结论大部分场景不需要微调。但如果你确实需要这一章会告诉你完整的实操路径。3.1 微调 vs RAG vs 提示词工程决策树在决定微调之前先问自己三个问题第一提示词工程是否已经做到极致第二是否可以通过RAG引入外部知识解决第三是否有足够的标注数据如果提示词工程已经优化到极限效果还是不行那可能是模型本身的能力边界问题这时候微调才有意义。如果问题是模型缺乏特定领域的知识那RAG通常比微调更合适因为RAG可以随时更新知识库而微调每次更新都要重新训练。我一般用这个决策逻辑格式问题用提示词知识问题用RAG风格和能力问题用微调。比如你要模型学会特定的输出风格、特定的推理模式那微调是有效的。但如果你只是想让模型知道公司的最新产品信息RAG是更好的选择。3.2 数据准备微调成败的80%在这里微调的效果八成取决于数据质量两成取决于训练技巧。我见过太多人花大量时间调参但数据只有几百条且质量参差不齐最后效果当然不好。数据准备的核心是多样性和一致性。多样性是指覆盖各种输入情况一致性是指输出格式和风格统一。通常来说1000到5000条高质量数据就能看到一个明显的微调效果。如果少于500条建议先考虑提示词工程或RAG。数据格式一般是JSONL每行一个样本包含instruction、input、output三个字段。如果是对话模型则是messages数组。这里的关键是output必须是你期望模型输出的“标准答案”不能有歧义。{instruction: 提取合同关键信息, input: 甲方某某公司..., output: {\甲方\: \某某公司\, ...}}提示数据标注完成后一定要做一轮人工抽检至少检查10%的样本。我遇到过标注员把金额单位搞错的情况这种错误会直接教坏模型。3.3 LoRA微调实操从环境搭建到训练完成LoRA是目前最主流的微调方式因为它显存占用低、训练速度快、效果接近全量微调。我用一张24G显存的卡就能微调7B模型这在全量微调时代是不可想象的。环境搭建我推荐用LLaMA-Factory这个框架它把数据加载、训练、推理都封装好了配置用YAML文件管理非常清晰。安装很简单git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .[torch,metrics]训练配置的关键参数我列一下参数推荐值说明lora_rank8-16秩越大容量越大但显存也越大lora_alpha16-32通常设为rank的2倍learning_rate1e-4到5e-5LoRA可以用比全量微调更大的学习率num_epochs3-5太多会过拟合batch_size根据显存调整配合梯度累积使用cutoff_len1024-2048根据你的数据长度分布定训练命令一行搞定llamafactory-cli train config/lora_sft.yaml训练过程中要盯着loss曲线。如果loss下降后又上升说明过拟合了要减少epoch。如果loss一直不降可能是学习率太小或数据有问题。3.4 微调后的效果评估与迭代微调完成后不要只看loss要看实际效果。我通常准备一个50到100条的测试集覆盖各种边界情况然后人工评估输出质量。评估维度包括格式合规率、内容准确率、幻觉率、输出长度分布。如果格式合规率低于95%说明数据格式不够统一。如果幻觉率上升说明训练数据里有错误信息被模型学到了。迭代的方向通常是补充bad case对应的训练数据调整数据配比重新训练。我一般会迭代2到3轮每轮补充100到200条针对性数据效果提升很明显。4. 模型部署从实验到生产的关键一跃模型部署是把你的成果变成可用服务的关键一步。很多人训练完模型就结束了但真正的挑战在部署阶段。这一章我讲清楚本地部署和云端部署的选型逻辑以及具体的实操方法。4.1 本地部署 vs 云端部署怎么选本地部署和云端部署不是对立的而是根据场景选择的。我整理了一个对比表维度本地部署云端部署延迟低可控取决于网络数据隐私高数据不出内网需要信任服务商成本前期硬件投入大按量付费弹性好运维需要自己维护服务商负责扩展性受硬件限制弹性扩展适合场景产线检测、隐私敏感客服、内容生成工业AI检测、服装检测这类场景我强烈建议本地部署。产线环境网络不稳定延迟要求高数据也不能外传。而一些内部工具、非实时分析云端API完全够用。4.2 用Docker部署Ollama最省心的本地方案如果你要在本地跑模型Ollama是目前最省心的选择。它把模型下载、量化、推理都封装好了一条命令就能跑起来。配合Docker环境隔离也解决了。docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama docker exec -it ollama ollama pull qwen2.5:7b拉下来之后直接调API就行curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好, stream: false }这个方案的好处是零配置、跨平台、模型管理方便。Windows上装个Docker Desktop就能跑Linux更不用说了。我实测在一台32G内存的机器上跑7B的量化模型推理速度完全可用。注意Ollama默认的上下文长度是2048如果你的任务需要更长上下文要在Modelfile里调num_ctx参数。4.3 GPUStack部署多模型多卡的管理方案如果你有多张卡、要部署多个模型Ollama就不够用了。这时候可以考虑GPUStack它是一个专门做GPU资源调度和模型部署的工具支持多机多卡、模型自动调度、API统一管理。安装也很简单Docker一行命令docker run -d --gpus all -p 80:80 -v gpustack-data:/var/lib/gpustack gpustack/gpustack然后通过Web界面添加模型、分配GPU资源。它支持vLLM、llama.cpp等多种推理后端可以根据模型大小自动选择。对于团队使用来说这个方案比每个人自己搭一套环境要高效得多。4.4 模型量化与推理加速让消费级显卡也能跑量化是让大模型在消费级硬件上跑起来的关键技术。简单说就是把模型参数从16位浮点数压缩到8位、4位甚至更低显存占用减少一半以上速度也有提升代价是精度略有下降。常见的量化格式有GGUF和AWQ。GGUF适合CPU加GPU混合推理AWQ适合纯GPU推理。我一般用llama.cpp的量化工具来做./quantize model-f16.gguf model-q4_k_m.gguf q4_k_mq4_k_m是我最常用的量化级别在精度和体积之间平衡得最好。7B模型量化后大约4G左右24G显存的卡可以轻松跑起来甚至32G内存的机器用CPU推理也能接受。关于“32G内存能装AI大模型”这个问题答案是能装但要看量化和推理框架。32G内存跑7B的q4量化模型没问题但13B以上就比较吃力了。如果要用CPU推理建议用llama.cpp它的内存管理做得很好。5. 常见问题与排查技巧实录这一章我整理了一些实际项目中高频遇到的问题以及我的排查思路和解决方法。这些问题在官方文档里通常找不到答案都是踩坑踩出来的。5.1 模型输出不稳定怎么办这是最常见的问题。同一个提示词有时候输出JSON有时候输出Markdown有时候还加一堆解释。排查思路是先看约束再看示例最后看温度参数。约束要明确到“只输出JSON不要任何其他文字”。示例要给2到3个覆盖不同情况。温度参数建议设为0到0.3太高会导致输出随机性增大。如果这三步都做了还不稳定那可能是模型本身能力不够考虑换更大的模型或微调。5.2 显存不够用怎么优化显存不够是部署阶段最头疼的问题。优化手段按优先级排序量化 → 减小batch size → 减少上下文长度 → 换更小的模型。量化是最有效的4位量化能把显存占用降到原来的四分之一。如果还不行就把batch size设为1上下文长度从4096降到2048。再不行就只能换更小的模型了比如从7B换到3B。我试过在8G显存的卡上跑7B的q4模型batch size设为1上下文2048勉强能跑但速度比较慢。5.3 微调后模型变“傻”了怎么回事这是典型的过拟合或灾难性遗忘。微调数据太少、训练轮次太多、学习率太大都会导致这个问题。解决方法是减少epoch、降低学习率、增加数据多样性。还有一个容易被忽略的原因是数据格式不一致。如果训练数据里有些是JSON有些是纯文本模型就会混乱。我建议在训练前写个脚本统一检查数据格式确保所有output都是同一种结构。5.4 推理速度太慢怎么加速推理速度慢的原因可能是模型太大、量化不够、硬件不行、框架没优化。加速手段包括用量化模型、用vLLM或TensorRT-LLM等优化框架、开启批处理、用更快的GPU。vLLM是我最推荐的推理框架它的PagedAttention技术能大幅提升吞吐量。同样的硬件vLLM比HuggingFace的默认推理快3到5倍。如果延迟要求极高可以考虑TensorRT-LLM但配置复杂度也更高。5.5 常见问题速查表问题可能原因快速解决输出格式乱约束不明确加JSON schema和示例显存OOM模型太大或batch太大量化减小batch推理慢框架未优化换vLLM用量化模型微调效果差数据质量低检查数据格式和标注模型编造无防幻觉约束加“不知道就说不知道”中文输出差训练数据英文为主用中文数据微调这些问题的解决方法我都实际验证过大部分情况下按表里的思路走就能解决。如果还不行那可能需要更深入的调试比如看attention输出、分析token概率分布等。6. 学习路径与资源推荐少走弯路的实操建议最后这一章我想聊聊学习路径。网上资源太多了反而让人不知道从哪开始。我按阶段整理了一条路径以及每个阶段最值得投入时间的方向。6.1 第一阶段跑通最小闭环1到2周这个阶段的目标是能调用模型、能写提示词、能做出一个简单应用。不要纠结原理先动手。推荐从API调用开始写一个简单的问答脚本然后逐步加功能。这个阶段的关键是建立信心。当你看到自己写的提示词能让模型输出想要的结果时那种成就感会驱动你继续深入。我建议从实际需求出发比如做一个自动整理会议纪要的小工具比单纯跑demo有意思得多。6.2 第二阶段深入提示词工程和RAG2到4周这个阶段要系统学习提示词工程的各种技巧同时掌握RAG的基本原理和实现。RAG是当前企业应用最广泛的技术方案掌握RAG就能解决大部分知识问答场景。RAG的核心是向量检索加生成。你需要了解embedding模型、向量数据库、检索策略、重排序这些概念。推荐用LangChain或LlamaIndex来快速搭建原型然后逐步深入理解每个环节。6.3 第三阶段微调与部署1到2个月这个阶段开始接触微调和部署。先从小模型开始用LoRA微调一个7B模型走通全流程。然后学习量化、推理优化、服务化部署。这个阶段最重要的是动手做完整项目。从数据准备到训练到部署到评估完整走一遍。我见过很多人只跑过教程里的demo没有自己准备过数据结果遇到实际问题就懵了。6.4 我踩过的坑与给你的建议第一个坑是盲目追求大模型。一开始总觉得参数越大越好后来发现7B的模型在大部分场景下够用了关键是数据和提示词。第二个坑是忽略工程化。提示词版本管理、数据版本管理、实验记录这些工程实践比模型本身更重要。第三个坑是不重视评估。没有评估就没有迭代方向我现在的习惯是每个项目先建评估集再开始优化。如果让我给一条最重要的建议那就是从实际需求出发不要为了学而学。找一个你真正想解决的问题用它来驱动学习。这样你学到的每一个技能都是有用的而且有正反馈能坚持下去。