RAG sobre Documentação Técnica e Regulatória: Respostas com Citação, Não Alucinação | Blog

# RAG sobre Documentação Técnica e Regulatória: Respostas com Citação, Não Alucinação

TL;DR: Um sistema de RAG (retrieval augmented generation) bem construído para documentação técnica e regulatória não é "ligar um chatbot aos PDFs" — é uma cadeia de decisões de engenharia (chunking, embeddings, pesquisa híbrida, reranking) que termina, obrigatoriamente, numa citação verificável da fonte; sem essa última peça, está apenas a automatizar a alucinação com mais confiança.

O problema real

Uma operadora com um manual de integridade de pipelines em inglês, um dossier de conformidade ANPG em português, e um conjunto de normas HSE traduzidas por terceiros tem, na prática, três problemas sobrepostos: os documentos estão em formatos diferentes (PDF digitalizado, Word, folhas de cálculo com tabelas técnicas), estão em duas línguas, e ninguém tem tempo de os ler todos antes de responder a uma pergunta como "qual é o binário de aperto recomendado para esta flange, segundo o manual do fabricante?" ou "que documentos são exigidos pela ANPG para a certificação de um subcontratado de perfuração?".

A tentação é colar os documentos todos num modelo de linguagem e pedir para responder. Isto funciona mal por duas razões estruturais. Primeiro, a maioria dos corpora documentais de uma operadora ou EPC excede em muito a janela de contexto que é prático (e barato) enviar em cada pedido. Segundo — e este é o ponto que mais preocupa equipas de engenharia e compliance — um modelo de linguagem sem acesso aos documentos reais tende a preencher lacunas com texto plausível mas inventado. Em documentação regulatória, uma resposta plausível mas errada sobre um prazo fiscal ou um requisito de certificação não é um erro cosmético; é um risco de conformidade com custo real.

RAG (retrieval augmented generation, ou "geração aumentada por recuperação") é a arquitectura que resolve isto separando duas coisas que os modelos de linguagem tendem a confundir: memorizar factos e raciocinar sobre texto. Em vez de pedir ao modelo para "saber" o conteúdo do manual, o sistema primeiro recupera os excertos relevantes de uma base documental controlada, e só depois pede ao modelo para raciocinar sobre esses excertos concretos — e a citar exactamente de onde veio cada afirmação. A investigação académica sobre este tema mostra de forma consistente que ancorar a geração em documentos recuperados reduz significativamente a taxa de alucinação e melhora a fidelidade factual das respostas face a perguntas sobre conhecimento específico de domínio, precisamente porque o modelo deixa de ter de "adivinhar" e passa a ter de "citar" [Yao et al., arXiv 2503.10677]. Esse desvio — de "o modelo sabe" para "o modelo mostra onde leu" — é a diferença entre uma ferramenta útil e um gerador de responsabilidade civil.

A mecânica real, passo a passo

1. Chunking — dividir sem destruir o significado

Um documento técnico não pode ser indexado inteiro (é demasiado grande para pesquisa eficiente) nem cortado às cegas de 500 em 500 caracteres (corta uma tabela de especificações ao meio, ou separa uma cláusula do seu número de artigo). Chunking é o processo de dividir cada documento em segmentos ("chunks") pesquisáveis de forma independente.

Na prática de engenharia, o ponto de partida mais comum para documentos técnicos em prosa é um chunk de 400 a 512 tokens (aproximadamente 300 a 400 palavras), com uma sobreposição ("overlap") de 10% a 20% entre chunks consecutivos para não perder contexto que atravesse uma fronteira de corte. Para documentos com uma estrutura clara — manuais com secções e subsecções numeradas, normas com artigos e alíneas, como é o caso da generalidade da documentação regulatória angolana — o corte deve respeitar essas fronteiras estruturais (secção, artigo, tabela) em vez de um número fixo de caracteres; nesses casos, a sobreposição necessária tende a ser menor, na ordem dos 5% a 10%, porque a própria estrutura do documento já preserva o contexto [Databricks Engineering Blog, "The Ultimate Guide to Chunking Strategies for RAG Applications"]. Uma tabela de especificações técnicas ou um quadro de tarifas fiscais deve, sempre que possível, ser mantido como uma unidade indivisível — parti-lo a meio é uma das causas mais comuns de respostas erradas em sistemas de RAG mal desenhados para conteúdo técnico.

2. Embeddings — transformar texto em coordenadas de significado

Cada chunk é convertido num vector numérico (um "embedding") por um modelo de embeddings, de forma que chunks com significado semelhante fiquem próximos nesse espaço vectorial, independentemente de usarem as mesmas palavras. É isto que permite que uma pergunta como "o que fazer se um trabalhador não usar EPI" encontre um chunk que fala em "incumprimento do uso de equipamento de protecção individual", mesmo sem sobreposição literal de palavras.

Para um contexto bilingue português/inglês — que é o caso real de qualquer operadora ou EPC a trabalhar em Angola, com manuais de fabricantes internacionais em inglês e documentação regulatória e contratual em português — a escolha do modelo de embeddings importa mais do que em ambientes monolingues. Modelos multilingues como o embed-multilingual-v3.0 da Cohere, treinados para cobrir mais de 100 línguas, colocam frases equivalentes em português e inglês próximas no mesmo espaço vectorial, o que permite pesquisar em português e recuperar um excerto que só existe em inglês no manual original — sem tradução manual prévia de todo o corpus [Cohere Documentation, "Cohere's Embed Models"].

3. Pesquisa híbrida — vector e palavra-chave, não um ou outro

Aqui está o erro mais comum em implementações de RAG feitas às pressas: usar apenas pesquisa vectorial (semântica). A pesquisa vectorial é excelente a encontrar significado, mas é sistematicamente má a encontrar coisas exactas — um número de norma ("ISO 14224"), uma referência de artigo de lei ("Decreto Presidencial n.º 271/20"), um código de peça, um número de factura. Para esses casos, a pesquisa por palavra-chave clássica (o algoritmo BM25, usado há décadas em motores de pesquisa) continua a ser mais fiável do que qualquer embedding.

A solução de engenharia, hoje standard, é correr as duas pesquisas em paralelo — vectorial e por palavra-chave — sobre a mesma base documental, e depois fundir os dois conjuntos de resultados com um algoritmo de fusão de ranking, tipicamente Reciprocal Rank Fusion (RRF), que combina a posição de cada resultado nas duas listas num único ranking final [Microsoft Learn, "Hybrid Search Scoring (RRF) — Azure AI Search"]. Isto não é exclusivo de um fornecedor: a mesma abordagem híbrida BM25 + vector + RRF está disponível tanto em motores de pesquisa dedicados (Azure AI Search, Elasticsearch) como directamente dentro de uma base de dados Postgres através da extensão pgvector, combinada com o motor de full-text search nativo do Postgres — uma opção especialmente relevante para operadoras cuja stack já assenta em Postgres, evitando introduzir uma base de dados vectorial separada só para este efeito [ParadeDB, "Hybrid Search in PostgreSQL: The Missing Manual"; documentação pgvector].

4. Reranking — a segunda passagem que separa "relevante" de "correcto"

Uma pesquisa híbrida costuma ser configurada para devolver algumas dezenas de candidatos plausíveis — 20 a 50 é uma ordem de grandeza comum, não uma regra. Nem todos são igualmente úteis — e enviar 50 chunks para o modelo de linguagem é caro, lento, e dilui o sinal certo no meio de ruído. O reranking é uma segunda passagem, feita por um modelo especializado (mais pequeno e mais barato do que o modelo de geração final), que reordena esses candidatos por relevância real face à pergunta exacta do utilizador, olhando para a pergunta e cada candidato em conjunto — algo que os algoritmos de pesquisa da primeira passagem não fazem de forma tão fina.

Modelos como o Cohere Rerank suportam mais de 100 línguas e atingem desempenho equivalente em português face a outras línguas de negócio [Cohere Documentation, "An Overview of Cohere's Models"], o que é relevante precisamente porque, num corpus bilingue, a pergunta pode chegar em português e o chunk mais relevante estar em inglês (ou vice-versa) — o reranker tem de avaliar essa correspondência sem se deixar enganar pela diferença de língua.

5. Obrigar citação da fonte — o ponto que separa uma ferramenta séria de um brinquedo

Isto é o coração de tudo o resto. Depois de reranking, o modelo de geração recebe apenas os 3 a 8 chunks mais relevantes — e a instrução explícita de que cada afirmação factual na resposta tem de vir acompanhada da referência exacta ao documento e à secção de onde foi retirada, e de que, se a resposta não estiver suportada por nenhum chunk recuperado, o sistema deve dizer que não encontrou a informação em vez de a inventar.

Na prática de engenharia isto implica três coisas concretas: (1) cada chunk armazenado transporta metadados de proveniência — nome do documento, versão, número de secção ou artigo, número de página; (2) o prompt do modelo de geração é construído de forma a que a citação seja uma exigência estrutural da resposta (por exemplo, forçando um formato de saída onde cada frase tem um identificador de fonte associado), não uma sugestão; (3) existe uma camada de validação depois da geração que confirma que cada citação apontada pelo modelo corresponde de facto a um chunk que lhe foi fornecido — impedindo o caso, observado em sistemas mal implementados, em que o modelo "cita" um documento real mas com um número de secção inventado. A literatura de investigação chama a isto "citação fundamentada" (grounded citation), e mostra que forçar a geração a estar ancorada a uma citação verificável, gerada em simultâneo com a resposta e não como um adorno posterior, reduz de forma consistente a proporção de afirmações não suportadas pelos documentos-fonte [arXiv 2507.18910, "A Systematic Review of Key Retrieval-Augmented Generation (RAG) Systems"]. Sem esta camada, um sistema de RAG é apenas um chatbot com uma pesquisa a montante — continua a poder alucinar, só que agora com uma aparência de rigor que engana mais facilmente um leitor apressado.

O caso multilingue português/inglês: o cenário real angolano

Qualquer operadora, EPC ou empresa de serviços petrolíferos a operar em Angola vive este problema todos os dias, mesmo sem lhe chamar "multilingue": os manuais de equipamento vêm do fabricante em inglês (frequentemente também em francês ou chinês, no caso de fornecedores asiáticos), os relatórios internos e a correspondência com reguladores locais são em português, e a documentação de conformidade tem de referenciar simultaneamente normas técnicas internacionais (API, ISO, NFPA) e enquadramento legal angolano.

Dois exemplos concretos do tipo de documentação regulatória que hoje exige este tratamento em Angola:

[Facturação electrónica](https://wise-hustlers.com/blog/facturacao-electronica-angola-2026-erp-petroleo-gas) e SAF-T (AO): o Decreto Presidencial n.º 71/25, de 20 de Março, torna obrigatória a emissão e comunicação de facturas electrónicas a partir de 1 de Janeiro de 2026 para grandes contribuintes e empresas que facturam a entidades do Estado, e a partir de 1 de Janeiro de 2027 para os restantes contribuintes dos regimes Geral e Simplificado; a submissão do ficheiro SAF-T (AO) relativo à contabilidade está prevista para 2026, com dados referentes a 2025, e o software de facturação passa a ter de estar certificado ou validado pela Administração Geral Tributária (AGT) [EY Angola, "Facturação Electrónica a partir de 1 de Janeiro de 2026"; Angola24Horas]. Uma equipa de finanças ou de TI que precise de saber, rapidamente, se um determinado tipo de operação está abrangido pela obrigatoriedade em 2026 ou só em 2027 está, na prática, a fazer uma pergunta de RAG sobre um documento regulatório em português.
Certificação ANPG e [conteúdo local](https://wise-hustlers.com/blog/conteudo-local-angola-anpg-software-conformidade): o Decreto Presidencial n.º 271/20 aprovou o novo Regime Jurídico do Conteúdo Local no Sector Petrolífero, e o Instrutivo n.º 6/21 estabelece que qualquer entidade prestadora de serviços ao sector petrolífero tem de se registar e certificar junto da ANPG, com um prazo legal de até 180 dias após a submissão dos documentos [PWC Angola, "Obrigatoriedade de certificação pela ANPG"; ANPG, "Conteúdo Local"]. Uma subcontratada a preparar essa certificação beneficia directamente de conseguir perguntar, em português, "que documentos tenho de submeter" e receber uma resposta que cita o artigo exacto do Instrutivo — em vez de ter de garimpar manualmente um PDF de dezenas de páginas.

Nenhum destes dois exemplos precisa de tradução do corpus para funcionar bem num sistema de RAG bem desenhado — precisa de um modelo de embeddings e de um reranker genuinamente multilingues, e de pesquisa híbrida que não perca as referências exactas a números de decreto, artigo ou instrutivo, que são exactamente o tipo de âncora textual em que a pesquisa por palavra-chave é insubstituível.

Arquitectura: opções reais, sem empurrar uma "solução única"

Não há um único fornecedor "certo" para isto — a escolha depende do volume documental, da stack já existente na empresa, e de requisitos de residência de dados.

Componente	Opções reais no mercado	Nota honesta
Pesquisa híbrida gerida	Azure AI Search, Elasticsearch	Maduras, com reranking semântico nativo; custo de licenciamento e uma peça de infraestrutura adicional a operar
Base vectorial dentro do Postgres já existente	`pgvector` + full-text search nativo do Postgres	Evita introduzir um novo sistema; vem instalado por omissão nos principais Postgres geridos (AWS RDS, Google Cloud SQL, Supabase, Neon) e o próprio cookbook da OpenAI documenta guardar os seus embeddings nele; exige tuning manual de índices (IVFFlat/HNSW) à medida que o corpus cresce
Embeddings e reranking multilingues	Cohere (`embed-multilingual-v3.0`, Rerank 4.0)	Cobertura forte de português como uma das línguas de negócio prioritárias; é um serviço externo, o que tem implicações de residência de dados a avaliar caso a caso
Integração à medida com o resto do sistema (ERP, CRM, documentos contratuais)	Construção sob medida	É aqui que entra o trabalho de engenharia de aplicações como a Wise Hustlers — não porque a tecnologia de RAG em si seja proprietária, mas porque o valor real está em ligar a citação da fonte ao documento vivo dentro do sistema empresarial (o manual actualizado, o decreto em vigor, o contrato assinado), e não a uma cópia estática

A Wise Hustlers constrói e opera o seu próprio ERP para o sector energético, assente em Postgres, e trata pesquisa aumentada por IA sobre documentação técnica e regulatória como parte do mesmo trabalho de engenharia de dados — não como um produto à parte. Quem quiser perceber como isto se encaixa num sistema mais amplo de machine learning aplicado a operações pode ver o serviço de Machine Learning da Wise Hustlers.

Sobre custo e prazo: qualquer número afirmado por um fornecedor sem contexto do volume documental real, do número de línguas e do nível de integração exigido deve ser tratado com cepticismo. Como estimativa própria da Wise Hustlers — não uma média de mercado — um piloto funcional de RAG sobre um corpus de algumas centenas de documentos técnicos e regulatórios, com pesquisa híbrida, reranking e citação obrigatória, é tipicamente um projecto de várias semanas, não de vários dias; a maior parte do esforço não está em "ligar a API de um modelo", mas em limpar e estruturar os documentos de origem (muitos PDFs digitalizados exigem OCR e correcção manual antes de sequer poderem ser indexados) e em validar, com utilizadores reais do domínio, que as citações produzidas são de facto correctas.

Perguntas frequentes

RAG substitui a necessidade de rever manualmente documentação regulatória crítica?

Não, e nenhum sistema sério deveria ser vendido dessa forma. RAG acelera drasticamente a localização da informação relevante e obriga a que cada resposta aponte para a fonte exacta, mas a decisão de conformidade continua a ser humana. O valor está em reduzir de horas para minutos o tempo de encontrar o excerto certo — não em eliminar a revisão.

Preciso de traduzir todos os meus documentos em inglês para português antes de os indexar?

Não, se usar um modelo de embeddings e um reranker genuinamente multilingues (como os da Cohere, entre outras opções). O sistema pode receber uma pergunta em português e recuperar correctamente um excerto que só existe em inglês no documento original, sem tradução prévia do corpus inteiro.

Uma pesquisa vectorial "boa" já não é suficiente, sem pesquisa por palavra-chave?

Não para documentação técnica e regulatória. Referências exactas — números de decreto, códigos de norma, números de artigo — são precisamente o tipo de conteúdo onde a pesquisa vectorial falha com mais frequência, porque um embedding capta significado, não correspondência literal. A combinação híbrida (vector + BM25) com fusão por RRF é hoje a prática standard, não uma opção de luxo.

O que acontece se o sistema não encontrar a resposta nos documentos indexados?

Num sistema bem desenhado, deve dizer explicitamente que não encontrou suporte documental para a pergunta, em vez de gerar uma resposta plausível mas não verificada. Esta é, na prática, a diferença de engenharia mais importante entre um sistema de RAG com citação obrigatória e um simples chatbot com acesso a uma pesquisa.