Retrieval-Augmented Generation (RAG)
A pattern that combines generation with retrieved sources or data at answer time.
RAG is plumbing around a generative model: retrieve context, add it to the input, and generate a response. Quality depends on the corpus, retrieval, prompt, model, and evaluation—not the acronym.
For ecommerce, RAG is not a ranking protocol, crawler, or SEO setting. Accurate public pages improve inputs; third parties still control crawling, indexing, retrieval, citation, and traffic.
What is retrieval augmented generation?
Retrieval augmented generation is an application pattern that retrieves external context at answer time, adds selected context to a model prompt, and generates a response. The three stages are retrieval, augmentation, and generation. RAG changes the information available to the application; it does not create a public ranking protocol or crawler.
Google Cloud defines RAG as retrieve, augment, and generate with post-training knowledge. Retrieval selects; augmentation assembles evidence and instructions; generation responds.
The 2020 Lewis et al. paper combined parametric and non-parametric memory. Its results apply to tested datasets and models, not universal commerce ranking, citation, accuracy, or revenue.
How is RAG different from model training and web search?
RAG, model training, and web search solve different problems. Training changes model parameters; RAG supplies selected external context at answer time; web search retrieves public results for a query. A product can combine them, but a search interface or generative model should not be assumed to use a particular RAG architecture.
| Approach | Input or change | Timing | Does not imply |
|---|---|---|---|
| Training | Parameters | Training | Current facts |
| RAG | Retrieved context | Answer | Correct result |
| Web search | Public index | Query | Generation |
| Long context | Supplied documents | Prompt | Retrieval system |
Vertex AI’s RAG overview and AWS’s RAG explanation describe implementations, not private logic of unrelated answer engines.
How do ingestion, chunking, and indexing work?
Production RAG begins before the user asks a question. Teams select sources, parse and clean documents, split them into chunks, add metadata, create searchable representations, and maintain an index. That lifecycle determines what can be retrieved; a fluent model cannot recover evidence that was omitted, corrupted, or made stale upstream.
Use this ingestion and index workflow:
- Define corpus, use case, permissions, and deletion rules.
- Ingest authorized sources with provenance.
- Normalize without losing material context.
- Chunk at meaningful boundaries and add metadata.
- Build vector, lexical, or hybrid indexes.
- Test representative queries and missing evidence.
- Refresh, version, and delete with source changes.
Microsoft’s advanced RAG guidance covers ingestion, chunking, enrichment, retrieval, evaluation, and processing. OpenAI’s Retrieval guide covers vector stores and semantic search for builders—not ChatGPT Search ranking.
How do retrieval and reranking shape context?
Retrieval selects candidate context, while reranking can reorder candidates before augmentation. Query rewriting, metadata filters, hybrid lexical-and-vector search, top-k limits, and rerankers change what reaches the prompt. More context is not automatically better: irrelevant, contradictory, stale, or hostile passages can crowd out the evidence needed for a reliable answer.
Teams should inspect both the candidate set and the final context. A relevant document can exist in the index yet miss the top results; a reranker can improve ordering or suppress useful evidence; an overly broad chunk can contain the answer but dilute its signal.
Augmentation should preserve source boundaries and material qualifications. Generation should distinguish supported statements from inference and uncertainty. A linked citation is still an output choice: it does not prove that retrieval was complete, the passage was current, or the answer interpreted it correctly.
How should RAG quality be evaluated?
Evaluate retrieval and answer quality separately. Retrieval tests whether relevant evidence enters the candidate set and final context; answer tests whether the response is supported, complete, useful, and appropriately uncertain. A polished answer can hide failed retrieval, while strong retrieval can still feed a model that misstates the evidence.
| Layer | Example measures | What failure can mean |
|---|---|---|
| Corpus | Coverage, freshness, permissions | Needed evidence is absent or unusable |
| Retrieval | Recall, precision, ranking quality | Context is missing or noisy |
| Answer | Evidence support, completeness, task success | Generation misuses available context |
| Outcome | User resolution, conversion, deflection | Business result needs attribution context |
The NIST Generative AI Profile supports structured risk measurement and evaluation. Record the corpus version, queries, relevance judgments, prompts, model, settings, retrieved passages, answers, and reviewer criteria so results remain scoped to the tested system.
How should teams manage freshness and security?
Freshness and security are part of RAG quality, not maintenance afterthoughts. The index needs update and deletion paths, source timestamps, permissions, and provenance. Retrieved external text must be treated as untrusted input because it can contain errors, malicious instructions, hidden payloads, or content the application was never authorized to expose.
Refresh schedules should match the consequence of stale facts: product price, inventory, returns, safety, and legal policies may need different controls. Remove revoked material from every derived index, not only the source. Log which version supported each answer when auditability matters.
OWASP’s prompt injection guidance explains why external instructions can be hostile. Separate retrieved content from system instructions, enforce authorization before retrieval, minimize tool permissions, validate outputs, and test attacks that attempt to override policy or exfiltrate data.
What does RAG mean for ecommerce storefronts?
Preparing an ecommerce storefront for public discovery is not the same as building a RAG system. A merchant can publish crawlable, current product, offer, policy, comparison, and entity facts. A third party still controls crawling, indexing, retrieval, chunking, ranking, augmentation, generation, and whether any source appears in an answer.
RFC 9309 defines controls for compliant crawling, not downstream indexing or retrieval. Schema.org Product and Organization describe entities; they do not select sources. Crawler access, schema, or an llms.txt file cannot guarantee retrieval or citation.
Use structured data to express supported visible facts, then evaluate any AI citation as a sampled output. The guide to measuring AI search visibility and StoreCited research keep readiness, observations, and business outcomes separate.
What can StoreCited truthfully assess?
StoreCited is a point-in-time public-storefront readiness audit, not a RAG inspection or monitoring platform. It cannot build or inspect third-party pipelines, query private indexes, observe retrieval traces, monitor live prompts or citations, identify competitors actually selected by a system, or guarantee retrieval, citation, traffic, conversion, or revenue.
StoreCited can flag observable public issues such as blocked access, inconsistent product facts, missing context, or markup mismatches in the response it tests. It cannot establish whether any third party ingested, chunked, indexed, retrieved, trusted, or cited that response.
Run the free StoreCited readiness scan to inspect public inputs you control. Pair the result with documented platform sampling and first-party analytics when you need evidence about citations, visits, or sales.