O problema que o RAG veio resolver
Imagine um dos cientistas mais brilhantes do mundo, com acesso a toda a literatura acadêmica publicada até determinada data — mas sem acesso a nada que tenha ocorrido depois disso. Ele sabe tudo o que sabia antes, mas ignora completamente o que aconteceu ontem, na semana passada ou no último mês. Pior: às vezes, quando a resposta não está em sua memória, ele simplesmente inventa uma — com a mesma confiança de quando realmente sabe a resposta.
Essa é, em essência, a condição dos grandes modelos de linguagem (LLMs — Large Language Models) em sua forma mais básica. Eles são extraordinariamente capazes para uma infinidade de tarefas, mas sofrem de dois problemas estruturais graves: o conhecimento estático, limitado à data de corte do treinamento, e as alucinações, fenômeno pelo qual o modelo gera informações falsas apresentadas com aparência de certeza.
Foi para resolver — ou ao menos mitigar drasticamente — esses dois problemas que Patrick Lewis e seus colegas de pesquisa da Facebook AI Research (hoje Meta AI), da University College London e da New York University publicaram, em maio de 2020, um artigo que se tornaria um dos mais influentes da história recente da inteligência artificial: “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”. O nome da técnica que propuseram? RAG — Retrieval-Augmented Generation.
O próprio Lewis, em entrevista à NVIDIA, admitiu com bom humor que se soubesse que o termo se tornaria tão difundido, teria pensado mais cuidadosamente no nome. “Definitivamente teríamos pensado melhor no nome se soubéssemos que nosso trabalho se tornaria tão widespread”, disse ele. Mas o nome pegou — e o conceito revolucionou a indústria.
1. Fundamentos Conceituais: O Que é RAG?
1.1 A Definição técnica
RAG é uma arquitetura de inteligência artificial que combina dois tipos de memória: a memória paramétrica, armazenada nos pesos de um modelo de linguagem pré-treinado, e a memória não-paramétrica, que consiste em uma base de dados externa consultada em tempo real. O resultado é um sistema capaz de gerar respostas fundamentadas em fatos específicos e atualizados, ao invés de depender exclusivamente do que o modelo memorizou durante o treinamento.
Em termos mais simples: o RAG ensina o modelo a consultar fontes externas antes de responder, assim como um pesquisador competente vai à biblioteca — ou ao Google — antes de redigir um parecer, ao invés de confiar apenas na própria memória.
Como descrevem Lewis et al. (2020) no artigo seminal, o RAG pode ser entendido como “uma receita de ajuste fino de propósito geral para geração aumentada por recuperação — modelos que combinam memória paramétrica pré-treinada com memória não-paramétrica para geração de linguagem.” A proposta é elegante em sua concepção: o modelo aprende não apenas a responder, mas a decidir o que buscar e como usar o que encontrou.
Por que Isso Importa? O problema das alucinações
Os LLMs modernos são treinados em bilhões de tokens de texto, o que lhes confere uma capacidade extraordinária de compreensão e geração de linguagem natural. No entanto, como aponta a literatura técnica, “a capacidade desses modelos de acessar e manipular conhecimento com precisão ainda é limitada, e, portanto, em tarefas intensivas em conhecimento, seu desempenho fica aquém de arquiteturas específicas para tarefas” (Lewis et al., 2020).
O problema se manifesta de maneiras perigosas em aplicações do mundo real. Um assistente médico que alucina dosagens de medicamentos, um sistema jurídico que inventa precedentes ou um assistente financeiro que fabrica dados de mercado não são apenas inúteis — são ativamente perigosos. Estudos indicam que o RAG é capaz de reduzir as taxas de alucinação factual entre 40% e 60% em comparação com a geração puramente paramétrica, dependendo da qualidade da recuperação.
Além disso, o RAG oferece algo que os modelos tradicionais nunca poderiam oferecer: rastreabilidade. Assim como as notas de rodapé de um artigo científico, o RAG pode citar a fonte de cada informação que gera, permitindo que o usuário verifique independentemente as afirmações. Isso não é apenas tecnicamente superior — é epistemicamente honesto.
RAG vs. Fine-Tuning: A comparação que toda equipe de engenharia precisa fazer
Quando uma organização precisa adaptar um LLM a um domínio específico — seja medicina, direito, finanças ou engenharia — ela tipicamente enfrenta uma escolha: fazer fine-tuning (ajuste fino do modelo em dados específicos do domínio) ou implementar RAG. Cada abordagem tem seus méritos.
O fine-tuning integra o conhecimento diretamente nos parâmetros do modelo, tornando-o intrinsecamente especializado. No entanto, é um processo caro, demorado e estático — o modelo treinado ontem não sabe o que aconteceu hoje. Além disso, quando os dados mudam — e em ambientes corporativos, eles mudam constantemente — é necessário retreinar o modelo, o que pode custar dezenas de milhares de dólares em computação.
O RAG, por sua vez, não modifica o modelo. Em vez disso, alimenta o modelo com informações atualizadas em tempo de inferência. Isso o torna incrivelmente flexível: a base de conhecimento pode ser atualizada a qualquer momento, sem necessidade de retreinamento. Como observou Lewis, desenvolvedores podem implementar o processo com tão poucas quanto cinco linhas de código — tornando o método mais rápido e menos custoso do que retreinar um modelo com datasets adicionais.
A escolha não é binária: as melhores implementações frequentemente combinam as duas abordagens, usando fine-tuning para adaptar o estilo e o comportamento do modelo e RAG para fornecer conhecimento factual atualizado.
A arquitetura do RAG: dissecando o pipeline
Um sistema RAG completo é composto por três fases principais: indexação, recuperação e geração. Cada fase tem sua própria complexidade técnica e seus próprios pontos de falha potenciais.
Fase 1 — Indexação: Preparando a base de conhecimento
Antes de qualquer consulta ser feita, os documentos que formarão a base de conhecimento precisam ser processados e indexados. Esse processo envolve quatro etapas fundamentais:
Coleta e carregamento de dados. Os dados podem vir de diversas fontes: PDFs, páginas web, bancos de dados relacionais, wikis corporativas, e-mails, arquivos de texto, transcrições de vídeo, entre outros. A qualidade e a curadoria dos dados nessa etapa têm impacto direto e decisivo na qualidade das respostas geradas. Lixo entra, lixo sai — esse princípio nunca foi tão verdadeiro quanto em sistemas RAG.
Fragmentação (chunking). Documentos completos são geralmente grandes demais para serem processados integralmente em cada consulta. Por isso, são divididos em fragmentos menores — tipicamente entre 256 e 512 tokens. A estratégia de fragmentação é uma das decisões mais críticas do design do sistema: fragmentos muito pequenos perdem contexto; fragmentos muito grandes consomem desnecessariamente a janela de contexto do LLM e podem diluir a relevância semântica.
Geração de embeddings. Cada fragmento é então convertido em um vetor numérico — um embedding — por meio de um modelo de embeddings (como os da família BERT, OpenAI, Cohere ou modelos open-source como o sentence-transformers). Esse vetor captura o significado semântico do fragmento em um espaço de alta dimensão, tipicamente entre 768 e 3.072 dimensões. Fragmentos com significados semelhantes ficam próximos nesse espaço vetorial, independentemente das palavras exatas usadas.
Armazenamento no banco de dados vetorial. Os embeddings gerados são armazenados em um banco de dados vetorial especializado, otimizado para buscas por similaridade em alta velocidade. Bancos de dados como Pinecone, Weaviate, Milvus, Chroma e pgvector (extensão do PostgreSQL) são projetados especificamente para esse fim, usando estruturas de indexação como HNSW (Hierarchical Navigable Small World) e IVF (Inverted File Index) para reduzir a complexidade de busca de O(n) para tempo logarítmico.
Fase 2 — Recuperação: Encontrando os fragmentos relevantes
Quando o usuário faz uma consulta, o sistema precisa identificar, dentre todos os fragmentos indexados, quais são mais relevantes para responder à pergunta. Esse processo de recuperação é onde a maior parte da evolução técnica do RAG aconteceu nos últimos anos.
Busca semântica (densa). A consulta do usuário é convertida em um embedding usando o mesmo modelo utilizado na indexação — isso é fundamental. Em seguida, o banco de dados vetorial realiza uma busca pelos fragmentos cujos embeddings são mais próximos ao embedding da consulta, usando métricas de similaridade como cosseno ou produto interno. Essa abordagem captura a intenção semântica da pergunta, encontrando fragmentos relevantes mesmo quando as palavras exatas não coincidem.
Busca lexical (esparsa). Algoritmos como BM25 (uma evolução sofisticada do TF-IDF) buscam correspondências baseadas em palavras-chave exatas. Essa abordagem é particularmente útil para termos específicos de domínio: nomes de produtos, siglas, códigos, termos técnicos que o modelo de embedding pode não ter representado adequadamente.
Busca híbrida. A melhor prática atual é combinar as duas abordagens por meio de técnicas como Reciprocal Rank Fusion (RRF), que mescla os resultados de ambas as buscas em uma lista unificada e ordenada por relevância. Implementações como o Pinecone permitem essa configuração com configuração mínima.
Reranking. Um passo adicional que cresceu enormemente em importância: após a recuperação inicial dos top-k fragmentos (tipicamente 50-100 candidatos), um modelo de reranking — como os oferecidos pela Cohere ou modelos open-source como BGE-Reranker — avalia cada par (consulta, fragmento) com muito mais profundidade do que o simples cálculo de similaridade de embeddings. O objetivo é filtrar os resultados para os 5-10 mais relevantes com alta precisão. Esse único componente pode dobrar a qualidade das respostas em sistemas bem implementados.
Fase 3 — Geração: Integrando contexto e resposta
Com os fragmentos mais relevantes recuperados, eles são inseridos no prompt enviado ao LLM, compondo o que se chama de contexto aumentado. O modelo então gera sua resposta baseado tanto em seu conhecimento paramétrico quanto no contexto fornecido, mas com instruções explícitas para priorizar as informações recuperadas e, idealmente, citá-las.
O design do prompt nessa fase é crucial. Instruções como “responda apenas com base nos documentos fornecidos” ou “se a informação não estiver nos documentos, informe que não sabe” são essenciais para minimizar alucinações — mas precisam ser calibradas cuidadosamente para não tornar o sistema excessivamente restritivo a ponto de se recusar a responder perguntas que poderia responder bem.
RAG-Sequence vs. RAG-Token: Os dois modelos originais
No artigo seminal de Lewis et al. (2020), foram propostas duas variantes do modelo RAG. No RAG-Sequence, o mesmo conjunto de documentos recuperados é usado para gerar toda a sequência de saída — o documento é tratado como uma variável latente marginalizada para calcular a probabilidade da sequência. No RAG-Token, cada token da resposta gerada pode ser condicionado a um documento diferente — o que confere maior flexibilidade, mas maior complexidade computacional.
Estudos demonstraram que o RAG-Sequence tende a produzir respostas mais coesas e diversas para tarefas de geração de texto mais longas, enquanto o RAG-Token pode ser mais preciso para respostas curtas e factuais como resposta a perguntas de domínio aberto.
Evolução do RAG: De Naive RAG a Agentic RAG
Desde o artigo original de 2020, o RAG evoluiu de forma vertiginosa. O que começou como uma arquitetura relativamente simples (recuperar-uma-vez, gerar-uma-vez) transformou-se em um ecossistema de arquiteturas sofisticadas.
Naive RAG (RAG Básico)
O RAG em sua forma mais simples: o usuário faz uma consulta, o sistema recupera os k documentos mais similares e o LLM gera uma resposta. Funciona bem para casos de uso simples, mas tem limitações claras: recuperação única (não há segunda chance se o primeiro resultado for ruim), ausência de verificação de qualidade e incapacidade de lidar com perguntas que requerem raciocínio de múltiplas etapas.
Advanced RAG
Incorpora técnicas como reranking, reformulação de consultas, recuperação múltipla e chunking adaptativo. O sistema torna-se mais robusto, mas ainda opera de forma relativamente linear.
Corrective RAG (CRAG)
Proposto por Yan et al. (2024), o CRAG adiciona um avaliador leve que pontua a qualidade dos documentos recuperados antes de passá-los ao gerador. Se os documentos forem classificados como “corretos”, a geração prossegue normalmente. Se forem “ambíguos” ou “incorretos”, o sistema reformula a consulta e tenta uma nova recuperação — potencialmente de fontes externas via busca na web. Essa abordagem endereça diretamente um dos problemas mais críticos do RAG básico: a recuperação ruim pode piorar as alucinações, não apenas deixar de melhorá-las.
GraphRAG
Uma das inovações mais significativas dos últimos anos: ao invés de tratar documentos como coleções de fragmentos isolados, o GraphRAG extrai entidades (pessoas, organizações, conceitos, eventos) e seus relacionamentos durante a indexação, construindo um grafo de conhecimento estruturado. Durante a recuperação, o sistema pode navegar por esse grafo para responder perguntas que requerem múltiplos saltos de raciocínio — algo que a busca vetorial simples é fundamentalmente incapaz de fazer.
Por exemplo, a pergunta “Como a política de juros do Fed em 2024 afetou os resultados das startups de tecnologia financiadas por capital de risco?” requer conectar entidades e relações através de múltiplos documentos. O GraphRAG pode atravessar o grafo de conhecimento para construir essa resposta, onde o RAG vetorial simples simplesmente falharia.
Agentic RAG
A fronteira atual do campo: ao invés de um pipeline fixo de recuperação-geração, o Agentic RAG usa um LLM como agente de raciocínio que decide dinamicamente quando recuperar, o que recuperar, quais ferramentas usar e como sintetizar informações de múltiplas fontes. O agente pode fazer múltiplas rodadas de recuperação, refinando progressivamente sua compreensão do problema antes de gerar a resposta final.
Como descreve a Pinecone em sua documentação técnica: “Com o RAG agêntico, trata-se de decidir quais perguntas fazer, quais ferramentas usar, quando usá-las e então agregar resultados para fundamentar respostas.” Isso representa uma mudança paradigmática: de um pipeline de busca para um sistema de raciocínio ativo.
Multimodal RAG
A extensão natural do RAG para além do texto: sistemas que indexam e recuperam imagens, áudio, tabelas, vídeos e outros tipos de dados estruturados e não-estruturados. Um sistema de manutenção industrial, por exemplo, pode recuperar não apenas documentação técnica textual, mas também imagens de peças, diagramas de circuito e transcrições de vídeos de treinamento, tudo integrado em uma resposta coesa.
Como medir se seu RAG é bom?
Um dos erros mais comuns de equipes que implementam RAG é a ausência de métricas rigorosas de avaliação. Intuição e avaliação manual não escalam — e frequentemente enganam. A literatura técnica estabelece um conjunto robusto de métricas para avaliar sistemas RAG:
Faithfulness (Fidelidade): A resposta gerada é suportada pelos documentos recuperados? Mede se o modelo “inventou” algo além do que estava no contexto. Uma alta fidelidade indica baixa alucinação.
Answer Relevance (Relevância da Resposta): A resposta gerada responde de fato à pergunta feita? Uma resposta pode ser fiel ao contexto mas completamente irrelevante para a pergunta do usuário.
Context Precision (Precisão do Contexto): Dentre os fragmentos recuperados, qual proporção era genuinamente relevante para responder à pergunta? Alta precisão significa menos ruído no contexto passado ao LLM.
Context Recall (Recall do Contexto): O sistema conseguiu recuperar todos os fragmentos relevantes que existiam na base de conhecimento? Alto recall garante que nenhuma informação crítica foi perdida.
Frameworks como RAGAS (RAG Assessment) e DeepEval automatizam o cálculo dessas métricas, permitindo avaliação contínua e sistemática. A prática de RAGOps — manter um conjunto de dados de referência (golden dataset) e bloquear implantações que não atendam a thresholds de qualidade predefinidos — é hoje considerada não negociável para sistemas empresariais sérios.
Casos de uso no mundo real
O RAG não é uma tecnologia em busca de problema — é uma solução que encontrou problemas em praticamente todos os setores da economia:
Assistência jurídica: Sistemas RAG indexando milhares de contratos, legislação, jurisprudência e pareceres técnicos, permitindo que advogados façam perguntas em linguagem natural e recebam respostas com citações precisas dos textos legais relevantes. A rastreabilidade das fontes é essencial nesse domínio — uma resposta sem citação não tem valor jurídico.
Suporte ao cliente: Ao invés de chatbots com respostas pré-programadas, sistemas RAG conectados a bases de conhecimento de produtos, manuais técnicos e histórico de tickets resolvidos. A resposta é sempre atual e contextualizada ao produto específico do cliente.
Medicina e saúde: Como envisagado pelos próprios autores do artigo original, um assistente médico conectado a uma base de dados atualizada de literatura médica, protocolos clínicos e bulas de medicamentos. A pesquisa acadêmica publicada na MDPI em 2025 explora precisamente como arquiteturas RAG híbridas reduzem drasticamente alucinações em contextos clínicos, onde a precisão factual é literalmente uma questão de vida ou morte.
Inteligência de negócios: Analistas financeiros conectando modelos de linguagem a relatórios trimestrais, dados de mercado, transcrições de earnings calls e análises setoriais. O sistema responde perguntas como “como nosso desempenho nesse trimestre se compara ao de nossos três maiores concorrentes?” com precisão e rastreabilidade.
Educação: Tutores virtuais conectados ao material do curso, capazes de responder perguntas dos alunos com referências precisas aos textos das aulas, mantendo consistência pedagógica e evitando que o modelo introduza conceitos fora do currículo.
Pesquisa científica: O sistema OpenScholar, descrito na literatura recente, usa RAG sobre 45 milhões de artigos científicos de acesso aberto para sintetizar respostas com citações bibliográficas, superando substancialmente modelos de propósito geral.
Desafios atuais e fronteiras do campo
Seria desonesto apresentar o RAG como uma solução perfeita. A literatura acadêmica e a experiência prática apontam para desafios reais que a comunidade ainda trabalha para resolver:
O problema da recuperação imperfeita. RAG não elimina alucinações — apenas as reduz. Uma recuperação ruim pode, perversamente, piorar as alucinações ao fornecer ao modelo um contexto enganoso. A qualidade do retriever é o elo mais fraco da corrente e o foco mais importante de esforços de melhoria.
Chunking como arte, não ciência. Não existe uma estratégia de fragmentação universalmente ótima. O tamanho ideal de chunk, a sobreposição, a hierarquia de separadores — tudo depende do tipo de documento, do perfil das consultas e do modelo usado. Isso exige experimentação empírica para cada caso de uso.
A maldição da alta dimensionalidade. Vetores com 3.072 dimensões em bases de dados com milhões de documentos representam desafios computacionais e de armazenamento significativos. Técnicas de quantização (redução da precisão dos vetores) e indexação aproximada mitigam mas não eliminam esse custo.
Raciocínio multi-hop. Perguntas que requerem encadear informações de múltiplos documentos de forma lógica — “quem foi o mentor do cientista que descobriu X, e qual foi o trabalho mais influente desse mentor?” — continuam sendo um desafio para sistemas RAG puramente vetoriais. O GraphRAG e as arquiteturas agênticas abordam esse problema, mas com trade-offs em custo e latência.
Latência. Um pipeline RAG completo com busca híbrida, reranking e geração por um LLM premium pode levar vários segundos para responder. Para aplicações que exigem respostas em tempo real, esse é um gargalo real que precisa ser gerenciado cuidadosamente.
RAG vs. contexto longo. O surgimento de modelos com janelas de contexto de 1 milhão ou mais de tokens levantou a questão: por que recuperar, se posso simplesmente passar todo o meu conhecimento no prompt? A resposta é: custo, latência e precisão. Processar 1 milhão de tokens em cada consulta é ordens de magnitude mais caro e lento do que um sistema RAG bem configurado. Além disso, modelos frequentemente perdem informações em meio a contextos muito longos (“needle in a haystack problem”). O RAG e o contexto longo são complementares, não competidores.
O que separa sistemas mediocres de sistemas excelentes
Depois de tudo o que discutimos, aqui está o destilado das práticas que distinguem implementações amadorísticas de sistemas RAG verdadeiramente robustos:
Qualidade dos dados antes de qualquer coisa. Nenhuma técnica de recuperação compensa dados mal estruturados, duplicados, desatualizados ou inconsistentes. Invista em limpeza, curadoria e atualização contínua da base de conhecimento. Estabeleça uma “fonte única de verdade” para conteúdo RAG-ready.
Use sempre busca híbrida em produção. A combinação de busca semântica e lexical é superior a qualquer uma das abordagens isoladas na grande maioria dos casos de uso reais. O custo adicional é mínimo; o ganho de qualidade é consistente.
Adicione reranking. É o componente de maior ROI em sistemas RAG maduros. Recupere 50-100 candidatos com busca vetorial rápida (otimizando recall) e use um cross-encoder para filtrar para os 5 melhores (otimizando precisão).
Meça tudo com rigor. Use RAGAS ou DeepEval para calcular métricas de fidelidade, relevância e precisão de contexto em um conjunto de dados de referência estável. Nunca faça deploy de uma nova versão sem comparar com a versão anterior usando essas métricas. Isso é RAGOps.
Projete o prompt com cuidado. Instrua explicitamente o LLM a usar apenas o contexto fornecido e a reconhecer quando não sabe. Mas teste rigorosamente para não tornar o sistema excessivamente restritivo.
Inclua metadados ricos na indexação. Data de publicação, autor, categoria, departamento responsável, versão do documento — metadados permitem filtragem e permitem que o sistema gere respostas com citações precisas e rastreáveis.
Monitore em produção continuamente. Implementar é o início, não o fim. Rastreie padrões de consultas não respondidas, feedbacks negativos dos usuários e degradação de métricas ao longo do tempo. A base de conhecimento envelhece — mantenha-a atualizada.
RAG Como Infraestrutura Estratégica
Quando Patrick Lewis e sua equipe publicaram aquele paper em maio de 2020, provavelmente não imaginavam que o acrônimo que inventaram na hora — com um certo desconforto, como o próprio Lewis reconheceu — se tornaria o nome de uma das arquiteturas mais transformadoras da inteligência artificial moderna.
O RAG resolve um problema fundamental: como fazer modelos de linguagem extremamente capazes atuarem de forma confiável, verificável e atualizada sobre o mundo real — e não apenas sobre uma versão congelada do passado armazenada em seus parâmetros. Essa é a diferença entre uma ferramenta impressionante em demonstrações e uma infraestrutura confiável em produção.
Em 2024, o número de artigos científicos sobre RAG publicados no arXiv chegou a 1.202 — contra apenas 10 em 2022. Esse crescimento exponencial não é hype acadêmico: reflete uma necessidade real e urgente de resolver os problemas das alucinações e do conhecimento estático em sistemas de IA que são cada vez mais integrados em processos críticos de negócios e de saúde pública.
O campo avança rapidamente. GraphRAG, Agentic RAG, RAG multimodal, RAGOps — o que era tecnologia de ponta há dois anos é agora prática padrão em times de engenharia maduros. E o que ainda está na fronteira da pesquisa acadêmica chegará à produção antes do que muitos esperam.
Para organizações que ainda não implementaram RAG: o momento de começar é agora. Para as que já implementaram na forma básica: o momento de evoluir para arquiteturas mais sofisticadas, com reranking, busca híbrida e avaliação rigorosa, também é agora. A inteligência artificial confiável, rastreável e atualizada não é um destino distante — é uma escolha de arquitetura.
E essa arquitetura tem um nome: RAG.
Fontes
- Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., … & Kiela, D. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems (NeurIPS 2020).
https://arxiv.org/abs/2005.11401 - Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Versão completa via Meta AI Research.
https://ai.meta.com/research/publications/retrieval-augmented-generation-for-knowledge-intensive-nlp-tasks/ - Neuhaus, J., Brauer, S., & Söllner, M. (2025). Retrieval-Augmented Generation (RAG). Business & Information Systems Engineering, Springer Nature.
https://link.springer.com/article/10.1007/s12599-025-00945-3 - Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. ACM Digital Library (NeurIPS Proceedings).
https://dl.acm.org/doi/abs/10.5555/3495724.3496517 - Merritt, R. (2023). What Is Retrieval-Augmented Generation aka RAG. NVIDIA Blog.
https://blogs.nvidia.com/blog/what-is-retrieval-augmented-generation/ - Semantic Scholar — Lewis et al. (2020). Retrieval-Augmented Generation for NLP Tasks. Citation database entry.
https://www.semanticscholar.org/paper/Retrieval-Augmented-Generation-for-NLP-Tasks-Lewis-Perez/659bf9ce7175e1ec266ff54359e2bd76e0b7ff31 - ResearchGate. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — Entrada de publicação e citações.
https://www.researchgate.net/publication/341639856_Retrieval-Augmented_Generation_for_Knowledge-Intensive_NLP_Tasks - Pinecone. Retrieval-Augmented Generation (RAG) — Documentação técnica e guia de implementação.
https://www.pinecone.io/learn/retrieval-augmented-generation/ - Yan, S. et al. (2024). Corrective Retrieval-Augmented Generation. arXiv preprint arXiv:2401.15884.
https://arxiv.org/abs/2401.15884 - Gao, Y. et al. (2024). Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv preprint arXiv:2312.10997.
https://arxiv.org/abs/2312.10997 - MDPI Electronics. (2025). Evaluating Retrieval-Augmented Generation Variants for Clinical Decision Support: Hallucination Mitigation and Secure On-Premises Deployment.
https://www.mdpi.com/2079-9292/14/21/4227 - Databricks Engineering Blog. Improving Retrieval and RAG with Embedding Model Finetuning.
https://www.databricks.com/blog/improving-retrieval-and-rag-embedding-model-finetuning - Yu, F. J. (2024). 2024: The Year of RAG — Part 1. Medium.
https://medium.com/@yu-joshua/2024-the-year-of-rag-part-1-bdf8a05f818d - Kusupati, A. et al. (2022). Matryoshka Representation Learning. NeurIPS 2022.
https://arxiv.org/abs/2205.13147 - Asai, A. et al. (2024). OpenScholar: Synthesizing Scientific Literature with Retrieval-Augmented LMs. arXiv preprint arXiv:2411.14199.
https://arxiv.org/abs/2411.14199
