Do you need an AI assistant, or just better search?
When people need to find a document, better search with good metadata may be enough, and it costs less. When they need an answer assembled from several passages, with a citation, an assistant earns its keep. Many teams need search first.
veridive5 min read
The request usually arrives as one sentence: “We need an AI assistant, nobody can find anything on the intranet.” Both halves can be true, but they describe different problems. If people can’t find the travel expense form, an assistant is an expensive way to fix a search problem. If they find the documents but can’t work out what applies to them, better search won’t help.
The rule is simple. When people need to find a document, fix search: it costs less and is easier to trust. When they need an answer assembled from several passages, with a citation, an assistant earns its keep. When in doubt, search comes first, because most of that work is groundwork an assistant needs anyway.
What problem are people actually describing?
Look at the questions, not the request. Four kinds show up, and each points somewhere different.
| The question | What people need | Points to |
|---|---|---|
| “Where is the travel expense form?” | A document | Search |
| “Who approves purchases above the limit?” | One fact in one known place | Search, with a clear title or a pinned result |
| “Can I carry over leave if I change teams mid-year?” | An answer from several passages, with conditions | An assistant |
| “Can I get an exception to the relocation rules?” | A decision | A person |
When is better search enough?
When most questions are of the first two kinds. The fixes are unglamorous and effective:
- Titles that say what a document is. “Travel expense form” beats “Form_v3_final”.
- Metadata: owner, document type, status, audience and language, so people can filter.
- One current version. Duplicates and old versions compete with the current one in every result list.
- Synonyms and variants, including Turkish. People search “masraf” and “harcama” for the same thing, type “odeme” for “ödeme”, and use forms like “masrafların”. A Turkish-aware analyzer and a synonym list catch these.
- Pinned results for the most common queries, so “travel form” and “seyahat formu” both lead to the right page.
- Search logs. Queries with no results, or no clicks, show what is missing or badly named.
When does an assistant add real value?
When the answer depends on several passages or conditions, the documents are long, people ask in their own words, and the same questions keep reaching an expert team. That is where reading for people, rather than pointing them to documents, saves real time.
It adds value only with four things in place, each explained in RAG, explained for business teams:
- Citations to the exact passage, so every answer can be checked.
- Permissions checked at search time, so nobody gets answers from documents they couldn’t open.
- An evaluation set of real questions with approved answers, run before launch and after each change.
- “No source found” as a normal answer, instead of a guess.
Search leaves the reading to people. An assistant reads for them, and must show its sources.
What does each cost to build and run?
| Aspect | Better search | Assistant |
|---|---|---|
| Build | Clean-up, metadata, synonyms, tuning | The same groundwork, plus retrieval, prompts, citations, permission checks and an evaluation set |
| Run | Index updates and a look at the search logs | Model usage per question, quality monitoring and review of samples |
| When it’s wrong | The user sees the wrong document and usually notices | The user gets a fluent wrong answer and may act on it |
| Owner effort | Keep titles and metadata current | The same, plus approving answers to sensitive questions and reviewing unanswered ones |
The biggest difference is not the build but the running. An assistant needs someone to read a sample of its answers every week and an owner who settles the questions it gets wrong. If nobody has that time, answer quality drifts unnoticed, and better search is the more reliable choice.
Can one lead to the other?
Yes, and usually in that order. Search work isn’t wasted when an assistant follows: clean titles, retired duplicates, metadata and permission-aware indexing are exactly what retrieval needs, as the document clean-up checklist shows. A useful middle step is a search page that shows a short, cited answer above the results for question-shaped queries. It lets you measure how often the answer helps before committing to a full assistant.
How do you test which one your users need?
Collect a week of real questions from where people already ask: the HR inbox, the help desk, a chat channel. Sort each into the four kinds in the table above, and note who answered it and how long that took; that is your baseline for either option. The split tells you what to build.
In an illustrative case, an HR team collects a week of questions from its shared inbox and chat channel, a bit over a hundred. More than half are “where is…” questions about forms. About a quarter are answered by one paragraph the asker couldn’t find. Around one in eight need several documents and conditions: carrying over leave when changing teams, relocation allowances, parental leave combined with part-time work. A few ask for exceptions. The split is invented for illustration; the decision follows from it. Fix search first, with better titles, metadata and pinned results for the top forms. Then pilot an assistant only on the multi-document topics, with HR owning the answers, and keep exceptions with a person.
If almost nothing needs an answer from several documents, the honest outcome may be no AI at all; see when not to use AI.
Sort before you buy
Run the one-week sort before any vendor demo. If a real share of questions needs answers from several documents, a Discovery Sprint can scope the assistant, and knowledge and document intelligence shows what one looks like in practice.
Ask an assistant about this note