智能销售助手Rola微调数据集-测试集

- 公开对话
  - 明确禁止的用法
- 合成数据：
三类数据数据标注的特点
三类数据集的数据量准备
训练集，验证集，测试集
如何评测微调后的效果
微调后用公开数据集测试通用能力
使用公开数据集评测微调后的模型的通用能力
公开数据集评测工具 Hugging Face evaluate

数据来源	占比
自有真实对话 + 标注	70–90%
公开对话（intent-only）	10–20%
合成数据（规则生成）	≤10%

公开对话

公开可获得的真实人类对话文本，只拿来学“用户怎么表达”，不拿来学“你要怎么卖”。

可以用的来源（工程可接受）
MultiWOZ（只用 user turns）
SNIPS（只用 intent 部分）
Kaggle 客服 / 投诉对话
Amazon / App Store 评论（筛选“犹豫/不确定”）

明确禁止的用法

❌ 不要学回复
❌ 不要学销售策略
❌ 不要混入你的 next_action 标签

否则会出现：

模型学到“别人的销售风格”，污染你自己的策略。

合成数据：

（规则生成）」是不是基于场景人工生成，而且这是冷启动阶段非常重要的一类。本质是：把业务人员脑子里的“典型客户说法”系统化产出。

三类数据数据标注的特点

简短答案：是的，标注“字段结构”要一样；但“标注深度”和“约束强度”必须不一样。
这是很多团队最容易踩坑的地方。

下面我用工程可执行的方式，把三类数据的标注一致性原则讲清楚。

一、一个总原则（必须记住）

模型只能学一种“输出接口”。
不管数据来自哪里，label schema 必须完全一致，否则 LoRA 学不到稳定偏置。

也就是说：

同样的 intent 枚举
同样的字段名
同样的取值空间

这一点对三类数据是完全一致的。

二、但三类数据的「标注深度」不同（这是关键）

① 自有真实对话 + 标注（最深）

这是主训练集，标注要“完整、严格”。

{
  "input": "这个价格有点高，我得回去跟老板确认",
  "intent": "OBJECTION_EXPRESSION",
  "objection_type": "PRICE",
  "stage": "EVALUATION",
  "next_action": "PRESENT_VALUE"
}

特点：

多标签
强业务约束
用于真正“学决策”

② 公开对话（intent-only）（刻意变浅）

这里只标你 100% 确定的字段。

{
  "input": "我再看看别的方案吧",
  "intent": "OBJECTION_EXPRESSION"
}

明确原则：

✔ 只标 intent
❌ 不标 stage
❌ 不标 next_action
❌ 不推断销售策略

原因很现实：

你无法从别人的对话里，安全推断“你公司下一步该怎么做”。

③ 合成数据（规则生成）（结构完整，但来源不同）

合成数据的字段结构和真实数据完全一致：

{
  "input": "这个价格对我们来说有点高，能不能再优惠点？",
  "intent": "OBJECTION_EXPRESSION",
  "objection_type": "PRICE",
  "stage": "EVALUATION",
  "next_action": "OFFER_DISCOUNT"
}

但它的前提是：

场景已被业务确认
策略是确定性的
属于“已知规则”

三、为什么不能三类数据都“同样标全”

这是一个模型层面的硬约束问题。

如果你对公开数据也标 next_action，会发生什么？

公开数据里的“策略”是别人的
LoRA 会把这些策略学进去
结果是：
- 模型在你业务里推错动作
- 且错误非常稳定（很难纠正）

如果你对合成数据只标 intent，会发生什么？

浪费合成数据的价值
本来是“规则固化”
却只学到“语言重复”

四、一个你可以直接落地的对照表

数据来源	schema 是否一致	标注深度
自有真实对话	✔ 完全一致	最深
公开对话	✔ 完全一致	最浅（intent-only）
合成数据	✔ 完全一致	深（等同真实）

五、一个非常重要的工程细节（容易忽略）

缺失字段要怎么处理？

不要乱填 null 或猜。

推荐方式：

{
  "input": "我再考虑一下",
  "intent": "OBJECTION_EXPRESSION"
}

而不是：

{
  "input": "我再考虑一下",
  "intent": "OBJECTION_EXPRESSION",
  "stage": "EVALUATION",
  "next_action": "PRESENT_VALUE"
}

不确定，就不要标。
模型比你更怕“错误的确定性”。

六、一句话总结（给团队用）

三类数据用同一套标签体系，但不承担同一层决策责任。
真实数据负责“学决策”，公开数据负责“学表达”，合成数据负责“固规则”。

三类数据集的数据量准备

针对智能销售助手的 LoRA 微调，数据量的分配和数量规模取决于三个因素：

真实数据稀缺程度
公开数据和合成数据的辅助作用
模型参数量和微调容量（LoRA 低秩矩阵通常容量较小）

下面我给你一个工程可执行的数量参考。

一、总原则

真实对话为核心（70–90%），公开对话辅助（10–20%），合成数据补充长尾（≤10%）

LoRA 参数容量有限，不需要大量数据
数据质量优先于数量
冷启动阶段无需上万条真实对话也能微调出效果

二、三类数据数量参考

数据来源	建议数量	说明
自有真实对话 + 标注	1,000–5,000 条	核心训练集；覆盖不同意图、阶段、异议类型。数量越多越稳定，但 1k 也能起作用。
公开对话（intent-only）	200–1,000 条	用于增加语言多样性，只标 intent。
合成数据（规则生成）	100–500 条	用于覆盖已知业务规则长尾，字段完整。

⚠️注意：比例要控制在前面说的 70–90% / 10–20% / ≤10%，否则 LoRA 容易学到噪声或策略偏差。

三、数量设计思路（如何快速规划）

先统计意图分布
- 核心意图 ≥ 50 条样本
- 次要意图 ≥ 10–20 条样本
异议类型 + 阶段组合覆盖
- 核心组合至少 5–10 条样本
- 长尾组合可用合成数据补充
冷启动策略
- 真实对话最少 1k，保证 LoRA 能学到决策偏置
- 公开对话和合成数据按比例增加语言和场景覆盖

四、举例（可直接落地）

假设你有 5 个核心意图，每个意图有不同阶段和异议类型：

核心真实数据：2,500 条
公开对话（intent-only）：500 条
合成规则数据：250 条

总计：3,250 条，分配比例大约 77% / 15% / 8%，非常符合工程经验。

五、工程实践经验

真实数据少于 500 条：LoRA 微调效果不稳定
真实数据超过 5k 条：LoRA 仍可工作，但收益边际递减
公开数据和合成数据比例过大：容易“学错策略”

六、一句话总结

LoRA 微调不是为了训练海量数据，而是为了让模型学会你自己的决策偏置。
真实对话 1–5k 条 + 适量公开/合成数据，通常就够冷启动了。

训练集，验证集，测试集

我帮你把 验证集 (Validation) 和 测试集 (Test) 的特点区分得更清楚，用工程思路+业务场景说明，保证一眼就能理解。

一、核心区别概念

数据集	核心作用	什么时候用	数据特点	示例指标
验证集（Validation）	微调效果评估，调参 / Early Stopping	训练阶段，模型微调完成后立即评估	- 与训练集不同，但来源同业务场景 - 覆盖核心意图 + 阶段 - 数量 100–500 条	Intent Accuracy, Next-Action Accuracy, Stage Correctness
测试集（Test）	泛化能力检测 & 上线前验证	微调完成后 & 上线前或上线后	- 与训练集和验证集完全独立 - 可包含长尾场景 / 新客户表达 / 公开数据集 - 数量可少，但覆盖边缘场景	Intent Accuracy, Stage/Flow Correctness, 对比原模型性能

二、用业务场景比喻

假设你在做智能销售助手：

训练集
- 你把销售团队过去对话 + 核心意图整理成 2,500 条
- 模型学到：核心业务意图、阶段和动作
验证集
- 从同一业务场景抽出 300 条没在训练集出现的对话
- 作用：
  - 检查模型是否正确识别意图
  - 检查预测动作是否合理
  - 决定是否 Early Stopping / 调整 LoRA 超参数
测试集
- 包含真实业务新场景或公开对话样本
- 作用：
  - 测试模型在长尾客户说法、复杂表达上的表现
  - 测试微调后模型是否破坏原始通用能力（逻辑、常识、语言理解）

对，这可以用比例理解，但需要具体区分验证集和测试集的作用，不能简单按训练集比例随意设置。下面我给你整理成工程可执行的方案：

一、推荐比例（工程经验）

数据集类别	占比（相对于训练集）	数量示例（假设训练集 2,500 条）	说明
训练集	100%	2,500 条	核心业务数据，微调模型的主力
验证集	10–20%	250–500 条	与训练集不重复，检测微调效果，用于调参/Early Stopping
测试集	≤10%	≤250 条	完全独立，检测泛化能力 + 通用能力，可包含长尾场景或公开数据

注：这里的“占比”是相对训练集数量的经验值，不是严格公式，主要是保证验证集和测试集足够覆盖意图和阶段，但不要占用训练集过多数据。

二、设计思路

训练集：覆盖核心业务意图 + 阶段组合
验证集：随机抽取训练集之外的真实业务对话，覆盖核心意图
测试集：可选公开数据或未见过客户表达，覆盖长尾/复杂场景

三、工程原则

验证集比例太小（<5%）：难以可靠评估微调效果
验证集比例太大（>20%）：占用训练数据，影响模型学习
测试集比例一般 ≤10%，主要用于上线前或上线后监控
训练/验证/测试三者不重叠

如何评测微调后的效果

检测 LoRA 微调效果，要对照业务目标和模型行为两个维度，既要看模型在训练集上的表现，更要看它在真实业务场景中的泛化能力。下面给你一个系统、可落地的检测方案。

一、核心原则

LoRA 微调不是通用能力提升
- 目标是学业务决策偏置（意图识别 + 下一步动作）
检测指标必须贴近业务决策
- 纯语言生成指标（如 BLEU、ROUGE）意义有限
对比基线
- 微调前模型 + Prompt 控制 = 基线
- 微调后模型 = 测试对象

二、检测维度

1️⃣ 意图识别准确率（Intent Accuracy）

核心指标
方式：
1. 准备验证集（最好是真实对话，100–500 条）
2. 比较预测 intent 与标注 intent 是否一致
指标：
- 准确率（Accuracy）
- Top-2/Top-3 准确率（可选）

2️⃣ 下一步动作预测准确率（Next-Action Accuracy）

直接衡量 LoRA 学到的业务偏置
方法：
- 验证集标注 next_action
- 预测结果对比
指标：
- Accuracy
- 可结合 F1-score，如果动作类别不均衡

3️⃣ 流程闭环正确率（Business Flow Accuracy）

针对销售阶段和流程推进
检查：
1. 模型输出的动作是否符合当前 stage 和 intent
2. 是否产生非法动作（例如“推折扣”在初次接触阶段）
指标：
- 合规率 = 正确动作 / 总动作
- 阶段跳跃率 = 错误跨阶段动作占比

4️⃣ 泛化能力（Generalization）

用未见过的真实对话进行测试
可用以下方法：
1. 留出部分真实对话作为测试集
2. 收集上线后的真实交互日志
指标：
- 与验证集类似，但重点关注新用户表达、长尾意图、长句子/复杂表达

5️⃣ 对比 Prompt 基线（可选）

微调前：
- 基于 Prompt + 系统指令的预测
微调后：
- LoRA + 相同 Prompt
对比：
- 意图准确率提升
- Next-Action 正确率提升
- 错误分布变化

目的是量化 LoRA 的实际增益，而不是绝对数值

三、可落地的检测流程

准备验证集
- 真实对话，完整标注 intent + next_action + stage
前测基线
- 测 Prompt 模型输出指标
微调 LoRA
- 训练完成
后测指标
- 同验证集上做预测
对比分析
- 指标提升
- 错误类型变化（是“边缘意图”改进，还是“核心决策”改进）

四、日志/在线指标（上线后）

用户实际交互日志 → 收集预测 vs. 实际动作
指标：
- 意图匹配率
- Next-Action 完成率
- 阶段正确率
可形成 滚动反馈闭环：
- LoRA 微调增量数据
- 再微调/迭代

五、避免常见误区

误区	正确做法
只看训练集损失下降	换到验证集/真实对话检测
用 BLEU/ROUGE 检测销售助手	关注业务动作准确率
上线就用 LoRA 微调	先做离线验证、再小规模上线

六、一句话总结

检测 LoRA 微调效果的核心，是“业务决策准确率”，而不是语言生成质量”。
意图、下一步动作、流程闭环正确率 + 泛化能力，是最直接可量化指标。

微调后用公开数据集测试通用能力

针对你问的 “微调后用公开数据集测试通用能力，需要准备多少数据”，我们可以用工程可执行原则来设计，不需要太多，因为这只是检测，不是训练。

一、核心原则

测试目的不是训练
- 只是验证 LoRA 微调是否破坏原模型的通用能力（逻辑、常识、对话理解等）
覆盖即可，不追求数量庞大
- 核心是每类能力都有样本代表，不需要上万条
保证与训练集无交集
- 测试集必须独立于训练数据和验证数据

二、公开测试数据集数量建议

能力类型	数据集示例	建议数量	说明
自然语言理解	MultiNLI / SNLI	200–500 条	检查逻辑/语义理解，不用全部数据集
QA / 文本理解	SQuAD / Natural Questions	200–500 条	检查阅读理解，抽取代表性问题即可
常识推理	COPA / CommonsenseQA	100–200 条	长尾常识问题足够覆盖常见推理能力
多轮对话	MultiWOZ	100–300 条	检查多轮对话理解，抽取 20–50 个场景每轮 3–5 轮即可

⚠️总量不需要很大：大概 600–1,500 条样本就足够检测通用能力。
目标是覆盖能力类别，而不是统计显著性

三、设计思路

每个能力类别抽取代表性样本
- 逻辑、推理、理解、对话四类都要覆盖
保证数据独立
- 不要和微调训练数据重复
指标
- 精度（Accuracy）、F1、Macro-F1
- 可和微调前模型对比，关注是否下降
采样策略
- 随机抽取 + 长尾代表样本
- 真实场景 + 公共数据集结合

四、总结

不需要大规模公开数据，只要每类能力覆盖代表性样本
600–1,500 条即可，保证指标可测微调影响。

使用公开数据集评测微调后的模型的通用能力

可以把整个流程拆成两个核心步骤：如何使用公开数据集评测通用能力 + 可用工具和方法。我帮你整理成工程可落地方案。

一、使用公开数据集评测微调后的模型通用能力

1️⃣ 准备公开测试集

选择代表性数据集（之前表格里列出的几类能力）：
- 自然语言理解：MultiNLI / SNLI
- QA / 文本理解：SQuAD / Natural Questions
- 常识推理：COPA / CommonsenseQA
- 多轮对话：MultiWOZ
采样原则：
- 每类能力 100–500 条样本即可
- 样本尽量覆盖各种场景、长尾情况
- 与微调训练集、验证集完全独立
格式化数据：
- 统一成 {input, label} 格式，和 LoRA 微调模型输出对比
- 对话数据可按 turn 拆分或按完整对话保留

2️⃣ 定义评测指标

不同能力对应指标：

能力类型	指标
自然语言理解	Accuracy、F1-score
QA / 文本理解	Exact Match (EM)、F1
常识推理	Accuracy
多轮对话	Intent Accuracy、Slot Accuracy、Dialogue Success Rate

对比微调前后模型：
- 基线：原始大模型 + 相同 Prompt
- 测试：LoRA 微调模型
- 指标差异衡量微调是否破坏通用能力

3️⃣ 执行评测流程

模型推理
- 对公开测试集逐条输入模型
- 获取预测结果
指标计算
- 对比 预测结果 与 标注 label
- 输出 Accuracy、F1 等
分析结果
- 如果微调后 Accuracy / F1 下降明显 (>3–5%) → 说明微调可能破坏通用能力
- 观察哪些能力类别下降 → 可能是 LoRA 学到过度偏置

二、可用工具

1️⃣ 机器学习评测工具

工具	功能	说明
scikit-learn	Accuracy, F1, Precision, Recall	Python 库，计算分类指标简单方便
seqeval	Slot / Sequence Label Accuracy	用于对话 NER / Slot 标签评测
Hugging Face `evaluate`	支持多种 NLP 任务指标	EM, F1, BLEU, ROUGE 等
pandas / numpy	数据处理 & 指标计算	配合 Python 自定义分析

2️⃣ 对话类评测

MultiWOZ Evaluation Scripts：计算对话成功率、Slot Accuracy
自定义脚本：
- 对每轮预测意图 / 动作计算 Accuracy
- 统计流程错误率（比如阶段跳跃）

3️⃣ 流程可视化

┌─────────────┐
│ 公开测试集    │
│ (input,label)│
└─────┬───────┘
      │
      ▼
┌─────────────┐
│  LoRA模型预测 │
│   (output)   │
└─────┬───────┘
      │
      ▼
┌─────────────┐
│  指标计算    │
│ Accuracy/F1 │
└─────┬───────┘
      │
      ▼
┌─────────────┐
│ 分析 & 对比  │
│ 基线 vs 微调 │
└─────────────┘

三、总结

公开数据集评测目的是验证微调对通用能力的影响
样本不需要很多，覆盖能力类别即可（600–1500 条）
指标主要是 Accuracy / F1 / Dialogue Success Rate
工具推荐：scikit-learn, seqeval, Hugging Face evaluate, MultiWOZ 官方脚本

公开数据集评测工具 Hugging Face `evaluate`

完全可以，只用 Hugging Face evaluate 就足够大部分通用能力评测了。

我帮你分析一下为什么可行，以及适用场景：

一、为什么只用 Hugging Face `evaluate`

支持多种任务指标
- 分类指标：Accuracy, F1, Precision, Recall
- QA 指标：Exact Match (EM), F1
- 文本生成指标：BLEU, ROUGE, METEOR
- 多轮对话指标：可以自定义 slot / intent 准确率
统一接口
- 不需要切换 scikit-learn、seqeval、官方脚本
- Python 直接调用，数据处理简单
社区维护
- Hugging Face 官方维护，适配主流 NLP 数据集
- 可以直接加载公开数据集，如 MultiNLI、SQuAD、COPA 等

二、适用场景

能力类型	数据集示例	是否可用 `evaluate`
自然语言理解	MultiNLI / SNLI	✅ Accuracy / F1
QA / 文本理解	SQuAD / Natural Questions	✅ Exact Match / F1
常识推理	COPA / CommonsenseQA	✅ Accuracy
多轮对话	MultiWOZ	⚠️ 需要自定义 metric（intent/slot accuracy）

对 MultiWOZ，你可以用 evaluate 自定义一个函数计算 意图正确率 / Slot Accuracy / Dialogue Success Rate，不必引入 seqeval 或官方脚本。

三、推荐做法

准备数据
- 转换成 {input, label} 格式

调用 Hugging Face evaluate

from evaluate import load

metric = load("accuracy")  # 或 "f1", "exact_match"
results = metric.compute(predictions=preds, references=labels)
print(results)

多轮对话自定义指标
- 对每轮预测意图/slot计算 Accuracy
- 对比真实对话的阶段流转是否正确

四、总结

只用 Hugging Face evaluate 就能覆盖绝大部分任务，
对 MultiWOZ 这种对话任务，只需写一个小函数计算 slot/intent 准确率即可，不必引入 seqeval 或官方脚本。

如果你愿意，我可以帮你写一个Hugging Face evaluate 的全套 Python 模板，可以直接跑 LoRA 微调后的模型通用能力评测，包括分类、QA、常识推理和多轮对话指标。

你希望我直接出这个模板吗？

posted @ 2025-12-30 09:01 向着朝阳阅读(84) 评论(0) 收藏举报

刷新页面返回顶部

aibi1

智能销售助手Rola微调数据集-测试集

公开对话

明确禁止的用法

合成数据：

三类数据 数据标注的特点

一、一个总原则（必须记住）

二、但三类数据的「标注深度」不同（这是关键）

① 自有真实对话 + 标注（最深）

② 公开对话（intent-only）（刻意变浅）

③ 合成数据（规则生成）（结构完整，但来源不同）

三、为什么不能三类数据都“同样标全”

如果你对公开数据也标 next_action，会发生什么？

如果你对合成数据只标 intent，会发生什么？

四、一个你可以直接落地的对照表

五、一个非常重要的工程细节（容易忽略）

缺失字段要怎么处理？

六、一句话总结（给团队用）

三类数据集的数据量准备

一、总原则

二、三类数据数量参考

三、数量设计思路（如何快速规划）

四、举例（可直接落地）

五、工程实践经验

六、一句话总结

训练集，验证集，测试集

一、核心区别概念

二、用业务场景比喻

一、推荐比例（工程经验）

二、设计思路

三、工程原则

如何评测微调后的效果

一、核心原则

二、检测维度

1️⃣ 意图识别准确率（Intent Accuracy）

2️⃣ 下一步动作预测准确率（Next-Action Accuracy）

3️⃣ 流程闭环正确率（Business Flow Accuracy）

4️⃣ 泛化能力（Generalization）

5️⃣ 对比 Prompt 基线（可选）

三、可落地的检测流程

四、日志/在线指标（上线后）

五、避免常见误区

六、一句话总结

微调后用公开数据集测试通用能力

一、核心原则

二、公开测试数据集数量建议

三、设计思路

四、总结

使用公开数据集评测微调后的模型的通用能力

一、使用公开数据集评测微调后的模型通用能力

1️⃣ 准备公开测试集

2️⃣ 定义评测指标

3️⃣ 执行评测流程

二、可用工具

1️⃣ 机器学习评测工具

2️⃣ 对话类评测

3️⃣ 流程可视化

三、总结

公开数据集评测工具 Hugging Face evaluate

一、为什么只用 Hugging Face evaluate

二、适用场景

三、推荐做法

四、总结

公告

三类数据数据标注的特点

公开数据集评测工具 Hugging Face `evaluate`

一、为什么只用 Hugging Face `evaluate`