基于 DeepSeek 的 ITSM 工单意图识别实践 —— 从 Prompt 工程到 Go 后端集成

一、背景与痛点

在企业 IT 运维体系中，工单系统 (ITSM, IT Service Management) 是承载事件管理 (Incident)、服务请求 (Service Request)、变更管理 (Change Management) 等核心流程的枢纽。然而随着数字化程度的提升，工单量级不断攀升，业务类型愈发复杂，人工分单、人工识别意图的模式逐渐暴露出以下痛点：

1. 人工分单效率低：用户提交工单后，人工客服或一线工程师需要判断工单类型，分派给相应的支持组，耗时且易出错。
2. 规则引擎难以维护：传统基于关键字的分类规则复杂且僵硬，随着业务扩展不断膨胀，导致规则冲突与维护成本高企。
3. 工单延误与客户不满：错误分派或延迟识别直接造成 SLA 违约，引发用户投诉。

于是，借助 大模型（LLM, Large Language Model） 的 意图识别能力，让工单系统能够 自动理解用户诉求 → 分类 → 分派，成为企业智能化运维的关键方向。

在此背景下，DeepSeek 模型凭借其轻量化、多任务理解能力、低成本推理的特性，非常适合作为 工单意图识别引擎 的核心组件。

本文将结合真实 ITSM 语料，系统性介绍如何基于 DeepSeek + Go 后端 构建企业级 智能工单意图识别方案。

二、意图识别在智能工单系统中的价值

在 ITSM 体系中，工单大致分为以下几类：

1. Incident (事件报障) —— 网络故障、系统崩溃、VPN 无法连接。
2. Service Request (服务请求) —— 账号申请、软件安装、硬件申请。
3. Change Request (变更请求) —— 配置变更、系统升级、资源扩容。
4. Information Query (信息查询) —— 工单进度、账单咨询、操作指引。
5. Complaint (投诉反馈) —— 服务慢、工单延误、系统性能不满。
6. Other (其他) —— 含糊不清、追问进展等。

如果企业能通过 自动化意图识别 实现：

• 工单提交即自动归类 → 直接分派到责任团队；
• 提前识别投诉或 SLA 风险工单 → 提升服务感知；
• 持续沉淀工单语料 → 优化分类模型与知识库；

将显著提升 工单处理效率、客户满意度、运维自动化水平。

三、DeepSeek 模型选择与 Prompt 工程

3.1 模型选择

DeepSeek 提供多种推理模型：

• deepseek-chat —— 通用对话理解，适合意图识别。
• deepseek-r1 —— 强逻辑推理，适合分类、结构化输出。

在意图识别场景下，我们推荐 deepseek-r1 或 deepseek-chat，前者适合精准分类，后者在开放语料下表现更灵活。

3.2 Prompt 设计原则

为了保证模型输出稳定，我们遵循以下原则：

1. 定义分类全集 —— 明确所有一级意图、二级意图。
2. 固定输出格式 —— 强制模型输出 JSON，以便程序解析。
3. 提供 few-shot 示例 —— 给出典型案例，帮助模型学习分类边界。
4. 限定 reasoning 简短说明 —— 避免模型啰嗦输出。

3.3 Prompt 示例

你是一个 ITSM 智能助手，需要根据用户输入的文本，识别该工单/对话的意图。  
请严格输出 JSON 格式，包含以下字段：
- intent: 主意图类别 (Incident / Service_Request / Information_Query / Change_Request / Complaint / Other)
- sub_intent: 二级意图类别
- confidence: 0-1之间的小数，代表置信度
- reasoning: 简要说明原因（不超过20字）

意图类别全集：
1. Incident
   - Network_Failure, Email_IM_Failure, VPN_Failure, App_Crash, DB_Error, Storage_Failure, Device_Failure
2. Service_Request
   - Account_Creation, Access_Request, Software_Install, Hardware_Request, Mailbox_Request, VPN_Request, Certificate_Request
3. Information_Query
   - Maintenance_Info, Account_Status, Ticket_Status, User_Guide, Billing_Info
4. Change_Request
   - System_Config_Change, Server_Upgrade, DB_Upgrade, App_Upgrade, Network_Policy_Change
5. Complaint
   - Service_Attitude, Ticket_Delay, System_Performance
6. Other
   - Follow_Up, Uncategorized

### Few-shot 示例
用户输入: "VPN 登录不上去，显示认证失败"
输出:
{
  "intent": "Incident",
  "sub_intent": "VPN_Failure",
  "confidence": 0.93,
  "reasoning": "VPN认证失败"
}

用户输入: "请帮我开通一个新的OA账号"
输出:
{
  "intent": "Service_Request",
  "sub_intent": "Account_Creation",
  "confidence": 0.97,
  "reasoning": "账号申请"
}

该 Prompt 可直接投喂 DeepSeek，保证输出结构化 JSON。

四、ITSM 语料设计与分类全集

在训练和测试中，我们需要一套覆盖全面的 ITSM 工单语料库。以下是示例：

4.1 Incident

• 我的电脑无法连接公司 WiFi → Network_Failure
• 邮箱一直提示密码错误，收不到邮件 → Email_IM_Failure
• ERP 系统频繁崩溃，无法录入数据 → App_Crash

4.2 Service Request

• 请帮我开通一个新的 OA 账号 → Account_Creation
• 我要申请一台新的笔记本电脑 → Hardware_Request
• 帮我安装 Photoshop 软件 → Software_Install

4.3 Change Request

• 我要把测试环境内存升级到 32G → Server_Upgrade
• 数据库存储不足，请申请扩容 50G → DB_Upgrade
• 请求调整防火墙规则，开放 443 端口 → Network_Policy_Change

4.4 Complaint

• 你们服务太差了，处理速度太慢 → Service_Attitude
• 工单总是超时，没人跟进 → Ticket_Delay
• 系统太卡了，性能太差 → System_Performance

完整语料库建议扩展到 500-1000 条，覆盖多业务线、多语气表达，作为模型验证与微调数据。

五、Go 后端集成实践

5.1 Go 调用 DeepSeek API

我们采用 go-openai SDK 调用 API（兼容 DeepSeek API 格式）。

package main

import (
"context"
"encoding/json"
"fmt"
"log"

 openai "github.com/sashabaranov/go-openai"
)

type IntentResult struct {
 Intent     string`json:"intent"`
 SubIntent  string`json:"sub_intent"`
 Confidence float64`json:"confidence"`
 Reasoning  string`json:"reasoning"`
}

func main() {
 client := openai.NewClient("YOUR_API_KEY")
 userQuery := "我的邮箱收不到邮件"

 prompt := fmt.Sprintf(`...few-shot prompt... 用户输入: "%s"`, userQuery)

 resp, err := client.CreateChatCompletion(
  context.Background(),
  openai.ChatCompletionRequest{
   Model: "deepseek-chat",
   Messages: []openai.ChatCompletionMessage{
    {Role: "system", Content: "你是一个专业的 ITSM 意图识别助手。"},
    {Role: "user", Content: prompt},
   },
  },
 )
if err != nil {
  log.Fatalf("API error: %v", err)
 }

var result IntentResult
if err := json.Unmarshal([]byte(resp.Choices[0].Message.Content), &result); err != nil {
  log.Fatalf("JSON 解析失败: %v", err)
 }

 fmt.Printf("识别结果: %+v\n", result)
}

5.2 Ent Schema 设计

type IntentResult struct {
 ID         int     `json:"id"`
 TicketID   int     `json:"ticket_id"`
 Intent     string  `json:"intent"`
 SubIntent  string  `json:"sub_intent"`
 Confidence float64 `json:"confidence"`
 Reasoning  string  `json:"reasoning"`
 CreatedAt  time.Time
}

该表可与 工单表 (Ticket) 建立外键关联，实现 工单 → 意图识别结果 的落库。

5.3 集成流程

1. 用户提交工单 → Ticket 入库。
2. 触发 DeepSeek API 调用 → 获取 IntentResult。
3. 落库 → 存入 IntentResult 表。
4. 自动分派引擎 → 根据 intent/sub_intent 匹配责任组。
5. 运维自动化执行 → 可触发脚本、流程引擎、机器人响应。

六、落地挑战与优化

1. 分类边界模糊：有些语料既可归为 Incident 也可归为 Complaint，需要结合上下文或 SLA 状态判断。

• 优化：引入多轮上下文或结合工单元数据。

• 输出 JSON 不稳定：LLM 偶尔会输出多余文字或解释，导致 JSON 解析失败。

• 优化：使用正则抽取 JSON 或在 system prompt 强制要求 只输出 JSON。

• 性能与成本：高并发下调用大模型成本较高。

• 缓存高频语料 → 使用 Redis 记忆；
• 小模型本地化推理 → 结合 RAG 或蒸馏模型；
• 批量请求 → 降低 API 调用次数。

• 优化：

• 语料覆盖度：若分类全集未覆盖某些场景，模型会错误分类。

• 优化：持续收集工单语料，定期扩展分类全集。

---

七、总结与展望

本文介绍了如何基于 DeepSeek 模型 实现 ITSM 工单意图识别，从痛点分析、语料分类、Prompt 工程，到 Go 后端集成与落地优化。该方案在企业数字化运维转型中具有显著价值：

• 提升效率：工单自动分派，减少人工干预。
• 增强体验：快速识别投诉工单，提前 SLA 风险预警。
• 知识沉淀：通过意图识别结果，沉淀运维知识体系。

未来方向：

1. 引入多模态识别 —— 结合截图、日志文本，实现更准确分类。
2. 多语言支持 —— 支持中英文混合语料，适配跨境业务。
3. 在线学习与反馈闭环 —— 用户修正分类结果后，自动进入训练集，持续优化模型。

最终目标是打造一个 智能化、自学习、可观测 的 ITSM 工单系统，真正实现企业运维的自动化与智能化升级。