G3.17.1field-level match attribution设计研究
结果需标明匹配发生在标题、正文还是标签等具体字段
别名: 匹配字段 · match in title · 命中位置
概念解释
一条结果能排上来，是因为查询打中了某个字段：题名、正文、作者、标签、附件名、评论。字段级归因（field-level match attribution）把这个字段写出来，而不是只在摘要里把字符涂黄。涂黄回答「这段文字里哪几个字重合」；字段归因回答「系统拿哪一层元数据当真」。题名命中与一条脚注命中的证据强度不同，人需要看见差别才能决定要不要改查询、要不要换字段限定。
它不是排序权重的公开（「标题 ×3」），而是把命中落在哪个可命名的槽里告诉用户。
机制
人按字段形成不同预期：题名像对象的真名，正文像内容，标签像他人的归类，文件名像存放习惯。命中落在哪一层，决定下一步该修哪一层——题名不对就换词，正文对了题名不对就加引号或字段前缀，只打中标签就要怀疑标签体系。不标字段，所有命中被压成同一种「包含这个词」，改写没有支点。
多字段索引还会制造假相关：查询是人名，打中的是评论区里的同名；查询是错误代码，打中的是一篇无关文档的附件名。摘要高亮可能根本看不到那个字段。归因把「为什么这条会在这里」从字符重合提升到结构位置，工作记忆才能把这条结果当成某一种证据，而不是笼统的「搜到了」。
怎么研究
操纵字段归因的有无，看查询改写是否朝正确的字段走。
- 范式：同一结果集，一种只做正文摘要高亮，一种在行上标明「题名 / 正文 / 标签 / 附件」；任务包含「只要题名里有这个词」和「正文里讨论这个词」两类。企业搜索和邮件搜索是字段丰富的现场。
- 自变量：是否显示命中字段、字段名是否用用户词汇、一条结果多个字段命中时如何并列。
- 因变量：改写为字段限定（
title:或界面上的「仅标题」）的次数、误把评论命中当对象命中的比例、任务完成率。 - 方法论注意点：若所有命中都在题名，归因没有新信息，差异测不到。要故意混入正文-only 和元数据-only 的命中。高亮与字段归因要拆开，不要把「有高亮」当成已经做了字段说明。
边界
单字段集合（纯题名目录、只有文件名的列表）标字段是噪音。屏幕阅读器上字段名必须进可访问名称，否则归因只对视力用户存在。字段名是内部代号（body_html、facet_3）时，归因会增加困惑，必须映射成用户语言。匹配发生在隐藏字段（权限 ACL、内部 ID）时不能把该字段当命中展示，否则泄露结构；应改写成「因权限或内部编号命中」或根本不拿隐藏字段当检索证据。
怎么落地
- 在结果行用短标签标明命中字段（「标题」「正文」「标签」「文件名」），多字段命中并列，不要只高亮一段摘要。
- 标签用导航和表单里的同一套词，不要用索引 schema 名。
- 提供「仅在标题中」一类后置收窄，让归因能立刻变成操作。
- 验证：混入只在标签里命中、题名完全不含查询词的对象。用户应能说出「它是因为标签才出现的」，并选择是否改成只搜标题。若只能看见一段不包含该词的题名加一段不相干的摘要高亮，字段没有被标明。