多平台 AI 回答采集中的场景分类与样本存储设计

原创

用户12582597

发布于 2026-06-26 14:46:42

630

在构建 AI 回答监测系统时，开发者面临的核心挑战往往不在模型层，而在工程层。如何把“用户向 AI 提问”这个动作拆解成可调度、可复现的任务？如何把不同场景的问答结果有序存下来，方便后续分析？本文将从云上任务调度、回答采集、队列处理、样本存储和场景分类五个环节展开，分享一套经过验证的工程实践方案。

一、问题定义：为什么需要场景分类

采集 AI 回答与爬网页不同。网页结构相对固定，采集规则只需关注 DOM 变化。而 AI 回答监测要面对的是：同一个对象，用户可能从完全不同的角度提问。

以消费品监测为例，用户可能在以下场景中提问：

“有哪些适合夏天用的防晒霜推荐？”——推荐场景
“A 品牌和 B 品牌哪个更适合敏感肌？”——对比场景
“某品牌防晒霜靠谱吗？”——风险判断场景
“防晒霜 SPF 值是什么意思？”——信息导航场景

如果不对这些问题做场景分类，所有采集结果混在一起，后续只能得出一个笼统的“出现次数”，无法判断品牌在哪个决策环节表现更好、在哪个环节存在认知空白。场景分类的价值，在于把 AI 回答中的品牌呈现从“一条模糊信息”变成“一组可对比的数据维度”。

二、系统架构总览

采用事件驱动架构，核心分四层：任务工厂、消息队列、采集执行层、存储层。

各层职责明确：调度器负责“要问什么、问谁、问几遍”；队列负责削峰填谷；云函数负责执行采集并写入存储；数据库负责按场景维度提供聚合查询能力。

三、场景分类设计：把用户意图结构化

场景分类的核心，是建立一套可枚举、可扩展的意图标签体系。建议在问题库表中增加 scene_type 字段，让场景标签随问题一同流转。

-- 问题库表，含场景分类字段
CREATE TABLE question_library (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    scene_type VARCHAR(30) NOT NULL COMMENT '场景类型',
    query_text TEXT NOT NULL COMMENT '提问原文',
    target_object VARCHAR(100) COMMENT '监测对象',
    status TINYINT DEFAULT 1，
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP，
    INDEX idx_scene (scene_type)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4；

推荐场景枚举值（可根据业务扩展）：

场景代码	场景名称	典型问题示例
RECOMMEND	推荐决策	“有哪些值得推荐的 XX？”
COMPARE	对比分析	“A 和 B 哪个更适合？”
PURCHASE	购买意图	“选 XX 时应该优先考虑哪些品牌？”
DISCOVER	场景发现	“想找一款适合送长辈的 XX”
NAVIGATE	信息导航	“XX 是什么意思？”
COGNITION	品牌认知	“某品牌主要是做什么的？”
RISK	风险判断	“某品牌靠谱吗？”

这样设计的好处是：一个监测对象完成一轮采集后，可以按场景维度输出一份热力图——在推荐场景提及率 60%，在风险判断场景被提及率仅 10%，说明该对象在用户“查口碑”环节存在可见度缺失。

四、任务调度：三要素组合生成任务

调度器需要将 问题 × 平台 × 轮次 三个维度组合，生成独立任务消息。

{
  "task_id": "uuid-xxxx",
  "scene_type": "RECOMMEND",
  "platform": "deepseek",
  "query_text": "有哪些适合企业使用的云数据库方案？",
  "target_object": "某品牌数据库",
  "round": 2,
  "created_at": "2026-06-26T10:00:00Z"
}

每条消息进入队列后，由云函数消费者独立处理。同一问题多轮采样（建议至少 3 轮）的消息彼此隔离，互不干扰，确保后续能计算稳定性指标。

五、采集执行：适配器模式处理多平台差异

不同 AI 平台的调用方式差异较大，建议用适配器模式封装：

class BasePlatformAdapter:
    def call_api(self, query: str, context: dict) -> dict:
        raise NotImplementedError

class DeepSeekAdapter(BasePlatformAdapter):
    def call_api(self, query: str, context: dict) -> dict:
        # 具体调用逻辑
        pass

class KimiAdapter(BasePlatformAdapter):
    def call_api(self, query: str, context: dict) -> dict:
        pass

云函数从队列拉取任务后，根据 platform 字段选择对应适配器，调用并获取原始回答。建议设置超时兜底（如 60 秒），超时样本标记为 invalid，不进入有效统计。

六、样本存储：原始留档与结构化分层

一次采集产出两类数据，建议分层存储。

（1）对象存储 COS：原始回答留档

文件命名规范：{日期}/{平台}/{场景}/{task_id}.json

{
  "task_id": "uuid-xxxx",
  "platform": "deepseek",
  "scene_type": "RECOMMEND",
  "query": "有哪些适合企业使用的云数据库方案？",
  "raw_response": "根据您的需求，以下方案值得考虑：...",
  "response_at": "2026-06-26T10:00:05Z"
}

（2）关系型数据库：结构化指标落库

-- 采集结果表，关联场景分类
CREATE TABLE monitoring_result (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    task_id VARCHAR(64) NOT NULL,
    platform VARCHAR(30) NOT NULL,
    scene_type VARCHAR(30) NOT NULL COMMENT '场景分类',
    target_object VARCHAR(100) NOT NULL,
    
    is_mentioned TINYINT(1) DEFAULT 0 COMMENT '是否提及',
    is_recommended TINYINT(1) DEFAULT 0 COMMENT '是否推荐',
    recommendation_rank INT DEFAULT 0 COMMENT '推荐位次',
    has_citation TINYINT(1) DEFAULT 0 COMMENT '是否引用',
    
    raw_data_url VARCHAR(512) COMMENT 'COS原始文件链接',
    sampled_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    
    INDEX idx_scene_object (scene_type, target_object)，
    INDEX idx_platform_date (platform, sampled_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4；

场景分类字段与索引设计，让后续查询“某对象在推荐场景下的提及率”变成一次简单的聚合操作，无需二次解析文本。

七、数据查询：按场景维度输出指标

数据入库后，场景维度的分析变得直观：

-- 按场景统计提及率
SELECT 
    scene_type,
    COUNT(*) AS total_samples,
    SUM(is_mentioned) AS mentioned_count,
    ROUND(SUM(is_mentioned) * 100.0 / COUNT(*)， 2) AS mention_rate
FROM monitoring_result
WHERE target_object = '某品牌数据库'
  AND platform = 'deepseek'
GROUP BY scene_type
ORDER BY mention_rate DESC；

同样的查询模板可用于推荐率、引用率等指标。多场景对比结果可以快速定位品牌在 AI 回答中的长板与短板。

八、工程实践中的三个注意点

场景边界模糊问题：有些问题可能同时踩中“推荐场景”和“对比场景”，建议按主要意图归类，并在一轮监测中保持一致，避免同一问题在不同轮次被归入不同场景。
无效样本剔除：云函数超时、AI 平台限流返回错误、回答内容明显不相关（如“我还不会回答这个问题”）等情况，都需要在入库前做筛选，标记 is_valid=0，不进入指标计算。
采样成本控制：多平台 × 多场景 × 多轮次，任务量会快速增长。可以利用云函数按需计费的特性，定时触发批量任务，非监测窗口期缩容到零，大幅降低闲置成本。

九、结语

多平台 AI 回答监测的工程难点，不在于单次调用大模型，而在于如何把“问 AI”这件事系统化。场景分类让采集结果有了业务语义，分层存储让原始证据和结构化指标各得其所，队列调度让系统能够稳定支撑大规模采样。

这套设计已经过实际场景验证，适配消费品牌、企业服务、本地生活等多种行业的 AI 可见度监测需求。对开发者来说，搭建这样一套系统，本质上是在为“品牌在 AI 中的信息呈现”提供可量化、可复现的技术底座。

说明：本文所述方案聚焦于技术架构与数据流程设计，实际运行结果取决于具体平台、问题集合与采样规则。监测数据反映特定条件下的信息呈现状态，不等同于市场份额或商业排名。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能

登录后参与评论

0 条评论

热度