上周，我们团队把推荐流个性化模型正式推上了公司内部知识平台的首页信息流。不是PPT里的‘未来规划’，而是真实替换了原来按发布时间排序的静态列表——用户打开页面，看到的第一条内容，是系统根据他过去三个月的文档阅读行为、岗位角色、甚至最近一次搜索关键词动态算出来的。
没那么玄乎，但得踩过坑
很多人以为个性化推荐部署就是训练完模型导出ONNX，扔进API服务就完事了。我们试过，结果上线第二天，首页加载延迟从300ms飙到2.1秒，IT同事直接在群里发了个哭笑不得的表情包。
问题出在特征实时计算上。原方案每次请求都去查用户最近7天的全部操作日志，再调用Python脚本做归一化和拼接——这在离线评估时跑得飞快，一到线上并发就卡住。后来改成预计算+Redis缓存：用户每次点击/收藏/停留超30秒，就触发一个轻量任务，把更新后的向量存进user:feat:{uid}，接口层只做一次GET。延迟立马回到400ms以内。
模型更新不能停，但也不能乱动
业务方总想‘马上用上最新版’，可我们不敢随便热更。上个月一次未经灰度的全量更新，导致新模型对‘行政类文档’打分普遍偏低，连带HR部门的周报模板推荐率掉了37%。
现在流程固定成三步：先在测试环境用一周历史流量回放验证；再切5%真实用户走AB分流（用Nginx根据cookie哈希路由）；最后确认核心指标（如点击率、平均停留时长）稳定提升超过2%才全量。所有切换操作都有记录，谁在什么时间点了发布按钮，后台自动存档。
别忘了人还在环路里
模型上线第三天，销售部老张在钉钉群里问：‘为啥给我推财务报销流程？我连发票都没经手过。’我们查了下，发现他上周帮同事代交过一份差旅单——系统把它当成了强兴趣信号。
于是加了个‘人工干预开关’：运营后台点开某个用户ID，能临时屏蔽某类标签（比如‘财务相关’），也能手动注入一条‘近期关注：客户合同模板’。这个功能没写进PRD，但成了日常运维最常用的按钮。
附：我们用的最小可行部署栈
特征服务：Feast + Redis（缓存用户向量）
模型服务：Triton Inference Server（支持PyTorch/TensorFlow模型混部）
召回层：Elasticsearch（基于岗位、部门、关键词的粗筛）
排序层：轻量级GBDT（XGBoost，特征维度压到28维以内）
监控：Prometheus + Grafana（重点盯住p95延迟、特征缺失率、负样本比例）没有大厂级别的Flink实时数仓，也没有K8s集群自动扩缩容。用好Redis的过期策略、给Triton配好内存限制、把XGBoost模型转成ONNX减少加载开销——这些才是让推荐流真正稳在办公场景里的东西。