从用户行为到定时推荐：AI 商品匹配链路设计

目标

推荐系统的业务目标很直接：在合适的时间，把更可能被接受的商品推荐给合适的人，减少运营筛选成本并提高转化。

但“把所有日志发给大模型，让它推荐商品”不是一个可落地方案。日志量会快速膨胀，模型成本不可控，结果缺乏稳定性，也很容易触碰隐私边界。

这套链路把问题拆成五个阶段：

行为与交易数据
   -> 时间窗口聚合
   -> 可解释画像标签
   -> 规则 + 向量候选召回
   -> 排序、文案与定时推送

文章中的用户、品牌、商品、接口和内部地址均已删除或替换。示例只表达工程方法。

两类主体与四类上下文

推荐场景中存在两类主体：

销售侧：关注销售能力、内容风格、商品偏好和社群特征；
消费侧：关注明确授权范围内的浏览、搜索、加购与购买行为。

候选商品可以由四类上下文共同决定：

销售者最近的搜索、分享、活动页访问和加购；
社群在品类、价位和互动上的聚合特征；
消费者群体的匿名聚合偏好；
季节、天气、活动周期和库存等外部条件。

不是所有可推断信息都应该成为标签。收入、健康、家庭成员等敏感属性不应在没有明确授权和必要性的情况下被模型推断或用于推荐。

事件进入特征层

原始事件先标准化，再按固定窗口聚合：

{
  "subject_id": "hashed_subject_id",
  "event_type": "view_item",
  "object_type": "item",
  "object_id": "item_xxx",
  "occurred_at": "2026-08-23T10:00:00Z",
  "source": "app"
}

常见窗口包括 1 天、7 天和 30 天。聚合结果应优先保留统计特征，而不是把完整行为日志长期发送给模型。

select
  subject_id,
  category_id,
  count(*) as view_count,
  max(occurred_at) as last_view_at
from user_event
where occurred_at >= :window_start
  and event_type = 'view_item'
group by subject_id, category_id;

标签模型

标签分成两类：

属性标签：由稳定业务事实产生，例如等级、城市层级、历史销售区间；
行为标签：由时间窗口内的行为产生，例如近期关注品类、分享频率和活动参与度。

标签表不要只保存一段模型生成的自然语言。至少需要保留结构、强度、证据和版本：

create table profile_tag (
  subject_id_hash text not null,
  subject_type text not null,
  tag_key text not null,
  tag_value text not null,
  score numeric(5, 2) not null,
  evidence_code text[] not null default '{}',
  window_start timestamptz not null,
  window_end timestamptz not null,
  model_version text,
  updated_at timestamptz not null default now(),
  primary key (subject_id_hash, subject_type, tag_key, window_end)
);

evidence_code 保存可审计的证据类型，例如 recent_category_views，不保存原始私聊文本或不必要的个人信息。

用 AI 提炼，而不是吞掉全部日志

第一版容易遇到三个问题：标签太多、日志太长、每个人都单独调用模型导致成本过高。

可以采用分层压缩：

SQL 先按事件、商品、品牌和类目聚合；
规则删除低频、过期和不可行动的特征；
对相近兴趣做语义聚类；
用批量推理一次处理多个聚合画像；
只让模型输出固定 Schema。

{
  "tags": [
    {
      "key": "recent_category_interest",
      "value": "outdoor",
      "score": 0.78,
      "evidence": ["search_7d", "share_7d"]
    }
  ]
}

这种方式能显著减少 Prompt 长度和调用次数，也让模型输出更容易验证、缓存和回放。

候选召回不要只依赖大模型

推荐链路可以使用多路召回：

规则召回：库存、上架状态、权限、价格区间
协同召回：相似群体的历史转化
向量召回：画像标签与商品描述的语义相似度
运营召回：活动商品、新品与业务白名单

所有候选先经过硬规则过滤，再交给排序阶段：

score =
  0.35 * semantic_similarity
  + 0.25 * recent_behavior_match
  + 0.20 * historical_conversion
  + 0.10 * inventory_health
  + 0.10 * campaign_priority

权重只是示例，线上值需要通过离线评估与 A/B 实验确定。大模型适合生成解释和文案，不适合绕过库存、权限、价格等确定性约束。

定时推送的工程设计

定时任务不能简单地“每天遍历所有人然后发一次”。需要处理时区、频控、去重、失败重试和人工停用。

create table recommendation_delivery (
  id uuid primary key,
  subject_id_hash text not null,
  recommendation_date date not null,
  batch_version text not null,
  item_ids text[] not null,
  status text not null,
  scheduled_at timestamptz not null,
  sent_at timestamptz,
  unique (subject_id_hash, recommendation_date, batch_version)
);

唯一键保证同一个批次重复执行时不会重复推送。推荐生成与消息发送应通过队列解耦：

Scheduler
  -> Generate Batch
    -> recommendation_delivery
      -> Message Queue
        -> Delivery Worker
          -> Channel Adapter

发送 Worker 使用带抖动的指数退避，并区分可重试错误与永久失败。系统还需要全局开关、用户退订、渠道频控和人工撤回能力。

运营专题生成

除了个体推荐，还可以按季节、生活场景和商品功能生成运营专题。输入不应是未经筛选的上千个完整商品描述，而应先按库存、销量、类目和活动状态筛选，再给模型一组结构化候选。

{
  "date": "2026-08-23",
  "season": "late_summer",
  "scenes": ["back_to_school", "weekend_outdoor"],
  "candidate_categories": ["learning", "outdoor", "health"]
}

输出同样使用固定格式，并增加去重与敏感词检查：

[
  {
    "topic": "开学焕新",
    "slogan": "学习与护眼装备一次配齐",
    "scene": "back_to_school"
  }
]

数据安全与隐私

画像与推荐系统需要比普通报表更严格的边界：

标识符进入特征层前做不可逆或受控映射；
明确数据用途、保留周期和用户退出机制；
不使用私聊内容、精确地址等非必要数据；
不让模型推断健康、收入、家庭等敏感属性；
模型输入使用最小化聚合特征；
推荐结果、证据、模型版本和人工修改均可审计；
训练、评测和线上推理环境使用不同权限；
对外部模型调用设置字段允许列表和脱敏网关。

评估指标

离线指标

Recall@K、NDCG@K 和候选覆盖率；
标签稳定性、Schema 合法率与证据一致性；
无库存、重复和权限错误的拦截率；
每千次推荐的模型与检索成本。

在线指标

点击率、加购率、转化率和取消率；
推荐多样性与重复曝光率；
推送送达率、退订率和投诉率；
分人群、分品类的长期增益，而不只看单次点击。

需要保留随机对照组，避免把季节、活动和自然增长误判为推荐系统收益。

演进路线

第一阶段：只做销售侧聚合

优先使用低敏感、可解释的销售与行为聚合，建立标签表、候选召回和人工审核。

第二阶段：加入社群级特征

只使用匿名聚合结果，设置最小群体规模，避免从小群体结果反推出个体。

第三阶段：自动化与实验

接入批量推理、定时任务、频控、A/B 实验和成本监控，再逐步扩大覆盖范围。

总结

一条可靠的 AI 推荐链路，核心不是写出更长的 Prompt，而是把数据、规则、模型与交付拆开：SQL 聚合事实，标签层保留证据，多路召回控制候选，大模型完成语义提炼和文案，队列与幂等表保证按时送达。

当每个阶段都可验证、可回放、可停用时，推荐系统才能从一次实验变成长期运行的业务能力。