两个同事为「提示词改版有没有用」吵了一周 九月份我们改了一版运维 Agent 的系统提示词,主要变化是加了「先确认信息是否充分,再决定调用工具」这一段。改完之后团队内部炸了: 小王说「明显变准了,我测的几个问题都对」;老李说「变差了,现在它老是不干活,一直问我问题」。两人各举了三四个例子,都很有说服
把 AI 服务压到 3000 QPS 之后,GC 曲线完全变了 我们有个文档问答服务,跑在 JDK 21 + G1 上,原来堆 4G,Young 区 1.2G,日均 800 万次调用,GC 表现平平无奇:Young GC 每 8 秒一次,单次 25ms 左右,Full GC 一周见不到一次。 八月份
实习生问我:为什么文档喂得越多,答案越差 七月份团队来了个实习生,负责维护我们的文档问答系统。他有天跑来问我一个问题:「我把 topK 从 5 调到 20,召回率肯定上去了吧?但测试集准确率从 71% 掉到 63%,是不是哪儿写错了?」 我看了下代码,没写错。这不是 bug,这是我们一直没认真对待的
供应商挂了,我们的降级逻辑一行没生效 六月下旬的一个晚上,模型供应商华东区域故障,持续 23 分钟。我们有完整的降级设计(规则引擎兜底、熔断、重试),理论上最多影响一部分请求的响应时间。实际结果是:全线报错,客服系统完全不可用。 事后复盘,原因特别打脸:降级逻辑的入口写在了 catch (Model
财务拿着一张 14.7 万的账单来找我 六月初,财务同事拿着模型账单发消息给我:"你们那个智能运维 Agent,上个月花了 14.7 万?预算不是 5 万吗?" 我一看确实超了快三倍,而且这个 Agent 上线才一个月,日均任务量只有 420 个左右。 我花了两天把账单拆开分析,发现问题比想象的有意
风控要在 200ms 内给出决策,而模型要 150ms 我们电商风控原来是一套 Drools 规则引擎,几百条规则,命中就拦截。去年底开始加模型:用用户最近 5 分钟的行为序列算实时特征,喂给一个轻量模型打分,超过阈值就拦截。 难在时间预算。风控决策必须在用户下单后 200ms 内返回,而模型推理本
产品说"用户上传截图自动填工单" 三月中旬产品提了个需求:用户报障时经常甩一张截图过来,客服要手工把里面的订单号、错误码、时间点一个个敲进工单系统,平均 90 秒一条,希望系统能自动识别和填充。听起来简单,做下来发现"看懂一张图"这件事在工程上的复杂度远超我的预期。 这篇记录我们在 Java 应用里
组里的实习生问我"Java 是不是没前途了" 2025 年春节后回来的第一周,组里新来的实习生私下问我:"现在 AI 不都是 Python 写的吗,我学 Java 是不是选错方向了?" 这话我没法用一句"不会"糊弄过去,因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态
5 万条评测数据,从 80 分钟压到 9 分钟 今年 1 月要做一次大模型效果评测:5 万条标注问题,分别跑三个候选模型,记录每条的输出、耗时和 token 数。总共 15 万次调用。 第一版脚本用 200 线程的固定线程池,跑了 82 分钟还没跑完(因为触发限流重跑了一批)。我花了一天改成虚拟线程
10 月账单 11.7 万,调用量才涨了 40% 11 月 1 号早上收到云厂商账单:10 月大模型调用费用 11.73 万元。9 月是 4.31 万,涨了 172%。但同期我们的业务量只涨了 40%,这中间肯定有浪费。 我花了两天做了一次完整的用量审计,最后把 11 月的账单压到了 5.1 万。过