A RAG assistant that answers from your documents
We build the retrieval, permission and evaluation layer under the chat window. Every answer points at the passage it came from, so your team can check it.
- 4.8 on Clutch across 22 reviews
- PremiumAudit.io: audit cycle cut 75%, calculation errors cut 95%
- In production for SmartREI, Tankaware, ZyloBase, KiwiWrite
A chatbot that cannot show you where an answer came from is a demo, not a product. We ship assistants built on retrieval-augmented generation: the system searches your documents first, answers from what it found, and cites the passage. When it finds nothing good, it says so instead of guessing.
Why the chat window is the easy part
Wiring an API key to a chat box takes an afternoon. The hard parts sit underneath, and they are where these projects die.
Your documents contradict each other. Half the PDFs are scans. The 2019 policy and the 2026 policy both come back, and the model picks the wrong one. One user can suddenly read a salary band they should never see. Nobody notices for six weeks, because nothing tests whether the answers are still right.
We published a ranked comparison of the firms in this space, ourselves included and not at the top. Read it before you shortlist anyone.
What we build under the chat window
Ingestion per source
PDFs, wikis, ticket systems and databases each get their own pipeline. Scanned documents get OCR. A shared template makes every source slightly wrong.
Retrieval you can tune
Chunking, embeddings and re-ranking, adjusted against your real questions until the right passage comes back rather than a nearby one.
Permissions inside the query
Access filters run as part of retrieval, not as a check afterwards. A document a user cannot open must never reach the model that answers them.
Evals that gate releases
A scored question set runs before every change ships, and again on a schedule after launch. Retrieval quality drifts as documents change.
- IngestPer source, OCR where needed
- Chunk & embedSized to your documents
- Filter by accessBefore the search runs
- Retrieve & re-rankBest passage, not nearest
- Answer & citeOr say it found nothing
- ScoreEval set gates the release
The access filter sits before retrieval. Applied after, it leaks the passage into the model's context and only hides it in the interface.
The hardest part is your worst documents
Demos use clean documents. Production runs on the scanned contract, the spreadsheet pasted into a Word file, and the wiki page nobody has read since 2021.
For Greenlight, an ESG research platform, the answer had to come from independent evidence rather than a company's own reporting. That build covers more than 50 ESG topics and pulls 10 to 15 independent sources for each one, with live citations a user can click. Source selection was the product, not a detail.
- Scanned and photographed documents, handled with OCR rather than skipped.
- Conflicting versions resolved by recency and source, so the current policy wins.
- Tables kept intact, because a row split across two chunks answers wrongly.
Two ways this lands
- Enterprise: an internal assistant over a large private corpus, where permissions and an audit trail decide whether it can go live at all.
- Startup: a product or support assistant on a smaller corpus, scoped to answer a narrow set of questions correctly rather than everything badly.
The stack behind these builds
Models and orchestration
- Claude
- GPT-4
- Fireworks AI
- LangGraph
- Perplexity Sonar-Pro
Data and infrastructure
- PostgreSQL
- Redis
- FastAPI
- NestJS
- AWS
- Docker
- Vercel
Runs after launch
- Scored eval sets
- Retrieval monitoring
- Audit trails
- Access filtering
“Hashlogics' fast turnarounds stand out.”
Sil van der Woerd · Studio Birthplace
The usual chatbot build against ours
Where answers come from
The usual approach
The model's training data, with your documents pasted into a prompt when they fit.
How we build it
Retrieval over your corpus, with the passage cited on every answer.
Permissions
The usual approach
Checked in the interface, after the model has already read the document.
How we build it
Applied as a filter inside the query, so restricted passages never reach the model.
Knowing it still works
The usual approach
Someone tries a few questions by hand before launch.
How we build it
A scored question set gates each release and re-runs on a schedule afterwards.
When it does not know
The usual approach
Produces a fluent answer anyway.
How we build it
Returns nothing found, which is the behaviour regulated buyers test for first.
After launch
The usual approach
Handed over at go-live.
How we build it
We stay on under an agreed service level, or train your team and hand over.
Bring us the documents you think are too messy
Tell us what people ask and what they are allowed to see. We will tell you what retrieval can answer today and what needs cleaning first.
01Our documents are messy and confidential. Is that a problem?+
Messy is normal and confidential is the common case. Ingestion runs per source, so scans get OCR and tables stay intact. Access filters run inside retrieval, so a user only sees passages they could already open. On TrialTriage, a clinical trial matching platform, patient data is de-identified first. Age ranges, ZIP prefixes and pseudo-patient IDs replace anything that could identify a patient before the model sees it.
02How do you stop an AI chatbot from making things up?+
Three mechanisms, and none of them is a clever prompt. The assistant answers only from retrieved passages, cites the passage on every claim, and must pass a scored question set before a release ships. One more behaviour matters as much: it has to be able to return nothing found.
03Is RAG better than fine-tuning?+
Retrieval supplies facts and fine-tuning changes behaviour, so they solve different problems. Choose retrieval when answers must reflect documents that change, because an edited document is live at once. Our page on rag vs fine tuning walks through the third option people forget, which is simply putting the documents in a long context window.
04Can you add this to a product that already exists?+
Yes, and it is the common request. For Military Cruise Deals we added a conversational search module to their live WordPress site. FastAPI and LangGraph sit behind it, and results hand back to the search engine they already ran. Nothing about the existing site had to be rebuilt.
05What does it cost?+
Cost follows the data, not the chat window. The drivers are the number of source systems, how much cleaning the documents need, and how complex the permission rules are. Who owns the system after launch matters too. Scoping calls are free. Every build starts with a fixed-fee Blueprint: an engineer reads your real systems and writes the plan, with a fixed price for each milestone rather than a guess. The fee is credited in full against the build, and if the plan isn't one you'd act on, you don't pay for it.
06Who owns what you build?+
You own the code, the pipeline and the index, from the first commit. We do not hold your embeddings hostage in an account you cannot access. The first 2 months of support and maintenance are free, with every build.
Read next
- Best RAG development companies →A ranked comparison of the firms in this space, us included and not at the top.
- retrieval-augmented generation →The definition, and where retrieval stops helping.
- vector databases →Where the embeddings live, and why filtering is the hard part.
- hallucination →Why a confident wrong answer is the expensive failure.
- hire RAG engineers →Engineers who have shipped retrieval into live products.
- surviving real users →What changes between the demo and production.
