LLM动手实践指南：从提示词工程到RAG与微调

刚拿到《Hands-On Large Language Models》这类动手型教程时，我最大的困扰不是看不懂字面意思，而是不知道下一步该做什么。大型语言模型（LLM）的资料已经多到爆炸，可大多数指南要么停在原理层，要么只教你调API。这篇实用指南写给两类人：一类是从零开始、希望把LLM真正学懂的新手；另一类是已经会调用接口、但发现链路做不扎实的工程师。我会按动手实践的顺序，把学习路线、原理底子、提示词工程、检索增强生成（RAG）、微调和评估串成一条可直接参照的路径，并把实操中踩过的坑一并写进来。书名里的"Hands-On"不是形容词，而是在提醒你——要亲手把模型跑起来，才算真的学会。

1. 先把学习顺序理顺：别一上来就微调大模型

1.1 学LLM最常见的三种弯路

第一种弯路，跳过原理，直接微调。A同学拿到一个开放权重模型后，直接下载各类微调脚本，数据集拼了几天，跑了十几个小时，结果回答质量还不如提示词调教过的原版模型，于是得出"微调没用"的结论。其实不是微调没用，是顺序错了。模型怎么训练、为什么要微调、微调解决什么问题，这些判断力都还没建立起来，就去装最重的轮子，翻车几乎是必然的。

第二种弯路，只学提示词，一遇到幻觉问题就束手无策。提示词确实是LLM应用里性价比最高的技术，但它不能解决"模型不知道某件事"的问题。你问它一个超出预训练知识范围的领域问题，它会一本正经地编一个答案。如果你只会换提示词，就会陷入不断"优化咒语"却始终没有进步的循环。

第三种弯路，只看不动手。读再多的Transformer讲解、注意力机制可视化，不如完整跑通一次最小的生成Demo。我见过太多人把教程存进收藏夹，三个月后还停留在第一个章节。LLM的学习曲线不是"看懂-记住-复述"的线性关系，而是"跑通-踩坑-修正-理解"的螺旋上升。你看一百遍"上下文长度有限"的文字描述，都不如亲眼看一次长文档被截断后模型回答得牛头不对马嘴来得深刻。

1.2 我推荐的四阶段学习节奏

下面这个表基本是我给周围人推荐的学习节奏，时长按每天投入两小时估算：

为什么把微调放在最后？不是因为微调最难，而是因为大多数业务问题根本轮不到微调上场。你先把提示词和RAG这两层压榨干净，再回头看微调，就会清楚自己到底缺什么：是真的需要改变模型行为，还是只需要一个更好的搜索和提示编排。

另外，我不建议在阶段0花超过两周。原理是用来指导实践的，不是用来考试的。你不需要把注意力公式的维度推导完全背下来，但你需要知道"模型看到多长的上下文、它怎么把词变成向量、它按什么顺序训练出来"，因为这几个认知会直接决定你后来调试方向时往哪儿看。整个学习过程可以慢，但不要停，断了三周再回来，前面建立的手感会丢掉一半。

2. 原理底子怎么补：从注意力机制到训练三阶段

2.1 只需要建立五个核心直觉

我见过太多人倒在"学原理"这道坎上，原因是按学术教材的顺序从神经网络、反向传播一层层学，还没碰到Transformer就放弃了。对应用型学习，我建议把目标定成"建立直觉"而不是"推导一切"。下面五个直觉是必须的。

第一个核心直觉：大语言模型本质上是下一个词的预测器。给模型一段文本，它在内部计算的是下一个token应该是什么的概率分布。所谓生成，就是反复执行"根据前文预测下一个token，把预测结果拼回前文，再预测下一个"。这个机制决定了它天然不是知识检索器——它不会去数据库确认事实，只会根据训练时见过的统计规律，把最像答案的文本续写出来。理解这一点，你就明白幻觉为什么无法根除：只要概率最高的续写不等于事实，模型就可能一本正经地胡说。

第二个核心直觉：自注意力机制解决的是长距离参照问题。早年语言模型很难把句子末尾和开头的词关联起来，注意力机制让每个位置的token都能直接看到序列里所有位置的token，并自己决定"我更应该参考谁"。用生活化的例子说，就像开会时每个人发言后，其他人都能参考全场所有信息来组织语言，而不是只参考隔壁座位的人。

第三个核心直觉：注意力本身不分顺序，所以需要位置编码。把一句话的词全打乱，注意力结构看不出差别，因此必须把"第几个位置"的信息额外加进去，模型才能理解词序。早期Transformer用三角函数式的位置编码，后来出现了可学习位置编码、旋转位置编码等变体，本质都一样：给模型补上顺序感。

第四个核心直觉：训练是一步步来的，不是一次成型的。通常分为预训练、指令微调、对齐三个阶段。预训练阶段模型从海量文本里学语言规律，但它只会续写，不会回答——你给它"用户："它可能继续写下去，而不是认真回答问题。指令微调阶段用大量"指令+回答"的样本，让它学会以问答形式与人对上话。对齐阶段再按人类偏好筛选和优化，减少有害、编造和不合偏好的内容。你可以把这三步理解为：先让一个人博览群书，再教他学会问答礼仪，最后再让他懂得什么话不该说、怎么说大家才爱听。

第五个核心直觉：上下文窗口是硬件和训练设定共同决定的硬边界。模型能一次处理多长文本，由训练时的序列长度、显存条件等共同决定。超出窗口的部分会被截断，模型根本看不见。这个直觉会在你做RAG时反复用到，也是很多人第一次理解"为什么不能把整本手册塞给模型"的关键。

2.2 为什么原理会左右你后面的每一个决定

举几个我在实际项目里反复感受到原理起作用的例子。

当你理解了next-token预测机制，你就不会指望"把知识写进提示词里它就记住了"。提示词只是上下文，这次用完下次就没了。想让模型稳定知道某件事，要么每次把材料塞进上下文（这就是RAG），要么把知识固化进参数（这就是微调，成本高得多）。你会自然地倾向于先用前者。

当你理解了三阶段训练，你就明白为什么有些模型的对话感更好，而另一些更像补全器——这不是智商差异，而是后训练阶段用没用够指令数据。选模型的时候，除了看参数规模和基准分数，你还会多问一句：它到底经历了多少指令微调和偏好对齐。这个判断力能帮你避开很多"纸面很强、实际很怪"的模型。

当你理解上下文窗口的限制，你才明白RAG里为什么非要做切分和检索。不是偷懒，而是你根本没办法把整本手册塞进提示词，只能选出最相关的片段喂给模型。所以检索质量直接决定最终回答质量，这就是第4部分要花大力气讲检索的原因。

2.3 用一个最小实验验证你的理解

我建议新手在本地或者云上租一个很小规模的开放权重模型（大概0.5B到1B参数级别就够）做三件事。

第一，直接输入一句"中国的首都是"，观察纯补全行为，这和你平时在对话产品里体验到的感觉会完全不同。第二，把temperature从0调到0.7再调到1.5，看输出从保守稳定到随机发散的变化，体会采样参数如何影响生成。第三，用同一个问题变着法问：加不加"请回答"、加不加示例、加不加系统提示，观察输出差异。这三个实验做完，比闷头读五章理论都有用。

硬件上不用太焦虑。8G左右显存基本能跑一个小模型，没有独立显卡用CPU也能跑，只是慢一点。库的选择也简单：用开源推理库加载下载好的模型权重，写十几行代码就能完成一次生成。关键是迈出这一步，而不是等设备完美了再开始。

3. 动手第一站：提示词工程不是"会聊天"，而是"会定义任务"

3.1 提示词的结构拆解

提示词是你和模型交互时唯一能完全控制的输入。大部分人把它理解为"把话说清楚"，但在工程视角里，一个高质量提示词可以拆成四个清晰的部分。

系统提示和角色设定，告诉模型你希望它扮演什么角色、遵守什么约束；任务指令，说清楚要做什么，最好用动词开头，比如提取、总结、判断；输入材料，即你要处理的内容，一段文本、一份表格、一个用户问题都算；示例与输出格式，给模型兜底，让它明白答案长什么样。

很多时候我们以为模型笨，其实是提示词把模型搞糊涂了。举个我改过很多次的例子。一开始我写的是"帮我写一封催供应商交期的邮件"，信息太模糊，模型给了一封通顺但完全不能用的邮件。后来我改成这样：

你是采购部门的资深助理，沟通风格专业且不卑不亢。 任务：写一封催交期邮件，收件人是供应商的业务负责人。 背景：订单号 XK20240501 的物料原定本周五到货，但周一收到消息说要推迟两周。 我方底线：最多延迟一周，否则影响产线排期。 要求：语气礼貌但明确，给出我方底线，请对方两天内回复确认。 格式：邮件正文，不用称呼和落款，150字以内。

同样的模型，第二种输出的可用度提升非常明显。差别不在于话说得更客气，而在于你把任务、背景、约束、格式全都定义清楚了。这四件套才是提示词工程真正的抓手。

3.2 少样本示例和思维链：给模型一张"解题样例"

少样本示例（few-shot）是指你在提示词里放几条"问题-答案"对，让模型照着样例的格式和推理方式生成。它特别适合任务边界模糊的场景，比如"从用户反馈里判断情绪类别"，你给它三条标注好的例子，它大概率会按你的格式输出。

思维链（Chain-of-Thought）是另一种非常有效的技巧：在指令里要求模型先逐步思考再给出最终答案。为什么有效？因为语言模型倾向于直接跳到最顺口的答案，而显式要求它分步推理，相当于把计算路径从"即兴回答"切换成"草稿加复盘"。但要注意，思维链提高的是复杂推理任务的准确率，简单的分类任务用它反而可能出错、也浪费token。

这里最值得记住的一点是：提示词并不神奇，它是在给模型指定一条更有利的计算路径。你想让模型做什么，就把它展示得越具体越好。你写得越像一道有明确步骤的题，模型就越不容易天马行空。

3.3 没有评估的提示词优化，就是在碰运气

很多人的提示词优化流程是：改一句话，人工看一眼觉得好像不错就上线了。这是提示词工程里最常见的问题——你觉得不错，是因为你的测试问题太少。换一批真实用户问题，可能立刻翻车。

我建议至少准备10条、最好30条真实场景问题作为评估集，每条提前写好标准答案或检查要点。每次改提示词，把这30条全部跑一遍，记录每一条的通过或失败，再计算通过率。你可以写个简单脚本批量调用模型，把结果导出成表格，再逐条检查。

坚持用评估集做提示词迭代后，很多玄学就会被挤走。比如你会发现某类输入始终失败，于是针对那类输入补一个示例；你会发现模型总在格式上出错，于是你在输出格式里补一条"如果无法回答，只输出：无法回答"。这些靠"再试一次"可能永远试不出来，但有了评估集，一次就能定位。

4. 第二站：检索增强生成（RAG）——先学它，是因为它解决绝大多数业务问题

4.1 为什么RAG的优先级高于微调

我接触过的绝大多数LLM应用场景，本质上都是同一个问题：让模型基于我们自己的资料，用自然语言回答用户的问题。无论是内部知识库、产品文档还是营销素材，都逃不开这个模式。这个问题有两个难点：第一，模型没看过你的资料；第二，你不可能把全部资料一次性塞进上下文。

RAG的思路非常直接：每次回答问题前，先从资料库里检索最相关的片段，把片段拼进提示词，让模型基于这些片段作答。它最大的价值是以检索换知识。和微调相比，RAG在大多数场景下的优势几乎是一边倒的：

所以我在任何项目里都坚持同一个顺序：先做提示词，再做RAG，最后才考虑微调。如果RAG就能让模型基于你的资料稳定作答，就没有理由额外承担微调的硬件和迭代成本。

4.2 最小可用RAG链路怎么搭

一个最简单的RAG流程包含六个环节：加载、切分、向量化、索引、检索、生成。下面用伪代码把这六个环节串起来：

# 伪代码示意图，重点看流程不看具体实现 docs = load_documents("知识库目录") # 加载：PDF、Word、Markdown等 chunks = split_documents(docs, chunk_size=800, overlap=100) # 切分 vectors = embed_documents(chunks) # 向量化：把文本变成向量 index = build_vector_index(vectors) # 索引：方便快速查找 question = "报销流程里，发票丢失怎么办？" query_vector = embed_query(question) # 问题也向量化 hits = index.search(query_vector, top_k=4) # 召回最相关片段 answer = llm.generate( prompt_with_context(question, hits) # 把片段拼进提示词 )

这六步每一步都有坑。加载环节要注意PDF里的表格、图片、扫描件，它们经常不能正常解析；切分环节不能只看字数，还要尊重语义边界；向量化环节要选对嵌入模型，不同嵌入模型对中文、对领域术语的区分度差异很大；索引环节要决定用向量数据库还是普通内存索引，数据量小的时候后者完全够用；检索环节要调top_k，太少召回不全，太多会塞入噪声；生成环节要写清楚"只基于给定材料回答，材料里没有就说不知道"。

4.3 三个最容易翻车的工程细节

第一个是切分。很多教程会告诉你"每800字切一块、重叠100字"，这只是一个起点，不是真理。我踩过最典型的坑是：把一个表格或者一段连续的操作步骤拦腰切断，导致模型只能凭半截信息脑补后半段。后来我改成尽量按标题、章节、段落做结构化切分，实在不行再按字数兜底。切分原则应该是"宁可一个块稍大，也不要让一个完整语义被撕碎"。

第二个是嵌入模型的选择。通用嵌入模型对常见话题表现不错，但遇到公司内部的黑话和缩写，检索出来的片段可能完全不相关。这时候不要急着换向量数据库、调参数，先手动看几个"问题-召回片段"对：如果召回片段本身不相关，问题多半出在嵌入模型上。好的做法是准备一组领域检索样本，比较通用嵌入和领域微调嵌入的召回命中率，让数据替你选。

第三个是检索结果太多导致的"迷失在中间"效应。模型不是对所有上下文一视同仁的，塞给它8个不相干片段，它可能忽略真正关键的那一个。实测下来，对多数问答场景top_k用3到5比较合适，同时可以在提示词里写明"优先参考与问题最相关的片段"。如果召回结果太杂，再考虑加一道重排序步骤，先向量召回一大批，再用模型精排。

5. 微调：什么时候做、怎么做、以及大多数人其实不需要

5.1 微调负责"改变行为"，不负责"注入知识"

如果让我用一句话概括微调的适用范围，就是上面这句。它特别适合三类需求：格式强制，无论用户怎么问，都输出合法的JSON结构；风格对齐，用特定说话风格回复，比如客服话术；交互方式改变，把通用聊天模型调成信息抽取器或分类器。这三类需求的共同点是：模型原本也能做到一些，但做得不够稳定，你希望通过调整参数，把不稳定的能力变成稳定的默认行为。

但很多人期望微调去解决"让模型知道我们公司的产品知识"这个需求，这就麻烦了。微调相当于把知识写进权重里，你需要准备高质量、大规模、覆盖全面的数据去训练，而且一次知识更新，整个训练还要再来一遍。相比之下RAG只需把新文档放进资料库。所以我几乎总是建议：知识型需求走RAG，行为型需求才考虑微调。

5.2 LoRA与QLoRA：让单卡也能做微调的现实方案

全参数微调在百亿级模型上是绝大多数个人和中小团队负担不起的。这里要提两个技术名词：LoRA和QLoRA。

LoRA（低秩适配）的思路很聪明：微调时不更新模型的全部参数，而是把权重的更新量近似成两个小矩阵的乘积，只训练这两个小矩阵。直觉上就像给一个人做行为培训时不动他的全部知识储备，只在他身上贴一张很小的补丁，专门修正你要的那个行为。

QLoRA则是LoRA加上量化，把模型权重压到4位精度来节省显存，训练时再恢复成更高精度做计算。这样一来，原来需要多卡才能完成的微调，单张消费级显卡也能尝试。我见过很多项目的路径就是"先用QLoRA在几十万条数据上跑通，再用验证集对比效果，最后才决定要不要上全量微调"，这是很理性的做法。

实操建议：不要一上来就奔超大模型。先在较小规模、与你任务最接近的开源基座模型上试，跑一个epoch，看输出变化，再逐步扩数据量。微调不是玄学，但你至少要能控制变量，别同时换模型、换数据、换参数，否则出了问题根本不知道是哪一步引起的。

5.3 数据质量：微调成败的80%

很多教程会讲训练参数、学习率、批次大小，但微调真正决定成败的是数据。我在数据准备上吃过亏：一开始收集了一堆格式混乱、答案质量参差的样本，模型训练完确实听话了一些，但也沾染了样本里的错误表达，有些问题甚至答得更差了。后来把训练集清理到只剩几百条高质量样本，效果反而明显上升。

高质量训练样本有三个硬指标。第一是多样性，问题表述不能千篇一律，否则模型只学会了你这套模板，换一种问法就失效。第二是正确性，每一条标准答案都要经过人工检查，一个错误样本在训练里会被放大很多倍。第三是格式统一，指令、输出要遵循同一套标注规范，别一会儿让模型输出JSON，一会儿又让它输出纯文本。

训练时记得切一小块验证集出来。如果训练损失下降而验证损失升高，说明开始过拟合；如果模型输出变得机械、重复，往往也是数据多样性不足。微调完之后，拿同一套评估集做微调前后对比，不只看"变聪明了"，要看具体指标：格式正确率、领域问题准确率、拒答率，每一项单独打分。

6. 评估、踩坑与长期自我提升路径

6.1 给模型做"体检"：一套最简单的评估体系

我见过太多项目上线全靠"人工抽几条问题看看效果"，这种评估方式完全扛不住需求变更。自己建一套简易评估体系其实不难，四个维度就够了：

评估集怎么来？最可靠的方式是从真实业务问题里抽样，再人工标答案。哪怕先标50条，也比"拍脑袋测试10条"强得多。关键是让评估集保持稳定，提示词或模型一改，立刻就能跑出对比分数。有了这套机制，你做任何改动心里都有底。

6.2 我踩过的几个代表性坑

第一个坑是"模型变聪明了"的假象。某次微调后做评估，指标全面提升，大家都很兴奋。后来才发现评估集里的一部分问题跟训练样本几乎一样，模型相当于在背答案，一换新问题就露馅。教训是：评估集必须和训练集严格隔离，这应该成为红线。

第二个坑是"上下文越长效果未必越好"。做RAG时，我一度为了不漏信息把top_k调到10，结果模型被大量噪声片段干扰，回答质量反而下降。后来老老实实把top_k降到4，并在提示词里强调"只依据与问题最相关的片段回答"，效果立刻改善。加上下文不是免费午餐，每一条不相关片段都在稀释真正重要的信息。

第三个坑是中文PDF的解析。某次内部知识库问答项目里，扫描版PDF转出来的全是乱码和残缺表格，切分后检索到的片段毫无语义。这个坑不解决，后面调什么都白费。后来改成对扫描件做OCR，对文字版PDF按版式信息解析，才把数据源头稳住。做RAG一定要先审视源头文档的质量，否则整个链路都建立在沙子上。

第四个坑是"提示词改了一版，忘了回归旧问题"。新提示词在某类问题上效果变好，但其他类型全部退化，因为没有评估集，回归测试完全靠运气。这个教训让我最终养成了"每次改动都跑评估集"的习惯，无论改的是提示词、切分参数还是模型版本。

6.3 学完这些之后，继续往哪个方向走

如果你把前面几步都走了一遍，说明你已经不是LLM新手了。接下来可以按兴趣选进阶方向：想加深原理，就去复现一个极小的Transformer，在自己的数据上从头训练一个迷你语言模型，这会让你对损失曲线、收敛条件、数据配比有非常直观的认识；想深入工程，就去研究推理加速、KV缓存、量化推理、服务化部署；想走向多模态，可以尝试让模型理解图片和音频，这其实是在LLM基础上扩展编码器；也可以关注开放模型社区，看最新的模型卡、基准测试和技术报告，保持对新模型的判断力。

LLM这个领域更新太快，最好的学习方式是把核心原理和动手能力握在手里。之后每出现一个新模型，你都能快速评估它适不适合你的场景，而不是被它牵着走。

如果只让我留一条建议，那就是：把"跑通链路"放在"读完所有理论"前面。我至今记得第一次完整跑通RAG链路的感觉，模型给出的答案并不算完美，但它老老实实地把我资料库里的正确段落组织成了一段回答——那一刻我忽然明白了这个技术栈是怎么协作的。哪怕你手上的硬件很普通，哪怕只是租一台最小的云实例，也请动手把最小链路跑一遍。过程可能会狼狈，但收获会是几何级别的。