DeepSeek剧本微调实战：LoRA训练与风格迁移全流程解析

简介：面向影视编剧、内容创作者及自然语言处理技术爱好者，这份二十三页的PDF系统讲解如何借助DeepSeek完成行业语料微调与剧本风格迁移。文档从影视创作与技术融合的背景切入，先梳理DeepSeek模型起源、架构与预训练机制，再展开行业语料收集、筛选、清洗、标注与预处理的方法；微调部分覆盖环境搭建、参数设置、训练流程及过拟合处理，风格迁移部分详述编码器—解码器架构、风格特征提取、对抗训练、推理过程与评估指标，并配有数据准备、微调、风格迁移、模型评估等关键环节的代码示例。资源为单个PDF文件，压缩包约1.83MB，目录结构清晰、图文显示正常，方便按章节检索阅读。已有75人学习，适合希望借助大模型辅助剧本创作、实现个人或平台风格适配的读者作为从入门到进阶的系统参考。

1. 为什么让 DeepSeek 直接写剧本总是一股“AI 味”

影视剧本创作这件事，大多数团队现在的第一反应是“让 DeepSeek 先出个三幕结构”。但你真拿去试过就会发现，模型写出来的东西结构上挑不出毛病——起承转合齐全，人物弧光也不缺，可一落到具体对白和场景描述就露馅了：台词像访谈节目，人物说话没有潜台词，场景描写全是“气氛紧张”“内心复杂”这种黑匣子式形容词。问题不在 DeepSeek 本身，而在它训练时看过太多通用文本，没看过足够多“真正的剧本”。

所谓“真正的剧本”，指的是业界实际在用的剧本格式——场景标题、动作描述、角色名冒号对白、括号内的语气提示，这些东西和小说、新闻、聊天记录完全不是一个文体。行业语料微调与风格迁移，就是把 DeepSeek 从一个什么都懂的通用模型，变成一上来就懂“场地、内景、日”这种黑话的影视剧本专用模型。本文不聊那些云端一键微调的噱头，直接讲清楚语料怎么洗、LoRA 参数怎么调、风格迁移到底迁移的是什么，以及哪些地方会让你白烧几千块 GPU 电费。

2. 行业语料准备：先让模型“看懂”剧本长什么样

2.1 影视剧本语料和普通文本语料的三个本质区别

很多人以为“行业语料微调”就是把一堆 PDF 剧本喂给模型让它学。实际上剧本语料的处理难度远高于同量级的新闻或百科语料，因为剧本的信息密度分布极其不均匀。第一，剧本里有大量“格式即语义”的内容，比如“内景 办公室 - 夜”这行字不是描述，是场景切换的硬标记，模型必须学会把它当成“新一场戏开始”的信号；第二，对白占比超过百分之六七十，而且对白说话人标记（角色名冒号）一旦丢失，整段训练样本就成了无意义的文本流；第三，剧作里有大量“无效文段”——封面、版权页、演职员表、导演注释、分场大纲，这些混进语料会让微调模型学会生成一堆和剧情无关的边角料。

所以第一步不是找语料，而是定清洗规范。我一般会把语料处理分成三级：第一级是格式规范化，把 PDF 或 Word 导出的乱码整理成统一的“场景标记 + 动作描述 + 角色:对白”结构；第二级是内容过滤，去掉版权页、片头片尾、剧本分析文章这些非剧本正文；第三级是对话块切分，保证每个训练样本内部是完整的叙事单元，而不是在一场戏中间拦腰截断。

2.2 原始剧本转训练集的清洗脚本

下面这段代码解决的是第一级和第二级问题的合并处理。它读取一批纯文本格式的剧本文件，按场景标记切分并将对白行规范成“角色名 + 冒号 + 内容”的模板。

import re from pathlib import Path def clean_script(raw_text: str) -> list[str]: # 逐行清洗：先剔除版权页、页码、演职员表等噪声行 lines = raw_text.splitlines() cleaned = [] scene_pattern = re.compile(r'^(内景|外景|内|外)\s+.+?[\.\-—]\s*(日|夜|黄昏|清晨|白天|晚上)') dialogue_pattern = re.compile(r'^[A-Z\u4e00-\u9fa5]{1,8}\s?[:：]\s?') for line in lines: line = line.strip() if not line: continue # 过滤纯数字页码和“第X页”这类内容 if re.fullmatch(r'(\d{1,4}|第\s*\d+\s*页)', line): continue # 过滤版权/演职员关键词开头的行 lower_line = line.lower() if any(word in lower_line for word in ["copyright", "编剧", "导演", "出品", "主演"]): continue # 场景标题行保留并加【场景】标记，对白行加【对白】标记 if scene_pattern.match(line): cleaned.append(f"【场景】{line}") elif dialogue_pattern.match(line): role, content = re.split(r'[:：]', line, maxsplit=1) cleaned.append(f"【对白】{role.strip()}:{content.strip()}") else: cleaned.append(f"【动作】{line}") return cleaned # 处理示例：单文件清洗后按500字符切块 if __name__ == "__main__": raw = Path("sample_script.txt").read_text(encoding="utf-8") blocks = clean_script(raw) chunk, buffer = [], [] for block in blocks: buffer.append(block) if sum(len(b) for b in buffer) >= 500: chunk.append("\n".join(buffer)) buffer = [] if buffer: chunk.append("\n".join(buffer)) # chunk 即为可直接用于构造训练样本的文本块

这段脚本的核心逻辑有三处值得注意：场景标题正则故意覆盖了“内景|外景|内|外”加地点加“日|夜”的常见结构，但不覆盖“闪回”“梦境”这类特殊场景标记——这两个标记我建议在清洗之后单独手工处理，因为它们在剧本里经常和正常场景混写，模型容易误判为动作描述。“对白”正则里的角色名长度限制在 1 到 8 个字符，这是因为中文剧本的说话人标记通常不超四个字，“林助理”“王总”“母亲”都在范围内，但如果你的语料里有“出租车司机甲”这类长角色名，这个正则需要放宽到 12 字符。

切块策略上，500 字符一块不是拍脑袋定的。训练 DeepSeek 这类模型时，样本太短学不到上下文，太长又把显存和训练时间拖爆。500 到 800 字是剧本对白场景的常见长度区间——大概就是一场两三分钟的戏，包含场景描述、人物动作和一段完整对话，既能让模型学到“对话怎么接”，又不至于让它只盯着长文本的结构。

2.3 语料规模、比例与训练验证集切分的实际经验

关于行业语料微调，被问得最多的问题是“到底要多少数据才够”。我的经验是分场景看：如果你只想让 DeepSeek 学会剧本格式和基本的对白节奏，五万到十万条清洗后的场景文本块就够做一次像样的 LoRA 微调；如果你想让它学会某个特定编剧的风格，比如“对白简短、动作描写极简、喜欢用留白”，那么这个编剧有署名的作品全集是不够的，你需要把他的剧本、访谈、创作谈混在一起，凑出至少两万条风格样本才有机会让模型抓住那种“语感”。少于五千条看不出来效果，多于三十万条边际收益极低，而且训练时间翻倍。

训练集和验证集的比例我习惯用 9:1，验证集必须保证和训练集来自不同的剧本文件，而不是同一部戏里的随机抽段——否则模型见过同一场景的上下文，验证 loss 好看但没有实际参考价值。更隐蔽的一个问题是语料的“时代分布”：如果你喂进去的剧本有一半是 90 年代的情景喜剧，微调出来的模型写对白会带着明显的“室内剧节奏”，拍都市短剧就会觉得对话太密、留白不够。所以清洗之后最好按剧本类型做一次粗筛，至少要知道语料里“场景喜剧、电视连续剧、电影剧本、话剧”各占多少比例。

3. 用 LoRA 做 DeepSeek 行业语料微调：训练脚本与关键参数

3.1 为什么选 LoRA 而不是全参数微调

影视剧本微调有一个很尴尬的处境：全参数微调效果好，但成本高到大多数工作室承受不起。DeepSeek 这类模型的参数量动辄几十亿甚至上百亿，全参数微调需要把完整优化器状态、梯度、参数全塞进显存，一张 24GB 的消费级显卡根本跑不动，就算用 A100 也得租好几张。而 LoRA 的原理是冻结原始模型权重，只训练注入到注意力层和前馈层的低秩矩阵。它的核心思想是“原始模型已经懂语言，只需要微调一小部分参数让它懂剧本”，实际训练参数量可以压缩到原来的 1% 以下。

从效果上说，LoRA 在剧本任务上有一个意想不到的优势：不易灾难性遗忘。全参数微调的模型在学剧本的同时会逐渐忘记通用能力，比如逻辑推理、常识问答；而 LoRA 冻结了基座，微调完的模型既能写剧本，又不至于连“帮我想个短剧选题”这种普通对话都变得只会用剧本腔回答。影视剧本创作这个场景偏偏需要这种“双模”能力——你既要它写场景，又要它和你讨论剧情逻辑。

3.2 基于 HuggingFace 的 DeepSeek LoRA 训练脚本

下面这段脚本是我实际在用的训练流程，依赖 transformers、peft、datasets 和 torch，基座模型用 DeepSeek 的中文对话版本。训练前需要把上一章清洗好的文本块做成 JSONL 格式，每行包含 instruction 和 output 两个字段——instruction 是“请根据以下场景创建一个剧本片段”，output 是清洗后的场景文本。这种指令化的格式比单纯喂文本更能让模型学会“被要求创作时输出剧本”的触发条件。

import torch from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from datasets import load_dataset from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from trl import SFTTrainer # 1. 加载 DeepSeek 基座模型（以 7B 级模型为例，按实际显存选择） model_name = "deepseek-ai/deepseek-llm-7b-chat" model = AutoModelForCausalLM.from_pretrained( model_name, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True, ) tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True) tokenizer.pad_token = tokenizer.eos_token # 2. 配置 LoRA 参数 lora_config = LoraConfig( r=16, # 低秩矩阵的秩，决定 LoRA 的容量 lora_alpha=32, # 缩放系数，实际影响比 lr 更直观 target_modules=["q_proj", "v_proj", "k_proj", "o_proj", "down_proj", "up_proj"], lora_dropout=0.05, # 防过拟合，语料量小时建议调大到 0.1 bias="none", task_type="CAUSAL_LM", ) model = prepare_model_for_kbit_training(model) model = get_peft_model(model, lora_config) # 3. 训练参数：核心是学习率和小批量设置 training_args = TrainingArguments( output_dir="./deepseek_script_lora", num_train_epochs=3, per_device_train_batch_size=2, per_device_eval_batch_size=2, gradient_accumulation_steps=8, # 等效 batch size = 2*8 = 16 learning_rate=2e-4, # LoRA 学习率通常比全参高 10 倍 warmup_ratio=0.03, logging_steps=20, eval_strategy="steps", eval_steps=200, save_steps=500, fp16=True, # 显存不够时改用 8bit 量化加载基座 remove_unused_columns=False, ) # 4. SFTTrainer 自动拼接 instruction + output 训练 trainer = SFTTrainer( model=model, args=training_args, train_dataset=load_dataset("json", data_files="train.jsonl")["train"], eval_dataset=load_dataset("json", data_files="eval.jsonl")["train"], formatting_func=lambda x: f"【指令】{x['instruction']}\n【输出】{x['output']}", max_seq_length=1024, ) trainer.train()

这组参数踩过不少坑，逐个解释。r=16 是 LoRA 矩阵的秩，数值越大模型能记住的风格细节越多，但训练参数和显存占用也线性增长。剧本对白这类“风格强、知识弱”的任务，r=16 到 32 之间够用，r=64 我试过，生成质量没有明显提升，训练时间翻了四倍。lora_alpha=32 和 r 的比例关系是“2 倍原则”，很多新手把 lora_alpha 调到 64 或 128 想增强效果，结果模型生成内容变得重复且死板，因为缩放系数过大会让新注入的低秩矩阵在和基座权重合并时占比过重，压制了模型的原有生成多样性。

学习率 2e-4 是 LoRA 训练的最稳起点。全参数微调常用 1e-5 到 5e-5，但 LoRA 只训练少量参数，需要更高的学习率才能让它们发挥作用。如果你的显卡只支持 8bit 量化加载基座，学习率建议降到 1e-4，否则量化带来的精度损失会被放大，生成文本可能出现乱码。gradient_accumulation_steps=8 配合 per_device_batch_size=2 的实际效果是等效 batch size 16——这个值对剧本任务很重要：batch 太大会让模型忽视风格细节，太小则收敛不稳，16 是对话生成类任务的甜点位，也基本是两张 24GB 显卡能跑动的上限。

3.3 训练时长、显存占用与 checkpoint 选择策略

LoRA 微调 DeepSeek 7B 级模型，单卡 24GB 显存（如 RTX 3090/4090）可以跑，但需要打开 8bit 量化。显存占用大头不是 LoRA 参数，而是激活值和优化器状态，我实测 bf16 + 8bit 基座 + r=16 的情况下峰值显存约 18GB，刚好压线。如果是 14B 或更大参数版本，别犹豫，直接上双卡或租云 GPU。训练时长方面，十万条样本、每条约 500 字符、3 个 epoch，在单张 4090 上大约需要 6 到 10 小时，这取决于序列长度和 batch 设置。

checkpoint 不是保存越频繁越好。save_steps=500 我建议改成 save_steps=200，但只保留最后两个 checkpoint，因为剧本微调的“过拟合拐点”经常出现在最后一个 epoch 的最后三分之一处。你需要对比的是“epoch 2 结束时的 checkpoint”和“epoch 3 结束时”的生成质量——现象很常见：epoch 3 的训练 loss 比 epoch 2 低，但生成的对白开始出现“角色 A 说完上句，角色 B 复读下句”的退化迹象，这说明模型开始机械模仿语料中的高频句式，泛化能力反而下降了。保存多个 checkpoint 是事后对比的后悔药，不要只留最后一个。

4. 风格迁移的本质：不是换滤镜，是换“台词习惯”

4.1 风格迁移到底迁移的是哪个层级的特征

很多教程把风格迁移讲得像“给模型加一个风格提示词”，比如在 system prompt 里写“请用王家卫的风格写这段戏”——这能改变措辞，但改变不了模型对剧本节奏的底层理解。风格迁移在行业语料微调里的真实含义是：通过微调让模型的对白分布发生系统性偏移。具体来说，不同编剧的对白特征体现在三个可量化的维度：句长分布（A 编剧平均每句 12 字，B 编剧 25 字）、语气词密度（“嗯”“啊”“那个”出现的频次）、信息推进方式（靠对话直接推进 vs 靠动作和留白推进）。提示词只能改变表面措辞，LoRA 微调才能改变这三组统计特征。

所以在实操上，风格迁移的落地路径是“风格语料提取 → 风格 LoRA 训练 → 风格强度控制”。前两步和上一章的行业语料微调共用同一套训练流程，区别在于训练数据要全部换成目标风格的剧本文本，第三步则是推断阶段的技巧——把风格 LoRA 做到能随时上线、下线、调节强度。

4.2 把“某个编剧风格”做成可切换的 LoRA 权重

做法不复杂：在基础微调（学会剧本格式）的 checkpoint 上，再用风格语料训练一个独立的 LoRA adapter。推理时先按场景写“格式正确的剧本”，再叠加风格 LoRA 做二次生成。这样做的好处是格式能力和风格能力解耦——你换风格不需要重新训练“剧本格式”那部分，只需要换一个风格 adapter 文件。

from peft import PeftModel, PeftConfig from transformers import AutoModelForCausalLM, AutoTokenizer import torch base_model_name = "deepseek-ai/deepseek-llm-7b-chat" base_model = AutoModelForCausalLM.from_pretrained( base_model_name, torch_dtype=torch.bfloat16, device_map="auto", ) tokenizer = AutoTokenizer.from_pretrained(base_model_name) # 加载格式微调 LoRA（剧本格式能力） format_adapter = PeftModel.from_pretrained( base_model, "./deepseek_script_lora/checkpoint-2000", # 格式微调的最优 checkpoint ) # 在格式模型之上叠加风格 LoRA（风格迁移能力） style_path = "./style_lora/known_script_style" format_adapter.load_adapter(style_path, adapter_name="style_a") format_adapter.set_adapter("style_a") prompt = """【指令】请创作一场两人对话的戏：场景是深夜的便利店，人物是老陈和陌生女孩。女孩买完东西却不走。要求包含场景描述和对白。 【输出】""" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") outputs = format_adapter.generate( **inputs, max_new_tokens=800, do_sample=True, temperature=0.9, top_p=0.95, repetition_penalty=1.1, ) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

这段代码展示了叠加 adapter 的完整流程。有一个关键参数容易被忽略：repetition_penalty=1.1。风格 LoRA 微调后的模型天然有重复倾向——因为它学到的是某位编剧的惯用语，而这些惯用语在语料里反复出现。如果不加 repetition penalty，生成到 300 字左右就开始自我重复，而设置到 1.1 可以压制这个倾向又不至于让对白变得生硬。如果生成结果还是重复，就往上调到 1.15，但超过 1.2 会出现“每句话都在故意换词”的怪异感，像学生作文。

temperature=0.9是剧本创作场景的推荐值。写剧本不是解题，需要一定的随机性来产生“出乎意料的对白”。温度低于 0.7 生成结果会变得平淡，高于 1.0 则会出现逻辑断裂——角色上一句还在讨论去哪吃饭，下一句突然开始回忆童年，这种断裂在剧本里不是艺术，是 bug。

4.3 风格强度的量化控制与多风格组合

风格 LoRA 的一个独特玩法是“按比例混合多个风格”。比如你想写“悬疑剧的节奏 + 轻喜剧的对白”，可以把悬疑风格 LoRA 和喜剧风格 LoRA 按 0.6:0.4 的权重合并成一个新的 adapter，合并过程是对两个 LoRA 矩阵做加权求和。PEFT 库提供了add_weighted_adapter接口，但有一个副作用：两个 adapter 如果训练自不同 epoch 的基座，权重矩阵的尺度可能不同，直接相加会引入噪声。经验做法是先把两个 adapter 的矩阵分别做归一化，再加权，最后再乘回原始尺度。

风格强度还有一个更朴素的控制手段：训练时在语料里按比例混合风格样本和普通剧本样本。比如风格样本占 30%，模型会学到“在保留基本剧本结构的同时带有一点风格倾向”，风格样本占 70%，风格就压倒了剧本的通用性。我踩过的坑是：风格样本占比超过 80% 后，模型写所有场景都像同一部戏里的片段——古代宫廷戏、现代职场戏、科幻戏，角色说话的方式一模一样，这就叫“风格迁移过度”。

5. 剧本微调避坑：5 个让训练成果报废的常见问题

5.1 训练 loss 持续下降，但生成文本是完全不通的乱码

现象：loss 曲线非常漂亮地从 2.1 降到 0.9，但推理时输出的中文文本流畅度尚可，却夹杂着“㹴”“熌”这类生僻字，对白毫无剧情逻辑。

原因：这是典型的语料编码污染。你的清洗脚本处理的是 UTF-8 编码的文本，但很多旧剧本 PDF 转出来的纯文本是 GBK 或 GB18030 编码，转换到 UTF-8 时产生了不可见字符或错误映射。模型把这些“看起来很合法”的乱码当作正常文本学习了，loss 当然会下降。

解决：在清洗脚本里增加编码检测步骤，遇到非 UTF-8 文件先统一转码，并过滤掉所有包含 Unicode 特殊区段字符的行（比如 CJK 扩展 B 区以外的生僻字）。转码完用“随机抽 200 条样本人工检查”的方式过一遍，不要只看 loss 曲线。

5.2 微调后角色 A 经常说出角色 B 的台词

现象：生成的剧本里，两个角色在对话，但说话内容完全不符合各自的人物设定——女儿说出母亲的台词，下属说出老板的台词。

原因：语料切块时把“说话人标记”和对白内容切开了。清洗脚本按 500 字符切块，如果一条样本恰好从对白中间截断，下一块样本就没有角色名，模型在训练时学到的是“无标记的对白文本”，它没有学会“谁在说话”和“说了什么”之间的绑定关系。

解决：切块必须以“完整对白块”为单位，不能以纯字符数为准。我的做法是先把剧本按场景标记切成大块，再在每一大块内部按“对白 + 后续动作描述”为最小单位拼接，保证每条训练样本要么是一个完整的对话回合，要么是一整场戏。宁可某些样本短到 200 字，也不要让一条 800 字样本里出现半截台词。

5.3 微调完模型写什么都是“短剧”味

现象：无论你输入“写一部 90 分钟电影的开场戏”还是“写一段栏目剧片段”，模型的输出都是每场 60 到 90 秒的短剧节奏——对白密集、场景转换快、信息量大但情绪深度浅。

原因：训练语料里以短剧或短视频剧本为主，这类剧作的节奏特征就是“快速铺设冲突、三句话一个反转”。模型根据语料统计出的“剧本节奏先验”被短剧模式主导了，这和数据量无关，是语料类型分布极度偏斜造成的。

解决：在清洗阶段对语料按类型打标签，训练时按类型比例采样，把长片剧本的比例人为抬高到 40% 以上。如果你的目标本来就是要做短剧，这条可以跳过，但需要意识到：风格迁移只能改变局部语言习惯，改变不了篇幅和叙事节奏这样的全局结构特征——后者必须靠语料比例来约束。

5.4 LoRA 权重合并后生成质量反而下降

现象：单独加载 LoRA adapter 生成效果正常，但用merge_and_unload()把 LoRA 权重合并回基座模型后，生成质量明显下降，甚至出现重复和乱码。

原因：合并过程把低秩矩阵加回原始权重，但 LoRA 的缩放系数 lora_alpha 在推理时会被微调框架自动处理，合并为静态权重后，这个缩放系数如果和权重矩阵的数值尺度不匹配，就会导致注意力机制里的数值分布偏移。

解决：非必要不合并。推理时直接加载 PeftModel 和 adapter 文件，框架会正确处理缩放。如果必须合并做部署优化（比如用 vLLM 部署），合并后做一次困惑度测试，对比合并前后的生成文本，困惑度明显上升就改用“运行时加载 LoRA”的方式，不要追求静态合并。

5.5 多轮对话中剧本创作能力“断崖式消失”

现象：第一轮输入“写一个两人相遇的场景”，模型输出质量不错。接着输入“现在把场景改成雨天”，模型突然变得不会写剧本，输出退化成普通聊天内容的格式。

原因：微调时你的训练样本都是单轮的“指令 + 剧本文本”，没有构造“修改剧本”这类多轮监督数据。模型在微调中学会了“有指令就写剧本”，但没有学会“在多轮对话的上下文中继续扮演剧本创作助手”。

解决：训练数据里追加一部分多轮改写样本——把清洗好的剧本场景作为初版输出，把修改要求（换时间、换地点、增加一个角色）作为后续指令，构造两到三轮的对话格式。数据量不需要大，五千到一万条就能显著改善这个能力。

6. 微调后的部署与验证：怎么判断这次的训练真的成功了

6.1 用 vLLM 做低延迟剧本生成部署

微调出来的 LoRA 模型不能老挂着 Python 脚本跑推理，生产环境需要一个高吞吐的服务化方案。常见做法是用 vLLM 加载 DeepSeek 基座并指定 LoRA adapter 目录，然后通过兼容 OpenAI 格式的 API 对外提供服务。下面是一个最小部署配置：

# 安装 vLLM 后，直接通过命令行指定模型和 LoRA python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-llm-7b-chat \ --enable-lora \ --lora-modules script_lora=./deepseek_script_lora/checkpoint-2000 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

启动后用 curl 就能测接口：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "script_lora", "prompt": "【指令】写一段两个律师在法庭外走廊的戏【输出】", "max_tokens": 500, "temperature": 0.9 }'

部署时两个参数值得注意。--max-model-len 8192不是越大越好——剧本创作经常需要把前文背景塞进上下文，但序列长度和显存占用线性相关，如果卡只有 24GB，设成 8192 就可能 OOM，降到 4096 更稳。--gpu-memory-utilization 0.9是 vLLM 显存分配的硬上限，不要设到 0.95 以上，推理时如果触发 KV cache 重算，延迟会飙升——这是许多人说“vLLM 部署 DeepSeek 变慢了”的主要原因，不是 vLLM 慢，是显存余量留太少。

6.2 剧本质量的 4 项验证指标：不只看 loss 曲线

训练结束后，我习惯用一份固定的“剧本测试集”做四项评分，而不是只盯着验证 loss。第一项是“场景标记正确率”——生成的每一场戏是否正确包含场景标题、动作描述、对白标记，三项都有的比例超过 95% 才算格式过关。第二项是“角色一致性”——同一角色在五轮对话内的语气和意图是否保持连贯，这个指标需要人工打分，我会找两个不参与训练的同事分别打，取平均值。第三项是“对白推进度”——每段对白是否让剧情状态发生了改变（信息变化、关系变化或冲突升级），如果连续十组对白都在原地打转，说明模型学到了“对话感”但没学到“叙事感”。第四项是“风格距离”——把生成文本和风格语料的句长分布、形容词密度、语气词频率做对比，数值接近才说明风格迁移真的起效了。

表格对比是最直观的验证方式：

这条验证流程能帮你区分两种常见情况：格式微调有效但风格迁移无效，说明风格语料不够或学习率不当；格式和风格都有效但角色一致性差，说明语料切块时破坏了对白回合的完整性。总之，可量化的验证指标是微调项目的终点，也是下一次循环的起点。

6.3 进阶技巧：双阶段生成法解决“长剧本结构崩坏”

最后一个值得分享的实战技巧是“双阶段生成法”。直接让模型生成完整 90 分钟电影剧本，它一定会崩——前半部分还行，后半部分人物动机全乱，事件线索丢得七七八八。这不是微调能完全解决的问题，因为剧本的结构信息（第 1 幕埋的伏笔到第 3 幕要回收）超出了单次生成长度的“注意力跨度”。

我的做法是分两步：先用普通 DeepSeek 对话生成三幕结构大纲和每场戏的核心冲突清单，这个过程用基座模型就可以，它的通用规划和推理能力足够；然后逐一用微调后的模型填充每一场戏的具体对白和动作。填充时把“上一场戏结尾状态”和“本场戏目标”作为前缀塞进 prompt，让模型知道每一场戏从哪里开始、要往哪里走。

这个习惯我踩过不少坑之后才固定下来。最初总想让一个模型把所有事情做完，结果生成的剧本前 30 场戏质量不错，后 30 场开始人物动机混乱，像换了编剧。后来坚持“大纲用基座、对白用微调”的分工方式，生成质量稳定得多，也更容易定位问题——如果是大纲问题，从头调整结构；如果是单场对话问题，回炉改语料或调 LoRA 参数，不用整锅重烧。

现在每做完一次微调，我都会把生成样本和验证数据归档成一份固定的“测试基线”，下次调整语料或参数时直接对照，不再靠感觉判断“这版比上版好”。这个习惯帮我避开了不少玄学调参的弯路，希望也能帮到你。

本文还有配套的精品资源，点击获取