Users mistype. They swap letters, drop endings, and mash the spacebar. A chatbot that only understands perfect spelling feels broken, while one that quietly tolerates typos feels intelligent. The good news: effective typo tolerance needs no model — just edit distance and a vocabulary.

Edit distance basics

The Levenshtein distance between two strings is the minimum number of single-character insertions, deletions, or substitutions needed to turn one into the other. 'retrival' is distance 1 from 'retrieval'; 'embbeding' is distance 1 from 'embedding'. Most genuine typos fall within distance 1 or 2 of the intended word.

function levenshtein(a, b) {
  const prev = Array.from({ length: b.length + 1 }, (_, i) => i);
  for (let i = 1; i <= a.length; i++) {
    let diag = prev[0];
    prev[0] = i;
    for (let j = 1; j <= b.length; j++) {
      const temp = prev[j];
      prev[j] = Math.min(prev[j] + 1, prev[j - 1] + 1, diag + (a[i - 1] === b[j - 1] ? 0 : 1));
      diag = temp;
    }
  }
  return prev[b.length];
}

This single-row implementation uses O(n) memory and is fast enough to compare a query term against thousands of vocabulary entries.

Correcting against a vocabulary

Build the correction vocabulary from your own content: knowledge-base terms, topic titles, and entity names. For each unknown query word, find the vocabulary entry with the smallest edit distance, accepting corrections within a threshold that grows with word length — distance 1 for short words, distance 2 for words of seven or more characters.

Weight candidates by frequency so 'gradient' beats 'gradients' when both are distance 1 away. Frequency comes free from your inverted index document counts.

Where correction belongs in the pipeline

Apply correction before retrieval, but keep the original terms too:

  1. Normalize the query with your standard pipeline.
  2. For each out-of-vocabulary term, find the best correction.
  3. Search with both the original and corrected terms, weighting exact matches higher.

Searching both forms protects against over-correction. If the user really meant an unknown word — a new API name, say — the original term still matches documents that contain it.

Prefix and substring fallbacks

Edit distance misses some cases: transposed words, missing spaces ('neuralnetwork'), and extra spaces ('neural net work'). Add two cheap fallbacks: try removing spaces and comparing against compound vocabulary entries, and try prefix matching against autocomplete phrases. These catch the errors pure edit distance cannot see.

Knowing when not to correct

Aggressive correction creates its own failures. Never correct terms that already match content exactly, never correct inside quoted phrases, and never correct short words (under four characters) where almost everything is distance 1 away. When the best correction is ambiguous — two candidates at equal distance and frequency — keep the original and let dense retrieval or the heuristic fallback handle it.

Measuring the impact

Collect real user queries, label the mistyped ones, and check correction accuracy before and after tuning thresholds. Even a simple distance-1 corrector typically fixes the majority of typos with negligible latency, making it one of the cheapest robustness wins in any browser chatbot.