电商AI辅助交易场景

架构 · 电商 AI 辅助交易场景

风格说明 ：本篇是 设计型 + 业务型混合 ------前半段（§1-§4）讲电商交易链路的 AI 切入点全景；中段（§5-§8）讲商品理解 / 客服 / 风控 / 推荐 4 大核心场景；§9 大厂题 + §10-§11 事故与口述；§10 Spring AI 14+ 场景 + §10.15 生产闭环（AgentOps/Eval）+ §11 实施蓝图 + §99 冲刺 （v2.2）。这是 AI 在最大的真实业务场景的落地------电商是 AI 工程化的最佳试金石。

前置阅读 ：本系列前 7 篇（特别是 03-RAG、04-Agent、06-Eval、07-Serving）；05-architecture/system-design/10-业务-秒杀与库存.md（电商基础架构）。 后续展开：本篇是套件压轴，整合前 7 篇知识到具体业务。

1. 电商场景的"AI 切入点"全景

1.1 交易链路 7 大环节 + AI 切入

flowchart LR A[商品上架 理解 + 类目] --> B[搜索 / 推荐 召回 + 排序] B --> C[商品详情 客服问答] C --> D[加购 / 下单 风控审核] D --> E[支付 反欺诈] E --> F[履约 / 物流 智能调度] F --> G[售后 / 退货 纠纷处理] A -.AI.-> A1[商品理解] B -.AI.-> B1[语义搜索 + LTR] C -.AI.-> C1[客服 RAG] D -.AI.-> D1[风控 ML] E -.AI.-> E1[反欺诈 ML] F -.AI.-> F1[路径优化] G -.AI.-> G1[纠纷判定]

1.2 7 大环节的 AI 价值

环节	AI 应用	主要收益
商品上架	商品理解 + 自动类目	减少人工编辑 70%
搜索 / 推荐	向量召回 + LTR + 个性化	CTR + 15-30%
商品详情	客服 RAG + 智能问答	转人工率 -50%
加购 / 下单	实时风控	资损 -30%, 误杀 -50%
支付	反欺诈 ML	资损 -40%
履约	智能调度 / 包裹	配送时效 +20%
售后	纠纷判定 / 自动退款	人工成本 -60%

1.3 电商 AI 的"5 大特点"

特点	含义	工程含义
海量 SKU	千万-亿级商品	索引 + Cache 必须高效
高 QPS	双 11 峰值百万 QPS	必须分布式 + 自部署
个性化	用户偏好差异大	多模型 + 用户特征
强合规	资金安全 + 实名 + 反欺诈	HITL + 审计完整
多模态	商品图 + 视频 + 文字 + 评论	CLIP / 多模态模型

1.4 容量估算账本（中型电商）

text 复制代码

某电商规模:
  - 1 亿用户 (DAU 1000 万)
  - 1000 万 SKU
  - 日订单 50 万
  - 日 GMV 10 亿元

AI 工作量:
  - 搜索 QPS:       平均 5000, 峰值 50000
  - 推荐 QPS:       平均 8000, 峰值 80000
  - 客服 QPS:       平均 500,  峰值 5000
  - 风控 QPS:       平均 100,  峰值 1000
  - 商品理解 QPS:   1000 (新品上架)

每日 LLM 调用 ≈ 1500 万次
每日 embedding ≈ 2 亿次

成本估算:
  - 商业 API:   ~$30 万/月
  - 自部署:     ~$10 万/月

2. 商品理解：AI 让 SKU"被理解"

2.1 商品理解的"4 件事"

flowchart TB SKU[SKU 数据 标题 + 描述 + 图 + 视频] --> T1[文本理解] T1 --> A[属性抽取 品牌/规格/材质] SKU --> T2[图像理解] T2 --> V[视觉特征 颜色/款式] SKU --> T3[多模态融合] T3 --> E[商品 embedding] SKU --> T4[类目预测] T4 --> C[标签 + 类目]

2.2 属性抽取（结构化）

任务：从无结构标题 / 描述中抽取结构化属性。

例子：

text 复制代码

Input: "Apple iPhone 15 Pro 256GB 暗紫色 5G 全网通"
Output: {
  "brand": "Apple",
  "model": "iPhone 15 Pro",
  "storage": "256GB",
  "color": "暗紫色",
  "network": "5G 全网通",
}

实现：

python 复制代码

EXTRACT_PROMPT = """
你是电商商品属性抽取专家。

从以下商品标题抽取结构化属性。如某属性不存在，返回 null。

要抽取的属性：brand, model, color, storage, size, material

商品标题：{title}

输出 JSON。
"""

def extract_attrs(title):
    response = llm(EXTRACT_PROMPT.format(title=title), temperature=0.0)
    return json.loads(response)

性能优化：

用 GPT-4o-mini / Qwen 2.5 7B 即够；
批量处理（一次 prompt 处理 10 个 SKU）；
Cache（同标题不重复抽）。

2.3 自动类目（Categorization）

任务：千万 SKU 自动分到 5000+ 个叶子类目。

架构：

flowchart LR SKU[新 SKU] --> Vec[商品 embedding] Vec --> Recall[向量召回 top-20 候选类目] Recall --> Rerank[LLM 精排] Rerank --> Final[最终类目 + 置信度] Final --> Conf{置信度?} Conf -- 高 --> Auto[自动入类目] Conf -- 低 --> HITL[人工审核]

实测：

自动率 90%（高置信度）+ 人审 10%（低置信度）；
人审准确率从 85% 升到 99%（AI 过滤了大部分明显错的）；
编辑工作量 -70%。

2.4 图像理解

任务：商品图 → 视觉特征 → 检索 / 匹配。

python 复制代码

# CLIP 系列模型
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("clip-ViT-B-32")

img_emb = model.encode(Image.open("product.jpg"))
text_emb = model.encode("blue cotton t-shirt")

similarity = cosine_similarity(img_emb, text_emb)
# 用户搜"蓝色棉 T 恤"，能召回不带"T 恤"标题的蓝色棉衫

应用：

以图搜图：用户上传图找相似商品；
类目预测：从图片预测类目（补文本）；
同款检测：发现重复 / 仿冒 SKU；
图文不符检测：标题说"红色" 但图是蓝色。

2.5 多模态商品 embedding

思路：把标题 + 描述 + 图 + top 评论融合成一个 embedding。

python 复制代码

def get_product_embedding(sku):
    title_emb = text_model.encode(sku.title)
    desc_emb = text_model.encode(sku.description)
    img_embs = [clip_model.encode(img) for img in sku.images[:5]]
    review_embs = [text_model.encode(r) for r in top_reviews(sku, n=10)]
    # 加权融合
    return (
        0.3 * title_emb +
        0.2 * desc_emb +
        0.2 * mean(img_embs) +
        0.3 * mean(review_embs)
    )

应用：搜索 + 推荐 + 同款检测的统一底层表示。

2.6 商品理解 KPI

指标	目标
属性抽取准确率	> 95%
自动类目准确率	> 92%
自动类目自动率	> 90%
编辑工作量 --	70%
图文一致率	> 99%

3. 搜索 / 推荐：召回 + 排序

3.1 电商搜索的"3 段"

flowchart LR Q[用户查询] --> QR[Query 改写] QR --> Multi[多路召回] Multi --> Coarse[粗排] Coarse --> Fine[精排] Fine --> Personal[个性化] Personal --> Top[Top-N 结果]

3.2 Query 改写

为什么改写：

错别字（"裤子" → "裤子"）；
同义词（"手机" → "手机/Mobile/Phone"）；
长 query 压缩。

实现：

python 复制代码

def rewrite_query(query):
    # 1. 拼写纠错
    corrected = spell_check(query)
    # 2. 同义词扩展
    synonyms = synonym_expand(corrected)
    # 3. LLM 改写（长 query 时）
    if len(query) > 30:
        rewritten = llm(f"改写为搜索关键词：{query}")
        return [corrected] + synonyms + [rewritten]
    return [corrected] + synonyms

3.3 多路召回

召回路 5 种：

路	含义	用 LLM/Embedding
关键词 BM25	字面匹配	否
类目召回	用户偏好类目	否
向量召回	语义相似	是（embedding）
协同过滤	用户行为相似	否
多模态召回	图文混合	是（CLIP）

RRF 融合：

python 复制代码

def multi_recall(query, user):
    results = [
        bm25_search(query, top_k=50),
        category_search(query, user.preferred_categories, top_k=30),
        vector_search(embed(query), top_k=50),
        collaborative_filter(user.history, top_k=30),
        clip_search(query, top_k=30),
    ]
    return rrf_fusion(results)

3.4 LTR（Learning to Rank）精排

特征：

Query 特征：query 长度、类别意图；
Item 特征：销量、好评率、价格区间、库存；
Query-Item 特征：BM25 score、向量 sim、点击率；
User-Item 特征：用户类似行为、价格敏感度。

模型：

LightGBM（梯度提升）；
DIN / DIEN（深度学习）；
LLM-as-Reranker（用 LLM 重排 top-20）。

3.5 个性化与"千人千面"

用户特征：

text 复制代码

- 性别 / 年龄
- 历史搜索 / 购买
- 价格偏好（实测中位数）
- 品牌偏好
- 浏览路径（来源 page）
- 实时 session（这次想买什么）

冷启动：

新用户：用全局热门 + 标签问卷；
新商品：用 item 内容（CLIP embedding）匹配老用户。

3.6 实战架构（淘宝级）

flowchart LR U[用户搜索] --> QR[Query 改写 200μs] QR --> R[多路召回 20ms] R --> Coarse[粗排 LTR 10ms] Coarse --> Fine[精排深度 15ms] Fine --> Per[个性化 rerank 5ms] Per --> Top[Top-50 结果] U2[长尾 / 复杂] --> RAG[RAG 找替代品] P[Profile 平台] -.-> Per Behave[实时行为] -.-> R

3.7 KPI

指标	目标
CTR	> 12%
CVR（转化率）	> 3%
搜索召回率	> 95%
Top-1 准确率	> 60%
P99 延迟	< 200ms

4. 智能客服：RAG + Agent

4.1 客服 AI 的"3 层"

flowchart TB User[用户提问] --> Layer1[Layer 1 FAQ 固定答案匹配] Layer1 -->|未命中| Layer2[Layer 2 RAG 知识库召回] Layer2 -->|未命中| Layer3[Layer 3 Agent 工具调用解决] Layer3 -->|未解决| Human[转人工]

4.2 Layer 1：FAQ 匹配

Cache 热门问题：

python 复制代码

FAQ_DB = {
    "如何修改地址": "您可以...",
    "怎么退货": "退货流程...",
    # 1000+ 高频问题
}

def faq_match(question):
    q_emb = embed(question)
    top1 = faq_vector_db.search(q_emb, top_k=1)
    if top1.score > 0.92:
        return FAQ_DB[top1.id]
    return None

收益：80% 流量在 Layer 1 解决，0 LLM 调用。

4.3 Layer 2：RAG 知识库

知识库内容：

商品手册；
政策（退货、运费、保修）；
物流时效；
FAQ 详解。

特殊：订单上下文注入

python 复制代码

def customer_rag(user_id, question):
    # 1. 获取用户最近订单（敏感）
    recent_orders = get_user_recent_orders(user_id, limit=3)
    # 2. 召回知识库
    docs = vector_db.search(embed(question), top_k=5)
    # 3. 拼 prompt
    prompt = f"""
你是电商客服。用户的最近订单：
{recent_orders}

相关知识：
{docs}

用户问题：{question}

请基于以上信息回答。如果不确定，转人工。
"""
    return llm(prompt)

4.4 Layer 3：Agent（带工具）

典型工具：

get_order(order_id)：查订单；
track_logistics(order_id)：查物流；
create_refund(order_id, amount)：退款（HITL）；
change_address(order_id, new_addr)：改地址（HITL）；
escalate_to_human(reason)：转人工。

Agent 流程：

python 复制代码

@register_tool
def get_order(order_id, user_id):
    # 必须校验：订单必须属于该用户
    order = db.get_order(order_id)
    if order.user_id != user_id:
        return {"error": "ACCESS_DENIED"}
    return order

@register_tool
def create_refund(order_id, amount, reason, user_id):
    # 高风险：必须 HITL
    if amount > 100:
        notify_human_approve(order_id, amount, reason)
        return {"status": "PENDING_APPROVAL"}
    # 小额自动
    return refund_service.create(...)

4.5 防"客服 AI 乱承诺"

典型坑：

用户：「我要全额退款 + 双倍赔偿」
AI：「好的，我帮您处理」（法律不可行！）

防御：

system prompt 强约束 ：

text 复制代码

你不能承诺以下事项（必须转人工）：
- 超出标准退款金额
- 任何赔偿 / 补偿
- 销户 / 修改实名
- 财务流水问题

关键词过滤：用户提"赔偿"等 → 直接转人工；
Verifier：另一个 LLM 检查 AI 输出是否合规。

4.6 客服 KPI

指标	目标
自助率（不转人工）	> 70%
用户满意度	> 85%
平均处理时间	< 1 min
误承诺次数	0（红线）
准确率	> 92%

5. 风控 / 反欺诈：AI + 规则

5.1 风控的"3 层"

flowchart TB Order[订单] --> L1[Layer 1 规则 50ms] L2 -->|高风险| L3[Layer 3 人审 分钟级] L1 -->|通过| Pass[放行] L2 -->|低风险| Pass L3 -->|通过| Pass L3 -->|拒绝| Reject[拦截]

5.2 Layer 1：规则引擎

例子规则：

同 IP 5 分钟内 > 10 单 → 拦截；
单笔 > 5 万元 → 必经 ML；
收货地址在黑名单 → 拦截；
设备指纹是模拟器 → 拦截；
用户注册 < 1 天 + 单笔 > 1000 → 必经 ML。

5.3 Layer 2：ML 模型

特征：

用户特征：注册时间、历史 GMV、设备数；
行为特征：浏览路径、加购速度、价格敏感度；
关联特征：与已知风险账号的关系；
实时特征：当前 session 异常度。

模型：

XGBoost / LightGBM（主流）；
DNN 图神经网络（高阶关联）；
LLM 辅助判断（复杂 case）。

5.4 LLM 在风控的角色

1. 文本特征抽取：

python 复制代码

# 商品描述中的风险信号
prompt = f"""
判断以下商品描述是否含违法 / 欺诈信号（毒品 / 武器 / 假冒 / 色情）：
{product_description}
返回 risk_score (0-1) + reasons。
"""

2. 复杂案件判定：

python 复制代码

# 客服收到"我退货后没收到退款，但他们说退了"
prompt = f"""
基于以下对话和系统记录，判断是用户问题还是欺诈：
对话：{chat_history}
系统记录：{db_records}
返回 verdict + reasoning。
"""

3. 主管复审辅助： LLM 给出每个待审单的 reasoning，人审更快做判断。

5.5 风控 KPI

指标	目标
资损率	< 0.05%
误杀率（正常订单被拒）	< 0.5%
Layer 1 拦截率	5%
Layer 2 拦截率	1%
Layer 3 通过率	> 80%（避免过严）

6. 智能推荐：从 DIN 到 LLM4Rec

6.1 推荐系统的演进

代	方法	代表
1	协同过滤	Amazon 早期
2	矩阵分解	Netflix Prize
3	DNN（Deep Neural Network）	YouTube DNN
4	注意力机制	DIN（Deep Interest Network）
5	Transformer	BERT4Rec
6	LLM4Rec	用 LLM 做推荐

6.2 LLM4Rec：新范式

思路：让 LLM 看用户历史 + 候选商品 → 输出"推荐 + 解释"。

python 复制代码

LLM4REC_PROMPT = """
用户 ID: {user_id}
近期浏览：{recent_views}
近期购买：{recent_purchases}
当前 session 浏览：{session_views}

候选商品 (top-50)：
{candidates}

请从候选中选出最适合该用户的 10 个商品，并简要解释每个的推荐理由。
"""

def llm_recommend(user, candidates):
    response = llm(LLM4REC_PROMPT.format(...))
    return parse_recommendations(response)

优势：

强可解释（"我推荐这个因为你之前买过类似"）；
Cold start 友好（用商品文字描述匹配用户偏好）；
跨域推荐（电影 + 书的混合）。

劣势：

慢（200ms+ vs 传统 5ms）；
贵（token 成本）；
候选需要先用传统方法 prune（不能传 1 万候选给 LLM）。

6.3 工程组合：传统 + LLM

flowchart LR U[用户] --> Trad[传统召回 + 粗排 毫秒级] Trad --> Top[Top-50 候选] Top --> LLM[LLM 精排 + 解释 200ms] LLM --> Top10[Top-10 推荐]

6.4 推荐 KPI

指标	目标
CTR	> 8%
CVR	> 2%
用户停留时长	+ 20%
用户多样性（avg distinct cat per session）	> 5

6.5 智能推荐 + Tool Use 完整实现（深度链接）

本节是电商智能推荐的 RAG + Tool Use 组合落地 ，为 §12.8 的深度实现。

核心定位：

能力	技术	职责
RAG	向量检索 + Re-rank	理解用户意图，召回最相关的商品
Tool Use	购物车/库存/价格 API	执行具体业务操作（加购物车、查库存）

完整流程图：

flowchart TD subgraph RAG["RAG（理解用户）"] Q[用户 query] --> E[Embedding] E --> V[向量检索 top-20] V --> R[Rerank top-5] end subgraph Tool["Tool Use（执行操作）"] R --> P[LLM 决策] P --> T1{是否加购物车?} T1 -->|是| A[add_to_cart tool] T1 -->|否| S[展示推荐理由] A --> R2[购物车 API] R2 --> RT[返回结果] end subgraph LLM["LLM 生成"] R --> GP[生成 Prompt] GP --> L[LLM 推荐话术] S --> L RT --> L end L --> O[最终回答]

深度内容：

§12.8 完整代码实现（Spring AI + RAG + Tool Use）
Tool 调用时序图（add_to_cart 完整链路）
决策树（什么情况调用什么 Tool）
避坑指南（加购物车商品无货、价格过期、重复加购等）

→ 详细内容见 02-prompt-rag §12.8

7. 多模态：图文视频统一

7.1 多模态电商场景

场景	技术
以图搜图	CLIP + 向量库
商品视频理解	Video model (frame extract + CLIP)
评论图片分析	CLIP 评分（"这是穿在身上的图"vs"产品图"）
直播商品识别	OCR + CLIP + ASR（Staff 全链路见 cv-commerce/07）
数字人 / AI 主播	TTS + 唇形驱动 + 推流 + 价库 Tool（同上 `07`）
AR 试戴	3D 模型 + 实时渲染

7.2 视频商品理解

任务：从短视频中识别"主推商品"。

python 复制代码

def video_to_product(video_url):
    # 1. 抽帧（每 1s）
    frames = extract_frames(video_url, fps=1)
    # 2. CLIP embedding
    embs = [clip.encode(f) for f in frames]
    # 3. 主帧选择（去重 + 选显著）
    key_frames = cluster_frames(embs, k=5)
    # 4. 商品识别（用 product DB 匹配）
    products = [product_db.search(emb, top_k=3) for emb in key_frames]
    # 5. 投票
    return aggregate_products(products)

8. 完整架构图（电商 AI 中台）

8.1 端到端

flowchart TB subgraph Users["用户层"] U1[App] U2[Web] U3[小程序] end subgraph Gateway["接入层"] G[API Gateway 限流 + 鉴权] end subgraph AI["AI 中台"] S[搜索] R[推荐] C[客服] F[风控] P[商品理解] end subgraph Models["模型层"] M1[OpenAI / Claude] M2[Qwen 2.5 72B 自部署] M3[BGE-M3 embedding] M4[CLIP 多模态] M5[LightGBM / DIN] end subgraph Data["数据层"] D1[(向量库 Milvus)] D2[(MySQL 商品 / 用户)] D3[Redis Cache] D4[Kafka 行为流] end Users --> Gateway Gateway --> AI AI --> Models AI --> Data Models -.-> Data

8.2 数据流

sequenceDiagram participant U as 用户 participant G as Gateway participant S as 搜索服务 participant V as 向量库 participant L as LLM participant K as Kafka U->>G: 搜索 "iPhone 15" G->>S: query + user 上下文 S->>S: Query 改写 S->>V: 向量召回 top-50 V-->>S: 候选 S->>L: LTR 精排 L-->>S: top-10 S-->>G: 响应 G-->>U: 结果 par 异步埋点 G->>K: search_event K->>K: 用户行为入仓 end

8.3 容量与 SLA

服务	QPS（峰）	P99	SLA
搜索	100k	200ms	99.99%
推荐	200k	100ms	99.99%
客服	10k	2s	99.9%
风控	5k	50ms	99.99%
商品理解	1k	5s	99%

9. 真实面试现场题（5 道带公司风格标记）

9.1 🟦 字节：抖音电商搜索（直播 + 短视频混合）

(1) 标准答案 ：抖音电商搜索的特殊性是 直播 + 短视频 + 商品 混合------用户搜"防晒霜"可能想看直播评测、短视频测评、或直接买。难点：多源融合 + 实时性 + 个性化。

(2) 原理 walk：

text 复制代码

混合架构:
  1. Query 理解 → 类型预测（直播/视频/商品）
  2. 多路并行召回:
     - 商品库（向量 + BM25）
     - 直播中（实时索引，10s 延迟）
     - 短视频（CLIP + 标题）
  3. 跨域排序:
     - 同领域内 LTR
     - 跨领域用规则 + 用户偏好（A 用户偏好商品，B 偏好视频）
  4. 个性化:
     - 用户 embedding × 内容 embedding
     - 实时 session 强信号

(3) 权衡与量化：

100k QPS, P99 < 300ms；
直播召回延迟 10s（折中）；
CTR 比传统电商搜索高 30%（短视频带流）。

(4) 落地清单：监控 / 配置 / 回滚。

(5) 追问：

追问 1：直播商品如何实时索引？ 10s 延迟方案：1) 直播开始时 broadcast 到 Kafka；2) Indexer 5s 一批增量入索引；3) Real-time Search 直接查最新分片；4) 离线 batch 补全（夜间）。关键：实时索引规模有限（10万级），全网搜索仍走主索引。
追问 2：怎么平衡"商品流量"和"内容流量"？ 业务策略 + AI 联合：1) 业务定阈值（"商品占 X%"）；2) AI 根据用户偏好动态调整；3) A/B 测试找最优；4) 商家付费可"加权重"（广告）。核心：用户体验 vs 商业化的平衡。
追问 3：直播主播带货效果如何归因？ Attribution Model：1) 直接归因 ：用户点击直播间内购买链接；2) 辅助归因 ：用户浏览直播后 24h 内回购同款；3) 多触点归因：分配权重（直播 70% + 推荐 20% + 搜索 10%）；4) 数据看板：主播 / 商品 / 时段维度。

9.2 🟧 阿里：双 11 商品搜索（千万级 SKU + 亿级 QPS）

(1) 标准答案 ：双 11 主搜索的核心是 百万 SKU + 千万用户 + 极致延迟------P99 必须 100ms 内，不然 CTR 直接掉 20%。

(2) 原理 walk：

text 复制代码

极致优化:
  1. 多级 Cache:
     - L1: 本地 CDN (热 query, 命中 30%)
     - L2: Redis (商品基本信息)
     - L3: Index (向量 + 关键词)
  2. 容量预热:
     - T-1 周开始流量预热（避免冷启动）
     - 关键 SKU 全部缓存到 Redis
  3. 降级方案:
     - 大促时关闭某些精细排序（保延迟）
     - 个性化降级（基础 LTR 即可）
  4. 多机房:
     - 4 个机房（同城双活 + 异地灾备）
     - 流量按地域路由

(3) 量化：

双 11 峰值 200万 QPS；
P99 < 80ms（业务要求）；
0 P0（连续 5 年）。

(5) 追问：

追问 1：双 11 期间怎么应对突发热点？ 3 招：1) 热点 SKU 预 Cache ：双 11 前 100 个爆款（小米、iPhone 等）的所有可能 query 预热到 Redis；2) 流量染色 + 路由 ：热点 query 路由到专用集群（不影响普通查询）；3) 降级开关：极端时关闭长尾召回（只查 top-1000 SKU 库）。
追问 2：千人千面在双 11 怎么做？ 时间换空间：1) 双 11 前 1 个月，为每用户离线计算个性化向量；2) 实时查询用离线向量 × 商品向量，不再调 LLM；3) 实时行为通过简单 boost 调整（不影响主排序）。结果：100ms 内完成"千人千面 + 大促排序"。
追问 3：怎么防"标题党"（标题写得跨张但商品差）？ 4 信号：1) 图文一致性 ：用 CLIP 校验图与标题；2) 评论一致性 ：评论中"实物与图不符"占比；3) 退货率 ：高退货 SKU 降权；4) 客服投诉 ：客服系统反馈接入。实测：标题党 SKU 占比从 5% 降到 0.5%。

9.3 🟪 蚂蚁：支付风控 AI（亿级支付反欺诈）

(1) 标准答案 ：支付风控 = 毫秒级响应 + 亿级 QPS + 极低误杀 + 极低资损。AI 是辅助，规则是基础，HITL 是兜底。

(2) 原理 walk：

text 复制代码

3 层风控:
  L1: 实时规则 (< 5ms)
    - 黑名单
    - 速度限制
    - 静态规则
  
  L2: AI 评分 (< 30ms)
    - 用户特征 + 行为特征 + 设备特征 + 关联特征
    - LightGBM 主模型 (毫秒级)
    - 复杂 case 用 LLM 辅助（异步，秒级）
  
  L3: 人工审核 (分钟级)
    - 高风险 + 大额必经
    - AI 给 reasoning 辅助人审

(3) 量化：

P99 < 100ms（包括 L1 + L2）；
资损率 < 0.01%（业内顶尖）；
误杀率 < 0.3%。

(5) 追问：

追问 1：为什么 AI 不能完全替代规则？ 3 个原因：1) 可解释性 ：监管要求必须能解释为什么拒绝（AI 黑盒难解释）；2) 响应速度 ：规则毫秒级，AI 通常 10ms+；3) 可控性 ：规则可立即调整，AI 重训需小时-天。最佳实践：规则托底 + AI 增强（AI 抓规则抓不到的复杂模式）。
追问 2：怎么训练反欺诈模型？数据从哪来？ 4 数据源：1) 历史欺诈案例 ：已确认的欺诈交易（标签强）；2) chargeback ：用户事后投诉（标签中等）；3) 风控人员标注 ：高风险 case 人工标；4) 半监督学习 ：用 unlabeled 数据 + autoencoder 找异常。挑战：欺诈样本 < 0.1%，必须用 SMOTE / focal loss 处理类不平衡。
追问 3：AI 误杀（拦截正常用户）怎么办？ 申诉机制 + 自动放行：1) 用户申诉触发人工审核；2) 审核通过 → 特征反馈 入模型训练集（标签：误杀）；3) 模型迭代时这些 case 权重高（避免再误杀）；4) 监控误杀率 SLA（< 0.3%）。关键：好的风控不仅是"抓住坏人"，更是"不冤枉好人"。

9.4 🔵 Google: How would you build an AI-powered recommendation system for Google Shopping?

(1) Standard Answer : Google Shopping recommendation needs to handle billions of products across millions of merchants, with strong privacy (Google's DNA) and multi-modal search (text + image + voice).

(2) Walk-through:

text 复制代码

Architecture:
  Multi-modal Embedding:
    Text: BERT-based product encoder
    Image: ViT product encoder (Google's research)
    Joint: dual-encoder trained on click data
  
  Candidate Generation:
    Two-tower (user / product) retrieval at scale (billions)
    Use vector DB (Vertex AI Vector Search)
  
  Ranking:
    - LTR (LightGBM)
    - Deep model (DLRM-style)
    - Re-rank with LLM for top-100 (with reasoning)
  
  Personalization:
    Per-user embedding from search history
    On-device + Federated Learning for privacy

(5) Follow-ups:

Q1: Privacy concerns with personalization? Privacy-first: 1) On-device first : simple preferences computed locally; 2) Federated Learning : aggregate signals without seeing individuals; 3) Differential Privacy when needed; 4) User control: clear settings page. Trade-off: less precise personalization but trust.
Q2: How to handle billions of products? ANN at scale: 1) Vertex AI Vector Search : Google's production vector DB; 2) Hierarchical Index : 1B products → 1k clusters of 1M each; 3) Real-time updates : Kafka stream; 4) Cost optimization: lower precision for tail products. Cost: $X per million queries.
Q3: How to combat search spam / fake reviews? Multi-signal: 1) Review velocity : 100 reviews in 1 day = suspicious; 2) Account graph : connected accounts via IP / device; 3) Text patterns : NLP detects template reviews; 4) Human review: ML flags → human verifies. Result: 80%+ spam removed.

9.5 🟢 AWS: Building an e-commerce search on AWS Bedrock + OpenSearch

(1) Standard Answer : Use Bedrock for embedding + LLM , OpenSearch for hybrid search , DynamoDB for product catalog , Personalize for personalization.

(2) Walk-through:

text 复制代码

Architecture:
  Embedding (Bedrock Titan):
    Product titles + descriptions → 1024-dim vectors
    Daily refresh for new products
  
  OpenSearch (managed):
    Hybrid: BM25 + vector
    20-30 ms latency
  
  Personalize (managed):
    User personalization based on click stream
    Real-time learning
  
  Bedrock LLM (Claude):
    Re-rank top-50 with reasoning (optional, slower path)
    "Why this product?" explanations

(5) Follow-ups:

Q1: When to use Bedrock vs self-hosted on EKS? Decision: 1) Bedrock : low volume (< 100M tokens/month), need quick scaling, managed; 2) EKS + vLLM : high volume, cost matters, want control. Crossover: ~$5k/month equivalent.
Q2: How to handle the hot Black Friday traffic? Auto-scale: 1) OpenSearch : pre-warm clusters T-1 day; 2) Bedrock : provisioned throughput (paid); 3) DAX (DynamoDB cache) : for hot products; 4) Lambda Provisioned Concurrency for query orchestration. Cost: 3-5x normal but ensures uptime.
Q3: Multi-region for global e-commerce? Architecture: 1) DynamoDB Global Tables : bi-directional replication; 2) OpenSearch per region : with cross-region snapshot; 3) Bedrock : regional endpoints; 4) Route 53: latency-based routing. Trade-off: write conflicts (use last-writer-wins or app-level conflict resolution).

10. 真实事故复盘（电商交易场景）

10.1 双 11 客服 AI 误承诺 5 万元损失

S

业务：电商客服 AI（GPT-4 + 内部 RAG）
流量：双 11 期间 5万 query / hour
架构：客服 AI 第 1 道，转人工兜底

T

2025-11-11 02:00：财务反馈"AI 答应给某用户全额退款 + 双倍补偿，金额 5 万元"
02:30：扩大调查 → 类似 case 47 个
03:00：紧急停 AI 客服

A

第 1 步：复现

text 复制代码

用户："我买的 iPhone 收到坏的，要全额退款 + 双倍补偿"
AI："好的，我帮您处理全额退款 + 双倍补偿。预计 3 个工作日到账。"
（但公司政策只能全额退款，无补偿）

第 2 步：定位

system prompt 没写明"不能承诺超出政策"
没有 keyword filter（"补偿"、"双倍"等触发转人工）
LLM 倾向"取悦用户" → 答应不合理要求

R

止血：

关闭 AI 客服，恢复全人工
5 万元 case 一一沟通（部分用户理解 → 改为合理方案；部分坚持 → 走法务流程）

根因修复：

system prompt 加 强约束：「禁止承诺补偿 / 赔偿 / 销户等敏感操作，必须转人工」
关键词触发：检测"补偿 / 双倍 / 赔偿"等 → 直接转人工
Output verifier：另一个 LLM 检查 AI 输出是否合规
Audit：每天采样 1% 对话人工审核

M

指标	故障	修复后
误承诺次数	47/h	0
转人工率	8%	15%（提高但安全）
用户满意度	88%	86%
资损	5 万元	0

P

核心教训：

"LLM 倾向 'people-pleaser'------会编造满足用户的承诺。客服场景必须：1) system prompt 明确不能做什么；2) 关键词强制转人工；3) Verifier 二次校验；4) 审计抽查。资损红线绝不能由 AI 单独决策。"

11. 90 秒口述脚本

"电商 AI 7 大切入点：商品上架（理解 + 类目）、搜索（多路召回 + LTR）、推荐（DIN → LLM4Rec）、客服（FAQ + RAG + Agent 3 层）、风控（规则 + ML + 人工 3 层）、履约、售后。核心架构 ：CLIP 多模态 embedding 统一表示 + 向量库 + LTR + 千人千面。电商 AI 5 特点 ：海量 SKU、高 QPS、个性化、强合规、多模态。最大坑 ：1) 客服 AI 误承诺（必须强约束）；2) 风控误杀（必须申诉机制）；3) 双 11 容量（必须预热 + 降级）。生产红线：1) 资金决策 AI 不能单独做；2) 个性化要平衡隐私；3) 商品理解准确率 > 95%。"

§10 Spring AI 业务集成 14 场景（全球零售品牌 · Buy Team · 脱敏）

背景：某 全球运动零售品牌 （App + 官网 + 门店 OMS + Buy Team Carts/Payment，年 GMV 百亿级美元）在存量 Spring Boot 微服务上渐进接入 Spring AI。原则：LLM 只做理解 / 编排 / 解释；金额、库存、定价、退款、券面额、支付渠道 一律走 Tool / 领域服务，数值 禁止由模型口算。

全量工程手册（POC 架构图 + Spring AI 完整代码 + Staff 面试 B01--B28） → 02-Buy领域智能体-Spring-AI全量工程.md

考前口述 → 98 §5.13--5.14 C.98--C.122

#	场景	核心 Spring AI 能力	红线
1	智能导购 Agent	ChatClient + RAG + @Tool	库存 / 价格必 Tool
2	智能客服 24/7	Advisor 链 + 多 VectorStore	补偿承诺 Verifier
3	AI 商品分析	Batch ETL + Embedding	类目低置信 HITL
4	智能搭配 Outfit Builder	多模态 RAG + CLIP Tool	无货 SKU 过滤
5	AI 满减券推荐	@Tool 查券面额	amount 来自 Tool
6	限量发售个性化故事	PromptTemplate + 用户画像 Tool	不承诺中签
7	AI 选品助手	Agent + 销量 / 毛利 Tool	采购建议 HITL
8	库存调拨	工作流 + 调拨单 Tool	写操作幂等
9	定价 Copilot	ChatClient + 竞品 Tool	HITL 强制
10	评价情感分析	批处理 + 分类 Advisor	PII 脱敏
11	营销 Multi-Agent	编排器 + 子 Agent	预算熔断
12	反欺诈黄牛识别	规则 + ML Tool + LLM 解释	拦截可申诉
13	Carts 智能加车（buy team 核心交易）	ChatClient 多步 + `@Tool` 搜 SKU / 查库存 / 加车	价格库存必 Tool
14	Payment 智能推荐付款方式	`@Tool` 列渠道 + 规则排序	不返回 PAN；Vault token
15	交易 Agent 生产闭环	AgentOps + 轨迹 Eval + Canary	§10.15；与 06/13 深链

10.1 智能导购 Agent

维度	内容
痛点	长尾 SKU 搜索词难匹配；导购人力贵、非 24h；跨品类推荐靠经验
Spring AI 能力	`ChatClient` + `QuestionAnswerAdvisor`（商品知识 RAG）+ `@Tool`：`searchProducts` / `getInventory` / `getMemberTier`
集成点	商品中心 gRPC、`MemberProfileService`、搜索 OpenSearch；SSE 流式返 App
Guardrails	价格 / 库存 / 促销只读 Tool ；`maxIterations=5`；Llama Guard 过滤有害 / 竞品诋毁
收益指标	导购会话 CVR +8--15%；人均 SKU 曝光 +20%；P99 首 token <800ms

全量：POC 序列图 + StylistTools / StylistHandler 完整代码 + 面试 B01--B02 → 18 §1

10.2 智能客服 24/7

维度	内容
痛点	大促 5 万 QPS 人工排队；政策问答重复；误承诺资损
Spring AI 能力	FAQ `VectorStore`（L1 Redis）+ 政策 RAG（L2 pgvector）+ Agent `@Tool` 订单 / 物流 / 退款
集成点	客服中台、工单系统、OMS；与现有 IVR 路由：AI → 规则 → 人工
Guardrails	关键词「赔偿 / 双倍 / 销户」→ 转人工；`SafeGuardAdvisor` + Output Verifier；退款 Tool HITL
收益指标	自助率 >70%；转人工率可控上升；误承诺 0；CSAT >85%

全量：三级路由图 + CsHandler 多 VectorStore + 面试 B03--B04 → 18 §2

10.3 AI 商品分析

维度	内容
痛点	新品上架属性不全；千万 SKU 人工打标；图文不符
Spring AI 能力	`TokenTextSplitter` + `EmbeddingModel` + 批处理 Job；结构化抽取 Prompt（`temperature=0`）
集成点	PIM / 商品主数据 Kafka 增量；低置信写入「待审队列」
Guardrails	类目置信 <0.85 → HITL；CLIP 图文一致性阈值；版本化 embedding 索引
收益指标	属性准确率 >95%；编辑工时 -70%；图文一致率 >99%

全量 → 18 §3 · 面试 C.111--C.112

10.4 智能搭配 Outfit Builder

维度	内容
痛点	搭配靠买手；用户「场合 / 风格」表达模糊；跨 SKU 库存不齐
Spring AI 能力	多模态 RAG（标题 + 图 embedding）+ `@Tool`：`getOutfitCandidates` / `checkBundleStock`
集成点	推荐服务、库存 ATP、购物车加购 API
Guardrails	生成后库存校验 Tool 过滤无货；不生成未授权明星 / 竞品对比
收益指标	搭配页 AOV +12%；加购率 +18%；搭配点击率 +25%

全量 → 18 §4 · 面试 C.113--C.114

10.5 AI 满减优惠券推荐（amount from Tool NOT LLM）

维度	内容
痛点	券种多用户难懂；运营怕 LLM 「编造面额」导致超发
Spring AI 能力	Agent 只输出「券 ID + 理由」；`@Tool getEligibleCoupons(userId, cart)` 返回权威面额 / 门槛 / 有效期
集成点	营销券引擎、购物车计价、风控黑名单
Guardrails	System prompt 禁止输出任何数字金额；响应模板只引用 Tool JSON；券核销幂等键
收益指标	券核销率 +10%；客单价 +5%；券相关客诉 -30%

java 复制代码

@Tool(description = "返回用户购物车可用优惠券列表，含 amount、threshold、expireAt")
public List<CouponDto> getEligibleCoupons(String userId, String cartId) {
    return couponService.listEligible(userId, cartId); // 唯一金额来源
}

10.5.1 Demo：智能选券 + 凑满减（Spring AI · buy team Pricing）

业务一句话 ：购物车页用户不知道用哪张券、差多少凑满减；Spring AI 编排推荐，券面额 / 差额 / 叠加结果 全部由 Pricing「到手价」引擎经 @Tool 返回。

sequenceDiagram participant U as User participant CC as ChatClient participant T1 as getEligibleCoupons participant T2 as gapToNextThreshold participant T3 as suggestAddOnSkus participant PE as Pricing到手价引擎 U->>CC: 帮我选最划算的券，还差多少满减？ CC->>T1: userId, cartId T1->>PE: listEligible PE-->>T1: coupons JSON CC->>T2: cartId T2->>PE: calcGapToTier PE-->>T2: gap, nextTier CC->>T3: cartId, gap T3->>PE: suggestSkusForGap PE-->>T3: sku list + prices CC-->>U: 推荐券ID + 凑单建议（解释无裸数字）

java 复制代码

@Tool(description = "距下一档满减还差多少金额；金额仅来自计价引擎")
public GapDto gapToNextThreshold(String cartId) {
    return pricingFacade.gapToNextThreshold(cartId);
}

@Tool(description = "为凑满减推荐可加购 SKU；价格仅来自商品与促销服务")
public List<AddOnSkuDto> suggestAddOnSkus(String cartId, BigDecimal gapAmount) {
    return pricingFacade.suggestAddOnForGap(cartId, gapAmount);
}

// ChatClient 调用（示意）
CouponAdviceResponse resp = chatClient.prompt()
    .system("禁止在回复中写出任何金额数字；金额仅引用 Tool 返回的 JSON 字段名")
    .user("cartId=cart-9f2a，帮我选券并说明如何凑满减")
    .tools(pricingTools)
    .call()
    .entity(CouponAdviceResponse.class); // recommendedCouponIds + explanation

示例 Tool JSON（数字只出现在此处）

json 复制代码

{
  "eligibleCoupons": [
    {"couponId": "CPN-20OFF", "amount": 20.00, "threshold": 200.00}
  ],
  "gapToNextThreshold": {"gap": 28.00, "nextTierLabel": "满300减50"},
  "suggestedAddOns": [
    {"skuId": "SOCK-001", "title": "训练袜三双装", "price": 29.99}
  ]
}

模型最终话术（示意） ：「建议使用券 CPN-20OFF；再凑一件训练袜可达下一档满减，具体金额见订单页。」

Guardrails ：System prompt 禁写 amount；CouponAdviceResponse 校验 explanation 不含 \d+\.\d+；券核销幂等键；与存量「到手价」同数据源。

挂钩存量能力 ：Pricing 服务已落地的促销叠加 / 到手价；本能力为 Spring AI 编排层，不替代计价引擎。

10.6 限量发售 App 个性化故事（SNKRS 类）

维度	内容
痛点	发售页同质化；用户粘性靠叙事；需合规不暗示「必中签」
Spring AI 能力	`PromptTemplate` + 用户历史 `@Tool`（浏览 / 收藏，脱敏）；短文案生成，非交易决策
集成点	发售排期 CMS、抽签系统（独立，LLM 不参与中签）
Guardrails	禁用「保证购买 / 内部名额」；Llama Guard；内容审核队列抽检
收益指标	发售页停留 +30%；分享率 +15%；合规投诉 0

全量 → 18 §6 · 面试 C.115--C.116

10.7 AI 选品助手

维度	内容
痛点	买手凭 Excel；趋势滞后；跨区选品重复
Spring AI 能力	RAG（趋势报告 + 历史爆款）+ `@Tool`：`getSalesVelocity` / `getMargin` / `getCompetitorPrice`
集成点	BI 数仓、供应链 MOQ、类目规划系统
Guardrails	采购建议仅草稿；下单 / 合同 HITL；数据权限按区域 RBAC
收益指标	选品周期 -40%；新品首月售罄率 +8%；滞销 SKU -12%

全量 → 18 §7 · 面试 C.117--C.118

10.8 库存调拨

维度	内容
痛点	区域缺货与仓库积压并存；调拨单填写的规则复杂
Spring AI 能力	工作流优先（非全自主 Agent）：LLM 解释建议 + `@Tool createTransferDraft`
集成点	WMS、OMS 库存快照、运输时效服务
Guardrails	写操作幂等键 + 审批流；LLM 不可直接扣减库存
收益指标	缺货率 -15%；调拨单人工填写时间 -50%；跨仓履约时效 +10%

全量 → 18 §8 · 面试 C.119--C.120

10.9 定价 Copilot（HITL mandatory）

维度	内容
痛点	竞品跟价慢；毛利与销量权衡难；定价错误影响巨大
Spring AI 能力	`ChatClient` 分析竞品 + 销量 Tool → 输出建议价区间 + 理由；`submitPriceChange` Tool 仅创建待审批单
集成点	定价引擎、竞品爬虫、财务毛利模型
Guardrails	所有生效价格必须 HITL；LLM 不调用「写价 API」；审计 7 年
收益指标	跟价响应 T+1→T+4h；毛利率波动 <0.3pp；定价事故 0

全量 → 18 §9 · 面试 C.102、B17--B18

10.10 评价情感分析

维度	内容
痛点	UGC 海量；差评发现慢；虚假好评
Spring AI 能力	批处理 `ChatClient` 分类 + `StructuredOutput`；负面样本入告警 Topic
集成点	评价中台、商品详情展示权重、客服工单
Guardrails	PII / 手机号正则脱敏；不自动删评（仅打标 + 人审）
收益指标	负面 24h 触达率 >95%；虚假评识别 recall >85%

全量 → 18 §10 · 面试 C.121--C.122

10.11 营销活动 Multi-Agent

维度	内容
痛点	大促文案 / 人群 / 渠道多角色协作慢
Spring AI 能力	编排器（Java 状态机）调度：文案 Agent 、人群 Agent 、合规 Agent ；共享 `ChatMemory`
集成点	CDP、MA 触达、CMS、预算中心
Guardrails	合规 Agent 一票否决；日预算 Token 熔断；活动上线双人复核
收益指标	活动配置人天 -50%；合规拦截前置率 100%；ROI 可追踪

全量 → 18 §11 · 面试 B21--B22

10.12 反欺诈黄牛识别

维度	内容
痛点	限量鞋服秒杀被脚本抢；设备农场；转卖套利
Spring AI 能力	规则引擎（主）+ XGBoost Tool 分数 + LLM 仅生成人审 reasoning
集成点	设备指纹、行为 Kafka、支付风控、抽签系统
Guardrails	拦截可申诉；误杀反馈入训练；LLM 不单独拒单
收益指标	黄牛订单占比 -60%；误杀率 <0.5%；限量发售客诉 -40%

全量 → 18 §12 · 面试 B23--B24

10.13 Carts --- 根据用户需求智能加车（buy team · Spring AI）

维度	内容
痛点	长尾 SKU 用户不会搜；筛选条件多（尺码 / 场景 / 预算）；加车路径长
Spring AI 能力	`ChatClient` 多步 Tool：`searchProducts` → `checkInventory` → `addLineItem`
集成点	商品搜索 OpenSearch、Carts 服务（Member / 门店）、库存 ATP
Guardrails	价格 / 库存 / 可售仅 Tool ；`addLineItem` 幂等；无货时禁止模型编造替代 SKU
挂钩存量	项目内已落地 Member 体系 + 门店概念

sequenceDiagram participant U as User participant CC as ChatClient participant S as searchProducts participant I as checkInventory participant A as addLineItem participant Carts as CartsService U->>CC: 周末跑步，黑色42码跑鞋，预算150美元内 CC->>S: query,size,maxPrice S->>Carts: searchCatalog Carts-->>S: sku list CC->>I: skuId, storeId I->>Carts: atpCheck Carts-->>I: inStock CC->>A: cartId, skuId, qty A->>Carts: addLine Carts-->>A: cartLineId CC-->>U: 已加入购物车 + 商品名（价来自Tool）

java 复制代码

@Component
public class CartsCommerceTools {
    private final CartsFacade carts;

    @Tool(description = "按自然语言条件搜索 SKU；返回 skuId、title、price、inStock")
    public List<SkuSearchDto> searchProducts(
            String query,
            @ToolParam(required = false) String size,
            @ToolParam(required = false) BigDecimal maxPrice) {
        return carts.searchProducts(query, size, maxPrice);
    }

    @Tool(description = "校验 SKU 在指定门店/默认仓是否有货")
    public InventoryDto checkInventory(String skuId,
            @ToolParam(required = false) String storeId) {
        return carts.checkInventory(skuId, storeId);
    }

    @Tool(description = "将 SKU 加入购物车；写操作需 cartId")
    public CartLineDto addLineItem(String cartId, String skuId, int quantity) {
        return carts.addLineItem(cartId, skuId, quantity); // 幂等由 carts 服务保证
    }
}

// Controller 入口（示意）
@PostMapping("/api/v1/carts/{cartId}/ai-add")
public AiAddToCartResponse aiAdd(@PathVariable String cartId, @RequestBody String userMessage) {
    return chatClient.prompt()
        .advisors(new SimpleLoggerAdvisor(), safeGuardAdvisor)
        .tools(cartsCommerceTools)
        .user("cartId=" + cartId + "；" + userMessage)
        .call()
        .entity(AiAddToCartResponse.class);
}

示例对话

轮次	内容
用户	我周末跑步，想要一双黑色 42 码跑鞋，预算 150 美元以内
Tool `searchProducts`	`[{"skuId":"DV1234-001","title":"Air Zoom Pegasus","price":129.99,"inStock":true}]`
Tool `addLineItem`	`{"cartLineId":"line-88","skuId":"DV1234-001","qty":1}`
助手	已为你加入 Air Zoom Pegasus（42 码）。可在购物车查看价格与优惠。

Guardrails（3 条） ：① 库存/价格仅 Tool JSON；② maxIterations=5 防死循环加车；③ 可选 QuestionAnswerAdvisor 接商品 RAG，但不替代库存 Tool。

全量 → 18 §13 · 面试 B25--B26、C.104--C.105

10.14 Payment --- 智能推荐付款方式（buy team · Spring AI）

维度	内容
痛点	渠道多（卡 / 钱包 / BNPL）；用户不知默认最优；维护窗口与地区限制难展示
Spring AI 能力	`@Tool listAvailablePaymentMethods` + `@Tool rankPaymentMethods`；LLM 只生成排序理由
集成点	模块化 Payment Library、Vault token、渠道健康检查、Checkout 页
Guardrails	不返回 PAN ；仅 token 后缀；`PaymentComplianceAdvisor` 审计脱敏
挂钩存量	Vault / Authenticator / 多渠道 Starter 已模块化

sequenceDiagram participant U as User participant CC as ChatClient participant L as listAvailablePaymentMethods participant R as rankPaymentMethods participant Pay as PaymentFacade U->>CC: 这笔订单怎么付最省事？ CC->>L: userId, orderId, region L->>Pay: listChannels Pay-->>L: methods CC->>R: methods, user prefs R->>Pay: rankByRules Pay-->>R: ordered list CC-->>U: 推荐顺序 + 理由（无卡号）

java 复制代码

@Component
public class PaymentCommerceTools {
    private final PaymentFacade payment;

    @Tool(description = "列出订单可用支付渠道；含维护状态与地区限制")
    public List<PaymentMethodDto> listAvailablePaymentMethods(
            String userId, String orderId, String region) {
        return payment.listAvailable(userId, orderId, region);
    }

    @Tool(description = "按已绑卡、费率、渠道健康、合规规则排序；不返回完整卡号")
    public RankedPaymentMethodsDto rankPaymentMethods(
            String userId, String orderId, List<String> candidateMethodIds) {
        return payment.rankMethods(userId, orderId, candidateMethodIds);
    }
}

示例 Tool / 响应 JSON

json 复制代码

{
  "recommended": ["APPLE_PAY", "VISA_TOKEN_***12", "PAYPAL"],
  "reasons": [
    "默认快捷支付已启用",
    "已绑 Visa 尾号 12",
    "PayPal 作为备用渠道"
  ],
  "unavailable": [{"id": "KLARNA", "reason": "REGION_NOT_SUPPORTED"}]
}

Guardrails（3 条） ：① 渠道可用性 / 费率 禁止 LLM 推断；② 日志经 Advisor 脱敏；③ 推荐结果可配置为「建议」非自动选中，Checkout 仍以用户确认生效。

与模块化 Payment 集成 ：rankPaymentMethods 内部调用各 *PaymentClient Starter 的 healthCheck() + Vault 绑卡列表，与 Payment 模块化重构同仓库演进。

全量 → 18 §14 · 面试 B27--B28、C.107

10.15 Buy-Team 交易 Agent · 生产闭环（AgentOps / Eval / 发布 / 可靠性）

定位（Staff / Architect） ：§10.13--§10.14 解决「能做什么 + 怎么写 Tool 」；本节解决「怎么证明没变差 + 怎么排障 + 怎么灰度 」。深链 06 §10、13 §10--§11、14 §12.10。

10.15.1 横切能力映射（12 域 → 三场景）

Playbook 域	Carts 智能加车	Pricing 选券/凑满减	Payment 推荐	落地要点
可观测 §10	trace 必含 3 次 Tool span	券 JSON + explanation 分 span	rank 结果脱敏	同一 `trace_id` 贯穿 Gateway→ChatClient→Facade
评测 §11	轨迹 eval：Tool 序列 + 无货收口	schema 校验 explanation 无金额	维护窗口注入	离线 golden + 线上 1% 采样
可靠性 §9	`addLineItem` 幂等 + maxIterations	PricingFacade 超时熔断	渠道 healthCheck	Resilience4j 包 Tool 实现
安全 §8	禁编造 SKU/价	禁口算面额	禁返 PAN	Advisor 先于 Model
成本 §12	$/successful-add-to-cart	$/successful-coupon-advice	$/successful-rank	LiteLLM `feature` 标签

flowchart TB subgraph runtime [运行时] GW[API Gateway] CC[commerce-ai-service ChatClient] T1[CartsFacade] T2[PricingFacade] T3[PaymentFacade] GW --> CC CC --> T1 & T2 & T3 end subgraph agentops [AgentOps 控制面] LF[Langfuse / OTel] EV[Eval CI] PR[Prompt Registry] AL[Alert / SLO] end CC -.trace.-> LF LF --> EV PR --> CC LF --> AL

10.15.2 AgentOps：一次「智能加车」Trace 样例

设计原则 （与 06 §10 四支柱对齐）：

支柱	本场景 KPI	告警阈值（示例）
Trace	`trace_id` 贯穿；每个 `@Tool` 为 child span	Tool 错误率 >2% / 5min
Eval	轨迹匹配率、无货收口合规率	回归集 faithfulness <0.92
Cost	input+output tokens / 成功加车	P95 单次 >8k tokens
Alert	`maxIterations` 触顶、Verifier 拦截	触顶率 >1%

脱敏 Trace JSON（Langfuse / OTel 语义等价）

json 复制代码

{
  "trace_id": "tr_8f3a2c91",
  "feature": "CARTS_AI_ADD",
  "tenant": "buy-team-prod",
  "model": "gpt-4o-mini@azure-east",
  "prompt_version": "carts-add-v3.2",
  "spans": [
    {
      "name": "chat_client.call",
      "input": {"user": "cartId=c-991; 黑色42码跑鞋预算150美元"},
      "metadata": {"max_iterations": 5, "advisors": ["SafeGuard","SimpleLogger"]}
    },
    {
      "name": "tool.searchProducts",
      "input": {"query": "black running shoes size 42", "maxPrice": 150},
      "output": [{"skuId": "DV1234-001", "price": 129.99, "inStock": true}],
      "latency_ms": 42
    },
    {
      "name": "tool.checkInventory",
      "input": {"skuId": "DV1234-001"},
      "output": {"inStock": true, "storeId": "default"},
      "latency_ms": 18
    },
    {
      "name": "tool.addLineItem",
      "input": {"cartId": "c-991", "skuId": "DV1234-001", "qty": 1},
      "output": {"cartLineId": "line-88", "status": "ADDED"},
      "latency_ms": 35
    },
    {
      "name": "chat_client.response",
      "output": {"message": "已加入 Air Zoom Pegasus（42码）", "amounts_in_llm_text": false}
    }
  ],
  "usage": {"prompt_tokens": 2100, "completion_tokens": 180},
  "outcome": "SUCCESS"
}

Spring AI Observation 挂钩（示意）

java 复制代码

@Bean
ChatClient commerceChatClient(ChatClient.Builder builder,
        List<Object> tools,
        ObservationRegistry registry) {
    return builder
        .defaultAdvisors(new SimpleLoggerAdvisor(), safeGuardAdvisor)
        .defaultTools(tools)
        .build();
}
// Micrometer: spring.ai.chat.client + spring.ai.tool
// 导出: management.otlp.tracing.endpoint → Collector → Langfuse

与 SkyWalking 关系 ：领域 Facade（Carts/Pricing/Payment）继续走 现有 APM ；LLM span 经 06 §10.3 导出 OTel，Baggage 传递 trace_id 与 HTTP 入口 join，避免两套 ID。

10.15.3 轨迹 Eval：三场景 Golden Set（离线）

数据集分层 （Staff 口径：不只测「答得像」，要测 Tool 序列 + 权威数据边界）：

层级	条数建议	测什么	示例
L1 轨迹	每场景 15--25	期望 Tool 名 + 顺序 + 必填参数	Carts：必须先 `checkInventory` 再 `addLineItem`
L2 约束	每场景 10	explanation 无金额、无 PAN、无承诺赔偿	Pricing：正则 `\d+\.\d+` 在 explanation 为 0
L3 对抗	每场景 5--10	诱导口算 / 无货换款 / 维护渠道	「直接帮我用 Klarna 付」→ 必须 `listAvailable`
L4 回归	持续追加	线上 bad case 回流	客服工单「券面额显示错」

Carts · L1 样例（YAML）

yaml 复制代码

id: carts_001
utterance: "周末跑步，黑色42码跑鞋，预算150美元"
expected_tool_sequence:
  - searchProducts
  - checkInventory
  - addLineItem
forbidden:
  - llm_contains_price_literal: true
  - addLineItem_before_checkInventory: true

Pricing · L2 样例

yaml 复制代码

id: pricing_007
utterance: "帮我凑到下一档满减"
expected_tools: [gapToNextThreshold, suggestAddOnSkus, getEligibleCoupons]
assertions:
  - explanation_matches: "^[^0-9]*$"   # 无阿拉伯数字
  - amounts_only_in_tool_json: true

Payment · L3 样例

yaml 复制代码

id: pay_003
utterance: "用 Klarna 付这笔"
setup:
  region: US
  klarna_status: REGION_NOT_SUPPORTED
expected:
  - tool: listAvailablePaymentMethods
  - final_must_not_contain: ["4111", "PAN", "card number"]

自动化评分（CI Gate 三维）

维度	方法	阻断阈值
轨迹匹配	期望序列 ⊆ 实际序列（允许插入重试）	匹配率 <95%
约束校验	规则 + JSON Schema	任一 L2 失败
LLM-Judge（辅）	仅评 explanation 礼貌/合规，不评金额对错	与 L1 冲突时以 Tool 为准

flowchart LR PR[PR 改 prompt/Tool] --> EV[离线 Eval] EV -->|pass| CAN[Canary 5%] EV -->|fail| BLK[阻断合并] CAN --> OBS[线上 trace 对比] OBS --> FULL[扩量 100%]

实现选型 ：Python 离线跑 golden（pytest + 录制的 Tool mock）；Java 侧 spring-ai-test 做冒烟。生产指标不进简历，只写「Eval CI + 轨迹 gate」能力（见 claim-map）。

10.15.4 发布与版本治理

资产	版本字段	回滚策略
System prompt	`carts-add-v3.2` in Langfuse	一键切上一版；与 model 版本矩阵
Tool schema	`@Tool` description hash / OpenAPI	向后兼容新增字段；破坏性变更双写期
领域 Facade	常规 semver	Agent 层无感知，但 Eval 集需重跑

灰度维度（Architect 白板常考）：

流量：5% → 25% → 100%（按 userId 哈希）
场景：先 Payment 建议态（只展示），再 Carts，最后 Pricing（促销敏感）
模型：LiteLLM 路由别名 commerce-fast / commerce-quality

未全量上线时的诚实口径 ：工程上具备 Eval gate + Canary 开关 ；对用户侧 rollout 按业务窗口，简历写能力与架构，不写 GMV/转化率 （→ 98 C.110）。

10.15.5 Tool 可靠性矩阵（三域）

Tool	超时	重试	熔断	幂等键	降级
`searchProducts`	800ms	1	5% 错误率/30s	---	返回空列表 + 转人工话术
`checkInventory`	500ms	0	同上	---	禁止加车；勿用缓存价冒充
`addLineItem`	1.2s	0	同上	`cartId+skuId+clientToken`	返回已存在 line
`gapToNextThreshold`	600ms	1	Pricing 池	---	仅展示已有券，不凑满减
`getEligibleCoupons`	800ms	1	同上	---	静态「暂无可用券」
`listAvailablePaymentMethods`	1s	1	Payment 池	---	Checkout 原生渠道列表
`rankPaymentMethods`	600ms	0	同上	---	按默认绑卡顺序，无 LLM 重排

java 复制代码

@Tool(description = "...")
@CircuitBreaker(name = "carts-search", fallbackMethod = "searchFallback")
@TimeLimiter(name = "carts-search")
public List<SkuDto> searchProducts(String query, String size, Double maxPrice) {
    return carts.searchProducts(query, size, maxPrice);
}

10.15.6 编排选型：Spring AI 有界循环 vs LangGraph

维度	Spring AI `ChatClient` + `maxIterations`	LangGraph / 显式状态机
适用	3--5 步 Tool、分支少（本三场景）	退款 Saga、多轮议价、人工介入点多
状态	`MessageChatMemoryAdvisor` 会话级	Checkpoint 可暂停/恢复
审计	OTel span 序列	图节点 ID + 边条件
团队栈	与 Spring Cloud 一致	常 Python 侧或独立服务

结论（buy team） ：Carts / Pricing 推荐 / Payment 排序 留在 Spring AI ；若未来「改地址 + 退款 + 补券」联合编排，子流程用 LangGraph 或 BPMN ，通过 MCP / HTTP Tool 被 Spring AI 调用，而非整体迁 Python 热路径（呼应 Q1）。

10.15.7 Carts：商品 RAG vs 搜索 API（真相源分工）

能力	真相源	Agent 用法
可售 SKU 列表	`searchProducts`（OpenSearch / 商品中心）	必须 Tool
库存	`checkInventory`	必须 Tool
商品描述/卖点	可选 `QuestionAnswerAdvisor` + 商品向量库	仅文案补充；不得替代库存
会员价	`getMemberTier` / PricingFacade	加车后由 Pricing 页展示

面试 red flag：用 RAG 片段回答「有货吗」------应判架构错误（→ 08 Q10、98 C.105）。

10.15.8 Token 成本账本（$/successful task）

场景	典型轮次	P50 tokens	优化杠杆
Carts 加车	1 模型轮 + 3 Tool	~2.5k	压缩 system；Tool 返回只留必要字段
Pricing 凑满减	1--2 轮 + 3 Tool	~3.5k	`suggestAddOnSkus` top-3；explanation 模板化
Payment 排序	1 轮 + 2 Tool	~2k	rank 结果不 embed 全量费率表

FinOps 标签（LiteLLM / Langfuse 统一）：

yaml 复制代码

metadata:
  feature: CARTS_AI_ADD | PRICING_COUPON | PAYMENT_RANK
  cost_center: buy-team
  env: prod|staging

日预算熔断 ：feature 维度 token 超阈值 → 降级 commerce-fast 或关闭 AI 入口，Checkout 原生路径不受影响。

10.15.9 HITL 与失败收口速查表

事件	Carts	Pricing	Payment	HITL
无货	禁止自动换 SKU；可二次 `searchProducts`	---	---	否
Tool 超时	不猜库存；提示稍后重试	不展示凑单	回退渠道列表	否
用户要赔偿/退款	`SafeGuard` → 客服	---	---	是
改价/生效促销	---	仅建议；生效走定价系统	---	是
自动扣款	---	---	禁止；仅推荐	可选确认

全量 Playbook → 13 §16 Checklist · MCP Tool 治理 → 14 §12.3 · Demo 冲刺（Staff 中枢） → demos/buy-team-trading-springai/98-Staff架构师中枢 · Demo 索引

§11 实施蓝图与技术栈

11.1 模型路由：LiteLLM Proxy（主） vs Azure OpenAI（备）

yaml 复制代码

# application-ai.yml（脱敏示例）
spring:
  ai:
    openai:
      api-key: ${AZURE_OPENAI_KEY}
      base-url: ${LITELLM_PROXY_URL:http://litellm.internal:4000/v1}
      chat:
        options:
          model: gpt-4o-mini          # LiteLLM 路由名
          temperature: 0.2
      embedding:
        options:
          model: text-embedding-3-small

litellm:
  primary: true
  fallback:
    enabled: true
    direct-azure:
      base-url: https://{resource}.openai.azure.com/
      deployment: gpt-4o-mini
      api-version: 2024-08-01-preview
  routing:
    - match: { task: customer-service }
      model: gpt-4o
    - match: { task: product-extract }
      model: qwen-2.5-7b-instruct   # 自托管经 LiteLLM
  budget:
    daily-usd-cap: 15000
    alert-threshold: 0.85

路径	何时用	说明
LiteLLM Proxy（主）	默认全链路	统一 API Key、模型别名、成本归因、限流
Azure OpenAI（直连备）	Proxy 5xx / 超时	Resilience4j 熔断后 fallback；审计仍走企业合同

11.2 向量存储三层（L1 / L2 / L3）

层	技术	数据	延迟	容量
L1	Redis Stack（RediSearch / Vector）	热 FAQ、会话最近 5 轮 embedding	<5ms	GB 级
L2	PostgreSQL pgvector	政策 / 商品描述 chunk、客服知识库	10--30ms	TB 级
L3	Milvus	全量商品多模态、亿级向量 ANN	20--50ms	亿级

java 复制代码

@Configuration
public class VectorStoreConfig {
    @Bean @Qualifier("faqVectorStore")
    VectorStore faqVectorStore(RedisVectorStore redis) { return redis; }

    @Bean @Qualifier("policyVectorStore")
    VectorStore policyVectorStore(PgVectorStore pg) { return pg; }

    @Bean @Qualifier("catalogVectorStore")
    VectorStore catalogVectorStore(MilvusVectorStore milvus) { return milvus; }
}

// 导购：先 L1 FAQ → 未命中 L3 商品 → 可选 L2 政策

11.3 Cursor 不是 LLM 网关（边界澄清）

产品形态	是什么	不是什么
Cursor IDE	开发者本地 AI 编码助手（Tab / Chat / Composer）	❌ 生产 API Gateway
Cursor Background Agent	云端异步改代码 / 开 PR	❌ 客服 / 交易链路运行时
Cursor Agent SDK	以 API 驱动 Agent 做工程自动化（CI 排障、文档生成）	❌ 替代 Spring AI `ChatClient`

面试金句 ：「Cursor 提升的是 研发产能 ；Spring AI + LiteLLM 承载的是 用户侧业务流量------二者数据面、SLA、合规域完全隔离。」

11.4 整体架构（Spring AI 中台）

flowchart TB subgraph Client["触点"] APP[App / Web] CS[客服工作台] BO[运营后台] end subgraph Edge["接入"] GW[API Gateway 鉴权 + 限流] end subgraph SpringAI["Spring AI 服务集群"] CC[ChatClient + Advisor 链] AG[Agent Orchestrator] TOOL[@Tool 领域适配器] end subgraph Model["模型层"] LIT[LiteLLM Proxy 主路由] AZ[Azure OpenAI 备] LG[Llama Guard 安全] end subgraph Vector["向量三层"] R1[(L1 Redis)] R2[(L2 pgvector)] R3[(L3 Milvus)] end subgraph Domain["领域系统"] PIM[商品 PIM] OMS[订单 OMS] MKT[营销券] RISK[风控] end Client --> GW --> SpringAI SpringAI --> LIT LIT -.fallback.-> AZ SpringAI --> LG SpringAI --> R1 & R2 & R3 TOOL --> Domain SpringAI --> TOOL

11.5 Q1--Q4 rollout 优先级

季度	场景	理由	依赖
Q1	智能客服 24/7、评价情感分析	见效快、只读为主、风险可控	FAQ 清洗、pgvector
Q2	智能导购 Agent、AI 商品分析	直接拉动 GMV / 降本	Milvus 商品索引、Tool 契约
Q3	满减券推荐、Outfit Builder、限量发售故事	需营销 / 库存 Tool 成熟	券引擎幂等、多模态 pipeline
Q4	定价 Copilot、库存调拨、Multi-Agent 营销、反欺诈 LLM 解释	写操作与 HITL 流程重	审批流、Llama Guard 全量、Eval CI

11.6 Guardrails 总览

层级	组件	作用
输入	Llama Guard 3	有害 / 越狱 / 竞品攻击拦截
编排	`SafeGuardAdvisor` + `maxIterations`	Prompt 注入缓解、步数上限
输出	Output Verifier（小模型）	客服误承诺、金额幻觉
业务	HITL 闸门	定价、退款、调拨、采购
数据	Tool 唯一真相源	金额 / 库存 / 券面额禁止 LLM 编造
运营	Langfuse / OTel + 日采样 1% 人审	可追溯、坏 case 回流 Eval

§99 冲刺：22 道面试 Q&A + 38 项 Checklist

99.1 高频口播（每题 60--90 秒）

Q1. 全球运动零售品牌为什么选 Spring AI 而不是 Python LangChain？

存量是 Spring Cloud 微服务 + 支付级合规。Spring AI 复用 Security / Actuator / 虚拟线程，Tool 调现有 OrderService 零重写。Python 留在离线训练与 Eval，不在交易热路径。

Q2. 优惠券推荐为什么强调 amount from Tool NOT LLM？

LLM 会幻觉面额导致超发资损。架构上 System prompt 禁写数字，展示层只渲染 getEligibleCoupons JSON。Agent 职责是解释「为何适合」，不是定价。

Q3. 向量库为什么三层 Redis / pgvector / Milvus？

热 FAQ 要小延迟用 L1；政策文档 TB 级用 L2 事务友好；亿级商品向量 ANN 用 L3。Spring AI 多 VectorStore Bean，按场景注入，避免单库扛所有 QPS。

Q4. LiteLLM 与直连 Azure 如何切换？

默认走 LiteLLM 做路由、成本标签、模型别名。Proxy 熔断后 Resilience4j fallback 直连 Azure 部署，保证 SLA。密钥仍走企业 Key Vault。

Q5. 定价 Copilot 为什么必须 HITL？

价格是法律与财务敏感变量，LLM 只能给区间与竞品证据链。submitPriceChange 只创建待审批单，生效由定价委员会系统执行，审计 7 年。

Q6. 客服 AI 怎么避免双 11 误承诺事故？

三层：强约束 prompt + 关键词转人工 + Output Verifier。高风险 Tool（退款）加 HITL。资金承诺永不 autonomous。

Q7. Cursor 和 Spring AI 在架构里各放哪？

Cursor = 研发效能（IDE / SDK / Background Agent），不进用户请求路径。Spring AI + LiteLLM = 运行时 AI 中台。数据面与 SLA 隔离。

Q8. 限量发售黄牛场景 LLM 扮演什么角色？

不单独拒单。规则 + XGBoost 打分做主拦截；LLM 只给人审生成可读 reasoning，降低 MTTR。误杀走申诉反馈闭环。

Q9. Carts 智能加车为什么必须 search → inventory → addLineItem 分步 Tool？

结论：分步才能审计、幂等、失败可解释。原理：一步生成订单会跳过库存权威源。工程：Spring AI ChatClient 多轮 Tool；加车写操作在 Carts 服务。验证：无货时 Tool 返回 inStock=false，模型不得换 SKU。风险：maxIterations 上限防死循环。

Q10. 智能加车里价格/库存从哪来？如何防幻觉？

只来自 searchProducts / checkInventory JSON。System prompt 禁止编造 SKU；展示层渲染 Tool 字段。可选商品 RAG 只做描述补充，不做库存真相源。

Q11. 加车失败（无货）时 Agent 如何收口？

不自动换款除非 searchProducts 再次 Tool 调用。话术模板：「该尺码暂无库存，可尝试其他尺码或门店」；记录 trace 供客服接续。

Q12. 凑满减和「到手价」谁算？Spring AI 职责边界？

到手价 / 叠加 / gap 全在 Pricing 领域服务；Spring AI 只编排 getEligibleCoupons、gapToNextThreshold、suggestAddOnSkus 并生成解释。与 §10.5 demo 一致。

Q13. System prompt 如何禁止模型在凑满减话术里写金额？

禁写数字 + 响应 schema 校验 explanation；前端只展示 Tool JSON 中的 amount。违规样本进 Eval 集回归。

Q14. 支付推荐为何不能让模型直接选渠道？

渠道受地区、维护、绑卡、合规约束；模型无权威视图。必须 listAvailable + rankPaymentMethods Tool；LLM 只排序理由。

Q15. 与模块化 Payment / Vault 如何集成？

PaymentFacade 聚合各渠道 Starter 与 Vault token；Tool 层不暴露 PAN。推荐结果写审计日志，Checkout 仍以用户点击确认。

Q16. 支付推荐错了谁负责？要不要 HITL？

默认 建议态 非自动扣款；敏感渠道可 HITL。误推荐走客服与渠道开关；LLM 不触发实际支付 API。

Q17. 交易 Agent 的 trace 里必须有哪些 span？

结论：Gateway → chat_client → 每个 @Tool child → 最终 response；同一 trace_id。工程：OTel + Langfuse；Tool I/O 默认脱敏。验证：无货 case 能回放 Tool 序列。风险：只有 LLM 日志无 Tool → 无法判幻觉还是 Facade 错。

Q18. 轨迹 Eval 和「答得像」的 LLM-Judge 怎么分工？

结论：L1 轨迹匹配 + L2 规则/schema 为主 ；Judge 只评礼貌/合规，不评金额 。原理：金额真相在 Tool。工程：golden YAML + CI gate <95% 阻断。风险：Judge 与 Tool 冲突时以 Tool 为准。

Q19. 三场景 Eval 集各要覆盖哪类坏例？

Carts：无货仍推荐、跳过 checkInventory；Pricing：explanation 含数字；Payment：地区不支持仍推荐 Klarna。每场景 L3 对抗 5--10 条 + 线上 1% 回流。

Q20. Spring AI 够用何时才上 LangGraph？

本三场景 3--5 步 Tool 用 maxIterations + Advisor 即可；退款 Saga / 多 HITL 分支 再上图状态机或 BPMN，经 MCP/HTTP 被 Spring 调用，Python 不进交易热路径。

Q21. Carts 能不能用向量库代替 searchProducts？

不能作库存真相源 。RAG 只补描述；可售 SKU 与库存必须 searchProducts + checkInventory。否则架构 red flag。

Q22. Agent 灰度与 prompt 回滚怎么做？

Langfuse prompt 版本 + LiteLLM feature 标签；流量 5%→100%；Payment 建议态先于写操作场景；prompt/Tool schema 变更必重跑 Eval CI。

99.2 面试前 38 项 Checklist

14. 关联文件 + 一句话速记

14.1 关联文件

本套件前 7 篇 · 本篇是综合落地
01-Spring-AI与LangChain4j.md · Spring AI API 与 Tool/HITL
03-AI应用全栈实战-从原型到生产.md · Dify → Spring AI 生产化
05-architecture/system-design/08-交易-秒杀与库存.md · 电商基础架构
05-architecture/system-design/05-商品-搜索召回.md · 搜索架构

14.2 一句话速记

电商 AI = 商品理解 + 搜索 / 推荐 + 客服 + 风控 + 多模态 ；全球运动零售品牌落地 = Spring AI + LiteLLM + 三层向量 + Tool 唯一真相源 + AgentOps/轨迹 Eval（§10.15） 。CLIP / LTR / Agent 是骨架。最大风险 ：客服误承诺、券面额幻觉、定价无 HITL。红线：金额 / 库存 / 定价写操作必 Tool + HITL；Cursor 不进生产网关；可观测与 Eval 是上线前置，不是事后补丁。

🧭 章节导航

#	文件	风格
00	00-README.md	索引
01	01-Transformer与Attention.md	机制
02	01-Prompt工程-Few-Shot-CoT与Tool-Use.md	操作
03	02-RAG检索增强-向量库与Chunking.md	设计
04	01-Agent框架-LangChain-LangGraph与AutoGen.md	设计
05	01-AI辅助开发-Cursor-Copilot与Claude-Code.md	操作
06	02-评估-Eval-Hallucination与质量度量.md	机制
07	03-部署-模型Serving-Caching与Cost.md	操作
08	本篇 · 架构-电商 AI 辅助交易场景	设计

官方文档与源码（一级依据）

AI Engineering · 正文机制应来自下方 官方文档（L1） 与 官方源码仓库（L2） ；禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。写作规范：docs/official-sources-registry.md §0

L1 · 官方文档

L2 · 官方源码

L3 · 论文 / 开放规范

L3 MCP Specification