Knowledge scattered
The answer to most customer questions exists somewhere: in a PDF, in an old wiki page, in a Slack thread, or in the head of the one person who has been there longest.
Chat On Your Own Data
Chat On Your Own Data
RAG, or retrieval augmented generation, connects a language model to your own documents so it answers from your material instead of guessing. Done properly it shows you where each answer came from, says when it doesn't know, and can be measured for accuracy. We usually get a first version running in three to four weeks.
In practice01 02 03 04
Does this sound familiar?
Same twenty questions
Your support team answers the same twenty questions every week, and the answers are already written down where nobody can find them.
ChatGPT guesswork
You tried uploading files to ChatGPT and it either hit a limit or made something up that sounded convincing.
Compliance said no
Someone in legal or compliance asked where the data goes, and that ended the conversation.
Context
How do we stop it making things up?
Every answer is grounded in a retrieved passage, and we show you which one. If nothing relevant comes back from the retrieval step, the assistant says it doesn't know instead of filling the gap.
Before anything goes live, we build a test set from your real questions and measure how often the system retrieves the right passage and how often the answer is actually supported by it. You see those numbers. If they aren't good enough, we fix the retrieval rather than telling you the model is imperfect.
What we build
What we build
Customer-facing assistants
Answer from your help documentation, product specs and policies, with a link to the source under every answer.
Internal assistants
Indexed on your wikis, runbooks, contracts and handbooks, so new people stop interrupting senior people.
Search over hard documents
Scanned contracts or years of project files that were never really searchable.
How we work01 02 03 04
How we work through it
04 stepsIngest and index
We connect to your document sources, chunk and embed the content, and set up the retrieval pipeline.
Week 1Build the assistant
Prompting, guardrails, source citations, and the interface your team or customers will use.
Weeks 2 to 3Evaluate
Test set from your real questions. We measure retrieval accuracy and answer grounding before go-live.
Week 3 to 4Launch and tune
Roll out to a pilot group, watch real usage, and improve retrieval where the numbers say to.
Week 4Investment
What shapes the cost
We scope each one before quoting. The things that move it:
- Part 01
Material and state
How much material there is, and what state it's in. Clean text in a wiki is quick. Ten years of scanned contracts is a different job.
- Part 02
How often it changes
A document set that updates daily needs more infrastructure than one that updates twice a year.
- Part 03
Where it has to run
Using a managed model is cheapest. Running everything inside your own network costs more and sometimes it's the only option you have.
- Part 04
How accurate it needs to be
How accurate it needs to be before you'd trust it, and how much evaluation work that implies.
- Part 05
Running costs
Running costs are separate from the build and depend on how much people use it. We'll estimate both before you commit to anything.
Good fit matters
Who this isn't for
If you need software that takes actions in your systems, not just answers questions, you want an agent, not a knowledge assistant. If your documents are a mess with no owner willing to clean them up, fixing the data usually comes before any model work.
Options
RAG, fine-tuning, or a bigger context window?
| Criteria | RAG | Fine-tuning | Bigger context window |
|---|---|---|---|
| What it's good for | Answering from your documents with citations | Teaching a model a specific style or format | Short documents that fit in one prompt |
| What it costs | Moderate build, usage-based running costs | Higher upfront, retrain when docs change | Lowest build, highest per-query cost at scale |
| Updates when docs change | Re-index, no model retrain | Often requires retraining | Re-upload or re-prompt each time |
| Can cite sources | Yes, by design | No | Sometimes, unreliably |
| Wrong choice when | You need the model to act, not answer | Your docs change weekly | You have thousands of long documents |
RAG
What it's good for
Answering from your documents with citations
What it costs
Moderate build, usage-based running costs
Updates when docs change
Re-index, no model retrain
Can cite sources
Yes, by design
Wrong choice when
You need the model to act, not answer
Fine-tuning
What it's good for
Teaching a model a specific style or format
What it costs
Higher upfront, retrain when docs change
Updates when docs change
Often requires retraining
Can cite sources
No
Wrong choice when
Your docs change weekly
Bigger context window
What it's good for
Short documents that fit in one prompt
What it costs
Lowest build, highest per-query cost at scale
Updates when docs change
Re-upload or re-prompt each time
Can cite sources
Sometimes, unreliably
Wrong choice when
You have thousands of long documents
FAQ
Frequently asked questions
KaziHasan Ali
Founder & Principal Engineer at YeasiTech. Builds production web, mobile and AI products, and writes from work shipped since 2018. More at kazihasanali.com.
Tell us what you're trying to build
Fifteen minutes, no deck. Bring us a workflow that's eating your team's time, or a product idea you want built, and we'll tell you what we think it takes, what it roughly costs, and whether it's worth doing at all. Sometimes the answer is no, and we'll say so.
+91 8910704554(WhatsApp available)
ask@yeasitech.comMon-Fri, 10AM-7PM IST (Overlaps with UK, EU, Middle East & Australia)