Aller au contenu
Nyshporka Se connecter

Nyshporka 0.24.0 : de nouveaux modèles pour les manuscrits des XVIIIe et XIXe siècles

v0.24.0

La version 0.24.0 met à jour les trois modèles de reconnaissance de l'écriture manuscrite. Dans les registres paroissiaux du XVIIIe siècle, le nom de famille tombe dans le bon acte six fois plus souvent qu'avec la version précédente. Dans la cursive de chancellerie polonaise, les caractères erronés sont 38 % moins nombreux, et les mots lus sans aucune erreur 1,6 fois plus nombreux. La vitesse de traitement d'un dossier sur une seule carte Tesla V100 n'a pratiquement pas changé ; en mode cloud, sur deux de ces cartes, elle a augmenté d'environ 70 %.

Ce qui a changé

  • Pysar (cyrillique, modèle principal) — version 19. Entraîné avec des annotations manuelles supplémentaires de registres paroissiaux du XVIIIe siècle.
  • Diak-Litopysets (cyrillique, deuxième modèle) — nouvelle génération de Diak, sur la base ouverte PP-OCRv6.
  • Skryba PPv3 (écriture latine : cursive polonaise et latine) — nouveau modèle sur la même base, entraîné sur 28 écritures.

Nouveau moteur kraken 7.1

Les nouveaux modèles reposent sur une autre architecture (PP-OCRv6), qui ne fonctionne correctement qu'avec kraken 7.1. Cette mise à jour est donc plus importante que d'habitude : après nysh update, il faut aussi mettre à jour le moteur de lecture lui-même (nysh htr install).

Dans Nyshporka, kraken est modifié : six correctifs de vitesse, vérifiés sur la nouvelle version, maintiennent le traitement d'un dossier sur une seule carte Tesla V100 au niveau précédent, et l'écriture latine est lue presque deux fois plus vite sur la même carte. Le découpage des pages en lignes calculé par l'ancienne version est lu par la nouvelle sans être recalculé.

Qualité de la reconnaissance

Les versions précédente et nouvelle ont été comparées sur les mêmes pages, sur la même machine, avec une nouvelle reconnaissance à partir de zéro.

Matériau et mesure Avant Après
Registres paroissiaux du XVIIIe s. (ЦДІАК, fonds 224, 657 actes) : nom de famille dans le bon acte, au-delà du hasard 0,038 0,231
Idem, prénom 0,142 0,317
Notariat polonais (ДАВіО, fonds 792, lignes hors entraînement) : part de caractères erronés 20,9 % 12,9 %
Idem : mots lus sans aucune erreur 27,4 % 45,0 %
Procès-verbal de l'Assemblée de la noblesse de Podolie, 1802 (écriture hors entraînement) : part de caractères erronés 32,5 % 26,5 %
Registres paroissiaux du XIXe s. (2808 noms de famille de l'ensemble de référence) : trouvés 54,9 % 55,2 %
Recherche d'une famille précise sur 72 pages de registres du XIXe s. : pages trouvées par les deux modèles ensemble 65 64

« Au-delà du hasard » : part des actes où le nom de famille du relevé manuel est trouvé dans le même acte du texte reconnu, déduction faite des correspondances que donnerait une page prise au hasard. La référence : les regestes manuels de la chercheuse, établis indépendamment de la reconnaissance.

Sur les registres du XIXe siècle, la qualité reste au niveau précédent. Le deuxième modèle, Diak-Litopysets, confond moins souvent le nom recherché avec le nom semblable d'une famille voisine : sur les pages de contrôle, une erreur de ce type contre quatre.

Vitesse et coût

Mode Avant Après
Dossier complet sur une seule carte Tesla V100 (271 pages, toutes les étapes, un seul processus) 1871 s 1918 s
Écriture latine : reconnaissance d'une page, Tesla V100 1,86 s 0,99 s
Cloud, machine à deux cartes Tesla V100 (16 Go) : pages par heure, cyrillique, dossier de 606 p. ≈ 4600 ≈ 8000
Cloud, même machine (location 0,244 $/h) : coût de mille pages, cyrillique ≈ 0,05 $ ≈ 0,03 $

Les nouveaux modèles cyrilliques sont plus gros, mais l'étape la plus longue du traitement d'une page — la détection des lignes — n'a pas changé ; un dossier complet est donc traité sur une seule carte Tesla V100 pratiquement à la même vitesse (+2,5 %). En mode cloud, la nouvelle version fait tenir deux fois plus de processus parallèles sur une carte. Pour les dossiers mêlant écritures cyrillique et latine, où les trois modèles travaillent, la vitesse sur la même machine à deux cartes Tesla V100 (16 Go) est d'environ 5000 pages par heure.

Sans carte graphique

Processeur Intel Core i7-9750H (6 cœurs), page dense (~128 lignes), secondes par page :

Mode Avant Après
Cyrillique, deux modèles ≈ 46 ≈ 57 (+24 %)
Cyrillique, un seul modèle (--one-voice) ≈ 42 ≈ 42
Écriture latine ≈ 18 ≈ 29 (+60 %)
Dossier de 600 pages en cyrillique, deux modèles ≈ 7,7 h ≈ 9,5 h

Le ralentissement ne concerne que le processeur : sur une carte Tesla V100, l'écriture latine est au contraire lue presque deux fois plus vite. Un gros dossier se lit plus vite dans le cloud (nysh cloud go).

Sur quoi les modèles ont été entraînés

  • Annotation manuelle des lignes de registres paroissiaux du XVIIIe siècle (ЦДІАК, fonds 224, et d'autres dossiers).
  • Pour l'écriture latine — 28 écritures : registres notariaux du ДАВіО, fonds 792 ; registres du tribunal castral (grodzki) de la voïvodie de Kyiv (ЦДІАК, fonds 2) ; procès-verbaux de l'Assemblée de la noblesse de Podolie (ДАХмО, fonds 230) ; listes d'âmes du doyenné de Chechelnyk (ДАК, fonds 312) ; registres paroissiaux d'une église catholique romaine (fonds 685) ; ainsi qu'un corpus ouvert d'actes notariés néerlandais du XIXe siècle.
  • La base des nouveaux modèles est PP-OCRv6 medium (Benjamin Kiessling, Inria ; Zenodo, DOI 10.5281/zenodo.21788410), licence Apache-2.0.

Limites

  • Sur les registres paroissiaux de la seconde moitié du XIXe siècle, Pysar v19 trouve les noms de famille environ 1 point de pourcentage moins souvent que la version précédente.
  • Certains tests sont petits (143 lignes en écriture latine ; une page du procès-verbal de 1802) : des écarts de 1–2 points n'y sont donc pas significatifs. Les principaux changements (six fois mieux sur les noms du XVIIIe siècle, 38 % d'erreurs en moins en écriture latine) dépassent largement cette marge d'erreur.
  • Pour les petits dossiers (jusqu'à 100 pages), la vitesse dans le cloud sur une machine à deux cartes Tesla V100 est plus faible, environ 2000 pages par heure, à cause du temps de démarrage de chaque dossier.

Autres changements de la version

Moins d'espace disque

La bibliothèque torch n'est plus installée deux fois — à côté de l'application et dans le moteur de lecture. Elle ne se trouve plus que dans le moteur ; sous Linux, cela libère plusieurs gigaoctets.

Cloud

  • Un lot de dossiers se prépare en quelques minutes. Pour choisir la machine, Nyshporka estime combien de lignes compte une page d'un dossier non lu. Pour un lot, cette estimation est désormais tirée des dossiers déjà lus du même inventaire — 0,3 s au lieu de ~85 s par dossier. Un lot de 25 registres paroissiaux d'un même inventaire passait auparavant 35 min sur cette estimation, sur 50 min de préparation.
  • Une segmentation déjà faite n'est pas recalculée. La reprise d'un dossier, une relance après une coupure ou un nouveau modèle dans le même répertoire reprennent la segmentation de la lecture précédente.
  • On voit quels dossiers ne sont pas partis. La sortie du lot affiche « N dossiers sur M partiront » et la raison pour chaque dossier écarté.

Téléchargements

  • Un téléchargement interrompu reprend là où il s'est arrêté, au lieu de recommencer à zéro.
  • Face à une limitation de la fréquence des requêtes (429), Nyshporka attend exactement le temps demandé par le serveur.
  • Un fichier de Wikimedia Commons est vérifié avec sa somme de contrôle SHA-1.

Supriaha

  • Si un dossier se trouve dans Supriaha en plusieurs paquets, Nyshporka prend celui qui a été lu par les modèles en service les plus récents ; à défaut, par les précédents ; à égalité, le plus récent.
  • Nouveaux genres de fiches : registre paroissial complet et incomplet, enquêtes prénuptiales, ouvrages de référence (almanachs d'adresses, livres commémoratifs), dossiers judiciaires, dossiers de condition sociale (noblesse, livres généalogiques), visites pastorales, inventaires de domaines, recensements, états de service.
  • Un échec isolé de connexion au stockage n'est plus considéré comme un blocage : Nyshporka réessaie.
  • Si un répertoire ne contient qu'une partie des images d'un dossier, l'empaquetage demande le nombre d'images du dossier complet. Auparavant, une fiche pouvait afficher une couverture supérieure à 100 %.

Questions et réponses

Pourquoi publier de nouveaux modèles si l'ancien texte est utilisable ?

L'ancien texte est utilisable, il n'a aucun défaut. De nouveaux modèles sortent parce qu'un texte plus exact rend la recherche moins coûteuse et plus précise.

L'assistant qui recherche une famille dans les textes lus doit passer en revue les candidats et écarter les fausses correspondances. Plus le texte contient d'erreurs, plus il y a de contexte à examiner et à écarter. Un modèle plus exact donne moins de faux candidats : l'assistant trouve plus vite le bon endroit, dépense moins de tokens et laisse moins souvent passer quelque chose.

Dès maintenant, nous laissons peu de choses de côté, mais chaque nouveau modèle réduit encore cette part. De nouveaux modèles continueront de sortir.

Les dossiers et contributions lus par les anciens modèles ont-ils de la valeur ?

Oui. La recherche fonctionne sur le texte de n'importe quel modèle : les rapports quotidiens de recherche de familles que nous examinons donnent des trouvailles aussi sur des dossiers lus par des versions précédentes. Chaque trouvaille est vérifiée à l'œil sur l'image ; l'exactitude du modèle influe donc sur la quantité de travail avant la trouvaille, et non sur la confiance qu'on peut lui accorder.

C'est pourquoi vos contributions à Supriaha sont utiles dès maintenant, avec les modèles existants. Nous continuons à lire les dossiers avec les modèles disponibles ; quand de plus récents sortiront, on pourra relire la partie où cela en vaut la peine.

Le travail accompli n'est pas perdu non plus lors d'une relecture : le découpage des pages en lignes — la partie la plus longue de la lecture — est repris du cache, et les nouveaux modèles lisent les mêmes lignes.

Faut-il maintenant relire tous les dossiers déjà lus ?

Non. Tout ce qui a été lu reste dans la recherche et ne devient pas obsolète.

La relecture n'est utile que là où l'on veut tirer le maximum de la recherche à moindre coût : registres paroissiaux du XVIIIe siècle, dossiers latins et mixtes, ainsi que les dossiers où la recherche de la famille n'a rien trouvé. Sur les registres du XIXe siècle, la qualité est presque la même (55,2 % contre 54,9 % de noms trouvés) ; il n'est donc pas nécessaire de les relire pour les nouveaux modèles.

La relecture coûte moins cher que la première lecture : le découpage des pages en lignes déjà fait est repris du cache. Sur une seule carte Tesla V100, il occupe la plus grande partie du temps d'une page (5,5 s sur 8,9 s) ; la relecture est donc environ deux à trois fois plus rapide. Il suffit de relancer nysh read pour le dossier — les nouveaux modèles seront pris en compte d'eux-mêmes ; dans le cloud, nysh cloud go reprend automatiquement le découpage existant.

Peut-on rester sur les anciens modèles ?

Oui. Les anciens poids restent sur le disque : tant que les nouveaux ne sont pas téléchargés (nysh models get), Nyshporka lit avec eux, et dès que les nouveaux apparaissent, elle prend les plus récents en service. N'importe quel dossier peut être lu avec un modèle nommé explicitement : nysh read <справа> --model pysar_cyr_v17.pt.

Après la mise à jour de Nyshporka elle-même, il faut mettre à jour le moteur de lecture (nysh htr install) : sans cela, la lecture ne démarrera pas. Les anciens modèles fonctionnent sur le moteur mis à jour comme avant.

Quel texte Nyshporka prend-elle dans Supriaha ?

Si un dossier se trouve dans Supriaha en plusieurs paquets, Nyshporka prend celui qui a été lu par les modèles en service les plus récents ; à défaut, par les précédents ; à égalité, le plus récent. Il en va de même pour un seul dossier que pour un fonds ou un inventaire entier. À côté de chaque dossier, le catalogue indique par quels modèles il a été lu. Un dossier reçu arrive avec toutes ses lectures (voix), et la recherche porte sur toutes.

Si un dossier a déjà été pris et qu'un paquet du même dossier, lu par des modèles plus récents, apparaît dans le catalogue, on peut remplacer celui qui a été pris avec la commande nysh share pull … --force.

Pour ceux qui mettent à jour depuis une version antérieure à 0.22 : transfert du suivi des dossiers

Si vous mettez à jour depuis une version antérieure à 0.22, la mise à jour comprend le transfert du suivi des dossiers vers de nouvelles clés. C'est la seule étape qui modifie vos données ; elle mérite donc d'être faite avec attention.

La clé de chaque dossier contient désormais toujours l'inventaire : REPO/фонд/опис/справа, par exemple DAHMO/315/1/8433. Si l'inventaire est inconnu, _ le remplace. Auparavant, l'inventaire ne faisait partie de la clé que pour certains fonds, et deux registres portant le même numéro dans des inventaires différents (par exemple ДАДнО 193-1-213 et 193-3-213) avaient une seule clé.

Sont transférés : le stockage des pages, les liaisons des lectures, les verdicts sur les dossiers et les lignes, le journal de recherche, les fiches Supriaha, la file d'attente des dossiers et les profils de relecture.

Marche à suivre

  1. Arrêtez les autres sessions et les processus en arrière-plan qui écrivent dans le suivi. Tant qu'ils tournent, le transfert ne démarrera pas.
  2. Consultez le plan : nysh cases rekey. Il montre ce qui sera renommé, ce qui sera fusionné et ce qui ne pourra pas être transféré.
  3. Vérifiez les fusions. Si un même dossier avait des verdicts sous deux anciennes clés, le plus récent devient valable, et l'autre est conservé à côté comme remplacé.
  4. Lancez le transfert : nysh cases rekey --apply. Avant toute modification, une archive est créée dans data/cases/rekey/<час>/ ; une panne en cours de route remet l'espace de travail dans son état antérieur.
  5. Pour les dossiers dont l'inventaire est inconnu (_), ajoutez l'inventaire dans le passeport (nysh case <тека> --shifra "…") et relancez nysh cases rekey --apply.

À savoir

  • Avant le transfert, la lecture et la recherche fonctionnent, mais l'écriture dans le suivi est refusée avec l'indication de la commande à lancer.
  • Retour en arrière : nysh cases rekey --rollback. Si le suivi a déjà changé après le transfert, le retour en arrière est refusé avec la liste des fichiers modifiés ; --rollback --force — uniquement en connaissance de cause.
  • Les anciennes clés dans les notes et les messages mènent toujours à leur dossier grâce à la table de correspondance (data/cases/key_moves.json).

Comment mettre à jour

Après nysh update, deux commandes sont nécessaires : nysh htr install (met à jour le moteur de lecture sur place) et nysh models get (les nouveaux poids, environ 225 Mo). Nyshporka lit d'elle-même avec les modèles en service les plus récents s'ils sont sur le disque ; s'ils ne sont pas encore téléchargés, avec les précédents. Il n'y a rien à basculer à la main.

Comment la comparaison a été faite

Les deux versions ont traité les mêmes 271 pages sur une même machine louée équipée d'une carte Tesla V100, sans autre processus ; chaque page a été reconnue à partir de zéro. La vitesse dans le cloud a été mesurée séparément sur une machine à deux cartes V100, sur un dossier de 606 pages. Les pages utilisées pour l'entraînement des modèles ont été exclues de la comparaison. Mesures sur processeur : Intel Core i7-9750H, trois pages denses de ДАК 312-1-27.

Autres mises à jour