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

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

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

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

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

技术选型：LangChain4j 凭啥胜出？

维度	LangChain4j	Rasa	Dialogflow
开发语言	Java 一栈	Python	云端黑盒
本地部署	是	否（需翻墙）
与 Spring 集成	零配置 Starter	需 Flask 中转	官方 SDK 年久失修
自定义模型	任意兼容 OpenAI API 端点	支持	仅 Google 模型
上下文保持	内存/Redis 插件	Tracker Store	30 分钟自动过期
开源协议	Apache 2.0	MIT	闭源收费

一句话总结：团队全是 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，结果如下：

指标	老系统	LangChain4j 新系统
平均 QPS	210	820
P99 延迟	2.8 s	480 ms
错误率	3.2 %	0.1 %
CPU 占用	92 %（IO wait 高）	68 %

吞吐量提升 ≈ 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(); } }