What is RAG in voice agents, and how do you review sources?

Retrieval differs from training a model

RAG means Retrieval-Augmented Generation. The system retrieves relevant passages from available sources and uses them as context for an answer. This process does not retrain the model or guarantee source correctness; content, retrieval and interpretation each need review.

Tigy splits and indexes uploaded knowledge documents. After processing, attach them to the agent. Only selected sources are available for that agent's lookup.

A good source preserves exceptions

An exchange policy should include relevant conditions, deadlines and exceptions under clear headings. An isolated sentence about a deadline can produce incomplete guidance when conditions are missing.

Avoid selecting conflicting versions. When a rule changes, update the document, review attachments and test questions affected by the change.

Test questions the source cannot answer

Ask about a covered case, an exception and a condition absent from the material. Check that the agent distinguishes documented rules from information it could not find.

A delivery policy does not reveal an order's current location. Changing individual data needs a lookup in the responsible system, such as a configured HTTP tool.

Review the passage and conclusion

For an incorrect answer, check processing, attachment and content before adding instructions. Correct information may be in another source, or the rule may be ambiguous.

Keep questions to repeat after updates. Retrieval reduces reliance on generic knowledge; review verifies that an answer represents the company's approved rule.

Investigate incorrect answers through their sources

For fictional branches with different cancellation rules, test specified branches, missing branches and comparisons. Missing context should prompt clarification.

Verify processing, agent association, version and source clarity before reviewing question wording and response. Style instructions cannot fix contradictory sources.

Evaluate rule selection, fidelity and acknowledgment of insufficient information separately using both answerable and unanswerable questions. Fluent text can fail each condition.

Do not use documents to simulate live data

RAG can explain delivery procedures, but current order status requires its live system. Service descriptions do not establish calendar availability. Define when authorized tools replace document guidance.

Update policies at the source, verify processing, review affected agents and deselect conflicting versions. Keep regression questions for significant changes.

Human review remains necessary. Teams approve rules and conditions; retrieval should make answers traceable rather than turning textual similarity into certainty.

Define which answers documents can support

RAG describes an approach where retrieved information supports generated answers. Its service value depends on approved content existing for a question and preserving conditions in the explanation. It does not make every file current truth or replace individual-data retrieval. Begin with questions documents can genuinely answer.

Delivery policy may explain coverage and timing rules without establishing one purchase's status. Service descriptions may explain general conditions without proving current calendar availability. Separate stable knowledge from operational state before assigning questions to documents or tools.

Consider a fictional store. A customer asks about collecting an order at another branch. Documents explain that changes require verification. Answers should preserve that condition and identify procedure rather than claim the change occurred. Retrieving a correct rule does not authorize execution.

List covered questions and expected absences. Missing content can be legitimate: individual contract information, unapproved exceptions or recent events. Agents should recognize insufficient sources and offer next steps. Evaluate that exit as part of service, not merely a coverage failure.

In Tigy, use processed documents selected for the agent. Completed upload does not prove association with the tested conversation. Check configuration using a question answerable from that source, followed by an absent question. Together these distinguish material availability from behavior when sources cannot support answers.

Keep the expected response anchored to policy rather than a preferred sentence. Natural wording may vary while the relevant conditions remain equivalent.

Prepare sources that do not hide the rule

Useful sources keep scope, conditions and exceptions near primary information. Prices in tables can lose meaning if billing periods appear only in distant notes. Write units and conditions clearly and review how information works outside original presentation.

Headings should locate actual subjects. “Returns and refunds” is more explicit than “Other information.” Within it, distinguish deadlines, requirements and procedures. Repeating identical rules across many pages creates inconsistent-update risk rather than necessarily improving retrieval.

Resolve contradictory documents before association. When old manuals and new pages disagree, identify approved versions with owners. Do not expect models to infer authority from file appearance. Remove or correct superseded information while preserving still-valid content.

Explain abbreviations, internal names and customer terminology. Sources should support both reviewers and retrieval. Precise rules can receive plain conversational explanations, but material must provide necessary conditions. Vague marketing language cannot establish answers to specific operational questions.

Do not mix factual information with conflicting behavioral commands. Files explain policy; prompts guide conversation. Review material instructing unrestricted confirmation or ignored boundaries. Retrieved text remains information interpreted within scope, not authority to change permissions.

Assign ownership and review dates. Operational changes require appropriate source versions. Source maintenance belongs to answer quality even where models stay unchanged.

Try reading a policy aloud to someone unfamiliar with the company. Their questions can expose missing context that polished document layout concealed. Add clarification to the approved source instead of expecting the agent to infer it.

Distinguish missing content, retrieval and interpretation

When answers fail, first ask whether correct information existed in available sources. If absent, coverage or updating is responsible. If present, investigate association and retrieval. If relevant information arrived, inspect explanation. Different stages need different repairs.

Incomplete answers can arise from retrieving rules without exceptions. They can also arise when both are available but summarization omits conditions. Review sources and behavior rather than concluding “RAG does not work” from one answer.

Use reproducible questions and expectations. Include direct wording, informal versions and outdated premises. Add similar-looking questions not covered by policy. Comparison shows whether agents distinguish approved information from plausible extrapolation.

Do not require invented citations merely to sound convincing. Explanations should match material and available format. If claims cannot be verified in sources, flag them for review even when they sound correct. The criterion is support, not confidence.

When retrieval evidence is insufficient, record that limitation. Use test questions to verify association and inspect available execution information. Do not turn assumed causes into permanent changes. Choose hypotheses and trials that can support or challenge them.

Keep an accurate source excerpt for internal review under the team's data process. It provides a reference against which future explanations can be judged without relying on reviewer memory.

Preserve boundaries when callers suggest answers

Customers often bring premises: “Returns are allowed for thirty days, correct?” If approved policy differs, agents should correct it clearly. Courtesy agreement is not source fidelity. Include such questions in tests, especially after content changes.

Include requests for exceptions. Persuasive circumstances may not authorize rule changes. Distinguish explaining policy from deciding exceptions. Where staff hold that authority, route under approved procedures without promising review outcomes.

Test instructions embedded in questions or data, such as requests to ignore sources and use different deadlines. Behavior should remain within approved instructions. Integrated systems retain their own permissions, and retrieved documents do not replace authorization.

For audio, explain conditions and next steps briefly rather than reciting whole documents. Begin with the point determining the task and add detail where necessary. Faithful answers can still be hard to understand when many exceptions appear in one spoken block.

If callers correct context, reassess applicability. Policy for another branch may no longer apply. Agents should not continue repeating the first answer as though conversation stayed unchanged. Correct sources need correct context.

Include this context switch in regression tests. It verifies that retrieval-supported answers remain useful across a conversation rather than only at the first question.

Maintain reference questions for primary sources

Associate a small question collection with essential sources and repeat after updates. Record expected answers, important conditions and absences requiring fallback. This shows coverage and boundaries without one question for every manual sentence.

Group unanswered questions as editorial demand, but obtain approval before converting them into policy. Customer reports reveal uncertainty rather than automatically defining rules. Responsible staff should verify new content.

Separate correct answers, incomplete answers and correct unsupported-question exits in reports. Coverage can then improve without encouraging answers to everything. The objective is useful information supported by approved content and context, with honest alternatives where support is absent.

Review recurring failures with source owners and service staff together. Their combined view helps distinguish content needing clarification from tasks that should remain with live systems or human decisions. This keeps the knowledge base focused on information it can responsibly maintain.