11 Aug 2026

RAG Explained for Beginners: Classic RAG, GraphRAG, Agentic RAG, Hybrid RAG and Hyper-RAG

MarketMeGlobal Team

Retrieval-Augmented Generation, usually shortened to RAG, is a method that helps an AI answer questions using information retrieved from outside its original training data.

Instead of relying only on what a language model learned during training, a RAG system can search company documents, databases, websites, product catalogues, research papers or other approved sources. It then supplies the most relevant information to the model before the answer is generated.

This guide explains five important RAG approaches in simple language:

1. Classic RAG
2. GraphRAG
3. Agentic RAG
4. Hybrid RAG
5. Hyper-RAG

You will learn how each method works, when it emerged, where it is used, how the approaches differ and what to expect from RAG technology in the future.

What is RAG?

RAG is a system that retrieves relevant information from an external source and gives it to a language model as context for generating an answer.

Imagine the difference between a closed-book and an open-book exam:

1. A normal LLM answers from what it learned during training. This is the closed-book approach.
2. A RAG-powered system searches relevant material before answering. This is closer to an open-book exam.

The language model still writes the answer. RAG improves what the model has available to read before writing it.

A simple RAG example

Suppose a property developer has hundreds of project documents, price lists, floor plans and payment schedules.

A buyer asks:

What is the payment schedule for Apartment A203?

A basic RAG system can:

1. Search the company’s approved documents.
2. Retrieve the section mentioning Apartment A203.
3. place that section in the AI’s working context.
4. Ask the LLM to answer using the retrieved information.
5. Present the answer, ideally with a reference to the source document.

Without retrieval, the model may not know that apartment or may invent a plausible payment schedule. With RAG, it can use the actual company record.

How does a RAG system work?

A modern RAG system normally has an indexing stage and a question-answering stage.

Stage 1: Preparing the knowledge

Before users ask questions, the system:

1. Collects approved documents and data.
2. Extracts readable text and metadata.
3. Divides long documents into smaller sections called chunks.
4. Creates one or more searchable indexes.
5. Records useful information such as document title, date, department, product or access permissions.

Many systems create embeddings for each chunk. An embedding is a numerical representation that helps a search system identify passages with a similar meaning, even when they do not use exactly the same words.

Stage 2: Answering a question

When a question arrives, the system:

1. Interprets or rewrites the question.
2. Searches the index.
3. Retrieves the most relevant chunks, records or relationships.
4. Optionally reranks or filters the results.
5. adds the selected evidence to the LLM’s context.
6. Instructs the model to answer from that evidence.
7. Returns the answer, preferably with citations.

The basic pattern is:

Question → Retrieve evidence → Add evidence to the prompt → Generate an answer

When was RAG invented?

Information retrieval existed long before modern generative AI. Search engines, document databases and question-answering systems had already been combining queries with external information for decades.

However, the term and influential modern formulation of Retrieval-Augmented Generation were introduced in a research paper first submitted on 22 May 2020 and later accepted at NeurIPS 2020. The researchers combined a generative language model with a dense Wikipedia index that acted as external, non-parametric memory. Their results showed improvements on several knowledge-intensive tasks. Read the original RAG research paper.

It is important to distinguish that original research architecture from what developers now call “Classic RAG.” Most current implementations do not reproduce the original model exactly. Instead, they use the broader retrieve-and-generate principle with a general-purpose LLM, document chunks, embeddings and a vector database.

1. What is Classic RAG?

Classic RAG retrieves a small number of relevant document passages and gives them to an LLM in a single, mostly fixed workflow.

It is also called:

1. Traditional RAG
2. Basic RAG
3. Naïve RAG
4. Standard RAG

These labels are sometimes used slightly differently, but they generally describe the simplest retrieve-then-generate architecture.

How Classic RAG works

A typical Classic RAG pipeline:

1. Divides documents into chunks.
2. Creates embeddings for those chunks.
3. Stores them in a vector index.
4. Converts the user’s question into an embedding.
5. Finds the most similar chunks.
6. Sends those chunks and the question to an LLM.
7. Generates an answer.

Simple example

A customer asks:

Does the premium package include telephone support?

The system retrieves the pricing-page section describing the premium package. The LLM uses that text to answer.

The workflow normally performs one search and one generation step.

Where Classic RAG is used

Classic RAG works well for:

1. Customer-support chatbots
2. Employee handbook assistants
3. Product and service FAQs
4. Technical documentation
5. Company policy questions
6. Basic legal-document search
7. Property inventory questions
8. Educational knowledge assistants
9. Questions about uploaded files

Advantages

1. Relatively simple to build
2. Fast compared with multi-step agent systems
3. Easier to test and debug
4. Suitable for clearly written document collections
5. More affordable than complex graph or agentic architectures
6. Can provide citations to source material

Limitations

Classic RAG can struggle when:

1. The answer is spread across many documents.
2. The question requires several searches.
3. Exact keywords and semantic meaning both matter.
4. Relationships between people, products or events are important.
5. The question asks for a summary of an entire document collection.
6. Retrieved passages contain conflicting information.
7. Important context is lost because documents were divided into poor-quality chunks.

Classic RAG is often the best starting point, but it is not always the best final architecture.

2. What is GraphRAG?

GraphRAG organises information as entities and relationships, allowing an AI to retrieve connected facts and understand wider patterns across a collection of documents.

A standard knowledge graph might represent:

1. A person as a node
2. A company as another node
3. “Works for” as the edge connecting them

Microsoft’s GraphRAG method goes further by extracting an entity graph from source documents, identifying communities of related entities and creating summaries of those communities. This helps the system answer both local questions about specific entities and global questions about an entire dataset. Microsoft’s GraphRAG research paper was submitted on 24 April 2024, following a public Microsoft Research introduction in February 2024.

Simple example

Imagine a property company has information about:

1. Projects
2. Locations
3. Architects
4. Contractors
5. Schools
6. Hospitals
7. Amenities
8. Planning permissions
9. Construction stages

Classic RAG can retrieve a paragraph about one project.

GraphRAG can help answer a broader question such as:

Which projects are connected to the same contractors, are near international schools and have experienced similar planning delays?

The system can follow relationships across several entities instead of relying only on passages that happen to contain similar words.

Local and global questions

GraphRAG is particularly useful for distinguishing between two kinds of questions.

Local question:

What company supplied the windows for Project A?

Global question:

What are the main causes of construction delays across all our projects?

The second question requires an understanding of patterns across the collection. This was one of the central problems Microsoft’s GraphRAG research attempted to address.

Where GraphRAG is used

GraphRAG is useful for:

1. Fraud and financial-crime investigations
2. Scientific literature analysis
3. Legal discovery
4. Cybersecurity threat intelligence
5. Supply-chain analysis
6. Corporate intelligence
7. Complex property and construction records
8. Medical and biological research
9. Organisational knowledge management
10. Analysis of themes across large document collections

Advantages

1. Preserves relationships that ordinary chunk retrieval may miss
2. Supports multi-hop questions
3. Helps identify patterns across a complete dataset
4. Can make complex knowledge more explainable
5. Useful for both specific facts and high-level summaries

Limitations

1. Knowledge graphs can be expensive to create and update.
2. Entity extraction can introduce mistakes.
3. Graph construction usually requires additional LLM calls.
4. A graph may oversimplify information that does not fit clean relationships.
5. Indexing can be considerably slower than Classic RAG.
6. Small or simple document collections may not justify the extra complexity.

Microsoft describes GraphRAG as a structured, hierarchical RAG system that builds a knowledge graph from unstructured text. Its implementation was released publicly in July 2024 through the Microsoft GraphRAG project.

3. What is Agentic RAG?

Agentic RAG gives an AI agent control over the retrieval process so it can plan, choose tools, perform multiple searches, inspect results and decide what to do next.

Classic RAG follows a predetermined route. Agentic RAG can adapt its route to the question.

How Agentic RAG works

An Agentic RAG system may:

1. Decide whether retrieval is required.
2. Break a complex question into smaller questions.
3. Select which databases, websites or APIs to search.
4. Run several searches in parallel or sequence.
5. Inspect the results.
6. Rewrite weak search queries.
7. Compare conflicting sources.
8. Request additional evidence.
9. Critique the draft answer.
10. Stop when it has sufficient information or reaches a cost limit.

Simple example

A user asks:

Compare three properties below €350,000 that are suitable for a family, near an international school and potentially appropriate for a residency application.

A Classic RAG system might run one search against a property database.

An Agentic RAG system could:

1. Search the current property inventory.
2. Filter by price and bedrooms.
3. Search approved information about nearby schools.
4. Calculate approximate travel distances.
5. Check official residency requirements.
6. Identify missing or conflicting details.
7. Compare the remaining properties.
8. Produce a cited report with appropriate legal and price disclaimers.

When was Agentic RAG invented?

Agentic RAG does not have a single universally accepted invention date.

Its foundations developed through several areas of research:

1. The ReAct framework, published at ICLR 2023, combined reasoning with actions.
2. Self-RAG, published at ICLR 2024, trained a model to retrieve, generate and critique its own work.
3. Tool-using agents, query planning and adaptive retrieval continued developing through 2023 and 2024.
4. A major Agentic RAG survey was submitted in January 2025 and later expanded into a detailed taxonomy.

It is most accurate to say that Agentic RAG emerged as a recognised architecture during 2024 and 2025, rather than being invented by one company on one date.

Where Agentic RAG is used

1. Deep research
2. Market and competitor analysis
3. Complex customer-support investigations
4. Financial research
5. Legal research
6. Medical-literature reviews
7. Travel planning
8. Software-development agents
9. Multi-database enterprise search
10. Personalised recommendations
11. Due-diligence workflows

Advantages

1. Handles complex, multi-step questions
2. Can recover from weak search results
3. Chooses different sources for different subtasks
4. Supports verification and self-correction
5. Can combine retrieval with calculations, APIs and other tools

Limitations

1. More expensive than Classic RAG
2. Usually slower
3. More difficult to reproduce and test
4. Can enter unnecessary retrieval loops
5. Requires clear stopping conditions
6. Creates additional security risks when agents can access tools or private data
7. A model’s self-check is not equivalent to independent fact-checking

Agentic RAG should be controlled with tool permissions, source restrictions, step limits, cost budgets and human review for high-stakes decisions.

4. What is Hybrid RAG?

Hybrid RAG combines two or more retrieval techniques, data sources or RAG architectures to improve coverage and accuracy.

Unlike Classic RAG or Microsoft’s specific GraphRAG architecture, Hybrid RAG is an umbrella term. There is no single official Hybrid RAG design and no universally accepted invention date.

The most common meaning: keyword plus vector search

The most common Hybrid RAG architecture combines:

1. Keyword search, which finds exact words, names, codes and phrases.
2. Vector search, which finds passages with a similar meaning.

Microsoft’s documentation defines hybrid search as keyword and vector search executed together, with their results combined into one ranked list. Azure AI Search’s hybrid-search documentation explains the strengths of both approaches.

Simple example

A buyer asks:

Is Apartment A203 one of the two-bedroom units with a private garden?

Keyword search is good at finding the exact identifier A203.

Vector search is good at understanding that “private garden” may be described in the source as “exclusive landscaped outdoor area.”

A hybrid retriever can use both signals.

Other meanings of Hybrid RAG

Hybrid RAG can also combine:

1. Vector search and a knowledge graph
2. Document search and SQL queries
3. Internal documents and live web search
4. Text, image and table retrieval
5. Classic RAG for simple questions and Agentic RAG for complex questions
6. Dense retrieval, sparse retrieval and a semantic reranker
7. GraphRAG for relationships and vector search for source passages

Where Hybrid RAG is used

1. E-commerce catalogues
2. Technical support
3. Product inventory
4. Legal and regulatory search
5. Healthcare knowledge systems
6. Enterprise search
7. Multilingual document collections
8. Property databases
9. Systems containing exact reference numbers
10. Applications combining structured and unstructured data

Advantages

1. Better handling of both exact and conceptual searches
2. Greater flexibility across different question types
3. Can combine structured and unstructured data
4. Often improves recall without abandoning precision
5. More practical for messy enterprise data

Limitations

1. Multiple result lists must be combined fairly.
2. Different retrieval systems may return incompatible scores.
3. More components create more failure points.
4. Tuning becomes harder.
5. A complicated hybrid system can cost more without improving results.

Hybrid retrieval is increasingly a practical default for production RAG, especially when users search for both exact identifiers and natural-language concepts.

5. What is Hyper-RAG?

Hyper-RAG is a hypergraph-driven RAG method designed to capture relationships involving three or more entities at the same time.

It should not be confused with a general marketing term for “very advanced RAG.” Hyper-RAG refers to a specific research method introduced by Yifan Feng and colleagues.

Graph versus hypergraph

A normal graph uses edges that connect pairs of nodes:

1. Drug A → interacts with → Drug B
2. Person A → works for → Company B

A hypergraph can use one hyperedge to connect several nodes as one relationship:

1. Drug A + Drug B + genetic condition + patient group → combined clinical interaction
2. Buyer + household status + property type + residency rule → one multi-entity eligibility relationship

This matters when the meaning exists in the group as a whole and cannot be represented accurately as several independent pairs.

Simple example

Suppose a medical research question involves:

1. A particular medicine
2. A second medicine
3. A genetic marker
4. An age group
5. A neurological condition

GraphRAG can store several pairwise connections. Hyper-RAG attempts to preserve the complete multi-entity relationship as a single structured association.

This does not mean a Hyper-RAG system should independently make clinical decisions. Medical deployment would still require validated data, expert oversight and appropriate regulation.

When was Hyper-RAG invented?

The Hyper-RAG paper was first submitted to arXiv on 30 March 2025. The peer-reviewed article was published in Nature Communications on 27 April 2026, with the version of record released on 2 July 2026.

The study evaluated Hyper-RAG with:

1. GPT-4o Mini
2. Qwen-Plus
3. Llama 3.3 70B
4. GLM-4-Air
5. DeepSeek-V3
6. Doubao-1.5-Pro

Across the study’s NeurologyCrop evaluation, the researchers reported an average 12.3% improvement over direct LLM use. They also reported stronger results than the GraphRAG and LightRAG baselines used in that experiment. These are promising research findings, but they should not be interpreted as proof that Hyper-RAG will deliver the same improvement for every dataset, model or business application. Read the peer-reviewed Hyper-RAG study.

Where Hyper-RAG may be useful

1. Medical and biological knowledge
2. Drug-interaction research
3. Complex legal relationships
4. Financial-risk networks
5. Scientific literature
6. Multi-party events
7. Supply chains involving several dependencies
8. Fraud involving coordinated groups
9. Complex regulatory eligibility rules

Advantages

1. Represents pairwise and multi-entity relationships
2. May preserve information lost during ordinary graph construction
3. Designed for complex and multi-hop questions
4. Compatible with different underlying LLMs
5. Potentially valuable in relationship-heavy specialist domains

Limitations

1. Considerably newer than Classic or Hybrid RAG
2. More complex knowledge extraction
3. High-order relationships can be difficult to identify correctly
4. Cross-document and cross-chunk relationships remain challenging
5. Limited production evidence compared with mature RAG methods
6. No public evidence that ChatGPT or Claude universally uses Hyper-RAG internally

As of August 2026, Hyper-RAG should be considered promising but comparatively early-stage.

These categories can overlap. For example, an Agentic RAG system may use hybrid search, query a knowledge graph and fall back to Classic RAG when the question is simple.

Which RAG technologies are used with ChatGPT, Claude, Gemini and other LLMs?

The most important point is:

RAG is normally an architecture built around an LLM, not a feature that belongs exclusively to the base model.

GPT, Claude, Gemini, Llama, DeepSeek and Qwen models can all receive retrieved context. The surrounding application determines which retrieval architecture is used.

Does ChatGPT use GraphRAG or Hyper-RAG?

OpenAI publicly documents web search, file search, connectors and agentic research capabilities. However, this does not justify claiming that every ChatGPT answer uses one particular RAG architecture.

There is no public documentation establishing that ChatGPT universally uses Microsoft GraphRAG or the Hyper-RAG research architecture.

The same caution applies to Claude, Gemini and other commercial systems. A product may retrieve information without disclosing the complete internal ranking, graph or orchestration system.

Which RAG architecture should you choose?

Choose Classic RAG when:

1. Questions usually have one clear answer.
2. The answer appears in one or two document sections.
3. Speed and affordability are priorities.
4. You are building your first RAG system.
5. Your dataset is relatively small and well organised.

Choose Hybrid RAG when:

1. Users search using product codes, names or legal references.
2. Exact wording and conceptual meaning both matter.
3. You have structured and unstructured data.
4. Classic vector retrieval is missing important results.

Choose GraphRAG when:

1. Relationships are central to the problem.
2. Questions require following several connections.
3. Users need themes or patterns across an entire collection.
4. Your organisation can support the additional indexing cost.

Choose Agentic RAG when:

1. Questions require multiple searches.
2. Several databases or tools must be consulted.
3. The system must adapt its plan based on results.
4. Research quality is more important than immediate speed.

Consider Hyper-RAG when:

1. Important knowledge exists in relationships involving three or more entities.
2. Pairwise graphs are losing critical context.
3. The domain justifies experimental architecture and thorough evaluation.
4. You have specialist expertise to validate extracted relationships.

For most organisations, the safest progression is:

Classic RAG → Hybrid retrieval → Add graph or agentic capabilities only where testing demonstrates a benefit

Does RAG eliminate hallucinations?

No. RAG can improve grounding, but it does not guarantee truth.

A RAG system can still produce an incorrect answer when:

1. The source document is wrong.
2. The information is outdated.
3. The retriever selects the wrong passages.
4. The correct passage is never retrieved.
5. The model misinterprets good evidence.
6. Retrieved sources contradict each other.
7. Too much irrelevant context distracts the model.
8. A malicious document contains hidden instructions.
9. The system combines information users were not authorised to access.

The OWASP RAG Security Cheat Sheet warns that RAG introduces risks such as document poisoning, unauthorised access, data leakage and prompt injection through retrieved content.

Important or high-stakes answers should therefore include source citations, confidence rules and human review.

Common RAG mistakes

1. Starting with the most complicated architecture

A large multi-agent graph system may look impressive, but it can be slower, more expensive and harder to evaluate. Begin with the simplest architecture capable of answering the real questions.

2. Using poor-quality source documents

RAG cannot reliably repair incorrect, duplicated or outdated knowledge. Source governance is as important as model quality.

3. Dividing documents into arbitrary chunks

Poor chunking can separate a heading from its explanation, a price from its conditions or a legal rule from its exception.

4. Retrieving too many passages

More context is not always better. Irrelevant passages can reduce answer quality and increase cost.

5. Ignoring exact search terms

Vector search may understand meaning but miss identifiers such as model numbers, property codes or legal clauses. This is where hybrid retrieval becomes valuable.

6. Evaluating only the final answer

A good evaluation should separately measure:

1. Did the system retrieve the correct evidence?
2. Did it rank that evidence highly enough?
3. Was the answer supported by the evidence?
4. Were citations accurate?
5. Did the system refuse when evidence was insufficient?

7. Claiming that RAG makes an AI factual

RAG provides evidence to the model. It does not force the model to use that evidence perfectly.

Where are we with RAG in 2026?

By August 2026:

1. Classic RAG is a mature approach for document-grounded assistants.
2. Hybrid keyword and vector retrieval is a common production design.
3. GraphRAG is established for relationship-heavy and global-analysis tasks.
4. Agentic RAG is expanding rapidly through research systems, enterprise-search products and AI agents.
5. Hyper-RAG has peer-reviewed evidence but remains much less mature in general commercial deployment.
6. Long-context models increasingly complement RAG rather than automatically replacing it.
7. Security, source permissions, citations and evaluation are becoming central production requirements.

The future of RAG: what should we expect?

The following developments are informed expectations rather than guaranteed outcomes.

1. RAG systems will choose their own retrieval mode

Future systems are likely to route questions according to complexity:

1. No retrieval for simple conversational questions
2. Classic RAG for one-document facts
3. Hybrid search for exact and semantic queries
4. Graph retrieval for relationships
5. Agentic retrieval for complex investigations
6. Hypergraph retrieval for high-order associations

This can provide stronger answers without paying the cost of the most complex architecture for every question.

2. Agentic retrieval will become more controlled

More autonomy alone is not the goal. Production systems will increasingly use:

1. Search budgets
2. Maximum step limits
3. Approved-source lists
4. Permission-aware tools
5. Verification stages
6. Human escalation
7. Auditable retrieval logs

The future is likely to be bounded agency, not unlimited searching.

3. Multimodal RAG will become normal

RAG will increasingly retrieve from:

1. Text
2. Tables
3. Images
4. Diagrams
5. Audio
6. Video
7. Maps
8. 3D and spatial data

A construction assistant, for example, may need to retrieve written specifications, floor plans, site photographs and progress videos in the same answer.

4. Knowledge structures will become more dynamic

Instead of rebuilding an entire index periodically, future systems will update:

1. Changed facts
2. New relationships
3. Time-sensitive records
4. Entity histories
5. User permissions
6. Source reliability scores

Temporal knowledge will be particularly important because the correct answer may depend on the date.

5. Long context and RAG will work together

Larger context windows allow models to read more material directly, but sending an entire archive with every question can be slow and expensive.

RAG can identify the most relevant sources, while long-context models can analyse larger retrieved sections. Research comparing RAG and long-context approaches indicates that the best choice depends on performance and computational cost rather than one method universally replacing the other.

6. Provenance will become more important than fluent answers

Future enterprise systems will be judged not only on how well they write, but also on whether they can show:

1. Which source supported each claim
2. When the source was updated
3. Who approved it
4. Whether sources disagree
5. What evidence was missing
6. How the retrieval decision was made

7. Hypergraph and richer relational retrieval will continue developing

Hyper-RAG demonstrates one approach to preserving multi-entity relationships. Future work may improve cross-document relationship extraction, automated hypergraph construction and cost-efficient retrieval.

However, richer structures will need to demonstrate consistent benefits on real organisational data before becoming a standard replacement for simpler systems.

Key takeaways

1. RAG gives an LLM external evidence before it generates an answer.
2. Classic RAG is simple, fast and suitable for straightforward document questions.
3. GraphRAG focuses on entities, relationships and themes across large collections.
4. Agentic RAG plans and performs multiple retrieval steps.
5. Hybrid RAG combines search methods, knowledge stores or RAG architectures.
6. Hyper-RAG represents relationships involving several entities through hypergraphs.
7. RAG methods are usually model-agnostic and can be paired with GPT, Claude, Gemini, Llama, DeepSeek, Qwen and other models.
8. No RAG architecture completely eliminates hallucinations.
9. The best system is the simplest one that performs reliably on tested, real-world questions.

Frequently asked questions

What does RAG stand for?

RAG stands for Retrieval-Augmented Generation. It combines information retrieval with generative AI so the model can use external evidence when answering.

Is RAG a type of LLM?

No. RAG is normally an architecture surrounding an LLM. The retriever finds evidence, while the LLM reads that evidence and generates the response.

Does ChatGPT use RAG?

Some ChatGPT and OpenAI features clearly use retrieval, including ChatGPT Search, file search and deep research. However, it is too broad to claim that every ChatGPT answer uses the same RAG architecture.

What is the difference between Classic RAG and GraphRAG?

Classic RAG retrieves document passages based mainly on relevance to the question. GraphRAG also represents entities and relationships, making it better suited to connected facts, multi-hop questions and global themes.

What is the difference between GraphRAG and Hyper-RAG?

GraphRAG normally represents pairwise relationships through edges between two nodes. Hyper-RAG uses hyperedges that can connect several nodes as one multi-entity relationship.

Is Agentic RAG better than Classic RAG?

Not for every task. Agentic RAG is more flexible for complex research, but it is also slower, more expensive and harder to control. Classic RAG is often better for simple questions.

Is RAG the same as fine-tuning?

No. Fine-tuning changes a model’s parameters to influence its behaviour or specialised abilities. RAG supplies external information at the time of the request. The two methods can be used together.

Will long-context LLMs replace RAG?

Probably not completely. Long context is valuable when a model must analyse large source sections, while RAG helps select relevant material from much larger collections. Many systems will combine both.

Conclusion

RAG has developed from a relatively simple retrieve-and-generate method into a family of architectures for connecting AI with external knowledge.

Classic RAG remains the practical starting point. Hybrid retrieval improves search across real-world data. GraphRAG adds structured relationships. Agentic RAG introduces adaptive research and tool use. Hyper-RAG explores a newer method for representing relationships involving several entities at once.

The future is unlikely to belong to one single RAG architecture. More likely, AI systems will automatically select and combine retrieval methods based on the question, available evidence, cost, permissions and required level of reliability.

8. Sources

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv/NeurIPS

Full URL: https://arxiv.org/abs/2005.11401

Supports: The origin, publication date, architecture and original purpose of modern RAG.

From Local to Global: A Graph RAG Approach to Query-Focused Summarization — Microsoft Research/arXiv

Full URL: https://arxiv.org/abs/2404.16130

Supports: GraphRAG’s entity graph, community summaries, local/global questions and 2024 timeline.

Project GraphRAG — Microsoft Research

Full URL: https://www.microsoft.com/en-us/research/project/graphrag/

Supports: Microsoft’s description of GraphRAG and its July 2024 open-source release.

ReAct: Synergizing Reasoning and Acting in Language Models — OpenReview/ICLR

Full URL: https://openreview.net/forum?id=WE_vluYUL-X

Supports: The reasoning-and-action foundations that contributed to agentic AI workflows.

Self-RAG: Learning to Retrieve, Generate, and Critique Through Self-Reflection — OpenReview/ICLR

Full URL: https://openreview.net/forum?id=hSyW5go0v8

Supports: Adaptive retrieval, generation and self-critique research preceding modern Agentic RAG.

Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG — arXiv

Full URL: https://arxiv.org/abs/2501.09136

Supports: Agentic RAG definitions, taxonomy, applications, trade-offs and January 2025 research timeline.

Hybrid Search Overview — Microsoft Azure AI Search

Full URL: https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview

Supports: The definition and benefits of combining keyword and vector search.

Agentic Retrieval Overview — Microsoft Azure AI Search

Full URL: https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview

Supports: Multi-query planning and agentic retrieval in enterprise search.

Hyper-RAG: Combating LLM Hallucinations Using Hypergraph-Driven Retrieval-Augmented Generation — Nature Communications

Full URL: https://www.nature.com/articles/s41467-026-71411-1

Supports: Hyper-RAG’s definition, hypergraph structure, model evaluations, reported results, limitations and publication dates.

File Search — OpenAI API Documentation

Full URL: https://developers.openai.com/api/docs/guides/tools-file-search

Supports: OpenAI’s documented semantic and keyword retrieval over uploaded knowledge bases.

Introducing ChatGPT Search — OpenAI

Full URL: https://openai.com/index/introducing-chatgpt-search/

Supports: Current-information retrieval and source citations in ChatGPT Search.

Introducing Deep Research — OpenAI

Full URL: https://openai.com/index/introducing-deep-research/

Supports: Multi-step, agentic internet research in ChatGPT.

Claude Can Now Search the Web — Anthropic

Full URL: https://www.anthropic.com/news/web-search

Supports: Claude’s web retrieval, current information and direct citations.

Claude Takes Research to New Places — Anthropic

Full URL: https://www.anthropic.com/news/research

Supports: Claude’s multi-source Research capability.

Search Result Content Blocks — Anthropic Documentation

Full URL: https://docs.anthropic.com/en/docs/build-with-claude/search-results

Supports: Building cited RAG applications with Claude and developer-supplied search results.

Grounding with Google Search — Google Cloud

Full URL: https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/ground-with-google-search

Supports: Grounding Gemini responses with current public web information.

Introducing Vertex AI RAG Engine — Google Cloud

Full URL: https://cloud.google.com/blog/products/ai-machine-learning/introducing-vertex-ai-rag-engine/

Supports: Google Cloud’s managed infrastructure for enterprise RAG implementations.

RAG in Qwen-Agent — Qwen

Full URL: https://qwenlm.github.io/Qwen-Agent/en/guide/core_moduls/rag/

Supports: Qwen-Agent’s document parsing, BM25 retrieval and configurable hybrid retrieval capabilities.

RAG Security Cheat Sheet — OWASP

Full URL: https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html

Supports: RAG security risks, including poisoning, prompt injection, access control and sensitive-data leakage.

Retrieval-Augmented Generation or Long-Context LLMs? — ACL Anthology/EMNLP 2024

Full URL: https://aclanthology.org/2024.emnlp-industry.66/

Supports: The comparison and complementary roles of RAG and long-context language models.