AI分类准确率从50%飙到90%，我只做了这两件事
你有没有遇到过这种场景——一堆工单/反馈/邮件需要分类，人工分又慢又不准，想用AI却发现它比人还离谱？
我接手事件单分类时就是这样：前任分类被吐槽"乱分"，我一看数据，AI裸跑准确率只有50-60%。但最后只加了两招，准确率直接干到90%+。不用更贵的模型，不写更长的Prompt，核心思路就四个字：让数据说话。
先说结论
整个系统的核心策略就一句话：规则优先，AI兜底。
事件单导入
│
├─ 含案例ID？ ──是──→ 案例映射表匹配 → 直接分类（~20%）
│ │
├─ 含URL？ ──是──→ URL规则匹配 → 直接分类（~5%）
│ │
└─ 否 ──→ AI分类（增强Prompt） ──→ 解析 → 校验 → 通过（~70%）
│
└─ 校验失败 → 人工复核（~5%）
25%的事件单零AI调用直接出结果，剩下75%交给增强Prompt的AI，最终只有5%需要人工介入。
下面拆解怎么做到的。
为什么AI裸跑只有50%？
AI分类看起来简单——把文本扔给大模型，让它选一个分类。但实际跑起来有三个坑：
坑1：AI不按格式返回。 你要JSON，它给你一段带解释的文字；你要L1/L2/L3/L4，它给你一整段分析。输入都不稳定，后面的流程全废。
坑2：AI会"创造"分类。 分类字典里没有的名称，AI会自己编一个出来。看起来像那么回事，但根本对不上你的分类体系。
坑3：分类边界模糊。 有些事件单连人工都分不清该归哪类，AI更分不清。光靠一个分类字典，AI没有足够的判断依据。
先解决坑1和坑2，让系统跑通；再解决坑3，把准确率拉上去。
让AI乖乖输出结构化数据：三层漏斗
这是整个系统跑通的前提。大模型是自由文本生成模型，不保证输出格式，我用三层约束形成漏斗：
第一层：Prompt格式契约
在系统提示词中做三件事：
- 注入完整分类树JSON，告诉AI"只能从字典中选，不能自己编"
- 明确约定输出格式：
{"L1": "xxx", "L2": "xxx", "L3": "xxx", "L4": "xxx"} - 加一句"只输出JSON，不要输出其他内容"
第二层：多格式响应解析
AI的返回千奇百怪，解析逻辑要覆盖三种情况：
- 包裹在markdown代码块中 → 正则提取代码块内容
- JSON前后有额外解释文字 → 正则提取第一个
{...} - 字段大小写不一致（L1 vs l1）→ 统一兼容处理
解析失败不报错，返回空分类，让流程继续走。
第三层：分类路径合法性校验
即使AI返回了合法JSON，值也可能不在字典中，或L1→L2→L3→L4不构成有效路径。逐级校验：先验证L1，再验证L2是否属于该L1，以此类推。不合法的字段置空，保留合法部分。
Prompt约束 → 多格式解析 → 路径校验，三层漏斗确保100%的事件单都能获得可解析、可入库的结构化结果。这一步解决的是"能用"的问题。
第一招：案例链接锚定——25%的事件单零AI调用
观察数据时发现一个关键特征：解决方案中带案例链接的事件单，其分类几乎是确定的。 因为案例链接意味着该问题已有标准解法，分类是明确的。
思路很简单：从5000条历史数据中，离线提取所有案例ID与分类的映射关系。
- 遍历历史数据，用正则从解决方案中提取案例ID
- 对同一案例ID，统计其关联的所有分类及出现次数
- 取出现次数最多的分类作为该案例的最终映射
运行时，如果解决方案中包含案例链接，直接查表匹配，零AI调用，准确率接近100%。多个案例ID时，优先选历史命中次数最多的。
同理，没有案例ID但包含其他URL的事件单，也从历史数据中提取URL模式→分类的规则映射，只保留命中2次以上且分类一致性≥50%的规则。
这一招的本质：确定性场景不需要AI，查表就够了。
第二招：历史数据驱动的Prompt增强——准确率翻倍
这是最大的突破。仅提供分类字典时，AI没有足够的判断依据，准确率只有50-60%。与其绞尽脑汁写Prompt，不如让历史数据教AI怎么分。
从5000条历史数据中做了三件事：
1. 为每个分类生成描述和典型示例
统计每个分类下事件单的高频关键词、故障表象和典型标题，生成分类指南。每个条目包含：分类层级、名称、父分类、典型标题示例、故障表象标签。
AI拿到这些信息后，相当于有了一个"老员工的经验手册"，不再是两眼一抹黑。
2. 提取高置信度分类规则
基于案例链接和根因分析，提取每个分类的根因关键词、故障表象、典型标题，形成规则集。每条规则包含：完整分类路径、历史单量、根因关键词列表、故障表象列表、典型标题示例。
3. 全部注入System Prompt
最终增强后的Prompt结构：
[角色定义] 你是运维事件单分类助手
[分类字典] 完整L1~L4分类树JSON
[分类说明] 每个分类的描述 + 故障表象 + 典型例子
[判断要点] L1大类判断规则 + 关键词线索
[历史规则] 高置信度分类规则（含根因、故障表象、典型标题）
[输出格式] JSON格式约束
准确率从~60%直接跳到90%以上。 没有换模型，没有加参数，只是让数据替Prompt说话。
整体架构一览
系统采用前后端分离架构，后端Node.js + Express，前端Vue3 + Element Plus，数据存储使用lowdb，AI调用通过OpenAI兼容协议对接大模型。
┌──────────────────────────────────────────────────┐
│ 前端 (Vue3 + Element Plus) │
│ TicketList │ AI识别弹窗 │ 批量进度弹窗 │
└──────────────────────┬───────────────────────────┘
│ HTTP REST API / SSE
┌──────────────────────┼───────────────────────────┐
│ 后端 (Express) │
│ ┌─────────────────▼──────────────────┐ │
│ │ aiService (核心) │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ 1. 案例匹配 (caseMatch) │ │ │
│ │ │ 2. URL规则匹配 (urlRule) │ │ │
│ │ │ 3. AI大模型分类 │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ + dictionaryService (分类字典) │ │
│ │ + classificationGuideService │ │
│ └────────────────────────────────────┘ │
└──────────────────────┬───────────────────────────┘
│ OpenAI兼容API
┌────────▼────────┐
│ 大模型服务 │
└─────────────────┘
批量分类采用SSE推送实时进度，逐条串行调用避免AI服务过载。每条分类结果都带 source 字段标记来源（case_match / url_match / ai），方便统计各策略命中率和准确率。
五条可以直接抄的经验
-
AI最好的场景不是追求极致准确，而是"够用即可"的大规模处理——分类容忍少量错误，但人工分类本身就不准确。别在90%→95%上死磕，先解决0%→90%。
-
结构化输出是工程化的前提——三层漏斗（Prompt约束 → 多格式解析 → 路径校验）确保AI输出可解析、可入库。没有这层保障，AI再准也用不起来。
-
历史数据是最好的Prompt工程师——与其绞尽脑汁写Prompt，不如让数据说话：分类描述 + 故障表象 + 典型标题 + 根因关键词，比任何精心设计的指令都有效。
-
混合策略优于纯AI——案例匹配处理确定性场景，URL规则处理半确定性场景，AI处理模糊场景，各取所长。每条结果标记来源，便于持续优化。
-
离线数据加工 > 在线Prompt工程——案例映射表和URL规则表都是离线从历史数据中挖掘的，运行时零AI调用，既准又快。能查表的别调AI，能离线做的别放线上。
