CoolFace
Datasetpublic

albertkingdom/custom-service-ticket-zh-tw

Dataset Card:客服工單分類與結構化抽取(合成資料) 資料集摘要 繁體中文(台灣)電商客服工單合成資料集,用於六分類意圖分類 + 結構化欄位抽取任務。全部資料由 teacher LLM(Claude / GPT,經 OpenRouter 呼叫)依 schema-first structured output 生成,不含任何真實客服工單,無個資/版權疑慮。共 3,148 筆,切分為 train / validation / test 三份。 使用方式 from datasets import load_dataset ds = load_dataset("albertkingdom/custom-service-ticket-zh-tw", data_files={ "train": "train.jsonl", "validation": "validation.jsonl", "test": "test.jsonl", })… See the full description on the dataset page: https://huggingface.co/datasets/albertkingdom/custom-service-ticket-zh-tw.

sourceHugging Facecc-by-4.0updated 2mo agoView on Hugging Face
0likes20downloads
Dataset Card

Dataset Card:客服工單分類與結構化抽取(合成資料)

資料集摘要

繁體中文(台灣)電商客服工單合成資料集,用於六分類意圖分類 + 結構化欄位抽取任務。全部資料由 teacher LLM(Claude / GPT,經 OpenRouter 呼叫)依 schema-first structured output 生成,不含任何真實客服工單,無個資/版權疑慮。共 3,148 筆,切分為 train / validation / test 三份。

使用方式

python
from datasets import load_dataset

ds = load_dataset("albertkingdom/custom-service-ticket-zh-tw", data_files={
    "train": "train.jsonl",
    "validation": "validation.jsonl",
    "test": "test.jsonl",
})

資料切分

分割筆數label_status 分布用途
train2,497全部 confirmed訓練集
validation326confirmed 137 / boundary 189迭代期間評測,可重複查看
test325confirmed 136 / boundary 189最終評測,只查一次,避免被迭代決策污染

`label_status` 的意義:每筆工單生成後,會用另一個獨立來源的 LLM 重複判斷 5 次做多數決驗證(避免與生成 teacher 同源系統性偏誤未被抓到)。多數決結果與原始標籤一致 → confirmed;標籤本身落在語意模糊地帶、5 次判斷不一致 → boundary。

評測時 confirmed 與 boundary 必須分開計分:confirmed 有可信 ground truth,可用 Accuracy/F1;boundary 沒有唯一正確答案,只能用重複呼叫的標籤變異度衡量,不可混算成單一 accuracy。

欄位說明

每筆記錄結構如下(JSON Lines,一行一筆):

json
{
  "ticket": {
    "ticket_text": "你好,我的服飾配件包裹已經到超商快接近保留期限了,但我還沒收到任何取貨通知耶,想請問是正常流程嗎?謝謝!",
    "category": "物流查詢",
    "primary_intent": "詢問超商取貨通知狀況",
    "order_or_product_info": "服飾配件",
    "emotion_intensity": 1,
    "needs_human": false
  },
  "is_multi_intent": false,
  "label_status": "confirmed",
  "validator_agreement_ratio": 1.0,
  "needs_human_agreement_ratio": 1.0,
  "emotion_dispersion": 0.0
}
欄位型別說明
ticket.ticket_textstring模擬台灣客服工單的原始文字,口語化,可能包含多重訴求
ticket.categoryenum(6 類,見下)主要分類,核心分類欄位
ticket.primary_intentstring從工單內容判斷出的核心訴求,簡短描述
ticket.order_or_product_infostring \null工單中提及的訂單編號或商品資訊,無則為 null
ticket.emotion_intensityint 1–5顧客情緒強度,1 平靜、5 極度不滿
ticket.needs_humanbool是否需要人工客服優先介入
is_multi_intentbool生成時是否刻意設定為多重訴求案例
label_status"confirmed" \"boundary"見上方說明
validator_agreement_ratiofloat 0–1validator 5 次判斷中,category 多數決一致比例,決定 label_status 的依據
needs_human_agreement_ratiofloat 0–1診斷用欄位,needs_human 判斷的一致比例,不參與 label_status 分流
emotion_dispersionfloat ≥ 0診斷用欄位,5 次 emotion_intensity 判斷的標準差,越低越一致,不參與 label_status 分流

六大分類定義

分類定義重點
物流查詢已下單商品的物流/配送狀態(配送延遲、包裹未送達、地址變更、取貨地點),重點是「貨走到哪、什麼時候到」,不涉及商品規格或售前疑問
退換貨申請商品退貨、換貨、退款流程
帳務爭議涉及實際金錢的爭議(信用卡重複扣款、發票金額不符、分期算錯、退款被扣手續費),不含會員點數/優惠券這類非金錢紀錄
商品諮詢下單前的售前疑問(規格、庫存、使用方式、其他版本),重點是「商品本身是什麼」,不涉及已下單商品的物流狀態
帳號/系統問題帳號本身或 App/網站系統功能異常(登入失敗、App 閃退、個資更新失敗、會員點數/優惠券未正確累計或扣除),即使涉及點數也不算帳務爭議,因為點數非實際金錢交易
客訴投訴服務態度、重大不滿,需人工優先介入

生成方法論

  • —Teacher:Claude 或 GPT,經 OpenRouter 統一呼叫,schema-first structured output(不是自由文字生成後解析)
  • —多樣性控制:商品類型 × 情境 × 情緒強度 × 是否多重訴求的組合變數矩陣,並用巢狀輪替池(PairRotator)避免多變數各自獨立輪替時在週期最小公倍數處產生規律性重複
  • —去重:DedupPool 比對同分類已收錄的全部資料,避免組合重複
  • —二次驗證:與生成 teacher 不同來源的 LLM 重複判斷 5 次做獨立分類,多數決結果決定 label_status
  • —類別平衡補生成:針對確認率偏低的分類(客訴投訴/帳務爭議)補生成,將類別分布最大最小差異從 19.4% 收斂到 10.5%
  • —後續補資料:訓練迭代階段另外針對「服務態度型客訴」補生成 30 筆,直接併入 train,是 train 筆數(2,497)高於「總生成量減去 validation/test」的原因

已知限制

誠實揭露,這些是資料生成過程中發現、記錄但尚未修正的系統性風險:

  1. 1.`needs_human` 欄位操作型定義模糊:欄位判斷幾乎完全由 emotion_intensity 單軸決定,不是驗證不穩定,是生成 prompt 對這個欄位的定義本身不夠明確
  2. 2.`客訴投訴` 分類定義偏寬鬆:訓練集中約 36% 的「客訴投訴」案例語氣其實溫和(emotion_intensity <= 2),其中部分是純商品品質抱怨,沒有 schema 定義的「服務態度」核心,跟「退換貨申請」存在灰色地帶
  3. 3.`帳務爭議` / `退換貨申請` / `帳號系統問題` / `客訴投訴` 之間存在 schema 邊界模糊案例:例如「退款用購物金退回」該算帳務爭議還是退換貨;「退款金額被莫名扣手續費」的表述會同時貼近帳務爭議定義;個資外洩類客訴會同時貼近帳號/系統問題定義。這些模糊邊界會被 boundary 案例放大,訓練出的分類模型在這些邊界上容易出現「自信但方向系統性偏移」的分類坍縮,重訓無法解決,需從收緊 schema 操作型定義著手

授權與使用限制

  • —授權條款:CC-BY-4.0(可自由使用、修改、再散布,包含商業用途,須標註來源)
  • —全部資料為 LLM 合成生成,不含真實使用者資料
  • —適用於學術研究、模型訓練實驗、教學展示
  • —語言限定繁體中文(台灣用語)

引用

無特定論文或機構需要引用。