业务背景与实际约束
在品牌AI可见度监测中，需要定期向大模型发起查询，评估品牌在AI回答中的呈现情况。如果每次查询都直接调用最新的大模型，Token消耗会迅速膨胀，成本难以控制。以一个中等规模品牌为例，每天监测100个关键词，每个关键词涉及3个问题，每个问题平均输出500 Token，单日Token消耗就超过15万，按GPT-4价格计算，日成本超过30美元，月成本接近1000美元。对于长期监测项目，这样的成本显然不可持续。
问题现象与复现过程
我们最初采用最简单的方案：每次监测任务都直接调用GPT-4，不做任何缓存或优化。运行一周后，发现Token消耗超出预算3倍，且大量查询是重复的——同一关键词在不同时间点的回答高度相似，但每次都在重新生成。
原因分析
成本失控的核心原因有三个：
重复查询：同一关键词在短时间内多次查询，回答内容几乎不变，但每次都在消耗Token。
模型选择不当：所有查询都使用GPT-4，但部分简单问题（如“什么是品牌X”）用更小的模型也能得到足够好的回答。
缺乏监控：没有实时追踪Token消耗，导致超支后才被发现。
候选技术方案对比
针对上述问题，我们评估了以下方案：
方案 优点 缺点
全量缓存 实现简单，减少重复查询 缓存命中率依赖查询模式，无法处理动态变化
语义缓存 可缓存语义相似但表述不同的查询 实现复杂，需要向量化与相似度计算
模型分级 简单问题用小模型，复杂问题用大模型 需要设计分级规则
混合方案 结合缓存与模型分级，灵活控制成本 实现复杂度高
最终我们选择混合方案：语义缓存 + 模型分级 + 实时监控。
核心实现过程
- 语义缓存
使用Embedding模型将查询向量化，存入向量数据库。每次新查询到来时，计算与已有缓存的余弦相似度，若超过阈值（如0.95），则直接返回缓存结果。
import openai
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np
假设已有缓存向量库 cached_embeddings 和对应的回答 cached_answers
query = "品牌A在AI回答中的表现如何？"
query_embedding = openai.Embedding.create(input=query, model="text-embedding-ada-002")['data'][0]['embedding']
计算相似度
similarities = cosine_similarity([query_embedding], cached_embeddings)[0]
max_sim = np.max(similarities)
if max_sim > 0.95:
idx = np.argmax(similarities)
return cached_answers[idx]
else:
# 调用大模型
response = call_llm(query)
# 存入缓存
cached_embeddings.append(query_embedding)
cached_answers.append(response)
return response
- 模型分级
根据问题复杂度选择模型：
简单问题（如事实性查询）：使用GPT-3.5-turbo，成本仅为GPT-4的1/20。
中等问题（如品牌对比）：使用GPT-4-mini。
复杂问题（如情感分析、趋势判断）：使用GPT-4。
分级规则通过关键词匹配和问题长度初步判断，后续可根据实际效果调整。
- 费用监控
使用开源工具（如LangSmith）或自建日志系统，实时记录每次调用的模型、Token数、费用，并设置日预算告警。
测试结果与性能数据
在为期两周的测试中，我们对比了优化前后的成本：
指标 优化前 优化后
日均Token消耗 150,000 45,000
日均成本（美元） 30 4.5
缓存命中率 0% 65%
回答质量（人工评分） 4.5/5 4.3/5
成本降低85%，回答质量仅下降0.2分，在可接受范围内。
踩坑及风险边界
缓存过期问题：品牌信息可能变化，缓存需要设置TTL（如24小时），避免返回过时内容。
模型分级误判：简单问题可能被误判为复杂问题，导致成本增加。建议定期人工复核分级规则。
监控告警阈值：预算告警阈值设置过低会导致频繁误报，设置过高则失去作用。建议根据历史数据动态调整。
可复用经验总结
语义缓存是成本控制的核心，尤其适合查询模式稳定的监测场景。
模型分级需平衡成本与质量，建议从保守策略开始，逐步放宽。
费用监控必须前置，不要等到月底看账单。
缓存和分级规则需要持续优化，没有一劳永逸的方案。
以上实践适用于大多数品牌监测场景，但具体参数需根据实际业务调整。
