【Java大厂面试实录】谢飞机闯关AIGC智能客服系统：Spring AI + RAG + Redis向量检索 + 幻觉抑制实战

唤醒那回忆

413人浏览 · 2026-03-22 21:01:10

唤醒那回忆 · 2026-03-22 21:01:10 发布

【Java大厂面试实录】谢飞机闯关AIGC智能客服系统：Spring AI + RAG + Redis向量检索 + 幻觉抑制实战

面试官：字节跳动「豆包AI中台」Java高级工程师（AI Infra方向）
求职者：谢飞机（昵称“谢总”，简历写“精通Spring全家桶，略懂AI，会调OpenAI API”）

🎯 第一轮：业务切入 —— 为什么要做AI客服？传统方案卡在哪？

面试官（推了推眼镜）：谢同学，我们正在重构电商App的在线客服系统。当前用的是规则+关键词匹配的FAQ机器人，准确率仅62%，大量用户问“我昨天买的防晒霜还没发货，物流显示异常，能赔吗？”这类跨订单、跨状态、带主观情绪的复合问题，根本答不上来。你认为引入AIGC智能客服的核心价值是什么？技术上要解决哪三个最关键的瓶颈？

谢飞机（挺直腰板）：“咳咳，这个我知道！第一，得让机器人‘看懂人话’——用大模型；第二，不能瞎编，得查真实数据，比如订单库、售后政策PDF；第三……（挠头）第三是不是……得快？不然用户等3秒就退出了？”

面试官（点头微笑）：很好！语义理解、知识溯源、响应延迟——这正是AIGC落地的铁三角。那第二个瓶颈‘知识溯源’，你怎么确保大模型回答不胡说？比如用户问‘7天无理由退货怎么扣运费？’，模型若凭参数‘脑补’出错误条款怎么办？

谢飞机：“呃……加个‘请参考官方文档’？或者……让它说‘我不确定，建议联系人工’？”

面试官（轻笑）：这是兜底策略，但不是技术解法。我们今天聊的是工程化方案。

🚀 第二轮：技术深挖 —— RAG如何嵌入Java微服务？

面试官：我们选型Spring AI + 自研RAG Pipeline。现在问题来了：

用户提问到达后，服务端需对query做Embedding向量化。你用哪个Embedding模型？本地部署还是API调用？为什么？
向量检索我们用Redis Stack（Redis v7.2+ 的Vector Search模块），而非Milvus或Chroma。你觉得Redis的优势和风险分别是什么？
检索到Top-3相关文档片段后，如何安全拼接到Prompt里传给LLM？怎么防Prompt注入？

谢飞机（擦汗）：“啊……Embedding……我用过OpenAI的text-embedding-3-small，API调……因为……本地显存不够……（小声）Redis？快！内存数据库嘛……风险？嗯……数据丢了？（突然抬头）哦！它没持久化好！”

面试官（提示）：再想想——在高并发客服场景下，Redis作为向量库，它的分片能力、过滤语法支持度、与Spring Data的集成成本，哪个更关键？

谢飞机（眼神飘忽）：“分片……好像是cluster模式？过滤……where条件？Spring Data……有redis template……（停顿）那个……它……它能存向量吗？”

⚙️ 第三轮：架构闭环 —— 从检索到生成，如何抗幻觉、保合规？

面试官：最后一步：LLM生成答案前，我们插入了两道‘安检门’：

事实校验层：用Resilience4j熔断+重试机制，调用订单中心gRPC接口实时核验‘该用户昨日确有订单#OD20240520XXXX’；
合规审查层：基于Spring Security的权限上下文，动态注入‘当前用户为PLUS会员，可享运费险赔付’策略，并拦截所有含‘赔偿’‘补偿’等敏感词但无风控工单ID的输出。

问题：

若gRPC查询超时，熔断器打开，此时是返回‘系统繁忙’，还是降级走缓存中的历史相似问答？哪种更符合用户体验？
Spring Security在这里不鉴权，而做‘策略注入’，是否算误用？有没有更贴切的Spring生态组件？
整个链路涉及Spring AI、Redis Vector Search、gRPC、Resilience4j、Spring Security——你如何用Micrometer统一埋点，定位哪一环拖慢了P95延迟？

谢飞机（掏出手机假装看消息）：“这个……超时肯定要降级啊！缓存最快！Security……它本来就能管权限……也能管策略吧？Micrometer……那个……是个监控的……（叹气）面试官，您这题，比我上次调通Dubbo泛化调用还难……”

面试官（合上笔记本，微笑）：谢同学，你对基础概念有感知，也敢于表达思考路径，这点很可贵。但AIGC Infra不是API搬运工，而是要深入Embedding工程、向量DB选型权衡、LLM调用链路可观测性设计。建议系统补强RAG Pipeline原理、Redis Vector Search实战、以及Spring AI 1.0.0-Mx的AiResponse流式解析机制。感谢你今天的时间，我们会通过邮件反馈结果。

✅ 【附：小白也能懂的答案详解】

💡 场景还原：为什么是「电商智能客服」？

业务痛点：传统FAQ机器人无法处理多跳推理（如“我下单未支付→取消→又下单→物流异常→能否赔付”）、缺乏上下文感知（未识别用户VIP身份）、易产生幻觉（虚构不存在的赔付标准）。
技术目标：构建低幻觉、高时效、可审计的AIGC客服，核心指标：首响<800ms、事实准确率≥95%、合规拦截率100%。

🔧 关键技术点拆解：

1️⃣ Embedding模型选型

推荐方案：Ollama本地部署nomic-embed-text（Apache 2.0许可，1GB显存可跑，中文效果媲美text-embedding-3-small）。
为什么不用纯API？ 避免请求被限流/超时导致客服中断；规避敏感订单数据外泄风险；降低长尾请求成本。
Java集成：用spring-ai-ollama-spring-boot-starter + OllamaEmbeddingClient，异步批处理query，毫秒级完成向量化。

2️⃣ Redis Vector Search vs Milvus/Chroma

| 维度 | Redis Stack | Milvus/Chroma | |--------------|----------------------------------------|------------------------------| | 优势 | ✅ 与现有Redis缓存复用，零新运维组件；✅ 支持Tag过滤（WHERE source='policy_v2024'）；✅ Spring Data Redis 3.2+原生支持VectorSearchOperations | ✅ 专为向量优化，亿级召回更快；✅ 支持HNSW/GPU加速 | | 风险 | ❌ 单节点容量有限（建议≤500万向量）；❌ 复杂聚合能力弱（如跨多个vector field join） | ❌ 需独立部署K8s集群；❌ 与Spring生态集成较重 | | 决策依据 | 电商客服知识库稳定在200万片段内，且必须按document_type+effective_date精准过滤，Redis更轻量可控。

3️⃣ Prompt安全拼接与注入防护

安全拼接：用StringEscapeUtils.escapeHtml4()预处理文档片段，避免</prompt>闭合标签被恶意利用；
长度控制：采用RecursiveCharacterTextSplitter按语义切分，限制每段≤256 token，总上下文≤1500 token；
注入防护：在Prompt模板中强制声明<|START_OF_DOCUMENT|>...<|END_OF_DOCUMENT|>边界符，LLM输出后正则校验是否完整包含，否则拒绝返回。

4️⃣ 幻觉抑制双保险设计

事实校验层：gRPC调用订单中心OrderQueryService.GetOrderDetail，Resilience4j配置timeLimiterConfig.timeoutDuration=800ms + circuitBreakerConfig.failureRateThreshold=50%，熔断后自动降级至CaffeineCache中存储的近30天TOP100高频问答快照（非实时，但保可用）。
合规审查层：并非误用Spring Security！其SecurityContext天然携带Authentication.getAuthorities()，可扩展GrantedAuthority为PolicyAuthority("REIMBURSEMENT_VIP_PLUS")，再由自定义PostProcessor在LLM输出前注入策略约束。更优解是结合Spring AI的CallbackHandler，在onResponse()事件中执行审查逻辑。
全链路观测：用Micrometer Tracing（基于Brave）打标ai.rag.embedding/ai.rag.search/ai.llm.invoke三段span，Grafana看板配置P95延迟热力图，快速定位是Embedding耗时（CPU瓶颈）还是Redis网络延迟（RTT>15ms告警）。