SpringAI大模型在烘焙教学平台的智能客服实践

1. 为什么要在烘焙坊项目中引入SpringAI大模型？

去年我在开发一个线上烘焙教学平台时，遇到了一个棘手的问题：用户经常在深夜提出各种烘焙问题，而我们的客服团队无法做到24小时在线响应。这让我开始思考如何用技术手段解决这个问题。经过多方调研，最终选择了SpringAI作为大模型接入方案。

SpringAI是Spring官方推出的AI集成框架，它最大的价值在于为Java开发者提供了统一的大模型接入层。想象一下，你的应用就像一家面包店，而大模型API就像是面粉供应商。没有SpringAI时，你需要为每家供应商（OpenAI、Anthropic、Google等）单独适配接口；有了SpringAI后，就像建立了统一的采购标准，无论换哪家供应商，你的"面包配方"都不用重写。

在烘焙场景中，大模型可以发挥以下关键作用：

• 智能客服：解答用户关于配方、工艺的常见问题
• 配方生成：根据用户现有食材推荐个性化烘焙方案
• 故障诊断：通过文字描述帮助用户分析烘焙失败原因
• 多语言支持：为国际用户提供母语指导

提示：选择SpringAI而非直接调用API的最大优势是避免供应商锁定（Vendor Lock-in）。我在实际项目中就遇到过API服务突然变更的情况，由于使用了SpringAI的抽象层，切换供应商只用了不到1小时。

2. SpringAI环境搭建与基础配置

2.1 项目依赖配置

首先在pom.xml中添加必要依赖（以Spring Boot 3.2.x为例）：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>0.8.1</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-openai-spring-boot-starter</artifactId> </dependency>

这里有个实际踩坑经验：不同大模型供应商的starter包会引入冲突的Jackson版本。解决方法是在dependencyManagement中显式指定版本：

<properties> <jackson.version>2.15.3</jackson.version> </properties>

2.2 认证配置

在application.yml中配置API密钥：

spring: ai: openai: api-key: ${OPENAI_API_KEY} chat: options: model: gpt-4-turbo temperature: 0.7

温度参数（temperature）在烘焙场景特别重要：

• 0.2-0.5：适合精确的配方回答
• 0.7-1.0：适合创意食谱生成

• 1.0：可能产生天马行空的建议（慎用）

2.3 健康检查配置

添加以下配置确保服务启动时验证API连通性：

@Bean @ConditionalOnMissingBean public ApplicationRunner modelHealthCheck(AiClient aiClient) { return args -> { String response = aiClient.generate("健康检查"); log.info("大模型健康检查响应: {}", response); }; }

我在生产环境遇到过因API配额耗尽导致服务不可用的情况，后来增加了这个检查机制，在应用启动时就能发现问题。

3. 烘焙领域专用提示词工程

3.1 基础提示词模板

烘焙领域的提示词需要特别设计，这是我的经验模板：

String promptTemplate = """ 你是一位拥有20年经验的烘焙大师，擅长{0}类糕点制作。 请用{1}风格回答以下问题： 问题：{2} 回答时请注意： 1. 用量精确到克 2. 标明烤箱预热温度和时间 3. 分步骤说明操作要点 4. 常见失败原因及解决方法""";

实际使用示例：

String filledPrompt = MessageFormat.format(promptTemplate, "法式", "严谨专业", "如何制作可颂面包？"); ChatResponse response = chatClient.call( new Prompt(filledPrompt));

3.2 上下文记忆实现

烘焙咨询往往是多轮对话，需要实现上下文记忆：

public class BakingChatSession { private final List<Message> history = new ArrayList<>(); public String chat(String userInput) { history.add(new Message(userInput, Role.USER)); Prompt prompt = new Prompt(history); ChatResponse response = chatClient.call(prompt); Message assistantMessage = response.getResult().getOutput(); history.add(assistantMessage); return assistantMessage.getContent(); } }

这里有个性能优化点：大模型API通常按token计费，历史对话不宜过长。我的解决方案是：

1. 超过10轮后自动总结前面对话
2. 用总结内容替换原始历史
3. 保留最后3轮完整对话

3.3 结构化输出处理

让AI返回结构化数据便于前端展示：

@JsonFormat(shape = JsonFormat.Shape.OBJECT) public class BakingRecipe { private String title; private List<Ingredient> ingredients; private List<Step> steps; private String tips; } public BakingRecipe getStructuredRecipe(String query) { String jsonPrompt = """ 请将以下烘焙配方以JSON格式返回： {{ "title": "配方名称", "ingredients": [ {{"name":"材料名", "amount":"用量"}} ], "steps": ["步骤说明"], "tips": "注意事项" }} 问题：{0}"""; String response = aiClient.generate( MessageFormat.format(jsonPrompt, query)); return objectMapper.readValue(response, BakingRecipe.class); }

4. 性能优化与生产级部署

4.1 缓存策略实现

大模型API调用延迟较高，需要合理缓存：

@Cacheable(value = "bakingAnswers", key = "#question.concat(#style).hashCode()") public String getCachedAnswer(String question, String style) { return generateAnswer(question, style); }

缓存失效策略建议：

• 配方类：缓存1周
• 技术原理类：缓存1个月
• 实时数据（如天气影响）：不缓存

4.2 流式响应处理

长时间等待AI生成完整响应体验差，实现流式输出：

@GetMapping("/stream/recipe") public SseEmitter streamRecipe(@RequestParam String query) { SseEmitter emitter = new SseEmitter(30_000L); Prompt prompt = new Prompt(query); chatClient.stream(prompt) .subscribe( chunk -> { emitter.send(chunk.getResult().getOutput().getContent()); }, error -> emitter.completeWithError(error), emitter::complete ); return emitter; }

前端配合示例（JavaScript）：

const eventSource = new EventSource('/stream/recipe?query=如何制作马卡龙'); eventSource.onmessage = (e) => { document.getElementById('answer').innerHTML += e.data; };

4.3 负载测试与降级方案

使用JMeter进行压力测试时发现的问题及解决方案：

降级方案实现代码：

@HystrixCommand(fallbackMethod = "getBasicRecipe") public String getAIRecipe(String query) { // 正常AI调用逻辑 } public String getBasicRecipe(String query) { return cacheManager.getCache("fallbackRecipes") .get(query, String.class); }

5. 安全防护与内容审核

5.1 输入过滤机制

烘焙社区需要防范的恶意输入类型：

public class InputValidator { private static final Set<String> BLACKLIST = Set.of( "信用卡", "密码", "成人内容" /* 烘焙无关词汇 */); public void validate(String input) { if (input.length() > 500) { throw new IllegalArgumentException("输入过长"); } if (BLACKLIST.stream().anyMatch(input::contains)) { throw new SecurityException("包含敏感词汇"); } } }

5.2 输出内容审核

使用双保险审核策略：

1. 预定义合规检查规则（正则表达式示例）：

String[] RED_FLAGS = { "\\b(?:自杀|暴力)\\b", "[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,6}" // 邮箱 };

2. 调用内容审核API二次验证：

public boolean isSafeContent(String text) { return !Arrays.stream(RED_FLAGS) .anyMatch(pattern -> text.matches(pattern)) && moderationClient.moderate(text).isSafe(); }

5.3 用户反馈闭环

建立反馈机制持续优化：

@Transactional public void handleFeedback(Long answerId, boolean isHelpful, String comment) { AiAnswer answer = answerRepository.findById(answerId).orElseThrow(); answer.addFeedback(isHelpful); if (!isHelpful && StringUtils.hasText(comment)) { promptImprovementService.analyzeImprovement( answer.getPrompt(), comment); } }

我在实际运营中发现，用户对"面粉蛋白质含量"类专业问题的反馈最有价值，专门为此建立了知识库。

6. 进阶功能实现

6.1 多模态支持（图片识别）

处理用户上传的烘焙成果图：

public String analyzeBakingImage(MultipartFile image) { byte[] bytes = image.getBytes(); String base64Image = Base64.getEncoder().encodeToString(bytes); String prompt = """ 请分析这张烘焙图片： 1. 识别糕点类型 2. 评估烘烤程度（过生/正好/过火） 3. 给出改进建议 图片：{0}"""; return aiClient.generate( new Prompt(MessageFormat.format(prompt, base64Image))); }

6.2 本地模型部署方案

对于数据敏感场景，可使用Ollama部署本地模型：

# Dockerfile示例 FROM ollama/ollama RUN ollama pull llama3:8b EXPOSE 11434

SpringAI配置调整：

spring: ai: openai: base-url: http://localhost:11434 chat: options: model: llama3

6.3 成本监控仪表盘

重要指标监控实现：

@Scheduled(fixedRate = 3600000) public void logUsageMetrics() { Map<String, Double> metrics = Map.of( "avg_token_per_request", statsService.getAvgTokens(), "daily_cost", billingService.estimateDailyCost(), "error_rate", statsService.getErrorRate() ); metrics.forEach((k, v) -> meterRegistry.gauge("ai." + k, v)); }

我在Grafana中配置的告警阈值：

• 单日成本 > $50
• 错误率 > 5%
• 平均响应时间 > 8s

7. 实战问题排查记录

7.1 超时问题分析

错误现象：约15%的请求在10秒后超时

排查过程：

1. 确认不是网络问题（相同区域其他服务正常）
2. 检查API监控发现没有达到速率限制
3. 日志显示超时请求的prompt都包含图片base64
4. 发现base64编码未压缩

解决方案：

// 优化后的图片处理 String compressed = Base64.getUrlEncoder() .encodeToString(compressImage(imageBytes));

效果：超时率降至0.3%

7.2 内容质量问题

用户投诉：给出的配方用量不准确

根本原因：temperature参数设置过高（1.2）

验证实验：

最终采用动态temperature策略：

• 事实查询：0.3
• 创意建议：0.9
• 故障诊断：0.5

7.3 内存泄漏问题

现象：服务运行24小时后OOM

诊断步骤：

1. Heap dump分析显示ChatClient实例不断增长
2. 发现没有正确重用Bean实例
3. 检查出是@Scope配置错误

修复方案：

@Bean @Scope(proxyMode = ScopedProxyMode.NO) // 原先是DEFAULT public ChatClient chatClient() { return new OpenAiChatClient(openAiApi); }

8. 项目演进路线

当前架构的优化方向：

1. 知识库增强

   • 建立烘焙专业术语向量数据库
   • 实现RAG（检索增强生成）架构
   • 示例：用户问"水浴法"时，先检索专业解释再生成回答

2. 个性化推荐

   • 基于用户历史提问建立画像
   • 示例：对常问健康食谱的用户自动推荐低糖方案

3. 硬件加速

   • 使用NVIDIA Triton推理服务器
   • 测试数据：GPU加速可使本地模型推理速度提升8倍

4. 多模型路由

   • 根据问题类型自动选择最佳模型
   • 简单问答 → 小模型
   • 复杂创意 → 大模型

在实施这些改进时，我坚持的原则是：每次只做一个变更，通过A/B测试验证效果。比如在引入知识库后，我们跟踪了"专业术语问题"的准确率，从82%提升到了94%。