从“找得到”到“找得准”：用 Hologres 构建智能达人圈选系统

达人圈选真正变难，并不是因为缺少达人数据，而是因为数据多、变化快、证据分散，且业务判断很难只靠一张结构化表完成。达人库里可以沉淀账号基础信息、粉丝量、地区、互动率、历史报价、视频素材、评论反馈和投放表现，但业务人员真正要判断的是：这位达人是否讲过类似内容，受众是否与目标人群一致，表达方式是否符合品牌调性，近期内容有没有风险，是否适合新品首发、测评种草、直播转化或节点曝光。

传统筛选方式很难同时满足这些要求。规则筛选能处理平台、地区、粉丝量、性别、报价区间等硬条件，但无法理解视频内容和达人风格；人工翻看视频质量较高，却依赖经验、成本高，也难以扩展到大规模达人库；关键词或标签搜索可以提升效率，但标签往往粗糙、滞后，不同运营人员对同一达人也可能给出不同判断。更关键的是，达人状态持续变化，三个月前主做美食的账号现在可能转向母婴，过去内容安全也不代表近期没有高风险话术。

因此，达人圈选本质上是一个多模态、多约束、强时效、强解释的匹配问题。系统既要把硬条件严格过滤掉，又要从视频里理解内容、受众、风格和风险，还要解释每个候选为什么匹配、证据来自哪些视频。没有这条证据链，智能圈选很难真正进入投放决策流程。

在真实业务里，品牌方提出的需求通常不是一组整齐的数据库条件，而是一句话：

这句话背后至少包含四类判断。

第一类是硬约束，比如平台限定抖音、区域限定华东、粉丝数在 50 万以上、优先女性达人、近 30 天平均播放不能太低。这些条件不应该交给向量相似或大模型自由发挥，而应该在数据库里做稳定、可审计的标量过滤。

第二类是内容匹配。达人是否长期生产母婴、育儿、辅食、亲子生活等内容，是否有产品测评、新品种草、使用演示、生活方式类场景，不能只看账号简介，因为简介经常过时，真正能说明达人定位的是近期视频内容。

第三类是受众与风格匹配。品牌可能想找“年轻妈妈”“一二线城市家庭”“重视安全成分的人群”，也可能强调“真实温暖”“真人出镜”“不过度硬广”“有生活感”。这些信息很少天然存在于结构化字段里，需要从视频画面、口播、字幕、场景和评论语境中抽取。

第四类是品牌安全与商业适配。母婴、美妆、健康、金融等品类对夸大宣传、功效承诺、虚假背书、低俗内容、争议言论都有更高要求。品牌安全不能只是事后复盘，也不能只是关键词黑名单，而要在圈选阶段就作为重要约束进入检索和排序。

AI 在达人圈选里的价值，不是简单把“搜索框”换成“聊天框”，而是把原本依赖人工经验的判断拆成可计算、可检索、可复核的特征。更合理的链路是：

这正是 Hologres 适合切入的地方。Hologres 可以把对象存储中的视频、结构化达人画像、全文检索、向量检索、模型函数和增量动态表放在一条数据链路里，让“看懂视频”和“快速圈选”不再分散在多个系统中。本文围绕抖音/快手达人智能圈选场景，给出一套可落地的技术方案：视频留在 OSS，通过对象表与 ai_gen_structured 自动理解内容，通过动态表增量加工达人特征，再以标量、全文、向量多路召回和 ai_rank 重排完成自然语言圈选。

落到 Hologres 中，整体流程可以先看成五步。

这条链路的核心是把“看视频”和“找达人”放在同一个数据闭环里：视频理解发生在离线或增量加工阶段，在线圈选不再扫描原始视频，也不对全库调用大模型；高频查询只处理已经沉淀好的达人特征，并把大模型判断限制在少量候选上。

Hologres 能承载这条链路，是因为它可以把对象存储中的视频、结构化达人画像、全文检索、向量检索、模型函数和增量动态表组合在同一套查询与加工体系中。整体架构可以理解为四层。第一层是资产层，视频继续存放在 OSS，通过对象表映射到 Hologres。第二层是理解层，使用 ai_gen_structured 对视频进行结构化打标。第三层是特征层，通过动态表把视频级标签增量聚合成达人级特征，并生成多路嵌入向量。第四层是检索与排序层，通过标量过滤、全文检索、向量召回和 ai_rank 重排返回结果。

这套架构有三个关键点：

第一步先确定输入数据长什么样。系统通常已经有一张达人基础信息表，通常包含以下信息：

为简化达人与视频的关联，OSS 示例采用扁平目录和固定文件名：

__ 前是 creator_id，后面是 video_id。生产环境也可以使用独立的“达人—视频资产关系表”做关联。Object Table 默认只扫描 path 下的一级目录；如果使用多层目录，需要开启递归扫描，但应评估额外资源消耗。

有了这层约定后，就可以用对象表把 OSS 视频映射成 Hologres 中可查询的表记录：

Object Table 固定提供 object_uri、etag、file、metadata 等字段。object_uri 用来解析达人和视频标识，etag 用来识别文件内容变化，file 可以直接作为多模态 AI Function 的输入。若后续需要让动态表增量消费对象表的变化，应按当前 Hologres 实例版本和官方文档补充对应的刷新与增量配置。

视频被 Object Table 映射成记录后，下一步不是让模型自由写一段描述，而是先定义稳定的视频级标签结构。以母婴达人视频为例，每条视频经过 ai_gen_structured 后应得到一份结构稳定的 JSON：

这份结构直接决定后续能否检索和审计：内容主题回答“讲什么”，受众画像回答“影响谁”，人设风格回答“怎么讲”，商业适配和风险信号回答“能卖什么、是否安全”。与“让模型返回一串标签”相比，结构化字段可以明确区分内容、受众、商业和风险维度，也能把某条结论追溯回具体视频。

视频级 Dynamic Table 负责解析文件名，拿到 creator_id 和 video_id，再调用视频理解模型生成 tag_json：

视频级标签还不能直接用于达人圈选，因为一个达人不能由单条视频定义。第三步要把多条视频证据按达人聚合，形成四类达人级文本，而不是把所有标签塞进一个大字符串。

拆成四类文本的价值不仅是检索更准，也让最终结果可解释：系统可以明确告诉投放人员，这位达人是因为内容匹配、受众匹配，还是商业和风险特征匹配。

第二层 Dynamic Table 同时消费网红基础信息和视频标签。STRING_AGG(DISTINCT ...) 将多条视频证据聚合到达人级，ai_embed 将四类文本分别向量化：

示例使用 qwen3.7-text-embedding，默认输出 1024 维向量；该模型也支持配置为 2560、2048、1536、768、512 或 256 维。部署时如果选择了非默认维度，必须同步修改 CHECK。HGraph 只会在近似距离函数、索引距离类型和排序方向一致时生效：这里配置的是 Cosine，查询就要使用 approx_cosine_distance 并按得分 DESC 排序。托管模型列表[1]、HGraph 索引使用指南[2]。

四路向量可以提高内容、受众、风格和商业维度的独立召回能力，但会增加 Embedding 调用量和索引内存。流量较小或预算敏感时，可以先合并为“内容+受众”和“风格+商业”两路，或者只保留一列综合语义向量；这不会改变整套架构。

全文索引负责精确抓住“母婴”“辅食”“真人出镜”“夸大宣传”等关键词和短语。中文营销描述可从 IK 或 Jieba 开始评估：

Hologres 全文索引基于 Tantivy，并使用 BM25 相关性分数。索引文件随 Compaction 构建；首次批量加工或新建索引后，应根据资源情况触发 Compaction，并用 EXPLAIN 检查计划中是否出现 Fulltext Filter。全文倒排索引官方文档[3]。

到这里，圈选所需的离线资产已经准备完成：达人基础信息提供平台、地区、粉丝量等硬筛选字段；四类达人文本提供可解释证据；全文索引用来命中明确关键词；向量索引用来召回语义相近的内容和风格。也就是说，系统已经从“原始视频和达人资料”加工出了一个可被实时查询的达人特征层。接下来才进入用户真正发起圈选请求的在线阶段：用户输入一句自然语言需求，系统需要把这句话拆成筛选条件、语义查询和关键词查询，再基于前面准备好的特征层完成召回、去重和重排。

离线特征准备好后，在线请求拆成两条职责单一的 SQL。第一阶段只调用 qwen3.7-plus 理解自然语言并输出结构化检索计划；第二阶段接收这行结果，先执行标量 WHERE 过滤，再完成三路召回和重排：

首先，qwen3.7-plus 将自然语言需求解析为结构化检索计划。没有提到的硬条件不能猜；“华东”“华南”等业务区域则要展开为基础表可等值匹配的省级地区。本例约定去掉“省”“市”“自治区”等后缀，避免模型返回“江苏省”而基础表存储“江苏”造成零召回。示例需求可以得到：

本例从四类达人文本中选用 content_embedding 和 style_embedding 两个向量通道，以及 content_text 一个全文通道。不同业务可以替换这三列，但第二阶段结构不变：

为保证全文与 HGraph 索引直接作用于特征表，配套 SQL 将相同标量条件下推到三个索引分支。标量条件和两个向量检索文本可以使用绑定参数；Hologres 全文索引要求 search_expression 是计划期常量，因此应用端必须使用数据库驱动的安全转义能力，将第一阶段的 fulltext_query 直接渲染为第二阶段 TEXT_SEARCH 中的 SQL 字符串常量，不能通过 CTE 列传入。

如果新增了一个达人的视频，第一层只需要理解新增文件；第二层只需要订正受影响达人的聚合状态和向量，而不是每天重算全库。Dynamic Table 增量刷新支持 GROUP BY、STRING_AGG、CTE 和多表 JOIN，首次刷新会初始化全量状态，后续才进入小批增量，因此首刷应单独评估资源并优先使用隔离的计算资源。Dynamic Table 支持范围和限制[4]。

圈选结果可以直接返回给营销平台或运营工作台：

分数示例仅用于说明返回结构。真实系统应同时保留 object_uri 或代表视频 ID，使运营人员可以点回原视频复核，形成“机器召回—人工确认—投放反馈”的闭环。

不要让提示词无限生成同义标签。核心品类、风格、风险等级应尽量使用枚举或受控词表；同时保留摘要类开放文本，为长尾语义召回提供空间。用一批人工标注视频计算字段准确率和风险召回率，再决定是否上线。

优先分析近 30 至 90 天、播放或互动表现较好的代表视频；为每个达人设置最大采样数；用 etag 避免未变化视频重复推理。首次回灌历史视频与日常增量应使用不同资源和批次上限。

可限制每个达人参与特征加工的视频窗口，或在视频标签与达人特征之间增加按月摘要层。否则头部达人文本会不断增长，带来 Embedding 和 ai_rank token 成本上升，也会稀释近期内容方向。

对于监管、品牌安全和黑名单条件，不应只依赖向量相似。将 risk_level、高风险标签或人工审核状态额外物化为标量列，在召回阶段直接过滤；文本和向量用于补充发现未知风险。

持续检查 hologres.hg_dynamic_table_refresh_history 的刷新状态、延迟、排队时间和资源使用；用 EXPLAIN 确认全文计划出现 Fulltext Filter、向量计划出现 Vector Filter。全文和向量索引依赖 Compaction，不能只看建索引语句成功就认为检索已经就绪。

ai_rank 解决的是“需求与达人特征是否相关”，不等同于“这次投放一定转化好”。上线后应把完播率、点击率、转化率、审核拒绝、人工收藏和最终签约作为反馈特征，逐步校准召回配额和业务排序。

传统达人库回答的是“这个人有多少粉丝”；智能圈选系统要回答的是“这个人的真实内容、受众和表达方式，为什么适合这次投放”。

通过 Object Table，OSS 视频成为 SQL 可访问的数据；通过 ai_gen_structured，视频成为类型稳定、可审计的标签；通过 Dynamic Table，新增视频自动转化为最新达人特征；通过标量、全文和向量多路召回，确定条件与模糊语义同时生效；最后，ai_rank 只在少量候选上做精细判断。

这条链路把对象存储、数仓加工、检索和 AI 推理收敛在 Hologres 内，让达人圈选从“人工翻视频、凭经验搜标签”，升级为一套分钟级更新、自然语言驱动、结果可解释的智能数据产品。

对于出海品牌和达人营销服务商来说，它解决的不是单次搜索效率问题，而是把“达人理解、需求解析、智能召回、证据复核、投放反馈”沉淀为可持续迭代的营销数据基础设施。

想深入交流 Hologres 的技术细节或落地场景？

欢迎加入 Hologres 技术交流群，与产品、架构、解决方案专家直接对话！

（扫码入群 👇）

公众号正文不支持外链跳转，正文中编号对应的地址如下，可复制到浏览器打开：