How do you build customer support with RAG?

Key facts

Retrieval	POST /v1/embeddings with plugsky-embed over help center, policy and troubleshooting content
Generation	POST /v1/chat/completions with retrieved passages, citations and a refusal path
Models	30+ models; cheap aliases for routine answers and stronger ones for multi-article cases
Confidence floor	A similarity threshold triggers escalation with context attached instead of guessing
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
RAG status	RAG is live; embeddings plus chat completions are the building blocks
Governance	Audit logs can link answers back to retrieved sources
Roadmap	Rerankers are not in the documented live stack; batch ingestion is coming soon

TL;DR

• Answer only from retrieved passages and cite them.
• Escalate below a similarity floor with the retrieved context attached.
• Tag content by product, region and version so retrieval stays relevant.
• Review unanswered questions as a content backlog, not a model problem.
• Measure citation correctness, not just deflection.

How it works, step by step

1. Export help center, policy and troubleshooting content; tag each article by product, region and last review date.
2. Chunk by heading and keep the article title and section in each chunk.
3. Embed with plugsky-embed and store vectors with source URL and metadata.
4. Retrieve per turn, drop chunks below the similarity floor, and fit the rest in a context budget.
5. Generate a cited answer, or escalate to a human with the retrieved context attached.
6. Review escalated and unanswered conversations weekly and update the affected articles.

Original data

Try it yourself

Open the RAG sandbox →

Why support answers need grounding

Support is a zero-tolerance domain: a plausible but wrong policy answer creates refunds, escalations and lost trust. Grounding changes the failure mode from confident invention to an honest 'let me connect you', which is a recoverable outcome.

It also keeps answers current. Policy and product content changes on its own schedule, and re-indexing an article is far cheaper than retraining or rewriting prompts. Finally, citations make review practical: a human can verify an answer in seconds by reading the linked article.

Building the support index

Support content has structure worth preserving:

• Chunk by section and keep the title, heading and product name in each chunk.
• Tag metadata: product, plan, region, language and last-reviewed date.
• Separate audiences: keep internal agent notes out of the customer-facing index.
• Deprecate explicitly: remove vectors for retired articles on publish, not on a quarterly cleanup.
• Balance content: long policy articles produce many chunks; avoid letting one document dominate retrieval.

Implementation and evaluation

The turn is retrieve, answer, decide:

1. Embed the customer question with plugsky-embed and retrieve candidate chunks.
2. Apply the similarity floor and a context budget; if nothing clears the floor, escalate.
3. Generate an answer with citations and a rule against adding information not present in the passages.
4. Validate that cited sources exist and attach them to the conversation record.

Evaluate retrieval recall on a labeled question set, citation correctness, deflection on intents you intend to contain, and escalation precision. Track unanswered question clusters to drive content work.

Limitations

RAG answers document questions; account questions need tools:

• 'Where is my order?' is not a retrieval question — it needs an account tool, so plan for a hybrid agent when support spans both.
• Contradictory articles produce contradictory answers; retrieval exposes the problem but only editorial work fixes it.
• You own the index: Plugsky provides embeddings, so search quality depends on your storage and ranking choices.
• Rerankers are not part of the documented live stack, and batch ingestion is coming soon, so plan index refreshes with your own scheduler.
• Highly localized answers may need per-region indexes or strict metadata filters to avoid returning the wrong region's policy.

Honest comparison

Capability	Support RAG on Plugsky	Fine-tuned support model	Static FAQ bot
Content updates	Re-index changed articles	Retrain and redeploy	Manual editing
Citations	Retrieved source ids attached	None	Fixed links
Coverage gaps	Visible as unanswered clusters	Hidden in weights	Obvious
Model choice	30+ aliases, routed per question	One model	One model
Escalation	Similarity floor with context	Usually absent	Keyword trigger

Frequently asked questions

How do I keep support answers accurate?

Retrieve from approved content, answer only from retrieved passages with citations, and escalate below a similarity threshold instead of guessing.

How should I chunk help center articles?

By section, keeping the article title, heading, product and region in each chunk so both retrieval and citations stay precise.

Can this handle order status questions?

Those need live account data, which is a tool call rather than retrieval. Build a hybrid agent: RAG for policy content, tools for account state.

What similarity floor should I use?

Start around 0.7 for cosine similarity with plugsky-embed on English content, then calibrate on labeled support questions from your own helpdesk.

Which model should answer support questions?

Routine single-article answers run well on plugsky-micro or plugsky-lite, while questions spanning several articles benefit from a stronger alias.

How do I measure success?

Track citation correctness, retrieval recall, deflection on intended intents and escalation precision, plus unanswered question clusters for content planning.

Can I test support RAG for free?

Yes. Embeddings and chat completions are live, the free plan includes two free models with no card, and the 14-day full-access trial supports evaluation with paid models.