团队接了个客服 AI 助手的需求,后端调 GPT-4 生成回复,本地测试好好的,上线第一周用户反馈"等半分钟没反应,以为崩了就走了"。日志一看,平均响应时间十二秒,P99 接近三十秒,用户根本不会等。这种"模型本身慢"的问题不能靠加机器解决,必须从交互设计和工程实现上重新思考。这篇把我们两周内做的几轮优化全部讲清楚:从同步阻塞到流式响应、从单次调用到批量并发、从无缓存到语义缓存、从重型模型到混合调度,最终把感知响应时间从十二秒压到一点二秒,完成度达到客服一线员工愿意主动使用的水平。
故障现场
背景是一个 SaaS 平台的客服 AI 助手,核心功能是根据用户问题和企业知识库,自动生成回复建议供客服参考。客服每天处理上千条工单,如果每条都等十秒生成,体验完全无法接受。技术栈是 FastAPI 后端,前端 Vue,调用 OpenAI 的 GPT-4-turbo 模型。上线第一周的关键指标全部惨不忍睹:平均响应时间 12s、P95 22s、P99 28s、用户主动取消率 35%。客服反馈"还不如自己手写"。
| 时刻 | 事件 |
|---|---|
| 上线第 1 天 | 客服反馈"太慢了" |
| 第 3 天 | 使用率不到 10%,客服基本不用 |
| 第 5 天 | 开始流式响应改造 |
| 第 8 天 | 流式上线,首字时间 800ms |
| 第 10 天 | 批量优化 + 语义缓存上线 |
| 第 14 天 | 感知响应时间降到 1.2s, 使用率 65% |
第一版的设计为什么慢
第一版是最朴素的同步调用,客服点"生成建议"按钮,后端调 OpenAI API,等返回完整回复后再一次性返回给前端。这种设计在小模型(比如 GPT-3.5)上勉强可用,因为响应时间通常在两三秒。但 GPT-4 的生成速度本来就慢,加上回复长度通常一两百字,完整生成需要十秒以上。同步设计在等待期间用户什么都看不到,只能盯着 loading 转圈,体感非常糟糕。
# 第一版:同步阻塞,反面教材
from openai import OpenAI
client = OpenAI()
@app.post("/api/suggest")
async def suggest_reply(req: SuggestRequest):
response = client.chat.completions.create(
model="gpt-4-turbo",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": req.user_message}
],
temperature=0.7
)
return {"suggestion": response.choices[0].message.content}
这段代码的问题不止"慢",还有几个隐性问题。第一,没有超时设置,OpenAI 偶发延迟会直接挂死请求。第二,没有重试逻辑,网络抖动一次就直接报错。第三,system prompt 每次都重复传,浪费 token 也浪费时间。第四,没有日志埋点,出问题时根本不知道是哪一步慢。第一版上线后,这四个问题在生产环境全都暴露了,客服一边吐槽一边把这个功能晾在一边。
优化一:流式响应改造
GPT-4 API 本身就支持 stream 模式,每生成一个 token 就推送一次,首字时间通常在五百到八百毫秒。前端边接收边渲染,用户能在一秒内看到第一个字,感知响应时间从十秒降到一秒,体感完全不同。流式响应是 LLM 应用的标配,几乎所有面向用户的 AI 产品都用这种交互模式。
# 第二版:流式响应,后端用 SSE 推送
from fastapi.responses import StreamingResponse
import json
@app.post("/api/suggest/stream")
async def suggest_stream(req: SuggestRequest):
async def event_generator():
stream = await client.chat.completions.create(
model="gpt-4-turbo",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": req.user_message}
],
stream=True,
temperature=0.7
)
async for chunk in stream:
delta = chunk.choices[0].delta.content
if delta:
yield f"data: {json.dumps({'text': delta})}\n\n"
yield "data: [DONE]\n\n"
return StreamingResponse(event_generator(), media_type="text/event-stream")
前端用 EventSource 或 fetch + ReadableStream 接收 SSE,每收到一个 chunk 立刻追加到回复区域。用户在一秒内看到第一个字,后面的字陆续出现,感觉就像有人在实时打字。这种"打字机效果"是 ChatGPT 等产品的标配,用户已经形成了"AI 就是这样回复"的心理预期,接受度极高。
// 前端接收 SSE
async function streamSuggestion(userMessage) {
const res = await fetch('/api/suggest/stream', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({user_message: userMessage})
});
const reader = res.body.getReader();
const decoder = new TextDecoder();
let buffer = '';
while (true) {
const {done, value} = await reader.read();
if (done) break;
buffer += decoder.decode(value, {stream: true});
const lines = buffer.split('\n\n');
buffer = lines.pop();
for (const line of lines) {
if (line.startsWith('data: ')) {
const payload = line.slice(6);
if (payload === '[DONE]') return;
const {text} = JSON.parse(payload);
appendToReply(text);
}
}
}
}
流式改造上线之后,客服的使用率从百分之十涨到百分之三十,这是第一个明显的拐点。虽然总生成时间没变,但用户感知到的"等待时间"从十秒降到一秒,这就是体验设计的力量。感知速度比真实速度更重要,这条原则不仅适用于 AI 应用,也适用于所有面向用户的系统。
优化二:批量请求并发
客服界面里通常会一次性显示多条工单,以前是用户点哪条才调一次 API,但很多客服反馈"如果能预先生成所有工单的建议就好了"。这个需求本质上是把串行变并行,理论上可以大幅缩短总时间,但要注意 OpenAI 的 rate limit 和成本控制。我们用 asyncio.gather 配合 semaphore 控制并发数,在 rate limit 之内尽可能并发。
import asyncio
from openai import AsyncOpenAI
aclient = AsyncOpenAI()
sem = asyncio.Semaphore(10) # 同时最多 10 个并发请求
async def generate_one(message: str) -> str:
async with sem:
try:
resp = await aclient.chat.completions.create(
model="gpt-4-turbo",
messages=[
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": message}
],
temperature=0.7,
timeout=30.0
)
return resp.choices[0].message.content
except Exception as e:
logger.warning(f"generate failed: {e}")
return ""
@app.post("/api/suggest/batch")
async def suggest_batch(req: BatchRequest):
tasks = [generate_one(m) for m in req.messages]
results = await asyncio.gather(*tasks)
return {"suggestions": results}
批量并发的效果非常明显:十条工单串行需要一百二十秒,并发只要十二秒。但要注意几个细节。第一,并发数不是越大越好,超过 OpenAI 的 RPM(每分钟请求数)限制会被限流,反而变慢。我们的 Tier 是 5000 RPM,但实际并发到三十就开始出现限流响应,稳妥起见控制在十以内。第二,要给每个请求设超时,避免某个慢请求拖垮整批。第三,部分失败要有降级方案,不能因为一个失败就让整批返回空。
优化三:语义缓存
客服场景下,很多问题是高度重复的,比如"怎么退款"、"订单查询入口在哪"。这些问题用同样的回复就足够,没必要每次都调 GPT-4。但传统的 key-value 缓存对自然语言不友好,用户问"退款怎么操作"和"如何申请退款",字面不一样但语义相同,key 完全对不上。解决方案是语义缓存:用 embedding 计算问题的向量,在向量库里查找语义相似的历史问题,命中就直接复用历史回复。
from openai import OpenAI
import numpy as np
client = OpenAI()
# 用 Redis Vector 或 Milvus 或 pgvector 存储 embedding
# 这里简化为内存字典示意
cache = [] # [(embedding, question, answer), ...]
THRESHOLD = 0.92 # 余弦相似度阈值
def get_embedding(text: str) -> np.ndarray:
resp = client.embeddings.create(
model="text-embedding-3-small",
input=text
)
return np.array(resp.data[0].embedding)
def cosine_sim(a, b):
return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))
def semantic_cache_lookup(question: str):
emb = get_embedding(question)
best_sim, best_answer = 0, None
for cached_emb, _, ans in cache:
sim = cosine_sim(emb, cached_emb)
if sim > best_sim:
best_sim, best_answer = sim, ans
if best_sim >= THRESHOLD:
return best_answer, best_sim
return None, 0
def semantic_cache_store(question: str, answer: str):
emb = get_embedding(question)
cache.append((emb, question, answer))
语义缓存的关键是阈值的选择。阈值太低会误命中,把"退款"的回复返给"投诉"的问题,造成事故。阈值太高会很少命中,缓存效果差。我们的实践是从 0.95 开始,逐步降到 0.92,同时人工抽检命中样本,确保没有误命中。这种"先严后松"的调参方式比拍脑袋定阈值靠谱。最终命中率稳定在百分之四十左右,对应着百分之四十的请求直接走缓存,响应时间从秒级降到毫秒级。
优化四:混合模型调度
GPT-4 虽然好,但贵且慢,对于简单问题用 GPT-3.5 完全够用。我们引入了一个简单的"问题难度分类器",根据问题特征决定走 GPT-3.5 还是 GPT-4。简单问题(比如"几点上班")走 GPT-3.5,平均响应一两秒;复杂问题(比如多轮对话、需要推理的)走 GPT-4。这种混合调度把整体平均响应时间又降低了一半,成本也降了大约百分之六十。
问题难度分类可以用很多方法。最简单的是关键词匹配,带"如何"、"为什么"、"分析"等词的视为复杂。更精细的方法是训练一个轻量分类器,用历史数据标注难度。最现代的方法是用一个小模型(比如 GPT-3.5)做难度评估,但这又增加了一次调用。我们综合考虑后选了关键词加规则的方案,简单可控,准确率有百分之八十就够用,误判走 GPT-4 也只是稍贵一点,没什么后果。
四种优化对比
| 方案 | 响应时间改善 | 成本影响 | 实施难度 |
|---|---|---|---|
| 流式响应 | 感知速度提升 10 倍 | 无 | 低 |
| 批量并发 | 批量场景 10 倍 | 无 | 低 |
| 语义缓存 | 40% 请求秒级 → 毫秒级 | 降 40% | 中 |
| 混合模型 | 简单问题 5 倍 | 降 60% | 中 |
容易踩的几个坑
第一个坑是流式响应里的错误处理。流式开始后如果中途出错,前端可能已经显示了一半的内容,直接报错体验很差。我们的做法是流式过程中如果失败,先把已生成的内容标记为"未完成",前端弹一个"重试"按钮,让用户决定是否重新生成。这种"优雅降级"比直接报错友好得多。
第二个坑是语义缓存的更新机制。知识库会随时更新,缓存里的旧回复可能已经过期。我们的解决方案是给每条缓存加一个 ttl,默认七天过期。重要业务变更时(比如政策修改),手动清除相关缓存。还有一个更高级的做法是给每个缓存条目关联知识库版本号,知识库更新时自动失效相关缓存,但实现复杂度较高,小项目不必上。
第三个坑是并发请求的 rate limit 控制。OpenAI 的 rate limit 是按账号维度的,如果几个服务共用一个账号,合起来超限就麻烦了。我们的实践是给每个服务分配独立的 API key,从计费层面就隔离开,出问题时只影响一个服务。如果非要共用,需要在客户端做全局的 rate limiter,推荐用 Redis 实现的 token bucket。
第四个坑是token 计数和成本控制。GPT-4 的 token 单价是 GPT-3.5 的二十倍,稍不留神成本就爆炸。我们在每次调用前用 tiktoken 估算 token 数,超过阈值的请求要么截断要么走 GPT-3.5。每天定时跑一次成本统计,异常情况立刻告警。月初做预算评审,根据实际使用调整下个月的额度。这种成本意识对 AI 应用至关重要,没有的话第一个月账单可能让老板震惊。
提示词工程的几条经验
除了工程优化,提示词本身也是性能优化的重要一环。同样的问题,不同的提示词可能差几倍的 token 数和生成时间。我们总结了几条经验。第一条是system prompt 尽量简短,只保留必要的角色设定和约束,详细的业务规则放到知识库里按需检索。我们的 system prompt 从最初的 1500 token 压到 400 token,响应时间快了三秒。
第二条是明确指定输出格式。如果你需要 JSON 输出,在提示里说清楚"请只返回 JSON,不要任何解释",并给一个示例。模糊的提示会让 GPT 啰嗦地解释,白白浪费 token。第三条是用 stop 参数控制结束。如果你知道输出应该在某个 token 后结束,设 stop 参数可以让 API 提前返回,节省时间和成本。第四条是少用 few-shot,多用 RAG。few-shot 把示例塞在提示里,每次都要传,浪费 token;RAG 把示例放到向量库里按相关性检索,只传必要的,效率高得多。
# 优化前的 system prompt(过长)
SYSTEM_PROMPT_OLD = """
你是一个客服助手, 负责帮助客服人员回答用户问题...
(此处省略 1500 token 的详细规则)
"""
# 优化后的 system prompt(精简)
SYSTEM_PROMPT_NEW = """你是客服助手, 用简洁友好的中文回复。
- 不确定的信息回答"请稍候,我帮您转人工"
- 涉及金额或账户的, 必须让用户确认手机号后四位
- 输出控制在 100 字以内"""
# 调用时动态注入相关知识(RAG)
def build_messages(user_msg: str) -> list:
related_docs = vector_search(user_msg, top_k=3)
context = "\n".join(d.content for d in related_docs)
return [
{"role": "system", "content": SYSTEM_PROMPT_NEW},
{"role": "system", "content": f"参考资料:\n{context}"},
{"role": "user", "content": user_msg}
]
监控和可观测性
AI 应用的可观测性比传统应用更复杂,光看响应时间和错误率远远不够。我们在每次调用都记录以下指标:请求 token 数、响应 token 数、首字时间、总生成时间、模型版本、是否命中缓存、用户是否采纳建议。这些数据汇总到 Prometheus,在 Grafana 看板上实时观察。任何指标异常都有告警,比如平均 token 数突然翻倍可能是有用户在故意刷,需要排查。
from prometheus_client import Histogram, Counter
llm_latency = Histogram('llm_latency_seconds', 'LLM generation latency',
['model', 'cache_hit'])
llm_tokens = Histogram('llm_tokens', 'LLM token usage',
['model', 'direction'])
llm_errors = Counter('llm_errors_total', 'LLM API errors',
['model', 'error_type'])
async def instrumented_call(model, messages):
import time
start = time.monotonic()
try:
resp = await aclient.chat.completions.create(
model=model, messages=messages, stream=True
)
first_token_time = None
full_text = []
async for chunk in resp:
if first_token_time is None:
first_token_time = time.monotonic() - start
if chunk.choices[0].delta.content:
full_text.append(chunk.choices[0].delta.content)
total_time = time.monotonic() - start
llm_latency.labels(model=model, cache_hit='false').observe(total_time)
return ''.join(full_text), first_token_time
except Exception as e:
llm_errors.labels(model=model, error_type=type(e).__name__).inc()
raise
除了量化指标,我们还做了一套"采纳率分析"。客服可以选择"采纳"、"修改后采纳"或"放弃"三种操作,这些数据反映了建议的真实质量。如果采纳率持续低于百分之五十,说明模型或提示词有问题,需要回头优化。这种从产品指标反推技术决策的闭环,是 AI 应用持续改进的关键。
降级和兜底策略
AI 服务必须有降级,因为 OpenAI 不是百分百可用,网络也不是百分百稳定。我们设计了三级降级。第一级是模型降级,GPT-4 超时切到 GPT-3.5,虽然质量稍差但能用。第二级是规则降级,GPT-3.5 也失败时,返回基于关键词匹配的预设回复,虽然死板但不会让客服干等。第三级是静默降级,所有 AI 服务都不可用时,前端隐藏"AI 建议"按钮,客服回到完全人工模式,系统看起来就像没有这个功能,不影响主流程。
async def get_suggestion_with_fallback(user_msg: str) -> str:
# 第一级: GPT-4
try:
return await asyncio.wait_for(
call_gpt4(user_msg), timeout=5.0
)
except (asyncio.TimeoutError, Exception) as e:
logger.warning(f"gpt4 failed: {e}, fallback to gpt3.5")
# 第二级: GPT-3.5
try:
return await asyncio.wait_for(
call_gpt35(user_msg), timeout=3.0
)
except (asyncio.TimeoutError, Exception) as e:
logger.warning(f"gpt35 failed: {e}, fallback to rules")
# 第三级: 规则引擎
return rule_based_reply(user_msg) or ""
降级的关键是失败要快。每一级都设短超时,失败立刻切下一级,不要在某一级死等。同时降级行为要有日志和告警,运维能及时感知到 AI 服务在退化,主动排查上游问题。我们的告警规则是"五分钟内降级次数超过一百"就打电话,因为这往往意味着 OpenAI 那边有问题需要等待恢复或切换备用服务商。
关于多模型策略的思考
除了 OpenAI,业界还有 Anthropic Claude、Google Gemini、国产的通义千问、文心一言、智谱 GLM 等等。这些模型各有优势,Claude 在长文本和代码生成上表现优异,Gemini 在多模态上独占鳌头,国产模型在中文场景下经常超越 GPT-4。生产环境如果只依赖一家供应商,风险集中度太高。我们最终的架构是主用 GPT-4,备用 Claude,中文场景部分流量用国产模型,既享受了不同模型的优势,又分散了风险。
多模型架构的关键是统一抽象。我们封装了一个 LLMProvider 接口,每个供应商一个实现,业务代码只跟接口打交道,切换供应商只需要改配置。这种设计在 OpenAI 出过一次大规模故障时救了我们,把流量切到 Claude 只用了五分钟,业务感知接近零。如果当时还紧紧绑死 OpenAI,损失会非常大。
from abc import ABC, abstractmethod
class LLMProvider(ABC):
@abstractmethod
async def chat_stream(self, messages: list, model: str):
pass
class OpenAIProvider(LLMProvider):
async def chat_stream(self, messages, model):
async for chunk in self.client.chat.completions.create(
model=model, messages=messages, stream=True
):
yield chunk.choices[0].delta.content or ""
class ClaudeProvider(LLMProvider):
async def chat_stream(self, messages, model):
async with self.client.messages.stream(
model=model, messages=messages, max_tokens=1024
) as stream:
async for text in stream.text_stream:
yield text
# 业务代码只用接口
provider = get_current_provider() # 根据配置选择
async for text in provider.chat_stream(messages, "gpt-4-turbo"):
yield text
真实收益数据
| 指标 | 优化前 | 优化后 | 改善 |
|---|---|---|---|
| 感知响应时间(P50) | 12s | 1.2s | 10 倍 |
| P99 响应时间 | 28s | 8s | 3.5 倍 |
| 客服使用率 | 10% | 65% | 6.5 倍 |
| 采纳率 | 25% | 58% | 2.3 倍 |
| 每月 API 成本 | 3.2 万 | 1.1 万 | 降 66% |
| 客服平均工单处理时长 | 4 分钟 | 2.5 分钟 | 降 37% |
这些数据是上线两个月后的统计,真实反映了优化的价值。值得注意的是,采纳率的提升不只是因为响应快了,还因为模型质量的间接改善——更精简的提示词、更针对性的 RAG 检索、更合理的模型选择,这些都让生成的内容更贴合客服场景。性能优化和质量优化往往是连带发生的,值得一起做。
团队立的几条规矩
- 面向用户的 LLM 调用必须流式,不允许同步阻塞设计。
- 所有 API 调用必须设超时,GPT-4 不超过 30 秒,GPT-3.5 不超过 10 秒。
- 必须有三级降级:模型降级 → 规则降级 → 静默降级。
- 所有调用必须埋点 latency / tokens / cost,接入 Grafana 实时观察。
- 语义缓存阈值必须经过人工评审,不允许直接拍板上线。
- 每月做一次成本审计,异常增长必须有书面说明。
- 禁止硬编码 API key 到代码,必须走 secrets manager。
- 采纳率作为产品健康度核心指标,低于 50% 必须排查原因。
未来一年的演进规划
这次优化告一段落之后,我们规划了后续的演进方向。第一个方向是本地化部署小模型。客服场景的很多简单问题完全可以用 7B 的开源模型处理,响应快、成本低、数据不出内网。我们在测试 Qwen2.5-7B 和 Llama-3-8B,目前看简单意图识别和回复生成的效果已经接近 GPT-3.5,差距在持续缩小。一旦本地化能覆盖百分之七十的请求,云端 API 成本可以再降一半。
第二个方向是多 Agent 协作。把客服场景拆分成意图识别、知识检索、回复生成、敏感词过滤等多个 Agent,每个 Agent 用最合适的模型,通过 orchestration 协调。这种架构更符合复杂业务的真实需求,也更容易做精细化优化。我们在用 LangGraph 做实验,初步效果不错,准备小范围试点。
第三个方向是自动化的 A/B 测试。提示词调整、模型切换、参数变化,每一次变更都需要 A/B 测试验证,人工对比效率太低。我们正在搭一套自动化 A/B 平台,把变更通过流量灰度自动跑实验,几小时内就能得出结论。这种基础设施投入虽然不直接产生业务价值,但能让团队的迭代效率提升一个数量级,长期价值巨大。
给同行的几条建议
第一条建议是不要直接把 LLM 同步接到业务里。LLM 调用是一个高延迟、高变数的远程操作,必须用流式、必须有降级、必须有超时,这些都是工程基本功,不能省。同步阻塞的设计在 demo 阶段可以,但生产环境必须用流式。
第二条建议是从体验设计开始。AI 应用的性能优化,首先是体验问题而不是技术问题。流式响应不是技术上更快,而是让用户感知到"系统在工作"。理解了这一点,才能做出真正好用的 AI 产品。技术指标和用户感知不是同一回事,千万别把两者搞混。
第三条建议是成本必须从第一天就管控。LLM API 的成本随用量线性增长,稍不留神就会让财务找上门。从立项第一天就要设预算、做监控、定告警,养成成本意识。我们见过太多 AI 项目因为成本失控而被叫停,非常可惜。
第四条建议是把语义缓存纳入标配。任何重复性较高的 AI 场景都应该上语义缓存,这是性价比最高的优化。客服、问答、推荐这些场景命中率都能做到百分之三十以上,投入产出比极高。技术栈推荐 pgvector(已有 PG 的话)或 Qdrant(独立部署),两者都成熟易用。
事故复盘的几点反思
第一点反思是不要低估"感知速度"的力量。我们最初以为问题是 GPT-4 太慢,准备换 GPT-3.5 牺牲质量换速度。后来发现真正的问题是同步阻塞,改成流式之后质量保持 GPT-4 而感知速度大幅提升,这才是双赢。如果一开始就只盯着技术指标,可能就错过了体验优化的方向。
第二点反思是AI 应用的工程化能力比模型本身更重要。同样调 GPT-4 的两个产品,工程做得好的能让用户觉得"AI 真聪明",工程做得差的让用户觉得"AI 真笨"。模型只是基础,工程化才是差异化。这一点对所有想做 AI 应用的团队都很重要,不要把所有希望寄托在大模型本身的能力提升上,自己的工程能力同样关键。
第三点反思是客户反馈是最直接的产品信号。我们之前看 P50/P95 等技术指标都还行,以为没问题,实际客服一线反馈"根本不能用"。技术指标和用户感受之间总有 gap,必须有渠道直接听到一线声音。我们后来定了一个规矩:每月跟客服一线开一次需求会,听他们抱怨什么、希望什么,这些信息比任何监控数据都珍贵。
跟其他 AI 应用场景的对比
客服 AI 助手只是 LLM 应用的一个场景,其他场景的优化策略略有不同。代码助手(类似 Copilot)对首字时间要求极致,几百毫秒之内必须出第一个字符,否则破坏开发心流。这种场景需要更激进的优化,比如本地小模型预测前几 token,云端大模型异步补全。文档生成(类似 Notion AI)对总时间不敏感但对质量极敏感,允许等几十秒但内容必须精炼准确,需要更多 prompt engineering 和后处理。
RAG 问答(类似企业知识库助手)的瓶颈不在 LLM 而在检索质量,优化重点是 embedding 模型、向量库索引、reranker 等检索环节,LLM 反而是最简单的一步。多模态分析(图片/视频理解)受限于模型本身的处理能力,工程优化空间相对小,主要靠选择合适的模型和合理拆解任务。理解这些场景的差异,才能选对优化方向,不要拿客服的经验直接套用到代码助手上。
团队推广这些规矩时的真实阻力
事故复盘开完之后,我们想把那八条规矩推广到公司所有 AI 项目,实际执行时遇到了一些阻力。第一个阻力是业务团队对"流式响应必须做"的不理解,他们觉得 demo 阶段同步够用、上线再改就行。我们后来定了 code review 硬卡点,任何同步 LLM 调用代码直接打回。第二个阻力是语义缓存的人工评审耗时,产品经理觉得太重,希望能跳过。我们的折中是首批样本必须人工评审,后续可以靠采纳率指标自动监控,异常再人工介入。这种"先重后轻"的流程兼顾了安全和效率,业务团队也能接受。第三个阻力是成本审计的执行,各业务团队都不愿意"被审"。我们最后把审计搬到 BI 报表里自动跑,异常自动弹通知,从"审你"变成"通知你",阻力小了很多。
总结
LLM 应用的性能优化,核心思路是感知速度优先、批量并发、缓存复用、混合调度。流式响应是基础,把感知时间从十秒降到一秒;批量并发解决多请求场景;语义缓存让重复问题秒级响应;混合模型让简单问题用便宜模型,把成本和速度同时优化。这套组合拳让我们的客服 AI 从"基本没人用"做到了"客服愿意主动用",数据指标全面改善,成本反而降了三分之二。
这次优化让我深刻意识到,AI 应用的成败不在模型本身,而在工程化能力。OpenAI 的 API 谁都能调,把它做成用户喜欢的产品,需要大量的细节打磨。流式、缓存、降级、监控、成本控制,每一项都是工程功底的体现。希望这篇能给正在做 AI 应用的同行一些参考,如果你的项目还在为"模型慢"发愁,先别急着换模型,看看上面这几个工程优化点是不是都做到位了。绝大多数情况下,工程化的空间比模型本身大得多。
最后想说的是,AI 应用是一个仍在快速演进的领域,今天的最佳实践可能明天就过时了。保持对新技术、新模型、新工具的关注,持续投入学习,是这个领域工程师的必修课。但也不要被技术潮流绑架,任何选型都要基于具体场景和真实数据,不要为了用新技术而用新技术。技术服务于业务,这条原则永远不变。
—— 别看了 · 2026