A sua aplicação RAG consegue ingerir os documentos que realmente utiliza? Uma lista de verificação
Uma lista de tipos de ficheiro não permite saber se uma aplicação RAG extrai corretamente os documentos que utiliza. Crie um conjunto de testes representativo, inspecione o conteúdo ingerido e verifique como são tratadas as atualizações, as eliminações e as falhas.
Porque não basta o suporte anunciado a formatos de ficheiro
Uma lista de compatibilidade responde a uma pergunta limitada: a aplicação consegue aceitar um ficheiro com uma determinada extensão? Não indica se o conteúdo de que a sua equipa precisa será extraído na íntegra e num formato que a aplicação consiga utilizar.
Um PDF pode conter texto selecionável, imagens digitalizadas de páginas, tabelas complexas ou uma combinação dos três. Assim, dois ficheiros com a mesma extensão podem exigir testes de ingestão muito diferentes. Considere a indicação «suportado» como um motivo para testar um formato, não como prova de que os seus documentos estão prontos para pesquisa.
Mantenha esta avaliação centrada no processo de ingestão: que conteúdo e metadados entram no sistema, o que é omitido ou alterado e o que acontece quando os ficheiros de origem mudam. Avalie separadamente a qualidade das respostas e a atribuição das fontes.
- Distinga «carregamento aceite» de «conteúdo extraído corretamente».
- Registe se cada teste diz respeito à aceitação do ficheiro, à extração, aos metadados ou ao comportamento ao longo do ciclo de vida do ficheiro.
Crie um conjunto de testes pequeno e representativo
Comece com um conjunto pequeno que reflita as fontes dos seus documentos, em vez de uma grande coleção de ficheiros de exemplo convenientes. Inclua exemplos comuns, bem como os ficheiros mais problemáticos em que os colaboradores realmente confiam. Um conjunto de testes focado facilita a inspeção dos resultados e a repetição das mesmas verificações após alterações de configuração.
Inclua documentos com estruturas e origens variadas. Para páginas digitalizadas, utilize ficheiros cujo texto exista apenas como imagem. Para tabelas, escolha exemplos em que a relação entre títulos, linhas e valores seja importante. Inclua documentos extensos e documentos com várias secções para verificar se há conteúdo perdido ou colocado numa ordem inesperada.
Mantenha um manifesto simples junto dos ficheiros. Registe o conteúdo esperado de cada ficheiro, os campos importantes, o idioma, a estrutura e quaisquer particularidades conhecidas. Assim, os avaliadores terão uma referência para consultar ao inspecionarem o resultado ingerido.
- Ficheiros comuns de cada fonte importante e dos tipos de ficheiro mais frequentes.
- Páginas digitalizadas, documentos com muitas imagens e PDFs que combinam texto e imagens.
- Tabelas, formulários, cabeçalhos, rodapés, esquemas com várias colunas e documentos com listas.
- Documentos curtos e extensos, incluindo exemplos com várias secções.
- Os idiomas, as convenções de nomenclatura e os padrões de metadados presentes na sua coleção real.
Verifique a qualidade da extração: texto, estrutura, metadados e OCR
Para cada ficheiro de teste, compare o conteúdo ingerido com o original. Verifique se o texto essencial está presente, se a ordem de leitura faz sentido e se os títulos e limites entre secções continuam identificáveis. Observe atentamente os valores cujo significado depende de etiquetas próximas, como uma entrada de tabela situada sob um título de coluna específico.
No caso de materiais digitalizados, teste se o texto é extraído e se os erros de reconhecimento alteram nomes, datas, identificadores ou valores. Não assuma que o OCR foi executado apenas porque o carregamento foi bem-sucedido. Confirme-o na documentação da aplicação ou inspecionando o conteúdo resultante.
Verifique os metadados separadamente do texto principal. Conforme o seu caso de utilização, os campos úteis podem incluir o nome do ficheiro, a localização de origem, a data do documento, o idioma ou um identificador interno. Determine quais são preservados, quais podem ser fornecidos ou editados e quais não estão disponíveis. Não assuma que um campo é mantido só porque aparece nas propriedades do ficheiro original.
- É possível inspecionar ou exportar o conteúdo extraído de um ficheiro de teste?
- Os parágrafos essenciais estão presentes, são legíveis e seguem uma ordem lógica?
- Os cabeçalhos das tabelas continuam associados aos valores corretos?
- O OCR reconhece nomes, datas, números e identificadores essenciais com precisão suficiente para o seu caso de utilização?
- Que campos de metadados sobrevivem à ingestão e é possível distinguir ficheiros semelhantes posteriormente?
Teste duplicados, atualizações e eliminações
As coleções de documentos mudam. Teste explicitamente o ciclo de vida dos ficheiros, em vez de tratar a ingestão como um carregamento único. Utilize uma cópia de teste sem dados sensíveis e registe o que a aplicação apresenta antes e depois de cada ação.
Experimente ingerir o mesmo ficheiro duas vezes e, em seguida, teste dois ficheiros diferentes com nomes semelhantes ou conteúdo sobreposto. A aplicação pode tratar estas situações de formas diferentes; o objetivo é determinar o seu comportamento, não assumir que deteta ou combina duplicados.
Depois, altere uma frase ou um valor distintivo num documento de teste e ingira o ficheiro revisto. Verifique se o conteúdo antigo permanece, se o novo aparece e se é possível identificar qual é a versão ativa. Em seguida, remova o ficheiro de origem pelo processo documentado e verifique se o conteúdo ingerido também é removido ou tratado de outra forma, conforme exigido pela sua política.
- Carregue o mesmo ficheiro exatamente duas vezes e registe se é criado um ou mais itens ingeridos.
- Teste um ficheiro revisto com o mesmo nome e outro ficheiro revisto com um nome diferente.
- Verifique como a aplicação distingue dois documentos com nomes semelhantes.
- Após uma atualização, confirme que o texto antigo não permanece inesperadamente ao lado do novo.
- Após uma eliminação, verifique o que acontece ao conteúdo ingerido e aos metadados associados.
Observe as falhas, as novas tentativas e as conclusões parciais
Inclua pelo menos um ficheiro que espera que cause dificuldades, como um ficheiro danificado ou uma variante inesperada de um formato comum, se o puder fazer em segurança. Observe o processo completo, em vez de verificar apenas se o ecrã de carregamento aceitou o ficheiro.
Registe o que a aplicação apresenta quando a ingestão falha ou parece incompleta. Entre os sinais úteis podem estar um estado, uma mensagem de erro, uma entrada de registo ou uma indicação de que o processamento ainda está em curso; a disponibilidade e o nível de detalhe variam consoante a aplicação, por isso confirme-os num teste em vez de assumir que existem.
Se a aplicação disponibilizar uma ação para repetir ou reprocessar, teste-a numa cópia e registe se retoma o processo, começa de novo ou cria um segundo item. Determine também se um lote pode ser processado apenas parcialmente e como identificar os ficheiros que precisam de atenção.
- Se esses estados forem apresentados, é possível distinguir os itens em fila de espera, em processamento, concluídos e com falha?
- O erro identifica o ficheiro e fornece detalhes suficientes para decidir o que tentar a seguir?
- É possível repetir o processamento de um item com falha e o resultado é claro?
- Se um lote for processado parcialmente, é possível identificar os ficheiros concluídos e os que ficaram por processar?
- Os administradores conseguem encontrar registos relevantes ou outras informações de diagnóstico?
Compare o conteúdo extraído antes de avaliar a recuperação
Quando um resultado de pesquisa parece errado, a causa pode ser um problema de ingestão, uma questão de configuração da recuperação ou outro fator. Inspecionar primeiro o conteúdo ingerido ajuda a distinguir essas possibilidades. Se um parágrafo ou valor de tabela essencial nunca chegou ao conteúdo indexado, alterar as definições das respostas não fará reaparecer o texto de origem em falta.
Use as passagens ou os valores distintivos registados no manifesto para identificar se foram preservados. Anote omissões, texto duplicado, problemas na ordem de leitura e caracteres alterados.
O tutorial da LangChain sobre [a avaliação de uma aplicação RAG](https://docs.langchain.com/langsmith/evaluate-rag-tutorial) aborda a criação de conjuntos de dados de teste e a execução de uma aplicação RAG com esses conjuntos. Esse tipo de avaliação é distinto da verificação da forma como uma aplicação específica analisa documentos ou trata alterações nos ficheiros. Por isso, faça dos testes de ingestão uma fase própria.
- Compare o conteúdo extraído com a lista de elementos esperados no manifesto.
- Registe os defeitos de extração separadamente dos defeitos de recuperação ou de resposta.
- Se não for possível inspecionar o conteúdo extraído, pergunte ao fornecedor que evidências ou métodos de diagnóstico estão disponíveis.
Registe os resultados e defina critérios de aceitação
Um registo de avaliação útil é breve, mas repetível. Para cada ficheiro, anote a origem, o formato, as características relevantes, o resultado da ingestão, as observações sobre a extração, o resultado relativo aos metadados, os testes do ciclo de vida e quaisquer soluções alternativas. Registe a configuração da aplicação e a data do teste para que seja possível comparar futuras execuções de forma justa.
Defina critérios de aceitação com base nos seus riscos reais. Por exemplo, uma equipa pode exigir a preservação exata de determinados identificadores, texto utilizável de uma classe definida de páginas digitalizadas ou um processo claro para remover conteúdo quando uma fonte é eliminada. Torne a norma explícita, em vez de classificar simplesmente o resultado da ingestão como «bom» ou «mau».
Decida o que fazer quando um ficheiro não passar no teste. As opções podem incluir excluir essa fonte, preparar uma cópia normalizada, acrescentar uma etapa de revisão manual ou escolher outra aplicação. Se for necessária uma solução alternativa, documente quem é responsável por ela e como será mantida.
- Ficheiro de teste e origem
- Conteúdo e metadados esperados
- Extração observada e eventuais omissões ou distorções
- Comportamento perante duplicados, atualizações e eliminações
- Visibilidade das falhas, resultado de novas tentativas e intervenção manual
- Aprovado, aprovado com condições ou reprovado face a um requisito escrito
Questões a esclarecer na documentação ou através de um teste direto
O comportamento da ingestão depende da aplicação. Procure respostas na documentação oficial atual e confirme os requisitos importantes com o seu conjunto de testes.
Não pergunte apenas que formatos constam da lista: esclareça também que processamento é efetuado e que limites se aplicam. Confirme se há OCR, se este é executado no seu ambiente ou se envolve um serviço externo e que dados podem ser enviados para fora da sua implementação. Não deduza estes detalhes a partir de uma lista de formatos.
No caso de implementações com alojamento próprio, o facto de alojar a aplicação não resolve automaticamente todas as questões relacionadas com o tratamento dos dados. Confirme o percurso de processamento e as dependências e, em seguida, tome decisões sobre acesso, retenção e governação adequadas à sua organização.
- Que tipos de ficheiro e estruturas específicas de documentos estão documentados como suportados?
- Há limites para o tamanho dos ficheiros, o número de páginas, o tamanho dos lotes, o tempo de processamento ou o tamanho da coleção?
- O OCR está incluído, é opcional ou depende de outro componente ou serviço?
- O processamento de análise, OCR ou outras operações envia conteúdo dos documentos para um serviço externo?
- É possível inspecionar o texto extraído e os metadados? Que detalhes de diagnóstico estão disponíveis?
- O que é que a aplicação conserva depois da remoção de um ficheiro de origem e que passos são necessários para o eliminar?
Perguntas frequentes
Qual é a diferença entre o suporte a ficheiros e a ingestão bem-sucedida de documentos?
O suporte a ficheiros indica, geralmente, que uma aplicação aceita um formato. Uma ingestão bem-sucedida significa que o conteúdo e a estrutura relevante de que a sua equipa precisa foram extraídos e estão utilizáveis. Teste ambos com exemplos reais, incluindo documentos difíceis.
Quantos documentos deve conter um conjunto de testes de ingestão RAG?
Não existe um número universal. Comece com um conjunto de tamanho gerível que cubra as fontes, os formatos, os idiomas e os casos extremos importantes da sua coleção. O objetivo é obter uma cobertura representativa e inspecionar os resultados com atenção, não criar uma amostra grande só por si.
Como posso testar o OCR sem confundir a ingestão com a qualidade das respostas?
Escolha páginas digitalizadas com uma lista curta de nomes, datas, valores ou expressões esperados. Inspecione o conteúdo extraído, se estiver disponível, ou utilize o método de diagnóstico documentado pelo fornecedor. Verifique diretamente o reconhecimento antes de avaliar os resultados de pesquisa ou as respostas geradas.
Devo assumir que a atualização ou eliminação de um ficheiro de origem atualiza automaticamente o conteúdo ingerido?
Não. O comportamento pode variar consoante a aplicação e a configuração. Teste ficheiros revistos e removidos através do processo documentado e verifique o que acontece ao conteúdo ingerido antes de confiar nele para materiais importantes.
O alojamento próprio garante que o processamento de documentos permanece no meu ambiente?
Não é possível tirar essa conclusão apenas com base no alojamento próprio. Verifique se a análise, o OCR ou outro processamento depende de serviços externos e confirme que dados dos documentos são enviados e retidos.
Fontes e leituras adicionais
- Evaluate a RAG application — LangChain
- A complete guide to RAG evaluation — Evidently AI