É necessária uma assinatura do JoVE para visualizar este conteúdo. Faça login ou inicie seu teste gratuito.
Artigo de investigação
Aqui, apresentamos um protocolo para melhorar a descoberta em arquivos digitais históricos, integrando reconhecimento óptico de caracteres pós-correção, classificação visual de documentos, enriquecimento de metadados e avaliação de recuperação em um fluxo de trabalho auditável.
Arquivos digitais históricos estão cada vez mais pesquisáveis, mas a descoberta permanece limitada quando erros de reconhecimento óptico de caracteres, tipos de documentos visualmente heterogêneos e metadados escassos são tratados separadamente. Este estudo teve como objetivo desenvolver um protocolo reprodutível para avaliar se um fluxo de trabalho conservador de inteligência artificial multimodal pode melhorar a recuperação arquivística sem substituir a revisão por arquivistas. Um corpus de 1.600 registros arquivísticos digitalizados de oito classes de documentos foi montado, e um benchmark de 420 consultas foi usado para comparar cinco condições de recuperação: indexação de base, correção de reconhecimento óptico de caracteres isoladamente, classificação visual isolada, enriquecimento de metadados sozinho e integração multimodal completa. Os resultados em nível de registro incluíram taxa de erro de caracteres (CER), taxa de erro de palavra (WER), recordação de entidades nomeadas, precisão de classificação por tipo de documento, confiança na previsão, completude dos metadados e correspondência de títulos de assunto. Os resultados em nível de consulta incluíram P@10, R@10, nDCG@10, tempo até o primeiro resultado relevante e taxa de busca bem-sucedida. A correção por reconhecimento óptico de caracteres reduziu fortemente a WER para cartas manuscritas, livros-razão e livros de registro; o ajuste visual melhorou a precisão da classificação principalmente para mapas, cartazes, jornais e livros de registro; e o enriquecimento de metadados aumentou a completude em todos os períodos históricos. A condição multimodal completa alcançou o maior desempenho de recuperação (P@10 = 0,624, R@10 = 0,492, nDCG@10 = 0,634) e reduziu o tempo médio até o primeiro resultado relevante de 156,079 s para 58,485 s. Esses resultados suportam um fluxo de trabalho modular e auditável, no qual texto, imagem e sinais descritivos são combinados sob limiares explícitos e revisão humana.
Os arquivos digitais expandiram-se rapidamente e agora apoiam pesquisas em história, patrimônio cultural, administração pública e humanidades digitais. No entanto, o acesso permanece desigual porque registros arquivísticos frequentemente combinam saídas degradadas de reconhecimento óptico de caracteres, layouts de página visualmente diversos, práticas de catalogação inconsistentes e nomes, lugares e instituições historicamente variáveis. Essas limitações afetam não apenas a qualidade da transcrição, mas também a recuperação, filtragem e reutilização posterior de coleçõesdigitalizadas 1,2,3,4,5,6,7.
Estudos existentes de inteligência artificial documental e recuperação arquivística melhoraram componentes individuais, como reconhecimento óptico de caracteres após correção, classificação de imagens de documento, normalização de metadados, modelagem de tópicos, embeddings de palavras, recuperação neural e prática de governançade dados 8,9,10,11,12,13,14,15, 16,17,18,19,20,21,22,23,24,25. No entanto, muitos sistemas arquivísticos ainda avaliam esses componentes separadamente, tornando difícil determinar se um fluxo de trabalho combinado melhora a descoberta em condições de busca realistas. A lacuna metodológica abordada aqui é a ausência de um protocolo reproduzível e auditável que conecte módulos de texto, imagem e metadados aos resultados de recuperação em um único fluxo de trabalho arquivístico.
O objetivo central foi testar se correção de reconhecimento óptico de caracteres, classificação visual de documentos e enriquecimento de metadados restritos por regras produzem melhorias complementares quando avaliadas em relação ao mesmo benchmark de recuperação.
Hipotetizamos que a condição multimodal completa superaria cada condição de componente único porque a descoberta arquivística depende da interação de texto legível, estrutura de documento visualmente interpretável e metadados descritivos pesquisáveis. O fluxo de trabalho foi projetado de forma conservadora: saídas automatizadas podiam enriquecer índices de recuperação, mas previsões de baixa confiança eram sinalizadas para revisão em vez de usadas como descrição arquivística autoritativa.
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.
Este estudo utilizou registros arquivísticos digitalizados e consultas simuladas de recuperação como unidades de análise. Repositórios arquivísticos podem restringir o acesso a registros sensíveis ou culturalmente restritos. Siga as regras de acesso ao repositório, procedimentos institucionais de segurança de dados e requisitos de desidentificação antes de processar ou compartilhar qualquer registro. Nenhum lixo químico perigoso, biológicos, cortantes, radioativos ou outros resíduos laboratoriais regulados foi gerado por esse fluxo de trabalho digital.
Projeto do estudo e construção do corpus
A Figura 1 apresenta o fluxo de trabalho completo do estudo, incluindo construção de corpus, rotulagem de referência, pré-processamento de imagens, geração e pós-correção de OCR, classificação visual, enriquecimento de metadados, construção de índices, avaliação de recuperação, análise estatística e embalagem de reprodutibilidade.
A construção do corpus foi realizada de 15 de janeiro a 30 de abril de 2025, seguida pelo projeto e depuração do sistema de 1º de maio a 31 de outubro de 2025. O corpus continha 1.600 registros arquivísticos digitalizados, selecionados de oito depósitos que representam sistemas estaduais, municipais, religiosos, de museus, universitários e bibliotecarios. O quadro de amostragem foi estratificado por classe de repositório e documento para preservar a heterogeneidade arquivística entre cartas manuscritas, livros-caixa, mapas, jornais, fotografias com legendas, cartazes, livros de registro e correspondência datilografada.
Para cada registro candidato, o registro de seleção registrava o identificador do repositório ou coleção, identificador de catálogo, classe do documento, período histórico aproximado, contexto dominante do idioma, formato de imagem disponível, resolução da imagem, contagem de páginas e campos descritivos de referência. A inclusão exigia todos os seguintes fatores: um identificador estável de catálogo; pelo menos uma imagem de página em TIFF, JPEG ou PNG; resolução de imagem de origem de pelo menos 150 dpi; conteúdo textual, tabular ou estrutural documental legível; e atribuição a uma das oito classes de documentos predefinidas. Os critérios de exclusão eram duplicatas exatas, páginas reversas em branco, imagens cortadas a ponto de mais de 30% da área com texto estar faltando, e registros considerados ilegíveis após inspeção manual.
O benchmark de recuperação continha 420 consultas curtas em linguagem natural geradas entre 5 e 20 de agosto de 2025. A geração de consultas seguiu um modelo reproduzível: as necessidades de informação dos candidatos foram amostradas de pessoas, instituições, locais, períodos de datas, ocupações, eventos e temas atuais; cada consulta foi normalizada para 2–9 palavras; e registros relevantes ao alvo foram identificados antes da comparação do sistema. Cada consulta foi avaliada sob cinco condições de recuperação, produzindo 2.100 observações de condição de consulta correspondentes.
Rotulagem de referência e controle de qualidade
A rotulagem de referência foi realizada de 1º de maio a 15 de julho de 2025, por três anotadores: dois membros da equipe de arquivos com experiência em catalogação descritiva e um pesquisador de humanidades digitais com experiência em avaliação de documentos históricos. O guia de anotação definiu classes de documentos, categorias de contexto de idioma, bins de período histórico, campos de completude de metadados, categorias de entidades nomeadas e regras para selecionar regiões de avaliação de OCR.
Para avaliação de OCR, os anotadores selecionaram regiões representativas com texto que incluíam títulos, nomes, datas, termos institucionais, notas marginais, entradas tabulares e, quando presentes, áreas de layout ruidosas. Quando uma página continha múltiplas regiões de texto, a região selecionada precisava ser relevante para a recuperação e incluir caracteres suficientes para cálculos de CER e WER. As discordâncias eram inicialmente resolvidas por meio de discussões entre os dois principais anotadores; Casos não resolvidos foram julgados pelo pesquisador de humanidades digitais.
O controle de qualidade utilizou um subconjunto aleatório de 12% dos registros. O acordo entre anotadores para o tipo principal de documento era o kappa de Cohen = 0,86, apoiando um acordo substancial. O log de adjudicação manteve os rótulos original e final, a categoria de discordância e o motivo da resolução para que futuros usuários possam auditar definições de classes e casos extremos.
Pré-processamento de imagem
Todas as imagens foram processadas em nível de registro usando Python 3.11.8 com OpenCV 4.9.0, Pillow 10.3.0 e NumPy 1.26.4. Cada página de entrada era convertida para escala de cinza de 8 bits, a menos que a cor contenha informações semânticas, como mapas, cartazes, carimbos ou anotações codificadas por cores. O descompasso foi estimado usando perfis de projeção e detecção de linhas de Hough; Deskewing era aplicado apenas quando o ângulo absoluto de desvio ultrapassava 1,5 graus e era limitado a 8,0 graus para evitar distorção.
O aprimoramento de contraste utilizou equalização adaptativa de histogramas limitada por contraste com clipLimit = 2.0 e tileGridSize = 8 × 8. Um filtro mediano com um núcleo de 3 × 10−23 foi aplicado apenas quando a razão estimada de ruído de fundo excedeu 0,35. Imagens capturadas entre 150 e 299 dpi foram reamostradas para 300 dpi para reconhecimento óptico de caracteres; Imagens já a 300 dpi ou mais não foram ampliadas. Não foi usada super-resolução, restauração generativa ou alucinação de conteúdo.
O bleed-through, escurecimento das bordas, textura irregular do papel, carimbos marginais, caligrafia, linhas com regras e limites de tabela foram mantidos, a menos que impedissem a seleção de regiões OCR. Essa regra preservava evidências arquivísticas enquanto padronizava suficientemente as entradas de imagem para OCR reproduzível e classificação.
Geração de base OCR e pós-correção
O OCR de base foi gerado com o OCR Tesseract 5.3.0. O pacote de idiomas primários foi selecionado a partir do idioma do catálogo e do script visível; a decodificação multilíngue era ativada quando o idioma do catálogo e o script da página não coincidiam. As saídas do OCR eram agrupadas no nível do registro e armazenadas com identificadores de página, confiança do OCR, coordenadas da caixa delimitadora quando disponíveis e texto bruto antes da correção.
A correção pós-OCR utilizou um procedimento conservador em três estágios. Primeiro, a normalização em nível de caractere corrigiu confusões frequentes de reconhecimento histórico, incluindo ligaduras, substituições long-s/short-s, pontuação fragmentada e substituições dígito-letra. Segundo, a correção em nível de token utilizou candidatos de distância de edição e classificação de frequência a partir de um léxico específico do arquivo de nomes pessoais, nomes de lugares, instituições, termos administrativos e variantes históricas de ortografia. Terceiro, verificações de sequência baseadas em regras validaram entidades e datas nomeadas com base em evidências de contexto e metadados.
Substitutos candidatos foram aceitos apenas quando a confiança na correção posterior excedeu 0,80; Substituições de entidades nomeadas exigiam confiança de pelo menos 0,85. Candidatos abaixo do limite foram mantidos como texto do OCR, mas sinalizados para revisão. A CER foi calculada como a distância de edição de Levenshtein dividida pelo número de caracteres na transcrição de referência. A WER usava a mesma fórmula no nível do token. A recordação de entidades nomeadas foi calculada como entidades de referência corretamente reconhecidas divididas por todas as entidades de referência na região de avaliação selecionada.
Classificação visual de documentos
O módulo de classificação visual atribuía cada registro a uma das oito classes de documentos arquivísticos: carta manuscrita, livro-caixa, mapa, jornal, fotografia com legenda, pôster, livro de registro e correspondência datilografada. O tipo de documento previsto era usado como sinal de recuperação e filtragem, não como substituto autoritativo para a catalogação arquivística.
O modelo foi implementado no PyTorch 2.2.2 e no torchvision 0.17.2 usando uma espinha dorsal EfficientNet-B3 pré-treinada pelo ImageNet. As miniaturas em nível de registro foram redimensionadas para 384 x 384 pixels. Para reduzir vazamentos, os registros foram divididos por classe de repositório e documento em conjuntos de treinamento, validação e teste em uma proporção de 70:15:15, correspondendo a aproximadamente 1.120, 240 e 240 registros.
O treinamento usou AdamW com taxa inicial de aprendizado = 1 × 10-4, decaimento do peso = 1 × 10−2, tamanho do lote = 16, suavização de rótulos = 0,05 e parada precoce quando a perda de validação não melhorou por cinco épocas consecutivas. A inversão horizontal foi desativada porque layouts de arquivo espelhado não são realistas. O aumento foi limitado à rotação de -3 graus para +3 graus e variação de brilho dentro de ±10%.
Os diagnósticos de modelos em nível de época são resumidos em 20 linhas de treinamento, cada uma contendo perda de treinamento, perda de validação, precisão do treinamento, precisão de validação, macro-F1, F1 ponderado, ROC-AUC e PR-AUC.
Fluxo de trabalho de enriquecimento de metadados
O enriquecimento de metadados foi projetado para melhorar a descoberta enquanto preserva o conservadorismo arquivístico. Valores existentes do catálogo eram mantidos, a menos que contivessem uma contradição explícita, como uma data impossível ou um conflito do tipo documento confirmado tanto pelo OCR quanto por evidências visuais. Os campos de enriquecimento de candidatos incluíam título normalizado, tipo de documento, data aproximada, menções a instituições, menções geográficas, menções a nomes pessoais, títulos de assuntos e palavras-chave.
A prioridade das evidências seguia uma ordem fixa: (1) metadados existentes do catálogo, (2) saída corrigida do OCR e (3) previsão visual do tipo de documento. A correspondência controlada de vocabulário foi usada para títulos de assuntos, e a expansão semântica do vizinho mais próximo com transformadores de frase 2.7.0 foi usada apenas quando a similaridade do cosseno era pelo menos 0,72. A normalização de data exigiu confiança de pelo menos 0,85 ou concordância entre OCR e metadados. Cada campo adicionado automaticamente manteve sua fonte, confiança e identificador de regra.
Completude dos metadados foi definida como o número de campos descritivos centrais preenchidos dividido pelo número de campos centrais aplicáveis para aquele registro. A correspondência de título de assunto foi definida como a presença de pelo menos um rótulo de assunto de vocabulário controlado, apoiado por evidências de conteúdo em nível de registro e considerado relevante para a categoria de consulta.
Construção do sistema de recuperação
Cinco índices de recuperação foram construídos para isolar contribuições de módulos: indexação de linha de base; apenas correção de reconhecimento óptico de caracteres; apenas classificação visual; apenas enriquecimento de metadados; e integração multimodal completa. Todos os índices foram construídos no software de mecanismo de busca listado na Tabela de Materiais (versão 8.11.1) no nível de registro. Os parâmetros de BM25 foram fixados em k1 = 1,2 e b = 0,75 antes da avaliação.
O índice de referência usava metadados originais e texto OCR de referência. A condição de TOC substituiu o OCR de base por um TOC corrigido. A condição visual adicionou priors do tipo documento e aumentos de ranking conscientes da classe. A condição de metadados adicionou campos descritivos enriquecidos. A condição multimodal completa combinava OCR corrigido, priors visuais e metadados enriquecidos. Os pesos dos campos foram fixados antes do teste: título normalizado = 3,0, títulos de assunto = 2,5, menções a pessoas e instituições = 2,2, menções ao local = 2,0, tipo de documento = 1,8, texto do corpo do OCR corrigido = 1,0 e texto do corpo do OCR de base = 0,8, quando aplicável.
A correspondência exata de frases foi habilitada para consultas citadas. A expansão de consultas era permitida apenas nas condições de enriquecimento de metadados e multimodal completo, e era limitada a sinônimos aceitos de vocabulário controlado e variantes de cabeçalhos de assunto. Os registros de busca foram gerados de 25 a 28 de agosto de 2025, no ambiente Linux conteinerizado listado na Tabela de Materiais, com sementes fixas e configurações de índice congeladas.
Projeto de consulta e medidas de resultado
As 420 consultas representavam comportamentos comuns de busca arquivística, em vez de prompts de benchmark apenas com palavras-chave. Os temas incluíam nomes pessoais, instituições, lugares, datas e intervalos de datas, ocupações, eventos e temas temáticos. Cada consulta era armazenada com sua redação normalizada, conjunto de registros alvo, categoria de tópico de consulta e pontuação de dificuldade.
A dificuldade foi avaliada antes da coleta usando ambiguidade do alvo, especificidade lexical e frequência esperada de expressão. Pontuações compostas abaixo de 0,40 foram classificadas como de baixa dificuldade, de 0,40 a 0,69 como de dificuldade moderada, e de 0,70 ou superior como de alta dificuldade. Os julgamentos de relevância eram concluídos antes da comparação do sistema e depois verificados em relação à coleção finalizada.
Os desfechos da coleta incluíram P@10, R@10, nDCG@10, tempo até o primeiro resultado relevante e taxa de busca bem-sucedida. P@10 foi a proporção dos 10 melhores discos considerados relevantes. R@10 foi a proporção de todos os registros relevantes conhecidos recuperados entre os 10 primeiros. nDCG@10 usava relevância graduada quando disponível e relevância binária caso contrário. O tempo até o primeiro resultado relevante foi medido desde o envio da consulta até o primeiro registro relevante aparecer na saída ranqueada. Uma busca bem-sucedida foi definida como pelo menos um resultado relevante entre os 10 melhores registros.
Coleta de estatísticas
Todas as análises foram realizadas usando as versões de software listadas na Tabela de Materiais. Os resultados contínuos foram resumidos como média ± DS quando aproximadamente simétricos e como mediana com intervalo interquartil caso contrário. Os resultados categóricos foram resumidos como contagens e percentagens.
A normalidade das diferenças pareadas foi avaliada pelo teste de Shapiro-Wilk e pelos gráficos de distribuição. Os resultados pré/pós de TOC e metadados foram comparados com testes T pareados quando as diferenças pareadas eram aproximadamente normais e os testes de Wilcoxon assinados por rank fora do caso. O desempenho da classificação antes e após o ajuste fino foi comparado usando o teste de McNemar em rótulos pareados corretos/incorretos. Os resultados de coleta multi-braço pareados foram comparados com o teste de Friedman, seguido pelos testes de Wilcoxon por sinal ajustados por Holm.
Todos os testes estatísticos foram bilaterais, e P < 0,05 foi considerado estatisticamente significativo. Intervalos de confiança foram estimados usando 2.000 reamostras bootstrap, com a semente aleatória fixada em 2025. Os efeitos foram relatados como diferenças médias, razões de chances pareadas ou tamanhos de efeito baseados em classificação, de acordo com o tipo de desfecho.
Reprodutibilidade, escopo e disponibilidade de recursos
Todos os parâmetros do pipeline eram fixados antes dos testes de recuperação. Nenhum parâmetro foi otimizado no benchmark de recuperação mantido para fora. Arquivos de configuração, vocabulários controlados, tabelas de léxicos, modelos de consulta, mapeamentos de campos, diretrizes de anotação, scripts estatísticos e scripts de geração de figuras foram mantidos no sistema de controle de versões listado na Tabela de Materiais com semente aleatória 2025.
Para suportar validação independente, o livro de dados de origem inclui uma tabela desidentificada com 1.600 registros e 17 variáveis usadas para reconhecimento óptico de caracteres, metadados e análises de classificação visual. Tabelas 1, Tabela 2, Tabela 3, Tabela 4 e Tabela 5, resumos de figuras e fontes, definições de benchmark-consulta, resumos de relevância-julgamento, substitutos de log-retrieval, diagnósticos de treinamento, categorias de léxico, regras de mapeamento de vocabulário e campos de diretrizes de anotação são fornecidos como tabelas ou arquivos de materiais carregáveis separados quando aplicável. Materiais que não podem ser compartilhados publicamente devido a restrições de repositório são representados por campos de metadados desidentificados e campos de amostragem reprodutíveis.
Este protocolo avalia descobertas orientadas à recuperação, em vez da veracidade das alegações históricas. Ela não substitui a avaliação do arquivista, avaliação de proveniência, revisão de privacidade ou regras específicas de acesso do repositório.
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.
A correção OCR melhorou a transcrição, especialmente em registros manuscritos e tabulares
A correção por reconhecimento óptico de caracteres melhorou a qualidade da transcrição em todas as oito classes de documentos arquivísticos (n = 1.600 registros). A média do WER diminuiu de 0,529 ± 0,172 para 0,384 ± 0,123, com uma variação média pareada de −0,144 (IC 95%, −0,149 a −0,139; Wilcoxon assinado - posto P < 0,001). A média da CER dimi...
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.
Esse protocolo demonstra que a descoberta em arquivos digitais históricos melhorou mais quando a correção de OCR, a compreensão visual de documentos e o enriquecimento conservador de metadados foram avaliados como componentes de recuperação conectados, em vez de atualizações técnicas isoladas. Os maiores ganhos em OCR ocorreram em materiais manuscritos, tabulares e de registro, apoiando o valor da correção pós-correção para classes de documentos onde o reconhecimento de linha de base é m...
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.
Os autores não têm nada a revelar.
Os autores agradecem sinceramente aos dois membros experientes da equipe de arquivos e ao pesquisador profissional de humanidades digitais pela valiosa assistência na anotação de texto e controle de qualidade. Essa pesquisa foi financiada pelo Plano de Projeto de Ciência e Tecnologia dos Arquivos Provinciais de Jiangsu (Grant No. 2024-9) para a construção de um sistema inteligente de arquivos orais baseados em fala, e pelo Plano Provincial de Desenvolvimento de Ciência e Tecnologia de Jiangsu para Medicina Tradicional Chinesa (Grant No. MS2025025) para estudar a herança e o desenvolvimento das escolas da MTC sob uma perspectiva arquivística.
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.
| Nome | Empresa | Número de catálogo | Comentários |
|---|---|---|---|
| Python | Python Software Foundation | v3.11.8; https://www.python.org/ | Scripting de fluxo de trabalho, processamento de dados, correção pós-ocorrência óptica de caracteres e suporte estatístico |
| R | R Foundation for Statistical Computing | v4.3.3; https://www.r-project.org/ | Análise estatística e geração de figuras finais |
| Tesseract OCR | Tesseract OCR Project | v5.3.0; https://github.com/tesseract-ocr/tesseract | Geração de reconhecimento óptico de caracteres base |
| Pacotes de idiomas Tesseract | Tesseract OCR Project | Pacotes de idiomas específicos do estudo; https://github.com/tesseract-ocr/tessdata | Decodificação primária e mista de reconhecimento óptico de caracteres |
| OpenCV | OpenCV Team | v4.9.0; https://opencv.org/ | Desviação, estimativa de ruído e pré-processamento de imagem |
| Pillow | Python Imaging Library contributors | v10.3.0; https://python-pillow.org/ | Entrada/saída de imagem e normalização de formato |
| NumPy | NumPy developers | v1.26.4; https://numpy.org/ | Computação de matriz para processamento de imagens e métricas |
| pandas | pandas development team | v2.2.2; https://pandas.pydata.org/ | Manuseio de dados tabulares e exportações de resumo |
| SciPy | SciPy developers | v1.13.1; https://scipy.org/ | Testes estatísticos e utilitários numéricos |
| statsmodels | statsmodels developers | v0.14.2; https://www.statsmodels.org/ | Modelagem estatística e suporte de comparação emparelhada |
| scikit-learn | scikit-learn developers | v1.4.2; https://scikit-learn.org/ | Métricas de classificação, diagnósticos ROC/PR e utilitários de validação |
| rapidfuzz | Max Bachmann and contributors | v3.9.0; https://github.com/rapidfuzz/RapidFuzz | Classificação de candidatos por distância de edição para correção de reconhecimento óptico de caracteres |
| spaCy | Explosion AI | v3.7.4; https://spacy.io/ | Processamento de entidades nomeadas com tabelas de léxico personalizadas |
| PyTorch | PyTorch Foundation | v2.2.2; https://pytorch.org/ | Treinamento de classificador de documentos visuais |
| torchvision | PyTorch Foundation | v0.17.2; https://pytorch.org/vision/ | Implementação EfficientNet-B3 e transformações de imagem |
| Backbone EfficientNet-B3 | torchvision / Imagens predefinidas do ImageNet | EfficientNet-B3; https://pytorch.org/vision/stable/models/efficientnet.html | Backbone para classificação de documentos visuais |
| sentence-transformers | UKP Lab / Hugging Face ecosystem | v2.7.0; https://www.sbert.net/ | Expansão semântica para candidatos de vocabulário controlado |
| Software de mecanismo de busca | Elastic | Elasticsearch v8.11.1; https://www.elastic.co/elasticsearch | Indexação, recuperação e classificação BM25 |
| Motor de contêiner | Docker Inc. | Docker v26.1.1; https://www.docker.com/ | Ambiente de recuperação em contêiner |
| Sistema operacional Linux | Canonical | Ubuntu 22.04 LTS; https://ubuntu.com/ | Ambiente operacional fixo para execuções de recuperação |
| Sistema de controle de versão | Git project | Git v2.44.0; https://git-scm.com/ | Controle de versão para configuração, vocabulários, scripts e código de figuras |
| ggplot2 | tidyverse | v3.5.1; https://ggplot2.tidyverse.org/ | Renderização de figuras baseada em R |
| Matplotlib | Matplotlib developers | v3.8.4; https://matplotlib.org/ | Visualizações suplementares e gráficos de garantia de qualidade |
| Diretriz de anotação | Autores | 5 seções de anotação; 8 rótulos de classe de documento; regiões de OCR; rótulos de entidade; julgamentos de relevância; regras de adjudicação | Definições para classes de documento, regiões de OCR, entidades, julgamentos de relevância e adjudicação |
| Lexicon OCR específico do arquivo | Autores | 6 categorias de léxico: variantes de pessoa, nomes de lugares, nomes de instituições, padrões de data, termos administrativos, abreviações | Nomes, lugares, instituições, termos administrativos e variantes ortográficas |
| Mapeamento de vocabulário controlado | Autores / repositórios de arquivo | 5 regras de mapeamento ligando entidades OCR, classe visual, palavras-chave do título, cobertura de data e tópico da consulta a campos de metadados | Correspondência de cabeçalhos de assunto e expansão semântica |
| Conjunto de consulta de referência | Autores | 420 consultas de referência; 6 tópicos de consulta; 3 níveis de dificuldade; 8 classes de documentos-alvo; 4 períodos históricos; 6 contextos linguísticos | Benchmark de recuperação correspondido em cinco braços do sistema |
| Julgamentos de relevância | Autores / anotadores | 2.100 linhas de consulta-sistema; 420 consultas x 5 braços do sistema; totais relevantes, contagens de relevantes-no-top-10, relevância classificada e sinalizadores de sucesso | Surrogato de verdade para P@10, R@10, nDCG@10 e taxa de busca bem-sucedida |
| Diagnósticos de treinamento | Autores | 20 épocas; perda de treinamento; perda de validação; precisão de treinamento; precisão de validação; macro-F1; F1 ponderado; ROC-AUC; PR-AUC | Resumos de diagnóstico do modelo em nível de época |
| Hardware computacional | Autores | 8 núcleos de CPU; 32 GB de RAM; ambiente de treinamento com GPU da classe NVIDIA | Detalhes de recursos de reprodutibilidade para submissão JoVE |
| Arquivo de conjunto de dados | Autores | data.xlsx; 1.600 registros; 17 variáveis; DOI listado na disponibilidade de dados do manuscrito | Dados de origem em nível de registro para análises de reconhecimento óptico de caracteres, completude de metadados, descoberta e classificação visual |
Acesso restrito. Inicie sessão ou comece um teste para visualizar este conteúdo.