自建提问集与供应商预设提问集的区别

AI 可见度监测的一切指标都除以同一个分母——提问集。这个分母从哪来，有两条路：工具自带的供应商预设题库，或团队自建的提问集。取舍的本质不是质量高低，而是一次交换：预设题库用「业务贴合度与数据主权」换「起步速度与运维省力」，自建集作反向交换。交换的代价不在签约时显现，在使用半年后显现——题不贴业务，读数再漂亮也回答不了决策问题；序列存在别人手里，一次更换就是断代。

对照表

数据主权：序列存在谁手里

提问集的版本史是日后解释涨跌的唯一凭据——这一条决定了主权问题的分量。用预设题库有两层让渡：第一层是导出权，历史数据的导出格式、粒度、保留期限都在供应商手里，工具停服、被收购、改产品线的风险由你的时间序列承担；第二层是变更权，供应商对题库的增删改版不会按你的监测需求来，一次产品升级改写了某条题，你的历史对比就断了，而且你未必被告知。自建集的全部纪律——冻结、版本记录、新增探针并行观察——都建立在对集合的完全控制上；把这纪律套在供应商题库上，等于要求对方替你执行你的口径纪律，通常做不到。更换供应商的代价也要提前算：预设集的历史数据哪怕能导出，分母（题库）不属于你，数字迁到新分母上不可比——监测序列的连续性，本质上是分母的连续性，集合本身的分层与冻结纪律见提问集。采购合同里值得多写一行：题库变更的通知义务与历史数据的导出承诺——这行字的价值要等到你换工具那天才会显现。

可比性：预设题库给不了的那部分

预设题库最常被当作卖点的是「行业基准」：同一套题，你可以和同行比。这里必须写明一个口径事实：跨工具数字不可比，各家分母、加权、平台集都不同——同一套预设题库在两家工具上跑出的数字也不可并表，因为统计口径长在工具侧，不在题库侧。即便口径对齐了，还有一层同质化问题：你的竞品大概率也用同一套题，大家测的是同一批题上的表现，测不出你们各自客户真正在问什么——题库越普及，它的读数离你的生意越远。自建集的可比性同样有边界：它只保证自家时间序列内的可比，把自建集数字与任何外部数字并排，都要先核对分母。真正的可比性来自口径的稳定与透明，不来自题库的普及，报表层的落实见监测指标体系实操。

常见误用

一是拿预设集的「行业基准」向管理层汇报自家份额——分母不是你的题、口径不是你的口径，这个数字解释不了你自己的涨跌，它出现在汇报里的唯一正确形态是带口径限定的参考信息。二是把本地化做成「在模板上直接加词」——没走冻结与版本记录的加题，从第一天就在制造断代，正确顺序是先定集合基线再开测，跑够观察窗之后再谈增补。三是用预设集测了一段时间后才自建，然后把两段序列接成一条曲线——两套分母之间没有换算关系，正确画法是断点标注、两段各自成立。集合规模与采样次数的预算权衡在两条路上都成立：先保采样次数，再保提问数量，最后才是引擎数量。

折中做法与起步路径

从零起步的团队有第三条路：按行业模板起步再本地化。模板给结构与覆盖面——品牌词、品类词、场景题的分层与问法式样，团队按自家产品线与客户语言增删；起点是模板，落点是自建，站内为各行业准备了成组的现成提问，形态见轨道交通装备提示词集一类的模板卡。预算与人力允许的团队用双集并行：自建主集出正式读数，供应商预设集作行业参考面——两套分母各自成序列，永不并表，参考面只回答「大方向上行业在动还是我们在动」。立项前想清楚这个问题，比事后迁移便宜得多，决策框架见自建与采购的权衡；集合建成后还有维护的一半工程，季度重估、淘汰与扩充的判据见提问集维护 SOP。另一件容易与本题混起来的事是采集面：同一套提问集走 API 还是走用户真实界面，是独立的口径决策，辨析见API 监测与 UI 监测的区别。