In this guide 6 sections
Keyword search matches the letters typed, not the meaning behind them. A clause titled liquidated damages will not appear for a search on penalty, and a part called a ferrule at one branch is a sleeve at another. Synonym lists patch known gaps. An index built on meaning closes the rest.
Why a keyword box misses a document you know exists
A keyword index stores every word of every file, then returns only the files that contain exactly the words you typed into the box. Nothing more. It has no sense of meaning.
Take a contracts manager hunting for the clause that lets a customer charge a fixed sum for late delivery, who types penalty into the search box. Nothing comes back. The agreement says liquidated damages, inside a PDF scanned from paper, so the index holds no text for that page at all.
She decides the document is missing. It is not. The index and the human used different words for one idea, and a deadline slips while she rings round the office asking who saved the file.
- A scanned PDF with no text layer, so nothing was indexed
- A clause heading in legal wording, a search in everyday wording
- A plural, a misspelling or a hyphen the index treats as a different word
- A file name that says final_v3 and tells nobody anything
Three branch names for one part
A distributor buys one steel sleeve for hydraulic hose, and three different people in three places record it under three different names. Branch one writes ferrule. Branch two writes collar. The central store enters sleeve. The supplier’s own catalogue prints only a code.
A support agent who searches the ticket history for ferrule finds the cases from branch one and none of the identical faults logged under the other two names. Every answer looks complete. So nobody suspects the gap.
Abbreviations make it worse. Staff type MS for mild steel and SS for stainless, and they use a retired model name that customers still quote down the phone line.
What synonym lists fix and where they stop
A synonym list tells the search that penalty, liquidated damages and LD clause all mean the same thing, so a query on any one returns files holding the others. It is cheap and quick. An administrator edits a plain CSV file, reloads the index, and retests the five searches that failed last week before anyone else notices a change.
The list has limits. Somebody must keep it current. It cannot catch a sentence such as the customer may recover a pre-agreed sum, because that sentence uses none of the listed words. Context is invisible to it: a collar in a plumbing catalogue is a different object from a collar in a tailoring catalogue, yet the list treats them alike.
Start here anyway. It costs an afternoon, and it shows exactly how large the real problem is before you spend more on anything heavier.
- Works well for a short, stable vocabulary such as part names
- Handles abbreviations like SS and MS once you list them
- Needs an owner who reads the failed-search log each month
- Misses ideas described in entirely different words
When an index of meaning is the cheaper repair
An index of meaning, often called a vector or semantic index, turns each passage into a list of numbers that places similar ideas close together. So a search for penalty lands beside the liquidated damages passage. No list is needed.
It earns its cost when vocabulary is wide and keeps changing, as in contract libraries, support tickets, engineering notes and tender replies that run to many thousands of pages. A synonym file for that much text becomes a part-time job nobody wants. Building the index once is cheaper.
It is not magic. Exact codes, invoice numbers and surnames still need plain keyword matching, so good systems run both methods side by side and merge the results into one ranked list. Scanned pages need text recognition first.
Test your own search before you decide
Collect twenty searches that failed in the past month, taken from the helpdesk log or from a manager’s complaints about not finding things. For each one, write down the words typed. Add the file they finally found.
Run the twenty through the current search. Add a synonym list and run them again. If most still fail, the vocabulary problem is too wide for any list, and that result becomes your argument for an index of meaning. The sheet drops straight into a brief.
- Keep the exact words typed, including the spelling mistakes
- Note which branch or team typed them
- Record how the file was finally found, by asking a colleague or by browsing folders
- Mark the ones where the file was a scan
Failed-search log
A single printed page, ruled as a log. Each failed search gets a row. The columns hold the date, the searcher, the words typed, the document finally found and the words that document really used. Three more columns give its location, scan or not, and the fix tried. A second block lists each synonym group and names who maintains it and when it is next checked.
Open a blank worksheet to printQuestions owners ask
Why does search find a file by its title but not by its contents?
Many systems index only titles and tags. Scanned pages hold no text until they pass through text recognition. Check whether the contents of your files were ever indexed. Do that before blaming the words people type.
Can we just ask staff to use the official terms?
It rarely lasts. People type what they remember, and customers use their own words. A search that bends to the user is easier to keep than a vocabulary that staff must obey. Both can run together.
Is a meaning index the same as a chatbot?
No. The index only finds passages. A chatbot may then summarise them. You can ship the better search first and add answers later, once the right passages come back reliably.
Will it also search scanned documents and photographs?
Only after text has been read from the image. Quality depends on the scan. Skewed pages, handwriting and stamps lower accuracy, so test with your worst scans before committing.