# RAG de ponta a ponta: um tutorial prático

Ideia-chave: O valor do RAG não está em “plugar um vector store”: está em ler bem os documentos, buscar de forma híbrida, fazer reranking e, acima de tudo, medir a recuperação e as respostas separadamente.

Nos testes da Anthropic (2024), adicionar contexto aos chunks, BM25 e um reranker reduziu as falhas de recuperação em 67%. Ferramentas comerciais de RAG jurídico alucinam em 17–33% dos casos (Stanford, 2024), e no benchmark CRAG da Meta (2024) os melhores sistemas de RAG industriais só respondem sem alucinar em 63% das vezes. Para medir tudo isso, um juiz LLM concorda com humanos em mais de 80% das vezes (Zheng et al., 2023).

Conferi quase tudo o que está aqui na documentação oficial e nos artigos citados em 23 de setembro de 2026. Alguns detalhes de ferramentas marcados com † vêm da experiência geral e não voltei a verificá-los. Recursos marcados com (preview) existem, mas o fornecedor ainda não os recomenda para produção. As siglas são explicadas na primeira vez em que aparecem e ficam reunidas no glossário no final; os artigos são citados pelo nome no texto (SPLADE, ColBERT, RAGAS), com autores, ano e link nas referências.

Parte I · Conceitos

1. O que é RAG, explicado com uma biblioteca

RAG (Retrieval-Augmented Generation) significa que, antes de responder, um modelo de linguagem busca nos seus documentos e responde a partir do que encontrou, citando a fonte.

Por que você precisa disso? Um modelo de linguagem não conhece os documentos internos da sua empresa, o conhecimento dele para numa data de corte e ele pode inventar coisas (“alucinar”). Com RAG, a resposta se apoia em documentos específicos que qualquer pessoa pode conferir, e atualizar o conhecimento não exige retreinar o modelo.

O jeito mais fácil de ver como as peças se encaixam é pensar em uma biblioteca e em alguém que chega ao balcão com uma pergunta:

1. A biblioteca são os seus documentos: tudo de onde o sistema pode tirar respostas, como PDFs, wikis ou políticas internas.
2. As fichas são os chunks. Ninguém relê um livro inteiro a cada pergunta, então cada documento é cortado em fichas pequenas, cada uma com um pedaço de informação que se entende sozinho.
3. O catálogo é o índice. Cada ficha é arquivada de duas formas: pelas palavras que contém e pelo que significa. É isso que depois permite buscar tanto por palavra-chave quanto por significado.
4. O bibliotecário é a busca. Quando chega uma pergunta, ele traz rapidamente umas 50 fichas que parecem relevantes, sem lê-las com atenção.
5. O especialista é o reranker. Ele lê a pergunta ao lado de cada uma dessas fichas e fica com as 5 melhores.
6. O redator é o modelo de linguagem. Só agora alguém escreve a resposta, usando essas 5 fichas e citando a ficha de onde sai cada frase. Se as fichas não têm a resposta, o honesto é dizer “não sei”.
7. O professor é a avaliação. Ele avalia duas coisas separadamente: se o bibliotecário trouxe as fichas certas e se a resposta é fiel a elas.

O resto do tutorial segue a mesma ordem: preparar os documentos (etapas 1 a 3), busca (4), reranking (5), geração (6) e avaliação (7).

Nem todo sistema RAG tem as sete etapas. Gao et al. (2023/24) distinguem três gerações:

Nos termos da biblioteca, o Naive RAG é um bibliotecário que passa as primeiras k fichas direto para o redator, sem o especialista no meio. Este tutorial descreve um Advanced RAG, com peças modulares onde elas compensam (seção 10).

2. Os três circuitos de um sistema RAG em produção

Um sistema RAG em produção funciona com três circuitos. O primeiro prepara os documentos uma única vez, offline: fontes, parsing e chunking, embeddings e índice (etapas 1 a 3 da biblioteca). O segundo roda a cada pergunta: busca híbrida, reranker e o modelo que responde com citações (etapas 4 a 6). O terceiro avalia, antes do deploy com um golden dataset e em produção com amostras do tráfego real, e devolve melhorias para os outros dois (etapa 7). As partes II a VI tratam deles nessa ordem.

Parte II · Preparando os documentos

3. Ler bem o documento (parsing)

O parsing tem mais impacto do que qualquer outra etapa, e é a que as equipes mais deixam de lado. Converta um PDF em “texto puro” e você perde os títulos, as tabelas ficam embaralhadas e cada chunk perde o seu contexto.

Os estudos concordam nisso:

• Os autores do ColPali (ICLR 2025) “costumam constatar que otimizar o pipeline de ingestão traz melhorias muito maiores do que otimizar o modelo de embedding”. O próprio ColPali dispensa a extração de texto e o chunking e indexa diretamente as imagens das páginas; no benchmark ViDoRe ele marcou 81.3 de nDCG@5, contra ~65–67 dos pipelines de parsing.
• No estudo da Unstructured sobre o FinanceBench (2024), o chunking por elementos do documento (títulos, tabelas) chegou a 53.2% de acurácia, contra 48.2% com chunks fixos de 512 tokens, e usou metade dos chunks.
• Um estudo em turco (2026) constatou que o chunking que respeita o layout ajuda muito mais em documentos com tabelas do que em documentos só de texto.

As ferramentas mais usadas são a Document Layout skill (Azure), o Document AI Layout Parser (Google) e o Docling (IBM, open source). A seção 22 compara as três.

4. Chunking

O chunking divide cada documento em pedaços pequenos (chunks) que são indexados separadamente.

4.1 As estratégias

4.2 O que diz a evidência: o chunking semântico é superestimado

• A Vectara (2024) perguntou “Is Semantic Chunking Worth the Computational Cost?” e concluiu que “os custos computacionais associados ao chunking semântico não se justificam por ganhos de desempenho consistentes”. O chunking de tamanho fixo venceu nos 4 datasets de documentos reais (no HotpotQA, por exemplo, o F1@5 foi 90.59 com tamanho fixo contra 87.37 com o semântico). O modelo de embedding pesou mais do que o chunking.
• A Chroma (2024) constatou que a estratégia de chunking muda o recall em até 9%. O chunker semântico padrão dela ficou um pouco abaixo da média (83.6% de recall), enquanto um chunker recursivo de 200 tokens sem sobreposição chegou a 88.1%. O melhor resultado (91.9%) usou um modelo de linguagem e custou bem mais.
• A NVIDIA (junho de 2025) obteve a melhor acurácia média (0.648) e a menor variância entre datasets com chunking por página.
• Em biomedicina (2026), o chunking semântico ganhou +8.4 pontos de F1 em um dataset, mas nos demais o chunking de tamanho fixo “continua competitivo ou melhor”. Depende do domínio.

4.3 O que funciona: adicionar contexto a cada chunk

O Contextual Retrieval da Anthropic (set. 2024) faz um modelo escrever 50–100 tokens de contexto e os coloca no início de cada chunk. Medido como a taxa de falha de recuperação dentro dos 20 primeiros resultados, partindo de uma linha de base de 5.7%:

• contexto só nos vetores: 3.7% (−35%)
• contexto nos vetores e no BM25: 2.9% (−49%)
• tudo isso mais um reranker: 1.9% (−67%)

O custo, pago uma única vez, é de ~$1.02 por milhão de tokens de documento com prompt caching. Cuidado ao citar esses números: as três porcentagens são reduções em relação à linha de base de 5.7%, então a contribuição do reranker em si é o passo de 2.9% para 1.9%.

O late chunking (Jina, 2024) calcula primeiro o embedding do documento inteiro e só depois o divide, de modo que cada vetor “sabe” de que documento vem. Ele melhora o nDCG@10 de +2.7% a +3.6% sem retreinar.

4.4 Tamanhos iniciais

Bhat et al. (2025) sugerem 64–128 tokens para perguntas factuais curtas e 512–1024 tokens para perguntas que exigem contexto amplo. O Azure recomenda começar com 512 tokens e 25% de sobreposição, e adicionar o título do documento aos chunks do meio.

Um padrão razoável: comece com chunking recursivo ou por seção/página de 256–512 tokens, não divida tabelas, adicione contexto e ajuste medindo (Parte VI).

5. Transformar texto em vetores (embeddings)

Um embedding é uma lista de números que representa o significado de um texto. Textos com significados parecidos ficam próximos:

Meça com os seus próprios dados. Os rankings públicos (como o MTEB) mudam todo mês e nem sempre refletem o seu domínio. E fixe a versão do modelo: se você misturar vetores de modelos diferentes, as buscas deixam de fazer sentido.

6. Índice e permissões

O índice guarda cada chunk com seu texto, seu vetor e seus metadados:

Sem allowed_groups e um filtro de segurança em cada busca, um estagiário poderia receber chunks de documentos do comitê executivo.

Parte III · Recuperação

7. BM25: busca por palavras-chave

O BM25 é o algoritmo clássico de busca por palavras-chave (léxica) e o padrão no Elasticsearch, no OpenSearch e no Azure AI Search. Ele funciona sobre um índice invertido, que se parece com o índice remissivo no final de um livro:

A pontuação tem três partes:

O BM25 é rápido, não precisa de modelo, pode ser explicado e é excelente para termos exatos como códigos, siglas e nomes próprios. O ponto fraco são os sinônimos: “notebook barato” não encontra “laptop econômico”.

8. Busca semântica: pelo significado

8.1 Vetores densos (busca de vizinhos mais próximos)

Aqui a pergunta vira um vetor e você recupera os chunks mais próximos. Fazer isso rápido sobre milhões de vetores exige um índice aproximado, geralmente HNSW (um grafo de vizinhos).

A busca densa entende sinônimos, paráfrases e idiomas diferentes. Por outro lado, é uma caixa-preta (não dá para explicar por que algo deu match), pode confundir códigos quase idênticos (ORA-00942 vs ORA-00943) e usa mais memória. A quantização reduz a memória comprimindo os números, por exemplo para 8 bits ou para binário.

8.2 Esparso aprendido (SPLADE, ELSER)

O esparso aprendido fica entre os dois. Um modelo expande o texto com termos relacionados e seus pesos, e a busca roda sobre um índice invertido, como no BM25:

"cheap laptop" → { laptop: 2.1, notebook: 1.8, computer: 1.2, cheap: 1.9, budget: 1.5, price: 0.9 }

É mais fácil de explicar do que os vetores densos e ainda encontra sinônimos. O problema é que depende do idioma do modelo (o ELSER é recomendado só para inglês) e tem limite de tokens (o ELSER codifica os primeiros 512 tokens de cada campo).

8.3 Qual vence

Nenhum deles vence sempre, e é por isso que se combinam.

9. Busca híbrida e RRF

9.1 O problema

As duas buscas devolvem pontuações em escalas incompatíveis:

Somar 12.4 + 0.81 faz tanto sentido quanto somar euros e quilos.

9.2 A solução: RRF (Reciprocal Rank Fusion)

O RRF ignora as pontuações e usa só a posição de cada documento em cada lista:

RRF(doc) = Σ  1 / (k + position of doc in that list)      with k = 60 typically
       over each list

Vamos usar os mesmos rankings de antes:

O doc_A vence porque aparece bem colocado nas duas listas. O RRF premia a concordância entre os dois métodos.

9.3 Por que k = 60?

O valor vem do artigo original (Cormack, Clarke e Büttcher, SIGIR 2009), onde foi escolhido empiricamente, e o Azure AI Search documenta que ele funciona melhor com valores pequenos, como 60.

9.4 Vantagens, limites e variantes

O RRF não precisa de calibração de escala nem de treino, e aceita N listas (BM25, vários vetores, várias reformulações da pergunta). Ele tem dois pontos fracos. Ignora a magnitude, então ser primeiro “com folga” vale o mesmo que ser primeiro “por um fio”. E uma lista ruim conta do mesmo jeito: se a busca vetorial devolve lixo, esse lixo também ganha pontos.

Há duas variantes comuns:

• O RRF ponderado dá mais peso a uma das listas (por exemplo, a lista vetorial ×2). Está disponível no Azure (vector weighting), no EnsembleRetriever do LangChain † e no Google Vector Search com rrf_ranking_alpha.
• A combinação linear normaliza as pontuações e as soma com pesos. Ela aproveita a magnitude, mas você precisa calibrá-la com dados. Exemplos são o retriever linear do Elasticsearch e o DBSF no Qdrant †.

Tenha em mente que o RRF não é um reranker. Ele só funde listas, e o reranker vem depois.

10. Estratégias avançadas de recuperação

11. Estudo de caso: Elasticsearch

O Elasticsearch tem quatro peças “semânticas” diferentes, e é fácil confundi-las:

• A. Denso: dense_vector + consulta knn, com quantização int8, int4 e BBQ. Você pode usar E5 (multilíngue), Jina (pelo Elastic Inference Service) ou modelos externos (OpenAI, Azure OpenAI, Cohere, Bedrock, Vertex AI, Hugging Face).
• B. O ELSER expande termos. O que ele acrescenta são associações aprendidas, não sinônimos. No benchmark BEIR feito pela própria Elastic, ele melhora o nDCG@10 em relação ao BM25 em 18% na média (10 vitórias, 1 empate, 1 derrota). É recomendado para inglês, lê 512 tokens por campo e exige assinatura paga.
• C. Reranker: o retriever text_similarity_reranker ou o comando RERANK no ES|QL.
• D. semantic_text (GA desde a versão 9.0). Se você não fixar o inference_id, índices novos podem passar a usar outro modelo depois de uma atualização de versão, então fixe sempre o modelo em produção.

Esta é a busca híbrida com reranker em uma única chamada:

{
  "retriever": {
    "text_similarity_reranker": {
      "retriever": {
        "rrf": {
          "retrievers": [
            { "standard": { "query": { "match":    { "content": "remote work days manager Spain" } } } },
            { "standard": { "query": { "semantic": { "field": "content_semantic",
                                                     "query": "remote work days manager Spain" } } } }
          ],
          "rank_window_size": 50,
          "rank_constant": 60
        }
      },
      "field": "content",
      "inference_id": "my-rerank-endpoint",
      "inference_text": "remote work days manager Spain",
      "rank_window_size": 50
    }
  }
}

Você também pode fundir com o retriever linear (normalizadores minmax ou l2_norm) ou, no ES|QL, com FORK + FUSE (RRF ou LINEAR) + RERANK. No formato multi-field, a Elastic normaliza os campos léxicos e semânticos para que cada grupo contribua com 50%.

Atenção ao vocabulário. No Elastic, “semantic search” significa buscar com embeddings; no Azure, o “semantic ranker” é um reranker.

Parte IV · Reranking

12. Reranking

12.1 O que é

Um reranker pega os ~50–150 candidatos da busca e os reordena lendo a pergunta e cada chunk juntos. Isso é mais preciso do que comparar vetores, porém mais lento, então você só o aplica a poucos candidatos.

A arquitetura típica tem dois estágios: busca híbrida (que prioriza a cobertura), depois um reranker sobre 100–150 candidatos e, por fim, de 10 a 20 chunks entregues ao modelo que escreve a resposta.

12.2 Tipos

12.3 Modelos de destaque (verificados)

12.4 Regras práticas

Um reranker é a melhoria mais barata e mais comprovada que você pode fazer. Nos números da Anthropic, só o acréscimo do reranker leva a taxa de falha de 2.9% para 1.9%.

Mas o reranker só reordena o que a busca encontrou. Se o documento correto não está entre os candidatos, ele não tem como salvar você, e é por isso que primeiro se mede a cobertura da recuperação (recall).

O que hoje diferencia os rerankers é a capacidade de seguir instruções: você pode passar regras de negócio como “priorize conteúdo recente”. Todo fornecedor diz que é o melhor, então meça com os seus dados.

Alguns complementos valem a pena. O MMR remove chunks redundantes. A compressão com LongLLMLingua dá +21.4% de qualidade com ~4× menos tokens. E a posição no prompt importa: coloque o conteúdo mais relevante no começo ou no fim (“Lost in the Middle”).

Parte V · Geração e guardrails

13. Geração com citações e guardrails

O prompt fica assim:

System:   Answer ONLY from the context. Cite every claim as [n].
          If the context does not contain the answer, say "I don't know".
Context:  [1] Remote Work Policy §3.2 Spain, p. 4: "Manager: 2 days/week..."
          [2] 2026 Annex, p. 1: "...starting January 2026, 3 days for..."
Question: remote work days for a manager in Spain

Os guardrails atuam antes, durante e depois da geração:

1. Antes, detectar tentativas de manipular o modelo (“jailbreak” ou prompt injection).
2. Durante, se o reranker não deixar nenhum chunk acima do limiar, responder “Não encontrei essa informação” em vez de inventar algo.
3. Depois, verificar se cada frase da resposta é sustentada pelos chunks. Se a verificação falhar, gerar de novo ou responder com cautela.

Parte VI · Avaliação

14. Dois testes separados

Se você olha só a resposta final, não sabe o que corrigir. A Microsoft chama a avaliação da etapa de recuperação de process evaluation e a avaliação da resposta de system evaluation.

15. O golden dataset (o “gabarito”)

O golden dataset é um conjunto de 100 a 300 perguntas, cada uma com a sua resposta correta e os documentos que deveriam aparecer:

{"query": "Remote work days, manager, Spain?",
 "ground_truth": "2 days per week; 3 from January 2026 according to the annex",
 "relevant_docs": [{"document_id": "teletrabajo_p4", "query_relevance_label": 4},
                   {"document_id": "anexo2026_p1",  "query_relevance_label": 3}]}

16. Métricas de recuperação, com números

Digamos que, para uma pergunta, os documentos corretos sejam A e C, e o buscador tenha devolvido [B, A, D, C, E].

Esses números dizem onde olhar. Se o Recall@50 está baixo, o problema está na recuperação (chunking, embeddings, falta de BM25), e o reranker não vai resolver. Se o Recall@50 está alto mas o nDCG@5 está baixo, o problema está no reranker.

17. Métricas de resposta, com números

Suponha que o sistema responda: “Você tem 2 dias por semana [1], 3 a partir de janeiro de 2026 [2], e pode escolher as sextas-feiras.”

A Microsoft enquadra da mesma forma: a fidelidade ao contexto é o lado da precisão (não acrescentar nada) e a completude é o lado da cobertura (não omitir nada crítico).

Outra opção é a avaliação por “nuggets” (TREC 2024): você define os fatos atômicos que uma boa resposta precisa conter e conta quantos aparecem.

18. O LLM como juiz

Ninguém revisa 10,000 respostas à mão, então outro modelo faz o papel de professor. Esse juiz tem vieses conhecidos. Prefere a primeira opção que vê (posição), prefere respostas longas (verbosidade) e prefere textos da própria família de modelos (autopreferência).

Para montar um juiz em que dê para confiar:

1. Um humano rotula 50–100 casos.
2. Meça a concordância juiz–humano (kappa de Cohen, acurácia, F1).
3. O juiz deve ser de uma família de modelos diferente da do gerador.
4. O juiz deve explicar a sua nota.
5. Pontuar afirmação por afirmação (RAGChecker) ou por nuggets é melhor do que dar uma única nota geral.

Até onde dá para confiar nele? O GPT-4 como juiz chega a mais de 80% de concordância com humanos, o mesmo nível observado entre dois humanos (Zheng et al., 2023). No TREC 2024, a concordância perfeita entre humano e GPT-4o foi de 56%, e de 72% quando o humano corrigia o rótulo do modelo. Ou seja, o juiz LLM é confiável para comparar sistemas e menos confiável pergunta a pergunta. O ARES combina algumas centenas de rótulos humanos com o juiz automático para produzir intervalos de confiança estatisticamente válidos.

19. Avaliação antes do deploy e em produção

Um quality gate na integração contínua poderia exigir que o Recall@10 não caia mais de 2 pontos, que a faithfulness fique ≥ 95% e que as respostas “não sei” corretas fiquem ≥ 90%. Esses limiares são só exemplos; quem define os reais é o negócio. Em produção, você amostra uma porcentagem do tráfego real e a avalia sem resposta de referência (faithfulness, relevância da resposta, relevância do contexto), junto com os votos positivos e negativos, a latência e o custo.

A Microsoft recomenda uma varredura de parâmetros (parameter sweep): testar combinações e medir qual vence. Os números abaixo são ilustrativos, não resultados reais:

O DeepEval sugere no máximo umas 5 métricas por aplicação. MLflow / Databricks recomendam usar os mesmos avaliadores em desenvolvimento e em produção. E em produção você só pode usar métricas que não precisam de uma resposta correta.

20. Por que isso importa: alucinação em sistemas reais

Vários desses números são de 2023–2024 e vêm de modelos mais antigos, então cite-os sempre com o ano e o modelo.

Parte VII · Um exemplo em produção no Azure

21. Copiloto de políticas internas, passo a passo

O caso é uma empresa com 20,000 funcionários, com documentos de RH, jurídico e compras no SharePoint e no Blob Storage. Ela precisa de permissões por usuário, citações em cada resposta e “não sei” quando não há informação.

21.1 Arquitetura

Se você conhece a stack LangChain + Chroma/Qdrant, as peças se correspondem assim:

21.2 Uma pergunta, de ponta a ponta

Ana, gerente em Madri, perguntou sobre o contrato dela mais cedo na conversa. Agora ela digita “e quantos dias posso trabalhar remotamente?”

1. O modelo reescreve a pergunta usando o histórico da conversa: “dias de trabalho remoto permitidos para um gerente na Espanha”.

2. O BM25 e a busca vetorial rodam em paralelo e são fundidos com RRF (k=60). Antes da pontuação, o filtro de segurança remove tudo o que Ana não tem permissão para ver.

3. O semantic ranker pega só os top 50 e dá a eles notas de 0 a 4:

   Nota	Significado
   4	Responde totalmente
   3	Relevante, mas incompleto
   2	Parcial
   1	Relacionado, responde muito pouco
   0	Irrelevante

   Chunks com nota < 2 são descartados. Se não sobrar nenhum, a resposta é “Não encontrei essa informação”. A Microsoft avisa que a distribuição das notas pode variar um pouco, então os limiares não devem ser muito finos.

4. O modelo gera a resposta com citações, usando a estrutura de prompt da seção 13.

5. Uma verificação de fidelidade confere se cada frase é sustentada pelos chunks. Se falhar, a resposta é gerada de novo ou dada com cautela.

Uma pergunta complexa (“compare o trabalho remoto na Espanha e no México e me diga qual se aplica se eu me mudar”) vai para o agentic retrieval do Azure AI Search, que a divide em subconsultas, executa-as em paralelo, reordena cada uma com o semantic ranker e junta os resultados. O planejamento de consultas e a síntese de respostas com LLM ainda estão em preview.

Uma pergunta global (“quais temas se repetem em todas as políticas de 2026?”) é onde o GraphRAG vale a pena.

21.3 Avaliação no Azure (Microsoft Foundry)

As notas vão de 1 a 5 e, por padrão, o limite de aprovação é 3. A avaliação contínua roda sobre amostras de tráfego real (porcentagem configurável, até 1000 requisições por hora) e envia os resultados para o Application Insights, vinculados aos traces.

Parte VIII · Comparação: Azure vs Google Cloud vs open source

22. Azure vs Google Cloud vs open source

Alguns produtos mudaram de nome recentemente (verificado em 2026-09-23):

• No Google, o Vertex AI agora aparece como Gemini Enterprise Agent Platform, o Vertex AI Search está sendo renomeado para Agent Search e o Vector Search 2.0 agora se chama Agent Retrieval.
• Na Microsoft, o Azure AI Foundry agora é Microsoft Foundry.

Fase 1: Preparando os documentos

Fase 2: Respondendo a uma pergunta

Fase 3: Geração e guardrails

Fase 4: Avaliação e monitoramento

Resumo em uma imagem

Três diferenças que importam

1. Busca híbrida: o Azure AI Search já inclui busca por palavras-chave. No Google Vector Search você mesmo precisa gerar o vetor esparso; se quiser que o Google cuide disso, use o Agent Search. Em open source, depende do banco.
2. Reranker: o do Azure reordena só os top 50. A Ranking API do Google aceita até 1000 chunks e funciona com qualquer buscador, até um externo. Em open source você controla o modelo, o custo e a latência, mas também precisa operá-lo.
3. Avaliação: as duas nuvens agora oferecem avaliação offline e avaliação contínua sobre tráfego real, com traces padronizados (OpenTelemetry). Em open source, RAGAS ou DeepEval (offline) mais Phoenix, MLflow ou Langfuse (produção) cobrem o mesmo terreno, mas a integração fica por sua conta.

Apêndice · Glossário

Apêndice · Referências

Documentação oficial (acessada em 2026-09-23)

Microsoft Azure

• Semantic ranker: https://learn.microsoft.com/en-us/azure/search/semantic-search-overview
• RRF na busca híbrida: https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
• Busca agêntica: https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview
• Document Layout skill: https://learn.microsoft.com/en-us/azure/search/cognitive-search-skill-document-intelligence-layout
• Chunking no Azure AI Search: https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-chunk-documents
• Avaliadores de RAG: https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators
• Avaliação contínua: https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/continuous-evaluation-agents

Google Cloud

• Ranking API: https://cloud.google.com/generative-ai-app-builder/docs/ranking
• Check Grounding: https://cloud.google.com/generative-ai-app-builder/docs/check-grounding
• Document AI Layout Parser: https://cloud.google.com/document-ai/docs/layout-parse-chunk
• RAG Engine: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/rag-overview
• Busca híbrida no Vector Search: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/vector-search/about-hybrid-search
• Embeddings de texto: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/embeddings/get-text-embeddings
• Online Monitors: https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-online

Elastic

• Busca semântica: https://www.elastic.co/docs/solutions/search/semantic-search
• Busca vetorial: https://www.elastic.co/docs/solutions/search/vector
• semantic_text: https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/semantic-text
• ELSER: https://www.elastic.co/docs/explore-analyze/machine-learning/nlp/ml-nlp-elser
• Retrievers: https://www.elastic.co/docs/reference/elasticsearch/rest-apis/retrievers

Artigos e relatórios

Recuperação

• Gao et al., RAG for LLMs: A Survey, 2023/24 — https://arxiv.org/abs/2312.10997
• Cormack, Clarke, Büttcher, Reciprocal Rank Fusion, SIGIR 2009 — https://dl.acm.org/doi/10.1145/1571941.1572114
• Formal et al., SPLADE, 2021 — https://arxiv.org/abs/2107.05720
• Chen et al., BGE-M3, 2024 — https://arxiv.org/abs/2402.03216
• Khattab & Zaharia, ColBERT, 2020 — https://arxiv.org/abs/2004.12832
• Faysse et al., ColPali, ICLR 2025 — https://arxiv.org/abs/2407.01449
• Gao et al., HyDE, 2022 — https://arxiv.org/abs/2212.10496
• Zheng et al., Step-Back Prompting, ICLR 2024 — https://arxiv.org/abs/2310.06117
• Sarthi et al., RAPTOR, 2024 — https://arxiv.org/abs/2401.18059
• Edge et al., GraphRAG, 2024 — https://arxiv.org/abs/2404.16130
• Microsoft Research, LazyGraphRAG, 2024 — https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
• Gutiérrez et al., HippoRAG 2, ICML 2025 — https://arxiv.org/abs/2502.14802
• Han et al., RAG vs. GraphRAG, 2025/26 — https://arxiv.org/abs/2502.11371
• Asai et al., Self-RAG, 2023 — https://arxiv.org/abs/2310.11511
• Yan et al., Corrective RAG, 2024 — https://arxiv.org/abs/2401.15884
• Jeong et al., Adaptive-RAG, NAACL 2024 — https://arxiv.org/abs/2403.14403
• Singh et al., Agentic RAG Survey, 2025/26 — https://arxiv.org/abs/2501.09136
• Jin et al., Search-R1, 2025 — https://arxiv.org/abs/2503.09516
• Liu et al., Lost in the Middle, TACL — https://arxiv.org/abs/2307.03172
• Li et al., Self-Route, EMNLP 2024 — https://arxiv.org/abs/2407.16833
• Li et al., LaRA, 2025 — https://arxiv.org/abs/2502.09977

Chunking

• Qu, Tu, Bao (Vectara), Is Semantic Chunking Worth the Computational Cost?, 2024 — https://arxiv.org/abs/2410.13070
• Smith & Troynikov (Chroma), Evaluating Chunking Strategies for Retrieval, 2024 — https://research.trychroma.com/evaluating-chunking
• NVIDIA, Finding the Best Chunking Strategy, 2025 — https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
• Jimeno Yepes et al., Financial Report Chunking, 2024 — https://arxiv.org/abs/2402.05131
• Günther et al. (Jina), Late Chunking, 2024 — https://arxiv.org/abs/2409.04701
• Anthropic, Contextual Retrieval, 2024 — https://www.anthropic.com/engineering/contextual-retrieval (números verificados por meio de um espelho; a página original bloqueou o acesso automatizado)
• Bhat et al., Rethinking Chunk Size, 2025 — https://arxiv.org/abs/2505.21700
• IBM, Docling, 2024 — https://arxiv.org/abs/2408.09869

Reranking

• Nogueira & Cho, monoBERT, 2019 — https://arxiv.org/abs/1901.04085
• Thakur et al., BEIR, 2021 — https://arxiv.org/abs/2104.08663
• Sun et al., RankGPT, 2023 — https://arxiv.org/abs/2304.09542
• Pradeep et al., RankZephyr, 2023 — https://arxiv.org/abs/2312.02724
• Su et al., BRIGHT, 2024 — https://arxiv.org/abs/2407.12883
• Abdallah et al., How Good are LLM-based Rerankers?, 2025 — https://arxiv.org/abs/2508.16757
• Agentset, Cohere Rerank 4, 2025 — https://agentset.ai/blog/cohere-reranker-v4
• Qwen, Qwen3 Embedding & Reranker, 2025 — https://qwenlm.github.io/blog/qwen3-embedding/
• Jina, jina-reranker-v3.5, 2026 — https://arxiv.org/abs/2607.18152
• Mixedbread, mxbai-rerank-v2, 2025 — https://www.mixedbread.com/blog/mxbai-rerank-v2
• Jiang et al., LongLLMLingua, ACL 2024 — https://arxiv.org/abs/2310.06839

Avaliação

• Es et al., RAGAS, 2023 — https://arxiv.org/abs/2309.15217
• Saad-Falcon et al., ARES, NAACL 2024 — https://arxiv.org/abs/2311.09476
• Ru et al. (Amazon), RAGChecker, NeurIPS 2024 — https://arxiv.org/abs/2408.08067
• Gao et al., ALCE, EMNLP 2023 — https://arxiv.org/abs/2305.14627
• Zheng et al., Judging LLM-as-a-Judge, NeurIPS 2023 — https://arxiv.org/abs/2306.05685
• Thakur et al., Support Evaluation TREC 2024, SIGIR 2025 — https://arxiv.org/abs/2504.15205
• Yang et al. (Meta), CRAG benchmark, NeurIPS 2024 — https://arxiv.org/abs/2406.04744
• Islam et al., FinanceBench, 2023 — https://arxiv.org/abs/2311.11944
• Magesh et al. (Stanford), Hallucination-Free?, 2024 — https://arxiv.org/abs/2405.20362
• Vectara, Hallucination Leaderboard — https://github.com/vectara/hallucination-leaderboard
• Bao et al., FaithBench, 2024 — https://arxiv.org/abs/2410.13210
• Vectara, Open RAG Eval — https://github.com/vectara/open-rag-eval
• DeepEval, Metrics — https://deepeval.com/docs/metrics-introduction
• Databricks, Scorers and LLM judges — https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/concepts/scorers