Java团队用LangChain4j打造医疗智能客服：多轮对话与RAG实战-北京尧图网络

做医疗智能客服这个项目的时候我最大的感受是AI框架的选型真的可以决定一个Java团队的开发节奏。我们内部代号叫硅谷小智说白了就是一个面向患者问诊前、问诊后的智能接待机器人要能回答科室导诊、就诊流程、检查注意事项、报告查询这些高频问题还要能识别出紧急情况引导用户直接走急诊通道。技术栈最终落在LangChain4j上整个过程从零搭骨架到核心功能跑通大概花了两周多这篇笔记把关键设计和实操细节完整记录下来。如果你也在用Java做LLM应用开发或者正纠结要不要把LangChain4j引入团队这篇内容应该能帮你避开不少弯路。我不会堆概念只讲我们项目里的真实取舍、踩过的坑以及最终能跑的代码长什么样。1. 项目到底要做什么需求拆到不能再拆1.1 硅谷小智是谁服务谁项目的目标很明确做一个医疗场景的智能客服挂在医院的在线服务入口上替代一部分人工坐席的工作。患者不需要下载额外的东西在公众号或者小程序里就能直接对话问我最近老是咳嗽挂什么科或者明天做胃镜能喝水吗这类问题。医疗客服和普通电商客服差太多了。电商客服答错了最多退货退款医疗客服要是把病情方向带偏了那是人命关天的事。所以产品层面一开始就定了几个硬约束不做诊断只做信息指引和就医辅助。紧急症状必须识别出来先引导拨打120或者去急诊。涉及具体用药、治疗方案的问题一律给出请以医生面诊为准的态度。所有回答尽可能引用知识库内容降低模型自由发挥的空间。这个定位决定了后续所有的技术选型。我们不是要做一个什么都能聊的通用大模型机器人而是要做一个带着镣铐跳舞的领域助手知识边界必须清晰。1.2 需求拆解客服能力拆成三个模块把产品需求翻译成技术需求时我习惯先把能力拆成独立模块然后再看每个模块需要什么AI能力支撑。硅谷小智最终被拆成三大块第一块是通用多轮对话能力。患者不会只问一句话他会一直追问我应该挂哪个科这个科周末上班吗那我要带什么证件这种连续对话场景要求大模型必须能记住上下文也就是常说的对话记忆。没有记忆的客服就是个只会回答单句问题的复读机。第二块是医疗知识库问答能力。导诊规则、就诊流程、科室介绍、检查注意事项这些内容其实是相对固定的最适合放进知识库做检索增强生成。模型每回答一个问题先到知识库里检索最相关的几个片段再结合问题生成答案。这样做既能提高答案的准确性又能给回答加上引用来源方便用户追溯。第三块是意图识别和工单能力。对话里会出现一些需要触发特定动作的情况。比如用户说我胸口很疼喘不上气这明显是紧急情况客服不能还慢悠悠地介绍科室而是要立刻跳转到急救引导流程。再比如用户问了一堆问题后说我还是没搞清楚想找人工这时候需要识别出转人工意图生成一条工单推给人工坐席。这三块能力对应到LangChain4j里分别是ChatMemory、RAG检索增强生成和Function Calling。分工清晰后续开发也是按这个主线展开的。2. 技术选型为什么是LangChain4j2.1 Java团队做AI的尴尬与出路项目立项的时候团队里认真讨论过要不要直接用Python那一套。LangChain的Python版生态最齐全社区也最活跃很多新功能都是Python版先上。但问题很现实整个后端团队全是JavaSpring Boot是绝对主力没人愿意为了一个客服项目另起炉灶搭一套Python服务。跨语言调服务的方案也想过。Python那边起一个独立的AI服务Java这边通过HTTP调用。这种方案不是不行但会增加一个维护节点而且模型输出的流式传输、对话状态管理这些逻辑跨服务传递时会麻烦很多。LangChain4j的出现正好解了这个死结。它是Java版本的LLM应用框架核心思路和Python的LangChain是一致的提供了模型封装、对话记忆、向量检索、Agent工具调用这些组件而且原生适配Java生态。对我们这种Java团队来说能在熟悉的语言里直接操作大模型开发效率和维护成本都是最优解。关于框架的成熟度说实话还是比Python版差点版本迭代也快但够用。我们当时的选型判断就是项目复杂度可控核心链路并不复杂LangChain4j完全撑得住而且它还在高速发展后续升级也方便。这里建议还在观望的同学先确认你的后端团队主力语言主力是Java就大胆用主力是Python就别勉强了各回各家各自舒服。2.2 LangChain4j核心组件到底提供了什么LangChain4j这个名字听着挺唬人实际上它做的事情可以拆成几块模型接入层。不管底层接的是哪个大模型它都统一封装成ChatLanguageModel接口Java代码调用起来和调普通方法没有区别。支持OpenAI协议的服务基本上都能通过对应模块接入配置模型名称、接口地址、API Key就完事。对话记忆层。ChatMemory接口管理多轮对话的历史消息常用的有MessageWindowChatMemory只保留最近N条消息用起来非常省心。向量检索层。EmbeddingModel负责把文本转成向量EmbeddingStore负责存储和检索向量EmbeddingStoreIngestor管道式地处理文档切片、向量化、入库。这套东西组合起来就是RAG的基础设施。Agent构建层。AiServices可以把模型、记忆、工具、RAG组件编排在一起再通过注解定义提示词代码结构非常清爽。我把这些组件理解成一个个积木块。你不是非要全部用上按需组装就行。我们项目只需要对话记忆、RAG检索、工具调用这三块其他功能一概没碰避免引入不必要的复杂度。2.3 工程骨架与依赖引入我们用的是Maven多模块结构核心模块就两个一个assistant-core放主要的对话编排逻辑一个web-api放Spring Boot接口。依赖上只在core模块引入langchain4j相关包。我写一下当时的依赖清单给你做个参考dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.3x/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-open-ai/artifactId version0.3x/version /dependency dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-embeddings/artifactId version0.3x/version /dependency每个小版本的API会有些许调整当时的版本到现在的版本类名和包名可能都有变化。我的建议是不要照抄版本号去Maven仓库看最新的稳定版然后对照官方文档改改import路径就行核心思路是通用的。模型的初始化代码长这样把大模型的接入封装在配置类里ChatLanguageModel model OpenAiChatModel.builder() .baseUrl(https://your-llm-service.example.com/v1) .apiKey(sk-xxxx) .modelName(your-model-name) .maxTokens(1024) .temperature(0.2) .build();温度参数我直接设成了0.2医疗场景下决不允许模型自由发挥越是保守的答案越安全。有些同学喜欢调到0.7让对话变得更灵动这个在娱乐聊天可以在客服场景是灾难凡是涉及专业内容的任务低温永远是最优先的选择。至此工程骨架搭完了后面每一块能力都是在这些基础组件上做文章。3. 多轮对话ChatMemory 与流式输出落地3.1 ChatMemory的两种打开方式多轮对话是整个客服系统最基础的体验。用户问一句、客服答一句看起来简单但要让模型理解你正在说的事情必须把之前的对话内容一起送过去。如果每次请求都是孤立的用户上一句说我感冒了下一句问那我可以吃火锅吗模型根本不知道那指的是什么。LangChain4j的MessageWindowChatMemory用的是滑动窗口思路只保留最近若干条消息。我当时配置的是20条消息窗口按一轮问答两条消息来算大概能覆盖最近10轮对话对客服场景足够了。ChatMemory chatMemory MessageWindowChatMemory.builder() .maxMessages(20) .build();使用窗口记忆的好处是省token不用每次请求都携带全量历史。但也有局限窗口外的信息会永远丢失这时可以把长对话做成摘要记忆。LangChain4j里有一种SummarizingChatMemory它会自动把旧消息浓缩成摘要再拼到窗口前面兼顾了省token和保留上下文两头。不过我们最终没用它原因很简单客服场景的对话平均时长并不长用户要么问清流程就走要么主动转人工20条消息窗口完全够用。关于对话记忆有一个必须强调的点每个独立用户必须独立记忆实例。我见过有同学图省事把ChatMemory配成单例全局共享结果用户A问“我胃疼”用户B接着问“那我呢”模型完全答非所问。这还不算最严重的极端情况下用户A的身份证号、病情信息会被用户B的对话带出来直接构成隐私泄露事故。正确的做法是给每个用户创建一个独立的记忆对象用sessionId做key存储。3.2 流式输出与SSE对接早期的版本客服回答是一整段蹦出来的。用户问完问题服务端要等模型完全生成完再一次性把答案返回体验非常糟糕。稍微长一点的回答用户得盯着屏幕等好几秒心里默念是不是坏了。流式输出就优雅多了。模型每生成一小段文字就立刻推到前端用户看到的回答是打字机效果边看边出体感响应时间被压缩到几百毫秒。LangChain4j的流式调用长这样model.chat(chatRequest, StreamingResponseHandlerAiMessage() { Override public void onNext(String token) { // 每个token推送给前端 } Override public void onComplete(ResponseAiMessage response) { // 生成结束 } Override public void onError(Throwable error) { // 异常处理 } });后端把token逐段推给前端后端用SSEServer-Sent Events前端用EventSource接收。这里有个细节SSE推送的时候上下文边界要处理好——每一段token推过去之后前端要自己去拼装文本拼到对话历史里也要把新产生的用户消息记录到ChatMemory不然下一轮就失忆了。3.3 会话隔离的坑会话隔离这个坑我多说几句因为它坑了我整整一个下午。我们的用户会话是这样的用户进入页面后端创建一个sessionId所有对话请求都带上这个ID。最开始我天真地以为只要给每个sessionId创建独立的ChatMemory就万事大吉。实验结果啪啪打脸。问题出在关闭浏览器和重新打开这个环节。用户关掉页面sessionId没用了再打开就生成新的sessionId之前的对话历史全丢了。一开始用户还不在意后来发现用户问完我昨天来咨询过转人工的事客服一脸茫然体验直接崩了。解决思路是sessionId只做短期关联真正的用户标识是用户ID。只要用户登录状态不变后端就把同一个ChatMemory绑定到用户ID上sessionId只是当前浏览器会话的临时标签。这样用户关掉页面再回来对话还能接上。如果是匿名用户就更简单了sessionId可以直接作为用户ID但要做好过期清理不然内存里堆一堆废弃的ChatMemory久而久之会有内存泄漏风险。我后来写了个定时任务超过30分钟没有新消息的会话主动清掉对应的记忆实例。4. 医疗知识库RAG 从文档到检索的完整链路4.1 知识库从哪来文档清洗与切片多轮对话只是骨架医疗客服真正的血肉在于知识库。RAG方案的核心逻辑是不指望大模型记住所有医疗知识而是让它在回答前先去检索相关的知识片段基于检索结果生成答案。第一步是准备知识文档。我们和运营拿到的资料是各种Word文档、PDF手册内容五花八门有科室介绍、导诊须知、楼层索引、检查准备说明。第一步不是切片而是清洗。PDF里扫描版需要OCRWord文档格式不统一要统一转成纯文本或Markdown表格要单独整理因为直接切成文本后表格结构会乱掉检索时就找不准。清洗完之后进入切片环节。切片是RAG里影响最终效果的最关键步骤切大了一个片段里塞进好几个主题检索出来噪音太大切小了上下文语义不完整模型理解不了。LangChain4j提供了DocumentSplitters.recursive支持按段落、句子、指定长度做递归切分。我当时的配置是按照大概500字符一个片段片段之间重叠100字符。DocumentSplitter splitter DocumentSplitters.recursive(500, 100); ListTextSegment segments splitter.split(document);为什么要加重叠因为知识的边界不是一刀切的重叠部分能保证被两个片段共享的主题无论检索命中了哪个片段上下文都基本完整。500字符对医疗导诊类文本来说差不多是一两个段落的量语义内容相对完整。切片完成后要给每个片段加metadata比如来源文件名、所属科室、文档类型。这个metadata在后续检索过滤中的作用非常大我们后面还会提到。4.2 embedding 模型与向量存储的选择文本变向量这个过程用的是embedding模型。它会把一段文字映射成一个高维向量语义相近的文本向量距离越近。检索的时候把用户的问题也转化成向量然后在库里找最接近的几个向量对应的文本就是最相关的知识片段。当时我们用的是开源的中文embedding模型部署在一台GPU服务器上LangChain4j通过HTTP接口调它EmbeddingModel的实现一个HTTP客户端封装就搞定了。为什么不直接用大模型自带的能力因为embedding和对话模型通常是两个独立的服务embedding模型相对小而快专门做文本向量化这一件事。向量存储的实现上项目初期我直接用LangChain4j内置的InMemoryEmbeddingStore就是内存版向量库。这样做的好处是零依赖、调试方便坏处是数据量一大就撑不住重启服务数据就清空了。后来换成某个开源的向量数据库既然要走docker部署为解决可用性数据落盘是必须的。LangChain4j的向量存储抽象接口很干净换实现不需要改业务代码这一点做得确实不错。4.3 检索优化与提示词注入所有知识片段向量化完成后就进入检索和注入环节。上代码EmbeddingModel embeddingModel ...; EmbeddingStoreTextSegment embeddingStore ...; // 用户问题转向量 Embedding queryEmbedding embeddingModel.embed(userMessage).content(); // 查最相似的5个片段 ListEmbeddingMatchTextSegment matches embeddingStore.findRelevant(queryEmbedding, 5);在真实项目中我建议你不仅仅依赖向量的语义相似度还要结合metadata过滤。比如用户明确说我要做胃镜那检索的时候可以带上科室过滤条件只搜消化内科相关的片段。基于向量的召回和基于规则的过滤结合效果比单一向量召回稳定得多。这也是为什么前面反复强调切片时要把metadata打全的原因——没打metadata后面想过滤都没得滤。还有一个细节检索回来的片段不能直接一股脑全塞给模型。要在提示词里给模型划分清楚哪些是知识库里正儿八经的内容哪些是当前用户的问题。我的提示词大致长这样SystemMessage( 你是医疗智能客服小智。请严格按照下面的知识片段回答问题。如果知识片段中没有相关信息请直接回复这个问题我不太确定建议您咨询在线人工客服。不要编造答案不要自行补充知识片段以外的信息。 ### 知识片段 ### {{knowledge}}) String chat(UserMessage String userMessage);{{knowledge}}是LangChain4j支持的模板变量可以把检索出来的知识片段拼进去。这里有个细节值得注意知识片段如果太多塞入的token消耗会很大响应速度也会变慢。我当时设了上限最多只拼6个片段一个片段500字符那就是3000字符加上对话历史和问题一次请求控制在3500字符左右性价比比较合理。检索不到内容时模型必须承认不知道而不是硬编一个答案。医疗场景下我不知道是个好回答胡编乱造才是致命的。这个约束不只在提示词里写后续还要在测试里不断逼问、调整话术。5. 意图判断与工单能力Function Calling5.1 为什么需要工具调用光有对话和检索还不够客服系统还需要一些动作能力。比如识别出用户需要急救就不能只是回句话而是要立刻跳转急救流程给用户的页面弹出拨打120的确认框。再比如用户说我想投诉或者你答非所问我要转人工系统要能创建一个工单。这些动作没法靠纯文本生成完成需要让模型调用代码。LangChain4j提供的Function Calling能力就是干这个的——定义一些Java方法在提示词里告诉模型有哪些工具可用模型判断当前场景需要时会在回复中请求调用某个方法框架再把方法跑起来把结果返回给模型。这个机制理解起来有点绕我打个比方。模型就像一个实习生他知道现在该去拿一份文件但不知道文件放在哪里于是他写了一张条子请帮我到B栋3楼档案室拿这份文件。框架就是传递条子的行政拿到条子后跑过去把文件取回来递给实习生实习生看完文件继续写报告。模型本身不能执行代码但它能决定什么时候调用、调用哪个工具这就够用了。5.2 Tool 实现紧急情况识别与科室转接在我们项目里工具调用主要用于两个场景。第一个是紧急情况识别。我给模型配了一个工具方法Tool(判断用户描述的症状是否属于需要急救的紧急情况) public boolean isEmergency(String userMessage) { ListString keywords Arrays.asList(胸口剧痛, 呼吸困难, 大出血, 意识模糊, 剧烈头痛); for (String kw : keywords) { if (userMessage.contains(kw)) { return true; } } return false; }实际项目里这个判断不会这么简单会结合正则表达式、关键词表甚至一个专门的文本分类模型。但思路是一致的模型读到用户消息感觉这批信号已经超出知识库能处理的范畴于是调用isEmergency工具拿到true之后就会切换话术引导用户拨打120并关闭当前的常规导诊流程。第二个是转人工工单。用户表达不满或者问了三四轮还是没解决时模型会调用创建工单的方法把对话上下文的关键信息用户ID、问题摘要、所属科室传给工单系统人工坐席端就能尽早看到。工具调用的配置非常简单用AiServices把这些方法注册进去模型调方法时框架自动处理MedicalTools tools new MedicalTools(); MedicalAssistant assistant AiServices.builder(MedicalAssistant.class) .chatLanguageModel(model) .chatMemory(chatMemory) .tools(tools) .build();关于工具调用有一个必须注意的坑工具方法一定不要做有副作用、需要权限的操作比如主动扣费、删除数据这类直接挂在AI Agent上风险极高。模型会不会误触发完全不可控我当时把转人工工单弄成可撤销的草稿状态而不是直接分配给坐席先让人工审核确认再正式推入队列多了一道兜底。5.3 AiServices 串联记忆、模型与工具AiServices在这套体系里的位置非常重要。之前提到的对话记忆、RAG知识检索、工具调用其实都可以通过它编排起来组合成一个完整的AI fluent接口。我在代码里定义了一个接口interface MedicalAssistant { SystemMessage( 你是医疗智能客服小智你可以根据知识库回答就医问题也可以在必要时调用工具完成紧急情况识别与工单创建。) String chat(String userMessage); }然后构建MedicalAssistant assistant AiServices.builder(MedicalAssistant.class) .chatLanguageModel(model) .chatMemory(chatMemory) .tools(tools) .build();如果需要加RAG可以利用ContentRetriever把检索链路接进来。这样每次调用assistant.chat(userMessage)的时候框架层面的动作是取聊天记忆、拼系统提示词、做知识检索、判断是否调工具、生成回复。业务侧看到的只是一个普通的方法调用底层的复杂度都被框架消化了。这种设计对团队协作很有价值。上游接口层拿到的是一条干净的调用线不管后续模型换供应商、知识库换向量数据库都不需要把整条链路推倒重来。6. 联调阶段踩过的坑和排查实录6.1 六大高频问题的排查表项目联调期积攒了一批很有价值的坑我整理成一张速查表应该能帮你省掉很多无头绪的排查时间。现象根因解决方式用户A的对话回复里出现了用户B的隐私信息ChatMemory被配置成全局单例按用户维度创建独立ChatMemory实例用完释放用户重新打开页面后客服不记得之前的对话sessionId变化导致记忆丢失用用户ID绑定记忆sessionId只做临时关联检索到的知识片段文不对题切片粒度不合适或metadata未设置过滤条件调整切分参数补充metadata过滤逻辑回答经常出现编造的内容提示词约束不够强硬温度设置过高把temperature降到0.2提示词中加强不许编造指令多工具调用顺序混乱模型一次调用好多个工具工具定义之间的依赖没有明确限制给工具方法加上清晰的使用说明必要时用状态标志位防止并发调用响应速度越来越慢知识片段塞得过多token消耗超预期限定片段数量启用流式输出提升体验其中知识片段文不对题这个问题我排查得最久。一开始以为是embedding模型不行换了好几个都没效果后来才发现是文档里几个相似症状的描述太像了向量空间里的距离自然很近。最后是在metadata里加了症状关键词标签再加一层规则过滤效果才改善。6.2 医疗场景的安全边界设计医疗客服在安全边界上花再多时间都不为过。边界一不提供诊断结论。模型可以描述发烧伴随咳嗽可能是上呼吸道感染的表现但绝对不能说你得了肺炎。这句怎么说是有讲究的核心是把回答从你得了什么病引导成这类症状通常与什么情况有关需要线下确认。边界二用药建议必须有信息源。用户问感冒了能吃布洛芬吗知识库里没有药品信息时模型必须直接说建议咨询医生或药师不能凭模型训练时的记忆自行给建议。大模型的训练数据里确实有大量药物知识但那些知识没有经过我们审核不能直接输出。凡是这类问题我都在提示词里单独声明了一条用户询问用药、治疗方案时不回复具体建议一律引导至专业渠道。边界三紧急症状优先于一切指令。测试过程中我们发现如果不做特殊处理模型被用户绕几轮你帮我分析一下我这个情况是不是很严重之后容易进入常规问答模式。当用户已经说出胸痛、呼吸困难这类关键词时任何其他指令都不能覆盖急救引导的逻辑。这个优先级是在Prompt和工具调用两个层面双重锁定的。边界四敏感信息过滤。用户可能无意中透露身份证号、手机号这些信息不能进日志也不能进入知识检索的上下文。我们在入口处加了一层脱敏把手机号、身份证号打码后再传给模型。6.3 成本控制与响应速度调优最后聊聊成本和响应速度这是所有AI应用上线前都躲不开的两件事。成本大头在token消耗。我们的调优思路是按会话维度控制上下文长度会话超过20轮之后自动把最老的消息丢出窗口或者提示用户可以开启新会话。这招立竿见影平均每会话的token消耗直接降了30%出头。响应速度上核心优化是控制单次请求的输入长度。医学知识片段虽然要引入但不是越多越好。我们内置了一个检索质量门控只有当检索分数超过阈值时才把片段拼入提示词分数太低的宁可不引入让模型直接说不知道。这样既省了token又避免了弱知识干扰回答质量。还有一个很实用的小技巧把系统提示词做成固定前缀不在每次请求都重复携带大段的示例和规则。LangChain4j允许在构建助手时预设SystemMessage这部分是每个会话固定的不用重复计费。像我们这种场景把医疗安全边界五条规则固定成SystemMessage既安全又省钱。流式输出也是体验优化的重要手段。即使后端完整生成需要3秒但只要第一段字在200毫秒内出现用户感知的等待时间就完全不一样。这里要提醒一下SSE的断线重连机制要处理好不然用户一边听一边断客服的话就漏了一段。最后再说两句我项目做完后回头看LangChain4j对Java团队的帮助是实实在在的。它把模型接入、记忆管理、RAG、Function Calling这些LLM应用的基础能力都框架化了Java开发者的学习成本比想象中低很多。硅谷小智作为一个医疗智能客服它的边界设计、检索策略、工具调用规范其实可以平移到任何行业客服项目里。医疗场景的特殊性决定了我们处处都要稳字当头不能为了炫技让模型自由发挥。希望这篇实战笔记能给正在做类似项目的同学一个参考尤其是那些正准备从零搭建LLM应用的Java团队。下次如果再写这个系列我应该会分享硅谷小智的评测方案和知识库的持续运营策略那又是一个完全不同的战场。

Java团队用LangChain4j打造医疗智能客服：多轮对话与RAG实战

相关推荐

多模态大模型训练避坑指南：归一化、激活函数与架构一致性

diagram-design：让架构图成为可执行的技术契约

远程控制软件怎么选？五款主流远控工具实测对比

更多资讯

RS232通讯芯片D3232

Agentic Awesome Skills 实战指南：Apify Actor 日志系统深度解析（apify/log 与 Actor.log 全级别使用规范）

双通道音频功率放大器D2025

MySQL底层运行原理深度解析与性能优化指南

44:第n小的质数

嵌入式C与标准C的差异：内存、运行时与编译器行为解析

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？