Sites that load fast and convert
Custom builds and integrations
Bounded, auditable, human-approved
Being found, staying fast, staying safe
Retrieval-augmented generation is the unglamorous name for something straightforward: before the model answers, the system finds the passages in your own material that bear on the question, and requires the answer to come from those. What you get back is checkable.
The value is not that it sounds knowledgeable. It is that every claim points at a document you can open. When an answer is wrong, you can see exactly which passage misled it and fix the passage — which is a far better position than arguing with a model's memory.
Drag your cursor over the panel ↓Three options
There are only three, and the differences in cost, freshness and traceability are large enough that picking wrong is expensive.
Fine-tuning gets proposed far more often than it should be. It teaches a model a style or a format well and facts poorly, and every time your content changes you are back where you started.
Whatever it absorbed during training. Broad, frozen at a date, impossible to attribute, and it has never seen a single internal document of yours.
Fails atAnything specific to your business, anything recent, and anything that needs a source.
Adjusting the model's weights on your examples. Effective for teaching tone, structure and classification. Poor at teaching facts, and stale the moment a document changes.
Fails atFreshness and citation. Updating means another training run.
Find the relevant passages at question time and require the answer to be built from them. Update a document and the next answer reflects it immediately.
Good atFresh, attributable, permission-aware answers over content that keeps changing.
Interactive
Before anything can be retrieved it has to be cut into pieces. How you cut is the single most consequential decision in the whole system, and it is the one most often made by accepting a default.
Drag the size slider and switch the strategy. Fixed-length splitting severs sentences mid-clause — amber blocks show where. A chunk that ends halfway through a condition is worse than useless: it retrieves confidently and answers with half a rule.
The stack
Most of a knowledge system is a search problem, and search has been engineered for decades. The choices below are made per project — a few thousand documents and a hundred million behave nothing alike.
Embedding & language models
Vector & keyword index
Ingestion pipeline
Where the knowledge already lives
Applications
Each one starts from the same complaint: the answer exists somewhere in our own material, and finding it takes a person who already knows where to look.
Policies, procedures and past resolved tickets made answerable, so new team members stop interrupting the person who has been there longest.
Best first project for most teams
Public documentation and help articles made conversational, with a clean handover to a person the moment confidence drops.
Deflects the repeat questions
Agreements, terms and coverage documents searchable by question — what notice is required, which clause governs, what is excluded.
Finds the clause, does not interpret it
Customers describing a problem rather than naming a product, matched against specifications, compatibility notes and manuals.
For catalogues too large to browse
Reports, studies and archives made queryable, with passages surfaced rather than documents, so nobody skims forty pages for one paragraph.
For archives nobody has time to read
Equipment documentation, service histories and troubleshooting guides answerable from a phone by someone standing in front of the machine.
Where the answer is needed on site
Interactive
Three questions against the same imaginary company handbook. Pick one and see what was retrieved, what scored too low to use, and how the answer is assembled from what survived.
The third question is the important one. Nothing in the source material answers it, and the correct behaviour is to say so rather than to produce something plausible. A system that cannot decline is a system you cannot trust on the questions that matter.
Honesty
When one of these underperforms, the cause is almost never the model. It is one of the following, and all of them are addressable.
Split by character count with no regard for structure, so half the pieces begin mid-thought and end mid-condition. The lab above shows what that looks like.
Vector similarity is a coarse first pass. Without a second model reordering the shortlist, the genuinely best passage frequently sits fourth.
Embeddings are poor with part numbers, names and codes. Serious systems run keyword search alongside and merge the results.
Documents changed and nothing re-indexed them, so the system answers confidently from a version that was replaced months ago.
Scanned documents, multi-column layouts and tables need real extraction work. Naive text pulling turns a pricing table into unusable soup.
Internal acronyms and product nicknames that appear nowhere in the documents. Queries need expanding before they are matched.
Access filtering has to happen during retrieval, not after. Retrofitting it is difficult and the failure mode is showing someone a document they should not see.
If nothing relevant is found, the system must say so. Without a floor on relevance it will answer from weak matches and sound certain doing it.
Sometimes the documentation genuinely does not contain the answer, is contradictory, or was never written. No retrieval system fixes that.
Scope
Roughly two thirds of the work happens before a model is called at all.
Finding where the knowledge actually lives, what is current, what contradicts what, and what will need writing before anything can answer from it.
Getting clean text out of PDFs, wikis, ticket systems and shared drives — including the awkward ones with tables, scans and multiple columns.
Boundaries that follow the structure of your documents, tuned against real questions rather than accepted from a default.
Vector and keyword search together, with a reranking pass, because neither approach alone is good enough on real business content.
Access checks applied during retrieval so results are filtered before they are ever assembled into an answer.
Answers constrained to the retrieved passages, with citations verified to point at material that was genuinely used.
Re-indexing when documents change, on a schedule or by event, with visibility into what is current and what has drifted.
Real questions with known good passages, so retrieval quality is a measurement rather than an impression.
Logging what people asked that nothing could answer. This is frequently the most valuable output of the whole project.
Questions
Retrieval-augmented generation. The system retrieves relevant passages from your content first, then asks the model to generate an answer using only those passages.
The name is unhelpful. The idea is simple: look it up before answering, and show your working.
Search returns documents and leaves the reading to you. This returns an answer assembled from the relevant passages, with links to them.
Underneath, it is search — which is why the quality of the retrieval matters far more than which model writes the final sentence.
Fewer than most people expect. A few hundred pages of genuinely useful, current material outperforms tens of thousands of pages of duplicated drafts.
Quality and currency beat volume comfortably. If three versions of a policy exist and nobody knows which is live, that is the first problem to solve.
It should say so. A relevance threshold means weak matches produce "I could not find this" rather than an invented answer, and the question gets logged.
That log is genuinely valuable. It tells you exactly which documentation is missing, ranked by how often people need it.
Yes, and it must. Permission filtering is applied during retrieval, so a passage someone cannot access is never a candidate for their answer in the first place.
Getting this right is design work, not a setting, and it needs to be in the plan from the start.
A refresh pipeline re-indexes changed material — on a schedule, or triggered when something is edited. The next question reflects the new version.
This is the main practical advantage over fine-tuning, where a change means another training run.
Usually. PDFs, wikis, shared drives, ticket systems and databases are all normal sources. Scanned documents and heavy tables need more extraction work, which we assess early because it changes the estimate.
If a source has no API, there is almost always an export route.
By measuring it. We build a set of real questions with the passages that should be found, then track how often the right passage appears in the results and how often answers stay faithful to them.
Without that set, every change is a guess and "it feels better" is the only available verdict.
Call back
Leave a number and a good time. We will call you back to talk about what you are trying to build — no charge for the conversation.
Or call us directly +1 (647) 385-5532