RAG na Prática com RAGFlow: Assistentes Corporativos que Citam a Fonte

Colocar um assistente corporativo em produção raramente falha por falta de um bom modelo de linguagem. Falha na recuperação: o LLM responde com confiança sobre o documento errado, ignora a versão vigente de uma política ou inventa um número que não existe em nenhuma planilha. É por isso que Retrieval-Augmented Generation (RAG) deixou de ser um experimento e passou a ser padrão de arquitetura para IA aplicada a conhecimento proprietário.

Este artigo é um guia prático de RAG usando o RAGFlow como plataforma de referência: o que ele resolve, como estruturar a ingestão de documentos reais (PDFs escaneados, contratos, planilhas, tickets), como avaliar a qualidade da recuperação com métricas e o que muda quando o piloto vira sistema de produção com governança, custo e SLA.

Por que RAG e não fine-tuning

A pergunta aparece em toda avaliação técnica: se o modelo não sabe algo, por que não treiná-lo? Porque os dois mecanismos resolvem problemas diferentes.

• Fine-tuning ensina comportamento — formato de saída, tom, estilo de classificação, aderência a um esquema. É bom para "como responder".
• RAG fornece fatos — a cláusula específica do contrato, o preço vigente, o procedimento atualizado ontem. É bom para "com base em quê responder".

Em ambiente corporativo, RAG ganha por três razões operacionais: o conhecimento muda toda semana (retreinar não escala), a resposta precisa ser rastreável até a fonte (auditoria, LGPD, compliance) e o controle de acesso precisa valer no momento da consulta — um usuário não pode recuperar um documento que não teria permissão de abrir. Nada disso se resolve com pesos de modelo.

Anatomia de um pipeline RAG

Um sistema RAG tem duas metades que costumam ser confundidas: uma roda offline (indexação) e a outra online (consulta). Tratar as duas com o mesmo rigor é o que separa um protótipo de um produto.

1. Ingestão e parsing

A qualidade final é limitada pelo parsing. Um PDF de 200 páginas com tabelas financeiras extraído como texto corrido destrói a relação linha-coluna e produz respostas numéricas erradas — o modelo não tem culpa, o dado chegou quebrado. Na prática você precisa de: OCR para documentos escaneados, reconhecimento de layout para separar cabeçalho, corpo, tabela e rodapé, e extração de tabelas preservando estrutura.

2. Chunking

Dividir o documento é a decisão de projeto mais subestimada. Chunks pequenos recuperam com precisão mas perdem contexto; grandes trazem ruído e encarecem o prompt. O que funciona:

• Chunking estrutural: respeitar títulos, seções e cláusulas em vez de cortar a cada N caracteres.
• Sobreposição controlada: 10–15% de overlap evita cortar uma frase no meio de uma definição.
• Enriquecimento de contexto: prefixar cada chunk com o caminho hierárquico ("Política de Crédito > Capítulo 4 > Limites") melhora sensivelmente a recuperação.
• Metadados desde a ingestão: versão, data de vigência, área, nível de sigilo. Sem isso não existe filtro nem governança depois.

3. Embeddings e índice

Cada chunk vira um vetor. A escolha do modelo de embedding e do vector database define latência, custo de reindexação e capacidade de filtro — tratamos esses critérios em detalhe no guia de infraestrutura para RAG: vector databases, modelos e frameworks. Para português, sempre valide modelos multilíngues com seus documentos: benchmarks em inglês não transferem automaticamente.

4. Recuperação

Busca vetorial pura falha justamente onde o negócio dói: códigos de produto, números de contrato, siglas internas. A configuração robusta é busca híbrida — vetorial (semântica) combinada com léxica (BM25) — e fusão dos rankings por Reciprocal Rank Fusion. Depois, um reranker (cross-encoder) reordena os 20–50 melhores candidatos e você envia apenas os 3–8 mais relevantes ao LLM. Esse estágio costuma dar o maior ganho de precisão por real investido.

5. Geração com citação obrigatória

O prompt deve exigir que a resposta se baseie exclusivamente no contexto recuperado, cite a fonte e diga explicitamente "não encontrei" quando o contexto não sustentar a resposta. Um assistente que admite não saber vale mais, em ambiente corporativo, do que um que sempre responde.

Onde o RAGFlow entra

O RAGFlow é um motor de RAG open source cuja principal contribuição está na etapa que mais quebra projetos: a compreensão profunda de documentos. Em vez de tratar todo arquivo como texto plano, ele aplica reconhecimento de layout e modelos de parsing por tipo de documento, o que muda o resultado em três frentes.

• Templates de chunking por tipo de arquivo: manual, artigo, apresentação, planilha, currículo, tabela. Cada um com estratégia própria de segmentação, em vez de um cortador genérico.
• Chunking auditável: a interface mostra os chunks gerados, permite corrigir manualmente e mostra de qual região da página cada trecho veio. Isso encurta drasticamente o ciclo de depuração — você vê que a resposta errada nasceu de um chunk mal cortado, não adivinha.
• Citação com rastreabilidade visual: a resposta aponta o trecho exato do documento original, o que viabiliza revisão humana e aceitação por áreas de risco e jurídico.

Além disso, entrega o que se espera de uma plataforma: múltiplas bases de conhecimento isoladas, busca híbrida com reranking, API para integração em produtos existentes e orquestração de fluxos com agentes. O ponto importante é o critério de escolha: o RAGFlow brilha quando o gargalo é documento complexo (PDF escaneado, tabela, formulário). Quando os dados já estão limpos e estruturados, um pipeline próprio sobre pgvector pode ser mais simples e barato de manter.

Do piloto à produção: o que realmente decide

Pilotos de RAG impressionam em duas semanas e travam no terceiro mês. Os pontos que determinam o desfecho:

Avaliação com métricas, não com "achei bom"

Monte um conjunto de 100–300 perguntas reais com resposta e fonte esperadas — construído junto com quem usa o sistema. Meça separadamente:

• Recall@k e MRR na recuperação: o trecho correto está entre os k recuperados, e em que posição?
• Fidelidade (groundedness): cada afirmação da resposta é sustentada pelo contexto?
• Precisão de citação: a fonte apontada é mesmo a que contém a informação?
• Taxa de abstenção correta: quando não há resposta na base, o sistema recusa?

Separar recuperação de geração é essencial para diagnóstico: se o recall é baixo, trocar o LLM não resolve nada.

Permissões avaliadas no momento da consulta

Filtragem por metadados de acesso precisa acontecer antes do reranking, no próprio índice. Filtrar depois é vazamento de dados esperando acontecer.

Atualização e ciclo de vida do índice

Documento revisado exige reindexação incremental e remoção da versão anterior — caso contrário o assistente cita política revogada. Vale versionar o índice e manter o modelo de embedding fixo por versão: trocar o modelo obriga a reindexar tudo.

Custo e latência sob controle

Cache de perguntas frequentes, limite de chunks no prompt, modelo menor para reformulação de consulta e modelo maior só na síntese final. Boa parte do custo em RAG vem de enviar contexto irrelevante — que é exatamente o que o reranker elimina.

Observabilidade

Registre consulta, chunks recuperados, scores, prompt final, resposta e feedback do usuário. Sem esse rastro não há como melhorar o sistema nem responder a uma auditoria. É o mesmo princípio de MLOps aplicado a RAG.

Erros mais comuns (e como evitá-los)

• Ignorar o parsing: investir em LLM de ponta e ingerir PDF quebrado. Comece pelo documento.
• Só busca vetorial: sem BM25, consultas com códigos e siglas falham silenciosamente.
• Não usar reranker: é o ganho mais rápido de qualidade em quase todo pipeline.
• Enviar contexto demais: mais chunks não é mais qualidade; é mais custo e mais ruído.
• Não ter baseline de avaliação: sem métrica, cada ajuste é opinião.
• Tratar RAG como projeto de uma entrega: é sistema vivo — conhecimento muda, o índice acompanha.

Quando RAG multimodal faz sentido

Se a informação crítica está em diagramas, fotos de inspeção, plantas ou frames de vídeo, texto sozinho não resolve. A extensão do pipeline para múltiplas modalidades — embeddings unificados, chunking de conteúdo visual e trade-offs de custo — está detalhada no nosso guia completo de RAG multimodal e vetorização.

Perguntas frequentes

Quanto tempo leva para colocar um assistente RAG em produção?

Um piloto com escopo fechado e base de conhecimento delimitada costuma ir ao ar em 4 a 6 semanas, incluindo conjunto de avaliação. O prazo se estende quando o acervo exige OCR pesado ou quando as regras de acesso são muito granulares.

RAGFlow ou pipeline próprio?

RAGFlow quando o desafio é documento complexo e você quer inspecionar e corrigir chunks rapidamente. Pipeline próprio (por exemplo Postgres com pgvector) quando os dados já são estruturados, o volume é moderado e você prioriza simplicidade operacional.

Como reduzir alucinação?

Melhorando a recuperação (híbrida + reranking), exigindo citação, instruindo abstenção explícita e medindo fidelidade de forma contínua. Alucinação em RAG é, na maioria dos casos, sintoma de recuperação ruim.

Os dados saem da empresa?

Não necessariamente. Índice e documentos podem ficar na infraestrutura da própria empresa, e a geração pode usar modelos hospedados no seu ambiente ou provedores com acordo de não-retenção. É uma decisão de arquitetura definida no início do projeto.