BERTopic 选题聚类：读者反馈如何整理成选题池

主题线索与需求结论

编辑面对评论、站内搜索问题和咨询记录时，真正要回答的是：哪些人在什么场景下，反复被哪个操作问题卡住？本流程把交付物分成三层：模型输出的主题线索、能够回查的反馈原文、编辑确认后的候选选题。三层分别保存，不用自动标签覆盖原文，也不让主题名称直接成为发布标题。

资料包中的 Hugging Face Blog 索引收录了 2023 年 5 月 31 日的《Introducing BERTopic Integration with the Hugging Face Hub》。这能确认相关集成文章的存在，但索引不含文章正文、中文模型配置或当前接口说明。以下表格与复核规则是面向编辑任务提出的工作方案，不是该文章的功能摘录；建模环节须在补齐当前文档后执行，本文不提供未经确认的安装命令、模型推荐或运行结果。

本题适用于尚未形成稳定标签的读者反馈聚类。已有清晰栏目、需要将稿件分配到固定类别的任务，可另看少量标注稿件的分栏与复核方法，不要把需求发现与固定栏目分流混为同一个任务。

反馈清理与问题单元

先限定同一产品或内容范围、采集时间段和允许使用的渠道。原始资料留在受限位置，建模输入使用脱敏副本。建议采用下列自定义字段，它们是团队记录字段，不代表软件自带的接口字段。

1. 去掉重复导入记录、客服固定签名和与问题无关的模板段落。语义相似但条件不同的提问先保留，不能只因都含“导出”就合并。
2. 移除姓名、电话、邮箱、订单号、访问凭证及其他敏感信息；必要的业务条件使用不含身份信息的概括表达。脱敏后再人工检查，无法确认使用权限的记录暂不纳入。
3. 一条记录含两个可独立回答的问题时，拆成两个子条目并保留 parent_id；不能独立理解的上下文应一起保留。
4. 保留动作、对象、失败现象、否定词与限制条件。例如“不能导出透明图”不能清成“导出透明图”。
5. 冻结一版输入表，记录纳入、排除、待确认和重复导入的数量。若为拆分后的问题单元计数，要明确它不等于原始反馈条数。

建模输入可按团队约定对确认的重复表达选取一条代表文本，并在统计表保留出现次数。不要为了让某个方向更显眼而复制输入，也不要把出现次数直接当成独立读者数。

中文配置核对与建模流程

“官方存在集成文章”不是“当前环境能够直接运行”的证明。新手应先完成配置核对，再交给技术同事或已核验的运行环境执行。下列步骤描述任务顺序，不声称已经完成文档核对或模型运行。

1. 在官方博客索引中按上述英文标题定位集成文章，再核对当前 BERTopic 文档。记录所用软件版本、文档版本或核对日期，以及当前示例的输入输出要求。
2. 核对候选嵌入模型的模型卡，确认中文支持说明、使用许可、输入长度限制、必要的文本预处理和运行条件。资料未提供这些信息时，配置状态记为“待核对”，不要凭模型名称推断可用性。
3. 分别确认嵌入输入与主题关键词提取所需的中文处理方式。将分词、停用词和业务术语处理约定写入配置表；不能因为文本能输入就认定中文关键词可直接使用。
4. 按当前官方示例建立最小运行环境，只输入批准使用的 safe_text，并保持文本顺序与 feedback_id 的映射。使用非敏感小批次先检查输出能否逐条回查；小批次仅用于核对流程，不用于证明主题稳定。
5. 核对通过后，对冻结的输入版本执行主题建模。归档运行编号、依赖版本、模型版本、全部配置和输出文件；失败时保留报错，不用空结果冒充“没有需求”。
6. 将实际输出整理成主题表和逐条归属表。主题表记录主题标识、关键词和成员数；逐条表记录运行编号、反馈编号及实际归属。另设编辑复核状态，避免把人工修改混入原始输出。
7. 按当前文档核实未归类或离群结果的标记含义，再提取对应反馈。本文不预设某个数字一定代表离群，也不将任何分数解释为需求成立的概率。

运行前的配置登记可采用：运行编号｜输入版本｜软件与依赖版本｜嵌入模型及版本｜中文处理约定｜建模配置｜输出位置｜接口核对状态。尚未核对的项目明确写“待核对”；此时可以继续清理反馈和人工归纳，但不能宣称已经得到建模结果。

代表性原文与主题校准

下面全部是虚构反馈和假设主题线索，仅演示对照表填写方法，不是模型生成记录，也不是本站读者需求统计。表中的主题代号由本文临时设置。

实际使用时，每个主题都要对照代表性反馈，同时补看随机成员和不符合主题解释的反例。若软件输出了代表文本，先回查它对应哪条输入，不要只阅读摘要。小主题可逐条复核；大主题的抽样范围与未读部分要在记录中说明，不能把少量样本说成整组结论。

主题关键词只用于找线索。编辑命名应尽量写成“对象＋操作阶段＋卡点”，并保留反例。例如同含“透明”和“导出”的反馈，可能分别指创建设置、文件保存或展示环境，不能强行写成一篇包办所有问题的文章。

离群项与混合主题处理

建议把下列规则作为人工复核约定，而非自动重分配规则。每次调整都记录原归属、新归属、原因和复核人。

• 离群但问题完整：保留原文，标记“独立问题待补证”。先找是否存在相似反馈，再决定是否形成候选题，不因未入组而删除。
• 离群且缺上下文：标记“需补问”，记录缺少的操作、对象或条件。不要让模型补全原文没有的信息。
• 同组存在不同目标：按原文拆出编辑子主题。若需要重跑，先保存旧结果，再对调整后的输入与配置单独编号。
• 一条反馈跨多个问题：能独立理解时拆分并关联母记录；不能拆时保留整条，注明多个需求，不强塞单一解释。
• 两个主题看似重复：只有当用户目标、操作阶段和回答范围一致时才考虑编辑合并，并保留旧主题映射。关键词接近不是充分理由。
• 重跑后归属变化：按反馈编号和原文比较成员变化，不按主题数字硬对齐。暂时无法解释的主题保持待确认，不急着排期。

常见故障与修正动作

选题入池与发布验收

完成主题复核后，再为候选题填写下面的团队模板。选题是否入池由编辑判断，不以主题成员数单独决定；需求明确也不代表已经具备撰写答案的事实材料。

选题编号：
运行编号与输入版本：
关联主题及反馈编号：
目标读者与使用场景：
已确认的操作问题：
代表性原文及反例：
记录数与去重口径：
拟定标题与回答范围：
不回答的相邻问题：
已有文章覆盖情况：
待补充的事实、界面或操作依据：
需求确认状态：待复核 / 已确认 / 暂缓
内容依据状态：待补证 / 可开稿
确认人、日期与排期意见：

以上例 F01 为例，编辑可暂拟“透明图片导出后变白怎么排查”，但必须先确认具体环境并补充格式与保存流程依据。F02 则另建创建类问题，不能因共用主题关键词就合并。示例不能替代实际需求确认，也不能直接填成“已确认”。

选题交付及文章发布前，逐项检查：

• 每个候选问题都有真实反馈编号和可回查的脱敏原文，虚构示例没有进入需求统计。
• 原始主题输出、反馈原文和编辑拟题分别存放，人工拆分与合并有理由及映射记录。
• 重复导入、相似表达、拆分问题与独立读者的计数口径已区分，没有用记录数冒充受众规模。
• 未归类项、混合主题和反例均有处理状态，未读或不确定部分没有被写成确定结论。
• 候选题已检查站内已有内容，能说明新增回答范围，而不是更换标题重复生产。
• 涉及模型、接口、界面或参数的方法已有对应版本依据；仍待核对的步骤不包装成可直接运行的说明。
• 文章中的事实答案另有资料支持，不把“读者提出问题”当成某项功能存在或某个故障原因成立的证明。
• 需求确认人与内容审核人完成复核；未满足条件的项目留在待补证队列，不自动发布。

当前可以先完成清理表、原文对照表和人工候选池。下一步应补齐集成文章正文、当前接口说明与中文嵌入模型卡，再实施建模和结果复核；在此之前，这份流程只作为编辑研究原型使用。