Neo4j acquires GraphAware. Learn more about this exciting new chapter.

Retrieval-augmented generation (RAG)

What is retrieval-augmented generation (RAG)?

Retrieval-augmented generation (RAG) is an approach that combines information retrieval with generative AI. Instead of asking a large language model (LLM) to answer a question using only information encoded in its training, a RAG system first retrieves relevant information from a defined source and provides it to the model as context for generating a response.

This distinction matters in intelligence analysis. An analyst may need to question hundreds of intelligence reports, witness statements, financial records or other case documents. The answer needs to be grounded in the material available to the investigation, rather than relying on what a general-purpose model may know.

RAG provides a way to connect an analyst’s question to relevant source material and use that material to support a generated response.

It does not, however, guarantee that an answer is correct. Retrieval can miss relevant information, the retrieved material can be incomplete, and an LLM can still misinterpret what it finds. For high-stakes analysis, the retrieval process and the evidence behind the answer therefore matter as much as the generated response.

How does RAG work?

A basic RAG workflow has three stages:

Retrieve

The system receives a question and searches a defined collection of information for material that may help answer it.

For example, an analyst investigating suspected money laundering might ask:

Which companies received payments connected to this network during the period under investigation?

The retrieval stage might search reports, company records or other relevant material for passages containing evidence related to the question.

Augment

The retrieved material is supplied to the LLM as additional context alongside the analyst’s question.

This gives the model specific information to work from rather than requiring it to rely solely on its general training.

Generate

The LLM uses the question and retrieved information to produce a response.

The quality of that response depends partly on the quality of the retrieval. If important evidence is not retrieved, the model cannot reliably use it.

For intelligence work, there is also an important requirement beyond the basic RAG pattern: the analyst needs to be able to examine the evidence supporting the answer.

What can RAG retrieve?

RAG is an architectural approach rather than a specific search technology. The information it retrieves can come from different sources, including:

  • Documents
  • Databases
  • Knowledge bases
  • Reports
  • Case files
  • Internal records
  • Other structured or unstructured sources

The retrieved material might be a database record, a document, or a specific passage from a larger document.

This makes RAG useful when analysts need to interrogate large collections of existing information without manually locating every relevant piece of material first.

How is information retrieved in RAG?

Different retrieval methods are suited to different types of questions.

Keyword or lexical search looks for specific words or phrases in the available information.

This is useful when exact identifiers matter, such as names, vehicle registrations, company numbers or reference codes.

Semantic search

Semantic search uses representations of meaning to find information that is conceptually related to a query, even where the wording is different.

For example, a search for a suspect’s movements might retrieve a passage referring to a “waterfront” even though the analyst used the word “harbour”.

Hybrid search combines approaches such as keyword and semantic retrieval.

This can be useful in investigations where both exact identifiers and broader concepts matter.

Re-ranking

A system can initially retrieve a larger set of potentially relevant results and then assess which are most relevant to the specific question.

The important point is that retrieval quality is fundamental to RAG. A well-written answer cannot compensate for evidence that was never retrieved in the first place.

What are embeddings and vector databases?

Semantic retrieval often uses embeddings, which represent text as numerical vectors so that semantically similar material can be identified.

A vector database can store and search those vectors efficiently.

However, embeddings and vector databases are not synonymous with RAG. RAG can use semantic search, keyword search, hybrid search or other retrieval mechanisms, depending on the application.

They are components that can support the retrieval stage of a RAG system, rather than defining RAG itself.

RAG in intelligence analysis

RAG is particularly relevant to intelligence analysis because investigations generate large volumes of unstructured material.

Consider an organised crime investigation involving witness statements, surveillance reports and intelligence from partner agencies. An analyst might want to know:

Which witnesses place the suspect near the harbour between 10 and 15 March?

Finding the answer could require searching several documents and comparing how different sources describe the same person, place or event.

A RAG system can retrieve relevant passages and use them as context for an answer. But for an intelligence analyst, the answer itself is only part of the requirement.

The analyst also needs to know where the information came from.

This is why source visibility and evidence linkage are particularly important when applying RAG to investigations. GraphAware’s approach to Document Intelligence is based on the principle that AI should support analyst judgement by helping surface relevant evidence while keeping that evidence visible and verifiable.

RAG and high-stakes analysis

A generated answer can sound convincing without being adequately supported by the available evidence.

For intelligence and law enforcement use cases, this creates a different standard from many everyday AI applications. An analyst may need to use the result in an intelligence report, briefing or later evidential process, where conclusions need to be defensible and traceable to their sources.

A RAG system should therefore be considered in terms of more than the fluency of its answers.

Analysts need to understand:

  • What information was retrieved
  • Which sources contributed to the answer
  • Whether relevant information may have been missed
  • Which evidence supports individual claims
  • Where uncertainty or gaps remain

Retrieval does not establish that a source is true. It establishes that the source contains relevant information. Analysts still need to assess reliability, context and corroboration.

What is agentic RAG?

Basic RAG can retrieve information once and then generate an answer. Agentic RAG extends this approach by allowing retrieval to happen iteratively.

Rather than:

Question → Retrieve → Generate

an agentic system can work more like:

Question → Retrieve → Evaluate → Refine → Retrieve again → Generate

The system can assess whether the information it has found is sufficient, identify gaps and try another retrieval strategy before producing an answer.

This is particularly relevant to complex investigative questions that require information from multiple documents.

GraphAware’s upcoming Document Intelligence work is currently in development and will use this principle. When an analyst asks a question, the planned system can search Workspace documents, assess the results, broaden or narrow the search when necessary, and continue retrieving information before constructing an answer. A separate evaluation step then checks the answer against the retrieved evidence.

This is a distinction worth preserving: agentic RAG is an iterative way of implementing RAG, rather than a completely separate technology.

What is the difference between RAG and GraphRAG?

RAG is the broader approach of combining retrieval with generation. GraphRAG is a specific approach that incorporates graph structures into the retrieval and reasoning process.

One GraphRAG architecture can involve processing documents in advance, extracting entities and relationships, and building a knowledge graph that can then be queried as part of the retrieval process.

GraphRAG can be useful where relationships between entities are particularly important. However, building a graph from documents can also introduce additional processing, cost and review requirements, particularly when AI is making decisions about which entities and relationships to extract before an analyst has asked a question. GraphAware explored this approach as part of its Document Intelligence research and chose a different architecture for the capability being developed for GraphAware Hume.

The distinction is therefore:

RAG describes the broader retrieval-and-generation approach.

GraphRAG describes approaches that incorporate graph structures into that process.

Agentic RAG describes RAG systems where retrieval can be iterative and adaptive.

These approaches can overlap. They should not be treated as interchangeable terms.

How does GraphAware Hume use RAG?

GraphAware Hume’s Document Intelligence capability is currently in active development for a future Hume release. It is designed around an agentic RAG approach for interrogating documents held within an analyst’s Workspace.

Rather than requiring a full knowledge graph to be built from the documents before an analyst can ask questions, the planned architecture uses a simpler, lighter document representation. Documents are chunked and indexed so they can be searched using conceptual similarity and exact text matching. Intelligence is then applied at query time, when the analyst’s question provides the context for retrieval.

The planned workflow is designed to keep the evidence visible throughout the process. Answers are assembled from retrieved passages, with sentence-level source attribution and visibility into the documents considered during retrieval. This is intended to let analysts inspect the evidence and judge the answer themselves rather than treating the AI output as a conclusion that must simply be accepted.

That approach reflects a wider principle in GraphAware’s work on AI in intelligence analysis: AI should support the analyst’s judgement rather than replace it.

What are the benefits of RAG?

Used appropriately, RAG can help intelligence teams work with large collections of information more efficiently.

Access to organisation-specific information

RAG allows an LLM to work with information retrieved from a defined collection of sources rather than relying solely on its training.

Faster access to relevant evidence

Retrieval can surface potentially relevant passages from large document collections, helping analysts focus their reading.

Support for complex questions

More advanced retrieval approaches can gather evidence from multiple passages or documents to support questions that cannot be answered from a single source.

Greater transparency

Where source attribution is built into the system, analysts can inspect the information behind a generated response.

Analyst support

RAG can help analysts search and synthesise information while leaving assessment, interpretation and investigative judgement with the analyst.

What are the limitations of RAG?

RAG is not a guarantee of reliable AI output.

A system can still produce a poor answer when:

  • Relevant information was not retrieved
  • The retrieved evidence is incomplete
  • Sources contradict one another
  • The model misinterprets the retrieved material
  • The retrieval strategy does not suit the question

There is also a fundamental difference between retrieving information and establishing what is true.

RAG can help an analyst find what a collection of documents says about a subject. It does not independently determine whether those statements are accurate. That remains an analytical task requiring source assessment, context and human judgement.

FAQs

What does RAG stand for?

RAG stands for retrieval-augmented generation. It describes an approach in which information is retrieved from a defined source and provided to a generative AI model as context for producing a response.

Does RAG guarantee accurate answers?

No. RAG can help ground a response in retrieved information, but retrieval can be incomplete, and the model can still misinterpret what it finds.

Does RAG require a vector database?

No. Vector databases are commonly used for semantic retrieval, but RAG can also use keyword search, hybrid search or other retrieval methods.

Semantic search is a retrieval technique that finds information based on meaning or conceptual similarity. RAG combines retrieval with generation, using retrieved information as context for an LLM to produce a response.

What is the difference between RAG and GraphRAG?

RAG is the broader retrieval-and-generation approach. GraphRAG is an approach that incorporates graph structures, such as entities and relationships, into the retrieval process.

What is agentic RAG?

Agentic RAG is an approach where retrieval can happen iteratively. The system can assess what it has found, identify gaps, refine its search and retrieve additional information before generating an answer.

Can RAG replace intelligence analysts?

No. RAG can support analysts by helping them search and synthesise large volumes of information, but assessing evidence, interpreting context and making investigative judgements remain human responsibilities.

How does GraphAware Hume use RAG?

GraphAware Hume’s Document Intelligence capability is currently in active development. The planned approach uses agentic RAG to interrogate Workspace documents, with iterative retrieval and evidence linkage designed to keep the supporting source material visible to the analyst.