Adding a linguistic model to a web application does not guarantee that the product has become reliable. The model may make mistakes, invent details, or be influenced by instructions within untrusted documents. Design starts with a specific task, clear sources, repeated evaluation, data and budget protection, and user experience.
What you will take away from the article
- Choosing a task and clear success criteria.
- Retrieving trusted sources via RAG when needed.
- Protecting secrets, measuring quality and cost.
Start with the problem, not the model name
Determine what the user needs to accomplish: summarizing a document, searching a guide, categorizing a request, or suggesting a formulation. Define the acceptable outcome and unacceptable errors, and determine when to reject the answer or refer the user to a source. Sometimes, a traditional rule or search process is simpler and more accurate than a linguistic model. Test a sample that represents the real language and context, including ambiguous questions and out-of-scope requests, and compare performance with a clear baseline.
What is RAG and why doesn't it guarantee truth?
Retrieval-Augmented Generation retrieves passages from specified sources and then passes them to the model as context. It helps with changing documents without retraining for each update, but the quality of the answer depends on the quality of indexing, retrieval, passage ordering, and the model's ability to use them. Measure retrieval separately from the quality of formulation, keep the source and page or link, and request clarification of the lack of guidance instead of filling the gap with false confidence.
Treat documents as an untrusted input
A retrieved document or user question may contain prompt injection that attempts to change the model's behavior or reveal data. It is not enough to put instructions in the prompt to solve this. Make tool permissions limited and isolate retrieved data from system policies as much as possible. Do not grant the model sensitive operation permissions just because its text appears convincing; the server is what enforces permissions and verification, and important operations need human confirmation or independent controls.
Privacy, cost, and evaluation
Send only the necessary data, determine what can be sent to the model provider according to privacy policies and contracts, and do not put API keys in JavaScript that reaches the browser. Monitor input length, output, response time, failure, and cost for each operation, and set limits for requests, timeouts, and retries. Build a fixed test set that includes reference questions, out-of-scope requests, and conflicting content; and after changing the model, prompt, or retrieval, compare results and review human samples.
Simplified RAG flow structure
async function answerQuestion(question, user) {
const docs = await getDocumentsUserCanRead(user);
const passages = await retrieveRelevantPassages(question, docs);
if (!passages.length) return { answer: "Not enough evidence.", sources: [] };
const result = await generateGroundedAnswer({
question, passages: passages.map(p => p.text)
});
return { answer: result.answer, sources: passages.map(p => p.source) };
}
Consider documents and retrieval as trust boundaries
In RAG, the application retrieves passages from documents and then puts them in the model's context to formulate an answer linked to the source. This may reduce the need to rely on knowledge stored in the model, but it does not guarantee truth; the system may retrieve irrelevant passages or the model may misinterpret them or add unsupported claims.
Separate access permissions from retrieval quality. A document that the user does not have permission to read should not enter the context just because its embedding is close to the question. Apply filtering according to source permissions before or during retrieval, and record the IDs of retrieved documents to facilitate auditing without leaking their content to inappropriate logs.
Detailed case study: from presentation to root cause
The practical case here is: an RAG system gives a confident answer but retrieves an old or unreadable document for the user. It is not enough to fix the apparent symptom; one must draw the data path or request from its beginning to the result, and find out where the difference arose. Start by recording what happened, what was expected to happen, and the step that can be proven by measurement, log, or test. Then change one clear factor and redo the same scenario to verify that the root cause is addressed. If several components change at once, it will be difficult to know which one made the difference.
Link the case result to the article's principle: start with the problem, not the model name, and what is RAG and why doesn't it guarantee truth?. These two concepts determine what should be examined first and what can be postponed. Also, record untested cases, so that the success of one scenario does not turn into a claim that the entire system is problem-free.
Data pipeline is more important than model name
An RAG system usually goes through text extraction, cleaning, division, adding metadata, indexing, then retrieving passages and possibly reordering them, then building context and producing an answer and verifying it. A flaw in any stage reflects on the result; poor division may separate a title from its answer, and incomplete metadata may prevent filtering, and wide retrieval may add noise to the context.
Choose passage length and overlap by testing on your actual documents, not a fixed general number. Short passages may lose context, and long passages may introduce unnecessary text and exceed context limits or increase cost. Keep a version of the index and a policy for rebuilding it when documents or embedding models change.
From example to implementation in a real project
Start from the example code presented in the article: "Simplified RAG flow structure". Do not transfer it literally to production before determining its inputs, outputs, and assumptions. Ask what happens when a value is missing, or unexpected data arrives, or a request is repeated, or an external dependency is delayed. Then implement a small version inside an independent branch and add a test for the basic case and another for a failure case.
Use these steps as a starting point: determine the task, success criteria, and baseline. Then separate source retrieval from answer generation. Then apply access permissions before retrieval and to tools. Make each step reviewable, and do not combine real project settings and secrets within an educational example. If your environment differs from the example, document the difference and modify the implementation based on official documentation rather than copying the solution without understanding.
Evaluate retrieval and answer each separately
When the answer is incorrect, first ask if the necessary passages were among the results. If not, the problem is in retrieval, division, indexing, or formulation. And if they were present but the model ignored them, examine the prompt formulation, passage ordering, and context limits. This separation prevents changing the model to solve a problem whose source is the data.
Form a evaluation set that represents real questions with sources, expected answers, or clear acceptance criteria. Measure the quality of retrieval, accuracy of citations, avoidance of lack of evidence, response time, failure, and cost. Do not be satisfied with trying some questions that the developer knows; this experience may hide common failures in names, dates, or conflicting documents.
Systematic diagnosis approach when failing
When the solution does not work, do not start by adding another condition before determining the evidence of failure. Record the input, expected outcome, actual outcome, and message or measurement that supports the conclusion. One of the repeated mistakes in this topic is assuming that RAG completely prevents hallucinations. Treat this point as a hypothesis to be tested, not a pre-diagnosis; the problem may be in a neighboring layer or in an incorrect assumption during testing.
Divide the system into clear boundaries: inputs, processing, external dependency, and outcome. Test each boundary separately as much as possible, then implement an integrated scenario. If you fix the problem, add a test that prevents its return or an operational note that helps to detect it early. The goal is for diagnosis to become repeatable by another team member, not to remain linked to the memory of the person who discovered the fault.
Instruction injection, privacy, and cost
Retrieved text is untrusted data, even if it comes from an internal file; it may contain instructions that attempt to direct the model to bypass what is required. Separate system instructions from content, and do not grant the model unlimited executive permissions based on retrieved text. If the model can invoke tools, apply authorization in the application before each operation, not relying solely on the model's request.
Review what is sent to the model provider, retention periods, personal data filtering, and the cost of inclusions, retrieval, and response. Set a limit on the length of the request and the number of documents, and verify the sources of the response before presenting them in sensitive areas. Clarify to the user that citation helps with review but does not equate to a guarantee that every formulation is correct.
Advanced Considerations Before Adopting a Solution
In a real project, a solution is not evaluated on the success of the happy case alone. Review behavior under load, failure cases, future changes, and relevant security boundaries. It is important here to verify document permissions and citations and abstain when evidence is lacking, and not grant the model executive powers based on retrieved text. Do not treat these points as a later addendum; a design decision may be difficult to change when data accumulates or multiple clients depend on it.
Define acceptance metrics or tests before integration, and clearly document the solution's limits. The solution may be suitable for a small site but may need a queue or cache or a more stringent structure when usage grows. Do not add complexity prematurely without evidence, but do not ignore a clear sign that requirements exceed the simple version. A good decision balances current simplicity with the expected cost of change and maintains system clarity for the team.
Gradual Launch Plan for an AI Feature
Start with a narrow use case that can be evaluated, such as searching within a help guide, and do not start with a broadly empowered assistant that answers anything. Define the cases it should answer, the cases it should declare insufficient evidence for, and the response time and cost limits. Test on a preserved set, then implement a human trial before expanding access.
During the launch, monitor the percentage of source-supported answers, failed retrieval, the model's abstention rate, user complaints, and the cost per successful task. Collect feedback in a way that does not preserve sensitive data without need, and use failures to fix data, retrieval, or instructions according to the identified cause.
Practical Application and Acceptance Criteria
Try this exercise on a trial project or a separate branch: create five evaluation questions with their sources and test a question without evidence and an unauthorized document. Write the expected outcome before implementation, record what actually happened, and then fix the difference if it appears. Also, try a boundary case or a safely induced failure. Do not use real data or a production system to cause a test failure.
Consider the task complete when re-test steps are documented, the test proves basic behavior and failure case, there are no secrets or sensitive information in the log, and another developer can understand the reason for the solution. If this is not achieved, what is required is not to add more code directly; rephrase the problem and clarify the assumption that was not correct. This approach makes the article a starting point for a technical practice, not just a theoretical reading.
Frequently Asked Questions About RAG and AI
Does RAG completely prevent hallucinations? No; it reduces some risks but does not guarantee the correct use of evidence.
Can the retrieved document guide the model? Yes, so it must be treated as untrusted content and the use of tools restricted.
What is the success criterion? Independent evaluation of answer quality, citations, retrieval, privacy, and cost, not the impression from one conversation.
Practical Implementation Plan
- Define the task, success criterion, and baseline.
- Separate source retrieval from answer generation.
- Apply access permissions before retrieval and on tools.
- Set limits for usage, data, and cost.
- Evaluate results on a fixed set and review human samples.
Common Mistakes to Watch Out For
- Assuming RAG completely prevents hallucinations.
- Sending sensitive data without review.
- Allowing the model to execute sensitive operations without server-side verification.
Conclusion
A reliable AI feature is not just a good prompt; it is a system that combines a defined task, clear sources, limited permissions, and continuous evaluation. Separate retrieval and generation, monitor cost and privacy, and make refusing an answer due to lack of evidence an acceptable behavior.