RAG sem Mistério: o que É, Quando Usar, Como Configurar e Quando Não Vale a Pena

Resumo

Este artigo responde a uma pergunta: o que é RAG, para que serve, como se configura e em que situações ele vale ou não vale a pena?

O raciocínio começa pelas limitações de um modelo de linguagem que responde só com o que aprendeu no treino. Delas surge a ideia do RAG (Retrieval-Augmented Generation, ou geração aumentada por recuperação): buscar trechos relevantes numa base externa antes de responder. Para entender como a busca funciona, o artigo introduz embeddings, busca vetorial e busca lexical. Com esses conceitos, a conclusão que organiza o resto do texto fica clara: a qualidade da resposta é limitada pela qualidade da recuperação. Por isso a configuração é apresentada na ordem do pipeline, do parsing ao prompt, seguida de como medir se cada etapa funciona. Por fim, o artigo compara o RAG com as alternativas (fine-tuning e contexto longo), mostra onde ele falha e reúne tudo num checklist.

Em síntese, a literatura mostra três coisas. Para colocar conhecimento factual novo num modelo, a recuperação supera de forma consistente o fine-tuning não supervisionado. Parsing, chunking, busca híbrida e reranking pesam mais do que trocar de modelo. E o RAG não elimina alucinação, abre uma superfície de ataque nova e, quando a base é pequena, perde para a alternativa mais simples de colocar tudo no contexto.

1. O Problema: o que um Modelo de Linguagem Não Consegue Fazer Sozinho

Um modelo de linguagem (LLM) responde com base no que ficou registrado em seus pesos durante o treino. Isso impõe cinco limitações:

Retreinar o modelo a cada mudança resolveria as duas primeiras limitações, mas custa semanas e muito dinheiro, e não resolve as outras três. É preciso outra abordagem.

2. A Ideia: Buscar Antes de Gerar

A abordagem proposta por Lewis et al. (2020), pesquisadores da Meta AI, no artigo Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020), foi combinar dois tipos de memória:

• memória paramétrica: o que está nos pesos de um modelo gerador (seq2seq);
• memória não paramétrica: um índice vetorial da Wikipédia, consultado por um recuperador neural denso (DPR, de Karpukhin et al., 2020).

Antes de responder, o sistema recupera trechos relevantes do índice e os entrega ao gerador como contexto. O modelo continua raciocinando com o que aprendeu no treino, mas os fatos passam a vir de uma fonte que você controla, atualiza e pode citar. No artigo original, esse arranjo gerou respostas mais específicas e factuais que um modelo apenas paramétrico.

Trabalhos da mesma época seguiram a mesma ideia, como o REALM (Guu et al., 2020) e, depois, o RETRO, da DeepMind, que recupera trechos de uma base de trilhões de tokens (Borgeaud et al., 2021).

Voltando à tabela da seção 1, cada limitação ganha uma resposta:

Há ainda dois benefícios de arquitetura. Conhecimento e raciocínio ficam separados: dá para trocar o modelo sem refazer a base, e vice-versa. E o custo cai, porque processar vinte trechos custa muito menos que processar um acervo inteiro a cada pergunta (Li et al., 2024).

Hoje "RAG" virou nome genérico para qualquer sistema que recupera antes de gerar. A revisão de Gao et al. (2023) organiza a evolução em três gerações: Naive RAG (buscar e colar), Advanced RAG (otimizações antes e depois da busca) e Modular RAG (componentes combináveis, com roteamento e busca iterativa).

A pergunta seguinte: "recuperar trechos relevantes" pressupõe que o sistema saiba comparar o significado de uma pergunta com o de milhares de documentos. Como isso é feito?

3. O Mecanismo: Como a Busca Encontra Trechos Relevantes

3.1 Três conceitos

• Embedding: um vetor numérico que representa o significado de um texto. Textos com significado parecido ficam próximos nesse espaço vetorial.
• Busca vetorial (densa): transforma a pergunta em embedding e encontra os trechos cujos embeddings estão mais próximos. Captura sinônimos e paráfrases, mesmo sem palavras em comum.
• Busca lexical (esparsa, BM25): encontra trechos que contêm as mesmas palavras da pergunta, ponderadas por raridade. Captura termos exatos: códigos de erro, siglas, nomes de produto, IDs.

3.2 As duas fases de um sistema RAG

Como os embeddings dos documentos precisam existir antes da pergunta, todo sistema RAG tem uma fase de indexação (offline) e uma fase de consulta (online):

INDEXAÇÃO (offline)                    CONSULTA (online)
────────────────────                   ─────────────────
Documentos                             Pergunta do usuário
   │ parsing (PDF, HTML, tabelas)         │ (opcional) reescrita / expansão
   ▼                                      ▼
Chunking (pedaços de texto)            Busca vetorial + lexical (BM25)
   │                                      │ fusão (ex.: Reciprocal Rank Fusion)
   ▼                                      ▼
Embeddings + metadados                 Reranking (cross-encoder)
   │                                      │ top-k trechos
   ▼                                      ▼
Índice (vetorial / BM25)  ───────────► Prompt = instruções + trechos + pergunta
                                          ▼
                                       LLM gera a resposta com citações

3.3 A consequência que organiza o resto do artigo

O diagrama mostra que o modelo só vê o que a recuperação entrega. Daí a frase que resume a literatura: se o trecho certo não chega ao prompt, nenhum modelo salva a resposta. Por isso a configuração, na próxima seção, segue a ordem do pipeline e concentra o esforço nas etapas anteriores à geração.

4. Como Configurar: Etapa por Etapa, na Ordem do Pipeline

4.1 Parsing e limpeza

É a primeira etapa, e erros aqui se propagam por todas as outras. Tabelas quebradas, cabeçalhos repetidos, rodapés, PDFs escaneados sem OCR e colunas que viram texto corrido estão entre as causas mais comuns de erro. É trabalho de engenharia de dados: extrair bem, preservar a estrutura (títulos, seções, tabelas) e guardar metadados (fonte, data, área, permissão), que serão usados na etapa 4.6.

4.2 Chunking

O documento é dividido em pedaços (chunks), e cada um vira um vetor. As decisões são:

• tamanho: pedaços pequenos demais perdem contexto; grandes demais diluem a relevância e gastam contexto;
• sobreposição (overlap): repetir parte do final de um chunk no início do próximo evita cortar uma ideia ao meio;
• fronteiras: respeitar seções e parágrafos costuma ser melhor que cortar por número fixo de caracteres.

Não existe tamanho universal. O certo depende do tipo de documento e de pergunta, e deve ser escolhido por teste (seção 5), não pelo padrão do framework.

4.3 Contexto no chunk (Contextual Retrieval)

O chunking cria um problema: um pedaço isolado muitas vezes perde o sentido. "A receita cresceu 3% no trimestre" não diz de qual empresa nem de qual trimestre. A Anthropic propôs usar um LLM para acrescentar a cada chunk, antes de indexar, uma frase curta que o situa no documento. Os resultados publicados, medidos como taxa de falha de recuperação no top-20 (Anthropic, 2024):

A tabela já antecipa as duas próximas etapas: somar BM25 à busca vetorial e reordenar com um reranker reduziram ainda mais as falhas. No mesmo experimento, passar os top-20 chunks ao modelo funcionou melhor que top-10 ou top-5.

4.4 Busca híbrida

A seção 3.1 mostrou que embeddings e BM25 têm pontos fortes diferentes. O benchmark BEIR avaliou 10 sistemas de recuperação em 18 conjuntos de dados e concluiu que o BM25 continua um baseline robusto, enquanto modelos densos muitas vezes perdem para ele fora do domínio em que foram treinados (Thakur et al., 2021). Na prática, combinar as duas buscas cobre os pontos fracos de cada uma. As listas podem ser unidas com Reciprocal Rank Fusion (RRF), método simples que soma o inverso da posição de cada documento em cada lista (Cormack et al., 2009).

4.5 Reranking

A busca inicial traz dezenas de candidatos rapidamente, mas com precisão limitada, porque compara vetores calculados separadamente. Um reranker (em geral um cross-encoder, que lê a pergunta e o trecho juntos) reordena esses candidatos e mantém os melhores. No BEIR, arquiteturas de reranking tiveram o melhor desempenho médio, com custo computacional maior (Thakur et al., 2021). É a troca clássica de precisão por latência.

4.6 Metadados, filtros e permissões

Os metadados guardados na etapa 4.1 servem aqui. Filtrar por data, área, idioma ou versão antes da busca melhora a precisão. Filtrar por permissão do usuário é obrigatório: se o índice é compartilhado, o usuário pode "recuperar" o que não deveria ver. O OWASP lista esse risco como LLM08:2025 Vector and Embedding Weaknesses e recomenda controle de acesso fino e armazenamento vetorial ciente de permissões (OWASP, 2025).

4.7 O prompt de geração

Só agora o modelo entra. A documentação da Anthropic traz três recomendações diretamente aplicáveis a RAG (Anthropic, s.d.):

• documentos no topo, pergunta no fim: segundo a documentação, perguntas no fim melhoraram a qualidade da resposta em até 30% nos testes, sobretudo com vários documentos;
• estrutura com tags: cada trecho dentro de <document>, com <source> e demais metadados;
• ancorar em citações: pedir que o modelo primeiro extraia os trechos relevantes e só depois responda.

A isso se soma uma instrução simples e essencial: responder apenas com base nos trechos e dizer "não encontrei" quando a informação não estiver lá.

4.8 As etapas juntas: um exemplo mínimo

Um exemplo ilustrativo com PostgreSQL + pgvector (etapas 4.4 e 4.6: busca vetorial com filtro de permissão) e o template de prompt (etapa 4.7):

-- ILUSTRATIVO — índice vetorial com pgvector e filtro de permissão
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
    id          bigserial PRIMARY KEY,
    documento   text        NOT NULL,
    secao       text,
    conteudo    text        NOT NULL,
    grupo_acesso text       NOT NULL,
    atualizado_em date      NOT NULL,
    embedding   vector(1024) NOT NULL   -- dimensão do seu modelo de embeddings
);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

-- :q = embedding da pergunta; :grupos = grupos do usuário
SELECT documento, secao, conteudo
FROM chunks
WHERE grupo_acesso = ANY(:grupos)
ORDER BY embedding <=> :q      -- distância de cosseno
LIMIT 20;

<documents>
  <document>
    <source>Política de Reembolso v3 — seção 2.1 (atualizado em 2026-08-10)</source>
    <document_content>...</document_content>
  </document>
  ...
</documents>

Responda à pergunta usando SOMENTE os documentos acima.
Primeiro, copie em <quotes> os trechos que sustentam a resposta.
Depois, responda em <answer> citando a fonte de cada afirmação.
Se os documentos não contiverem a resposta, diga "Não encontrei essa
informação nos documentos disponíveis" e não complete com conhecimento próprio.

Pergunta: {pergunta}

Frameworks como LangChain e LlamaIndex, e serviços gerenciados de busca (Azure AI Search, OpenSearch, bases vetoriais dedicadas), automatizam boa parte disso. As decisões das etapas 4.1 a 4.7 continuam sendo suas.

4.9 Técnicas avançadas (quando o básico não bastar)

Cada técnica abaixo ataca uma falha específica do pipeline básico:

A pergunta seguinte: cada etapa tem várias opções (tamanho de chunk, top-k, com ou sem reranker). Como saber qual configuração funciona na sua base?

5. Como Saber se Funciona: Avaliar Recuperação e Geração Separadamente

Como o pipeline tem duas partes (recuperar e gerar), um erro na resposta pode vir de qualquer uma. Por isso a regra é avaliar as duas separadamente; se forem medidas juntas, não dá para saber onde está o problema.

O framework RAGAS propõe métricas para essas dimensões sem exigir anotação humana de cada resposta (Es et al., 2023). Ainda assim, um conjunto de perguntas reais com respostas conferidas por especialistas continua sendo a base mais confiável, principalmente em domínios regulados. É esse conjunto que permite escolher, por medição, o chunking da etapa 4.2 e o top-k da etapa 4.3.

6. Quando Usar: o RAG Comparado às Alternativas

Saber configurar não responde se o RAG é a ferramenta certa. Para isso é preciso compará-lo com as duas alternativas: ensinar o modelo por fine-tuning ou simplesmente colocar tudo no contexto.

6.1 RAG ou fine-tuning?

Ovadia et al. (2023) compararam as duas abordagens em tarefas intensivas em conhecimento. O RAG superou de forma consistente o fine-tuning não supervisionado, tanto para conhecimento que o modelo já tinha visto no treino quanto para conhecimento inteiramente novo. Os autores também observaram que os modelos têm dificuldade de aprender fatos novos por fine-tuning não supervisionado.

A regra prática:

• RAG muda o que o modelo sabe (fatos, documentos, dados atuais);
• fine-tuning muda como o modelo se comporta (formato, tom, tarefa especializada, vocabulário de domínio).

As duas técnicas não são excludentes e podem ser combinadas.

6.2 RAG ou contexto longo?

Modelos atuais aceitam contextos muito grandes, o que cria uma alternativa óbvia: não buscar nada e entregar a base inteira.

• Quando a base é pequena, essa é a opção recomendada pela própria Anthropic: com menos de 200 mil tokens (cerca de 500 páginas), dá para colocar a base inteira no prompt, usando prompt caching para reduzir custo e latência (Anthropic, 2024). Nesse caso, o RAG só acrescenta componentes que podem falhar: chunking, índice, busca, sincronização.
• Quando a base é grande, a comparação é de custo contra qualidade. Li et al. (2024), em estudo publicado no EMNLP, mostraram que, com recursos suficientes, o contexto longo superou o RAG em qualidade média, e a vantagem do RAG foi o custo muito menor. Os autores propuseram o Self-Route: o próprio modelo decide, pergunta a pergunta, se responde com RAG ou com o contexto completo, com qualidade comparável à do contexto longo e custo bem menor.

6.3 Onde o RAG se encaixa melhor

Juntando as duas comparações, o RAG é a escolha natural para:

• perguntas e respostas sobre documentação interna, manuais, políticas e bases de suporte;
• conhecimento que muda com frequência (preços, normas, catálogo, procedimentos);
• domínios em que citar a fonte é obrigatório: jurídico, saúde, compliance, auditoria;
• acervos grandes demais para caber no contexto do modelo;
• cenários com permissões diferentes por usuário ou por cliente.

7. Onde o RAG Falha

Mesmo bem configurado e bem escolhido, o RAG tem limites. Cada um decorre do mecanismo descrito na seção 3.

7.1 Perguntas que exigem visão do todo

"Resuma todos os contratos", "quais são os temas recorrentes nas reclamações", "quantos clientes citaram atraso". A busca top-k só enxerga fragmentos. O artigo do GraphRAG afirma que o RAG convencional falha em perguntas globais sobre um corpus inteiro, porque elas são tarefas de sumarização, não de recuperação (Edge et al., 2024). Para contagens e agregações sobre dados estruturados, o caminho certo costuma ser SQL, não RAG.

7.2 Trecho irrelevante atrapalha

Recuperar "algo parecido" não é neutro:

• o desempenho dos modelos cai muito quando o problema vem acompanhado de informação irrelevante (Shi et al., 2023);
• documentos que o recuperador classifica como muito relevantes, mas que não contêm a resposta, prejudicam a precisão (Cuconasu et al., 2024);
• o desempenho cai quando a informação relevante está no meio de um contexto longo e é maior no começo ou no fim, o efeito Lost in the Middle (Liu et al., 2023).

É por isso que reranking, filtros e um limite sensato de trechos (etapas 4.5 e 4.6) importam.

7.3 O RAG não garante ausência de alucinação

Um estudo pré-registrado de Stanford avaliou ferramentas jurídicas comerciais que se anunciavam como "livres de alucinação" por usarem RAG. O Lexis+ AI errou ou alucinou em 17% das consultas e o Westlaw AI-Assisted Research em 33%, contra 43% do GPT-4 sem recuperação (Magesh et al., 2024). O RAG reduz a alucinação, mas não a elimina: o modelo ainda pode interpretar mal um trecho, misturar fontes ou citar um documento que não sustenta a afirmação.

7.4 A base vira superfície de ataque

Se o modelo confia no que é recuperado, quem controla a base controla a resposta:

• envenenamento: o PoisonedRAG alcançou 90% de sucesso ao inserir apenas cinco textos maliciosos por pergunta-alvo numa base com milhões de textos, e as defesas avaliadas foram insuficientes (Zou et al., 2024);
• injeção indireta de prompt: instruções escondidas em documentos recuperados podem ser executadas pelo modelo como se fossem do usuário (Greshake et al., 2023);
• vazamento entre contextos e inversão de embeddings: riscos catalogados pelo OWASP no LLM08:2025 (OWASP, 2025).

A defesa é aceitar só fontes confiáveis, validar o que entra no índice, tratar todo trecho recuperado como dado (nunca como instrução) e registrar as consultas.

7.5 Custo operacional

O RAG é um pipeline de dados: ingestão, reprocessamento quando o modelo de embeddings muda, sincronização de documentos apagados ou alterados, monitoramento. Sem dono e sem métricas, o índice envelhece e as respostas pioram sem que ninguém perceba.

8. Recomendações Práticas: Checklist

O checklist segue a mesma ordem do artigo: decidir, construir, medir, proteger.

Decidir

1. Pergunte primeiro se precisa de RAG. Base abaixo de ~200 mil tokens: teste colocar tudo no contexto com prompt caching.
2. Monte um conjunto de avaliação antes de construir. De 50 a 200 perguntas reais, com a resposta esperada e o documento-fonte.

Construir

1. Invista em parsing. Tabelas e PDFs mal extraídos derrubam tudo o que vem depois.
2. Teste o chunking com seu conjunto de avaliação, em vez de aceitar o padrão do framework.
3. Adicione contexto aos chunks (Contextual Retrieval) quando os trechos perderem o sentido isolados.
4. Comece com busca híbrida (vetorial + BM25) e um reranker.
5. Filtre por permissão na busca, nunca só na resposta.
6. Instrua o modelo a citar e a dizer "não sei".

Medir e operar

1. Meça recuperação e geração separadamente e monitore em produção.
2. Trate a base como sistema de produção: dono, atualização, remoção de documentos obsoletos, logs.

Proteger e evoluir

1. Proteja a ingestão: fontes confiáveis, validação e trechos tratados como dados, não como instruções.
2. Só adote técnicas avançadas (GraphRAG, Self-RAG, agentes) quando a métrica mostrar um problema que elas resolvem.

9. Limitações e o que Ainda Não se Sabe

• Os números envelhecem rápido. Os estudos citados avaliaram modelos de 2023 e 2024. Janelas de contexto maiores e mais baratas mudam o ponto em que o RAG deixa de compensar.
• Os resultados da Anthropic são de um fornecedor, medidos nos próprios conjuntos de dados. Indicam uma direção, não garantem o resultado na sua base.
• Não há tamanho de chunk nem top-k universais. Qualquer número (inclusive o top-20 citado) deve ser validado no seu caso.
• Métricas automáticas de avaliação usam LLMs como juízes e herdam seus vieses. Não substituem a revisão de especialistas em domínios críticos.
• As defesas contra envenenamento e injeção indireta ainda são imaturas, segundo os próprios autores dos ataques.

10. Recapitulando o Raciocínio

1. Um LLM sozinho tem conhecimento congelado, não conhece dados privados, alucina em perguntas factuais e não cita fontes.
2. O RAG resolve isso buscando trechos relevantes antes de gerar: os fatos vêm de uma base que você controla.
3. A busca usa embeddings (significado) e BM25 (termos exatos), numa fase de indexação e outra de consulta.
4. Como o modelo só vê o que foi recuperado, a qualidade da recuperação limita a qualidade da resposta.
5. Por isso a configuração segue o pipeline (parsing, chunking, contexto, busca híbrida, reranking, filtros, prompt) e é validada medindo recuperação e geração separadamente.
6. Comparado às alternativas, o RAG muda o que o modelo sabe (o fine-tuning muda como ele se comporta) e perde para o contexto longo quando a base é pequena ou quando o custo não é restrição.
7. Ele falha em perguntas sobre o todo, sofre com trechos irrelevantes, não elimina a alucinação e transforma a base em superfície de ataque.

11. Conclusão

O RAG é, antes de tudo, um problema de busca com um modelo de linguagem no final. Serve para dar ao modelo conhecimento atual, privado e citável sem retreiná-lo, e a literatura mostra que, para esse fim, supera o fine-tuning. Os ganhos vêm menos da escolha do modelo e mais do trabalho de dados: extrair bem, dividir bem, buscar de forma híbrida, reordenar, filtrar por permissão e medir.

A resposta à pergunta, portanto: use RAG quando a base for grande, dinâmica, sensível a permissões ou exigir citação; evite quando ela couber no contexto, quando a pergunta exigir visão do todo ou quando ninguém puder operar o pipeline. E, quando usar, lembre que o RAG reduz a alucinação, mas não a elimina, e que a base de conhecimento passa a fazer parte da superfície de ataque.

Nota Metodológica

Os identificadores e títulos de todos os artigos do arXiv citados foram conferidos na API oficial do arXiv em 28/09/2026. Os números citados de Liu et al., Cuconasu et al., Zou et al., Thakur et al., Edge et al., Ovadia et al., Shi et al. e Es et al. foram conferidos contra os resumos (abstracts) oficiais. Os números de Magesh et al. foram conferidos na página do Stanford RegLab e no resumo do artigo; os de Li et al., na página do ACL Anthology. Os dados de Contextual Retrieval e as recomendações de prompt foram extraídos das páginas oficiais da Anthropic, e a descrição do LLM08:2025, da página oficial do OWASP, todas acessadas em 28/09/2026. A referência de Cormack et al. (2009) e os locais de publicação (conferências e periódicos) indicados nas referências não foram reconferidos na origem nesta revisão. Os exemplos de código são ilustrativos e não foram medidos contra nenhum benchmark.

Referências

1. Lewis, P.; Perez, E.; Piktus, A. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. Link

2. Karpukhin, V.; Oğuz, B.; Min, S. et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. EMNLP 2020. Link

3. Guu, K.; Lee, K.; Tung, Z.; Pasupat, P.; Chang, M.-W. (2020). REALM: Retrieval-Augmented Language Model Pre-Training. ICML 2020. Link

4. Borgeaud, S.; Mensch, A.; Hoffmann, J. et al. (2021). Improving Language Models by Retrieving from Trillions of Tokens. Link

5. Gao, Y.; Xiong, Y.; Gao, X. et al. (2023). Retrieval-Augmented Generation for Large Language Models: A Survey. Link

6. Thakur, N.; Reimers, N.; Rücklé, A.; Srivastava, A.; Gurevych, I. (2021). BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models. NeurIPS 2021 Datasets and Benchmarks. Link

7. Cormack, G. V.; Clarke, C. L. A.; Büttcher, S. (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. SIGIR 2009. Link

8. Anthropic. (2024). Introducing Contextual Retrieval. Link

9. Anthropic. (s.d.). Long context prompting tips. Documentação oficial. Link

10. OWASP GenAI Security Project. (2025). LLM08:2025 Vector and Embedding Weaknesses. Link

11. Gao, L.; Ma, X.; Lin, J.; Callan, J. (2022). Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE). ACL 2023. Link

12. Asai, A.; Wu, Z.; Wang, Y.; Sil, A.; Hajishirzi, H. (2023). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. Link

13. Yan, S.-Q.; Gu, J.-C.; Zhu, Y.; Ling, Z.-H. (2024). Corrective Retrieval Augmented Generation. Link

14. Edge, D.; Trinh, H.; Cheng, N. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. Link

15. Ovadia, O.; Brief, M.; Mishaeli, M.; Elisha, O. (2023). Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs. Link

16. Li, Z.; Li, C.; Zhang, M.; Mei, Q.; Bendersky, M. (2024). Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach. EMNLP 2024 (Industry Track). Link

17. Shi, F.; Chen, X.; Misra, K. et al. (2023). Large Language Models Can Be Easily Distracted by Irrelevant Context. ICML 2023. Link

18. Cuconasu, F.; Trappolini, G.; Siciliano, F. et al. (2024). The Power of Noise: Redefining Retrieval for RAG Systems. SIGIR 2024. Link

19. Liu, N. F.; Lin, K.; Hewitt, J. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. TACL 2024. Link

20. Magesh, V.; Surani, F.; Dahl, M.; Suzgun, M.; Manning, C. D.; Ho, D. E. (2024). Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools. Journal of Empirical Legal Studies (2025). Link

21. Zou, W.; Geng, R.; Wang, B.; Jia, J. (2024). PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models. USENIX Security 2025. Link

22. Greshake, K.; Abdelnabi, S.; Mishra, S. et al. (2023). Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. AISec '23. Link

23. Es, S.; James, J.; Espinosa-Anke, L.; Schockaert, S. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. EACL 2024 (System Demonstrations). Link