向量数据库在 UGC 社区个性化推荐的落地指南

全文概述

本文详细介绍了如何在UGC社区中使用向量数据库进行个性化推荐。通过双向量建模（短期兴趣+长期偏好）和OceanBase原生向量能力，实现了一次SQL多路召回，确保推荐系统的高效性和准确性。

UGC社区特点与推荐系统目标

UGC社区内容量大、更新快、长尾重，推荐系统需兼顾即时兴趣和稳定偏好，并保证毫秒级延迟。本文提出了一套双向量用户兴趣加一次SQL多路召回的实践方案。

选择OceanBase的原因

OceanBase集成了结构化表、VECTOR列和HNSW/IVF向量索引，支持事务一致性，兼容MySQL技术栈，接入和运维成本低，且具备分布式弹性扩展能力。

表结构设计

包括内容表、用户表和行为表。内容表存储帖子或短视频信息及向量；用户表记录用户的双向量（短期和长期兴趣）；行为表记录用户对内容的操作，用于去重和特征提取。

双向量兴趣的产出与更新

长期向量通过双塔模型或对比学习聚合历史行为数据，日更或小时更；短期向量基于会话级序列用Transformer/SASRec实时更新。在线更新时，浏览计数与短期向量在同一事务中更新。

一次查询多路召回策略

通过一次SQL请求同时召回短期兴趣近邻和长期兴趣近邻，并叠加新鲜度和人气，统一排序。强过滤先行以减少参与向量搜索的数据量，确保高效性。

精排与多样性控制

轻量GBDT/LightGBM作为初步精排模型，后续可升级为DNN。通过MMR算法控制主题、作者和价格带占比，避免信息茧房，同时考虑业务约束如状态、合规等。

性能与运维建议

强过滤先行，减少参与向量搜索的数据量；优化HNSW索引参数；保持用户短期向量更新与行为写入同事务；定期校准HNSW参数与权重，监控CTR/CVR等关键指标。

MVP路线与常见问题解答

MVP路线包括建表、离线产出长期向量、实时流更新短期向量、一次SQL多路召回、快速特征迭代和监控打点。常见问题解答涉及单向量局限性、融合排序原因及新内容冷启动策略。