分组维度应对齐用户决策维度，而非数据库内部字段
别名: 决策维度分组 · facet of choice · 内部字段分组
概念解释
结果可以按很多轴收组：内容类型 ID、存储分片、CMS 频道、文件扩展名、价格、卖家、成色。对用户有用的轴是正在用来做选择的那一条（decision dimension），不是表结构里最先能 group by 的那一列。买鞋时按尺码和成色收组是在帮决策；按 asset_type=sku_variant 或按所在仓库编号收组，是把内部字段投影成了界面类别。Scatter/Gather 一类方法若用的特征与任务无关，簇在算法上成立，在选择上不成立。
对齐决策维度，问的是「分开之后人能不能拿来选」，不是「数据库能不能聚得出来」。
机制
选择是在属性空间里走的。人拿当前任务激活的那几个属性比较对象——飞哪天、谁发货、哪个版本可编辑。分组把一个属性做成了列表的主结构，等于指定「先按这个比」。若指定的是内部字段（频道代号、索引类型、语言检测器的粗标签），比较会发生在用户没有的范畴上：看起来分成了块，块内仍要按真正的属性重新扫一遍，分组没有减少决策步，只是加了一层无意义的标题。
更糟的是错误的主结构会压制正确的那条。按文件类型把「同一报告的 PDF 与网页」分开，人要在两个组里各找一次；他们的决策其实是「哪一份报告」，类型只是载体。内部字段成了分割线，决策维度被拆到组间，工作记忆必须跨组拼接。
怎么研究
先引出任务的决策属性，再看分组轴是否与之重合。
- 范式：开放式前置访谈或卡片分类，问「你会根据什么决定点哪一条」；把同一结果集按决策轴、按内部字段、按文本聚类三种方式分组，做选择任务。电商里按「尺码」对按「类目 ID」、企业搜索里按「项目」对按「站点集」是典型对照。
- 自变量：分组所用字段是否来自用户提名的决策属性、组标题是否用用户词汇。
- 因变量：跨组才能完成的选择次数、组标题被当作相关范畴的比例、任务步数。
- 方法论注意点：开发者提名的「自然分组」经常就是表结构。金标准必须来自用户的决策叙述，不能来自 schema。同一集合在不同任务下决策轴会变（买 vs 退货 vs 找发票），一种分组不能假设服务所有任务。
边界
浏览型、没有明确决策属性的探索，文本主题聚类可以当临时轴，不必等待一个还不存在的「选择维度」。监管或专业界面（按案号、按记录类型）的决策轴本来就是那些正式字段，这时内部字段与决策维度重合。极度异质的混合检索（文件 + 人 + 消息）需要类型分组才能先选通道，类型在这里是决策的第一刀，不是仓库编号那种内部性。
怎么落地
- 写分组方案之前先写「用户凭什么在两条结果里选一条」，只用被提名的属性当组轴。
- 拒绝把
type_id、频道、分片、扩展名默认当成组；它们最多当次要过滤。 - 组标题用决策语言（「同一型号的其他颜色」「这个事件的其他报道」），不用内部代码。
- 验证：请未参与设计的人用组标题完成一次真实选择，问「这一组帮你比的是什么」。若答案是「不知道，好像是文件种类」，轴还停在字段上；若能说出正在做的那个选择（尺码、卖家、版本），轴对齐了。