核心要点

  • 把每条内容用 embedding 模型向量化,存进向量库(如 Milvus / pgvector),对当前内容做向量最近邻检索(ANN)取 Top-N

  • 别只返回最相似的就完事:要过滤已读、去重(同源/几乎重复内容)、过滤当前内容本身

  • 冷启动:新内容刚发布没有行为数据时,先靠纯内容向量召回,再逐步混入点击/协同信号

  • 简单场景不一定上向量:标签匹配 + 热度排序,或基于「看了又看」的协同过滤,成本更低

标准回答

整体思路

核心是「向量化 + 最近邻」。把标题、正文、标签拼成一段文本,用 embedding 模型(如 bge、text-embedding-3)转成向量,落库到向量数据库。用户看某篇内容时,拿这篇的向量去库里做 ANN 检索,取相似度 Top-20 作为候选。

落地步骤

  1. 离线批量:把存量内容全部向量化入库,新内容发布时增量写入(消息队列触发)。
  2. 在线检索:请求来时取目标向量做 ANN,向量库返回 Top-N + 相似度分数。
  3. 后处理:过滤掉自身、已读、低于相似度阈值的;按规则去重(同作者/近重复只留一条)。
  4. 重排:把语义相似度和业务信号(新鲜度、点击率)加权融合再排序。

实战提示

embedding 维度和模型要全站统一,换模型必须全量重算。向量库选型先看数据量:百万级 pgvector 够用,上亿再考虑专用库。

常见误区

⚠️ 常见踩坑

只看向量相似度不做去重,结果一堆「几乎一样」的内容堆在一起;以及忘了过滤已读,老给用户推他刚看过的。

追问

追问 1向量库的 ANN 检索为什么比暴力遍历快,代价是什么?

ANN(近似最近邻)用 HNSW、IVF 等索引把搜索空间剪枝,把 O(N) 暴力比对降到近似对数级,百万向量也能毫秒返回。代价是「近似」:可能漏掉个别真正的最近邻,召回率不是 100%。可以通过调索引参数(如 HNSW 的 efSearch)在速度和召回率间权衡。

追问 2内容实时更新(比如标题改了)怎么保证推荐不过时?

在内容写库的同时发一条更新消息,消费端重新算 embedding 覆盖旧向量。删除内容要同步从向量库删,否则会推到已下架的内容。高频更新场景可以做个延迟队列批量重算,避免频繁单条写入拖慢向量库。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。