- Home
- Blog
- How-to guides
- Retrieval augmented generation: 7 business examples
Retrieval augmented generation: 7 business examples
Seven places retrieval augmented generation earns its keep in a business, with what goes in, what comes out, and the one thing that usually breaks in each.
Retrieval augmented generation (RAG) is used today for HR policy assistants, support answers drawn from product manuals, contract clause lookup, proposal drafting from past bids, IT runbook search, regulatory Q&A and product questions on a website. In each, the system first searches your own documents, then a language model writes an answer from the passages it found and cites them. Each use also has one weak point to plan for, listed below.
This guide is for operations and IT leads choosing a first document chatbot. If you want the definition and the pipeline first, start with our glossary page on retrieval-augmented generation.

What makes a good first RAG project?
Three things. The answers already exist in writing, in documents someone maintains. People ask the same kinds of question often enough that looking them up costs real hours. And a wrong answer can be caught, because the assistant shows its source and a person can check it in seconds.
The pattern comes from a 2020 paper by Lewis and colleagues, which paired a language model with a searchable index of Wikipedia passages. Nothing about the model changes. You change what it reads.
Seven retrieval augmented generation examples
| Use | What goes in | What comes out |
|---|---|---|
| HR policy assistant | Handbook, leave and travel policies, country addenda, circulars | An answer with a link to the clause, or "ask HR" |
| Support answers from manuals | Product manuals, release notes, help articles, resolved tickets | A draft reply for the agent, with the manual page |
| Contract clause lookup | Signed contracts, amendments, side letters | The clause text, contract name and page |
| Proposal drafting from past bids | Past proposals, approved case studies, standard security answers | A first draft of each RFP answer, with its source |
| IT runbooks | Runbooks, post-incident reviews, configuration notes | The steps for an alert or error, with the runbook link |
| Regulatory Q&A | Regulations, regulator circulars, internal compliance policies | The rule and section, with the version it came from |
| Product questions on your website | Catalogue, specifications, delivery and returns pages | An answer for the customer, or a handover to staff |
Internal assistants: HR, IT runbooks and compliance
HR policy assistant. What breaks: versions and locations. The index holds the 2024 leave policy and its 2026 replacement, or the India handbook and the UK addendum, and the assistant quotes the wrong one with full confidence. Tag every document with its effective date, the country or entity it covers, and whether it has been superseded, then filter on those before the search runs. Remove old versions from the index rather than hoping the model picks the newer one.
IT runbooks. What breaks: staleness and exact strings. A runbook written for a server retired last year still reads as authoritative. Give every runbook an owner and a review date, and show that date next to the answer. Hostnames, error codes and ticket numbers also defeat search by meaning alone. Anthropic's 2024 write-up on contextual retrieval uses the example of a query for "Error code TS-999", which an embedding model can miss and keyword search (BM25) finds. Run both. Keep the assistant to reading: it suggests the steps, an engineer runs them.
Regulatory Q&A. What breaks: amendments and jurisdiction. Rules change on a set date, and a UK team, an EU team and an Indian team may face different rules for the same question. Store the effective date and jurisdiction on every passage, make the assistant say which version it used, and keep a compliance officer as the person who signs off. The assistant finds the text; it does not give legal advice.
Customer and commercial uses
Support answers from manuals. What breaks: tables and model numbers. Manuals keep torque values, compatibility lists and fault codes in tables, and a splitter that cuts a table in half separates each value from its heading. Parse the structure, keep each table whole, and carry the model number and manual revision on every passage. Start with replies drafted for agents before you put answers in front of customers.
Contract clause lookup. What breaks: amendments and "list every" questions. An amendment signed two years later overrides clause 12 of the base contract, but both sit in the index. Link amendments to their parent agreement and retrieve them together. RAG also fetches only a handful of passages, so "which of our 400 supplier contracts renew automatically?" needs those clauses extracted into a table first. Legal text is unforgiving: a peer-reviewed Stanford study published in April 2025 found that AI legal research tools from LexisNexis and Thomson Reuters, tested in 2024, each hallucinated between 17% and 33% of the time. Every answer needs its clause and page so a lawyer can check it.

Proposal drafting from past bids. What breaks: one client's details turning up in another client's draft. Past bids name customers, prices and staff. Build the index from an approved library (case studies you may share, standard answers, product sheets), and filter by permission before retrieval. OWASP's 2025 list of LLM application risks covers this under vector and embedding weaknesses, asking for permission-aware vector stores and strict partitioning between groups.
Product questions on your website. What breaks: live data. Prices, stock and delivery dates change by the hour, and an index rebuilt overnight is wrong by lunchtime. Answer policy and specification questions from documents, and give the assistant a read-only lookup into your database for anything that changes during the day.
When is RAG the wrong tool?
If the problem is tone, format or a narrow task rather than missing facts, read RAG vs fine-tuning. If the answer is a number in a database, query the database. If staff mostly need to find the right document rather than read an answer, start with semantic search over company documents. A chatbot is only as good as the search underneath it.
Where to start
Pick the one use above where questions are frequent and the documents are maintained. Collect 50 real questions from emails and tickets, with the right answer and source for each, before anything is built. Test the search on its own, and add generated answers once it passes.
Our RAG chatbot projects follow that order: list the sources and who may see them, write the question set, build ingestion, tune hybrid search and permissions, then pilot with one team. Models can be hosted APIs or open-weight models on your own servers.
If you have a shared drive full of policies, manuals or contracts and a team asking the same questions every week, tell us which one and we will suggest a first use you can test. Book a consultation.