点餐小程序的AI推荐第一版翻车了 - 问题出在我把大模型当成了全部
一、先说我做砸的那一版
去年帮朋友的连锁快餐店做点餐小程序，甲方提了个需求：“能不能让菜单自己变得聪明一点，老客户打开就看到他想吃的。”
我当时的方案非常“直男”：用户进入首页 → 把用户画像和完整菜单塞进 prompt → 调用大模型 → 返回推荐排序。整个链路只有一个核心函数，三天就写完了。
上线两周后问题接连出现：
第一，响应太慢。 高峰期一桌客人扫码点餐，首页推荐要转 3-8 秒的 loading。用户等不及，直接划走，推荐位点击率不到 2%。
第二，成本失控。 每次进入首页都实时调用大模型，菜单有一百多个 SKU,加上用户历史订单做上下文，单次 prompt 超过两千 token。一个月下来，光这一项的 API 费用比甲方原本预估的高了四倍。
第三，结果不稳定。 同一个用户两次打开，推荐结果差异很大，有一次甚至把“微辣”标签的用户推了一堆重辣菜。LLM 的输出没有结构约束，解析失败时我只能降级成随机推荐——那还不如不做。
第四，改一次模型配置要动三处代码。 我在推荐服务里硬编码了模型名和 API Key,后来想加一个备选模型做降级，发现小程序端、后台管理端、一个定时任务脚本里各写了一份调用逻辑，改起来心力交瘁。
这就是典型的失败路径：把大模型当成实时计算的引擎，而不是离线理解的工具。
二、正确的架构：推荐在线计算，AI离线工作
重构后的核心思路是：推荐排序的实时部分不要依赖大模型调用。
架构设计
┌─────────────┐
│ 小程序端 │ ← 请求推荐(带 userId,场景:午餐/晚餐)
└──────┬──────┘
↓ <100ms
┌─────────────┐ ┌──────────────────┐
│ 推荐服务 │ →→→ │ Redis:向量索引 + │
│ (规则+向量) │ │ 用户偏好画像(离线)│
└─────────────┘ └────────↑─────────┘
│ 定时任务(每日/每小时)
┌────────┴─────────┐
│ 统一AI网关 │
│ - 菜品描述向量化 │
│ - 订单评论打标签 │
│ - 用户口味画像 │
└──────────────────┘分工很清晰：
- 实时链路：纯向量相似度 + 规则(时间段、库存、利润率加权)，毫秒级返回，不调大模型。
- 离线链路：大模型负责三件事——给菜品生成标准化的口味标签、从历史订单和评论里提炼用户偏好画像、把这两者都变成向量。每天跑一次，成本可控且可预测。
三、关键实现步骤
第一步，菜单结构化。 用大模型离线批处理，把每道菜的描述统一输出成 JSON 标签：
DISH_PROMPT = """你是餐饮数据标注员。根据菜品信息输出JSON:
{"spicy": 0-5, "taste": ["咸鲜","酸甜"...],
"scene": ["一人食","聚餐","下饭"], "temp": "热/冷"}
菜品名称:{name}
菜品描述:{desc}
只输出JSON,不要其他文字。"""
# 离线批处理,失败自动重试,结果校验后写入数据库
tags = gateway.chat(DISH_PROMPT, model="lite", json_mode=True)第二步，用户画像离线更新。 每晚跑定时任务，把用户近 30 天订单交给大模型，输出结构化的口味画像(辣度偏好、价格带、品类倾向)，连同向量一起写入 Redis。
第三步，在线推荐纯计算。 用户请求到达时，做向量近邻检索拿到候选集，再叠加规则：午市优先推快出餐的、库存不足降权、新品保底曝光。全程无 LLM 调用，P99 延迟稳定在 100ms 内。
第四步，接统一 AI 网关。 所有模型调用收敛到一个入口，配置模型分层：标签提取这类简单任务走低成本小模型，画像提炼走能力更强的模型，由网关统一管理路由、重试和用量统计。
四、为什么统一网关省了大量维护成本
翻车那版最大的教训之一就是调用逻辑散落三处。收敛到统一 AI API 网关后：
- 一处换模型，全局生效。 想把标签提取从小模型 A 换到更便宜的 B,改网关里一条路由配置即可，不用碰业务代码、不用重新发版。
- Key 不再散落。 API Key 只存在网关侧，代码仓库和小程序端都不暴露，安全性直接上一个台阶。
- 限流、重试、降级集中处理。 某个模型超时，网关自动切备用模型，业务层无感知，我不用在每个调用点写一遍容错逻辑。
- 账单看得清。 网关按任务维度统计 token 消耗，哪条链路费钱一目了然，优化有据可依——重估后，离线任务月成本降到了第一版的三分之一以下。
五、结果与几点提醒
重构上线后：首页推荐响应稳定在百毫秒级，推荐位点击率明显提升，且模型调用成本变成了可预算的固定开销。不需要真实数据也能得出的经验是：
- 大模型做“理解和标注”极强，做“实时排序”又贵又慢；
- 一切 LLM 输出都要 JSON 模式 + 校验 + 降级兜底；
- 独立开发者的时间最贵，能交给网关的运维细节就别手写。
如果你也打算给点餐、零售类小程序加 AI 能力，建议从一开始就接入统一 AI API 网关，把模型管理这件事从业务代码里剥离出去。可以在 https://api.thistoken.ai/register 注册试用，把精力留给真正差异化的推荐策略上。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。