AI大模型从入门到微调：提示词、RAG与LoRA工程实践

第一次把一段两百多行的报错日志丢给AI大模型，让它整理成结构化摘要的时候，我是抱着看笑话的心态的。结果它几十秒就还给我一份按错误类型分组的清单，连哪几行是同一个根因引发的连锁反应都标出来了。那天之后我改了一个习惯：凡是重复性、模式化、需要从一堆乱七八糟的信息里提炼结构的工作，先想想能不能交给模型。这篇内容写给那些听过很多次"AI大模型"却一直没找到下嘴地方的读者，也写给已经用过几次对话产品、想再往深处走一步但被各种名词劝退的人。从我在实际项目里踩过的坑出发，把从零基础到能自己动手改模型这条路径拆开讲清楚，硬件、环境、提示词、微调、检索增强、评估，一个都不跳过。

1. 大模型到底在做什么：把"预测下一个字"这件事看透

1.1 自回归生成：一个字一个字往下猜

很多人把大模型想象成一个知道很多事情的知识库，输入问题它就去库里翻答案。这个理解偏差是后面一切困惑的源头。大模型做的事情本质上只有一件：给定前面已经出现的文字序列，预测下一个最可能出现的词元。生成一段话的过程，就是把"预测下一个、拼上去、再预测下一个"这个循环重复几十上百次。

理解了这一点，很多现象就顺了。为什么模型有时候会说得很流畅但内容不对？因为它优化的目标是"下一个词在统计上合理"，不是"这句话在事实上正确"。为什么同样的提示词两次运行结果不一样？因为采样过程中有随机性，模型输出的是概率分布，不是确定值。为什么上下文里给的信息越具体，回答质量越高？因为你把"下一个词该往哪走"的搜索空间收窄了。

我在带新人的时候经常用一个类比：模型像一位读遍了海量文本、但从没真正出过门的博学之人。它知道"下雨天要带伞"这个说法在文本里高频共现，但它没淋过雨。所以它能帮你写、帮你改、帮你类比、帮你把散乱信息整成结构，但它对"事实"没有天然的校验机制。你要做的是给它足够准确的上下文，以及在关键结论上自己把关。

1.2 注意力机制解决了什么问题

早年的文本模型处理长句子时有个硬伤：读到句尾，句首的信息已经衰减得差不多了，就像你听一段很长的口述，中间走神了一下，后面全靠猜。注意力机制的核心作用，是让模型在生成每一个词的时候，能够回过头去"看"输入序列里的所有位置，并按相关程度分配权重。

这个机制的直观效果是：模型能处理指代、能抓住长距离的依赖关系。你写"张三把报告交给李四，因为他要出差"，模型能通过注意力权重判断"他"更可能指向谁。当然，这种判断是统计意义上的，不是逻辑推理。

现在主流的模型结构基本都建立在Transformer这套思路之上，区别在于层数、隐藏维度、注意力头的数量、以及是否采用混合专家等变体。对入门者来说，没必要一上来就啃论文里的每一个公式，但有几个概念必须建立直觉：词元是模型处理的最小单位；嵌入是把词元映射成向量；注意力是让向量之间互相交换信息；前馈网络是对每个位置做非线性变换。这四件事串起来，就是一个基本层，堆几十层就是模型的主体。

1.3 能做什么与不能做什么：边界认知

我见过太多项目失败在起步阶段，原因不是技术不行，而是对模型能力的预期错位。把边界划清楚，比学十个技巧更有用。

模型擅长的：文本分类与抽取、摘要与改写、格式转换、代码补全与解释、多轮对话中的意图理解、把非结构化内容整理成表格或JSON、基于给定材料的问答。

模型不擅长的：需要精确计算的任务（除非调用外部计算工具）、需要实时事实的任务（除非接入检索）、需要严格遵循复杂业务规则的任务（除非把规则完整写进提示词并做充分测试）、需要长期记忆的任务（上下文窗口之外的信息它确实看不到）。

提示：判断一个任务适不适合交给模型，先问自己一句——这个任务如果交给一个聪明但没有业务背景的实习生，给他足够的参考资料，他能不能做对？能，大概率模型也能；不能，先别急着上模型。

2. 第一周怎么起步：硬件不到五千块也能跑通全流程

2.1 硬件与软件环境的最低配置

入门阶段最容易被劝退的一句话是"没有几张卡别玩大模型"。这话对训练成立，对入门完全不成立。你要跑通从调用到微调的完整链路，一台带独立显卡的普通笔记本就够起步了，甚至只有核显的机器也能通过量化后的模型完成推理体验。

我给新人的配置建议分三档。第一档是纯体验档：任何一台能上网的电脑，走调用接口的路线，零硬件门槛。第二档是本地推理档：显存8G起步，能跑量化后的中等规模模型，速度可接受。第三档是微调实验档：显存16G到24G，能对中小规模模型做轻量微调。

软件环境的搭建思路是这样的：先装Python，建议3.10或3.11版本，太新的版本有些库还没跟上；再用虚拟环境管理工具隔离依赖，避免不同项目之间打架；然后装深度学习框架和推理相关的库；最后按需装本地推理工具。这一步的坑主要在两个地方：一是显卡驱动和计算库版本不匹配，症状是库装上了但检测不到显卡；二是国内网络环境下部分依赖下载慢，需要配置镜像源。

# 环境隔离的通用做法 python -m venv llm_env source llm_env/bin/activate # Windows 下用 llm_env\Scripts\activate # 验证环境是否正常 python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

如果最后一行打印出True，说明显卡通路是通的；打印False，先别急着往下走，回头检查驱动和计算库版本。这个检查我每次开新环境都会做一遍，能省掉后面大量莫名其妙的报错。

2.2 三条上手路线：网页、API、本地

入门者经常纠结"到底该从哪条路开始"。我的建议是三条路都摸一遍，但顺序有讲究。

第一条是网页对话路线，零成本，适合建立直觉。用一两周时间，把它当成一个随时在线的陪练，练提问、练改写、练让它解释概念。这个阶段的目标不是学技术，是建立对模型脾气的感觉：什么样的问法它答得好，什么样的问法它会跑偏。

第二条是接口调用路线，适合马上要落地功能的人。核心就三件事：拿到访问凭证、构造请求体、解析返回结果。请求体的结构大同小异，通常包含模型标识、消息列表、温度参数、最大输出长度这几个字段。消息列表里区分角色，一般有系统指令、用户输入、模型回复三类。系统指令用来设定整体行为，用户输入是具体任务，历史回复用于多轮上下文。

import requests, json payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一名严谨的技术文档编辑，只输出JSON，不输出多余解释。"}, {"role": "user", "content": "把下面这段报错日志按错误类型分组：..."} ], "temperature": 0.2, "max_tokens": 1024 } resp = requests.post("https://your-endpoint/v1/chat", headers={"Authorization": "Bearer YOUR_KEY", "Content-Type": "application/json"}, data=json.dumps(payload), timeout=60) print(resp.json())

这段代码里的几个参数值得说清楚：温度控制随机性，做抽取类任务时调低，做创意类任务时调高；最大输出长度决定单次回复的上限，设太小会出现回答被截断的情况，我第一次接接口时就栽在这上面，日志里明明有内容，返回却是半句话。超时时间也要给足，大模型生成长文本本来就慢。

第三条是本地推理路线，适合对数据隐私有要求或者想深入调参的人。本地推理的价值在于你可以完全掌控输入输出，可以做离线实验，可以观察模型在不同参数下的行为差异。具体路线下面第四章展开。

2.3 Token与上下文窗口：新手最容易忽略的账本

词元是模型处理文本的最小单位，一个汉字通常对应一到两个词元，英文单词可能被拆成多个词元。这个单位看起来抽象，但它直接决定了三件事：成本、长度限制、以及模型对输入的理解粒度。

成本账很好算：输入词元数乘以输入单价，加上输出词元数乘以输出单价。很多人只算输入不算输出，实际使用中输出往往更长。我做过一个统计，同样一段两千字的文档处理任务，输出摘要通常只占输入的十分之一，但如果让模型做逐条改写，输出体积会超过输入。

长度限制是更隐蔽的坑。每个模型都有一个上下文窗口上限，超出部分会被截断，而截断往往发生在你最不希望的位置。处理长文档时，正确做法是先切分、再分别处理、最后汇总，而不是把整本书硬塞进去。切分的时候要留重叠，避免关键信息正好被切在边界上。

注意：调接口时如果发现回答质量和预期差距很大，第一件事是打印出实际发出的词元数，确认内容没被截断。这个检查我做过不下二十次，每次都能查出点东西。

3. 提示词工程：把话说清楚比堆参数有用得多

3.1 一个能落地的结构化提示模板

提示词不是玄学咒语，它的本质是给模型提供足够的上下文约束，把"下一个词该往哪走"的搜索空间收窄到你要的方向。我带团队时强制推行一个四段式模板，效果比随意提问稳定得多。

第一段是角色与目标。明确告诉模型它在这轮对话里扮演什么角色、要完成什么任务。"你是一名审校编辑"和"帮我看看这段文字"，后者的输出会散得多。

第二段是输入材料。把你希望模型处理的内容原样放进来，并且用清晰的分隔符标出边界。分隔符我习惯用三个连续符号包住内容，或者在材料前加一行标注。这一步的意义是让模型知道哪部分是"要处理的东西"，哪部分是"处理的要求"。

第三段是输出规范。格式、长度、语气、是否允许解释、是否允许省略，全部写清楚。做结构化抽取时，直接把目标JSON的字段结构写出来，比说"输出JSON格式"有效十倍。

第四段是边界与例外。告诉模型遇到不确定的情况怎么办，遇到超出范围的问题怎么答。这一条最容易被忽略，但它恰恰是减少胡编乱造的关键。"如果材料中没有相关信息，直接输出'未找到'，不要推测"这句话，我几乎每个生产环境的提示词里都会加。

3.2 少样本示例的写法和坑

给模型看几个例子，比写十段描述更有效，这叫少样本提示。做分类任务时尤其明显：你描述半天"这段话属于投诉还是咨询"，不如直接给三条标注好的样例。

示例的写法有几个讲究。数量上，两到五个通常够用，太多会挤占上下文还容易引入噪声。覆盖面上，示例要能覆盖边界情况，比如分类任务里最容易混淆的那两类，一定要各给一个例子。顺序上，示例的排列会影响模型的偏好，最后一个示例的影响往往最大，所以别把最特殊的那个放最后。

坑主要在两个地方。一是示例本身有错，模型会照着错的学，而且学得很像。二是示例格式不统一，比如前两个例子输出带解释、第三个不带，模型会随机选一种，导致输出不稳定。我见过一个项目，示例里有一条标错了类别，结果模型对那一类的识别率掉了将近三成，排查了两天才发现是示例的锅。

3.3 提示词的版本管理与回归测试

提示词是要进版本库的，这一点很多人不习惯。我现在的做法是：每个提示词存成独立的文本文件，文件名带版本号，改动记录写清楚改了什么、为什么改、改完之后哪几个用例的表现变了。

配套要有一套小的回归测试集。挑二十到五十条有代表性的输入，涵盖正常情况、边界情况、容易出错的情况，每次改提示词之后全部跑一遍，人工或自动比对输出。没有这套东西，你改一个词可能修好了A场景却弄坏了B场景，自己还浑然不觉。

温度参数也要跟着任务走。抽取、分类、格式转换这类需要确定性的任务，温度调到零附近；创意写作、头脑风暴这类需要多样性的任务，温度可以调高。同一个提示词配不同温度，效果可能差出一个档次，别指望一套参数打天下。

4. 从会用到会调：本地部署与LoRA微调的实操逻辑

4.1 本地推理路线的选择与量化

本地跑模型，核心矛盾是显存和效果之间的权衡。一个原始精度的大模型动辄几十上百G，普通显卡根本装不下，所以必须量化。量化的本质是把模型权重从高精度浮点数压缩成低精度整数，牺牲一点点精度换取大幅度的体积和速度优化。

常见的量化档位是四位、五位、八位。四位量化能把模型体积压到原始的四分之一左右，对多数任务的效果损失在可接受范围内，是入门首选。八位量化效果更接近原始模型，但体积也更大。选择的时候先看你显卡能装下什么，再看任务对精度的敏感程度。做摘要、改写这类任务，四位量化基本够用；做需要精确遵循格式的抽取任务，如果发现输出格式稳定性下降，可以试试更高精度。

本地推理工具的选型思路是看三点：是否支持你手上的量化格式、是否有易用的接口、是否能利用你的硬件加速。我一般先用最轻量的方案跑通，确认模型本身在你的任务上表现可以，再考虑换成更重的推理引擎做性能优化。顺序反了容易在环境上耗掉大量时间，还没验证模型价值。

启动本地服务之后，对外提供的接口通常和在线接口的结构兼容，这样你前面写的调用代码几乎不用改就能切换。这个设计很实用，意味着你可以先用在线接口做原型，效果验证之后再迁到本地。

4.2 LoRA到底改了模型的哪一部分

微调听起来吓人，但LoRA这套方法把门槛降得很低。它的思路是不动原始权重，而是在模型的部分层旁边挂两个小矩阵，训练时只更新这两个小矩阵，原始权重冻结。推理时把两个小矩阵的乘积加回原权重。因为小矩阵的参数量远小于原模型，显存和时间成本都大幅下降。

这带来几个实际好处：训练出来的适配器文件通常只有几十到几百兆，方便保存和切换；同一个底座模型可以挂多个适配器，做不同任务时换着用；训练失败了对底座没影响，重来成本低。

什么时候该微调，什么时候不该？我的判断标准是这样的：如果你只是想让模型按特定格式输出、或者扮演特定角色、或者遵循几条规则，先用提示词解决，解决不了再考虑微调。微调真正有价值的场景是：任务涉及大量领域专有表达，提示词里塞不下；或者需要模型学到某种固定风格，光靠描述学不会；或者对延迟有要求，希望减少提示词长度。

微调的数据准备比训练本身更耗时。经验值是一千到几千条高质量样本就能看到明显效果，但"高质量"三个字很贵。样本要覆盖任务的真实分布，标注要一致，格式要统一。我见过最典型的失败案例是：训练集里全是理想情况的样本，上线后遇到稍微复杂一点的输入就崩，因为模型没见过。

4.3 显存估算：一张表算清楚要多少卡

新手最常问的问题是"我这个配置能跑多大的模型"。下面这张表是经验值，实际会因框架和优化策略有浮动，但用来做初步判断够用。

估算的基本逻辑是：推理时显存主要被模型权重和上下文缓存占用，序列越长缓存越大；训练时还要额外存梯度和优化器状态，所以同样规模的模型，训练比推理吃显存得多。想省显存，招数有几个：降低批大小、缩短序列长度、开启梯度累积、用更激进的量化。梯度累积这个技巧值得单独说：它让你用小批大小模拟大批大小的效果，代价是训练变慢，但对显存有限的人是救命的。

5. 让模型回答私域问题：RAG落地时真正决定效果的细节

5.1 文档切分比模型选择更重要

模型不知道你公司内部的制度文档，也不知道你项目里的接口约定。让它回答这类问题，最直接的办法是把相关资料找出来塞进上下文，这就是检索增强生成的基本思路。很多人以为这套东西的瓶颈在模型，实际做下来，效果差异的大头在检索和切分。

切分策略直接决定检索能不能命中。切得太碎，一段话被拆成三句，语义不完整，检索出来也是断章取义；切得太粗，一整章塞进去，噪声太多，模型抓不住重点。我的经验值是每块三百到八百字，按语义边界切，比如按段落、按小节标题。技术文档里表格和代码块要单独处理，别硬按字数切，切坏了信息就废了。

还有一个容易被忽略的点是元数据。每块文本最好带上来源、章节、时间这些属性。检索的时候可以先用元数据过滤再算相似度，效果比纯向量检索稳得多。比如用户问的是某年某版本的规范，先按版本过滤，再在候选里做语义匹配，命中率能提高一大截。

5.2 检索质量的三个可量化指标

做检索增强最怕的是"感觉还行"。我建议从第一天就建立量化评估，哪怕样本只有几十条。核心看三个指标：召回率、命中位置、以及最终回答的可用率。

召回率是最基础的：正确答案所在的那块文本，有没有出现在检索返回的候选里。这个指标低了，后面模型再强也白搭。命中位置看的是正确文本排在第几位，排得太靠后，塞进上下文时可能被截断。最终回答可用率是人工判断，看生成的答案是否基于检索到的材料、是否准确。

评估集的构造方法是：从真实用户问题里采样，为每个问题标注出对应的正确文档块。二三十条就能看出趋势。每次调整切分策略、换嵌入模型、改检索参数，都跑一遍这套评估。我经历过一次，换了个嵌入模型，主观感觉回答变好了，跑完评估发现召回率反而降了，原因是新模型对短查询不敏感。没有这套数据，这种问题根本发现不了。

5.3 最小可用RAG链条的搭建思路

一条最小可用的链路包含四步：切分、向量化、检索、拼接生成。每一步都有便宜的做法和讲究的做法的区别，入门阶段先用便宜的做法跑通，再逐步优化。

切分这一步，先用基于规则的方案，按标题和段落切，控制在目标字数范围内，块之间留一成到两成的重叠。向量化这一步，选一个通用嵌入模型，把每块文本转成向量存起来，存的地方可以是简单的向量索引，数据量小的直接用内存里的数组都行。检索这一步，把用户问题也转成向量，算相似度，取前几名。拼接生成这一步，把检索到的文本块按相关度排序，拼进提示词，明确告诉模型"只根据以下材料回答，材料里没有的说不知道"。

# 检索环节的核心逻辑示意 def retrieve(query, index, top_k=5): q_vec = embed(query) scores = [cosine(q_vec, v) for v in index.vectors] ranked = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True) return [index.chunks[i] for i in ranked[:top_k]] # 拼接时的提示词骨架 prompt = """根据以下材料回答问题。材料中没有的信息，回答"未找到相关内容"，不要推测。 材料： {context} 问题：{question} """

这套东西跑通之后，优化方向按性价比排序：先优化切分，再优化检索的候选数量和重排，最后才考虑换更大的模型。顺序反了容易花大钱办小事。

6. 新手最容易栽的坑：一份实测清单

6.1 模型选型与量化参数陷阱

选模型时最常见的误区是唯规模论，觉得参数越大越好。实际选型要考虑任务难度、延迟要求、成本预算三者的平衡。一个七B级别的模型在明确的任务上，配好提示词，效果可能超过一个更大但没调好的模型。我做过一个对比，同样是结构化抽取任务，小模型配合精确的示例和格式约束，准确率和响应速度都更优，因为大模型的输出更"自由"，反而需要更多后处理。

量化参数的坑在于盲目追低。四位量化不是万能的，有些模型在四位量化后对数字和格式的敏感度会下降。判断方法是拿你的评估集分别跑原始精度和量化版本，看关键指标掉多少。掉得厉害就升精度或者换模型，别硬扛。

另一个坑是忽略模型的上下文长度限制和训练数据的时间边界。前者导致长文档处理被截断，后者导致模型对较新的事件一无所知。这两个限制在选型时就要确认清楚，写进技术方案的约束条件里。

6.2 幻觉处理与效果评估

幻觉是模型一本正经地输出不存在的信息，这是自回归生成机制的固有特性，不可能完全消除，只能管理和缓解。缓解手段按有效性排序：一是把材料放进上下文并明确要求只根据材料回答；二是要求模型在给出结论时附上依据的原文片段；三是对关键结论做二次校验，可以用另一个模型实例做交叉检查；四是在产品层面加免责说明和人工复核环节。

效果评估要尽早做，而且要用真实数据。我建议从项目第一天就攒一个评估集，哪怕只有三十条。每次改动模型、提示词、检索策略都跑一遍，记录指标。这套习惯能让你在别人还在争论"感觉哪个好"的时候，拿出数据说话。

评估指标要跟业务目标对齐。做抽取任务看字段准确率和召回率，做问答看答案正确率和拒答率，做生成任务看人工评分。指标选错了，优化方向就会跑偏。比如一个客服问答系统，如果只看回答像不像人话，不看有没有解决用户问题，最后会优化出一个话术漂亮但没用的东西。

6.3 学习路线图与时间分配建议

最后说说时间怎么分配。以每天投入两小时计，我的建议是：前两周建立直觉，大量使用对话产品，体会模型的能力边界；第三到第五周练提示词，把四段式模板用熟，开始攒自己的提示词库和评估集；第六到第八周跑通接口调用，做一个能实际用的小工具，比如文档摘要器或者分类器；第九周之后按兴趣选方向，想深入效果优化就走检索增强，想深入模型本身就走本地部署和微调。

每个阶段都要有产出物，不要只看不练。第一阶段的产出是一份"模型能做什么不能做什么"的清单，第二阶段的产出是一个提示词库加一套测试用例，第三阶段的产出是一个能跑的脚本，第四阶段的产出是一份效果对比报告。有产出物，学习才不是浮在表面。

提示：不要试图把所有方向都学一遍。大模型这个领域分支太多，一个人不可能全占。选一个跟自己工作最相关的方向扎下去，其他方向知道概念、能跟人对话就行。

我个人在实际操作中的体会是，这个领域最大的门槛不是数学，也不是工程，而是耐心。模型的行为有随机性，调一次不行很正常，关键是有没有建立一套可以复现的评估方法，让你知道每次改动到底带来了什么变化。很多半途而废的人不是学不会，是改了半天不知道有没有变好，最后失去了方向感。把评估这套东西搭起来，路会好走很多。