ChatGPT API接入与调优：从能用到用得好的工程实践

去年开始接触大语言模型的时候我的想法很简单。调个接口传个提示词拿到结果完事。真正做起来才发现从能用到好用中间隔着好几个坎。这篇文章不讲概念只讲我在接入ChatGPT API过程中遇到的几个实际问题以及对应的解决方案。每个问题都是真实踩过的坑每个方案都已经在生产环境跑通了。问题一流式响应的连接不稳定第一个版本用的是常规的一次性请求。前端发一个请求后端等模型生成完所有内容一次性返回。效果很差。用户等不了那么久尤其生成长文本的时候十几秒的空白页面直接劝退了。换成流式响应之后问题更多。最常见的是连接中断。模型还在生成客户端的连接先断了。断掉的原因五花八门。网关超时、网络波动、用户刷新页面都能导致连接提前关闭。解决方案是做一个代理层。在后端和模型之间加一层缓冲由后端维持长连接客户端只管从后端读数据。这样即使客户端连接断开后端也不会中断模型的生成。用户刷新页面重新连接后还能继续接收之前未完成的内容。具体实现上用Server-Sent Events替代WebSocket。SSE协议更简单浏览器原生支持断线重连机制也是内置的。服务端设置一个合理的超时时间比如三百秒大部分生成任务都能在这个窗口内完成。问题二Token消耗远超预期上线第一周就收到账单。Token消耗比预估高出将近三倍。排查之后发现几个原因。第一个是提示词冗余。每次请求都带着一长串系统提示词几千个Token而且每次都重新计算。优化方案是把系统提示词做缓存同一个会话内复用。不同会话的提示词如果相同也可以复用。这个改动让Token消耗降了大约百分之四十。第二个是历史消息累积。多轮对话场景下每次请求都把全部历史消息带上。对话轮次多了单次请求的Token数呈线性增长。限制是限制历史消息的长度超过阈值的部分做摘要压缩而不是简单截断。摘要保留了关键信息同时大幅减少了Token数。第三个是参数配置不合理。温度参数设置过高模型输出冗余内容多。调整温度从零点九降到零点七输出长度减少了约百分之十五。Top-p参数也做了类似调整从零点九五降到零点八五。问题三输出格式不可控模型返回的内容有时是完整的JSON有时是JSON外面包着文字说明有时JSON解析都会失败。这对下游系统来说是不可接受的。解决方案是函数调用。不用提示词让模型输出JSON而是定义函数签名让模型在生成内容的同时决定调用哪个函数、传什么参数。模型返回的是结构化的函数调用参数格式稳定解析可靠。如果必须用提示词方式也有一个技巧。在提示词里放一个示例输出格式然后用正则表达式从模型的原始输出里提取目标内容。遇到解析失败的情况重试一到两次通常会拿到正确格式。问题四响应延迟波动大同样的请求有时一秒返回有时要等五六秒。这个波动对用户体验的影响比较明显。分析后发现延迟高的时候往往伴随着模型重新加载。服务端资源有限多个模型共享冷启动时加载时间会长一些。高频调用的场景需要保持模型实例常驻避免频繁加载卸载。另一个因素是请求排队。高峰期请求量大服务端处理不过来。可以在客户端实现请求队列管理非紧急请求延迟发送错开高峰。紧急请求优先处理走单独的通道。缓存也能帮上忙。相同的查询重复出现的情况不少把结果缓存起来命中直接返回避免重复调用模型。缓存时间根据业务场景设定实时性要求高的场景缓存时间短一些要求低的场景可以长一些。一些经验关于提示词一个有用的实践是模板化。把提示词拆成固定部分和可变部分固定部分用模板管理可变部分动态填充。这样既保证了一致性又保留了灵活性。所有提示词模板都纳入版本控制变更可追溯。关于错误处理重试策略要配合退避算法。第一次失败等一秒第二次等两秒第三次等四秒。重试次数不宜过多三次最多。还要区分哪些错误值得重试网络超时可以重试参数错误重试也没用。关于监控以下几个指标值得关注。单次请求的Token消耗量超过阈值要预警。响应延迟的分位数P99超过设定值要关注。错误率的变化趋势突然升高要排查。这些数据能帮助你持续优化接入方案。结语从能用到好用中间隔着不少具体的工程问题。这篇文章没有涉及复杂的算法也没有高深的理论都是实际开发中会遇到的情况。如果你也在做类似的接入工作希望这些问题和解决方案能提供一些参考。每个系统的具体情况不同方案需要根据实际场景调整但排查问题的思路是通用的。