AI and ML
An AI Assistant on Your Own Knowledge Base: How RAG Works and What It Costs
How a RAG assistant differs from a button-tree bot and from an LLM with no data, where hallucinations come from and what actually reduces them, what SaaS costs against a custom build, and which month the project breaks even.
In short
A RAG assistant retrieves an answer from your own documents and replies from the retrieved passage with a link to the source. Market pricing: SaaS platforms from around 59,000 RUB a month, custom development from around 500,000 RUB plus 10,000-50,000 RUB monthly support. Veltos.Tech builds AI/ML projects from 180,000 RUB. At 3,000 tickets a month, break-even lands in month 11 or 12.
Four generations of bots and why the first two disappointed
The first generation was the button-tree bot. It worked in exactly the branches somebody had drawn in advance, and any question outside the tree hit a wall of "please choose one of the options". Users quickly learned to press "talk to an agent" as their first action, which showed up in reports as high support load alongside a working bot. Those bots are not useless, but they automate navigation rather than answers.
The second generation was a bot on a large language model with no access to your data. It writes fluently, handles any topic, and asked about delivery times to a specific city it confidently names a figure that does not exist. That is the core problem of generation two: excellent form without knowledge of the facts. In corporate support such an answer is worse than no answer, because the customer believes it and acts on it.
The third generation is the RAG assistant. Before answering, the system retrieves relevant passages from your knowledge base and answers strictly from what it found, showing which document the answer came from. This is the first generation you can put in front of real support traffic, because the answer is verifiable: the user sees the link and you see in the logs which passage was used. At this level the bot stops being a toy and starts removing load.
The fourth generation is an agent embedded in the process. It does not only answer, it acts: checks an order status in the accounting system, creates a ticket, changes a delivery date, escalates to a human with the context already assembled. Practice shows the real value appears here rather than in a chat window. An assistant that drafts an answer for an agent inside their own ticketing system delivers more than a standalone widget on a website that people have to visit on purpose.
How RAG actually works
It starts with preparing the base. Documents, meaning policies, instructions, product descriptions and question archives, are cut into passages of a few hundred words, usually with overlap so that a thought is not severed mid-sentence. Chunking matters more than it sounds: oversized chunks drag noise into the answer and confuse the model, undersized ones lose context until the passage stops making sense on its own. Half the eventual quality is decided at this step.
Every passage goes through an embedding model and becomes a vector, a set of numbers representing its meaning. The vectors go into a dedicated store. When a question arrives it is turned into a vector the same way, and the system retrieves the passages closest to it in meaning rather than in wording. That is why "can I return an item if the size does not fit" finds the policy section on exchanges and returns even when the phrase "does not fit" appears nowhere in it.
The retrieved passages then go into the prompt alongside the question, and the language model formulates an answer grounded in that context. The critical instruction in the prompt is to answer only from the supplied material and to say plainly when the answer is not there. The final step is citation: the reply carries a link to the document and section. That is not decoration but a control mechanism, letting the user verify and letting you reconstruct any disputed answer from the logs.
The obvious question: why not fine-tune a model on your data? For most business cases RAG wins on three counts. Updates: changing an answer means replacing a document in the base rather than running a training job. Transparency: RAG shows its source, a fine-tuned model does not, and diagnosing its mistakes is fundamentally harder. Cost: preparing and launching RAG is measured in weeks, while quality fine-tuning takes months and needs a volume of data most companies simply do not have.
- Chunking: a few hundred words with overlap, cut on meaning boundaries rather than character counts.
- Embeddings and a vector store: retrieval by meaning instead of keyword match.
- A prompt carrying the retrieved context and forbidding answers beyond it.
- Source citation as a verification mechanism rather than a formatting flourish.
- Knowledge updates by replacing a document, with no retraining involved.
Where hallucinations come from and what genuinely reduces them
The first source of errors is not the model at all, it is the base. If a company holds three versions of the returns policy, two obsolete and one current, retrieval will honestly find any of the three and the assistant will honestly quote the wrong one. This is the most common and most underrated case: the system works correctly and answers incorrectly because the source contradicts itself. So the first work in a project is not prompt writing but a document inventory, deduplication and naming an owner for each part of the base.
The second source is failed retrieval. When no relevant passage is found, a weakly instructed model completes the answer from general knowledge, and the result is fluent, confident and wrong. The fix works at two levels: a relevance threshold below which the system concludes it found nothing, and a hard instruction to reply "the knowledge base has no answer to this" instead of trying to help. An explicit refusal is not a weakness of the system, it is a mandatory property of it.
The third layer of defence is human handoff. The assistant has to escalate: on refusal, on a second misunderstood question, on clear user frustration, and on any topic from a stop list such as money, legal commitments or personal data. A correct escalation hands the agent the assembled context rather than restarting the conversation. That matters for perception more than people expect: customers are not annoyed that the bot could not help, they are annoyed at having to repeat everything afterwards.
And last, without which none of the above holds: logging and regular audit. Every answer is stored together with the question, the retrieved passages and the user rating. Once a week a person reviews a sample, usually a few dozen cases is enough, and assigns each error a cause: nothing found, wrong thing found, source outdated, prompt allowed a liberty. Without that loop the assistant will be noticeably worse in six months than it was at acceptance, and nobody will be able to say when that happened.
The full cost model: SaaS versus a custom build
The market offers two fundamentally different paths. A ready SaaS platform: you upload documents, configure a widget and pay monthly. Business tariffs on the Russian market start around 59,000 RUB per month and rise with request volume and channel count. A custom build: the system is shaped around your processes and integrations, with market pricing from roughly 500,000 RUB and support at 10,000 to 50,000 RUB per month. Veltos.Tech starts AI/ML projects at 180,000 RUB, which typically funds a pilot on one process with a limited knowledge base.
Both numbers are almost always understated, because neither includes the most labour-intensive part, which is preparing the knowledge base. Documents have to be gathered from different places, converted to a parseable format, deduplicated, stripped of obsolete versions, split into internal and customer-facing, and assigned owners. In an average company that is two to four weeks of work, and it has to be done by someone who knows the subject matter rather than by the vendor. Projects that failed usually failed here rather than on the technology.
The second forgotten line is model requests. Every answer costs money, and with RAG the cost is higher than expected, because the prompt carries the retrieved passages alongside the question, making one request several times larger than the user message. Compute it as monthly conversations times average request size with context times the rate, then double it as headroom for retries, debugging and the load growth that follows a successful launch.
The third and fourth lines are integrations and quality control. An assistant not connected to your CRM and accounting system answers only general questions and cannot handle "where is my order"; integration is what turns a reference desk into a working tool, and it usually accounts for a visible share of the estimate. Quality control is the continuous work described above: sampling, error analysis, document updates. If that line is missing from the budget it appears anyway, in the form of customer complaints.
| Cost line | SaaS platform | Custom build | Note |
|---|---|---|---|
| Getting the system up | Setup in days, often included in the tariff | from ~500,000 RUB on the market, pilots from 180,000 RUB | Custom pays back through volume and integrations |
| Knowledge base preparation | 2-4 weeks of work on your side | 2-4 weeks, partly delegable to the vendor | The most underestimated line in both options |
| Licence or subscription | from ~59,000 RUB per month on the market | None | Grows with request volume and channel count |
| Model requests | Usually inside the tariff, extra beyond the limit | Pay as you go, size it with a 2x margin | With RAG the prompt carries context, not just the question |
| CRM and accounting integrations | Only where the platform supports them | Any of them, as a separate estimate line | Without them the assistant cannot answer "where is my order" |
| Quality monitoring | Platform reports plus your own sampling | Your own metrics and logs with sources | A few hours a week, continuously |
| Support and iteration | Included in the subscription | 10,000-50,000 RUB per month on the market | The knowledge base changes more often than the code |
| Data residency | Depends on the platform and needs checking | Full control, on-premise possible | Critical where personal data and residency rules apply |
A worked ROI on a concrete scenario
The payback formula is simple: saving equals cost per conversation times volume times the share of automatable topics times automation quality, minus total cost of ownership. Take an illustrative but typical scenario: support receives 3,000 conversations a month, an agent spends about eight minutes on each, and the fully loaded agent hour is roughly 500 RUB. So one conversation costs the company about 70 RUB and the whole function around 210,000 RUB a month.
Then come two coefficients people usually inflate. The share of conversations whose answer genuinely exists in the knowledge base is realistically around 60%; the rest need data from systems or a human decision. Of that 60%, the assistant closes roughly 70% without an agent, because some users go to a human regardless and some questions arrive phrased too awkwardly. That automates about 1,260 conversations a month, worth roughly 88,000 RUB in saving.
Now the cost of ownership. For a custom solution: 600,000 RUB of development plus about 35,000 RUB a month for model requests, infrastructure and quality control. Net saving lands around 53,000 RUB a month and break-even falls in month eleven or twelve. For SaaS: 150,000 RUB of base preparation plus a 59,000 RUB monthly subscription, net saving around 29,000 RUB a month and break-even in month five or six.
The interesting part of the comparison is not that SaaS breaks even sooner but where the two paths cross. Cumulative spend levels out around month nineteen: before that the subscription is cheaper, after it the owned solution is. The practical conclusion follows: with a planning horizon under eighteen months or modest conversation volume, start with SaaS, and that is honest advice regardless of who gives it. A custom build is justified by volume, integrations and data residency requirements rather than by a wish to own something.
| Parameter | Value | Note |
|---|---|---|
| Conversations per month | 3,000 | Below 1,000 the economics usually do not work |
| Cost per conversation | ≈ 70 RUB (8 minutes at 500 RUB per hour) | Use the fully loaded hour, not the salary |
| Current support cost | ≈ 210,000 RUB per month | The baseline for comparison |
| Share of topics covered by the base | 60% | The rest needs system data or a human |
| Share closed without an agent | 70% of covered topics | A realistic coefficient rather than a marketing one |
| Monthly saving | ≈ 88,000 RUB | 1,260 conversations at 70 RUB |
| Custom: build and running cost | 600,000 RUB plus 35,000 RUB per month | Net saving ≈ 53,000 RUB per month |
| Custom: break-even | Month 11-12 | Saving accumulates from there |
| SaaS: setup and subscription | 150,000 RUB plus 59,000 RUB per month | Net saving ≈ 29,000 RUB per month |
| SaaS: break-even | Month 5-6 | Sooner, but the ceiling on saving is lower |
| Where cumulative costs cross | ≈ month 19 | SaaS is cheaper before it, the owned solution after |
Data and law: where everything is stored
The first question to ask before choosing a platform: what data will enter the system at all. If the assistant answers only from public materials such as service descriptions, delivery terms and instructions, the legal regime is simple. The moment a name, phone number, order number or the content of a specific customer conversation enters the dialogue, you are processing personal data and the system falls under residency rules, including the obligation to keep the primary database inside the country.
Practical limits follow. Foreign SaaS support platforms are in most cases unsuitable for personal data without separate legal work. Sending conversation fragments to a foreign model API is processing too, and has to be assessed. The workable options are: domestic models available through APIs in local clouds; open models deployed inside your own perimeter; or an architecture that strips personal data out of the request before anything leaves for an external service.
On-premise deployment has stopped being exotic: mid-size open models run on a single GPU server and deliver quality sufficient for support tasks over your own knowledge base. The price is the hardware or its rental, the upgrade work and noticeably higher demands on the team. The sensible logic: the more sensitive the data and the higher the request volume, the stronger the case for your own perimeter; for a small public knowledge base it is overkill.
Rollout: pilot, metrics, scale
The correct sequence is one process, then metrics, then expansion. The pilot takes the most frequent and most homogeneous topic, for instance delivery and returns questions where the answer definitely exists in a policy and needs no data from the accounting system. The knowledge base is limited to that topic, the assistant launches in one channel, and four to six weeks of statistics accumulate. Launching everything at once produces mediocre quality across all topics and no way to tell what to improve.
Three kinds of metric are needed. Coverage: what share of questions got an answer rather than a refusal. Quality: what share of answers a human rates as correct on a sample, specifically a human rather than an automated metric, because automation cannot distinguish a confidently phrased wrong answer. And a business metric: the share of conversations closed without an agent and the change in first response time. The third group decides the fate of the project, the first two explain why the result came out as it did.
Scaling runs along two axes: new topics in the knowledge base and new channels. Expand one axis at a time so that any quality drop remains explainable. And the more profitable axis is almost always not another channel but the move from answering to acting: an assistant that can check an order status and create a ticket removes more load than the same assistant added to one more messenger.
When not to do it at all. First, low volume: at a couple of hundred conversations a month no saving covers the cost of ownership, and the honest answer is "not yet". Second, a chaotic knowledge base: if there are no current documents and the knowledge lives in people heads, the cleanup comes first, and it is a separate project that is valuable in its own right. Third, no owner: if nobody is accountable after launch for keeping the base current and reviewing errors, the system degrades within months and becomes a source of wrong answers issued in your company name.
- Pilot: one topic, one channel, four to six weeks, success criteria set before the start.
- Metrics: coverage, human-rated quality, share of conversations closed without an agent.
- Expand one axis at a time: topics first, channels second.
- Moving from answers to actions delivers more than adding another channel.
- Do not start below roughly 1,000 conversations a month or without a knowledge base owner.
Frequently asked questions
What does an AI chatbot for business cost?
On the Russian market ready SaaS platforms for business start around 59,000 RUB a month, while custom development starts around 500,000 RUB plus 10,000 to 50,000 RUB of monthly support. Veltos.Tech starts AI/ML projects at 180,000 RUB, which typically funds a pilot on one process. To any of those figures add knowledge base preparation, two to four weeks of work on your side that cannot be fully delegated to a vendor because it requires subject matter knowledge.
Why is RAG better than fine-tuning a model on your data?
On three counts. Updates: changing an answer means replacing a document in the base rather than running training, which is hours instead of weeks. Transparency: RAG shows which document the answer came from, so a disputed case can be reconstructed, while a fine-tuned model leaves no traceable source. Cost and data: quality fine-tuning needs a volume of examples most companies do not have, whereas RAG works on the policies and instructions you already have, with no extra labelling.
How do you stop the bot inventing answers?
Not entirely, but four measures bring it to an acceptable level. Clean up the knowledge base: one current version of each document, no duplicates and no contradictions. Set a relevance threshold below which the system concludes it found nothing. Explicitly permit and require the answer "the knowledge base has no information on this" instead of an attempt to help. And enforce human handoff on stop-list topics and after a second misunderstood question. Add logging with a weekly sample review, without which everything else quietly stops working.
How long until an AI assistant pays for itself?
For a typical scenario of 3,000 conversations a month a custom solution breaks even around month 11 or 12, SaaS around month 5 or 6 but with a lower ceiling on saving. Cumulative costs on the two paths level out around month 19. The decisive variables are conversation volume and the share of topics the knowledge base actually covers. Below a thousand conversations a month payback usually never arrives, and the right decision is to postpone the project rather than to find a cheaper vendor.
Can foreign models be used under Russian data protection law?
If personal data never enters the requests, usually yes, and the typical example is an assistant over a public knowledge base with no user identification. The moment a name, phone number, order number or the content of a specific customer conversation appears, sending it to an external service becomes processing and needs separate legal assessment. The practical options then are domestic models via API, open models inside your own perimeter, or an architecture that strips personal data from the request before it leaves.
What if the company knowledge base is a mess?
Start with the base rather than with the assistant. Gather the documents in one place, keep one current version of each, remove contradictions, separate internal from customer-facing material, and assign an owner to each section. That is two to four weeks of work and it pays off on its own: staff start finding answers faster before any AI is involved. Launching an assistant on a chaotic base produces confident wrong answers issued in your company name, which is worse than having no assistant at all.
Need a hand with this?
We do this work, not just write about it. Describe the task and we will scope it and send a staged estimate.
Related services
- AI and ML developmentWe build AI that solves a defined task and pays for itself, not demos for the sake of demos. Classifiers, recommendations, text and document processing, LLM assistants, and model integration into an existing product.
- Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.
- AI strategy consultingMost companies have already run at least one AI pilot. A minority have taken even one pilot to stable, ongoing use. The gap usually is not the model, it is whether the process had a measurable payoff and whether the real running cost was worked out before starting. We help pick the right entry point so budget does not disappear into a demo that stays a demo.
Read next
- Where AI and ML Actually Pay Off in a Business, and Where They Are Expensive HypeMachine learning pays off where there is a repeated decision, a lot of similar data and tolerance for error. Missing any one of the three means do not. Here are the use cases that work, their realistic accuracy, the running costs and how to run a four to six week pilot.
- MVP in 2026: Real Timelines, Real Budgets and What to CutMVP no longer means cheap and rough. A weak prototype today produces a false negative and buries a workable idea. Here are four MVP tiers with prices and timelines, a framework for cutting scope, and the parts no budget justifies removing.
- Telegram Mini Apps for Business: Who Needs One and What It CostsA Mini App is a web application living inside Telegram with no store review and no install. We cover how it differs from a bot and a mobile app, which mechanics work, how authentication is built and what development costs.