提问集维护 SOP：季度重估、淘汰与扩充的判据

提问集是监测的第一资产，它的维护纪律一句话说完：主集冻结、季度重估、增删留版。冻结保证历史序列可比，重估解决集合的过期问题——死词占着样本、新问法进不来，监测面会慢慢偏离真实竞争；版本记录让每次涨跌都能归因到口径还是现实。提问集的结构、三层取材与规模权衡在提问集（Prompt Set）术语卡已讲全，本页是它的运维页：重估会的议程怎么定、淘汰与扩充的判据是什么、引擎升级时基线怎么处理。

冻结与演进怎么两全？

冻结的理由站内已反复论证：问句一改，前后数据就断代——同一个意图的两种措辞，在引擎的检索与生成链路里可能是两条路径、两个页面池、两种答案（口径展开见秀虎GEO 测量方法论）；放任演进，监测就失去可比性。但完全不演进也不成立：业务在变、买家的问法在变、竞品在换，两年前的题集到今天测的可能是一个不存在的市场——冻结保护的是序列，牺牲的是代表性，牺牲过头监测同样失真。

两全的解法是主集冻结加观察名单并行。主集的问句一字不改；新问法先进观察名单，以新增探针的方式与主集并行采集，跑够一个观察窗，确认有区分度、有业务含义，再在下一次季度重估时正式转入主集——转入也是新增，不是对旧句的改写。要淘汰的旧句走相反的方向：先停采、保留历史数据、在版本记录里声明退出的日期与理由，而不是悄悄删除。这样序列不断、集合也不腐，冻结与演进各管一半。观察名单的并行期有成本：监测预算要在一段时间内同时覆盖新旧两批题，所以观察名单同样要节制，进门先过「这道题回答什么业务问题」的判据。

冻结的颗粒度也要说全：不止问句正文，拼写、语序、量词、语言版本一并冻结——同一问句有无量词、简繁差异、中英差异，都可能指向不同的检索供给与不同的答案。把每条提问当代码资产管理：有编号、有版本号、有变更日志，改一个字也要走记录。麻烦是真实的，但比起涨了不知道为什么、跌了不知道怪谁，这点麻烦是成本最低的方案。

季度重估的议程怎么定

季度重估是固定议程的会议，不是随想式的增删，五步走完、产出一份版本记录。第一步覆盖盘点：逐条过主集，看近一个季度的数据健康度——长期缺失、长期无区分度（每家的答案都差不多、从来分不出高下）的题标为候选处置。第二步新问法取材：从搜索控制台的真实查询、客服与销售记录的客户原话、社区里新出现的问法、新业务线带来的新场景里收集候选——取材渠道与建集时相同，优先级同样是离成交越近越先进。第三步候选试跑：新问法以观察名单身份并行采集，用业务判据筛一道。第四步增删定稿：淘汰判据过一遍死词候选，扩充判据过一遍新词候选，确定新版本。第五步版本记录：版本号、增删清单、断点声明（从哪天起用新版本）入库——每次增删留版本记录是站内口径的底线纪律（见监测指标体系实操），没有版本化的题集，涨跌都说不清原因。

会议纪律一条：重估会的产品是版本记录，不是口头共识——会开完没有版本号入库，等于没开。另一条纪律是增删留痕到问句级：改了哪条、为什么改、谁拍的板，逐条可查，这不是文牍主义，是日后解释数据断点的唯一凭据。

什么词能删、什么词能进？

淘汰三类判据。业务消失：产品线下架、市场退出、政策变更使题目失去意义——题随业务走，业务没了题就删。问法灭绝：取材渠道里真实用户已不再这样问——判据是渠道证据，不是团队的语感；自以为过时的问法，在渠道里还大量出现，就不过时。长期病题：反复采集失败、或长期无提及无引用且无策略含义。但删病题之前先过一道自检：这道题测不出，究竟是题死了，还是你在这道题上真的缺席？后者是真实缺口，删掉它等于把不利的考题从考卷上撕掉，监测就失去了预警功能——自检过不了的题留下、加标注，转给内容与渠道团队处理。

扩充三类判据。新业务新场景：新产线、新市场、新政策带来的新问法，这是最正当的扩充来源。新竞品入场：值得单独立对比题追踪的新玩家——对比题测的是被点名后的叙事质量，与份额读数分开记、分开读。监测中的意外发现：例行采集时撞见的、题集没覆盖但真实出现的高价值问法，回填到取材渠道里走正常流程入库。扩充时还有一条归并规则：同一意图的不同措辞不要都收——以「回答的业务问题」为归并单位，一条业务问题保留两三种主流问法，超出部分进观察名单而不进主集；归并做粗了同一需求被重复计权，做细了问法覆盖不足，两三种是实践里平衡的落点。增删之后做一次配比回检：品牌、品类、买家问题三层的配比回到站内口径的取向——约 2:4:4、权重压向「不知道你的人」（口径见监测指标体系实操页）——防止几轮增删之后，集合慢慢滑成品牌词收藏夹。最后是采样预算的联动：题量与每题的观察密度此消彼长，采样不足的格子不报环比——扩集之前先确认监测预算跟得上，否则宁可不扩；五十条观察密度够用的题集，好过五百条只够问一轮的收藏夹。

引擎升级时怎么办？

比季度更急的一种维护触发器是引擎侧变更：换模型、改引用策略、答案风格突变，都会让历史基线的可比性失效。纪律是把版本变更标在趋势图上，变更点之后的数据与新基线分段比较，不跨断点连读（机制背景见模型版本漂移（Model Version Drift））；变更后先观察、再定标，不立刻判涨跌。变更的发现没有万全之法——静默升级只能靠答案风格与引用结构的异常变化间接察觉——但察觉后的动作是固定的：标注断点、观察一个窗口、重估基线。

还有一层提醒：单次读数的噪声本来就大到足以淹没真实变化（采样方差的展开见采样方差（Sampling Variance）卡），所以任何维护决策都要等窗口——这是把「维护」与「折腾」区分开的唯一标准。看到几天不理想就想改题集，与看到几天不理想就想换服务商，是同一种错误。业务侧的大变更同理：品牌更名、产品线重构这类事件之后，涉及旧名称的题不要当场改写，新旧两组题并行一个窗口，让新旧口径的过渡在数据里留出轨迹，之后才按淘汰与扩充的正常判据定稿。本页议程的表单化版本（勾选式清单）见站内的提问集维护 SOP 清单，方法页讲判据，表单管执行，两页配合使用。

限制自曝

• PM-01：本页为站方方法组织，议程与判据为站方演绎，无独立实验数据支撑；
• PM-02：季度是站内默认节奏，业务变化快的团队可加密，变化慢的可拉长，版本记录的纪律不变；
• PM-03：淘汰与扩充判据依赖取材渠道的质量，渠道覆盖薄的团队判据会失灵——先补渠道再谈维护；
• PM-04：引擎侧变更的发现依赖版本公告与人工识别，静默变更存在漏标可能，断点记录以已知变更为限。