为什么我放弃了传统方案，改用 Google Gemini

一个真实的痛点

三个月前，我的团队接了一个项目：给公司的客服系统加一个工单自动分类和摘要功能。听起来不难，对吧？

按老路子，我们先用正则和关键词规则做了第一版。结果上线一周，准确率惨不忍睹——用户写“退钱”它归类成“咨询”，写“我想取消但我还想继续用”直接把规则引擎搞懵了。维护规则表的成本越来越高，每来一个新的表达方式就得加几条规则，两周后规则表膨胀到了 400 多行，谁都不敢删。

然后我们尝试自训一个传统 NLP 模型。标注数据、调参、部署 GPU 推理服务，折腾了三周，准确率也就 78%，而且遇到没见过的表述照样翻车。

就是在那个时候，我决定认真试一下 Google Gemini。下面是我从零开始迁移的完整过程，包括踩过的坑。

第一步：把最小验证跑通

我不想一开始就动架构，先写了个 20 行的脚本验证效果。用的是 google-generativeai 这个 Python SDK：

pip install google-generativeai

import google.generativeai as genai

genai.configure(api_key="你的API_KEY")
model = genai.GenerativeModel("gemini-1.5-flash")

prompt = """
你是客服工单分类器。把下面的工单分到以下类别之一：
退款、账单、技术故障、账户问题、其他。
同时用一句话总结工单核心诉求。

工单内容：{ticket}
输出 JSON 格式：{{"category": "...", "summary": "..."}}
"""

response = model.generate_content(prompt.format(ticket=工单文本))
print(response.text)

第一版跑出来，我在 100 条历史工单上人工核对，准确率直接到了 94%。Flash 模型的响应时间大概 1-2 秒，对客服场景完全够用。

那一刻我意识到：不是我们的规则写不好，是这个问题本来就不该用规则解决。

第二步：踩坑记录

事情当然没那么顺利。迁移过程中我踩了几个坑，写出来避免你们重蹈覆辙。

坑 1：输出不是纯 JSON。 模型偶尔会输出类似 json ... 的包裹，或者前面加一句“好的，以下是分类结果”。解析直接报错。解决方案是用 Gemini 的结构化输出，明确告诉它 response_mime_type="application/json"：

response = model.generate_content(
    prompt,
    generation_config=genai.GenerationConfig(
        response_mime_type="application/json"
    )
)

加上这个之后，解析失败率从大约 15% 降到 0。

坑 2：长工单触发 token 上限。 有用户把整个聊天记录复制进来，几万字符。这正好是 Gemini 长上下文的优势——1.5 系列处理超长输入基本无压力，这在之前用传统方案时是直接截断丢弃的。不过我还是加了保险：超过 5 万字符的工单先截取关键部分（用户消息 + 最近交互），避免无关内容干扰分类。

坑 3：API 限流。 上线后高峰期偶发 429 错误。我没写重试逻辑就直接上了，被狠狠教育了一顿。现在用的是带指数退避的重试：

import time

def call_with_retry(fn, max_retries=5):
    for i in range(max_retries):
        try:
            return fn()
        except Exception as e:
            if "429" in str(e) and i < max_retries - 1:
                time.sleep(2 ** i)
                continue
            raise

第三步：用长上下文解决了一个意外问题

迁移两周后，我发现一个额外收益。传统方案里，工单分类只看当前这条消息，缺少上下文。而 Gemini 可以直接把用户的完整历史工单（可能十几条，几千字）一股脑塞进 prompt，让它结合历史判断。

比如有用户连发三条工单，前两条是“充值失败”，第三条只写了“又不行了”。没有历史的话这条只能归“其他”，有了历史就能准确归到“技术故障”。加上历史上下文后，准确率又提升了约 3 个百分点。

这也是我彻底放弃传统方案的关键原因之一——传统 pipeline 里要做多轮对话理解，需要自己设计状态管理，而在这里就是多给一点上下文而已。

第四步：成本和模型选型

这里是我的实际选型经验：

• gemini-1.5-flash：客服分类、摘要这种轻任务，速度快、便宜，是我们目前的主力。
• gemini-1.5-pro：留给疑难工单。当 Flash 的置信度低（我在 prompt 里让它输出置信度字段），或者用户明确表达强烈不满时，升级到 Pro 处理。

这个“两层模型”策略让成本只有全用 Pro 的四分之一左右，效果几乎没损失。

另外别忘了免费额度。Gemini API 的免费层对我们这种内部测试完全够用，我是在免费层验证了整整两周才决定付费接入的。

目前的效果和不足

上线三个月的真实数据：

• 分类准确率：94% → 97%（加了历史上下文和结构化输出之后）
• 摘要采纳率（客服人员觉得摘要写得好）：约 89%
• 单条处理成本：对比之前自训模型分摊的 GPU 成本，低了一个量级

但也要说清楚局限：

1. 网络依赖。API 挂了或网络抖动，整个分类流程就停了。我们现在的兜底是：API 失败重试 5 次后，降级到老的规则引擎——所以那 400 行规则表我留着没删，算是它最后的用武之地。
2. 偶发的幻觉。摘要功能偶尔会“脑补”用户没说过的诉求。我们要求客服确认摘要后再归档，不敢全自动。
3. 数据合规。工单里有用户手机号、订单信息，发给第三方 API 前需要做脱敏处理。我们写了一层预处理，把敏感字段替换成占位符再发送。这一步千万别省。

总结建议

如果你还在用规则引擎或传统 NLP pipeline 硬扛文本理解类任务，我的建议是：

1. 先花半天时间用脚本做最小验证，别急着动架构；
2. 一开始就上结构化输出，省去后期清洗的麻烦；
3. 永远保留一个降级方案，API 不是百分百可靠；
4. 敏感数据脱敏是上线前必做项，不是可选项。

对我个人而言，这次迁移最大的改变不是省了钱、提了准确率，而是我不再试图“教机器规则”了——把描述性工作交给大模型，把工程精力放在真正的业务逻辑上。这笔账，怎么算都划算。