你说“在吗”它回“嗯咋了”就这一句话直接把我拉回三年前。这不是复活也不是灵异事件而是一个跑在本地 Python 环境里的小项目用聊天记录微调一个对话模型把那个人的语气、口头禅、回复节奏都学下来然后以 TA 的身份陪你继续聊下去。项目标题叫“AI复刻前任用TA的语气陪你一直聊下去 python源码”听起来带着点情绪但本质上是一个非常典型、且特别适合拿来练手的“风格复刻 对话生成”AI 入门项目。这类项目的核心不是堆算力而是解决一个很现实的问题如何让模型输出的内容在“内容含义”之外更像一个具体的人。它不是让 AI 成为更好的助手而是让 AI 变成某个特定个体的“语气替身”。虽然挂的是“前任”的名头但底层技术完全可以迁移到数字纪念、虚拟陪伴、角色扮演、甚至客服风格的个性化定制上。你需要管的不是 GPU 集群而是一份聊天记录的清洗、一个有风格标签的训练集、一个微调后的轻量模型以及一套让对话不“崩人设”的采样策略。这篇文章我会从需求拆解开始走一遍数据清洗、LoRA 微调、推理采样、本地部署的完整流程把每一步的参数逻辑和踩坑点都摊开讲清楚。适合对 Python 有一定基础、想上手 NLP 微调但又不想读长篇论文的人也适合那些想把对话机器人做出“人味”的开发者。整个项目在消费级显卡上就能跑通没有显卡也可以用云端的免费 CPU 环境凑合做小规模实验。1. 项目整体思路与需求拆解1.1 这个项目到底在解决什么问题先说个直白的事实市面上绝大多数聊天机器人你问它吃了没它回“我吃了你呢”礼貌但空洞像一个训练有素的客服。而真实的人类对话尤其是亲密关系里的对话充满了大量“无意义”但极具识别度的信息固定的口头禅、句尾的语气词、喜欢用问句还是陈述句、回复长度的习惯、甚至标点符号的使用方式。这些特征综合起来才构成一个人在网络聊天中的“语气指纹”。“复刻前任”这个标题本质上要解决的就是“语气指纹”的建模问题。内容可以瞎编但语气必须像否则就是换了个头像的普通机器人。这意味着技术方案不能只靠提示词硬撑——比如在 System Prompt 里写“你是一个叫某某的人说话要温柔”模型根本不知道“温柔”在你的聊天记录里具体长什么样。它需要看真实的对话样本从 token 级别的选择偏好里学会“这个人在回复时更可能用哪些词、以什么顺序组织句子”。这就是为什么项目标题里强调“python源码”因为它确实是靠代码一步步实现的不是套个壳就能交差。你不需要让模型记住对话事实只需要让它学会说话的方式。后面我会反复强调一个词叫“人格一致性”这个项目里所有关键的技术决策都是在为“人格一致性”服务。1.2 为什么选择“风格复刻”而不是“内容复刻”做一个复刻前任的机器人有两种路线。第一种是把所有聊天记录当知识库存起来每次问答都去库里检索最相似的内容然后拼接答案类似 RAG 聊天机器人。第二种是用聊天记录做微调让模型在生成时模仿目标人的用词和句式习惯。我强烈建议选第二种也就是微调路线。原因是很少有人会把每句话都原样背下来人脑记忆也是“记住语气和关系忘记具体台词”。你需要的不是一个复读机而是一个知道“如果是 TA会怎么回这句话”的生成器。RAG 适合回答事实型问题比如“我们上次去的那家餐厅叫什么”但面对开放型闲聊检索出来的碎片根本拼不成连贯的话更没有风格可言。而微调后的模型即使你问一个聊天记录里从未出现过的问题它也能用 TA 的语气推测出一种回复方式这才叫“复刻”。当然纯微调也有局限比如对具体事件的时间线记忆会混乱。所以我实际做的时候是在微调基础上保留了少量“记忆锚点”作为前缀比如把重要事件、昵称、口头禅塞进对话的历史上下文中但模型权重层面的学习重点始终是说话风格。这样既保留了个体记忆又不牺牲生成的自然度。1.3 技术选型基座模型和微调方案的取舍选基座模型是这项目里第一个分水岭。总的原则是参数规模适中、中文对话能力强、开源可商用、社区资料多。我一开始试过 13B 量级的模型效果确实细腻但问题也很现实微调的时候 13B 全参数训练需要至少 24G 显存即使 LoRA 也要 16G 左右很多人的笔记本根本跑不起来。最后我把目标锁定在 7B 到 8B 量级的开源对话模型上这类模型经过大量中文指令数据清洗基础的中文语感和通用对话能力已经够用而且 LoRA 微调在 8G 显存的消费级显卡上就能跑。微调方案我选 LoRA不选全参数微调。核心原因有三点。第一全参数微调相当于把整个模型重训一遍数据量不够的话非常容易“灾难性遗忘”也就是模型原本会的东西被新数据冲掉导致答非所问LoRA 只训练一小部分低秩矩阵相当于在保留原模型能力的基础上“叠一层人格滤镜”。第二LoRA 产出的适配器文件只有几十到几百 MB拖到哪都能用全参数微调却是动辄十几个 G。第三LoRA 可以同时训练多个“人格”切换时只需要换适配器文件不需要重新部署模型。这个特性在做多角色陪伴类产品时特别实用。这里额外说一个很多人不重视的细节基座模型的选择直接影响微调数据集的构造方式。如果你选的是一个自带 System Prompt 概念的指令微调模型就需要把“语气示例”放在用户和助手来回的样例里模型才能学会角色扮演如果你选的是纯文本续写模型就需要换一种拼接格式。千万不要拿一套数据格式生搬硬套所有模型后面我会给具体例子。2. 核心细节解析与实操要点2.1 聊天记录的数据清洗与格式化这是整个项目里最脏最累但最能决定成败的环节。绝大多数人的聊天记录导出后是 JSON 或者 HTML 格式里面混杂着撤回提示、图片链接、语音转文字失败的空消息、群聊里插进来的无关消息、还有微信那种“你撤回了一条消息”的系统占位。这些脏数据如果不处理干净模型学到的不是语气而是“如何生成一堆乱码和无意义的撤回提示”。我建议先把数据统一转成一个人称归一化的文本格式把“你”和“对方”抽出来统一标记成两个角色然后按对话轮次配对。处理方法分三步走。第一过滤系统消息和媒价占位符只保留文本类型的消息第二按时间戳排序剔除超过 24 小时没有回复的“断档对话”因为那些往往是结束了的语境接在一起会导致模型学到莫名其妙的关联第三去掉连续的重复消息有些消息内容是复制粘贴的同一句话会让模型产生复读倾向。格式化方面我用的是类似角色扮演数据集的标准结构用户消息和助手消息交替排列整个对话打包成一个样本。注意一个容易犯的错要把“前任”作为“助手”来训练把“自己”作为“用户”。这样模型才会学到用 TA 的口吻回应而不是反过来。我贴一个我用的数据样本模板{ conversations: [ { role: user, content: 今天好累啊加班到现在 }, { role: assistant, content: 又加班你上次说忙完这阵子就歇的结果呢。叹气 }, { role: user, content: 这不是项目突然加需求了嘛我也没办法 }, { role: assistant, content: 行吧行吧我不也没说啥。赶紧回家吃饭别又点外卖。 } ] }数据量方面我的经验是至少要有 500 轮左右的干净对话少于这个数LoRA 学到的更多是噪声而不是语气如果能到 2000 轮以上语气会非常明显。如果聊天记录不够还有一个补充办法找 TA 在社交平台上公开发过的文字动态微博、朋友圈这类短文本把它们按单轮样本塞进去。这些文本虽然是独白不是对话但能有效补充词汇偏好和句式的覆盖面。2.2 风格注入的底层原理LoRA 到底在学什么很多人听到“微调”就觉得高深莫测其实 LoRA 的原理用一个生活类比就能讲清楚。想象一个组织能力很强的总编他能把任何稿件改得逻辑通顺这是基座模型的能力。但总编不知道“前任”喜欢用什么口头禅这时候 LoRA 就是在总编手边放一本薄薄的“语气速查手册”手册只记录这个人特殊的用词和句式习惯总编改稿时顺手翻一翻但不会丢掉自己原来的文字功底。技术层面LoRA 冻结了原始模型的绝大部分权重只在某些线性层旁边添加两个低秩矩阵。训练时只更新这两个小矩阵矩阵的乘积相当于对原始权重做一个低秩的增量修改。这个设计有三层含义第一因为训练参数量极少所以需要的数据和时间都少很多第二因为原始权重被冻结所以不容易遗忘通用能力第三低秩结构本身就带有一定的正则化效果防止模型把训练集里的某句话背下来更有利于学到抽象的语气模式。实际训练的时候有几个超参值得仔细调。rank我一般设 8 到 16不要盲目加大rank 过高容易过拟合复刻出来的效果其实是背诵整段对话稍微换个说法就崩。alpha一般设成 rank 的一半或者和 rank 一样大比如 rank8alpha8 是一个比较稳的起始点。学习率要尽量低我常用 1e-4 到 2e-4配上前 100 步的 warmup不然模型在前期很容易震荡。还有一个训练细节我不厌其烦地提醒一定要开gradient checkpointing这能在几乎不损失训练速度的前提下大幅度降低显存占用。我的 8G 显存显卡跑 7B 模型开这个选项后 batch size 可以从 1 提到 2稳定性明显更好。注意数据加载时要把长度相近的样本放到同一个 batch否则短的撑不满、长的放不进训练效率会很差。2.3 推理策略温度和采样参数怎么调才像“真人”模型微调好了扔到对话里发现一个尴尬的问题模型回复每句话都符合 TA 的语气但整段对话平淡得像白开水既没有情绪起伏也没有真实聊天的那种随意感。这个问题的根源不是微调没学好而是推理时的采样策略不对。先说温度模型生成时会计算下一个 token 的概率分布温度就是用来平滑或锐化这个分布的。温度越低越倾向于选概率最高的词结果就是安全但无聊温度越高越愿意选概率不那么高的词结果就是更有惊喜但容易跑偏。我实测下来复刻真实聊天语气温度设 0.8 到 1.0 比较合适。低于 0.6 的时候回复会变得像“背稿”一句话里全是 TA 的口头禅但毫无自然感高于 1.2 的时候回复开始出现用词混乱。真实的人聊天本来就有一定的随机性这一点必须靠温度体现。top_p我习惯设 0.85 到 0.95。它的作用简单说就是截断那些概率太低、基本不会被正常人使用的词。top_p 太大等同于没用太小又会丢掉模型学到的一些罕见但很有个人特色的表达方式。repetition_penalty也叫重复惩罚我设 1.05 左右只需要轻微惩罚设高了会出现句子里刻意避开某些常用词的现象看起来非常别扭。还有一个很多人忽略的选项max_new_tokens。真实的人聊天回复一般不会超过三四十个字除了偶尔长篇倾诉。我把生成上限设为 128一方面减少响应延迟另一方面也防止模型在没人打断的情况下越写越离谱像喝多了以后絮叨不停。你可以对比一下上限设 512 的效果那个“人味”立刻就会淡掉,因为正常人不会闲着没事连续输出两百字的小作文。generation_config { temperature: 0.85, top_p: 0.9, repetition_penalty: 1.05, max_new_tokens: 128, do_sample: True, }这些参数组合起来才让输出像是“一个具体的人在打字”而不是“一个号称是某人的模型在念稿子”。我后来做对比测试时发现温度对“像不像”的影响甚至大于 LoRA 训练本身——参数调错再厉害的微调也被糟蹋了。3. 完整实操流程与核心代码实现3.1 环境准备与依赖安装开始动手前先把环境搭起来。这个项目依赖不多核心就四个东西Python 3.10 以上、PyTorch、Transformers、PEFT。如果你有 NVIDIA 显卡CUDA 版本需要和 PyTorch 对应可以用nvidia-smi看一下驱动支持的 CUDA 版本然后去 PyTorch 官网选对应的安装命令。没有独显也不用急Apple Silicon 芯片的 Mac 可以用 MPS 后端跑小模型加 LoRA 微调也能出结果就慢一些。我顺手给一份安装命令建议用虚拟环境隔离别把系统 Python 环境搞乱了python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install torch transformers peft datasets accelerate sentencepiecetransformers不用追新稳定版本即可datasets用来做数据划分和预处理accelerate负责分布式和混合精度。混精度训练要提一嘴如果你的显卡支持 bf16 就优先用它一定程度可以减少显存占用老显卡不支持 bf16 的话用 fp16但 fp16 在 LoRA 训练后期偶尔会出现 loss 抖动要把fp16_opt_level相关参数设置保守一点。3.2 从聊天记录到训练集的转换脚本不管你从哪个平台导出的记录最后都要落成我前面说的 JSON 格式。这里给一个通用的清洗脚本假设你已经把原始记录整理成了 CSV每一行有三列timestamp、sender、content。脚本做的事情是过滤脏消息、切割长对话窗口、输出训练集和验证集。import json import random import pandas as pd def build_dataset(csv_path, target_user, speaker_nameassistant): df pd.read_csv(csv_path) df df.dropna(subset[content]) df df[df[content].str.strip() ! ] df df[~df[content].str.contains(撤回|图片|链接|语音, naFalse)] df df.sort_values(timestamp) # 剔除超过24小时没有回复的断档 df[gap_hours] df[timestamp].diff().dt.total_seconds() / 3600 session_ids (df[gap_hours] 24).cumsum() samples [] for _, group in df.groupby(session_ids): conv [] for _, row in group.iterrows(): role user if row[sender] ! target_user else speaker_name content row[content].strip()[:200] # 防止超长消息 if not content: continue conv.append({role: role, content: content}) # 只保留至少3轮以上的对话 if len(conv) 6: samples.append({conversations: conv}) random.shuffle(samples) split int(len(samples) * 0.9) train_data, val_data samples[:split], samples[split:] with open(train.json, w, encodingutf-8) as f: json.dump(train_data, f, ensure_asciiFalse, indent2) with open(val.json, w, encodingutf-8) as f: json.dump(val_data, f, ensure_asciiFalse, indent2) print(ftrain samples: {len(train_data)}, val samples: {len(val_data)}) # 用法示例sender列里写的是对方的名字 # build_dataset(chat_history.csv, target_user那个人, speaker_nameassistant)注意这里的角色映射规则target_user传的是“前任”的名字因为 TA 是我们要复刻的对象在训练集里会扮演assistant的角色你自己的消息会变成user角色。如果聊天记录里 TA 给你发了很多语音转文字的片段质量参差不齐建议人工抽样检查一遍把所有明显识别错误的内容删掉不然模型会学到一些莫名其妙的断句习惯。3.3 用 LoRA 微调的完整训练脚本训练脚本是项目的发动机。下面这份代码我尽量精简到能跑通关键地方都加了注释。需要提前说一下不同模型套用的 chat template 格式不同这里以通用对话模型的格式为例你在实际项目里需要用目标模型自带的模板方法。import torch from datasets import Dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer import json # 加载基座模型和分词器低资源环境记得加 device_mapauto model_path your-chosen-base-model model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16 if torch.cuda.is_available() else torch.float32, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) tokenizer.pad_token tokenizer.eos_token # 构造对话数据集 with open(train.json, r, encodingutf-8) as f: train_raw json.load(f) with open(val.json, r, encodingutf-8) as f: val_raw json.load(f) def preprocess(example): # 按角色拼接成文本换行分隔 text \n.join( [f{用户 if msg[role] user else 目标人物}: {msg[content]} for msg in example[conversations]] ) return {text: text} train_dataset Dataset.from_list(train_raw).map(preprocess) val_dataset Dataset.from_list(val_raw).map(preprocess) # LoRA 配置 lora_config LoraConfig( r8, lora_alpha8, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) training_args TrainingArguments( output_dir./clone_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate1.5e-4, warmup_steps100, logging_steps20, save_strategyepoch, evaluation_strategyepoch, fp16False, bf16torch.cuda.is_available(), gradient_checkpointingTrue, remove_unused_columnsFalse, report_tonone, ) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasettrain_dataset, eval_datasetval_dataset, argstraining_args, peft_configlora_config, formatting_funclambda x: x[text], ) trainer.train() # 保存 LoRA 适配器 trainer.model.save_pretrained(./clone_lora_adapter) tokenizer.save_pretrained(./clone_lora_adapter)这里有几个容易被坑的地方。第一gradient_accumulation_steps8配合batch_size1等效 batch size 是 8既能降低显存占用又不会让梯度过于抖动。第二num_train_epochs3是我试过多个数据集之后比较稳的默认值——训练集大可以降到 2训练集小就升到 4再多就基本开始背诵原文了。第三bf16需要 Ampere 架构以上的显卡如果是 20 系或更老的卡要强制设为fp16True, bf16False同时对 loss 震荡要有心理准备。整个训练过程在 8G 显存上大约需要 20 到 40 分钟看你数据量。如果你最终测下来语气不像先别急着改 LoRA 参数而是回头看看数据量够不够、数据清洗干不干净这个问题我后面还会再展开。3.4 推理脚本让模型以 TA 的身份聊下去训练完成后实际对话脚本反而比训练简单得多。核心就两步把 LoRA 适配器加载到基座模型上然后用本地生成循环来聊天。我不建议用 gradio 之类的大块头界面命令行就够了方便调试。import torch from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel base_model_path your-chosen-base-model adapter_path ./clone_lora_adapter tokenizer AutoTokenizer.from_pretrained(base_model_path) model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16 if torch.cuda.is_available() else torch.float32, device_mapauto, ) model PeftModel.from_pretrained(model, adapter_path) model.eval() history [] print(已加载复刻人格开始对话吧。输入 q 退出。) while True: user_input input(你: ) if user_input.strip().lower() q: break history.append(f用户: {user_input}) prompt \n.join(history[-10:]) \n目标人物: inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens128, temperature0.85, top_p0.9, repetition_penalty1.05, do_sampleTrue, ) reply tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) reply reply.strip().split(\n)[0] # 只取第一行防止一次生成多轮 print(TA:, reply) history.append(f目标人物: {reply})这里有个非常关键的细节我保留了最近 10 轮对话作为上下文。如果全部对话都塞进去一个是越聊越慢另一个是早期一两轮对话里的错误回答会被模型当作既定事实在后面反复引用导致人格漂移。10 轮是个平衡点既能提供充分的语境信息又不会让模型被自己几分钟前瞎编的内容带跑。另外我只取了生成结果的第一个换行之前的内容。这是因为有些模型在生成完一句话后会自然而然地继续生成用户的下一句或旁白如果不截断就会出现“两个人各说各话”的混乱画面。这个问题很隐蔽网上很多复刻类项目跑起来之后效果诡异十有八九就栽在这里。3.5 部署与体验优化纯命令行脚本自己玩没问题但如果想把它变成一个随时能打开的陪伴工具我建议做两个小升级。第一个是加一个简单的 Web 界面第二个是给对话上下文做持久化存储。Web 界面我用的是 Gradio 的聊天组件代码量很小几十行就能搞定支持流式输出体验比命令行舒服很多。但注意 Gradio 默认每次对话都会把历史传给后端如果你保存了整个 session 的历史再传入模型会导致生成延迟随对话次数上升。正确做法是后端只维护最近 10 轮的列表Gradio 界面上展示的完整历史另存一份两套数据互不干扰。持久化我推荐用 SQLite按日期和对话 session 存储。这样做的好处是你回头能翻出“上个月某天晚上 TA 说了什么”对这类情感陪伴产品来说这种“记忆感”比单纯的聊天能力重要得多。import sqlite3 conn sqlite3.connect(chat_history.db) conn.execute(CREATE TABLE IF NOT EXISTS messages (id INTEGER PRIMARY KEY AUTOINCREMENT, role TEXT, content TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)) conn.commit()常规的对话机器人往往不重视记忆存储但在复刻类场景里用户需要一种“这个人真的在和我持续交流”的错觉。把对话记录落库除了功能上的完整也方便事后分析模型哪里崩了人设——比如某天回答突然出戏你翻一下上下文就能定位问题。4. 常见问题与排查技巧实录4.1 训练数据相关的高频问题我见过最多的错误是数据量不够就急着开训。有朋友拿几十条聊天记录跑 LoRA结果模型确实记住了“在吗”“干嘛呢”这几句但换个问法就露馅回答开始东扯西扯。这属于典型的欠拟合加噪声过拟合混合症状。建议数据量低于 300 轮对话时先考虑补充公开的社交动态文本或者干脆换一个更小的基座模型比如 1B 到 3B 的模型在极少数据下反而更容易收敛出风格特征。第二个常见问题是数据里混了多个人。有些聊天记录导出时把群聊也带进来了群友的话被算进了 TA 的名下结果模型说话一阵像 TA一阵像你同事非常精神分裂。清洗脚本里我用sender字段做区分导出时务必检查群聊是不是已经被过滤掉。如果你收到的是合并转发式的聊天记录手工过一遍要比写自动过滤脚本更高效。第三个问题是 TA 的口头禅虽然被学会了但模型开始滥用。比如 TA 喜欢说“行吧”模型每一句回复结尾都带“行吧”像复读机。解决手段是在清洗时把过于高频的口头禅做一定程度的替换比如把连续三句都以“行吧”结尾的对话里后两句的“行吧”删掉人为制造一些多样性模型学到的是“有口头禅”而不是“只会口头禅”。4.2 训练层面的硬核排查如果你训练时 loss 一直在震荡或者 loss 降了但生成质量不升反降大概率是学习率太大或者训练轮次太多。LoRA 微调不同于预训练它对学习率非常敏感1e-4 到 2e-4 是个相对安全的区间。超过 5e-4 就会出现模型开始胡言乱语的情况。另外一个容易被忽略的因素是数据长度不一致导致的梯度不稳定建议在预处理时设置max_length512超长对话截断短对话 padding 到相同长度。显存不足的问题也经常出现。如果你只有 6G 显存跑 7B 模型确实非常吃力。有三个立即能用的省显存手段开gradient_checkpointing、用qlora也就是把基座模型量化到 4bit 再挂 LoRA、以及调低max_length。我实际测过 4bit 量化加 LoRA 在效果上比 8bit 略差一点但显存占用能压到 6G 以内对普通玩家来说是值得的取舍。这里提醒一个极其隐蔽的坑target_modules如果你设错了训练不会报错但 LoRA 可能根本没有作用。很多开源对话模型的门控模块名字不叫q_proj,v_proj而是qkv_proj或者W_pack需要先看一下模型的named_modules()输出再设置。否则你会看到 loss 乖乖下降但推理时加载适配器后听起来和基座模型毫无区别白白浪费几小时训练时间。我一开始就吃过这个亏后来固定流程是先打印几层模块名再写配置。4.3 对话效果不理想先别急着重新训练很多人跑完训练聊了两句觉得不像第一反应是调整 LoRA 参数然后重新训练。这其实不是最优解。我建议按顺序排查以下三点。第一采样参数把温度从 0.85 提到 1.0看看是不是回复变得更有“人味”。第二上下文窗口你的提示词里只放了最近 3 轮对话的话模型缺少语境自然很难用对语气。第三角色前缀试试在提示词里额外加一句角色描述比如你希望 TA 说话带点不耐烦还是温柔模型会顺着这个方向拉回一些人设。如果你的模型聊久了以后开始“这次我真的很认真”这种没头没尾的话看起来就像喝多了的人在写小作文那多半是max_new_tokens设太长导致的。每个人日常聊天都是碎片化的短句及时截断是保持人设像真的重要手段。我最终把max_new_tokens设在了 64效果比 128 更自然因为短回复更符合日常闲聊的节奏。还有一个屡试不爽的优化手段在推理时偷偷塞几个 TA 说过的原话片段作为 few-shot 前缀。比如在对话历史前面加一句“以下是你过去的聊天风格示例”然后贴上三五句 TA 的典型回复。这不会改变 LoRA 学到的权重但能从解码层面把语气往目标方向再拉一把效果立竿见影。这个技巧在角色扮演类产品里非常常见属于提示工程和微调的互补用法。4.4 情感边界与产品化提醒最后这部分我想多说两句。这类“复刻前任”的项目技术上很有意思但它触碰到的情感问题也很真实。我做过一个类似 Demo 给某位朋友体验TA 聊了几个小时后告诉我发现有些话当年没来得及说出口现在对着模型说完反而释然了。这让我意识到这类工具本质上是一种“情感完成”的辅助器它不该成为逃避现实关系的替代品。因此如果你把这个项目继续做成产品我建议在界面上明确提示“这是 AI 模拟不是本人”并且加入合理的使用时长提醒。从技术伦理的角度帮人走出上一段关系、或者纪念已经离开的人是正向价值但如果用户因此拒绝建立新的真实关系那就偏离了初衷。工具本身是中性的关键看产品定位和引导。另外提醒一个身份安全相关的点聊天数据是高度隐私的数据训练和推理过程最好全部在本地完成模型文件和数据集都不要上传到任何云端服务。用本地开源模型的一个隐藏好处就是隐私可控这一点在情感类 AI 场景里尤为重要。我看到市面上有些复刻类小程序要求用户上传聊天记录到服务器这在我看来是非常危险的做法一旦服务方的数据保护不到位你的私密对话就是别人的训练数据。在实现层面我建议在代码里加一个简单的脱敏预检识别并替换聊天记录里的手机号、住址、身份证号等敏感信息。即使本地运行也应该养成这个习惯因为你没法保证未来的某次导出、备份或者分享不会把这部分信息带出去。最后再分享一点我的实际体会这类项目做完一遍你对大模型微调的理解会提升一个台阶因为“复刻语气”比“让模型变聪明”要难得多。让模型变聪明数据堆得越多越好让模型像某个人数据要精挑细选训练要克制采样要细腻。我跑第二版的时候一度纠结于要不要换更大的基座模型后来发现瓶颈根本不在模型规模而在训练数据质量和推理参数适配。当我静下来把聊天记录里那些因为情绪激动而发得特别短的句子单独挑出来放进数据集后整段对话的“人味”立刻提升了一个档次。原来复刻一个人的灵魂藏在这些短暂、破碎、没头没尾的消息里。如果你是第一次跑这种项目别急着追求完美先把 1.0 版本跑通哪怕只复刻出了口头禅也算成功。然后拿着这段对话给认识你俩的人看让他们提意见这比任何自动评估指标都来得直接。语言风格这个东西人眼才是最准的评价器。这个项目后续还可以扩展的方向很多多角色切换、长期记忆数据库、语音输入和朗读甚至把它接到智能音箱上。只要本地模型这条路不堵死玩法多得是。别想太多先从把一条聊天记录变成一份干净的 JSON 开始。 
长河君 · 2026/10/21 5:44:15 · 阅读 1.2k 用Python微调聊天记录，复刻专属语气：LoRA对话模型本地部署实战
你说“在吗”它回“嗯咋了”就这一句话直接把我拉回三年前。这不是复活也不是灵异事件而是一个跑在本地 Python 环境里的小项目用聊天记录微调一个对话模型把那个人的语气、口头禅、回复节奏都学下来然后以 TA 的身份陪你继续聊下去。项目标题叫“AI复刻前任用TA的语气陪你一直聊下去 python源码”听起来带着点情绪但本质上是一个非常典型、且特别适合拿来练手的“风格复刻 对话生成”AI 入门项目。这类项目的核心不是堆算力而是解决一个很现实的问题如何让模型输出的内容在“内容含义”之外更像一个具体的人。它不是让 AI 成为更好的助手而是让 AI 变成某个特定个体的“语气替身”。虽然挂的是“前任”的名头但底层技术完全可以迁移到数字纪念、虚拟陪伴、角色扮演、甚至客服风格的个性化定制上。你需要管的不是 GPU 集群而是一份聊天记录的清洗、一个有风格标签的训练集、一个微调后的轻量模型以及一套让对话不“崩人设”的采样策略。这篇文章我会从需求拆解开始走一遍数据清洗、LoRA 微调、推理采样、本地部署的完整流程把每一步的参数逻辑和踩坑点都摊开讲清楚。适合对 Python 有一定基础、想上手 NLP 微调但又不想读长篇论文的人也适合那些想把对话机器人做出“人味”的开发者。整个项目在消费级显卡上就能跑通没有显卡也可以用云端的免费 CPU 环境凑合做小规模实验。1. 项目整体思路与需求拆解1.1 这个项目到底在解决什么问题先说个直白的事实市面上绝大多数聊天机器人你问它吃了没它回“我吃了你呢”礼貌但空洞像一个训练有素的客服。而真实的人类对话尤其是亲密关系里的对话充满了大量“无意义”但极具识别度的信息固定的口头禅、句尾的语气词、喜欢用问句还是陈述句、回复长度的习惯、甚至标点符号的使用方式。这些特征综合起来才构成一个人在网络聊天中的“语气指纹”。“复刻前任”这个标题本质上要解决的就是“语气指纹”的建模问题。内容可以瞎编但语气必须像否则就是换了个头像的普通机器人。这意味着技术方案不能只靠提示词硬撑——比如在 System Prompt 里写“你是一个叫某某的人说话要温柔”模型根本不知道“温柔”在你的聊天记录里具体长什么样。它需要看真实的对话样本从 token 级别的选择偏好里学会“这个人在回复时更可能用哪些词、以什么顺序组织句子”。这就是为什么项目标题里强调“python源码”因为它确实是靠代码一步步实现的不是套个壳就能交差。你不需要让模型记住对话事实只需要让它学会说话的方式。后面我会反复强调一个词叫“人格一致性”这个项目里所有关键的技术决策都是在为“人格一致性”服务。1.2 为什么选择“风格复刻”而不是“内容复刻”做一个复刻前任的机器人有两种路线。第一种是把所有聊天记录当知识库存起来每次问答都去库里检索最相似的内容然后拼接答案类似 RAG 聊天机器人。第二种是用聊天记录做微调让模型在生成时模仿目标人的用词和句式习惯。我强烈建议选第二种也就是微调路线。原因是很少有人会把每句话都原样背下来人脑记忆也是“记住语气和关系忘记具体台词”。你需要的不是一个复读机而是一个知道“如果是 TA会怎么回这句话”的生成器。RAG 适合回答事实型问题比如“我们上次去的那家餐厅叫什么”但面对开放型闲聊检索出来的碎片根本拼不成连贯的话更没有风格可言。而微调后的模型即使你问一个聊天记录里从未出现过的问题它也能用 TA 的语气推测出一种回复方式这才叫“复刻”。当然纯微调也有局限比如对具体事件的时间线记忆会混乱。所以我实际做的时候是在微调基础上保留了少量“记忆锚点”作为前缀比如把重要事件、昵称、口头禅塞进对话的历史上下文中但模型权重层面的学习重点始终是说话风格。这样既保留了个体记忆又不牺牲生成的自然度。1.3 技术选型基座模型和微调方案的取舍选基座模型是这项目里第一个分水岭。总的原则是参数规模适中、中文对话能力强、开源可商用、社区资料多。我一开始试过 13B 量级的模型效果确实细腻但问题也很现实微调的时候 13B 全参数训练需要至少 24G 显存即使 LoRA 也要 16G 左右很多人的笔记本根本跑不起来。最后我把目标锁定在 7B 到 8B 量级的开源对话模型上这类模型经过大量中文指令数据清洗基础的中文语感和通用对话能力已经够用而且 LoRA 微调在 8G 显存的消费级显卡上就能跑。微调方案我选 LoRA不选全参数微调。核心原因有三点。第一全参数微调相当于把整个模型重训一遍数据量不够的话非常容易“灾难性遗忘”也就是模型原本会的东西被新数据冲掉导致答非所问LoRA 只训练一小部分低秩矩阵相当于在保留原模型能力的基础上“叠一层人格滤镜”。第二LoRA 产出的适配器文件只有几十到几百 MB拖到哪都能用全参数微调却是动辄十几个 G。第三LoRA 可以同时训练多个“人格”切换时只需要换适配器文件不需要重新部署模型。这个特性在做多角色陪伴类产品时特别实用。这里额外说一个很多人不重视的细节基座模型的选择直接影响微调数据集的构造方式。如果你选的是一个自带 System Prompt 概念的指令微调模型就需要把“语气示例”放在用户和助手来回的样例里模型才能学会角色扮演如果你选的是纯文本续写模型就需要换一种拼接格式。千万不要拿一套数据格式生搬硬套所有模型后面我会给具体例子。2. 核心细节解析与实操要点2.1 聊天记录的数据清洗与格式化这是整个项目里最脏最累但最能决定成败的环节。绝大多数人的聊天记录导出后是 JSON 或者 HTML 格式里面混杂着撤回提示、图片链接、语音转文字失败的空消息、群聊里插进来的无关消息、还有微信那种“你撤回了一条消息”的系统占位。这些脏数据如果不处理干净模型学到的不是语气而是“如何生成一堆乱码和无意义的撤回提示”。我建议先把数据统一转成一个人称归一化的文本格式把“你”和“对方”抽出来统一标记成两个角色然后按对话轮次配对。处理方法分三步走。第一过滤系统消息和媒价占位符只保留文本类型的消息第二按时间戳排序剔除超过 24 小时没有回复的“断档对话”因为那些往往是结束了的语境接在一起会导致模型学到莫名其妙的关联第三去掉连续的重复消息有些消息内容是复制粘贴的同一句话会让模型产生复读倾向。格式化方面我用的是类似角色扮演数据集的标准结构用户消息和助手消息交替排列整个对话打包成一个样本。注意一个容易犯的错要把“前任”作为“助手”来训练把“自己”作为“用户”。这样模型才会学到用 TA 的口吻回应而不是反过来。我贴一个我用的数据样本模板{ conversations: [ { role: user, content: 今天好累啊加班到现在 }, { role: assistant, content: 又加班你上次说忙完这阵子就歇的结果呢。叹气 }, { role: user, content: 这不是项目突然加需求了嘛我也没办法 }, { role: assistant, content: 行吧行吧我不也没说啥。赶紧回家吃饭别又点外卖。 } ] }数据量方面我的经验是至少要有 500 轮左右的干净对话少于这个数LoRA 学到的更多是噪声而不是语气如果能到 2000 轮以上语气会非常明显。如果聊天记录不够还有一个补充办法找 TA 在社交平台上公开发过的文字动态微博、朋友圈这类短文本把它们按单轮样本塞进去。这些文本虽然是独白不是对话但能有效补充词汇偏好和句式的覆盖面。2.2 风格注入的底层原理LoRA 到底在学什么很多人听到“微调”就觉得高深莫测其实 LoRA 的原理用一个生活类比就能讲清楚。想象一个组织能力很强的总编他能把任何稿件改得逻辑通顺这是基座模型的能力。但总编不知道“前任”喜欢用什么口头禅这时候 LoRA 就是在总编手边放一本薄薄的“语气速查手册”手册只记录这个人特殊的用词和句式习惯总编改稿时顺手翻一翻但不会丢掉自己原来的文字功底。技术层面LoRA 冻结了原始模型的绝大部分权重只在某些线性层旁边添加两个低秩矩阵。训练时只更新这两个小矩阵矩阵的乘积相当于对原始权重做一个低秩的增量修改。这个设计有三层含义第一因为训练参数量极少所以需要的数据和时间都少很多第二因为原始权重被冻结所以不容易遗忘通用能力第三低秩结构本身就带有一定的正则化效果防止模型把训练集里的某句话背下来更有利于学到抽象的语气模式。实际训练的时候有几个超参值得仔细调。rank我一般设 8 到 16不要盲目加大rank 过高容易过拟合复刻出来的效果其实是背诵整段对话稍微换个说法就崩。alpha一般设成 rank 的一半或者和 rank 一样大比如 rank8alpha8 是一个比较稳的起始点。学习率要尽量低我常用 1e-4 到 2e-4配上前 100 步的 warmup不然模型在前期很容易震荡。还有一个训练细节我不厌其烦地提醒一定要开gradient checkpointing这能在几乎不损失训练速度的前提下大幅度降低显存占用。我的 8G 显存显卡跑 7B 模型开这个选项后 batch size 可以从 1 提到 2稳定性明显更好。注意数据加载时要把长度相近的样本放到同一个 batch否则短的撑不满、长的放不进训练效率会很差。2.3 推理策略温度和采样参数怎么调才像“真人”模型微调好了扔到对话里发现一个尴尬的问题模型回复每句话都符合 TA 的语气但整段对话平淡得像白开水既没有情绪起伏也没有真实聊天的那种随意感。这个问题的根源不是微调没学好而是推理时的采样策略不对。先说温度模型生成时会计算下一个 token 的概率分布温度就是用来平滑或锐化这个分布的。温度越低越倾向于选概率最高的词结果就是安全但无聊温度越高越愿意选概率不那么高的词结果就是更有惊喜但容易跑偏。我实测下来复刻真实聊天语气温度设 0.8 到 1.0 比较合适。低于 0.6 的时候回复会变得像“背稿”一句话里全是 TA 的口头禅但毫无自然感高于 1.2 的时候回复开始出现用词混乱。真实的人聊天本来就有一定的随机性这一点必须靠温度体现。top_p我习惯设 0.85 到 0.95。它的作用简单说就是截断那些概率太低、基本不会被正常人使用的词。top_p 太大等同于没用太小又会丢掉模型学到的一些罕见但很有个人特色的表达方式。repetition_penalty也叫重复惩罚我设 1.05 左右只需要轻微惩罚设高了会出现句子里刻意避开某些常用词的现象看起来非常别扭。还有一个很多人忽略的选项max_new_tokens。真实的人聊天回复一般不会超过三四十个字除了偶尔长篇倾诉。我把生成上限设为 128一方面减少响应延迟另一方面也防止模型在没人打断的情况下越写越离谱像喝多了以后絮叨不停。你可以对比一下上限设 512 的效果那个“人味”立刻就会淡掉,因为正常人不会闲着没事连续输出两百字的小作文。generation_config { temperature: 0.85, top_p: 0.9, repetition_penalty: 1.05, max_new_tokens: 128, do_sample: True, }这些参数组合起来才让输出像是“一个具体的人在打字”而不是“一个号称是某人的模型在念稿子”。我后来做对比测试时发现温度对“像不像”的影响甚至大于 LoRA 训练本身——参数调错再厉害的微调也被糟蹋了。3. 完整实操流程与核心代码实现3.1 环境准备与依赖安装开始动手前先把环境搭起来。这个项目依赖不多核心就四个东西Python 3.10 以上、PyTorch、Transformers、PEFT。如果你有 NVIDIA 显卡CUDA 版本需要和 PyTorch 对应可以用nvidia-smi看一下驱动支持的 CUDA 版本然后去 PyTorch 官网选对应的安装命令。没有独显也不用急Apple Silicon 芯片的 Mac 可以用 MPS 后端跑小模型加 LoRA 微调也能出结果就慢一些。我顺手给一份安装命令建议用虚拟环境隔离别把系统 Python 环境搞乱了python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate pip install torch transformers peft datasets accelerate sentencepiecetransformers不用追新稳定版本即可datasets用来做数据划分和预处理accelerate负责分布式和混合精度。混精度训练要提一嘴如果你的显卡支持 bf16 就优先用它一定程度可以减少显存占用老显卡不支持 bf16 的话用 fp16但 fp16 在 LoRA 训练后期偶尔会出现 loss 抖动要把fp16_opt_level相关参数设置保守一点。3.2 从聊天记录到训练集的转换脚本不管你从哪个平台导出的记录最后都要落成我前面说的 JSON 格式。这里给一个通用的清洗脚本假设你已经把原始记录整理成了 CSV每一行有三列timestamp、sender、content。脚本做的事情是过滤脏消息、切割长对话窗口、输出训练集和验证集。import json import random import pandas as pd def build_dataset(csv_path, target_user, speaker_nameassistant): df pd.read_csv(csv_path) df df.dropna(subset[content]) df df[df[content].str.strip() ! ] df df[~df[content].str.contains(撤回|图片|链接|语音, naFalse)] df df.sort_values(timestamp) # 剔除超过24小时没有回复的断档 df[gap_hours] df[timestamp].diff().dt.total_seconds() / 3600 session_ids (df[gap_hours] 24).cumsum() samples [] for _, group in df.groupby(session_ids): conv [] for _, row in group.iterrows(): role user if row[sender] ! target_user else speaker_name content row[content].strip()[:200] # 防止超长消息 if not content: continue conv.append({role: role, content: content}) # 只保留至少3轮以上的对话 if len(conv) 6: samples.append({conversations: conv}) random.shuffle(samples) split int(len(samples) * 0.9) train_data, val_data samples[:split], samples[split:] with open(train.json, w, encodingutf-8) as f: json.dump(train_data, f, ensure_asciiFalse, indent2) with open(val.json, w, encodingutf-8) as f: json.dump(val_data, f, ensure_asciiFalse, indent2) print(ftrain samples: {len(train_data)}, val samples: {len(val_data)}) # 用法示例sender列里写的是对方的名字 # build_dataset(chat_history.csv, target_user那个人, speaker_nameassistant)注意这里的角色映射规则target_user传的是“前任”的名字因为 TA 是我们要复刻的对象在训练集里会扮演assistant的角色你自己的消息会变成user角色。如果聊天记录里 TA 给你发了很多语音转文字的片段质量参差不齐建议人工抽样检查一遍把所有明显识别错误的内容删掉不然模型会学到一些莫名其妙的断句习惯。3.3 用 LoRA 微调的完整训练脚本训练脚本是项目的发动机。下面这份代码我尽量精简到能跑通关键地方都加了注释。需要提前说一下不同模型套用的 chat template 格式不同这里以通用对话模型的格式为例你在实际项目里需要用目标模型自带的模板方法。import torch from datasets import Dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer import json # 加载基座模型和分词器低资源环境记得加 device_mapauto model_path your-chosen-base-model model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16 if torch.cuda.is_available() else torch.float32, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) tokenizer.pad_token tokenizer.eos_token # 构造对话数据集 with open(train.json, r, encodingutf-8) as f: train_raw json.load(f) with open(val.json, r, encodingutf-8) as f: val_raw json.load(f) def preprocess(example): # 按角色拼接成文本换行分隔 text \n.join( [f{用户 if msg[role] user else 目标人物}: {msg[content]} for msg in example[conversations]] ) return {text: text} train_dataset Dataset.from_list(train_raw).map(preprocess) val_dataset Dataset.from_list(val_raw).map(preprocess) # LoRA 配置 lora_config LoraConfig( r8, lora_alpha8, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) training_args TrainingArguments( output_dir./clone_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps8, num_train_epochs3, learning_rate1.5e-4, warmup_steps100, logging_steps20, save_strategyepoch, evaluation_strategyepoch, fp16False, bf16torch.cuda.is_available(), gradient_checkpointingTrue, remove_unused_columnsFalse, report_tonone, ) trainer SFTTrainer( modelmodel, tokenizertokenizer, train_datasettrain_dataset, eval_datasetval_dataset, argstraining_args, peft_configlora_config, formatting_funclambda x: x[text], ) trainer.train() # 保存 LoRA 适配器 trainer.model.save_pretrained(./clone_lora_adapter) tokenizer.save_pretrained(./clone_lora_adapter)这里有几个容易被坑的地方。第一gradient_accumulation_steps8配合batch_size1等效 batch size 是 8既能降低显存占用又不会让梯度过于抖动。第二num_train_epochs3是我试过多个数据集之后比较稳的默认值——训练集大可以降到 2训练集小就升到 4再多就基本开始背诵原文了。第三bf16需要 Ampere 架构以上的显卡如果是 20 系或更老的卡要强制设为fp16True, bf16False同时对 loss 震荡要有心理准备。整个训练过程在 8G 显存上大约需要 20 到 40 分钟看你数据量。如果你最终测下来语气不像先别急着改 LoRA 参数而是回头看看数据量够不够、数据清洗干不干净这个问题我后面还会再展开。3.4 推理脚本让模型以 TA 的身份聊下去训练完成后实际对话脚本反而比训练简单得多。核心就两步把 LoRA 适配器加载到基座模型上然后用本地生成循环来聊天。我不建议用 gradio 之类的大块头界面命令行就够了方便调试。import torch from transformers import AutoModelForCausalLM, AutoTokenizer from peft import PeftModel base_model_path your-chosen-base-model adapter_path ./clone_lora_adapter tokenizer AutoTokenizer.from_pretrained(base_model_path) model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16 if torch.cuda.is_available() else torch.float32, device_mapauto, ) model PeftModel.from_pretrained(model, adapter_path) model.eval() history [] print(已加载复刻人格开始对话吧。输入 q 退出。) while True: user_input input(你: ) if user_input.strip().lower() q: break history.append(f用户: {user_input}) prompt \n.join(history[-10:]) \n目标人物: inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens128, temperature0.85, top_p0.9, repetition_penalty1.05, do_sampleTrue, ) reply tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) reply reply.strip().split(\n)[0] # 只取第一行防止一次生成多轮 print(TA:, reply) history.append(f目标人物: {reply})这里有个非常关键的细节我保留了最近 10 轮对话作为上下文。如果全部对话都塞进去一个是越聊越慢另一个是早期一两轮对话里的错误回答会被模型当作既定事实在后面反复引用导致人格漂移。10 轮是个平衡点既能提供充分的语境信息又不会让模型被自己几分钟前瞎编的内容带跑。另外我只取了生成结果的第一个换行之前的内容。这是因为有些模型在生成完一句话后会自然而然地继续生成用户的下一句或旁白如果不截断就会出现“两个人各说各话”的混乱画面。这个问题很隐蔽网上很多复刻类项目跑起来之后效果诡异十有八九就栽在这里。3.5 部署与体验优化纯命令行脚本自己玩没问题但如果想把它变成一个随时能打开的陪伴工具我建议做两个小升级。第一个是加一个简单的 Web 界面第二个是给对话上下文做持久化存储。Web 界面我用的是 Gradio 的聊天组件代码量很小几十行就能搞定支持流式输出体验比命令行舒服很多。但注意 Gradio 默认每次对话都会把历史传给后端如果你保存了整个 session 的历史再传入模型会导致生成延迟随对话次数上升。正确做法是后端只维护最近 10 轮的列表Gradio 界面上展示的完整历史另存一份两套数据互不干扰。持久化我推荐用 SQLite按日期和对话 session 存储。这样做的好处是你回头能翻出“上个月某天晚上 TA 说了什么”对这类情感陪伴产品来说这种“记忆感”比单纯的聊天能力重要得多。import sqlite3 conn sqlite3.connect(chat_history.db) conn.execute(CREATE TABLE IF NOT EXISTS messages (id INTEGER PRIMARY KEY AUTOINCREMENT, role TEXT, content TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)) conn.commit()常规的对话机器人往往不重视记忆存储但在复刻类场景里用户需要一种“这个人真的在和我持续交流”的错觉。把对话记录落库除了功能上的完整也方便事后分析模型哪里崩了人设——比如某天回答突然出戏你翻一下上下文就能定位问题。4. 常见问题与排查技巧实录4.1 训练数据相关的高频问题我见过最多的错误是数据量不够就急着开训。有朋友拿几十条聊天记录跑 LoRA结果模型确实记住了“在吗”“干嘛呢”这几句但换个问法就露馅回答开始东扯西扯。这属于典型的欠拟合加噪声过拟合混合症状。建议数据量低于 300 轮对话时先考虑补充公开的社交动态文本或者干脆换一个更小的基座模型比如 1B 到 3B 的模型在极少数据下反而更容易收敛出风格特征。第二个常见问题是数据里混了多个人。有些聊天记录导出时把群聊也带进来了群友的话被算进了 TA 的名下结果模型说话一阵像 TA一阵像你同事非常精神分裂。清洗脚本里我用sender字段做区分导出时务必检查群聊是不是已经被过滤掉。如果你收到的是合并转发式的聊天记录手工过一遍要比写自动过滤脚本更高效。第三个问题是 TA 的口头禅虽然被学会了但模型开始滥用。比如 TA 喜欢说“行吧”模型每一句回复结尾都带“行吧”像复读机。解决手段是在清洗时把过于高频的口头禅做一定程度的替换比如把连续三句都以“行吧”结尾的对话里后两句的“行吧”删掉人为制造一些多样性模型学到的是“有口头禅”而不是“只会口头禅”。4.2 训练层面的硬核排查如果你训练时 loss 一直在震荡或者 loss 降了但生成质量不升反降大概率是学习率太大或者训练轮次太多。LoRA 微调不同于预训练它对学习率非常敏感1e-4 到 2e-4 是个相对安全的区间。超过 5e-4 就会出现模型开始胡言乱语的情况。另外一个容易被忽略的因素是数据长度不一致导致的梯度不稳定建议在预处理时设置max_length512超长对话截断短对话 padding 到相同长度。显存不足的问题也经常出现。如果你只有 6G 显存跑 7B 模型确实非常吃力。有三个立即能用的省显存手段开gradient_checkpointing、用qlora也就是把基座模型量化到 4bit 再挂 LoRA、以及调低max_length。我实际测过 4bit 量化加 LoRA 在效果上比 8bit 略差一点但显存占用能压到 6G 以内对普通玩家来说是值得的取舍。这里提醒一个极其隐蔽的坑target_modules如果你设错了训练不会报错但 LoRA 可能根本没有作用。很多开源对话模型的门控模块名字不叫q_proj,v_proj而是qkv_proj或者W_pack需要先看一下模型的named_modules()输出再设置。否则你会看到 loss 乖乖下降但推理时加载适配器后听起来和基座模型毫无区别白白浪费几小时训练时间。我一开始就吃过这个亏后来固定流程是先打印几层模块名再写配置。4.3 对话效果不理想先别急着重新训练很多人跑完训练聊了两句觉得不像第一反应是调整 LoRA 参数然后重新训练。这其实不是最优解。我建议按顺序排查以下三点。第一采样参数把温度从 0.85 提到 1.0看看是不是回复变得更有“人味”。第二上下文窗口你的提示词里只放了最近 3 轮对话的话模型缺少语境自然很难用对语气。第三角色前缀试试在提示词里额外加一句角色描述比如你希望 TA 说话带点不耐烦还是温柔模型会顺着这个方向拉回一些人设。如果你的模型聊久了以后开始“这次我真的很认真”这种没头没尾的话看起来就像喝多了的人在写小作文那多半是max_new_tokens设太长导致的。每个人日常聊天都是碎片化的短句及时截断是保持人设像真的重要手段。我最终把max_new_tokens设在了 64效果比 128 更自然因为短回复更符合日常闲聊的节奏。还有一个屡试不爽的优化手段在推理时偷偷塞几个 TA 说过的原话片段作为 few-shot 前缀。比如在对话历史前面加一句“以下是你过去的聊天风格示例”然后贴上三五句 TA 的典型回复。这不会改变 LoRA 学到的权重但能从解码层面把语气往目标方向再拉一把效果立竿见影。这个技巧在角色扮演类产品里非常常见属于提示工程和微调的互补用法。4.4 情感边界与产品化提醒最后这部分我想多说两句。这类“复刻前任”的项目技术上很有意思但它触碰到的情感问题也很真实。我做过一个类似 Demo 给某位朋友体验TA 聊了几个小时后告诉我发现有些话当年没来得及说出口现在对着模型说完反而释然了。这让我意识到这类工具本质上是一种“情感完成”的辅助器它不该成为逃避现实关系的替代品。因此如果你把这个项目继续做成产品我建议在界面上明确提示“这是 AI 模拟不是本人”并且加入合理的使用时长提醒。从技术伦理的角度帮人走出上一段关系、或者纪念已经离开的人是正向价值但如果用户因此拒绝建立新的真实关系那就偏离了初衷。工具本身是中性的关键看产品定位和引导。另外提醒一个身份安全相关的点聊天数据是高度隐私的数据训练和推理过程最好全部在本地完成模型文件和数据集都不要上传到任何云端服务。用本地开源模型的一个隐藏好处就是隐私可控这一点在情感类 AI 场景里尤为重要。我看到市面上有些复刻类小程序要求用户上传聊天记录到服务器这在我看来是非常危险的做法一旦服务方的数据保护不到位你的私密对话就是别人的训练数据。在实现层面我建议在代码里加一个简单的脱敏预检识别并替换聊天记录里的手机号、住址、身份证号等敏感信息。即使本地运行也应该养成这个习惯因为你没法保证未来的某次导出、备份或者分享不会把这部分信息带出去。最后再分享一点我的实际体会这类项目做完一遍你对大模型微调的理解会提升一个台阶因为“复刻语气”比“让模型变聪明”要难得多。让模型变聪明数据堆得越多越好让模型像某个人数据要精挑细选训练要克制采样要细腻。我跑第二版的时候一度纠结于要不要换更大的基座模型后来发现瓶颈根本不在模型规模而在训练数据质量和推理参数适配。当我静下来把聊天记录里那些因为情绪激动而发得特别短的句子单独挑出来放进数据集后整段对话的“人味”立刻提升了一个档次。原来复刻一个人的灵魂藏在这些短暂、破碎、没头没尾的消息里。如果你是第一次跑这种项目别急着追求完美先把 1.0 版本跑通哪怕只复刻出了口头禅也算成功。然后拿着这段对话给认识你俩的人看让他们提意见这比任何自动评估指标都来得直接。语言风格这个东西人眼才是最准的评价器。这个项目后续还可以扩展的方向很多多角色切换、长期记忆数据库、语音输入和朗读甚至把它接到智能音箱上。只要本地模型这条路不堵死玩法多得是。别想太多先从把一条聊天记录变成一份干净的 JSON 开始。