G3.17.3disclose implicit filters设计研究
系统隐式施加的过滤条件需要向用户说明来源
别名: 隐式过滤 · silent constraints · 系统代筛
概念解释
安全搜索、所在地区、语言、租户隔离、「隐藏已读」、仅显示有权限的对象——这些约束常常在查询发出之前就被系统加上，用户没有勾选任何筛选芯片。隐式过滤要说明来源：名单被谁切过、凭什么切、怎么关掉或改掉。不说明时，人会把被切掉的对象当成不存在，或把责任推给自己的查询词。它和用户自己打开的筛选不同：那些筛选已经作为芯片出现；这里处理的是芯片从未出现过的刀。
也和个性化排序不同。排序改变的是先后；隐式过滤改变的是集合里还有没有这个对象。
机制
过滤在检索管道的上游把候选丢掉，下游的排序和摘要再也看不见它们。人用「搜不到」来更新世界模型。若丢掉发生在视线外，世界模型会被系统政策改写，当事人还以为是内容或自己的用词有问题。后续改写会朝错误方向走：加词、换同义，而真正该动的是那把没露面的刀。
来源说明把过滤从管道内部抬到可指责的界面状态。状态一旦可见，就可以被撤销、被质疑、被解释给别人（「不是没有，是安全搜索开着」）。不可见的政策没有这些挂钩，只能通过偶然关掉某个总开关才被发现，发现成本接近于故障排查。
怎么研究
把目标放在被隐式过滤切掉的一侧，比较有无来源说明。
- 范式：安全搜索或地区限制会藏起目标；一种条件完全静默，一种在结果区或零结果页写明「已按安全搜索 / 你所在地区过滤」并提供关闭。查询日志里「明明在库里却报告搜不到」的工单，常能追溯到未披露的租户或权限过滤。
- 自变量：是否披露过滤、披露位置（框旁 / 结果顶 / 仅设置页）、能否在当次查询撤销。
- 因变量：找回被切对象的成功率、把缺席归因于「库里没有」的比例、无提示找到撤销入口的时间。
- 方法论注意点：被试若不知道目标存在，测到的是普通零结果，不是隐式过滤。必须先让他们见过该对象，或明确告诉他们「有一篇叫这个名字的文档」。权限过滤的披露不能泄露他人文档的存在，实验设计要避开这个安全坑。
边界
安全与合规过滤有时不能被本人关闭（监管、儿童账号、企业 DLP）。仍要说明「被政策挡住」，不能假装成零命中；关闭入口可以换成「申请访问」。反垃圾和反钓鱼的过滤若全部披露规则，会变成绕过手册，来源说明应停在「已隐藏疑似垃圾」这一层，不列检测器细节。性能层的截断（只评前一万条）不是语义过滤，写成「未评完」比写成一种筛选更诚实。
怎么落地
- 把系统加上的每一条仍在生效的约束列在结果页顶部，用与用户筛选芯片不同的样式，标明「系统」或政策名。
- 能关的提供当次关闭；不能关的写明原因和申诉路径，不要做成灰掉却可点的假芯片。
- 零结果时优先检查隐式过滤，文案先说「被某某条件排除」，再说「没有匹配」。
- 验证：打开会藏起已知对象的安全或地区策略。结果页应出现该策略的来源，关闭或申请之后对象应能出现。若对象消失且任何地方都写着「无结果」而不提策略，来源没有被说明。