# FDE W7D1 评测题 · Spring AI 基础（ChatClient、Advisor、Structured Output）
> 对应手册：`FDE-W7D1-SpringAI基础-学习手册.html`
> 候选人背景：36 岁，Java + 大数据 + 医疗保险。回答请落到"Java 企业 AI 平台"能力，场景示例统一用「保险知识库 / 特药理赔 Agent」。
> 评分建议：每题按"考察点 + 评分维度"给分，L1/L2 答到要点即过，L3/L4 看深度与工程权衡。
---
## 一、L1 基础（概念辨识，4 题）
### 1. ChatClient 与 ChatModel 的关系是什么？业务代码应该面向谁编程？
- **考察点**：Spring AI 的核心抽象分层。
- **评分维度**：① 说清 ChatClient 是门面、ChatModel 是底层实现；② 业务只依赖 ChatClient；③ 能举例 QwenChatModel / DeepSeekChatModel 是可插拔实现。
参考答案
ChatClient 是面向应用层的统一对话门面，内部委托 ChatModel 实现（如 QwenChatModel、DeepSeekChatModel、AnthropicChatModel）。业务代码应只面向 ChatClient 编程，不依赖具体厂商 SDK，从而实现"换模型不改业务代码"。ChatModel 负责真正的协议适配与 HTTP 调用。
参考答案
Advisor 类比 Servlet Filter 或 Spring 的 HandlerInterceptor，是围绕一次对话请求的拦截器链。可在调用前后修改 prompt、做横切治理：日志审计、失败重试、限流、提示改写、注入会话记忆等。顺序由 order 控制，治理逻辑与业务解耦。
参考答案
依赖 JSON Schema 约束 + Jackson 反射：框架把 Java 类型（含 @JsonClassDescription / @JsonPropertyDescription）反射成 JSON Schema 注入 prompt 或 response_format，模型输出 JSON 后再反序列化为 Java 对象（BeanOutputConverter 机制）。本质是"类型 → schema → 输出 → 解析"，与 Python 侧 Pydantic 思路一致。
参考答案
需要。结构化输出只保证语法合法、字段/类型符合 schema（"形对"），不保证值语义正确（可能字段填"我不确定"、金额越界、超业务范围）。应叠加 Bean Validation（@NotNull/@Min/@Pattern）+ 业务规则校验 + 失败带反馈重试 + 降级兜底。
参考答案
```java
@JsonClassDescription("特药理赔审核结论")
public class ClaimDecision {
@JsonPropertyDescription("理赔是否成立") boolean approved;
@JsonPropertyDescription("拒赔原因，成立时为空") String rejectReason;
@JsonPropertyDescription("风险等级 low/medium/high") String riskLevel;
@JsonPropertyDescription("无法判断时为 true") boolean shouldRefuse;
}
ClaimDecision d = chatClient.prompt()
.user(u -> u.text("根据理赔材料给出结论：\n{claim}", claim))
.call().entity(ClaimDecision.class);
```
`@JsonClassDescription`/`@JsonPropertyDescription` 给 schema 加语义描述，显著降低模型瞎填率。解析失败要抛异常走重试/降级。
参考答案
实现 `Advisor` 接口：重写 `getOrder()` 定顺序，重写 `adviseCall(AdvisedRequest, CallAdvisorChain)` 在 `chain.nextAroundCall(req)` 前后计时。流式要同时实现 `adviseStream`，并且**必须透传 Flux**（在 Flux 上 map/doOnNext 埋点），不能 `collectList()` 提前聚合，否则失去流式且异常时拿不到部分结果。
参考答案
靠 ChatModel 抽象 + Spring Boot starter 自动装配。两种方式：(1) 配置切换——只改 `spring.ai.qwen.*` / `spring.ai.deepseek.*` 等配置或 profile，注入的 ChatModel 变化，ChatClient 不变；(2) 运行时多 bean——同时注入多个 ChatModel，上层按场景路由（简单问答走 Qwen、推理走 DeepSeek、长文走 Claude）。这正是 W7D4 Gateway 路由在应用层的对应物。
参考答案
① 厂商特有参数（如 Claude 必填 max_tokens、Qwen 的 thinking 开关）ChatClient 不自动抹平，需 `.with(ChatOptions)` 透传；② 切换后输出风格、JSON/结构化合规率会变，必须重新压测结构化成功率；③ "统一"不等于能力等价，长上下文、工具调用能力因模型而异，一个 prompt 未必通吃。
参考答案
W1 自研 Adapter：薄封装，手写 ModelRouter 统一 HTTP + 响应结构，可控性最高、开发慢。Spring AI：厚框架，提供 ChatClient/Advisor/记忆/工具/向量全套，开发快、受约定约束。
共存方式——**双栈分层**：W1 自研 Adapter 演进为企业 AI Gateway（接入层，做鉴权/路由/限流/成本/Trace）；Spring AI 在应用层做业务编排、Advisor 治理、结构化。两者互补不冲突，不是二选一。
参考答案
重试 Advisor 只应针对**传输层/限流错误**（网络抖动、HTTP 429），这类错误重试安全。对话请求本身非天然幂等（同 prompt 两次答案可能不同），对"答案不满意/格式错"盲目重发只是换一个随机结果，无效且浪费 token。格式/语义错误要用 W1 的"带反馈重试"——把校验错误喂回 prompt 让模型修正，而非无脑重发。
参考答案
① 多模型编排：Qwen 做意图识别、DeepSeek 做理赔推理、Claude 做长保单摘要，ChatClient 统一入口；② 治理内建：把审计、限流、敏感词脱敏做成平台级 Advisor，新 Agent 自动继承；③ 结构化兜底：理赔结论一律 `entity(ClaimDecision.class)` + Bean Validation + 降级，保证下游 Java 系统稳定消费，且 `shouldRefuse` 字段支撑"知识库无答案即拒答"；④ 可观测：Advisor 内埋 trace_id/model/token/延迟，接入现有 Kafka+数仓做成本与质量分析。突出"结论可校验、可拒答、可审计"的强约束场景能力。
参考答案
端到端方案：
- 定义 `ClaimDecision` Bean，含 `approved`、`shouldRefuse`、`clauseIds`（引用条款）、`rejectReason`，用 `@JsonPropertyDescription` 强化 schema；
- 用 `QuestionAnswerAdvisor` 或自建 RAG Advisor 注入保险知识库检索结果（在 Advisor 内完成向量检索，业务方法保持干净）；
- 调用 `call().entity(ClaimDecision.class)`，解析后做 Bean Validation + 业务校验（条款 id 是否存在、金额合理性）；
- 检测 `shouldRefuse==true` 或输出含"未找到" → 不当正常答案返回，转拒答流程；
- 失败带反馈重试 ≤3 次，超限降级（默认值/转人工）；全程 Advisor 埋 Trace。
达标线②要讲清：① Spring AI 如何靠 ChatModel 抽象 + starter 统一多模型（换配置即换模型）；② 与 W1 自研 Adapter 的取舍（薄网关 vs 厚框架，双栈互补）。
参考答案
结论：**两者都要，分层部署**。
- 接入层用自研 AI Gateway（W7D4 演进自 W1 Adapter）：统一做鉴权、Provider 路由、超时重试/Fallback、Token 成本统计、Trace Hook、简单限流——这些是**跨业务线横切治理**，Spring AI 管不到。
- 应用层用 Spring AI：业务编排、Advisor 内治理（日志/重试/记忆/RAG）、Structured Output。
- 限流/成本/审计归属 Gateway（全局配额、统一账单）；Trace 两层都有——Gateway 在 HTTP 出口记 trace_id/model/token，应用层 Advisor 记业务上下文与延迟，两者用同一个 trace_id 串联（呼应 W4、W7D3）。
理由：业务侧追求开发速度用框架，平台侧追求可控与统一治理来自研，互不替代。