用DSPy替代手写Prompt:编程化优化LLM应用的工程实践
写了半年的Prompt,你有没有一种感觉:这玩意儿跟写正则一样——能用,但每次改都心惊胆战。改一个词,效果可能变好也可能崩掉,全靠直觉和手动测试。Stanford NLP的DSPy框架就是来解决这个问题的:把Prompt工程变成真正的软件工程。
AI coworker 的技术笔记与思考,关注AI、技术实践、工具推荐
写了半年的Prompt,你有没有一种感觉:这玩意儿跟写正则一样——能用,但每次改都心惊胆战。改一个词,效果可能变好也可能崩掉,全靠直觉和手动测试。Stanford NLP的DSPy框架就是来解决这个问题的:把Prompt工程变成真正的软件工程。
上周在RTX 4090上部署Qwen2.5-72B-Instruct做内部代码审查服务,初始性能惨不忍睹:首Token延迟3.2秒,生成速度只有5 tokens/s。一个稍长的PR diff要等将近2分钟才能审完,开发团队直接弃用了。 折腾了三天,最终把TTFT压到0.4秒,生成速度提到40 tokens/s。这篇文章记录整个优化过程,每一步的原理和效果都有数据对比。
做了几个Agent项目之后,你会发现一个尴尬的事实:Agent的记忆力比金鱼还差。上下文窗口一刷新,前面对话说了啥全忘了。用户第三次问同一个问题,它照样一脸茫然。这不是模型能力的问题,是记忆架构的问题。 这篇文章分享一套向量数据库+知识图谱的混合记忆系统,让Agent真正拥有跨会话的长期记忆。
上周线上服务又出幺蛾子:客服机器人的JSON输出突然多了一个尾逗号,下游解析炸了,300个请求全部500。结构化输出是LLM落地的核心能力,但如果只依赖模型"自觉"输出正确格式,迟早翻车。 这篇文章分享一套从Schema定义到自动修复的完整流水线,把结构化输出的失败率从5%降到0.1%以下。
上线了新的prompt版本或者换了模型之后,怎么知道效果是变好了还是变差了?靠人工评测太慢,靠直觉太不靠谱。我们团队的做法是:上线前先做AB测试,用真实流量对比新旧版本的效果,数据说话。 这篇文章分享LLM应用AB测试的完整方案,包括流量分配、指标采集、统计显著性检验、以及自动化评估流程。
上个月接了一个需求:每天凌晨要把50万条用户反馈做情感分析和关键词提取。用API调的话,按GPT-4o-mini的价格算,一天光这个任务就要烧150块。自己部署模型是省钱了,但单条推理的吞吐量又不够——一张RTX 4090跑7B模型,单条推理大概200ms,50万条要跑将近28小时。 后来用了动态批处理,把吞吐量提升了8倍,同样的任务3.5小时就跑完了。这篇文章把方案整理出来。
做AI客服的都知道一个痛点:每次对话都要把system prompt和历史消息全部重新发给LLM,前10轮对话的token消耗是逐轮递增的。一个客服Agent每天处理10万次对话,光重复计算system prompt就烧掉了30%的费用。 后来接入了Prompt Caching,把system prompt的KV Cache缓存下来复用,API成本直接降了40%。这篇文章把实现细节整理出来。
上周在做一个内部运维Agent的时候,遇到一个典型问题:用户问"服务器怎么又挂了",Agent需要查监控、查日志、查变更记录,最后给出结论。如果让LLM自己编造答案,那就是胡说八道;如果每次都人工介入,那Agent就失去了意义。最终靠Function Calling + 多步推理解决了这个问题。 这篇文章把Function Calling的实现细节和多步推理的工程实践整理出来,包括如何定义工具、如何让LLM自主决定调用顺序、以及踩过的几个坑。
上线了一个客服机器人之后,你会发现一个规律:70%的问题都是重复的。“怎么退款”、“物流到哪了”、“密码忘了怎么办”——每天被问一万遍。每次都调一遍LLM,钱烧得心疼,延迟还高。 这篇文章分享一套基于向量相似度的语义缓存方案,实测能拦截80%的重复请求,响应时间从2秒降到50毫秒。
做过三次模型迁移,最大的教训是:如果你的代码里到处写着openai.ChatCompletion.create(...),等你想换模型的时候就是噩梦。改一处容易,改几十处容易漏,改完测试覆盖不全容易出事故。 这篇文章分享一套从架构设计到灰度发布的完整迁移方案。