容量随项目复杂度变化,简单项目与复杂项目不能用同一数字比较
别名: 组块复杂度 · 信息负荷权衡 · chunk complexity
概念解释
工作记忆能同时保持的项目数并不是一个与内容无关的固定值,而是随每个项目本身携带的信息量变化:颜色这种单一特征的项目,能同时保持的数量明显多于同时具备形状、颜色、方向等多个特征组合而成的复杂项目。这意味着任何一个具体的容量数字,只有说明清楚"每个项目有多复杂"才有意义,脱离项目复杂度单独引用一个数字是没有信息量的。
机制
容量之所以随复杂度下降,是因为维持一个项目所需的加工投入本身与该项目携带的信息量成正比:简单特征只需要较少的资源就能维持在可提取状态,复杂的多特征组合项目需要同时维持更多相互关联的细节,消耗的资源随之增加。在总加工资源大致固定的前提下,单个项目消耗得越多,能同时容纳的项目数量自然越少——这与"槽位数固定、复杂度无关"的直觉模型不同,更接近一种总资源在项目间按需分配的机制。
怎么研究
典型范式是视觉工作记忆的变化检测任务:先用只含单一特征(比如纯色色块)的项目测出一个容量估计,再用具备多个可变特征(比如同时改变颜色、朝向和形状的复合图形)的项目重复同一任务,比较两种材料下测出的容量数字差异。如果复杂材料测出的数字明显更低,说明容量确实会随信息负荷变化,而不是一个与材料无关的常数;研究者也会系统改变复杂度的级差(特征数量从一到多递增),观察容量数字是否随之单调下降,以确认这是连续的资源分配效应而非某个阈值效应。
边界
复杂度对容量的影响会因项目之间是否共享结构而打折扣:如果多个特征之间存在被试熟悉的规律性组合(比如经常一起出现、可以被当成一个整体记住),实际消耗的资源会低于把每个特征都当独立信息处理时的预期,这也是复杂度效应和组块化能够相互作用而不是互相矛盾的地方——但这层组合策略的具体展开不属于这条边界要处理的内容。
怎么落地
- 在设计任何要求用户同时记住或比较多个项目的界面时,不要只用"项目数量"作为唯一的负荷指标,还要看每个项目本身携带多少可变信息——五个只有颜色区别的图标和五个同时包含颜色、形状、位置意义的图标,对用户造成的记忆负荷并不相同,后者应该按更严格的数量上限设计。
- 需要用户同时追踪多个复杂对象状态的场景(比如多变量的仪表盘、需要同时留意的多个进度指示),优先降低单个对象携带的独立特征数,而不是简单减少对象总数;把可以合并表达的多个特征合成一个视觉整体,能在不减少信息量的前提下降低负荷。
- 验证办法:用同样的总数量、不同复杂度级别(单特征 vs 多特征)的项目做对照测试,比较用户在两种条件下的记忆或核对错误率,用来确定当前界面的项目复杂度是否已经超出该数量下用户实际能承受的负荷。
延伸
- 同组:A6.02.1 工作记忆同时保持的项目数有限 · A6.02.2 保持时间短且受干扰易失 · A6.02.3 跨页流程要求用户记住内容即是设计缺陷 · A6.02.4 工作记忆容量的经典估计约为四个组块,而非早期认为的七个 · A6.02.5 无复述条件下,工作记忆内容在约十几秒内自然衰退 · A6.02.6 复述可延长信息留存,但会占用同一有限的加工资源 · A6.02.8 容量限制与时间衰减是两种独立机制,缓解一种不能替代另一种
- 相邻:A6.03 组块化 · A9.06 内在、外在与关联负荷
- 站内检索:
visual working memory·chunk complexity·information load per item