业务场景
客服机器人在生产应用中的实际场景
SaaS 客户询问为什么账单被重复扣费。客服服务先检索当前计费政策和脱敏后的账单状态，再要求模型基于这些来源回答，或返回转人工对象。
模型不能自行退款，也不能编造账户状态。身份未验证、来源冲突或账单工具失败时，会话会连同摘要和来源 ID 一起转给人工。
生产使用场景
用于客服机器人的 LLM API
SaaS 客户询问为什么账单被重复扣费。客服服务先检索当前计费政策和脱敏后的账单状态，再要求模型基于这些来源回答，或返回转人工对象。
生产方案
API、主模型与故障切换配置
| 生产选择 | 推荐配置 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | 从服务端发送 OpenAI 兼容请求 |
| 主模型 | gpt-5.4-mini | gpt-5.4-mini 适合低延迟、高并发、回答与转人工边界清晰的客服轮次。 |
| 备用模型 | gemini-2.5-flash | Gemini 2.5 Flash 作为经过测试的经济型备用。复杂政策冲突或多工具账户问题交给 Terra 或人工。 |
| 升级模型 | gpt-5.6-terra | 只有主路由越过已定义的质量或复杂度边界时才使用 |
| 输出契约 | 经过验证的 JSON | 返回带内部来源 ID 的有依据回复，或结构化转人工原因。 |
应用架构
客服机器人工作流怎样运行
- 分类请求并检查身份要求。
- 检索获准政策和脱敏账户事实。
- 生成带内部来源 ID 的回答，或返回转人工对象。
- 验证每条结论都有来源支持。
- 在任何有后果的账户操作前转人工。
API 请求
通过 LLMFly AI 调用 gpt-5.4-mini
请求应从服务端发送。请将示例内容和占位工具 Schema 替换为应用中的真实数据与工具。
curl https://app.llmfly.ai/v1/chat/completions \
-H "Authorization: Bearer $LLMFLY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.4-mini",
"messages": [
{"role": "system", "content": "Answer only from SOURCES and ACCOUNT_FACTS. If evidence is missing, identity is unverified, or an action requires permission, return ESCALATE with a concise reason."},
{"role": "user", "content": "The customer says this invoice was charged twice. Explain the status or escalate."}
],
"response_format": {"type": "json_object"}
}'模型选择
为什么主模型选择 gpt-5.4-mini
gpt-5.4-mini 适合低延迟、高并发、回答与转人工边界清晰的客服轮次。
Gemini 2.5 Flash 作为经过测试的经济型备用。复杂政策冲突或多工具账户问题交给 Terra 或人工。
验收
客服机器人的验收条件
| 指标 | 通过条件 |
|---|---|
| 有依据回答比例 | 每条政策或产品结论都有获准且最新的来源支持 |
| 正确转人工比例 | 必须转人工的样例会在给出建议或执行账户操作前完成转接 |
| 首次有效回复时间 | 第一次回复能够解决问题，或只询问一个确实缺失的信息 |
| 每次解决会话的成本 | 检索、工具、重试和转接总成本不超过解决预算 |
失败处理
上线前必须处理的失败情况
- 不惜代价追求机器人闭环率
- 允许机器人编造政策
- 发送不必要的敏感数据
- 只衡量单轮回复
输出
返回结果与运行记录
返回带内部来源 ID 的有依据回复，或结构化转人工原因。
每次生产运行都应记录模型 ID、Request ID、Token 用量、重试、验证结果和最终处理状态。
常见问题
怎样让客服回答可信？
让回答基于获准且最新的支持内容，并保留使用的来源标识。
什么时候应该转人工？
政策要求、身份无法验证、置信度不足或工具失败时，应转人工。
如何衡量成本？
按完整解决会话计算，包括检索、工具、重试和转人工。
使用你的真实输入测试这套方案
让主模型和备用模型使用相同请求、工具和验证规则。