基于langchain4j实现智能客服：从架构设计到生产环境避坑指南

传统客服系统的“三座大山”

作为一线 Java 开发，我维护过基于关键字匹配的老客服系统，也踩过开源对话框架的坑。总结下来， 传统方案有三座绕不过去的大山：

1. 并发响应慢：Tomcat 线程池 + 同步调用外部 NLP 接口，高峰期平均 RT 2.5 s，CPU 空转在 IO 等待上。
2. 意图识别弱：正则或朴素贝叶斯，新意图要人肉加规则，上线一周准确率就掉到 60 % 以下。
3. 知识库更新难：FAQ 用 MySQL 做 like 查询，每次上新活动都要通宵导数据，还得重启应用。

去年“618”大促，客服峰值 QPS 2 k，老系统直接雪崩。痛定思痛，我们决定用 Java 生态最友好的 LLM 框架——langchain4j 重构，目标只有一个：让客服先“学会说话”，再“扛住流量”。

技术选型：LangChain4j 凭啥胜出？

一句话总结：团队全是 Java 栈，不想额外养 Python 运维，也不愿把核心语料放到公网，LangChain4j 成了“最省头发”的选择。

架构总览：一条链搞定“听懂→找到→答回”

用户提问 → Gateway → 意图识别（LLM）→ 知识库检索（Embedding）→ Prompt 组装 → LLM 生成答案 → 敏感词过滤 → 返回

整条链用 LangChain4j 的Chain接口串起来，每个节点都可插拔，方便 AB 实验。

核心实现：代码直接搬

1. 对话链入口（含超时与异常兜底）

@RestController @RequiredArgsConstructor public class ChatController { private final ChatService chatService; @PostMapping("/chat") public ApiResp<String> chat(@RequestBody UserQuery q) { try { // 2 s 超时，由 Resilience4j 包装 String ans = TimeLimiter.of(Duration.ofSeconds(2)) .executeFutureSupplier(() -> CompletableFuture.supplyAsync(() -> chatService.ask(q))); return ApiResp.success(ans); } catch (Exception e) { // 降级：返回静态文案 + 人工客服入口 return ApiResp.success("小姐姐正在忙，稍后回复或点我转人工～"); } } }

2. ChatModel 构建（支持随时换底座模型）

@Configuration public class LLMConfig { @Bean public ChatModel chatModel() { return OpenAiChatModel.builder() .baseUrl(System.getenv("LLM_ENDPOINT")) // 可指向私有部署 .apiKey(System.getenv("API_KEY")) .temperature(0.3) // 客服场景需要稳定 .callTimeout(Duration.ofSeconds(3)) .build(); } }

3. 知识库向量化量化（Embedding）与 Spring Boot 集成

@Component @RequiredArgsConstructor public class KbService { private final EmbeddingModel embeddingModel; private final EmbeddingStore<TextSegment> store; @PostConstruct public void loadFaqs() { List<Faq> faqs = faqMapper.selectAll(); List<TextSegment> segments = faqs.stream() .map(f -> TextSegment.from(f.getQuestion() + "\n" + f.getAnswer())) .toList(); store.addAll(embeddingModel.embedAll(segments).content(), segments); } public List<EmbeddingMatch<TextSegment>> search(String question, int topK) { Embedding query = embeddingModel.embed(question).content(); return store.findRelevant(query, topK); } }

• 时间复杂度：embedding 一次 O(L)（L 为 token 长度），faiss 检索 O(logN)。
• 空间：512 维 float 向量，每条 FAQ 约 2 KB，百万条不到 2 GB，内存管够。

4. 多轮上下文保持（基于 Redis）

@Component @RequiredArgsConstructor public class RedisChatMemory implements ChatMemory { private final StringRedisTemplate redis; private static final String KEY_PREFIX = "chat:memory:"; private static final Duration TTL = Duration.ofMinutes(30); @Override public List<ChatMessage> getMessages(String sessionId) { String json = redis.opsForValue().get(KEY_PREFIX + sessionId); return json == null ? List.of() : JsonUtil.toList(json, ChatMessage.class); } @Override public void add(String sessionId, ChatMessage msg) { List<ChatMessage> list = new ArrayList<>(get(sessionId)); list.add(msg); redis.opsForValue().set(KEY_PREFIX + sessionId, JsonUtil.toJson(list), TTL); } }

利用 Redis 的 TTL 自动过期，无需凌晨扫表，也避免内存泄漏。

性能压测：数据说话

JMeter 5.5，100 并发线程，循环 300 s，结果如下：

吞吐量提升 ≈ 300 %，CPU 反而降了，主要得益于异步 + 本地向量检索替代 like 查询。

生产环境注意事项

1. 大模型 API 限流

• 令牌桶 + 漏桶双层：本地先令牌桶 50 QPS，再远程漏桶 200 QPS，防止把供应商打爆。
• 返回 429 时立即熔断 30 s，并触发降级文案。

2. 敏感词过滤（AOP 实现）

@Aspect @Component public class SensitiveFilterAspect { @Around("@annotation(PublicApi)") public Object filter(ProceedingJoinPoint pjp) throws Throwable { Object[] args = pjp.getArgs(); if (args[0] instanceof String q) { if (SensitiveWords.hit(q)) { return "提问包含敏感内容，请文明沟通～"; } } return pjp.proceed(); } }

3. 对话日志脱敏

• 正则匹配手机、身份证、银行卡，统一替换为*，再落 ES。
• 关键字段 AES 加密，密钥放 KMS，审计平台单独授权。

踩坑小结

1. 向量维度不一致：embedding 模型换版本后 768 维，老数据 512 维，导致检索为空，解决：升级时全量重建索引。
2. Redis 序列化用 JDK 序列化，膨胀 5 倍，切 JSON 后省 70 % 内存。
3. LLM temperature 设 0.8 客服会“嘴瓢”，设 0 又太死板，最终 0.3 并加“请简短回答”提示词，效果最佳。

开放讨论：如果第三方 NLP 服务挂了，你的降级方案是什么？

• 本地缓存热点意图 + 静态答案？
• 规则 + 全文检索临时顶上？
• 还是直接转人工，业务可接受吗？

欢迎留言聊聊你们的做法，一起把智能客服做成“真正不慌”的系统。