RAG consulting

RAG consulting.
Answers you can check.

Find out why your chatbot gets the references wrong, invents capabilities or fails to answer from the information it has.

Your chatbot has documents. Its answers still need evidence.

Retrieval-augmented generation, usually shortened to RAG, combines a search step with a language model. The system retrieves material from a knowledge source and supplies it as context for an answer. This is useful for products that need to answer from their own documentation or business information.

A RAG chatbot can still select irrelevant passages, overlook the right source or make claims its references do not support. Our RAG consulting focuses on investigating these failures in an existing system and agreeing a practical recovery.

Four questions behind a useful investigation

1. Is the right information available?

Start with the question and the source that should answer it. Check whether that source is present, current and accessible to the intended user. An answer-quality problem may begin before retrieval, in missing or ambiguous product information.

2. Does retrieval find the relevant evidence?

Capture the material actually returned for a failing question. Compare it with the expected source. That helps establish whether the next investigation should focus on the content, indexing, retrieval settings or how the question reaches search.

3. Does the answer stay within that evidence?

Review each material claim against the context the model received. A citation needs to support the statement beside it. The system also needs a suitable response when the sources cannot answer the question.

4. Does it describe your product accurately?

A chatbot should not invent actions your application cannot perform. Product boundaries deserve explicit examples in the evaluation: what the system can explain, what it can do and when it needs to ask for clarification or decline to make a promise.

“Build a Ferrari” was the warning sign.

A sister concern’s vector-based RAG system selected the wrong references and invented product capabilities, including a claim that people could build a Ferrari using the app. Its answer-quality issues were resolved in approximately one week. Read the RAG recovery story →

Agree how improvement will be judged.

Collect representative questions, expected behaviour and the evidence needed to answer them. Include ordinary questions, known failures and requests the product cannot fulfil. The checks should cover retrieval relevance, support for the answer and correct treatment of uncertainty.

We scope changes around the observed failure. Possible investigation areas include source preparation, retrieval, model context, answer instructions and evaluation. The appropriate change is a finding to establish, not an assumption that every chatbot needs the same architecture.

RAG can help grounding; it does not guarantee correctness.

Microsoft’s RAG documentation describes both the grounding pattern and its limitations, including inaccurate responses despite retrieved context. Our guide to wrong RAG answers explains how to separate retrieval failures from unsupported generation.

Start with a free initial assessment.

Bring an anonymised example of the question, the incorrect answer and what should have happened. A first conversation establishes the problem and a sensible next step. Detailed RAG evaluation, code investigation and remediation are separately scoped.

If the problem extends into tools, agents or connected workflows, see our broader AI system rescue service.

The next step can be a small one.

Tell us where it
started going wrong.

A free initial assessment to understand the problem, discuss recovery options and agree a sensible next step.