LLM微调实战：从LoRA训练到AI分身微信接入的全流程指南

最近我把“AI分身”这个东西完完整整做了一遍，不是套壳调API，而是从语料整理开始，用开源基座模型做LoRA微调，再把模型服务化，最后接进IM生态。项目的标题很直白：LLM微调实战Demo——实现自己的AI微信分身。简单说就是训练一个能模仿我聊天习惯的对话模型，然后让别人能在聊天窗口里和它对话。这个方向听起来挺玄，拆开之后其实就是三条线：数据、模型、接入通道。数据决定了分身像不像你，微调决定模型能不能学会你的表达习惯，通道决定它最终出现在哪里。

这篇文章主要面向对LLM微调有兴趣、但还没完整跑通过一条链路的开发者。适合两类人：一类是从未做过微调，想找一个有实际意义、不枯燥的入门项目；另一类是已经会调用大模型API，但想搞明白“自己训一个模型”到底是怎么回事的初学者。我会把从数据清洗、训练参数、推理服务到IM合规接入的完整路径展开，最后附上我在实际操作中踩过的坑和排查经验。

1. 项目整体设计：先把“AI微信分身”这棵树拆开

1.1 这个Demo到底要做什么，不做什么

“AI微信分身”最容易让人想到的是那种接管个人微信、自动回复消息的外挂。这里我先说清楚边界：这个Demo不碰个人微信自动化。个人微信的自动化操作违反平台规则，轻则封号，重则有合规风险，不管是商用还是自用，都不值得为这个项目去踩线。那么“微信分身”怎么落地？我的解法是走合规路线：用LLM微调出一个拥有你语言风格的对话模型，把它做成一个标准的HTTP服务，再通过微信生态内允许的官方接口或一个独立的网页聊天窗来展示效果。

明确了不做什么，剩下要做什么就清晰了。这个Demo的核心目标有四条：

• 准备一套属于自己的、可公开分享的对话数据集。
• 基于开源基座模型做LoRA微调，让模型输出风格明显偏向自己。
• 把微调后的模型封装成OpenAI兼容的推理服务，任何第三方客户端都能直接调用。
• 用一个合规的展示载体，让“分身”真正出现在对话窗口里。

之所以这样定义，是因为微调本身是一个“模型工程”问题，而接入IM是一个“生态合规”问题。两者混在一起容易翻车，分开做更容易成功。

1.2 核心链路选型：为什么先数据、再模型、最后接入

整条链路我按四个模块来设计：语料模块、微调模块、推理服务模块、接入模块。顺序不能乱，数据准备必须排第一。原因很简单：微调模型的质量上限完全由数据决定。基座模型本身已经很聪明，LoRA微调不是教它新知识，而是教它“说话的方式”。如果你给的数据是一堆零散、无上下文的句子，模型学到的就只有碎片化的措辞，聊不了几句就崩。所以我花了大约三分之一的时间在数据处理上，训练反而只用了几个小时。

微调方案选LoRA（Low-Rank Adaptation）而不是全参数微调，是我权衡之后的决定。LoRA只训练注入到模型各层的一小部分低秩矩阵，显存占用小，训练速度快，消费级显卡就能跑。而且同一个基座模型可以挂多个LoRA适配器，相当于一个底座上可以随时切换不同的“人设”，这对后续做多分身场景很实用。全参数微调在这个数据量级下收益不明显，还容易把模型训坏，个人项目没必要冒这个风险。

推理服务模块做成OpenAI兼容格式，是我认为这个项目里最有“性价比”的设计决策。现在几乎所有机器人框架、聊天插件、自动化工作流都兼容这套协议。做到这一步之后，接微信是一个适配层，接网页是一个适配层，接企业内部工具也是一个适配层，之后想怎么扩展都方便。接入模块则选了两条路并行：一条是合规的企业IM自建应用接入，另一条是本地网页聊天窗演示。两条路共用同一个推理后端，切换成本很低。

2. 语料准备：AI分身的“人设”从哪来

2.1 语料来源与收集思路

我见过不少第一次做微调的人，上来就问“用什么模型”，其实最该问的是“拿什么数据训”。数据来源不用太纠结，核心原则是：必须大量来自你自己，并且能代表你真实的语言习惯。我常用的来源有几个：

• 社交平台上自己公开发布过的文字内容，包括长文、短评、回复。
• 聊天记录里自己写过的长段落回复。注意只截取自己的发言，不包含对方内容，避免涉及他人隐私。
• 过去写过的个人日志、周报、博客草稿，去掉敏感信息后也是很好的风格样本。

有开发者做过一个案例：把他一年内公开发布的所有文字、聊天里自己写过的完整回复、加上自己写的几篇长文，去掉重复内容后整理出约1.2万条有效样本。这个规模对7B量级的LoRA微调来说很够用。太少（低于2000条）的时候分身只会学到几个口头禅，太多（超过5万条）个人项目往往没精力清洗。

这里有一个经验：不要只收集“完美回复”。聊天记录里那些犹豫、反问、甚至是打错字又重新纠正的片段，恰恰是最有人味的部分。模型如果把你的高频表达习惯学到位，它说话才会像你，而不是像一个标准客服。我会在数据里刻意保留一部分真实的、有小瑕疵的表达，实测下来生成的文本反而更自然。

2.2 数据清洗脚本怎么写：三步把聊天记录变成训练样本

数据清洗这一步，不同平台导出的格式千差万别，但处理逻辑是通用的。我按最常见的文本导出格式来演示：每行一条消息，空行分隔不同对话。下面是一个可以直接改改就用的清洗脚本框架。

import json import re def load_chat_text(path): # 假设是从某平台导出的纯文本消息记录 with open(path, "r", encoding="utf-8") as f: lines = f.readlines() return lines def is_valid_line(line): # 过滤掉时间戳、系统通知、链接和过短的消息 if re.search(r"\d{4}-\d{2}-\d{2}", line): return False if "系统消息" in line or "撤回了一条消息" in line: return False if len(line.strip()) < 4: return False return True def segment_dialogues(lines, max_turns=6): """把连续文本切成多轮对话片段，超过max_turns就断开""" dialogues = [] current = [] for line in lines: line = line.strip() if not line: if len(current) >= 2: dialogues.append(current) current = [] continue if not is_valid_line(line): continue if len(current) >= max_turns: dialogues.append(current) current = [] current.append(line) if len(current) >= 2: dialogues.append(current) return dialogues def to_training_samples(dialogues): samples = [] for rows in dialogues: turns = [] # 简单按奇偶交替分配角色，实际使用时你需要根据你的来源标记角色 for i, text in enumerate(rows): role = "user" if i % 2 == 0 else "assistant" turns.append({"role": role, "content": text}) samples.append({ "conversation": turns, "source": "personal-chat" }) return samples if __name__ == "__main__": lines = load_chat_text("raw_chat.txt") dialogues = segment_dialogues(lines, max_turns=6) samples = to_training_samples(dialogues) with open("train.jsonl", "w", encoding="utf-8") as f: for s in samples: f.write(json.dumps(s, ensure_ascii=False) + "\n") print(f"共生成 {len(samples)} 条训练样本")

脚本的思路是：先过滤杂讯，再切对话块，最后转换成统一的JSONL格式。训练样本的结构采用多轮消息数组，和ChatGPT的数据结构保持一致，这样后续喂给微调框架时不需要再做格式转换。建议把max_turns控制在4到8轮之间，太长会超出模型的上下文窗口，太短则学不到对话的连贯性。

清洗环节最容易犯的错是“过度清洗”。有的人把语气词删了、把口语化的重复表达改了、把错别字修正了，最后留下的是一堆标准书面语。这等于把分身的灵魂给洗掉了。我的建议是：删除的优先级从高到低应该是“隐私信息 > 情绪垃圾 > 平台杂讯 > 口语化表达”，千万不要反向操作。

2.3 脱敏与合规边界：哪些内容不能进数据集

很多人第一次收集语料时热血沸腾，把一整年的聊天记录全导出来直接训练，这是一个非常危险的信号。聊天记录里不仅有你的隐私，还有对方的隐私。即便只是为了自己玩，你也不知道模型在微调过程中记住了什么、会在什么场景下被输出。所以我在这个项目里立了几条规矩：

• 除了自己的发言外，不保留任何真实他人的完整发言。
• 删除所有人名、昵称、手机号、地址、公司名等可直接定位到人的信息。
• 删除吐槽他人、情绪极端发泄、两性话题等敏感内容。
• 对于拿不准的内容，一律不放进数据集。

这一步没有捷径，只能靠关键词过滤加人工抽检。我自己的做法是：脚本先跑一遍正则把手机号、邮箱、链接清掉，再人工浏览一遍所有样本，看到拿不准的整条删除。数据量在1万条左右时，人工过一遍大约需要三到四小时，但这份投入是值得的。模型训练完之后，你很难精确控制它什么时候会吐出什么，所以源头把控才是唯一可靠的防线。

3. 微调实战：用LoRA把基座模型调成你的风格

3.1 基座模型选择：7B量级开源模型最适合入门

到了选模型这一步，不要跟风选最大的。我的选择标准有三个：社区生态成熟、显存要求友好、在中文对话上有基本盘。7B参数量的开源基座模型是目前性价比最均衡的档位。它在消费级显卡上跑得动，部署推理不需要专用服务器，数据量要求也在个人能力范围内。

硬件方面，我实测下来：一张24GB显存显卡跑LoRA微调非常舒服，batch size和序列长度都可以给得比较足；16GB显存也能跑，但需要配合梯度累积和4bit量化；如果你一张显卡都没有，用云GPU实例按小时租借也是常见做法，训练3个epoch大约需要几小时，费用在可接受范围内。

为什么不上13B或更大？因为个人项目的语料量通常在1万到3万条左右。这点数据量对7B模型来说足够调教风格，但想充分训练更大的模型则显得力不从心。数据规模决定了模型规模的上限，这句话在个人项目里体现得特别明显。另外，7B档位的推理速度明显更快，做实时聊天体验更好。

3.2 训练参数与关键配置：一组实测可跑的配置

微调任务里，参数不会直接告诉你“哪个一定最好”，但有一套很稳的起点组合。我把项目里实测可用的配置整理成了一张表，这张表适用于1万条数据、7B基座模型、LoRA微调的典型场景。

训练脚本和超参配置，我直接写在下面的代码里。这里用的是一个通用的开源微调框架，它内部帮你处理了LoRA注入和训练循环，省去自己造轮子的麻烦。唯一需要你改的是数据路径和几个核心参数。

from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments # 这里导入你选择的微调框架、LoRA配置等 from peft import LoraConfig, get_peft_model dataset = load_dataset("json", data_files="train.jsonl", split="train") # 假设数据已经是多轮消息格式，需要按基座模型的chat template拼装 def format_chat(example): # 具体实现取决于基座模型的tokenizer text = tokenizer.apply_chat_template(example["conversation"], tokenize=False) return {"text": text} dataset = dataset.map(format_chat) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", ) training_args = TrainingArguments( output_dir="./checkpoints", num_train_epochs=3, learning_rate=1.5e-4, logging_steps=50, save_steps=200, per_device_train_batch_size=1, gradient_accumulation_steps=16, lr_scheduler_type="cosine", warmup_steps=100, bf16=True, ) model = AutoModelForCausalLM.from_pretrained("your-base-model") model = get_peft_model(model, lora_config) model.print_trainable_parameters()

target_modules这块，不同的基座模型结构有差异，通常LoRA会作用在注意力层的query、key、value、output投影上。如果你使用的是某个以transformers为底座的模型，这几个模块名一般不会变。如果模型结构特殊，可以在训练日志里确认一下哪些层被注入了LoRA，确保不是零个可训练参数。

3.3 训练过程与损失观察：loss降了不代表人设对了

训练过程中的观察点非常关键。我第一次跑的时候，盯着loss曲线从2.1降到1.3，以为大功告成，结果打开测试对话发现模型说的话干巴巴的，根本没有自己的语气。教训就是：回归loss只是建模质量的指标，不是风格相似度的指标。

训练时要看两件事。一是loss是否在持续下降并最终收敛，这说明模型确实从数据中学到了东西。二是每个checkpoint保存后，马上用同一批测试问题去问它，看输出风格变化。我会在训练过程中准备20个固定的测试问题，比如“你现在心情怎么样”“周末有什么安排”“推荐一部电影”，每个checkpoint都问一遍。观察从第1个epoch到第3个epoch，输出是不是越来越像自己的语气。

另一个容易踩的坑是过拟合。模型到了后期，不是学会“怎样像你说话”，而是把训练数据里的原句背了下来。判别方法很简单：用训练集里没有的新问题去问它，如果它依然能自然组织语言，说明是学到了风格；如果它经常原封不动地复述训练数据里的句子，那就说明过拟合了。遇到这种情况，我一般会减少epoch数，或者加大LoRA dropout。

训练完成后，LoRA适配器会单独保存。我建议不要把最后一步的checkpoint当成唯一答案，而是多保存几个中间的checkpoint，最后在验证集上对比挑选。选一个“在最像你的前提下、仍然能流畅回答陌生问题”的版本，通常它就是最佳平衡点。

4. 推理服务化：让微调模型变成可调用的AI接口

4.1 合并LoRA权重与4bit量化：让部署门槛降下来

微调之后，模型的权重分为两部分：基座模型权重和LoRA适配器权重。在推理阶段，你有两个选择：一是直接用支持LoRA加载的推理框架实时合并，每次加载时把适配器“插”到基座上；二是把LoRA权重合并回基座模型，导出一个完整的模型文件。

我建议做成合并导出，理由有三点。第一，合并后的模型不依赖微调框架，部署时更干净；第二，可以直接做量化压缩，把7B模型从FP16的约14GB显存占用压到4bit量化后的约6GB；第三，后续接入任何服务端，都不需要额外依赖LoRA运行库。

量化的选择上，4bit量化是这个项目的甜点位。它的显存占用低到消费级显卡可以轻松推理，速度也快，而对话质量相比FP16只有极轻微的损失。对于聊天分身这种场景，质量和速度的平衡点很明显：量化后能更流畅地响应消息，远比那一点点理论上的质量差异重要。

4.2 搭建OpenAI兼容服务：五分钟跑通一个聊天接口

我选择用FastAPI来搭建推理服务，主要看中它的轻量和高性能。这个服务对外暴露一个/v1/chat/completions端点，输入输出协议完全兼容OpenAI的格式。这样做的最大好处是：你的分身服务写完之后，不需要为接入端开发定制接口，市面上任何支持OpenAI协议的工具都能直接连上来。

from fastapi import FastAPI, Response from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForCausalLM app = FastAPI() model_path = "./merged-chat-bot" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, device_map="auto" ) class ChatRequest(BaseModel): messages: list temperature: float = 0.7 max_tokens: int = 512 class ChatResponse(BaseModel): choices: list @app.post("/v1/chat/completions") def chat(req: ChatRequest): # 用模型的chat template拼prompt prompt = tokenizer.apply_chat_template( req.messages, tokenize=False, add_generation_prompt=True ) inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): outputs = model.generate( **inputs, max_new_tokens=req.max_tokens, temperature=req.temperature, do_sample=True, top_p=0.9, repetition_penalty=1.05, ) new_tokens = outputs[0][inputs.input_ids.shape[1]:] text = tokenizer.decode(new_tokens, skip_special_tokens=True) return ChatResponse( choices=[{"message": {"role": "assistant", "content": text}}] )

如果客户端调用时报错返回格式不标准，多半是响应结构里的字段名和OpenAI规范有出入。OpenAI兼容协议要求返回的choices数组里必须有index、message、finish_reason这几个字段，我在实际使用中为了兼容各种客户端框架，会把响应补成完整规范结构，而不只是给一个content。

4.3 客户端调用：验证服务是否正常的最短路径

服务跑起来之后，用一行curl就能验证接口是否正常工作：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "messages": [ {"role": "user", "content": "你好，最近怎么样？"} ], "temperature": 0.8, "max_tokens": 256 }'

透过这个接口，你可以顺手体验几个不同温度值的差异。temperature设到0.7到0.9时，分身回复比较自然、有波动；低于0.3时会趋于保守和重复；高于1.0则容易开始胡言乱语。做AI分身这种强调人设和语气一致性的场景，我倾向于把默认温度控制在0.75左右，既保留表达上的起伏，又不会跑偏。

接口层还有一个容易忽视的点：流式输出。早期版本我没做流式，一次性生成完再返回，前端体验是“停顿很久然后突然冒出一大段话”。给模型配置stream=True并让FastAPI按SSE格式逐token推送之后，用户的等待体感从10秒变成了首字2秒，效果天差地别。建议接入IM之前优先把流式支持做掉，后面所有聊天端都能受益。

5. 接入IM：合规地让“分身”出现在聊天窗口里

5.1 先想清楚：个人微信自动化为什么不能碰

技术社区里经常能看到“个人号机器人”的教程，基本原理是模拟操作、Hook系统接口或非官方协议。这类方案在技术上可行，但存在几个层面的问题：平台风控会识别异常行为，封号只是时间问题；涉及未经授权的自动化操作，商用场景还有法律风险；另外非官方通道极不稳定，你花大力气做出来的分身，可能上线没几天就失效了。

所以这个Demo我始终遵循一个原则：模型层可以随便玩，通道层只走合规路子。如果你想接微信生态，最稳的方式是使用微信生态内对开发者开放的官方能力，比如企业微信的自建应用。个人微信没有官方机器人接口，这一点短期内不会改变，所以“AI微信分身”真正能在真实IM场景里跑通的形态，就是通过企业IM这样的合法载体来呈现。

5.2 合规接入路径：通过企业微信自建应用实现自动回复

企业微信自建应用是一个合规的官方通道，适合用来展示分身效果。流程上可以这样理解：你在管理后台创建一个小应用，把它当作你和AI分身之间的桥梁。用户向这个应用发消息，后台把消息内容推送到你的公网回调地址，你的服务把消息转给本地推理接口，拿到回复后调用主动发送接口返回给用户。

整个接入链路分几步：

1. 在企业IM管理后台创建自建应用，拿到AgentId和Secret。
2. 配置回调URL，指向你部署了分身推理服务的公网地址。
3. 接收服务器推送的消息，先做签名校验，再解析出消息内容和发送人。
4. 把消息文本包装成OpenAI兼容格式的messages，转发给本地推理服务。
5. 拿到回复后，调用主动发送消息接口返回给对话窗口。

注意这里涉及到回调URL和公网地址，部署时需要一台能接受外部请求的轻量服务器或云函数，和本地只跑推理服务是不同的部署拓扑。如果你不想在云上跑模型，可以把推理服务留在本地，只把企业IM回调转发到内网穿透。不过这里面又牵扯网络配置，个人Demo阶段直接用一台云GPU服务器把推理和回调放在同机是最省心的。

5.3 快速替代方案：先用网页聊天窗完成展示

如果你暂时不想接企业IM，或者只是想快速验证微调效果，我强烈建议先做一个本地网页聊天窗。它不需要公网、不需要回调配置、不需要处理IM平台的签名逻辑，省掉接入层的复杂度，把注意力全部放在“分身像不像”上。

下面这个HTML页面就是够用版本，浏览器里打开直接和本地服务对话：

<!DOCTYPE html> <html lang="zh"> <head> <meta charset="UTF-8"> <title>AI分身演示</title> </head> <body> <div id="chat" style="height: 70vh; overflow-y: auto; border: 1px solid #ccc; padding: 12px;"></div> <input id="input" placeholder="说点什么..." style="width: 80%; padding: 8px;"> <button onclick="send()">发送</button> <script> async function send() { const text = document.getElementById('input').value; const chat = document.getElementById('chat'); chat.innerHTML += `<div><b>我：</b>${text}</div>`; const resp = await fetch('http://127.0.0.1:8000/v1/chat/completions', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({ messages: [{role: 'user', content: text}], temperature: 0.8 }) }); const data = await resp.json(); const reply = data.choices[0].message.content; chat.innerHTML += `<div><b>分身：</b>${reply}</div>`; document.getElementById('input').value = ''; } </script> </body> </html>

这个方案的意义在于做减法。接入IM时，你会被回调、签名、消息格式等杂事拖住，根本分不清“分身不像”到底是模型问题还是接入问题。先用网页窗把模型验证清楚，再动手接企业IM，排查范围会小很多。这也是我做完整个项目后最推荐的路线。

6. 常见问题与排查技巧实录

6.1 训练阶段的高频问题

loss不降怎么办？首先检查数据格式是否被正确拼装成了模型能读的文本，很多人第一步就挂在chat template上。其次看学习率，LoRA微调的学习率区间很窄，设成1e-3以上loss几乎不会正常下降。确认这两点后仍不下降，抽10条训练样本打印出来，肉眼检查有没有大量空内容或重复内容。

显存不足怎么处理？最直接的方案是把per_device_train_batch_size降为1，开梯度累积；其次是把max_length从1536降到1024；最后可以考虑用4bit基座模型加载，从源头降低激活值和参数占用的显存。做了这三步问题还不解，就该考虑换更大显存的机器了。

loss降了但模型说话没变化？我遇到这个情况通常有三种原因：数据量太少、LoRA rank太低、基座模型加载时根本没有真正启用LoRA。第三种最隐蔽，我建议训练开始后确认model.print_trainable_parameters()输出的可训练参数量不是0。

6.2 推理阶段的高频问题

回答速度慢到不可接受？首要排查是否用了非量化模型在CPU上推理。7B模型在CPU上每秒只能生成几个token，体验极差，必须使用GPU。其次检查是否没有开torch的推理模式，torch.no_grad()和model.eval()看起来是小事，但从耗时上看差异很大。

多轮对话上下文太长导致报错？聊天场景里多轮历史会不断累积，最终超过模型的最大长度。我的处理方式有两种：一是设置智能截断，只保留最近N轮；二是把早期轮次的内容摘要后替换掉。个人Demo阶段用第一种就够了，写清楚“最多保留最近10轮”，接口就永远不会被长上下文打挂。

回复内容重复同一句话？这通常是repetition_penalty没设置，或者温度值太低。我一般把repetition_penalty设在1.05到1.1之间，配合0.8左右的温度，可以大幅减少循环重复。

6.3 数据层面的隐性坑

我的数据准备阶段翻过几次车，一次是把聊天记录按行切得稀碎，整个数据变成了无上下文的单句，训练完模型说话前言不搭后语。后来重新按对话块切分，效果立刻改善。另一次是过度清洗，把所有语气词和口语表达都删干净了，模型输出的风格像新闻稿，完全没有分身的味道。这两次教训让我定下一条原则：在数据里保留原始表达的“颗粒感”，只删除会造成隐私或质量风险的内容，不要做额外的文学加工。

6.4 几个值得记住的小技巧

• 在数据集里适当保留一些你犯过的错、说过的“蠢话”和自嘲片段，模型的人设会更丰满。一味追求“完美回复”会把分身变成一个只会讲正确废话的机器人。
• 训练完成之后多对比几个checkpoint的实际输出，选择最接近自己表达习惯的版本，而不是看loss选。loss更低不代表更像你。
• 聊天场景里的温度值，不要跟着通用API推荐值走。通用场景经常给到0.9甚至1.0，但这个值在分身场景下会让人设飘忽，0.7到0.8是我的舒适区间。

个人做完这个Demo，最大的体会是整条链路并不复杂，难点全在“数据像不像人话”和“模型输出有没有人味”这两件事上。后续想继续扩展，方向也很多：给分身接入本地知识库，让它能回答你自己文档里的问题；把OpenAI兼容服务接进自动化工作流，让它替你处理一些需要打字回复的重复性任务；或者在同一个基座模型上训练多个LoRA分身，随时切换不同人设。对于想入门LLM微调的同学，我认为这个项目是值得动手跑一遍的。把一个看似玄乎的“AI分身”变成一条自己能完全掌控的、可复现的流水线，这个收获比“跑通模型”本身要大得多。