A demo funcionou com arquivos markdown limpos. A produção ingere 40.000 relatórios em PDF, documentos Word com alterações controladas, PowerPoints com tabelas embutidas e imagens escaneadas que alguém digitalizou em 2011. O modelo é o mesmo. Os resultados não são.
Um modelo melhor aplicado a documentos mal parseados produz respostas erradas que soam melhor. Não é uma preocupação teórica. É o padrão de falha mais comum em implantações corporativas de RAG, e é invisível até que o sistema esteja em uso.
A Realidade Inconveniente dos Documentos Corporativos
O conhecimento corporativo não vive em arquivos de texto limpos. Vive em PDFs com layouts de múltiplas colunas que fazem parse como texto intercalado, em documentos Word onde alterações controladas aparecem como conteúdo excluído na extração bruta, em PowerPoints onde a ordem de leitura dos elementos do slide não tem relação com a estrutura visual, em imagens escaneadas onde erros de OCR se acumulam, e em arquivos Excel onde fórmulas são removidas durante a extração e os valores que produzem nunca aparecem.
Bibliotecas padrão de parsing de PDF lidam adequadamente com documentos simples. Destroem a estrutura de tabelas em documentos complexos: colunas perdem alinhamento, cabeçalhos de múltiplas linhas se mesclam com células de dados, e tabelas que abrangem páginas produzem fragmentos incoerentes. Um documento de compliance regulatório onde uma tabela de requisitos é desestruturada durante o parsing produz um LLM que lê mal os requisitos com confiança.
O resultado no nível do chunk: tabelas parciais com células faltando, procedimentos divididos em pontos arbitrários sem contexto sobre o procedimento ao qual pertencem, e metadados que estavam incorporados na estrutura do documento (títulos de seções, números de página, identificadores do documento) removidos ou mal atribuídos.
Qualidade do modelo não pode compensar qualidade de ingestão. O pipeline de ingestão é onde a qualidade do RAG é determinada, não no momento da inferência.
O Stack de Parsing de Documentos que Preserva Estrutura
Três parsers merecem avaliação séria para implantações corporativas:
Docling (IBM open source [ESTIMATIVA: verificar status atual no GitHub IBM Research]): extração de PDF com reconhecimento de layout que preserva estrutura de tabelas, lida com layouts de múltiplas colunas e produz output hierárquico limpo. Projetado para documentos tipografados, não escaneados. Auto-hospedável, o que importa para residência de dados.
LlamaParse: parsing via API que lida com PDFs complexos incluindo tabelas, figuras e layouts de conteúdo misto. Produz output hierárquico que mapeia diretamente para estratégias de chunking hierárquico. O tradeoff: API em nuvem significa que documentos saem do perímetro da organização. Não adequado para corpora de documentos confidenciais ou com escopo GDPR sem acordos explícitos de processamento de dados.
Unstructured.io: suporte a mais de 20 formatos de arquivo, extração rica de metadados, auto-hospedável via distribuição open-source. Lida com o zoológico completo de documentos corporativos: Word, PowerPoint, HTML, Excel, e-mail. A versão auto-hospedada mantém dados on-premise e satisfaz requisitos de residência de dados.
A decisão de seleção não é sobre qual parser produz o melhor output em isolamento. É sobre duas restrições: residência de dados e distribuição de tipos de documento.
Para ambientes regulados, dados com escopo GDPR ou documentos contendo segredos comerciais, o parsing auto-hospedado é obrigatório. APIs de parsing em nuvem introduzem risco de residência de dados na etapa de parsing, antes que qualquer LLM tenha tocado o conteúdo. Se residência de dados é um requisito, descarte parsers somente em nuvem primeiro, depois avalie entre as opções auto-hospedáveis.
Para distribuição de tipos de documento: execute seus dez documentos de pior formato em cada parser candidato, depois inspecione manualmente se as tabelas são coerentes e os procedimentos estão íntegros. Benchmarks públicos em PDFs limpos não lhe dizem nada sobre seu corpus específico de documentos.
Estratégia de Chunking Não É um Detalhe
O chunking determina a granularidade das evidências disponíveis para o modelo. Granularidade errada em qualquer direção degrada a recuperação.
Chunking de tamanho fixo (o padrão em tutoriais): dividir texto a cada 512 tokens, sobrepor por 50 tokens. Rápido de implementar. Quebra unidades semânticas nas fronteiras de chunks. Um procedimento descrito ao longo de duas páginas fica em dois chunks; nenhum deles contém o procedimento completo. A perda de contexto é sistemática e previsível.
Chunking baseado em sentenças: respeita fronteiras de linguagem natural. Apropriado para texto narrativo, documentos de política, relatórios. Mal adequado para documentação técnica onde uma única sentença pode não ter sentido sem a tabela ou diagrama que a segue.
Chunking semântico: divide onde o tópico muda, baseado em similaridade de embedding entre passagens adjacentes. Apropriado para documentos técnicos com seções distintas. Requer uma chamada de embedding por decisão de divisão, o que adiciona custo de ingestão.
Chunking hierárquico (pai-filho): armazena resumos de documentos no nível pai e conteúdo completo em chunks filho. A recuperação identifica seções relevantes no nível de resumo, depois busca o conteúdo filho. Habilita o padrão “recuperar o resumo, buscar o detalhe sob demanda.” Apropriado para documentos regulatórios longos e manuais técnicos onde relevância no nível de seção difere da relevância no nível de passagem.
Chunking baseado em proposições: decompõe texto em afirmações factuais atômicas. Maior precisão de recuperação. Maior custo de ingestão. Apropriado para bases de conhecimento onde a granularidade de fatos importa: requisitos de compliance, cláusulas contratuais, especificações de produto.
A regra: combine a estratégia de chunking com a estrutura epistêmica do tipo de documento. Um manual de usuário, um documento regulatório e um relatório de resultados têm estruturas epistêmicas diferentes e justificam abordagens de chunking diferentes. Aplicar uma única estratégia em um corpus de documentos heterogêneos porque é o padrão do framework é uma decisão arquitetural feita por inação.
Metadados como o Multiplicador Oculto de Recuperação
Todo chunk no repositório vetorial deve carregar: fonte do documento, título da seção, data da última modificação, autor ou proprietário do documento, idioma, nível de classificação, jurisdição e tipo de documento. Isso não é enriquecimento opcional. É a infraestrutura que torna a recuperação controlável.
Filtragem de metadados antes da busca vetorial elimina resultados irrelevantes mais rápido e com mais confiabilidade do que reranking após a recuperação. Um usuário na equipe de operações alemã consultando um corpus de documentos multilíngue não deveria recuperar documentos da subsidiária brasileira em português. Esse filtro é uma operação de metadados. Não é algo que um reranker consegue corrigir depois, porque o reranker está operando em documentos que já estão no conjunto candidato.
Metadados faltando tornam o controle de acesso baseado em permissão impossível. Você não consegue restringir recuperação por departamento, nível de clearance ou jurisdição geográfica sem metadados consistentes em cada chunk. Controle de permissão aplicado na camada de interface de usuário, sem aplicação na camada de recuperação, não fornece proteção real. O documento foi recuperado. O que acontece com essa recuperação é definido pela implementação.
O pipeline de ingestão é onde os metadados são injetados. Retrofitar metadados em um repositório vetorial existente requer re-ingestão de todo o corpus: fazer parse, re-chunkear, re-embeder, re-indexar. O custo escala com o tamanho do corpus. O design de metadados na fase de arquitetura de ingestão é substancialmente mais barato do que a migração de metadados após a implantação.
A Decisão do Modelo de Embedding
A maioria das equipes corporativas adota como padrão OpenAI text-embedding-3-small ou text-embedding-ada-002 porque já tem uma conta OpenAI e os tutoriais o usam. O padrão funciona para corpora de documentos somente em inglês onde o uso de API em nuvem é aceitável.
Para implantações corporativas europeias ou do Oriente Médio com corpora de documentos multilíngues: BGE-M3 (BAAI) suporta mais de 100 idiomas em um único modelo e produz vetores densos, vetores esparsos e representações multi-vetor no estilo ColBERT simultaneamente. Um único embedding BGE-M3 suporta hybrid search sem a complexidade de rodar modelos densos e esparsos separados. Auto-hospeda no hardware que você já controla.
A restrição que torna a seleção do modelo de embedding uma decisão de longo prazo: re-embeder um corpus inteiro após mudar de modelos requer re-ingerir tudo. Um corpus de 50.000 documentos re-embedado com um modelo diferente é semanas de compute e trabalho de infraestrutura. Acerte a decisão do modelo de embedding na fase de arquitetura, quando mudá-lo custa horas, não semanas.
Faça benchmark no seu corpus, não em benchmarks públicos de domínios diferentes. Um modelo que tem bom desempenho no benchmark BEIR pode ter desempenho inferior nos seus tipos específicos de documentos. O procedimento de avaliação: pegue 200 documentos representativos do seu corpus, gere 50 consultas representativas, compare precisão e recall de recuperação entre modelos candidatos. Faça isso antes de se comprometer.
A Arquitetura do Pipeline de Ingestão em Produção
O pipeline de ingestão em produção tem sete etapas, e todas as sete importam:
Trigger: documento adicionado ou modificado em um sistema de origem (SharePoint, Google Drive, Confluence, um sistema de gestão de documentos) dispara um evento que inicia a ingestão. Novos documentos são ingeridos; documentos atualizados são re-ingeridos; documentos excluídos são removidos do repositório vetorial.
Extração: o documento é recuperado e parseado usando o parser de preservação de estrutura selecionado. O output é conteúdo estruturado com informações de layout, estrutura de tabela e hierarquia de seções.
Chunking: estratégia de chunking aplicada por tipo de documento. Documentos de política usam chunking semântico. Manuais técnicos usam chunking hierárquico. Contratos usam chunking baseado em proposições. O mapeamento entre tipo de documento e estratégia de chunking é configurado, não codificado, para que possa ser atualizado conforme o corpus de documentos evolui.
Enriquecimento: metadados injetados a partir de propriedades do documento, metadados do sistema de origem e regras de classificação. Fonte, data, proprietário, classificação, idioma, jurisdição. Todo chunk recebe metadados completos antes do embedding.
Embedding: modelo de embedding aplicado, vetores computados e armazenados no banco de dados vetorial junto com metadados. Embedding em lote para ingestão inicial, embedding incremental para atualizações de documentos.
Atualização do índice: novos vetores indexados, vetores atualizados substituem versões anteriores, vetores de documentos excluídos são removidos. O gerenciamento de frescor não é automático na maioria dos bancos de dados vetoriais; requer exclusão explícita de registros obsoletos.
Log de auditoria: todo evento de ingestão registrado com timestamp, identificador do documento de origem, hash do documento, contagem de chunks, versão do modelo de embedding e versão do pipeline de ingestão. Este é o registro que responde “qual versão de qual documento foi a fonte desta resposta?” Essa resposta é um requisito de compliance em indústrias reguladas, não um auxílio de depuração.
Sem o log de auditoria, você não consegue responder essa pergunta. Em indústrias onde essa pergunta tem peso regulatório, a incapacidade de respondê-la é uma responsabilidade, não um inconveniente.
Qualidade de ingestão determina o que a camada de recuperação tem para trabalhar. A arquitetura de recuperação que transforma documentos bem ingeridos em respostas com baixa alucinação está coberta em RAG Alucina Menos Quando Você Para de Tratá-lo Como Busca.
Para equipes corporativas avaliando se seu pipeline de ingestão atual é o gargalo, o AI Opportunity Sprint diagnostica isso em dias, não trimestres.