# RAG envia meus documentos para a IA? Entenda o caminho dos dados

Entenda quais dados um RAG envia para embeddings e geração, onde ficam documentos e logs e como verificar permissões, contexto e atualização das fontes.

Por Bruno Rana

Publicado em: 2026-10-22
Atualizado em: 2026-10-23

Artigo original: https://dev.buildrun.com.br/blog/rag-envia-documentos-para-ia/

**Em um RAG comum, o modelo que escreve a resposta recebe a pergunta e os trechos que a aplicação selecionou. Isso não exige enviar todos os documentos a cada pergunta.** Mas há uma segunda parte que merece atenção: antes da consulta, o texto pode ter passado por serviços de leitura, embeddings e armazenamento.

Imagine que você adicionou um manual a uma aplicação e perguntou como reiniciar um aparelho. Para entender o que foi enviado, precisamos acompanhar dois momentos: a preparação desse manual e a montagem da pergunta. Vamos separar os dois.

RAG significa geração aumentada por recuperação: a aplicação busca informação e a utiliza para apoiar a resposta. O nome descreve uma abordagem; não informa sozinho onde os dados ficam, quem pode acessá-los ou qual política de retenção se aplica.

Este artigo é para quem está começando a integrar IA a aplicações e quer compreender o caminho de um documento antes de escolher serviços. Os exemplos são conceituais, com dados fictícios.

## Documento, trecho, embedding e contexto são coisas diferentes

| Elemento | O que representa | Pergunta para inspecionar a aplicação |
| --- | --- | --- |
| Documento | Material de origem, como um manual. | Onde está o arquivo e quem consegue lê-lo? |
| Trecho | Parte extraída para processamento ou recuperação. | O corte preservou a condição necessária para entender o procedimento? |
| Embedding | Representação numérica produzida por um modelo. | Qual texto foi enviado para produzi-la e a qual serviço? |
| Metadados | Informações associadas, como origem, versão e escopo de acesso. | Quais campos são confiáveis e quem os define? |
| Contexto | Material efetivamente incluído na chamada de geração. | Quais trechos chegaram ao modelo junto da pergunta? |

Pense na busca como uma seleção de candidatos. Ela pode encontrar cinco trechos, e a aplicação decidir usar apenas dois. Esses dois entram no contexto enviado ao gerador. Por isso, olhar apenas a lista de resultados da busca ainda não mostra tudo o que o modelo recebeu.

## Primeiro caminho: ingestão dos documentos

### Leitura e extração

A aplicação lê o arquivo e obtém conteúdo utilizável. Um PDF pode exigir um leitor específico; uma imagem pode passar por extração de texto. Identifique se isso acontece no seu processo ou em outro serviço. O primeiro envio externo pode ocorrer antes de qualquer chamada ao modelo que responde perguntas.

A [documentação de ETL do Spring AI](https://docs.spring.io/spring-ai/reference/api/etl-pipeline.html) separa leitura, transformação e escrita de documentos. Essa divisão ajuda a localizar responsabilidades; não determina onde cada componente será hospedado.

### Divisão em trechos e embeddings

Ao dividir um manual, preserve informação suficiente para interpretar cada passagem. Um trecho com “pressione o botão” pode ficar incompleto se a condição “somente com o aparelho desligado” for separada dele. Não há um tamanho universal de trecho que dispense avaliar o seu material.

Em busca vetorial, um modelo transforma texto em vetores. Se o serviço de embeddings for remoto, o conteúdo enviado a ele cruza essa fronteira mesmo que o gerador de respostas rode localmente. Embeddings e geração podem usar fornecedores e configurações diferentes.

### Armazenamento

O índice pode guardar vetores, texto e metadados, conforme a implementação. Confira os campos reais em vez de presumir que só números são armazenados. Verifique também onde o documento original e as cópias de segurança permanecem.

A [referência de bancos vetoriais do Spring AI](https://docs.spring.io/spring-ai/reference/api/vectordbs.html) apresenta operações de armazenamento e busca por similaridade. Um banco vetorial não é, por si só, uma definição de privacidade nem uma garantia de isolamento entre usuários.

## Segundo caminho: da pergunta à resposta

### Recuperação

A aplicação recebe a pergunta e procura material pertinente. Na busca vetorial, isso normalmente envolve um embedding da consulta; logo, a própria pergunta também pode ser enviada ao provedor de embeddings. Recuperação lexical ou híbrida são outras possibilidades de implementação.

Um resultado semelhante é um candidato. Ainda é preciso considerar se ele pertence ao contexto do usuário, se está atualizado e se contém evidência suficiente. Um trecho sobre um aparelho parecido pode ter vocabulário semelhante e um procedimento diferente.

### Seleção e montagem do contexto

A aplicação escolhe quais resultados entram na chamada. No fluxo descrito pela [referência de RAG do Spring AI](https://docs.spring.io/spring-ai/reference/api/retrieval-augmented-generation.html), documentos recuperados são acrescentados à pergunta para fornecer contexto.

Vamos tornar isso visível. No nosso manual fictício, um trecho diz: “Para reiniciar o simulador, abra Configurações e escolha Reiniciar. Essa ação preserva as preferências”. Outro explica como apagar as preferências. A pergunta é apenas sobre reiniciar.

A chamada pode ser montada, conceitualmente, assim:

> **Pergunta:** Como reinicio o simulador sem perder minhas preferências?
>
> **Contexto selecionado:** Manual de demonstração, versão 2, seção Reinício — “Abra Configurações e escolha Reiniciar. Essa ação preserva as preferências”.
>
> **Orientação da aplicação:** Responda com base no contexto e informe quando ele não for suficiente.

Esse quadro é uma ilustração, não o formato obrigatório de uma API. Nessa chamada, o gerador recebeu texto legível. O embedding ajudou a encontrar o trecho; não substituiu esse texto na geração.

Ao conferir seu projeto, procure também instruções adicionais e histórico de conversa. Tudo isso ocupa a janela de contexto, que é o limite de material processado pelo modelo naquela chamada. Trazer mais trechos só ajuda se eles forem relevantes e couberem nos limites usados.

Para enxergar a ordem das decisões, podemos escrever o fluxo como pseudocódigo. Os nomes abaixo são operações conceituais da aplicação, não métodos de uma biblioteca:

```text
identidade = autenticar(requisicao)
escopo = obter_permissoes_no_servidor(identidade)
pergunta = requisicao.pergunta

# O serviço de embeddings pode receber a pergunta neste ponto.
candidatos = buscar_no_escopo(pergunta, escopo)
permitidos = conferir_permissao_e_versao(candidatos, escopo)
selecionados = escolher_trechos(permitidos, limite_do_contexto)

se selecionados estiver vazio:
    retornar "Não encontrei informação autorizada suficiente."

contexto = juntar_textos_e_fontes(selecionados)
# É aqui que os textos escolhidos seguem para o gerador.
resposta = gerar(pergunta, contexto)
retornar resposta
```

Se a busca encontrou cinco candidatos e apenas dois foram selecionados, são os textos desses dois que entram nessa chamada de geração. O escopo vem do servidor; não deve ser aceito apenas porque o cliente enviou um identificador. Esse desenho não implementa autenticação, controle de acesso ou proteção contra instruções maliciosas nos documentos. É um pseudocódigo para discutir o caminho dos dados, sem execução ou chamada a um provedor.

### Geração e apresentação

O gerador recebe o contexto montado e produz uma resposta. A aplicação pode apresentar referências para ajudar o leitor a conferir a origem. Para isso ser útil, o identificador exibido deve corresponder ao trecho usado, e a afirmação precisa ser sustentada por ele.

Ainda assim, vale abrir a fonte. Se um manual diz “desligue o aparelho antes de iniciar o procedimento” e a resposta pula essa condição, mostrar o link do manual não torna a orientação correta. A busca pode encontrar a passagem certa e a geração perder um detalhe necessário.

## Exemplo: rastrear uma pergunta sobre um manual fictício

Imagine um manual de demonstração com uma seção pública de reinício e uma seção de manutenção restrita. Uma pessoa pergunta como reiniciar o aparelho. O caminho conceitual é:

1. Na ingestão, o leitor extrai o texto e o divide em trechos com origem e versão.
2. O modelo de embeddings processa os trechos para a busca vetorial escolhida.
3. O armazenamento recebe os campos definidos pela aplicação.
4. Na consulta, a identidade da pessoa delimita quais informações podem participar da recuperação.
5. A aplicação seleciona os trechos permitidos e monta a chamada de geração.
6. A resposta é conferida contra esses trechos; logs e traces são inspecionados separadamente.

Para acompanhar esse fluxo no seu projeto, preencha uma tabela com destinos reais, sem dados sensíveis:

| Ponto de inspeção | Conteúdo a conferir | Destino que precisa ser identificado |
| --- | --- | --- |
| Extração | Arquivo original e texto extraído | Processo local ou serviço de leitura/OCR. |
| Embedding da ingestão | Texto de cada trecho | Modelo de embeddings. |
| Índice | Vetor, texto e metadados selecionados | Banco e backups. |
| Embedding da consulta | Pergunta do usuário | Modelo de embeddings da consulta. |
| Geração | Pergunta, instruções, histórico e contexto final | Modelo que escreve a resposta. |
| Observabilidade | Conteúdo registrado durante o fluxo | Logs, traces e ferramentas de diagnóstico. |

Preencha a última coluna com os componentes do seu projeto. Por exemplo: “extração no processo Java”, “embeddings no serviço contratado” e “índice no banco de teste”. Esses nomes são apenas possibilidades; substitua pelos destinos que você verificou. Se não sabe onde uma etapa roda, marque a dúvida. Ainda não dá para concluir que o dado ficou local.

## Permissões precisam valer antes do envio ao modelo

Um trecho relevante pode pertencer a outro cliente. A aplicação precisa verificar identidade e autorização antes de incluir esse conteúdo no contexto. Filtros por metadados podem fazer parte da solução, mas dependem de informações confiáveis e da aplicação correta das regras.

Não confie em um identificador de cliente fornecido livremente pela requisição como se ele provasse acesso. Em um exercício com duas identidades, tente consultar o mesmo assunto e confira os trechos efetivamente enviados. Verifique também caches e histórico: reutilizar uma resposta ou conversa de outro usuário pode reintroduzir conteúdo que a busca atual excluiu.

Suponha que o manual de manutenção seja restrito e a pessoa só tenha acesso ao manual de uso. Se o trecho de manutenção entrou na chamada, ele já foi enviado, mesmo que a resposta final não o mostre. Pedir ao modelo “não revele documentos privados” não corrige essa seleção. Confira primeiro o contexto e, depois, a resposta, usando dados fictícios.

## O que muda quando o documento é atualizado ou removido?

Alterar o arquivo original não demonstra que o índice já foi atualizado. No projeto, descubra como os trechos são identificados, substituídos e excluídos. Uma nova ingestão que apenas acrescenta entradas pode deixar versões antigas disponíveis para recuperação.

No manual fictício, acrescente uma orientação de espera: a versão 1 diz “aguarde 10 segundos”; a versão 2 diz “aguarde 20 segundos”. Atualize o documento e repita a pergunta. O contexto agora traz a versão 2? A passagem antiga ainda aparece entre os resultados?

Depois remova uma seção e tente encontrá-la novamente. Índice, respostas em cache e backups podem seguir processos diferentes de atualização ou remoção. Você precisa conhecer cada um para saber onde ainda existe uma cópia.

Se a resposta disser “20 segundos”, ainda olhe o contexto: o modelo pode ter recebido as duas versões. Encontrar esse conflito ajuda a corrigir a atualização do índice antes de depender da resposta.

## Modelo local, logs e retenção

Executar a geração localmente muda esse destino, mas extração, embeddings, armazenamento e observabilidade ainda podem ser remotos. O inverso também é possível: um banco local alimentando um modelo externo.

A [documentação de observabilidade do Spring AI](https://docs.spring.io/spring-ai/reference/observability/index.html) descreve opções de registro de prompts e respostas e alerta sobre exposição de conteúdo sensível. Confira a configuração da versão usada e as integrações adicionais. Para diagnosticar, prefira dados fictícios e registre apenas o necessário.

Retenção e uso para treinamento dependem do serviço, contrato e configuração. RAG não estabelece uma política universal. Uma avaliação precisa identificar os fornecedores e os produtos específicos envolvidos; executar uma etapa localmente não responde pelas demais.

## Dúvidas frequentes sobre o caminho dos dados

### RAG manda o PDF inteiro em toda pergunta?

Não é uma exigência da abordagem. A aplicação pode recuperar e enviar trechos selecionados. Mas uma implementação pode decidir incluir um documento completo, anexos ou outros conteúdos. Confirme a requisição real; não deduza o tamanho do envio apenas pelo nome RAG.

### Só enviar embeddings significa que o gerador não vê texto?

Não necessariamente. Em um fluxo textual comum, a busca usa vetores para localizar registros e a aplicação fornece o texto recuperado ao gerador. Verifique tanto a estrutura do índice quanto o contexto final. Também não trate um vetor como garantia automática de anonimização.

### RAG treina o modelo com meus documentos?

Inserir documentos no índice e recuperá-los como contexto não equivale, por si só, a alterar os pesos do modelo gerador. Fine-tuning envolve treinamento para ajustar o modelo. A [referência de conceitos do Spring AI](https://docs.spring.io/spring-ai/reference/concepts.html) diferencia essas abordagens. Essa distinção técnica não substitui a verificação das condições de uso de dados do provedor.

### RAG impede respostas inventadas?

Não. Uma resposta pode interpretar mal a fonte ou afirmar algo sem apoio suficiente. Teste perguntas com e sem evidência, confira as fontes e defina como a aplicação deve comunicar insuficiência de informação. Uma instrução ao modelo deve ser acompanhada de avaliação do comportamento observado.

## Exercício: testar acesso, evidência e atualização

Use apenas o manual fictício e identidades de teste. Não registre documentos reais para começar este diagnóstico.

| Cenário | Critério de verificação |
| --- | --- |
| Pergunta respondida pela seção pública | Contexto contém o trecho pertinente; resposta preserva suas condições. |
| Pergunta sem resposta no manual | Aplicação comunica insuficiência de evidência conforme o contrato definido. |
| Seção restrita, identidade sem acesso | Trecho restrito não entra no contexto; resposta não reutiliza cache de outra identidade. |
| Mesmo assunto, identidade autorizada | Apenas material permitido participa do contexto. |
| Procedimento atualizado | Trechos enviados correspondem à versão vigente. |
| Seção removida | Índice e contexto deixam de oferecer o trecho conforme o fluxo de exclusão definido. |

Anote o que você esperava e o que aconteceu. Se o trecho certo nem chegou à chamada, comece pela leitura, divisão, índice e busca. Se ele chegou e a resposta mudou a orientação, olhe a geração. Você passa a investigar uma etapa por vez, em vez de trocar componentes sem saber onde está o problema.

Use o ensaio para localizar por onde os dados passaram e revisar esses destinos antes de trabalhar com informação real.

## Checklist e próximo passo com a formação

* Identifiquei o conteúdo enviado para extração, embeddings e geração.
* Sei onde ficam arquivos, índice, logs, caches e backups.
* Testei autorização antes da montagem do contexto.
* Consigo relacionar a resposta ao trecho e à versão utilizados.
* Verifiquei ausência de evidência, atualização e remoção.
* Conferi retenção e uso de dados nos serviços e contratos efetivos.

As referências oficiais do Spring AI citadas foram consultadas em 22/10/2026. A documentação consultada se identifica como Spring AI 2.0.1; o artigo descreve conceitos e exercícios, sem prescrever uma configuração executável dessa versão.

Se você quer estudar IA junto às decisões de uma aplicação, consulte os [conteúdos da Formação Build & Run](https://dev.buildrun.com.br/blog/formacao-buildrun/). Leve a tabela de destinos como referência: ela ajuda a formular perguntas melhores sobre qualquer projeto.

## Para levar à prática

Acompanhe o documento desde a extração até o contexto entregue ao gerador. Permissões, versões, embeddings, logs e condições do provedor fazem parte dessa análise; uma resposta com citação ainda precisa ser conferida na fonte.