如何在不破坏成本或延迟的情况下将 LLM 集成到你的产品中
构建一个 AI Demo 非常简单。你只需获取一个 API 密钥，编写一段提示词（prompt），然后展示给你的团队即可。
然后你将其发布。流量随之而来。你的成本开始爆炸式增长，延迟也随之飙升。
从 Demo 转向真正的产品需要进行成本和延迟工程。以下是具体做法。
控制你的输出
大多数 API 按 token 计费。输出 token 的成本比输入 token 更高。
人们花时间精简提示词，却任由模型喋喋不休。这是一个错误。
为了节省金钱和时间，请约束输出：
- 要求返回 JSON。
- 要求仅返回一句话。
- 设置
max_tokens限制。 - 告诉模型要简洁。
短回答更快，也更便宜。
停止进行不必要的调用
最好的省钱方法就是根本不调用模型。
- 使用缓存：为常见问题存储响应。如果问题相似但不完全相同，语义缓存（semantic cache）会很有帮助。
- 使用路由：不要在简单任务上使用你最强大的模型。使用小型、廉价的模型进行分类。将昂贵的模型留给复杂的任务。
提升用户体验
如果响应需要时间，请让它“感觉”很快。
- 流式传输 token：在生成时实时显示单词。这可以减少感知的等待时间。
- 显示进度：如果任务包含多个步骤，请告知用户正在发生什么。使用类似“正在搜索文档...”的文本，而不是一个静默的加载圈（spinner）。
管理“尾部”延迟
某些请求总是会很慢。不要让它们搞垮你的产品。
- 设置超时：决定如果请求挂起该怎么办。使用备选方案（fallback）或更小的模型。
- 使用重试机制：针对小错误添加重试，但要设置上限。
- 使用熔断器（circuit breakers）：如果供应商宕机，立即停止发送请求，以避免长时间等待。
追踪你的数据
你无法修复你无法衡量的问题。为每个请求记录这三个数字：
- 输入 token。
- 输出 token。
- 总延迟。
关注每个成功用户结果的成本。一个能正常工作的特性，比一个便宜但失败的特性要好得多。
不要再把 LLM 当作魔法。把它当作一个必须管理的、缓慢且昂贵的依赖项。
Optional learning community: https://t.me/GyaanSetuAi