从今天起开一个固定栏目：每天读一本书，把里面的东西压缩到 20 分钟内读完，再写点自己的看法。方向是金融、AI、历史这三块——前两块是饭碗，最后一块是让人不至于把今年发生的事都看成世界末日。 这个栏目不打算做成读书笔记的搬运。我做了八年 Java 和 AI，又自己跑过出海盘子、也清零过两次，读这些书
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测，目标 800 QPS，结果压到 400 就开始大量超时。看 Grafana 面板，网关 CPU 才 40%，数据库连接池很闲，但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图，TIME_
产品说"用户上传截图自动填工单" 三月中旬产品提了个需求：用户报障时经常甩一张截图过来，客服要手工把里面的订单号、错误码、时间点一个个敲进工单系统，平均 90 秒一条，希望系统能自动识别和填充。听起来简单，做下来发现"看懂一张图"这件事在工程上的复杂度远超我的预期。 这篇记录我们在 Java 应用里
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 分钟还没跑完（因为触发限流重跑了一批）。我花了一天改成虚拟线程
用 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
安全部甩来 213 个漏洞，限期两周整改 11 月初，安全部门用他们的商用扫描器对我们的 14 个 Java 服务扫了一遍，发来一份 Excel：213 个"高危及以上"漏洞，要求两周内清零。 我们团队三个人，14 个服务，平均每人每周要处理 35 个漏洞。第一反应是不可能完成。但真正让我头疼的不是
周五下午 16:42，37 万行订单没了 11 月 15 号周五，下午四点四十二，我正准备收拾东西下班，监控群里炸了。 [16:42:07] 告警：order_center 慢查询数 5 分钟内 0 → 143 [16:42:31] 告警：order_center QPS 从 3800 跌到 41
搜索改版做了三个月，用户还在搜不到东西 公司的技术文档站搜索，原来是纯 Elasticsearch BM25。今年 8 月我接手改版，第一版直接换成了向量检索，想着"语义搜索肯定更强"。上线一个月，搜索结果的点击率从 68% 掉到 51%，用户投诉反而变多了。 我把 200 条低点击率的 query
数据量涨到 2300 万，向量检索 P99 从 60ms 崩到 1.8 秒 我们的商品语义搜索，7 月份上线时是 420 万条向量，P99 稳定在 60 毫秒。到 10 月底商品库扩到 2300 万条，接口 P99 涨到 1820 毫秒，同时 Milvus 集群的内存水位长期在 91%，隔三差五触发
10 月账单 11.7 万，调用量才涨了 40% 11 月 1 号早上收到云厂商账单：10 月大模型调用费用 11.73 万元。9 月是 4.31 万，涨了 172%。但同期我们的业务量只涨了 40%，这中间肯定有浪费。 我花了两天做了一次完整的用量审计，最后把 11 月的账单压到了 5.1 万。过
没人动过代码，准确率从 87% 掉到 71% 10 月中旬的一个周二，运营反馈客服机器人的回答质量明显变差。我看了一圈发布记录，前后三天没有任何代码上线。但监控上的数字是实打实的： chat_answer_quality_score{date="2024-10-14"} 0.871 chat_an
三个人都点了 Approve，上线还是出了事故 9 月底的一次线上故障，起因是个不到 200 行的 PR：修改优惠券核销逻辑。三个人 review 过，两个 LGTM 加一个 Approved，上线两小时后，监控发现优惠券超发了 1.7 万张。 复盘时我把三个人的评论翻出来看，发现一个规律： 评审人
