本文面向需要系统性地监测品牌在AI回答中表现的技术人员和数据工程师。在品牌AI可见度监测体系中问题库是整套系统的“输入层”——问题怎么设计、怎么分类、怎么分层管理直接决定了后续所有指标的可信度和可比性。文章将从问题模板设计、问题分类体系、场景标签管理、品牌绑定策略、采样计划配置和结果样本表设计六个环节拆解一套可落地的问题库系统设计思路。阅读后你将获得从“想到什么问什么”到“系统化、可复用的问题资产管理”的完整方法。目录问题库为什么需要系统化设计问题库系统的整体架构问题模板设计从自然语言到结构化模板问题分类体系意图、场景、对象三重维度场景标签的设计与管理品牌绑定策略问题与品牌的松耦合采样计划配置多平台、多轮次、多时间结果样本表设计从问题到回答的数据闭环问题库的维护与质量治理方法边界与注意事项总结一、问题库为什么需要系统化设计在品牌AI可见度监测的实践中一个常见的起点是“想到几个问题就去问AI”。这种做法在探索阶段可以快速验证想法但在体系化监测中会带来三个致命问题问题一结果不可比如果1月份用问题集A测试3月份用问题集B测试两次结果的差异到底是品牌表现变了还是问题变了没有固定的问题库就没有纵向可比性。问题二场景覆盖有盲区凭感觉想出来的问题往往集中在“推荐决策”类“有什么推荐的品牌”而忽略了“风险判断”“这个品牌靠谱吗”和“信息导航”“什么是XX品牌”等同样重要的用户意图。场景覆盖不全监测结果就是片面的。问题三问题本身可能引入偏差如果问题中直接出现了某个品牌名“品牌A和品牌B哪个好”AI的回答就已经被问题本身引导了。这样的问题测出来的不是“AI自然状态下对品牌的认知”而是“AI在被提示后的反应”。问题库系统化设计的目标就是用一套可管理、可复用、可追溯的结构化问题资产替代临时起意的提问确保监测结果的可靠性。二、问题库系统的整体架构问题库系统 ├── 问题模板管理 │ ├── 模板ID、模板文本含占位符 │ ├── 占位符说明场景变量、对象变量等 │ └── 模板来源与审核状态 ├── 问题分类体系 │ ├── 用户意图分类推荐决策/对比分析/信息导航/风险判断... │ ├── 消费场景分类毕业旅行/日常通勤/节日送礼... │ ├── 行业品类分类运动鞋/智能穿戴/餐饮... │ └── 对象类型分类品牌/产品/服务/机构 ├── 场景标签库 │ ├── 场景标签ID、名称、关键词 │ ├── 标签层级主场景→子场景 │ └── 适用品类关联 ├── 问题实例管理 │ ├── 问题ID、问题文本占位符已填充 │ ├── 关联的分类标签 │ ├── 适用品牌范围可为空不限品牌 │ └── 状态草稿/已审核/已归档 ├── 采样计划配置 │ ├── 计划ID、关联问题列表 │ ├── 平台配置、轮次配置 │ └── 执行时间窗口 └── 结果样本表 ├── 样本ID、关联问题ID、平台 ├── 原始回答、提取结果 └── 采样时间、有效性标记三、问题模板设计从自然语言到结构化模板3.1 为什么需要模板先看两个“问题”“毕业旅行穿什么运动鞋好”“端午节送长辈什么粽子礼盒合适”它们看起来是两个完全不同的问法但结构是完全一样的[消费场景] [需求描述] [品类词] [推荐意图]。如果不把这种结构抽象出来每增加一个新品类就要从零开始想问题问题库会迅速变成一堆无法管理的散乱文本。3.2 问题模板的结构# 问题模板记录结构question_template{template_id:TPL_RECOMMEND_001,template_name:场景推荐-基础版,template_text:【{scene}】{scene_desc}有什么{category}推荐,placeholders:{scene:{description:消费场景名称,example:毕业旅行,source:场景标签库},scene_desc:{description:场景补充描述增加真实感,example:每天走很多路、预算有限,source:场景标签库中的子场景描述},category:{description:消费品类,example:运动鞋,source:品类列表}},applicable_intents:[推荐决策,场景发现],template_source:人工设计,review_status:已审核,created_at:2026-07-01,version:1.0}3.3 常见问题模板类型模板类型模板文本示例适用意图场景推荐“{scene}{scene_desc}有什么{category}推荐”推荐决策预算限定“学生党{scene}预算{budget}以内买什么{category}划算”购买意图对比分析“{brand_a}和{brand_b}{scene}场景下选哪个好”对比分析风险判断“最近听说{category}行业有些品牌品控不稳定{scene}选什么比较靠谱”风险判断信息导航“什么是{category}有哪些主流品牌值得关注”信息导航场景发现“{scene}需要准备什么{category}有没有专门做这个的品牌”场景发现3.4 模板实例化从模板到可执行问题definstantiate_question(template,placeholder_values): 将模板实例化为具体问题 参数: template: 问题模板 placeholder_values: 占位符填充值 {scene: 毕业旅行, ...} 返回: 实例化后的问题文本和元信息 question_texttemplate[template_text]forkey,valueinplaceholder_values.items():placeholder{key}question_textquestion_text.replace(placeholder,str(value))return{question_id:generate_question_id(template[template_id]),template_id:template[template_id],question_text:question_text,placeholder_values:placeholder_values,intent_type:placeholder_values.get(intent_type,template[applicable_intents][0]),scene:placeholder_values.get(scene),category:placeholder_values.get(category),created_at:datetime.now().isoformat()}# 使用示例templateget_template(TPL_RECOMMEND_001)questioninstantiate_question(template,{scene:毕业旅行,scene_desc:每天走两万步,category:运动鞋})# 结果: 毕业旅行每天走两万步有什么运动鞋推荐四、问题分类体系意图、场景、对象三重维度4.1 为什么要多维分类一道问题“毕业旅行穿什么运动鞋”可以从三个维度同时分类意图维度推荐决策用户希望获得具体品牌/产品推荐场景维度毕业旅行特定的人生阶段和出行场景对象维度运动鞋品类 品牌监测对象单维分类会导致“只能在某一个维度上筛选”。多维分类允许在不同分析场景下灵活组合例如只看“推荐决策”意图下所有品类、所有场景的表现只看“毕业旅行”场景下所有意图、所有品类的表现只看“运动鞋”品类下所有意图、所有场景的表现4.2 三维分类的标签结构# 问题分类标签结构question_classification{question_id:Q20260707_001,classifications:{# 维度一用户意图intent:{primary:推荐决策,secondary:None,# 可选更细粒度的意图intent_code:INT_RECOMMEND_01},# 维度二消费场景scene:{primary:毕业旅行,secondary:长途步行,# 子场景scene_code:SCENE_GRADUATION_TRIP},# 维度三对象target:{category:运动鞋,# 品类category_code:CAT_SPORTS_SHOES,object_type:品牌,# 品牌/产品/服务/机构related_brands:[],# 问题中不应包含品牌名此字段留空表示不绑定品牌brand_binding:none# none/primary_only/competitor_set}}}4.3 分类体系的管理建议用枚举表管理所有分类值而不是在每条问题中自由填写文本# 用户意图枚举表intent_catalog{INT_RECOMMEND_01:{name:推荐决策,description:用户希望AI推荐品牌或产品},INT_COMPARE_01:{name:对比分析,description:用户希望AI比较多个选项的差异},INT_PURCHASE_01:{name:购买意图,description:用户接近购买阶段带有预算或明确需求},INT_DISCOVERY_01:{name:场景发现,description:用户从场景出发寻找解决方案},INT_INFO_01:{name:信息导航,description:用户希望了解概念或行业概况},INT_RISK_01:{name:风险判断,description:用户带有疑虑希望AI给出风险提示}}# 消费场景枚举表以运动鞋行业为例scene_catalog{SCENE_GRADUATION_TRIP:{name:毕业旅行,category:运动鞋},SCENE_DAILY_COMMUTE:{name:日常通勤,category:运动鞋},SCENE_OUTDOOR_SPORTS:{name:户外运动,category:运动鞋},SCENE_GYM_WORKOUT:{name:健身房训练,category:运动鞋},}五、场景标签的设计与管理5.1 场景标签的两层结构场景标签建议设计为主场景子场景两层主场景用户面临的生活/工作情境毕业旅行、日常通勤、节日送礼子场景该情境下的具体约束或需求预算有限、透气需求、送礼对象是长辈5.2 场景标签库设计scene_tag_library{tags:[{tag_id:SCENE_GRADUATION_TRIP,tag_name:毕业旅行,tag_type:主场景,keywords:[毕业,旅行,旅游,毕业季,出行],applicable_categories:[运动鞋,行李箱,防晒霜],sub_scenes:[{sub_tag_id:SUB_LONG_WALK,sub_tag_name:长途步行,keywords:[走很多路,暴走,日行两万步,不累脚,持久舒适],},{sub_tag_id:SUB_BUDGET_LIMITED,sub_tag_name:预算有限,keywords:[学生党,预算,500以内,性价比,划算,不贵],},{sub_tag_id:SUB_HOT_WEATHER,sub_tag_name:炎热天气,keywords:[夏天,透气,闷热,凉爽,网面],}]}]}5.3 场景标签在问题实例化中的应用当从模板生成具体问题时场景标签用于填充模板占位符并自动标记问题的场景分类defapply_scene_tags(question,scene_tag):为问题实例自动关联场景标签question[scene_tags]{primary:scene_tag[tag_name],primary_id:scene_tag[tag_id],sub_tags:[]}# 根据问题文本中的关键词自动匹配子场景标签forsubinscene_tag.get(sub_scenes,[]):forkwinsub[keywords]:ifkwinquestion[question_text]:question[scene_tags][sub_tags].append({sub_tag_id:sub[sub_tag_id],sub_tag_name:sub[sub_tag_name],matched_keyword:kw})breakreturnquestion六、品牌绑定策略问题与品牌的松耦合6.1 核心原则问题中不应包含品牌名问题库的设计有一个铁律用于监测品牌AI可见度的问题文本中不能出现任何品牌名。理由很简单如果问题已经提到了“品牌A”AI的回答中出现了“品牌A”就不能算作“AI主动提及”——那是被问题引导出来的。6.2 品牌绑定的两种模式问题本身不包含品牌名但分析时需要知道“这条问题的结果应该用来评估哪个品牌的表现”。这就产生了“品牌绑定”的概念模式一无品牌绑定问题完全开放AI回答中出现的所有品牌都被记录和分析。适用于行业榜单类监测“这个品类里哪些品牌被AI推荐最多”。模式二品类级绑定问题绑定到一个品类该品类下的目标品牌在分析时被重点关注。问题本身仍不包含品牌名。# 品牌绑定配置brand_binding_config{question_id:Q20260707_001,binding_mode:category_level,# none / category_levelcategory:运动鞋,target_brands:[品牌A,品牌B,品牌C],# 本次监测关注的目标品牌competitor_brands:[品牌D,品牌E],# 竞品品牌用于对比分析brand_inclusion_rule:问题文本中不包含任何品牌名AI自由选择提及对象}七、采样计划配置多平台、多轮次、多时间7.1 采样计划的结构有了问题库之后需要配置“什么时候、在哪些平台、用哪些问题、采多少轮”。这就是采样计划sampling_plan{plan_id:SP20260707_001,plan_name:运动鞋品牌-2026年7月常规监测,question_selection:{mode:by_filter,# by_filter / by_id_listfilters:{category:运动鞋,intents:[推荐决策,对比分析,预算限定,风险判断],scenes:[毕业旅行,日常通勤,户外运动],status:已审核},question_count:20# 筛选后的问题数量},platform_config:{platforms:[平台A,平台B,平台C],per_platform_rounds:3,# 每个平台每个问题的采样轮次round_interval_hours:2# 轮次之间的最小间隔},schedule:{start_time:2026-07-08 09:00:00,end_time:2026-07-10 18:00:00,time_zone:Asia/Shanghai},estimated_total_samples:180,# 20问题 × 3平台 × 3轮次status:待执行}7.2 采样计划的样本量估算defestimate_sample_size(plan): 估算采样计划的总样本量 question_countplan[question_selection][question_count]platform_countlen(plan[platform_config][platforms])rounds_per_platformplan[platform_config][per_platform_rounds]totalquestion_count*platform_count*rounds_per_platform# 预留10%的无效样本余量estimated_invalidtotal*0.1return{total_planned:total,estimated_valid:total-estimated_invalid,estimated_invalid:estimated_invalid,breakdown:f{question_count}问题 ×{platform_count}平台 ×{rounds_per_platform}轮次}八、结果样本表设计从问题到回答的数据闭环8.1 结果样本表的核心字段当采样计划执行后每条AI回答都需要记录在结果样本表中形成“问题→回答”的完整链路-- 结果样本表结构简化版CREATETABLEai_response_samples(-- 主键与关联sample_idVARCHAR(64)PRIMARYKEY,plan_idVARCHAR(32)NOTNULL,-- 关联采样计划question_idVARCHAR(32)NOTNULL,-- 关联问题-- 问题快照采样时的问题状态防止问题后续被修改导致历史数据不可追溯question_text_snapshotTEXTNOTNULL,-- 采样时的实际问题文本scene_tag_snapshotVARCHAR(128),-- 采样时的场景标签intent_type_snapshotVARCHAR(32),-- 采样时的意图分类-- 平台与时间platformVARCHAR(32)NOTNULL,request_timeDATETIMENOTNULL,response_timeDATETIME,-- 回答内容raw_responseTEXT,-- 原始回答response_text_cleanTEXT,-- 归一化后的纯文本response_lengthINT,-- 有效性标记is_validBOOLEANDEFAULTTRUE,invalid_reasonVARCHAR(64),-- 品牌识别结果JSON字段方便扩展brands_identified JSON,-- [品牌A, 品牌B]brand_details JSON,-- {品牌A: {mentioned: true, recommended: true, ...}}-- 元信息created_atDATETIMEDEFAULTCURRENT_TIMESTAMP,processed_atDATETIME-- 品牌识别处理完成时间);8.2 问题快照的必要性问题库中的问题可能会被修改优化措辞、调整分类标签等但历史采样数据必须保留“当时问了什么问题”。因此结果样本表中存储的是问题的快照而非外键关联到问题表的当前版本。defcreate_sample_with_snapshot(question,platform,raw_response):创建采样记录时同时保存问题快照return{question_id:question[question_id],question_text_snapshot:question[question_text],# 快照不随问题更新而改变scene_tag_snapshot:json.dumps(question.get(scene_tags,{})),intent_type_snapshot:question.get(intent_type),platform:platform,raw_response:raw_response,created_at:datetime.now().isoformat()}8.3 从样本表到分析视图样本表是原始数据层分析时通常需要创建聚合视图# 按场景×品牌×平台的聚合查询伪代码defaggregate_samples(samples,dimensions): 按指定维度聚合样本数据 dimensions: [scene, brand, platform] 等 # 实际实现中对应SQL的GROUP BY查询# SELECT scene, brand, platform,# COUNT(*) as total_samples,# SUM(CASE WHEN mentioned THEN 1 ELSE 0 END) as mention_count# FROM samples# WHERE is_valid true# GROUP BY scene, brand, platformpass九、问题库的维护与质量治理9.1 问题生命周期管理每个问题实例应管理其完整生命周期状态说明可执行采样草稿新建问题尚未审核否已审核通过质量检查可用于采样是已归档历史问题不再用于新采样否需修订发现措辞或分类问题待修改否9.2 质量检查规则defquality_check(question): 检查问题的质量 返回: (通过与否, 问题列表) issues[]# 检查1问题中是否包含品牌名核心规则known_brandsload_brand_list()forbrandinknown_brands:ifbrandinquestion[question_text]:issues.append(f问题文本中包含品牌名{brand}这会导致品牌被提示而非自然提及)# 检查2问题长度是否合理iflen(question[question_text])8:issues.append(问题过短可能无法提供足够的场景信息)iflen(question[question_text])100:issues.append(问题过长可能偏离真实用户的提问习惯)# 检查3分类标签是否完整required_tags[intent,scene,category]fortaginrequired_tags:iftagnotinquestion.get(classifications,{}):issues.append(f缺少分类标签:{tag})# 检查4与已有问题的语义去重similar_questionsfind_similar_questions(question[question_text],threshold0.85)ifsimilar_questions:issues.append(f与已有问题高度相似:{similar_questions[0][question_id]})returnlen(issues)0,issues9.3 问题库的版本管理问题库应支持版本管理每次修改都记录变更question_version_log{question_id:Q20260707_001,version:1.2,changed_at:2026-07-07 14:00:00,changed_by:编辑员-李四,change_type:措辞优化,change_detail:将有什么推荐改为有哪些值得考虑的品牌增强自然感,previous_version:1.1}十、方法边界与注意事项10.1 问题库不能无限扩大问题越多样本量越大但边际收益递减。当问题覆盖了主要的意图×场景组合后新增问题往往只是在重复已有覆盖。建议每个品类的问题数控制在15-30个之间优先保证覆盖率而非绝对数量。10.2 问题的“自然感”需要持续打磨模板生成的问题有时会带有“模板味”过于规整、缺少真实用户提问的随意感。建议定期从真实用户提问中采集表达方式反哺模板优化。10.3 问题库不能脱离行业知识同一个问题模板在运动鞋行业和餐饮行业的适用性可能完全不同。场景标签、品类特征、用户决策路径等都需要行业知识的输入。问题库的建设需要行业专家和技术人员的配合。10.4 采样结果对问题库的反哺问题库不是一成不变的。当分析发现某类问题的无效回答率特别高如AI频繁拒答可能说明问题本身需要调整。建立从“样本分析结果”到“问题库优化”的反馈闭环是长期运营的关键。十一、总结本文拆解了AI回答监测中问题库系统的设计思路核心包括六个环节问题模板设计将自然语言问题抽象为可复用的结构化模板通过占位符机制实现“一个模板生成多个场景问题”问题分类体系建立意图、场景、对象三维分类标签支持灵活的多维筛选和聚合分析场景标签管理设计主场景子场景两层标签库在问题实例化时自动关联场景分类品牌绑定策略问题文本中不包含任何品牌名通过品类级绑定实现“品牌不提示”的客观监测采样计划配置将问题库、平台、轮次、时间窗口组合成可执行、可复现的采样计划结果样本表设计用问题快照保证历史数据的可追溯性形成从问题到回答的完整数据闭环问题库是整个品牌AI可见度监测系统的“地基”。问题的质量、覆盖度和结构化程度直接决定了后续所有指标、诊断、对比的可信度。投入足够的精力在问题库建设上是整个系统长期可靠运行的保障。
本文面向需要系统性地监测品牌在AI回答中表现的技术人员和数据工程师。在品牌AI可见度监测体系中问题库是整套系统的“输入层”——问题怎么设计、怎么分类、怎么分层管理直接决定了后续所有指标的可信度和可比性。文章将从问题模板设计、问题分类体系、场景标签管理、品牌绑定策略、采样计划配置和结果样本表设计六个环节拆解一套可落地的问题库系统设计思路。阅读后你将获得从“想到什么问什么”到“系统化、可复用的问题资产管理”的完整方法。目录问题库为什么需要系统化设计问题库系统的整体架构问题模板设计从自然语言到结构化模板问题分类体系意图、场景、对象三重维度场景标签的设计与管理品牌绑定策略问题与品牌的松耦合采样计划配置多平台、多轮次、多时间结果样本表设计从问题到回答的数据闭环问题库的维护与质量治理方法边界与注意事项总结一、问题库为什么需要系统化设计在品牌AI可见度监测的实践中一个常见的起点是“想到几个问题就去问AI”。这种做法在探索阶段可以快速验证想法但在体系化监测中会带来三个致命问题问题一结果不可比如果1月份用问题集A测试3月份用问题集B测试两次结果的差异到底是品牌表现变了还是问题变了没有固定的问题库就没有纵向可比性。问题二场景覆盖有盲区凭感觉想出来的问题往往集中在“推荐决策”类“有什么推荐的品牌”而忽略了“风险判断”“这个品牌靠谱吗”和“信息导航”“什么是XX品牌”等同样重要的用户意图。场景覆盖不全监测结果就是片面的。问题三问题本身可能引入偏差如果问题中直接出现了某个品牌名“品牌A和品牌B哪个好”AI的回答就已经被问题本身引导了。这样的问题测出来的不是“AI自然状态下对品牌的认知”而是“AI在被提示后的反应”。问题库系统化设计的目标就是用一套可管理、可复用、可追溯的结构化问题资产替代临时起意的提问确保监测结果的可靠性。二、问题库系统的整体架构问题库系统 ├── 问题模板管理 │ ├── 模板ID、模板文本含占位符 │ ├── 占位符说明场景变量、对象变量等 │ └── 模板来源与审核状态 ├── 问题分类体系 │ ├── 用户意图分类推荐决策/对比分析/信息导航/风险判断... │ ├── 消费场景分类毕业旅行/日常通勤/节日送礼... │ ├── 行业品类分类运动鞋/智能穿戴/餐饮... │ └── 对象类型分类品牌/产品/服务/机构 ├── 场景标签库 │ ├── 场景标签ID、名称、关键词 │ ├── 标签层级主场景→子场景 │ └── 适用品类关联 ├── 问题实例管理 │ ├── 问题ID、问题文本占位符已填充 │ ├── 关联的分类标签 │ ├── 适用品牌范围可为空不限品牌 │ └── 状态草稿/已审核/已归档 ├── 采样计划配置 │ ├── 计划ID、关联问题列表 │ ├── 平台配置、轮次配置 │ └── 执行时间窗口 └── 结果样本表 ├── 样本ID、关联问题ID、平台 ├── 原始回答、提取结果 └── 采样时间、有效性标记三、问题模板设计从自然语言到结构化模板3.1 为什么需要模板先看两个“问题”“毕业旅行穿什么运动鞋好”“端午节送长辈什么粽子礼盒合适”它们看起来是两个完全不同的问法但结构是完全一样的[消费场景] [需求描述] [品类词] [推荐意图]。如果不把这种结构抽象出来每增加一个新品类就要从零开始想问题问题库会迅速变成一堆无法管理的散乱文本。3.2 问题模板的结构# 问题模板记录结构question_template{template_id:TPL_RECOMMEND_001,template_name:场景推荐-基础版,template_text:【{scene}】{scene_desc}有什么{category}推荐,placeholders:{scene:{description:消费场景名称,example:毕业旅行,source:场景标签库},scene_desc:{description:场景补充描述增加真实感,example:每天走很多路、预算有限,source:场景标签库中的子场景描述},category:{description:消费品类,example:运动鞋,source:品类列表}},applicable_intents:[推荐决策,场景发现],template_source:人工设计,review_status:已审核,created_at:2026-07-01,version:1.0}3.3 常见问题模板类型模板类型模板文本示例适用意图场景推荐“{scene}{scene_desc}有什么{category}推荐”推荐决策预算限定“学生党{scene}预算{budget}以内买什么{category}划算”购买意图对比分析“{brand_a}和{brand_b}{scene}场景下选哪个好”对比分析风险判断“最近听说{category}行业有些品牌品控不稳定{scene}选什么比较靠谱”风险判断信息导航“什么是{category}有哪些主流品牌值得关注”信息导航场景发现“{scene}需要准备什么{category}有没有专门做这个的品牌”场景发现3.4 模板实例化从模板到可执行问题definstantiate_question(template,placeholder_values): 将模板实例化为具体问题 参数: template: 问题模板 placeholder_values: 占位符填充值 {scene: 毕业旅行, ...} 返回: 实例化后的问题文本和元信息 question_texttemplate[template_text]forkey,valueinplaceholder_values.items():placeholder{key}question_textquestion_text.replace(placeholder,str(value))return{question_id:generate_question_id(template[template_id]),template_id:template[template_id],question_text:question_text,placeholder_values:placeholder_values,intent_type:placeholder_values.get(intent_type,template[applicable_intents][0]),scene:placeholder_values.get(scene),category:placeholder_values.get(category),created_at:datetime.now().isoformat()}# 使用示例templateget_template(TPL_RECOMMEND_001)questioninstantiate_question(template,{scene:毕业旅行,scene_desc:每天走两万步,category:运动鞋})# 结果: 毕业旅行每天走两万步有什么运动鞋推荐四、问题分类体系意图、场景、对象三重维度4.1 为什么要多维分类一道问题“毕业旅行穿什么运动鞋”可以从三个维度同时分类意图维度推荐决策用户希望获得具体品牌/产品推荐场景维度毕业旅行特定的人生阶段和出行场景对象维度运动鞋品类 品牌监测对象单维分类会导致“只能在某一个维度上筛选”。多维分类允许在不同分析场景下灵活组合例如只看“推荐决策”意图下所有品类、所有场景的表现只看“毕业旅行”场景下所有意图、所有品类的表现只看“运动鞋”品类下所有意图、所有场景的表现4.2 三维分类的标签结构# 问题分类标签结构question_classification{question_id:Q20260707_001,classifications:{# 维度一用户意图intent:{primary:推荐决策,secondary:None,# 可选更细粒度的意图intent_code:INT_RECOMMEND_01},# 维度二消费场景scene:{primary:毕业旅行,secondary:长途步行,# 子场景scene_code:SCENE_GRADUATION_TRIP},# 维度三对象target:{category:运动鞋,# 品类category_code:CAT_SPORTS_SHOES,object_type:品牌,# 品牌/产品/服务/机构related_brands:[],# 问题中不应包含品牌名此字段留空表示不绑定品牌brand_binding:none# none/primary_only/competitor_set}}}4.3 分类体系的管理建议用枚举表管理所有分类值而不是在每条问题中自由填写文本# 用户意图枚举表intent_catalog{INT_RECOMMEND_01:{name:推荐决策,description:用户希望AI推荐品牌或产品},INT_COMPARE_01:{name:对比分析,description:用户希望AI比较多个选项的差异},INT_PURCHASE_01:{name:购买意图,description:用户接近购买阶段带有预算或明确需求},INT_DISCOVERY_01:{name:场景发现,description:用户从场景出发寻找解决方案},INT_INFO_01:{name:信息导航,description:用户希望了解概念或行业概况},INT_RISK_01:{name:风险判断,description:用户带有疑虑希望AI给出风险提示}}# 消费场景枚举表以运动鞋行业为例scene_catalog{SCENE_GRADUATION_TRIP:{name:毕业旅行,category:运动鞋},SCENE_DAILY_COMMUTE:{name:日常通勤,category:运动鞋},SCENE_OUTDOOR_SPORTS:{name:户外运动,category:运动鞋},SCENE_GYM_WORKOUT:{name:健身房训练,category:运动鞋},}五、场景标签的设计与管理5.1 场景标签的两层结构场景标签建议设计为主场景子场景两层主场景用户面临的生活/工作情境毕业旅行、日常通勤、节日送礼子场景该情境下的具体约束或需求预算有限、透气需求、送礼对象是长辈5.2 场景标签库设计scene_tag_library{tags:[{tag_id:SCENE_GRADUATION_TRIP,tag_name:毕业旅行,tag_type:主场景,keywords:[毕业,旅行,旅游,毕业季,出行],applicable_categories:[运动鞋,行李箱,防晒霜],sub_scenes:[{sub_tag_id:SUB_LONG_WALK,sub_tag_name:长途步行,keywords:[走很多路,暴走,日行两万步,不累脚,持久舒适],},{sub_tag_id:SUB_BUDGET_LIMITED,sub_tag_name:预算有限,keywords:[学生党,预算,500以内,性价比,划算,不贵],},{sub_tag_id:SUB_HOT_WEATHER,sub_tag_name:炎热天气,keywords:[夏天,透气,闷热,凉爽,网面],}]}]}5.3 场景标签在问题实例化中的应用当从模板生成具体问题时场景标签用于填充模板占位符并自动标记问题的场景分类defapply_scene_tags(question,scene_tag):为问题实例自动关联场景标签question[scene_tags]{primary:scene_tag[tag_name],primary_id:scene_tag[tag_id],sub_tags:[]}# 根据问题文本中的关键词自动匹配子场景标签forsubinscene_tag.get(sub_scenes,[]):forkwinsub[keywords]:ifkwinquestion[question_text]:question[scene_tags][sub_tags].append({sub_tag_id:sub[sub_tag_id],sub_tag_name:sub[sub_tag_name],matched_keyword:kw})breakreturnquestion六、品牌绑定策略问题与品牌的松耦合6.1 核心原则问题中不应包含品牌名问题库的设计有一个铁律用于监测品牌AI可见度的问题文本中不能出现任何品牌名。理由很简单如果问题已经提到了“品牌A”AI的回答中出现了“品牌A”就不能算作“AI主动提及”——那是被问题引导出来的。6.2 品牌绑定的两种模式问题本身不包含品牌名但分析时需要知道“这条问题的结果应该用来评估哪个品牌的表现”。这就产生了“品牌绑定”的概念模式一无品牌绑定问题完全开放AI回答中出现的所有品牌都被记录和分析。适用于行业榜单类监测“这个品类里哪些品牌被AI推荐最多”。模式二品类级绑定问题绑定到一个品类该品类下的目标品牌在分析时被重点关注。问题本身仍不包含品牌名。# 品牌绑定配置brand_binding_config{question_id:Q20260707_001,binding_mode:category_level,# none / category_levelcategory:运动鞋,target_brands:[品牌A,品牌B,品牌C],# 本次监测关注的目标品牌competitor_brands:[品牌D,品牌E],# 竞品品牌用于对比分析brand_inclusion_rule:问题文本中不包含任何品牌名AI自由选择提及对象}七、采样计划配置多平台、多轮次、多时间7.1 采样计划的结构有了问题库之后需要配置“什么时候、在哪些平台、用哪些问题、采多少轮”。这就是采样计划sampling_plan{plan_id:SP20260707_001,plan_name:运动鞋品牌-2026年7月常规监测,question_selection:{mode:by_filter,# by_filter / by_id_listfilters:{category:运动鞋,intents:[推荐决策,对比分析,预算限定,风险判断],scenes:[毕业旅行,日常通勤,户外运动],status:已审核},question_count:20# 筛选后的问题数量},platform_config:{platforms:[平台A,平台B,平台C],per_platform_rounds:3,# 每个平台每个问题的采样轮次round_interval_hours:2# 轮次之间的最小间隔},schedule:{start_time:2026-07-08 09:00:00,end_time:2026-07-10 18:00:00,time_zone:Asia/Shanghai},estimated_total_samples:180,# 20问题 × 3平台 × 3轮次status:待执行}7.2 采样计划的样本量估算defestimate_sample_size(plan): 估算采样计划的总样本量 question_countplan[question_selection][question_count]platform_countlen(plan[platform_config][platforms])rounds_per_platformplan[platform_config][per_platform_rounds]totalquestion_count*platform_count*rounds_per_platform# 预留10%的无效样本余量estimated_invalidtotal*0.1return{total_planned:total,estimated_valid:total-estimated_invalid,estimated_invalid:estimated_invalid,breakdown:f{question_count}问题 ×{platform_count}平台 ×{rounds_per_platform}轮次}八、结果样本表设计从问题到回答的数据闭环8.1 结果样本表的核心字段当采样计划执行后每条AI回答都需要记录在结果样本表中形成“问题→回答”的完整链路-- 结果样本表结构简化版CREATETABLEai_response_samples(-- 主键与关联sample_idVARCHAR(64)PRIMARYKEY,plan_idVARCHAR(32)NOTNULL,-- 关联采样计划question_idVARCHAR(32)NOTNULL,-- 关联问题-- 问题快照采样时的问题状态防止问题后续被修改导致历史数据不可追溯question_text_snapshotTEXTNOTNULL,-- 采样时的实际问题文本scene_tag_snapshotVARCHAR(128),-- 采样时的场景标签intent_type_snapshotVARCHAR(32),-- 采样时的意图分类-- 平台与时间platformVARCHAR(32)NOTNULL,request_timeDATETIMENOTNULL,response_timeDATETIME,-- 回答内容raw_responseTEXT,-- 原始回答response_text_cleanTEXT,-- 归一化后的纯文本response_lengthINT,-- 有效性标记is_validBOOLEANDEFAULTTRUE,invalid_reasonVARCHAR(64),-- 品牌识别结果JSON字段方便扩展brands_identified JSON,-- [品牌A, 品牌B]brand_details JSON,-- {品牌A: {mentioned: true, recommended: true, ...}}-- 元信息created_atDATETIMEDEFAULTCURRENT_TIMESTAMP,processed_atDATETIME-- 品牌识别处理完成时间);8.2 问题快照的必要性问题库中的问题可能会被修改优化措辞、调整分类标签等但历史采样数据必须保留“当时问了什么问题”。因此结果样本表中存储的是问题的快照而非外键关联到问题表的当前版本。defcreate_sample_with_snapshot(question,platform,raw_response):创建采样记录时同时保存问题快照return{question_id:question[question_id],question_text_snapshot:question[question_text],# 快照不随问题更新而改变scene_tag_snapshot:json.dumps(question.get(scene_tags,{})),intent_type_snapshot:question.get(intent_type),platform:platform,raw_response:raw_response,created_at:datetime.now().isoformat()}8.3 从样本表到分析视图样本表是原始数据层分析时通常需要创建聚合视图# 按场景×品牌×平台的聚合查询伪代码defaggregate_samples(samples,dimensions): 按指定维度聚合样本数据 dimensions: [scene, brand, platform] 等 # 实际实现中对应SQL的GROUP BY查询# SELECT scene, brand, platform,# COUNT(*) as total_samples,# SUM(CASE WHEN mentioned THEN 1 ELSE 0 END) as mention_count# FROM samples# WHERE is_valid true# GROUP BY scene, brand, platformpass九、问题库的维护与质量治理9.1 问题生命周期管理每个问题实例应管理其完整生命周期状态说明可执行采样草稿新建问题尚未审核否已审核通过质量检查可用于采样是已归档历史问题不再用于新采样否需修订发现措辞或分类问题待修改否9.2 质量检查规则defquality_check(question): 检查问题的质量 返回: (通过与否, 问题列表) issues[]# 检查1问题中是否包含品牌名核心规则known_brandsload_brand_list()forbrandinknown_brands:ifbrandinquestion[question_text]:issues.append(f问题文本中包含品牌名{brand}这会导致品牌被提示而非自然提及)# 检查2问题长度是否合理iflen(question[question_text])8:issues.append(问题过短可能无法提供足够的场景信息)iflen(question[question_text])100:issues.append(问题过长可能偏离真实用户的提问习惯)# 检查3分类标签是否完整required_tags[intent,scene,category]fortaginrequired_tags:iftagnotinquestion.get(classifications,{}):issues.append(f缺少分类标签:{tag})# 检查4与已有问题的语义去重similar_questionsfind_similar_questions(question[question_text],threshold0.85)ifsimilar_questions:issues.append(f与已有问题高度相似:{similar_questions[0][question_id]})returnlen(issues)0,issues9.3 问题库的版本管理问题库应支持版本管理每次修改都记录变更question_version_log{question_id:Q20260707_001,version:1.2,changed_at:2026-07-07 14:00:00,changed_by:编辑员-李四,change_type:措辞优化,change_detail:将有什么推荐改为有哪些值得考虑的品牌增强自然感,previous_version:1.1}十、方法边界与注意事项10.1 问题库不能无限扩大问题越多样本量越大但边际收益递减。当问题覆盖了主要的意图×场景组合后新增问题往往只是在重复已有覆盖。建议每个品类的问题数控制在15-30个之间优先保证覆盖率而非绝对数量。10.2 问题的“自然感”需要持续打磨模板生成的问题有时会带有“模板味”过于规整、缺少真实用户提问的随意感。建议定期从真实用户提问中采集表达方式反哺模板优化。10.3 问题库不能脱离行业知识同一个问题模板在运动鞋行业和餐饮行业的适用性可能完全不同。场景标签、品类特征、用户决策路径等都需要行业知识的输入。问题库的建设需要行业专家和技术人员的配合。10.4 采样结果对问题库的反哺问题库不是一成不变的。当分析发现某类问题的无效回答率特别高如AI频繁拒答可能说明问题本身需要调整。建立从“样本分析结果”到“问题库优化”的反馈闭环是长期运营的关键。十一、总结本文拆解了AI回答监测中问题库系统的设计思路核心包括六个环节问题模板设计将自然语言问题抽象为可复用的结构化模板通过占位符机制实现“一个模板生成多个场景问题”问题分类体系建立意图、场景、对象三维分类标签支持灵活的多维筛选和聚合分析场景标签管理设计主场景子场景两层标签库在问题实例化时自动关联场景分类品牌绑定策略问题文本中不包含任何品牌名通过品类级绑定实现“品牌不提示”的客观监测采样计划配置将问题库、平台、轮次、时间窗口组合成可执行、可复现的采样计划结果样本表设计用问题快照保证历史数据的可追溯性形成从问题到回答的完整数据闭环问题库是整个品牌AI可见度监测系统的“地基”。问题的质量、覆盖度和结构化程度直接决定了后续所有指标、诊断、对比的可信度。投入足够的精力在问题库建设上是整个系统长期可靠运行的保障。
相关新闻
双梁正问题 【 torch 实战】（Python代码实现）)
