Survey of retrieval-augmented language models: architectures, retrievers, enhancements, and benchmarks

April 30, 20248 min

Overview

Decision SnapshotNeeds Validation

The paper compiles broad prior work and practical patterns; it is useful for engineers to choose architectures and baseline retrievers but does not introduce new experimental results.

Citations4

Evidence Strength0.80

Confidence0.80

Risk Signals12

Trust Signals

Findings with numeric evidence: 2/4

Findings with evidence refs: 4/4

Results with explicit delta: 0/0

Reproducibility

Status: Partial assets available

Open source: Partial

At A Glance

Cost impact: 55%

Production readiness: 60%

Novelty: 30%

Authors

Yucheng Hu, Yuxing Lu

Links

Abstract / PDF / Code

Why It Matters For Business

Retrieval augmentation makes LMs more factual and updatable by combining model memory with external, searchable knowledge, improving performance on knowledge-heavy tasks while enabling incremental updates without full model retraining.

Who Should Care

Summary TLDR

This 30-page survey defines Retrieval-Augmented Language Models (RALMs), covering both Retrieval-Augmented Generation (RAG) and Retrieval-Augmented Understanding (RAU). It organizes how retrievers and language models interact (three interaction modes), classifies retrievers (sparse, dense, internet, hybrid), summarizes LM families used, reviews improvements (retrieval quality, timing, end-to-end training), catalogs applications (QA, dialogue, translation, summarization, code, vision/audio), and lists evaluation suites and common failure modes (robustness, retrieval quality, cost). The paper links to a GitHub resource list.

Problem Statement

There is no single, practical overview that covers both retrieval-augmented generation and retrieval-augmented understanding, their interaction patterns, retriever types, enhancements, evaluations, and open problems; this survey aims to fill that gap with a structured taxonomy and recommendations.

Main Contribution

Defines RALM and precisely classifies three retriever–LM interaction modes: sequential single, sequential multiple, and parallel.

Systematically reviews retriever types (sparse, dense, internet, hybrid) and common LM families used in RALM pipelines.

Key Findings

There are three high-level ways a retriever and LM interact: sequential single, sequential multiple (iterative), and parallel.

Numbers3 interaction modes (Section 2)

Practical UseDesign pipelines by picking one of three patterns: single-shot for simple QA, iterative for multi-hop or long dialogue, parallel when blending model and retrieval outputs.

Evidence RefSection 2

Retrievers fall into four practical categories: sparse (TF-IDF/BM25), sparse vectors, dense (dual-encoder), internet, and hybrid combinations.

Numbers4 retrieval categories (Section 3)

Practical UseStart with BM25 or DPR as baselines; mix internet retrieval and re-ranking for open-domain needs; use hybrid strategies if single methods fail.

Evidence RefSection 3

What To Try In 7 Days

Add a BM25 baseline to an existing LM pipeline and compare outputs on 10 knowledge queries.

Plug a dense retriever (DPR) and measure retrieval relevance vs BM25 for your domain.

Implement a simple filter (lexical overlap or CXMI) before prompt augmentation and check error rate change.

Optimization Features

Token Efficiency
Increase retrieved paragraphs instead of model size (FiD approach)Use reranking to focus top sources
Infra Optimization
Streamline indexes and reduce embedding dimensionality for faster kNN lookups
Model Optimization
Structural instruction tuning (FLAN-style)FiD and FiD-Light reader optimizationsKNN-LM interpolation weight adaptation
System Optimization
Use internet search APIs for plug-and-play retrieval to avoid building full indicesIntermediate modules to avoid modifying black-box LLMs
Training Optimization
End-to-end retriever–reader trainingKnowledge distillation for retriever updatesInstruction / command fine-tuning with retrieval
Inference Optimization
Retrieval timing (when to call retriever)Prefix encoding to reduce runtimeGating circuits to block irrelevant retrieved docs

Reproducibility

Code AvailableYes
Data AvailableNo
Open Source StatusPartial
LicenseUnknown

Risks & Boundaries

Limitations

Poor robustness to adversarial or irrelevant retrieved context (prefix attacks and prompt perturbation).

Retrieval quality is uneven, especially when using raw internet sources without strong filtering.

When Not To Use

When strict low-latency or minimal inference compute is required.

If your retrieval sources are untrusted or highly noisy without good filtering.

Failure Modes

Irrelevant or misleading retrieved documents degrade generation quality.

Prompt injection or prefix attacks alter retriever outputs or LM behavior.

Core Entities

Models

RAGREALMFiDKNN-LMDPRContrieverColBERTBARTT5BERTGPT-3/3.5/4Llama/Llama2SELF-RAGSelfmemFILCO

Metrics

ROUGEBLEUbertScoreAccuracyFaithfulness / Context RelevanceNoise robustnessCounterfactual robustness

Datasets

Wikipedia / KILTHotpotQANatural Questions (NQ)FEVERCNN/DailyMailXSumBigPatentIWSLT14 De-EnStrategyQAMMLU-Med

Benchmarks

KILTSuperGLUERAGASRGBCRUD-RAGARESMIRAGERECALL

Context Entities

Models

RETOMATONFiD-LightADAPTRETTRIMERE-IMAGENRDMREPLUG

Metrics

FID (image)BLEU/ROUGE (text)RAGQuestEval

Datasets

KILT/Wizard of WikipediaCOCOCUBCodeXGLUEMedMC-QAEventKG

Benchmarks

EntityDrawBenchAESLCAG NewsGigaword