PG官网

  客户来问 AI 客服，我一般会先问一个问题：你说的 AI 客服，是让它答你产品的常见问题，还是想让它像销售一样跟客户聊？

  十次里有七次，对方会愣一下，说 "这个我们还没想过"。

  这个回答我太熟了。找我们做 AI 功能的客户，开口都是 "我们要做个 AI 客服"，问下去，有人想给售后减负，有人想把销售话术统一，还有人纯粹是看同行上线了 AI，自己不能没有。需求完全不一样，方案、预算、工期，差得不是一点半点。

  这篇不打算讲概念，概念网上到处都是。我写点实在的：接大模型 API 这事，钱花在哪、坑在哪、哪些事别一开始就想岔了。

先泼一盆冷水：别急着训模型

  先说结论，可能有点得罪人：绝大多数企业做 AI 功能，不需要训练模型，连微调都未必用得上。

  现在通用大模型 API 开箱就能干的活不少，答客服、写文案、做资料问答、抽结构化信息，都行。真到需要自己动模型的程度，基本绕不开三件事：数据出不了内网、响应要极低延迟、业务知识非常垂直而且 API 怎么调都不准。

  举政企项目说，数据不出域是硬要求，那就只能私有化部署。这跟买 API key 完全是两个量级：GPU、运维、模型版本管理全得自己扛，成本至少翻几倍。反过来，只是给内部员工做个知识库问答，数据不敏感，直接调 API 就是最划算的。

  所以我们谈需求，顺序是反的：先问数据能不能出去、业务允不允许用公有云，再谈选哪个模型。这两个问题没有答案，后面聊的全是白聊。

接 API 最容易翻车的地方

  模型选型其实最省事，各家接口基本都兼容 OpenAI 那套格式，换模型就是改个参数。真正耗时间的是工程。下面四个坑，是我们被坑得比较多的。

  超时和重试，代码必须写对。大模型生成是流式的，慢的时候几十秒都正常，网络层默认超时根本不够用；反过来完全不设超时，服务一挂，请求全堆在那儿，把别的接口也拖死。我们最早就是吃了这个亏，才沉淀出下面这个模板：

import time
import requests

def call_llm(prompt, model="qwen-plus", max_retries=3):
    url = "//api.example.com/v1/chat/completions"
    payload = {
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "temperature": 0.3,  # 客服场景温度调低，别让模型自由发挥
    }
    for attempt in range(max_retries):
        try:
            resp = requests.post(url, json=payload, timeout=(10, 120))
            resp.raise_for_status()
            return resp.json()["choices"][0]["message"]["content"]
        except requests.Timeout:
            # 超时先重试，指数退避，别一窝蜂打上去
            time.sleep(2 ** attempt)
        except requests.HTTPError:
            # 限流和5xx可以重试，4xx是参数问题，重试也没用
            if resp.status_code in (429, 500, 502, 503):
                time.sleep(2 ** attempt)
                continue
            raise
    raise RuntimeError("重试次数用尽，触发告警")

  几个细节容易漏：连接超时和读超时要分开设，连接超时短、读超时长；429 限流和 5xx 网关错误可以重试，4xx 是参数问题，重试一万次也白搭；重试要指数退避，不然并发一上来，你重试的请求比正常请求还多。

  流式输出，体验和账单要一起管。接完 API 被客户吐槽的第一件事，基本是 "回答太慢了"。非流式要等模型全部生成完才返回，长回答等十几秒很正常，用户早划走了。

  上 SSE 流式，字一个一个蹦出来，体验立刻不一样。但有两个代价：后端要扛长连接；流式的 token 没法提前预估，账单容易失控。我们的习惯是给每个会话设最大 token 上限，超了就截断提示。宁肯回答不完整，也不能让一次对话烧掉几百块。

  token 成本，按调用量算，别按单价算。很多客户一看报价，"百万 token 才几块钱？" 觉得便宜得离谱。单价确实便宜，架不住调用量大。

  毛估一下：一次企业知识库问答，用户问题按 200 token 算，检索回来的资料片段加模型回答，一次完整调用大约 2000 token。按目前主流模型百万 token 几块钱的报价，单次成本大概几厘到几分钱。看着不起眼，一个客服系统一天几千次调用，一个月就是几百到几千块。再上流式多轮追问，翻倍也不奇怪。

  这还没算真正的开销大头 —— 开发和调试。我们见过的项目，钱基本都花在联调阶段测各种边界情况。所以报价别只按 token 算，开发工时才是大头。

  幻觉和安全边界，比想象中难处理。模型一本正经胡说八道，这个都听过，但企业场景里后果会被放大：客服给客户报错价格，法务回错条款，这就是事故。

  我们一般做三层：能查证的走检索，把回答圈在知识库范围内，不让模型自由发挥；系统提示词里写死边界，"不知道就说不知道"；关键业务留人工兜底，AI 答不了直接转人工。

  数据安全更麻烦。走公有云 API，敏感信息别拼进 prompt，日志脱敏要做。政企项目数据出不了内网，只能私有化，这是硬边界，省不得。这条省了，后面全是雷。

什么项目接 API，什么项目自己扛

给个粗略的判断标准，别当圣经，例外挺多：

• 需求是通用能力（问答、文案、摘要、翻译），数据不敏感 → 接 API，最快最省钱

• 数据敏感或要求不出域 → 私有化部署，预算按至少五倍起步准备

• 业务知识垂直，API 怎么调都不准 → 先做 RAG（检索增强），还不够再想微调

• 实时性要求毫秒级 → 大模型这条路本身就要重新评估

大部分企业卡在第三档。RAG 做扎实，能解决大部分垂直场景问题，真走到微调那一步的项目，其实不多。

  最后说一句：AI 项目最大的坑，不是模型不够聪明，是需求没想清楚就动工。我们接过的项目里，谈需求多花一天，开发能少踩一周的坑。真见过太多项目，死就死在第一步。

  我们是成都本地的软件开发公司，APP、小程序、公众号、行业软件、物联网、AI 应用都做。如果你正卡在 "要不要上 AI"" 怎么上 AI"，欢迎来聊聊。我们一般会先问一堆问题，把需求聊明白，再谈方案。