早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
组里的实习生问我"Java 是不是没前途了" 2025 年春节后回来的第一周，组里新来的实习生私下问我："现在 AI 不都是 Python 写的吗，我学 Java 是不是选错方向了？" 这话我没法用一句"不会"糊弄过去，因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态
三十多个工具方法散在各处 去年底我们把内部运维助手接上了大模型，能查订单、查库存、重启任务。当时图快，工具方法用 Spring AI 的 @Tool 直接写在各个业务服务里，谁需要谁加。到 2025 年 2 月一数，散在 6 个服务里总共 37 个工具方法，问题就来了：网关那边的对话服务要用库存工具
8.6 万份文档，Tika 抽出来的表格全是乱码 去年底接了个企业知识库的项目，要把公司十年积累的技术文档、产品手册、标书、合同模板全部灌进 RAG。总量 8.6 万份，PDF 占 45%，Word 30%，Excel 15%，剩下是 PPT 和 HTML。 第一版我图省事，直接用 Apache T
单次 Function Calling 撑不住，我上了 ReAct 去年 11 月我们给内部运维做了个助手，能查监控、查日志、查工单、执行标准操作。第一版用的是大模型的 Function Calling：把工具列表丢给模型，模型返回一个函数调用，我们执行完把结果拼进上下文，再问一次，直到它不再调工具
5 万条评测数据，从 80 分钟压到 9 分钟 今年 1 月要做一次大模型效果评测：5 万条标注问题，分别跑三个候选模型，记录每条的输出、耗时和 token 数。总共 15 万次调用。 第一版脚本用 200 线程的固定线程池，跑了 82 分钟还没跑完（因为触发限流重跑了一批）。我花了一天改成虚拟线程
语义缓存一直跑在 Redis Stack 上，Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上（就是那个带 RediSearch 模块的发行版）。这套方案最大的别扭之处是：它跟官方主线版本是两套东西，运维要单独装，升级要跟 Stack 的节奏
用 WebFlux 四年，年底我把它重写了 2021 年我们做实时风控服务，选了 Spring WebFlux。当时的理由很充分：QPS 目标 2 万、需要背压、团队想试试响应式。四年过去了，这个服务一直在线上跑，但我对它的评价从"技术先进"变成了"维护负担"。 今年 10 月我用 JDK 21 虚
JNI 那套胶水代码，我写了三年，写烦了 我们有个自研的向量检索库 libhnswwrap.so，C++ 写的，Java 侧通过 JNI 调用。三年来每次 C++ 侧改接口，我都要同步改三处：C 的胶水层、Java 的 native 方法声明、还有两边的结构体序列化代码。 上次升级的改动是增加了一个
27 万个虚拟线程，把 4 核 8G 的容器拖死了 12 月 6 号凌晨，告警电话把我叫醒。AI 批处理服务的响应时间从正常的 300 毫秒涨到 30 秒以上，CPU 100%，但业务吞吐几乎归零。 # 监控截图里的数据 jvm_threads_live
