比赛结束，主队以微弱优势拿下了胜利。比分一旦定格，场上和场下的人马上开始算谁该背锅：哪次传球失误、哪次防守漏人直接决定了结果。把这套情形搬到短视频推荐上也差不多：表面上看是“给你推内容”，实际上背后是一堆数据和模型在算谁该出现。说白了，核心就是把人和内容都变成向量，用向量检索把“人找内容”反过来变成“内容来找人”。
整个推荐系统可以拆成五层，每层职责清楚。先从最底层讲起。
最底层是数据采集层，负责把各种原始素材攒齐。主要模块会有行为埋点 SDK、视频元数据爬虫和用户画像采集器。它们记录用户的点赞、收藏、评论、完播时间这些行为；把视频的标题、标签、封面、时长等元信息抓下来；再把用户的基础属性补齐。没有这些输入，后面的模型基本没法动弹。
第二层是数据处理层，一般用 SpringBoot 做调度，离线用 Spark，实时用 Flink。这里的活儿包括清洗行为日志、去噪声、抽特征，然后把文本、标签、行为等信息转成向量——也就是生成用户兴趣向量和视频内容向量。这一步就是把杂乱的数据变成机器能比对的“标准化表述”。讲真的，这一步做不好，后面检索出来的候选质量会很糟。
第三层是向量存储层。常用 Milvus（或者托管的 Zilliz Cloud）存高维向量，业务表放 MySQL。向量库要支持近邻搜索（ANN）、按条件过滤（列如视频分类、时长、是否付费等），响应要快到毫秒级。MySQL 则负责存用户、视频的结构化信息。两者分工明确，相互配合。
第四层是推荐服务层，系统的决策和路由都在这里。一般用 SpringBoot 写核心服务，配合负载均衡和 Redis 缓存。接到请求后，推荐服务会先调用向量检索接口拿候选，然后按业务规则（新鲜度、多样性、去重、上下限等）打分、筛选、精排，最后把结果返给前端。热门视频、用户兴趣向量、已看列表这些会放到缓存里，既减轻后端压力，也能加快响应速度。
最上层是应用层，短视频 App、小程序和管理后台都属于这一层。用户看到的推荐、产生的行为反馈、管理员在后台调整策略和监控模型效果，都是在这层完成。管理后台能改权重、配置流量分组、看离线评估指标，便于迭代和回滚。
说到选型，后端常见组合是 SpringBoot 3.x，遇到微服务拆分再上 Spring Cloud。向量库用 Milvus 2.x（自建）或 Zilliz Cloud（托管），关键要支持 ANN 和按条件过滤。嵌入模型方面，文本向量常用 Sentence-BERT，图像用 ResNet-50，或者直接用 Hugging Face 上的 Transformer 模型；这些都支持中文，可以本地部署也可以走 API。缓存推荐 Redis 7.x，离线向量生成走 Spark，实时流式计算用 Flink。结构化数据上 MySQL 8.x，半结构化元数据可以放 MongoDB。接口文档提议用 SpringDoc OpenAPI（也就是 Swagger）自动生成，方便前后端联调和测试。
核心依赖比较固定：SpringBoot、Milvus 客户端、Embedding 模型库、Redis 等。典型数据流大致是这样：先用 Sentence-BERT 把视频的标题、标签、描述转成文本向量，图像特征做成向量后和文本做多模态融合。然后根据用户历史行为（完播、点赞、收藏、评论等）按权重合成用户兴趣向量。权重可以手动设，也可以通过离线训练去优化——列如完播权重大些，点赞次之，评论又另算一套。说白了，这一步对结果影响很大，别小看它。
向量的增删查改要封装成统一接口：插入、近邻查询、更新、删除都要有。Milvus 提供底层功能，但业务侧应做一层抽象，便于后来换库或扩容。推荐服务把向量生成、向量搜素和业务规则整合后对外暴露推荐 API。接口返回的不仅有视频 id，还会带上推荐理由、置信度、召回来源等信息，方便前端做埋点和做多策略融合展示。
实现细节不少，容易踩坑。列如文本和图像向量是否做归一化，召回候选数目和后端精排开销怎么平衡，实时流量下如何保证向量索引的高可用，冷启动用户用哪套默认策略来覆盖，还有过滤条件要能在向量检索前做预筛（按分类、时长等），这样既省资源又能满足业务约束。emm，这些看着像配置，实操起来却常常能影响到线上指标，真让人无语。
业务端还得把监控和在线实验配好。每次换 embedding 模型、调整权重、改召回策略，都需要做 A/B 测试，拉数据看点击率、完播率、留存等关键指标。没有数据支撑的改动很容易出问题。
暂无评论内容