请举例说明假设在电商系统中，哪些功能适合直接使用大模型完成，哪些需要结合工程化手段？

标签：大模型

🏛 业务架构师

电商系统里我把功能按"错误代价"分两堆：

适合直接用大模型的——错误代价低、结果可人工快速修正的场景：

商品标题与详情文案生成、营销话术多版本草拟；
评价摘要、商品卖点提炼；
客服话术建议（给客服看，不是直接发给用户）；
内部知识问答（平台规则、运营 SOP）。

必须结合工程化手段的——高代价、强规则、要确定性的场景：

商品审核：合规词过滤用规则引擎先行，LLM 做语义级风险判断，最后人工抽检——纯 LLM 审核不可审计；
价格与促销：计算走确定性代码，LLM 最多做"解释"，一分钱都不能让模型算；
搜索推荐：语义召回用 Embedding 可以，排序融合、库存校验全部工程规则；
订单操作类 Agent（改地址、退款）：LLM 做意图识别，动作执行走白名单+风控+幂等设计，关键操作人工确认。

我的判断框架：内容生成类→直接 LLM；判断辅助类→LLM+规则双保险；资金与履约操作类→LLM 只碰意图不碰执行。电商的技术红线是资损和舆情，工程化手段就是给 AI 划的护栏，越接近交易链路护栏越密。

🏗 系统架构师

电商系统里我把功能按"误差代价 × 判断复杂度"分四象限，这决定 AI 直接用还是工程化兜底：

适合直接用大模型（低风险、语义密集）：

商品标题/详情文案生成、营销话术、多语言翻译；
评论情感分析与标签抽取、问答摘要；
客服意图识别、搜索 query 改写与扩召（配合人工运营词表校准）；
导购对话、推荐理由生成。

必须工程化组合（高风险、强一致、有状态）：

交易链路（价格、库存、订单、支付）：LLM 只做理解（"把这句话转成结构化改价指令"），执行走确定性服务 + 人工审批 + 幂等事务，模型输出永远不是事实源；
搜索排序：LLM 做 query 理解和特征，排序由精排模型/规则系统执行，延迟预算毫秒级，LLM 走异步旁路；
风控：LLM 做可疑模式解释与线索发现，决策由风控引擎（规则+专用模型）出，误杀率要可控可回滚；
售后退款：LLM 预判与话术，金额判定走规则引擎，超过阈值人工。

架构总结：大模型放"语言与语义层"，交易一致性和资金安全留给确定性系统——LLM 是接口和大脑皮层，不是账本。所有 LLM 触点要有降级路径（模型挂了系统还能交易）。

💻 全栈开发专家

电商系统我按「错误容忍度 + 输入输出确定性」来划线：

适合直接用大模型（生成型、错误成本低、有人审）：

商品文案/详情页生成、多语言翻译、营销短信——错了人审兜底，价值立现；
评论摘要、舆情分析、客服话术辅助；
图片打标、ALT 文本生成。

必须工程化手段结合（涉及事实、金钱、规则）：

商品搜索/推荐：语义向量召回（Embedding）+ 传统排序模型，LLM 只做 query 理解，排序绝不能交给生成模型；
价格/库存/订单：一律 Function Calling 走交易系统 API，模型只做「翻译官」，算账交给代码——让它口算满减就是事故；
智能客服退款：Agent 调工具 + 规则引擎校验（退款条件、金额上限），高危操作二次确认；
内容合规审核：LLM 分类 + 词库规则双层，处罚决定回流人审。

一条实战判断线：输出会被「直接执行」的（改价、发券、退款）→ 模型只能提议、代码执行、规则把关；输出是「给人看/用的素材」→ 放开生成。另外电商流量大，全链路要考虑成本——用小模型路由 + 缓存 + 语义缓存，我们曾靠这三招把 AI 渠道的单位成本降了 70%。