O RAG hierárquico, comumente implementado por meio da técnica de Parent Document Retrieval, é uma arquitetura avançada de geração aumentada por recuperação projetada para superar o dilema clássico de fragmentação de contexto em bases documentais extensas e formalmente estruturadas. Em sistemas tradicionais de RAG, o desenvolvedor é obrigado a escolher entre chunks pequenos (que geram vetores de embedding muito precisos para busca, mas perdem a visão global do tema) ou chunks grandes (que preservam o contexto narrativo, mas diluem os termos de busca gerando similaridade vetorial imprecisa).
No universo jurídico e regulatório brasileiro, códigos de leis, decretos executivos, resoluções normativas e contratos comerciais complexos apresentam uma hierarquia rígida composta por livros, títulos, capítulos, artigos, parágrafos, incisos e alíneas. Ao aplicar o Parent Document Retrieval, o pipeline segmenta os textos em pequenos fragmentos filhos (sub-chunks) de 100 a 200 caracteres para indexação vetorial, mas recupera o artigo pai completo (de 1.000 a 3.000 caracteres) para alimentar a janela de contexto do modelo de linguagem, garantindo respostas juridicamente impecáveis e livres de alucinações.
Resumo rápido
- O Parent Document Retrieval separa a unidade de busca vetorial (fragmento filho) da unidade de contexto fornecida ao LLM (documento pai).
- A técnica resolve o problema de incisos e alíneas isolados que perdem a regra do caput do artigo correspondente.
- Sistemas jurídicos conseguem encontrar termos pontuais em leis extensas mantendo a integridade hermenêutica do dispositivo legal.
- Bancos vetoriais modernos como Qdrant e Milvus integram perfeitamente esse padrão por meio de metadados relacionais e IDs de parentesco.
- A taxa de alucinação em auditorias de contratos corporativos cai substancialmente em comparação a estratégias de chunking linear ingênuo.
O problema do chunking linear ingênuo em textos jurídicos
Em tutoriais básicos de inteligência artificial, o fatiamento de documentos costuma ser ensinado com divisões fixas por contagem de caracteres (por exemplo, blocos de 500 caracteres com sobreposição de 50 caracteres). Quando essa técnica ingênua é aplicada à Consolidação das Leis do Trabalho ou ao Código Civil, ocorrem desastres interpretativos: um inciso que determina uma exceção à regra geral acaba separado do caput que definia o sujeito da obrigação.
Se o modelo de linguagem recebe apenas o fragmento que descreve a penalidade sem o artigo que delimitava a hipótese de incidência, a inteligência artificial inventa conexões falsas, gerando pareceres equivocados que induzem advogados e analistas de conformidade ao erro. Para compreender os fundamentos de embeddings e bancos vetoriais, veja nosso guia prático de RAG e bancos vetoriais e aprenda como estruturar coleções no tutorial de base de conhecimento com Supabase e pgvector.
Como funciona o Parent Document Retrieval
O princípio operacional do RAG hierárquico estrutura-se em um mapeamento relacional entre duas camadas de granularidade textual:
- Camada Pai (Parent Documents): representa a unidade semântica coesa, como um artigo completo de uma lei (incluindo caput, todos os parágrafos e incisos vinculados) ou uma cláusula contratual inteira com seus anexos de penalidades.
- Camada Filha (Child Chunks): fragmentos reduzidos derivados do texto pai, gerados para maximizar a similaridade semântica com perguntas pontuais do usuário (como uma pergunta específica sobre uma alínea de isenção).
- Armazenamento desacoplado: os vetores dos fragmentos filhos são gravados no banco vetorial indexados por um identificador que aponta para o ID do documento pai. O documento pai integral pode ficar armazenado no mesmo banco (em payload) ou em um banco chave-valor rápido como Redis.
Quando o usuário pesquisa: “Qual é a tolerância diária para batida de ponto sem desconto salarial?”, o sistema localiza o fragmento filho referente ao parágrafo 1º do artigo 58 da CLT. Porém, em vez de passar apenas aquela frase solta ao modelo, a esteira busca o artigo 58 inteiro e o injeta no prompt do LLM. O modelo lê a regra geral e a exceção de forma harmoniosa.
Comparativo: RAG Tradicional versus RAG Hierárquico
A tabela comparativa a seguir destaca as diferenças conceituais e operacionais entre o fatiamento simples e a recuperação hierárquica:
| Aspecto Arquitetural | RAG Tradicional (Chunking Linear) | RAG Hierárquico (Parent Document) |
|---|---|---|
| Granularidade de indexação | Chunks médios (ex.: 600 a 1000 caracteres) | Micro-chunks filhos (100 a 250 caracteres) |
| Contexto entregue ao LLM | Apenas o bloco recuperado na busca | O artigo pai completo ou cláusula inteira |
| Precisão da busca vetorial | Média (termos pontuais diluem-se no bloco) | Altíssima (foco estrito no conceito pesquisado) |
| Preservação de caput e incisos | Frequentemente rompidos entre blocos vizinhos | Sempre preservados na íntegra no documento pai |
| Complexidade de implementação | Baixa (apenas um divisor de texto padrão) | Média (exige controle de IDs pai-filho) |
Implementação prática com LangChain e LlamaIndex
Frameworks modernos de orquestração de inteligência artificial oferecem classes nativas para implementar o padrão sem a necessidade de construir gerenciadores de relacionamento manuais. No LangChain, utiliza-se a classe `ParentDocumentRetriever` em conjunto com um divisor de texto hierárquico:
from langchain.retrievers import ParentDocumentRetriever
from langchain.storage import InMemoryStore
from langchain_community.vectorstores import Qdrant
from langchain_text_splitters import RecursiveCharacterTextSplitter
parent_splitter = RecursiveCharacterTextSplitter(chunk_size=2000, chunk_overlap=0)
child_splitter = RecursiveCharacterTextSplitter(chunk_size=250, chunk_overlap=30)
store = InMemoryStore()
retriever = ParentDocumentRetriever(
vectorstore=vectorstore,
docstore=store,
child_splitter=child_splitter,
parent_splitter=parent_splitter,
)
Essa arquitetura permite que documentos regulatórios de centenas de páginas sejam ingeridos preservando a hierarquia natural do texto normativo. Para entender melhor como os modelos processam grandes volumes de informação, veja nosso artigo sobre janela de contexto e capacidade de leitura de LLMs e aprofunde o estudo sobre o que são embeddings e como funcionam.
Busca híbrida combinada: densa e esparsa com BM25
No domínio do Direito brasileiro, a busca vetorial puramente semântica (baseada em distâncias euclidianas ou cosseno) pode apresentar falhas quando a dúvida do usuário envolve termos estritamente literais ou identificadores numéricos, como números de leis, súmulas vinculantes ou artigos específicos (por exemplo, “artigo 7º, inciso XXIX da Constituição Federal”).
Para contornar essa deficiência, as implementações mais maduras de RAG hierárquico combinam o Parent Document Retrieval com busca híbrida. Nessa abordagem, um índice esparso baseado no algoritmo BM25 localiza palavras-chave exatas nos fragmentos filhos, enquanto o modelo denso de embeddings captura a intenção conceitual subjacente. Uma etapa de Reciprocal Rank Fusion (RRF) funde as duas listas ranqueadas e recupera os documentos pais correspondentes. Esse arranjo híbrido garante que termos técnicos processuais e números de súmulas sejam localizados com precisão cirúrgica antes de entregar o contexto completo ao modelo de linguagem.
Exemplo: busca em códigos tributários municipais em Porto Alegre
Um escritório de consultoria tributária com sede em Porto Alegre precisava criar um assistente interno para responder a dúvidas de clientes sobre o Código Tributário Municipal (CTM) e as leis complementares do ISSQN (Imposto Sobre Serviços de Qualquer Natureza). Na primeira versão do sistema, implementada com fatiamento linear tradicional de 500 caracteres, o assistente confundia com frequência alíquotas fixas com alíquotas proporcionais de sociedades uniprofissionais de médicos e advogados.
A equipe técnica reconstruiu o pipeline utilizando Parent Document Retrieval no Qdrant. Cada artigo de lei municipal foi tratado como um documento pai, enquanto os parágrafos e alíneas foram convertidos em microfragmentos de busca. Quando um consultor perguntou se sociedades de engenharia poderiam optar pelo recolhimento de ISS em cota fixa por profissional habilitado, o sistema encontrou o sub-chunk exato da exceção e recuperou o artigo inteiro contendo as condicionantes cadastrais e vedações de enquadramento.
O assistente gerou uma resposta fundamentada citando o número do artigo, transcrevendo o caput e alertando sobre as exigências de registro na prefeitura de Porto Alegre. A assertividade das respostas alcançou 98%, eliminando riscos de pareceres inconsistentes encaminhados a contribuintes.
Erros comuns
- Definir documentos pais extensos demais: criar pais com mais de 8.000 caracteres pode estourar o orçamento de tokens do prompt quando múltiplos artigos são recuperados simultaneamente.
- Não persistir o docstore em disco: armazenar os documentos pais apenas na memória volátil (`InMemoryStore`) causa perda de dados quando o serviço é reiniciado.
- Usar separadores de texto que ignoram quebras de artigo: fatiar leis por contagem pura de caracteres em vez de expressões regulares que identificam “Art.” e “Parágrafo único” quebra a coerência normativa.
- Desconsiderar metadados de vigência e revogação: não etiquetar artigos revogados ou alterados por legislações posteriores faz a IA citar regras caducas como válidas.
- Omitir técnicas de re-ranking: deixar de aplicar um modelo de re-classificação após a recuperação dos documentos pais pode trazer artigos correlatos que não respondem à pergunta central.
Perguntas frequentes
Qual é a diferença entre RAG hierárquico e busca por janela de contexto (Sentence Window)?
A busca por Sentence Window recupera um número fixo de sentenças adjacentes ao redor da frase encontrada. Já o Parent Document Retrieval recupera a unidade lógica e semântica inteira definida pelo desenvolvedor (como o artigo de lei completo), independentemente do número de linhas.
O Parent Document Retrieval aumenta o custo de armazenamento no banco vetorial?
O aumento de custo de vetores é mínimo, pois apenas os pequenos fragmentos filhos geram embeddings. Os documentos pais são armazenados em texto puro em tabelas de metadados ou bancos relacionais de baixo custo.
A técnica funciona para contratos comerciais privados em PDF?
Sim. O padrão é especialmente eficiente para minutas contratuais, fatiando cláusulas inteiras como pais e parágrafos de penalidades e prazos como fragmentos filhos de busca.
É necessário um modelo de embeddings específico para usar RAG hierárquico?
Não. Modelos de embedding textuais modernos como OpenAI text-embedding-3, Voyage ou modelos abertos como BGE operam perfeitamente com a técnica.
Quantos documentos pais devem ser injetados no contexto final do LLM?
Recomenda-se configurar o recuperador para retornar entre 3 e 5 documentos pais mais relevantes, garantindo densidade informativa sem sobrecarregar o modelo com ruído.
Como garantir que artigos revogados não sejam apresentados como vigentes?
Aplica-se filtragem prévia por metadados no banco vetorial (payload filtering) com campos como `status: “vigente”`, descartando normas revogadas antes do cálculo de similaridade.
