G3.02.3natural language queriesdesignresearch

Queries should accept natural language rather than requiring keywords

Aliases: natural-language search · keyword requirement · ASK

What it is

When people recall a target, what they hold is often a situated sentence: “how do I hand invoices to finance,” “that application from last week that needed a stamp.” Belkin’s ASK names the state: a need exists, but retrieval terms have not yet been carved out of the situation. Queries should accept natural language means the system must extract a searchable intent from full sentences, questions, and function words—not require the user to grind the sentence into space-separated keywords first. Requiring keywords outsources the hardest step, situation-to-index-term, to the moment before every submit.

Accepting natural language is not a promise of chat Q&A, and it is not Boolean training. It only requires that a human sentence not become zero results or scrambled ranking because it contained “how,” “that,” or “the.”

Why it happens

A keyword interface assumes the user has already finished the hardest part of formulation—picking content words that co-occur with the index, dropping function words, ordering them. Under ASK that step is incomplete. People pour the question, the spoken filler, and the content words into the box together. If the engine requires every token to appear, particles become mandatory hits and recall collapses; if it merely strips stopwords without recognizing question type (how / where / who), “how do I reimburse” and “reimburse” become the same bag, and ranking cannot prefer tutorials and procedures.

A natural-language interface treats the sentence as a carrier of intent: task verb, object, constraint, then a map onto fields and document types. That does not contradict “queries are usually short”—short queries remain the majority—but when someone is willing to type a few extra words, or speech delivers a whole sentence at once, those extra words should be signal, not noise. Forcing keywords also trains in reverse: people learn to throw nouns only, and the system never again receives the task type sitting in the verb and the question.

Studying it

Compare “must look like keywords” with “may look like a question” on the same ASK tasks.

  • Paradigms: Belkin-style situated tasks (elicit the gap, no canonical search terms); the same need issued as a question, a keyword string, and a padded spoken sentence, scoring recall and willingness to write a full sentence again; voice-query logs versus typed logs by channel.
  • Independent variables: stopword stripping, question-type recognition, whether failure says “please use keywords” or reinterprets the sentence.
  • Dependent variables: success of question queries, rate of blaming failure on “I shouldn’t have written a sentence,” whether the second attempt collapses to nouns only.
  • Methodological note: labs that forbid “wordy” queries pre-filter natural language out. Chinese has no spaces; a keyword requirement is often implemented as “don’t write sentences.” Separate length from “does it sound like speech” in the instructions. QA accuracy and “search accepts natural language” are different dependents: the former must produce an answer, the latter only needs results still ranked by intent.

Where it stops holding

Command-style tools (jump to a setting, run an action) will clash if a full sentence is treated as search; the box must declare whether it finds content or issues commands. High-precision field lookup (medical record numbers, case IDs) gets worse if natural-language tokenization splits the identifier; prefer exact match. Mixed-language strings, code fragments, and raw error messages look like language but are literals; if understanding rewrites the literal, known items vanish. Accepting natural language also does not mean a generated answer should replace the result list—the list remains the checkable finding artifact.

Applying it

  • Retrieve from questions and particle-filled submits by intent; do not send people back with “please enter keywords.” On failure, show the object and action extracted this time, rather than scolding the sentence.
  • Make stopword handling perceptible: extra “how” / “how to” should raise the weight of procedures and tutorials, not silently produce the same ranking as the bare noun.
  • Run voice and pasted sentences through the same intent path; do not optimize only for short keyboard queries.
  • Verify with ten real support utterances (questions, demonstratives, leftover politeness) against objects known to exist. Missing because “it didn’t look like keywords” means the interface still demands a translation first. Finding the object but ranking with no regard to question type is only stopword deletion, not acceptance of natural language.

Related

  • Within the group: G3.02.1 Queries users type are typically short and imprecise · G3.02.2 Advanced query syntax is almost never used
  • Adjacent: G1.04 Labeling systems · G3.03 Search suggestions · G3.17 Search result explainability
  • Search terms: natural language query · anomalous state of knowledge · query formulation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/G3.02.3