用户查询通常短且不精确
别名: 查询构造 · short queries · 短查询
概念解释
人在搜索框里真正键入的，往往是两三个词、而且对不上索引里的那个精确标题。这是查询构造（query formulation）的常态，不是用户「搜得不认真」。Furnas 的词汇问题早已指出：同一对象，人会用许多不同的词去叫，任意一个用户第一次想到的那个词，与系统选用的那个词重合的概率很低。查询日志里的长度分布长期偏短，不精确是短的连带结果——词少，能用来消歧的约束就少。
短且不精确描述的是提交出去的那串字符。它不解释用户为什么不用布尔语法，也不要求系统改去理解整句口语；那是相邻的问题。
机制
构造一次「足够好」的查询，要同时做三件事：从目标里抽出可键入的属性、把属性译成系统可能认识的词、决定写到多细。工作记忆装不下这三步的完整产品，人会停在代价最低的那一版——通常是脑子里最先冒出的两三个词。站点内搜索尤其明显：用户以为集合很小，「报销」就该 uniquely 指向那份制度，于是不再补「差旅」「2024」「财务」。
不精确还有来源：用户记得的是情境而不是标签（「上次那份要盖章的」），或只记得部分字符串（「好像带个差旅」）。短查询进入排序后，高气味的热门项会压过那个真正被记得的冷门项，看起来像排序有问题，其实是查询没有提供足以压过热度的区分度。系统若假定「用户会写出完整标题」，等于把查询构造的认知成本全部推回给用户。
怎么研究
先量真实查询长什么样，再谈界面该补哪一层。
- 范式：查询日志分析（token 数、唯一查询占比、同一会话内的改写次数）；已知项任务里只给情境不给标准标题，记录第一枪查询与目标标题的重叠；Hearst 对 Web 与站点搜索查询长度的对照。
- 自变量：任务是否提供标准名称、集合规模的可见提示、是否有查询建议可借用更长的说法。
- 因变量：首查询长度、首查询是否命中目标、会话内查询变长还是换词、把失败归因于「没有」还是「我词没写对」。
- 方法论注意点：实验室任务书若写出目标全名，首查询会被拉长，长度分布会假性接近「精确」。要用现场日志或只给情境的任务。平均长度会掩盖双峰（极短导航型 vs 稍长主题型），要分任务类型报，不要只报一个均值。
边界
专家库、法律检索、命令面板的用户会写出更长、更像标识符的查询，短查询假设不成立。语音输入和粘贴进来的整句会突然变长，长度统计要把输入通道分开。强制用户写满才能提交（最少 N 个字）不会让查询变精确，只会逼出凑字或放弃。当集合用唯一编号做主键、用户手里也有编号时，短查询反而是精确的——短不等于不精确，不精确来自词与对象之间的一对多。
怎么落地
- 按真实日志的长度分布设计，而不是按「理想查询」设计：默认按两三个词也能给出可判断的结果。
- 在结果页暴露可用来加长查询的线索（完整标题、同义词、所属类），让第二枪有材料，不要只说「请输入更精确的关键词」。
- 不要把空状态的锅只甩给用户用词，先核对短查询下目标是否至少出现在前几页。
- 验证：从日志抽出高频短查询，人工看目标是否在首屏。大面积不在，是索引和排序在惩罚短查询，不是用户需要被教会写长句。