归档

实习生问我：为什么文档喂得越多，答案越差 七月份团队来了个实习生，负责维护我们的文档问答系统。他有天跑来问我一个问题：「我把 topK 从 5 调到 20，召回率肯定上去了吧？但测试集准确率从 71% 掉到 63%，是不是哪儿写错了？」 我看了下代码，没写错。这不是 bug，这是我们一直没认真对待的

四个服务里塞了四份大模型调用代码 年初我们把 AI 能力往业务里铺的时候，图快，哪个服务需要就直接引一份 spring-ai-openai，配个 key 开干。到六月底盘点，订单服务、客服服务、商品服务、报表服务里各有一套调用代码，四份 application.yml 里躺着四个 API Key。

为什么我们决定在非 LTS 版本上跑生产 JDK 24 今年三月发布，是非 LTS 版本。我们公司原来的规矩是只用 LTS，所以 JDK 24 刚出来时没人提议升级。 改变想法是因为三个具体需求：AI 服务里的虚拟线程 pinning 问题、推理结果回写服务的大堆小对象内存压力、以及函数计算场景的冷

冷启动 4.2 秒，函数计算按毫秒计费 我们有一部分服务跑在函数计算上（内部 FaaS 平台），按实际运行时间计费。其中一个是文档解析入口，Spring Boot 3.5 应用，冷启动实测 4.2 秒——也就是说每次冷启动，用户先付 4.2 秒的钱，其中真正干活的只有不到 1 秒。 去年我们试过 G

供应商挂了，我们的降级逻辑一行没生效 六月下旬的一个晚上，模型供应商华东区域故障，持续 23 分钟。我们有完整的降级设计（规则引擎兜底、熔断、重试），理论上最多影响一部分请求的响应时间。实际结果是：全线报错，客服系统完全不可用。 事后复盘，原因特别打脸：降级逻辑的入口写在了 catch (Model

知识库从 5 万文档涨到 320 万，第一版设计撑不住了 我们公司的知识库最早是给客服用的，5 万篇 FAQ，存储设计得很随意：一张 kb_doc 表，切片直接以 JSON 数组的形式塞在 chunks 字段里，向量存在 Milvus 里，两边用 doc_id 关联。 这个设计在 5 万篇的时候完全

我们有个 WebFlux 服务，没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的，三个接口、两千多行，但组里除了我没人愿意碰它。原因很简单：那套 Mono/Flux 的链式调用，加上 .flatMap() 里嵌套 .zip() 的写法，改起来要花两倍时间，而且出错后堆栈完全看不

一次发版，37 个跑了两小时的任务全没了 五月底的一次例行发版，我们的合同审核 Agent 服务重启。重启完没多久，业务部门来问："我昨天下午提交的那批合同怎么一直显示'审核中'？" 查了一下，那次重启时正在执行的 37 个长任务全部丢失，其中最长的已经跑了 2 小时 17 分钟，完成了 60 多个

财务拿着一张 14.7 万的账单来找我 六月初，财务同事拿着模型账单发消息给我："你们那个智能运维 Agent，上个月花了 14.7 万？预算不是 5 万吗？" 我一看确实超了快三倍，而且这个 Agent 上线才一个月，日均任务量只有 420 个左右。 我花了两天把账单拆开分析，发现问题比想象的有意

三个团队写了三套几乎一样的东西 今年三月做季度复盘时，我们数了一下公司的 AI 建设：客服知识库、智能质检、合同审核，三个项目分属三个团队，各自实现了一遍模型调用封装、限流、审计日志、向量库接入、prompt 管理。代码重复度我粗略估了一下有 40% 以上。 更现实的问题是：三个项目都踩了同样的坑（