Retrieval-Augmented Generation

The knowledge brain behind every dealer conversation.

RAG is what separates a reliable enterprise sales agent from a hallucinating chatbot. Every scheme explanation, every objection answer, every policy guardrail — grounded in Berger's own verified knowledge, retrieved in real time, during a live voice call.

No invented scheme terms — answers grounded in approved knowledge Retrieval within live-call latency Consistent across 9 Indian languages
3–5×
Dealers reached per agent-hour vs. manual calling
~70%
Target objections resolved without human escalation
<1/10
Cost per AI scheme call vs. a human sales call
24×7
Outbound capacity, every language, no fatigue

Directional targets for the MVP business case — to be baselined against a controlled pilot before rollout.

The Core Problem RAG Solves

Scheme terms change. Dealer questions don't wait.

A sales agent that answers from memory alone will give yesterday's scheme details, wrong eligibility criteria, and make-up answers under objection pressure. RAG fixes this by retrieving verified, up-to-date knowledge at the moment of the question.

With RAG

Agent retrieves before it answers

  • Scheme details fetched live from the knowledge store
  • Eligibility rules sourced from MCC/Oracle-synced data
  • Objection answers matched to approved policy documents
  • Every retrieved chunk logged for full auditability
🔄
RAG + Feedback Loop

Knowledge improves after every call

  • Failed objection answers flagged and reviewed
  • New scheme terms ingested within the same cycle
  • Retrieval ranking tuned from call outcome data
  • Business users update knowledge without retraining the model
Without RAG, for contrast

LLM answers from training data alone

  • · Scheme details frozen at model training time
  • · Eligibility rules guessed, not retrieved
  • · Objection answers may contradict policy
  • · No audit trail for what knowledge was used
How It Works

From dealer question to grounded answer in five steps.

This pipeline runs entirely within the latency budget of a live phone call. The dealer never knows retrieval happened — they just get a confident, accurate answer.

01
Detect

Dealer utterance triggers a knowledge need

The Conversation Policy Engine identifies that the dealer's question — about a scheme, a product rule, an objection, or a policy — requires a grounded answer rather than a direct LLM response.

02
Query

Semantic search across the knowledge store

The dealer's question is embedded and matched against a vector index of scheme documents, FAQs, objection playbooks, and policy guidelines. Top-k most relevant chunks are retrieved by semantic similarity — not keyword matching.

03
Rank

Retrieval results filtered for dealer context

Retrieved chunks are re-ranked by relevance to the dealer's specific profile — segment, active scheme, and objection history. A scheme-balance question for a Tier-1 dealer gets different context than for a new dealer.

04
Augment

Context injected into the LLM prompt

The top-ranked knowledge chunks are injected into the LLM's context window alongside conversation history, dealer profile, and campaign objective. The model answers only from the provided evidence — not from memory.

05
Audit

Every retrieved chunk is logged

The exact document chunks used to generate each answer are recorded in the Audit Store alongside the LLM response. Business users can inspect exactly what knowledge grounded any specific claim made during any call.

Knowledge Store

Four layers of verified knowledge.

The RAG knowledge store is not a static document dump. Each layer has a defined source, an update frequency, and an owner inside Berger.

🏷️
Layer 01

Scheme Knowledge

Owner
Trade Marketing / MCC Oracle
Update Cadence
Updated each scheme cycle
  • Scheme names, mechanics, and qualifying criteria
  • Dealer eligibility rules by segment, market, and depot
  • Scheme balance, qualification threshold, and progress tracking
  • Approved pitch language and key selling points per scheme
  • Common dealer questions and approved answers per scheme
📋
Layer 02

Objection Playbook

Owner
Sales Enablement Team
Update Cadence
Updated from call outcome feedback
  • Categorised objection types and recommended responses
  • Price objection handling with competitive context
  • Scheme complexity objections answered in plain language
  • Timing objections with urgency and deadline framing
  • Escalation triggers: when to transfer to a human agent
📦
Layer 03

Product & Catalog Knowledge

Owner
Product Management / MCC Oracle
Update Cadence
Synced from MCC/Oracle master data
  • Product names, categories, and SKUs
  • Pack sizes, order units, and minimum order quantities
  • Product features, formulations, and application guidance
  • Substitution rules and related SKU recommendations
  • Catalog constraints used in order validation
⚖️
Layer 04

Policy & Compliance Guardrails

Owner
Legal / Sales Operations
Update Cadence
Updated on policy change events
  • What the agent is permitted to commit to on a call
  • Pricing and discount communication boundaries
  • Data handling and consent language for voice calls
  • Regulatory requirements for scheme communication
  • Fallback language when a question is out of policy bounds
Sales Query Patterns

Real dealer questions. Grounded answers.

These are the structured sales patterns the agent runs during a scheme call. Each defines the trigger phrase, what knowledge is retrieved, the strict guardrails, and the exact answer the agent must produce — no improvisation, no invented scheme terms. The payment-intelligence patterns already proven in the POC carry over as the same retrieval discipline.

Sales Pattern · Scheme Intelligence

Scheme Eligibility & Pitch

Core sales flow
Trigger Phrases
"Which scheme is running for me?"
"Am I eligible for this offer?"
"What do I get on this scheme?"
"Is there any new scheme this month?"
Retrieval Rule

Match the dealer's category · market · depot against the Scheme Engine's eligibility rules, then retrieve the approved pitch from the Scheme Knowledge layer. Only schemes the dealer actually qualifies for are surfaced.

Output Format

Names eligible scheme + approved pitch, in the dealer's language.

scheme name · qualifying slab
reward · validity · approved pitch
Sales Pattern · Objection Handling

Objection Handling

Policy-bounded
Trigger Phrases
"Your price is higher than the other brand"
"This scheme is too complicated"
"I'll think about it later"
"Margins are better elsewhere"
Strict Behavior Rules
Answer only from the approved Objection Playbook
Never invent discounts or off-policy commitments
Escalate to a human agent when the playbook has no answer
Output Format

Approved rebuttal + re-pitch, adapted to dealer tonality.

objection type · approved response
re-pitch hook · escalate? (y/n)
Scheme

Scheme Balance

"How much more to qualify?"

Balance must come from the Scheme Engine — not LLM math
Use this dealer's live qualification data only
State exact gap to the next slab, never an estimate

Output

current · target · gap · reward
Product

Product & SKU

"Which pack sizes are available?"

Catalog-grounded

SKU, pack size, and order unit fetched from MCC/Oracle-synced catalog.

Constraint-aware

Only valid SKUs and minimum order quantities are offered.

No out-of-catalog product is ever suggested.

Order

Order Confirmation

"Book 50 buckets of the premium emulsion."

Read-Back Template

"Confirming [qty] × [SKU]. Correct?"
Always read back product + quantity before submitting
Validate against catalog & scheme before Salesforce punch
Proven in POC

The same retrieval discipline already runs live in the POC for payment-intelligence queries — PD invoices, pending invoices, credit/debit notes, payment modes, and outstanding balance — with totals sourced strictly from database aggregation, never LLM calculation. The sales patterns above extend that proven pattern to scheme selling.

Language Architecture

One verified answer. Nine languages.

A dealer in Tamil Nadu asks in Tamil. A dealer in Bengal asks in Bengali. Both must receive the same approved scheme answer — not a different one, not a mistranslated one. Here is how the RAG layer keeps knowledge consistent across all nine languages.

1

Dealer speaks in any language

STT transcribes the question in the dealer's language — Tamil, Bengali, Marathi, and six more.

2

Meaning is normalised, not translated word-for-word

The question is embedded into a language-agnostic semantic space, so "qualifying slab" matches whether asked in Hindi or Kannada.

3

Retrieval hits one approved knowledge base

All nine languages retrieve from the same single source of scheme truth — there is no separate, drifting copy per language.

4

Answer is spoken back in the dealer's language

The grounded answer is rendered into natural TTS in the dealer's language — same facts, local voice.

Supported Languages
EnglishHindiBengaliGujaratiMarathiTamilTeluguKannadaMalayalam
Why this matters to Berger

Update a scheme answer once, and every dealer in every region hears the corrected, compliant version — no nine-way translation project, no regional inconsistency, no compliance gap between languages.

Security & Data Residency

Berger's data stays Berger's.

Dealer data, scheme terms, and order records are commercially sensitive. The RAG layer is architected so this knowledge never has to leave Berger's control.

🇮🇳

In-Region Hosting

Knowledge store and vector index can be hosted in Indian data centres to meet residency requirements.

🔐

Self-Hostable LLM

Can run on a private Llama-style model so dealer and scheme data is never sent to a third-party API.

👁️

Full Audit Trail

Every retrieved chunk and every answer is logged — inspectable on demand for compliance review.

🔓

Access-Controlled

Role-based access governs who can read, update, or approve knowledge in the store.

Self-Improving System

The RAG layer gets smarter after every call.

Most AI systems require an ML team to improve them. Berger's RAG layer is designed so that business users — not engineers — can update approved answers, retire outdated scheme documents, and tune retrieval performance within the same call cycle.

📞
Step 1

Call completes

Dealer conversation ends. Outcome classified: converted, objection, retry, or failed.

🔍
Step 2

Gaps are flagged

Unanswered questions, failed objections, and wrong extractions are tagged automatically for review.

✍️
Step 3

Knowledge is updated

Trade marketing or sales ops corrects the relevant scheme document or objection answer in the knowledge store.

Step 4

Next call is better

The updated document is re-indexed. The next dealer asking the same question gets the corrected, approved answer.

Business Case

Why RAG is non-negotiable for Berger.

🛡️

Brand Protection

A hallucinated scheme commitment made on a call is a legal and commercial liability. RAG ensures the agent never says something Berger hasn't approved.

📈

Scheme Conversion

Dealers convert on scheme calls when answers are fast and credible. RAG gives the agent instant access to exact scheme terms, balance, and pitch — no hesitation.

🔧

Ops Agility

New scheme every quarter. New objection every week. RAG means Berger's business team can update the agent's knowledge without touching code or retraining a model.

📋

Audit Readiness

Management or regulatory review of any call will show exactly which document was retrieved, which chunk was used, and what response was generated.

🤝

Dealer Trust

Dealers who receive consistent, policy-accurate answers across calls learn to trust the agent. Inconsistent AI answers destroy that trust permanently.

💡

Institutional Knowledge

The RAG store becomes Berger's living sales intelligence — the best objection answers, sharpest scheme pitches, curated from every call, every cycle.