查询应支持自然语言而非要求关键词
别名: 自然语言查询 · keyword requirement · ASK
概念解释
人想起目标时，脑子里往往是一句情境：「怎么把发票交给财务」「上周那个要盖章的申请」。Belkin 的 ASK 把这种状态说成：需求存在，可用来检索的词却还没从情境里析出来。查询应支持自然语言，指系统要能从整句、问句、带虚词的说法里抽出可检索的意图，而不是要求用户先把句子碾成空格分隔的关键词。要求关键词等于把「从情境到索引词」这步外包给每次提交之前。
支持自然语言不是承诺聊天式问答，也不是让用户去学布尔。它只要求：提交一句人话时，不要因为多了「怎么」「那个」「的」就变成零结果或乱序。
机制
关键词接口假定用户已经完成了查询构造里最难的那一步——选出与索引共现的实词，丢掉功能词，排好顺序。ASK 状态下这一步还没做完。人会把问句、口语填充和真正的内容词一起倒进框里。若引擎按「所有 token 必须出现」匹配，虚词和助词变成必中项，命中骤降；若简单丢掉停用词却不识别问句类型（怎么 / 哪里 / 谁），「怎么报销」和「报销」被当成同一袋词，排序无法偏向教程和流程。
自然语言接口要做的是把句子当作意图的载体：识别任务动词、对象、约束，再映射到字段和文档类型。这与「查询很短」并不矛盾——短查询仍是主流——但当用户愿意多写几个字、或语音一次说出整句时，多出来的那些字应被当成信号而不是噪声。强制关键词还会反向训练：用户学会只扔名词，系统就再也收不到动词和问句里的任务类型信息。
怎么研究
比较「必须像关键词」和「允许像问句」在同一批 ASK 任务上的差别。
- 范式：Belkin 式情境任务（先讲清缺口，不给标准检索词）；把同一需求写成问句、关键词串、口语填充三种查询，测召回与用户是否愿意再写整句；语音查询日志与键入日志分通道对比。
- 自变量：是否剥离停用词、是否识别问句类型、失败时是提示「请改用关键词」还是按整句重解释。
- 因变量：问句查询的成功率、用户把失败归因于「不该写成句子」的比例、第二枪是否退化成纯名词。
- 方法论注意点：实验室若禁止「啰嗦」的查询，等于事先滤掉自然语言。中文没有空格分词，关键词要求常被实现成「不要写句子」，要在指导语里分开「长短」和「像不像话」。问答系统的准确率和「搜索接受自然语言」不是同一个因变量：前者要给答案，后者只要检索结果仍按意图排。
边界
命令式工具（跳转到某设置、执行某操作）把整句当搜索会与命令解析冲突，需要明确当前框是找内容还是发命令。高精度字段检索（病历号、案号）被自然语言分词切开会更糟，应优先走精确匹配。多语言混写、代码片段、错误信息原文是「看起来像自然语言、其实是字面」，整句理解若改写了字面，已知项会丢。支持自然语言也不等于每次都用生成式回答顶掉结果列表——列表仍是可核对的查找产物。
怎么落地
- 对问句和带虚词的提交按意图检索，不要用「请输入关键词」把用户赶回去；失败时展示本次抽到的对象和动作，而不是指责句子不规范。
- 停用词处理要对用户可感知：多出来的「怎么」「如何」应提高流程类、教程类的权重，而不是被静默丢弃后与纯名词完全同结果。
- 语音和粘贴进来的整句走同一套意图处理，不要只为键盘短查询优化。
- 验证：用十句真实客服口语（含问句、指示代词、多余礼貌语）搜索已知存在的对象。因「不像关键词」而找不到，接口还在要求用户先完成翻译；能找到但排序完全不顾问句类型，只是做了停用词删除，还没有接受自然语言。