People search for what they remember, not for what was written down.
Somebody wants the clause about the penalty for late delivery. They cannot remember which contract it was in, and the contract calls it liquidated damages. The search box returns nothing, so they ask a colleague, who spends twenty minutes hunting.
AI search matches meaning rather than spelling. It is the smallest useful piece of AI in most businesses, and the one people go on using after the novelty wears off.
AI search reads your documents once and stores a numeric fingerprint of what each passage means. When somebody searches, their question gets the same treatment, and the system hands back the passages closest in meaning. A search for late delivery penalty finds the paragraph headed liquidated damages, because the two say the same thing in different words.
Where it earns its place.
What a keyword box misses
- A clause somebody remembers the sense of, not the wording
- A past job like the one being quoted today
- The complaint a customer made a year ago, in their own words
- A policy written in English by somebody who asks in Kannada
- A part described three ways by three branches
What it gets pointed at
Always inside the screen where the question comes up, rather than on a separate search site.
- Contract and document libraries
- Support ticket history
- Standard operating procedures and manuals
- Product and spare parts catalogues
- Old quotations and site reports
- The internal wiki nobody can find anything in
How it gets built
- Collect
- Read into text
- Split
- Index
- Search
- Rank
- Reading the source, scanned pages included, into text
- Splitting it so a result is a passage somebody can act on
- Storing the index in PostgreSQL with pgvector, beside the records
- Keeping keyword search alongside, because exact codes still matter
- Re-indexing when a document changes, not only at launch
The index lives in the same database as your data, so there is one thing to back up rather than two systems to keep in step.
Why this is not a chatbot
Search returns the document. An assistant answers in its own words, and can be wrong in a way a search result cannot.
- A result a person opens and reads for themselves
- The source in view, so somebody can judge it
- Nothing invented when nothing matches
- Cheaper to run, because most searches never reach a model
The two work well together. Search first and answer second is the order that keeps the answer honest.
What decides whether it works
- Whether the documents are actually gathered in one place
- Whether scanned pages have been read into text properly
- Who may see which document, applied to results as well as files
- Somebody keeping the source current after go-live
None of these are AI problems. They are filing problems, and they decide the outcome more than the model does.
When this is the right choice.
- People ask colleagues for documents they know exist somewhere
- The material is written down but spread across drives, email and a portal
- Customers and staff describe the same thing in different words
- You hold documents in more than one language
- One experienced person answers the same question from memory all day
When it is not.
- Finding an invoice by its number or a customer by phone, where a filter is faster and exact
- A hundred documents one person could read in an afternoon
- A library of scanned images nobody will pay to have read into text
- A business whose real problem is that documents are never saved anywhere in the first place
Questions we are asked about it.
How is this different from the search box we already have?
Your existing search looks for the words you typed. This looks for the meaning, so it finds a passage saying the same thing in other words. Both are useful, which is why we usually keep the old one running alongside.
Do we need a separate search product?
Usually not. PostgreSQL with pgvector holds the index next to your records, which keeps backups and permissions in one place. A dedicated search service is worth it only at a size most businesses never reach.
Can it search our scanned documents?
Once they have been read into text. That step decides the quality of everything after it, so we test it on your worst pages before quoting for the rest of them.
Will it show people documents they should not see?
Not if permissions are applied to the results, which is the part most easily left until last. We take the access rules from the same place your application takes them, so a result cannot become a back door.
Does our material leave our system?
The index is built inside your own database. Producing the fingerprints needs a model, which can be a hosted service or one running on your own server where the documents may not travel.
How long before people trust it?
About as long as it takes to find something they had given up on. We usually start with the one document set people already complain about, rather than with everything at once.
Services that use it.
What it sits with.
Not sure AI search is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private