文档下线三天了，客服机器人还在引用它 9 月中旬出了个不大不小的故障。运营下架了一份过期的《海外退换货政策 V1》，三天后还有用户在客服机器人里问到"海外订单 30 天可退"，而新政策是 15 天。用户截图投诉到了客服主管那里。 我查了一圈，问题出在存储架构上。我们当时的 RAG 是这样的： MyS
同事甩给我一个跑了 25 分钟的同步接口 上周三下午，做商品中心的小赵在工位上喊我："哥，我这个批量生成接口本地跑得好好的，一上预发就 504，你帮我看看。" 需求不复杂：运营上传一个 5000 行的商品 Excel，每行调一次大模型生成营销文案，全跑完导出结果文件。他写的是同步接口，一个 for
AI 应用开发：大模型与 RAG 实战 随着大语言模型（LLM）的快速发展，构建 AI 应用变得越来越容易。检索增强生成（RAG）是提升大模型回答质量的关键技术。 什么是 RAG？ RAG（Retrieval-Augmented Generation）结合了信息检索与文本生成的优势： 从外部知识库中
团队想给客服系统加 AI 能力，产品经理一句"接个大模型"听起来轻巧。真要做时，我发现最大的问题不是模型效果，而是：AI 该放在系统哪一层？和现有业务怎么融？出错了怎么办？这层边界不清，迟早把核心交易拖下水。 边界划分：AI 是增强，不是核心 我的第一原则是：AI 能力必须处在非关键路径。下单、扣款
大模型再能聊，它本身算不了实时库存、查不了数据库。要让它"动手"，得靠 Function Calling：模型决定调哪个函数、填什么参数，Java 侧真实执行，再把结果喂回去。这趟趟过的坑，比想象中深。 工具注册：把 Java 方法暴露给模型 用 Spring AI（1.0 GA 稳定版）注册一个工
LLM 进了核心链路，黑盒就太危险 工单助手上线后，运营反馈"有时候答非所问"。但 LLM 调用对我们来说是个黑盒：不知道每次花了多少 token、耗时多少、模型返回了啥。更糟的是出了错没法归因。我参照传统可观测性，给 LLM 调用也接上了 Trace、Token 统计和效果评估三件套，才算把这层黑
LLM 调用账单太吓人 工单助手每天上万次调用 GPT，账单一个月涨到三千刀。财务找过来时我才认真看数据：大量 query 语义相近（"怎么退货""退货流程""我要退钱"），答案其实一致，却每次都花 token 去问模型。用 Redis Stack 的向量检索做"语义缓存"，把相似问题直接命中缓存，
