Show HN: Parser de PDF open source baseado em regras para RAG

 (github.com/nlmatics)
1 pontos por GN⁺ 2024-01-26 | 1 comentários | Compartilhar no WhatsApp
  • nlm-ingestor é o código de serviço ao qual a API do llmsherpa se conecta, oferecendo parsers de documentos para PDF, HTML, Text, DOCX, PPTX e outros formatos voltados para RAG
  • O parser de PDF usa dados de coordenadas de texto, gráficos e fontes obtidos do Tika modificado pela nlmatics, e pode aplicar OCR automaticamente com a opção apply_ocr quando houver páginas digitalizadas
  • Os recursos de processamento de PDF incluem níveis de seção e subseção, mesclagem de parágrafos, ligação entre seções e parágrafos, tabelas, listas aninhadas, combinação de conteúdo entre páginas, remoção de cabeçalhos e rodapés repetidos, remoção de marca d’água e bounding boxes de OCR
  • Em comparação com parsers visuais baseados em modelo, o parser baseado em regras é descrito como 100 vezes mais rápido por não precisar gerar imagens das páginas do PDF, sendo considerado mais prático para PDFs com camada de texto e documentos com centenas de páginas
  • O servidor de desenvolvimento pode ser iniciado com Docker ou diretamente, e para produção é recomendada uma configuração executada atrás de um gateway de segurança, como nginx ou um gateway de nuvem

Parsers de documentos oferecidos pelo nlm-ingestor

  • nlm-ingestor é um repositório de código de serviço ao qual a API do llmsherpa pode se conectar
  • Ele oferece parsers personalizados para vários formatos de arquivo voltados para RAG (retrieval augmented generation)

    • PDF

    • HTML

    • Text

      • DOCX, PPTX e outros formatos suportados pelo Apache Tika

Como o parser de PDF funciona e quais recursos oferece

  • O parser de PDF é baseado em regras e usa dados de coordenadas de texto, gráficos e fontes obtidos do nlm-tika, uma versão modificada pela nlmatics
  • Ele funciona com base na camada de texto do PDF e pode aplicar OCR automaticamente quando houver páginas digitalizadas no PDF por meio da opção apply_ocr
  • O recurso de OCR é baseado internamente na versão modificada do Tika pela nlmatics, que usa tesseract
  • Há um notebook para testar diretamente o parser de PDF: pdf_visual_ingestor_step_by_step
  • Os recursos do parser de PDF incluem:
    • identificação de seções, subseções e seus níveis
    • combinação de várias linhas para formar parágrafos
    • criação de ligações entre seções e parágrafos
    • identificação de tabelas e das seções em que elas aparecem
    • tratamento de listas e listas aninhadas
    • combinação de conteúdo que atravessa páginas
    • remoção de cabeçalhos e rodapés repetidos
    • remoção de marca d’água
    • fornecimento de bounding boxes para resultados de OCR

Processamento de documentos HTML, Text e Office

  • O parser de HTML gera blocos com reconhecimento de layout para criar chunks de melhor qualidade e aumentar o desempenho de RAG
  • O parser de Text analisa apenas o texto, sem informações visuais, de fonte ou bounding boxes, para inferir listas, tabelas, cabeçalhos e outros elementos
  • DOCX, PPTX e outros formatos suportados pelo Apache Tika são processados usando a saída HTML do Tika e depois enviados ao parser de HTML

Execução e uso da API

  • O processo para executar diretamente consiste em instalar Java, iniciar o servidor Tika, instalar o nlm-ingestor e executar o ingestor
    • Iniciar o servidor Tika: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Instalação: pip install nlm-ingestor
    • Execução: python -m nlm_ingestor.ingestion_daemon
  • Há uma imagem Docker disponível no GitHub Container Registry público
    • Baixar a imagem: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Exemplo de execução: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Depois que o servidor estiver em execução, é possível receber chunks com a biblioteca da API do llmsherpa e usá-los em projetos com LLM
  • Um exemplo de llmsherpa_url é http://localhost:5010/api/parseDocument?renderFormat=all
    • Aplicar OCR: &applyOcr=yes
    • Usar o novo parser de indentação, que emprega um algoritmo diferente para atribuir níveis de cabeçalho: &useNewIndentParser=yes
  • Pode ser usado como servidor de desenvolvimento, mas em ambiente de produção é recomendada uma configuração atrás de um gateway de segurança, como nginx ou um gateway de nuvem
  • Há código de exemplo para testar o servidor com o parser do llmsherpa no notebook test_llmsherpa_api

Por que escolher um parser baseado em regras

  • A equipe da nlmatics afirma ter avaliado várias opções ao longo de 4 anos, incluindo um parser visual baseado em YOLO desenvolvido por Tom Liu e Yi Zhang, antes de escolher um parser baseado em regras
  • O parser baseado em regras é significativamente mais rápido do que qualquer parser visual, e a descrição do repositório o define como 100 vezes mais rápido
    • Parsers visuais precisam gerar imagens de todas as páginas, mesmo em PDFs que já têm camada de texto
    • Parsers visuais podem ser uma opção melhor para PDFs OCR sem camada de texto ou PDFs pequenos compostos por dados de formulários
    • Para PDFs grandes com camada de texto e centenas de páginas, o parser baseado em regras é visto como mais prático
  • Se o recurso de OCR do PDF não for usado, não há necessidade de hardware especial
    • A descrição do repositório afirma que ele pode rodar até em hardware do início dos anos 2000
  • Todos os parsers, inclusive os visuais, podem produzir erros, e a equipe diz não ter ficado satisfeita com a forma de corrigir erros em parsers baseados em modelo
    • Adicionar mais exemplos ao conjunto de treinamento pode reduzir a precisão de aprendizados anteriores e tornar incerto um código que antes funcionava
    • Corrigir problemas de parsers baseados em modelo com ideias baseadas em regras acaba levando novamente à escrita de muitas regras

Tika modificado pela nlmatics

  • O Tika modificado pela nlmatics está no branch 2.4.1-nlm
  • Para conveniência, um arquivo jar compilado está incluído na pasta jars/ do repositório
  • Alguns PDFs podem causar erros no servidor Java; nesse caso, pode ser necessário corrigir esse código e recompilar o arquivo jar
  • Os arquivos modificados adicionam fonte e coordenadas a cada elemento de texto do PDF e removem marcas d’água
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • A alteração em GraphicsStreamProcessor.java serve para adicionar linhas e retângulos que podem ajudar na detecção de tabelas
  • O impacto das mudanças pode ser visto no início do notebook pdf_visual_ingestor_step_by_step
  • Ideias para trabalhos futuros incluem:
    • escrever um wrapper próprio sobre o pdfbox para remover a dependência das mudanças no Tika
    • atualizar para uma versão mais recente do Tika
    • reorganizar o formato HTML retornado para ser mais compatível com CSS

Leituras relacionadas

1 comentários

 
GN⁺ 2024-01-26
Comentários do Hacker News

  • Se você trabalha com artigos científicos, GROBID também vale ser adicionado: https://github.com/kermitt2/grobid
    Uso junto com o paperetl(https://github.com/neuml/paperetl)

  • Ótimo projeto. Para parsing de documentos, usei Tika por muito tempo por causa da maturidade e da ampla variedade de formatos suportados, e a saída XHTML ajuda no chunking de documentos para RAG
    Há exemplos em https://neuml.hashnode.dev/build-rag-pipelines-with-txtai e https://neuml.hashnode.dev/extract-text-from-documents
    Para referência, sou o principal autor do txtai(https://github.com/neuml/txtai)

    • Fugindo um pouco do tema, mas tenho curiosidade sobre como o Tika se compara a outras bibliotecas de parsing de PDF
      O pdfminer.six(usado pelo unstructured) me decepcionou porque a detecção de layout é bem básica e falhou ao fazer parsing de texto em múltiplas colunas, enquanto o MuPDF lidou com isso perfeitamente
      No momento uso uma combinação de MuPDF + AWS Textract(principalmente para tabelas), mas gostaria de saber o que outras pessoas estão usando

  • Parece que pode ser bastante útil. Na empresa onde trabalho, temos uma ferramenta de comparação de PDFs chamada “PDFC”, que lê PDFs e compara diferenças semânticas: https://www.inetsoftware.de/products/pdf-content-comparer
    Como o formato PDF é muito complexo, o parsing pode dar bastante dor de cabeça. Já oferecemos suporte à maioria desses recursos, mas sempre há muitos casos de borda, então abordagens adicionais podem ajudar

  • O fallback com Tesseract OCR parece bom
    Hoje há muitos file loaders para RAG, como langchain, LLMindex, unstructured etc., e fico curioso se há algum motivo para preferir este. Por exemplo, se existem evidências como pontuações melhores em benchmarks

    • Esta ferramenta não compila em Apple Silicon e não há imagem Docker ARM, então não consegui testá-la diretamente
      Dito isso, já usei essas ferramentas de RAG para parsing de PDF e a qualidade da saída era bem baixa. Como o LLM contorna o problema até certo ponto, funciona mais ou menos para RAG, mas, se você quer respostas de qualidade mais alta com referências corretas, acho melhor usar diretamente um parser baseado em regras. Foi o que acabei fazendo, embora baseado em MuPDF, não em Tika
      Talvez os autores desta ferramenta tenham pensado de forma parecida
    • Na última vez que usei Langchain, admito que há cerca de 6 meses, a implementação de extração de conteúdo de arquivos PDF e HTML era muito básica
      Era suficiente para rodar um protótipo de RAG, mas não para construir algo confiável. Este projeto parece uma implementação muito mais testada em produção

  • Excelente trabalho e muito interessante. Mas, ao entrar no GitHub, aparece “This organization has no public members”, não dá para saber quem vocês são, e também não dá para saber o que mais pode estar incluído aqui sem estar público
    No geral, acho que é preciso um meio-termo entre “um grupo oculto sem nome postou isso em um site de segurança da $CORP” e as formas tradicionais de apresentação e construção de confiança, para que se possa construir identidade e confiança ao longo do tempo

  • Para obter chunks ideais em projetos LLM/RAG, você pode usar este servidor junto com o llmsherpa LayoutPDFReader: https://github.com/nlmatics/llmsherpa
    Veja os exemplos e notebooks no repositório

  • Fico curioso se há pares de entrada e saída de exemplo em algum lugar

  • Fiz parsing de algumas centenas de PDFs com isto e os resultados foram bem bons. Se tivesse sido desenvolvido em Julia, acho que teria sido pelo menos 10 vezes mais rápido

  • Fico curioso sobre como isto difere do Azure Document Intelligence, ou se na prática é a mesma coisa

    • Não fazem a mesma coisa. A maioria dos parsers em nuvem usa modelos de visão, então são muito mais lentos e caros, e você ainda precisa escrever mais código por cima para extrair bons chunks
      Usando este servidor junto com a biblioteca llmsherpa(https://github.com/nlmatics/llmsherpa), você consegue chunks compatíveis com layout para projetos LLM/RAG
    • Aqui não há OCR nem IA, exceto pelos fallbacks padrão
      Esta biblioteca e ferramentas como fitz/pymupdf extraem texto diretamente do PDF e permitem aplicar regras de parsing e estruturação. A maioria dos PDFs modernos permite extrair texto sem OCR
      Obviamente é muito mais barato, mas não escala bem para layouts dinâmicos em geral, então normalmente é usado quando dá para configurar para uma estrutura padrão. Ainda assim, vi que a extração de texto baseada em regras funciona de forma bastante dinâmica para coisas como artigos científicos
    • Na última vez que usei, o Azure Document Intelligence não era muito inteligente para escolher pontos de divisão. Este aqui parece ter implementado heurísticas melhores
    • Também estou curioso. O ADI é confiável, mas tem problemas com casos de borda em PDFs mal construídos
      Ainda assim, me preocupa se o Tesseract OCR pode ser uma limitação. Já vi ele cometer erros demais

  • Fico curioso se há exemplos. Não parece haver nenhum arquivo PDF no repositório

    • Os exemplos podem ser vistos no projeto llmsherpa: https://github.com/nlmatics/llmsherpa
      Este projeto nlm-ingestor fornece o backend que funciona com o llmsherpa. A biblioteca llmsherpa é muito conveniente para extrair bons chunks para projetos LLM/RAG