RetrievalGuide6 min

Design retrieval for customer support knowledge

A practical structure for grounding support answers in policies, product docs, and account-specific context.

Real example

Example: answer refund-policy questions with source-aware retrieval

Support policy differs by plan, region, and purchase date. A generic answer could create a refund promise the company cannot honor.

Index public docs, internal policy, and account metadata separately. Retrieve only sources allowed for the current user and ask the model to identify which policy version supports the answer.

The assistant can answer accurately and show the support agent which policy it relied on.

Tutorial path

How to implement it

Step 01

Separate public help content, internal policy, and customer-specific records.

Step 02

Attach metadata for freshness, product area, audience, and permission level.

Step 03

Retrieve only the sources needed for the current support intent.

Step 04

Ask the model to cite or summarize evidence in the response object.

Step 05

Route low-confidence or source-missing answers to human review.

Checklist

Ready when these are true

Source types separated

Permission metadata exists

Freshness rules defined

Evidence shown in UI

No answer without supportable source

Field notes

What matters in practice

Retrieval should give the model the smallest useful evidence set.

Policy content, product docs, and account records need different freshness and permission rules.

The UI should show what source supported the answer.

Avoid these mistakes

Common failure modes

Do not mix stale policy docs with current docs without freshness metadata.

Do not retrieve internal-only notes into customer-visible answers.

Do not answer if the retrieved source does not support the claim.

Practical tip

Retrieval quality is often metadata quality. Add product area, audience, date, and permission fields before tuning prompts.

Apply this to a build