订单系统线程池被一个"智能"功能打满 三月下旬的一个下午，监控突然报警：订单履约服务的 Tomcat 线程池活跃数从平时的 40 冲到 200（最大值），接口 P99 从 180ms 涨到 12s，大量订单卡在"待履约"状态。 排查过程很快。看线程 dump，200 个线程里有 187 个卡在同一个
半年过去了，我们团队到底提效了多少 2024 年 10 月我们组 11 个人开始全面用 AI 编码助手，到今年三月底正好半年。这半年里我在各种场合听到的说法从"提效 50%"到"就是个高级补全"都有，差距大到不像在说同一个东西。所以我们拉了数据自己看了一遍，顺便把踩过的坑和定下的规矩记下来。 数据是
产品说"用户上传截图自动填工单" 三月中旬产品提了个需求：用户报障时经常甩一张截图过来，客服要手工把里面的订单号、错误码、时间点一个个敲进工单系统，平均 90 秒一条，希望系统能自动识别和填充。听起来简单，做下来发现"看懂一张图"这件事在工程上的复杂度远超我的预期。 这篇记录我们在 Java 应用里
早上九点收到的一条额度告警 2025 年 2 月底的一个周一，我刚进公司就收到运维的消息："模型供应商账户额度用了 78%，平时这个时候只有 15%。" 紧接着业务群炸了，客服系统开始大面积报 429 Too Many Requests。 查了半小时，根因很朴素：上周五上线的智能质检功能有个循环调用
8.6 万份文档，Tika 抽出来的表格全是乱码 去年底接了个企业知识库的项目，要把公司十年积累的技术文档、产品手册、标书、合同模板全部灌进 RAG。总量 8.6 万份，PDF 占 45%，Word 30%，Excel 15%，剩下是 PPT 和 HTML。 第一版我图省事，直接用 Apache T
单次 Function Calling 撑不住，我上了 ReAct 去年 11 月我们给内部运维做了个助手，能查监控、查日志、查工单、执行标准操作。第一版用的是大模型的 Function Calling：把工具列表丢给模型，模型返回一个函数调用，我们执行完把结果拼进上下文，再问一次，直到它不再调工具
数据量涨到 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
AI 应用开发：大模型与 RAG 实战 随着大语言模型（LLM）的快速发展，构建 AI 应用变得越来越容易。检索增强生成（RAG）是提升大模型回答质量的关键技术。 什么是 RAG？ RAG（Retrieval-Augmented Generation）结合了信息检索与文本生成的优势： 从外部知识库中
