Nyshporka 0.24.0: nowe modele do rękopisów z XVIII–XIX wieku

Wersja 0.24.0 aktualizuje wszystkie trzy modele rozpoznawania pisma ręcznego. W księgach metrykalnych z XVIII wieku nazwisko trafia do właściwego wpisu sześć razy częściej niż w poprzedniej wersji. W polskiej kursywie kancelaryjnej błędnych znaków jest o 38% mniej, a słów odczytanych bez żadnego błędu — 1,6 raza więcej. Szybkość przetwarzania jednostki na jednej karcie graficznej Tesla V100 praktycznie się nie zmieniła, a w trybie chmurowym na dwóch takich kartach wzrosła o około 70%.

Co się zmieniło

• Pysar (cyrylica, model główny) — wersja 19. Wytrenowany z dodatkowymi ręcznie oznaczonymi wierszami metryk z XVIII w.
• Diak-Litopysets (cyrylica, drugi model) — nowa generacja modelu Diak na otwartej podstawie PP-OCRv6.
• Skryba PPv3 (alfabet łaciński: kursywa polska i łacińska) — nowy model na tej samej podstawie, wytrenowany na 28 charakterach pisma.

Nowy silnik kraken 7.1

Nowe modele zbudowano na innej architekturze (PP-OCRv6), która działa poprawnie tylko na kraken 7.1. Dlatego ta aktualizacja jest większa niż zwykle: po nysh update trzeba zaktualizować także sam silnik odczytu (nysh htr install).

Kraken w Nyshporce jest załatany: sześć poprawek szybkości, sprawdzonych na nowej wersji, utrzymuje przetwarzanie jednostki na jednej karcie Tesla V100 na dotychczasowym poziomie, a alfabet łaciński na tej samej karcie jest odczytywany prawie dwa razy szybciej. Podział stron na wiersze obliczony przez starą wersję nowa odczytuje bez ponownego liczenia.

Jakość rozpoznawania

Poprzednią i nową wersję porównano na tych samych stronach, na tym samym komputerze, z ponownym rozpoznaniem od zera.

„Ponad przypadkową zbieżność” — odsetek wpisów, w których nazwisko z ręcznego rejestru odnaleziono w tym samym wpisie rozpoznanego tekstu, po odjęciu zbieżności, jakie dałaby przypadkowa strona. Wzorzec — ręczne regesty badaczki, sporządzone niezależnie od rozpoznawania.

W księgach z XIX wieku jakość pozostała na dotychczasowym poziomie. Drugi model, Diak-Litopysets, rzadziej myli szukane nazwisko z podobnym nazwiskiem sąsiedniej rodziny: na stronach kontrolnych takich błędów był jeden wobec czterech.

Szybkość i koszt

Nowe modele cyrylickie są większe, ale najdłuższy etap przetwarzania strony — wykrywanie wierszy — się nie zmienił, więc cała jednostka na jednej karcie Tesla V100 jest przetwarzana praktycznie z tą samą szybkością (+2,5%). W trybie chmurowym nowa wersja mieści na karcie dwa razy więcej równoległych procesów. Dla jednostek z mieszanym pismem cyrylickim i łacińskim, gdzie pracują wszystkie trzy modele, na tym samym komputerze z dwiema kartami Tesla V100 (16 GB) szybkość wynosi około 5000 stron na godzinę.

Bez karty graficznej

Procesor Intel Core i7-9750H (6 rdzeni), gęsta strona (~128 wierszy), sekund na stronę:

Spowolnienie dotyczy tylko procesora: na karcie Tesla V100 alfabet łaciński jest, przeciwnie, odczytywany prawie dwa razy szybciej. Dużą jednostkę szybciej odczytać w chmurze (nysh cloud go).

Na czym wytrenowano

• Ręcznie oznaczone wiersze ksiąg metrykalnych z XVIII w. (ЦДІАК, zesp. 224 i inne jednostki).
• Dla alfabetu łacińskiego — 28 charakterów pisma: księgi notarialne ДАВіО, zesp. 792, księgi grodzkie województwa kijowskiego (ЦДІАК, zesp. 2), protokoły Podolskiego Zgromadzenia Szlacheckiego (ДАХмО, zesp. 230), spisy dusz dekanatu czeczelnickiego (ДАК, zesp. 312), metryki kościoła rzymskokatolickiego (zesp. 685), a także otwarty korpus holenderskich aktów notarialnych z XIX w.
• Podstawa nowych modeli — PP-OCRv6 medium (Benjamin Kiessling, Inria; Zenodo, DOI 10.5281/zenodo.21788410), licencja Apache-2.0.

Ograniczenia

• W metrykach z drugiej połowy XIX w. Pysar v19 odnajduje nazwiska o około 1 punkt procentowy rzadziej niż poprzednia wersja.
• Niektóre testy są niewielkie (143 wiersze alfabetu łacińskiego; jedna strona protokołu z 1802 r.), więc różnice rzędu 1–2 punktów nie są na nich istotne. Główne zmiany (sześciokrotnie na nazwiskach z XVIII w., o 38% mniej błędów w alfabecie łacińskim) znacznie przekraczają ten błąd pomiaru.
• Dla małych jednostek (do 100 stron) szybkość w chmurze na komputerze z dwiema kartami Tesla V100 jest niższa, około 2000 stron na godzinę, z powodu czasu uruchamiania każdej jednostki.

Inne zmiany w wersji

Mniej miejsca na dysku

Biblioteka torch nie jest już instalowana dwa razy — obok aplikacji i w silniku odczytu. Teraz jest tylko w silniku; na Linuksie zwalnia to kilka gigabajtów.

Chmura

• Partia jednostek przygotowuje się w kilka minut. Aby wybrać komputer, Nyshporka szacuje, ile wierszy jest na stronie nieodczytanej jednostki. Teraz dla partii to oszacowanie bierze się z już odczytanych jednostek tego samego inwentarza — 0,3 s zamiast ~85 s na jednostkę. Partia 25 metryk z jednego inwentarza stała wcześniej na tym oszacowaniu 35 min z 50 min przygotowań.
• Gotowa segmentacja nie jest liczona drugi raz. Dokończenie jednostki, powtórka po przerwaniu czy nowy model w tym samym folderze biorą segmentację z poprzedniego odczytu.
• Widać, które jednostki nie pojechały. Wynik partii wypisuje «поїде N з M справ» (pojedzie N z M jednostek) i przyczynę dla każdej jednostki, która odpadła.

Pobieranie

• Przerwane pobieranie wznawia się od miejsca przerwania, a nie zaczyna od zera.
• Przy ograniczeniu częstotliwości zapytań (429) Nyshporka czeka dokładnie tyle, ile prosi serwer.
• Plik z Wikimedia Commons jest sprawdzany sumą kontrolną SHA-1.

Supriaha

• Jeśli jednostka leży w serwisie Supriaha w kilku pakietach, Nyshporka bierze ten, który odczytano najnowszymi modelami produkcyjnymi; jeśli takiego nie ma — poprzednimi; spośród równych — najświeższy.
• Nowe rodzaje dokumentów na kartach: księga metrykalna pełna i niepełna, protokoły przedślubne, wydawnictwa informacyjne (kalendarze adresowe, księgi pamiątkowe), sprawy sądowe, sprawy stanowe (szlachectwo, księgi genealogiczne), wizytacje, inwentarze dóbr, spisy ludności, listy służbowe.
• Pojedyncza odmowa połączenia z magazynem nie jest już uznawana za blokadę: Nyshporka próbuje jeszcze raz.
• Jeśli w folderze leży tylko część skanów jednostki, pakowanie prosi o podanie liczby skanów całej jednostki. Wcześniej karta mogła pokazać pokrycie powyżej 100%.

Pytania i odpowiedzi

Po co wydawać nowe modele, skoro stary tekst się nadaje?

Stary tekst się nadaje, wszystko z nim w porządku. Nowe modele powstają, bo dokładniejszy tekst sprawia, że wyszukiwanie jest tańsze i dokładniejsze.

Asystent, który szuka rodu w odczytanym tekście, musi przejrzeć kandydatów i odrzucić fałszywe trafienia. Im więcej błędów w tekście, tym więcej kontekstu trzeba przejrzeć i odrzucić. Dokładniejszy model daje mniej fałszywych kandydatów: asystent szybciej znajduje właściwe miejsce, zużywa mniej tokenów i rzadziej coś pomija.

Pomijamy i teraz niewiele, ale każdy nowy model ten odsetek zmniejsza. Nowe modele będą się ukazywać nadal.

Czy jednostki i wkłady odczytane starymi modelami mają wartość?

Tak. Wyszukiwanie działa na tekście z każdego modelu: codzienne raporty z poszukiwania rodu, które analizujemy, dają znaleziska także w jednostkach odczytanych poprzednimi wersjami. Każde znalezisko sprawdza się wzrokiem na skanie, więc dokładność modelu wpływa na to, ile pracy dzieli od znaleziska, a nie na to, czy można mu wierzyć.

Dlatego Twoje wkłady do Supriahy są potrzebne już teraz, na modelach, które są. Jednostki odczytujemy dalej obecnymi modelami; gdy wyjdą nowsze, można odczytać ponownie tę część, gdzie jest to warte wysiłku.

Wykonana praca nie przepada też przy ponownym odczycie: podział stron na wiersze — najdłuższa część odczytu — bierze się z pamięci podręcznej, a nowe modele czytają te same wiersze.

Czy trzeba teraz odczytać od nowa wszystkie odczytane jednostki?

Nie. Wszystko, co odczytano, zostaje w wyszukiwaniu i się nie starzeje.

Ponowny odczyt jest potrzebny tylko tam, gdzie chcesz uzyskać jak największy efekt wyszukiwania mniejszym kosztem: metryki z XVIII w., jednostki łacińskie i mieszane, a także jednostki, w których poszukiwanie rodu niczego nie znalazło. W księgach z XIX w. jakość jest prawie taka sama (55,2% wobec 54,9% odnalezionych nazwisk), więc nie ma potrzeby odczytywać ich ponownie dla nowych modeli.

Ponowny odczyt jest tańszy niż pierwszy: gotowy podział stron na wiersze bierze się z pamięci podręcznej. Na jednej karcie Tesla V100 zajmuje on większą część czasu strony (5,5 s z 8,9 s), więc ponowny odczyt jest mniej więcej dwa–trzy razy szybszy. Wystarczy ponownie uruchomić nysh read dla jednostki — nowe modele włączą się same; w chmurze nysh cloud go bierze gotowy podział automatycznie.

Czy można zostać przy starych modelach?

Tak. Stare wagi zostają na dysku: dopóki nowe nie są pobrane (nysh models get), Nyshporka czyta nimi, a gdy tylko pojawią się nowe — bierze najnowsze modele produkcyjne. Każdą jednostkę można odczytać wprost wskazanym modelem: nysh read <справа> --model pysar_cyr_v17.pt.

Po aktualizacji samej Nyshporki trzeba zaktualizować silnik odczytu (nysh htr install): bez tego odczyt się nie uruchomi. Stare modele na zaktualizowanym silniku działają jak dotąd.

Jaki tekst Nyshporka bierze z Supriahy?

Jeśli jednostka leży w serwisie Supriaha w kilku pakietach, Nyshporka bierze ten, który odczytano najnowszymi modelami produkcyjnymi; jeśli takiego nie ma — poprzednimi; spośród równych — najświeższy. Tak samo dla jednej jednostki i dla całego zespołu czy inwentarza. Przy każdej jednostce w katalogu widać, jakimi modelami ją odczytano. Przyjęta jednostka przychodzi ze wszystkimi swoimi odczytami (głosami), a wyszukiwanie przechodzi przez wszystkie.

Jeśli jednostkę już pobrano, a w katalogu pojawił się pakiet tej samej jednostki odczytany nowszymi modelami, pobraną można zastąpić poleceniem nysh share pull … --force.

Dla aktualizujących z wersji sprzed 0.22: przeniesienie ewidencji jednostek

Jeśli aktualizujesz z wersji starszej niż 0.22, aktualizacja obejmuje przeniesienie ewidencji jednostek na nowe klucze. To jedyny krok, który zmienia Twoje dane, dlatego warto wykonać go uważnie.

W kluczu każdej jednostki jest teraz zawsze inwentarz: REPO/фонд/опис/справа, na przykład DAHMO/315/1/8433. Jeśli inwentarz jest nieznany, na jego miejscu stoi _. Wcześniej inwentarz wchodził do klucza tylko w części zespołów, a dwie księgi o tym samym numerze w różnych inwentarzach (na przykład ДАДнО 193-1-213 i 193-3-213) miały jeden klucz.

Przenoszone są: magazyn stron, powiązania odczytów, werdykty jednostek i wierszy, dziennik wyszukiwania, karty Supriahy, kolejka jednostek i profile korekty.

Kolejność działań

1. Zatrzymaj inne sesje i procesy w tle, które zapisują do ewidencji. Dopóki działają, przeniesienie się nie zacznie.
2. Obejrzyj plan: nysh cases rekey. Pokazuje, co zmieni nazwę, co się połączy i czego nie da się przenieść.
3. Sprawdź połączenia. Jeśli jedna jednostka miała werdykty pod dwoma starymi kluczami, obowiązującym stanie się późniejszy, a drugi zostanie zachowany obok jako zastąpiony.
4. Wykonaj przeniesienie: nysh cases rekey --apply. Przed zmianami tworzone jest archiwum w data/cases/rekey/<час>/; awaria w połowie przywraca przestrzeń roboczą do poprzedniego stanu.
5. Jednostkom z nieznanym inwentarzem (_) dopisz inwentarz w paszporcie (nysh case <тека> --shifra "…") i powtórz nysh cases rekey --apply.

Warto wiedzieć

• Przed przeniesieniem odczyt i wyszukiwanie działają, ale zapis do ewidencji jest odrzucany z podpowiedzią, jakie polecenie wykonać.
• Wycofanie — nysh cases rekey --rollback. Jeśli po przeniesieniu ewidencja już się zmieniała, wycofanie jest odrzucane z listą zmienionych plików; --rollback --force — tylko świadomie.
• Stare klucze w notatkach i wiadomościach nadal prowadzą do swojej jednostki przez mapę przeniesień (data/cases/key_moves.json).

Jak zaktualizować

Po nysh update potrzebne są dwa polecenia: nysh htr install (aktualizuje silnik odczytu na miejscu) i nysh models get (nowe wagi, około 225 MB). Nyshporka sama czyta najnowszymi modelami produkcyjnymi, jeśli są na dysku; jeśli jeszcze ich nie pobrano — poprzednimi. Niczego nie trzeba przełączać ręcznie.

Jak przeprowadzono porównanie

Obie wersje przetwarzały te same 271 stron na jednym wynajętym komputerze z kartą Tesla V100, bez innych procesów; każda strona była rozpoznawana od zera. Szybkość w chmurze zmierzono osobno na komputerze z dwiema kartami V100, na jednostce z 606 stron. Strony użyte do trenowania modeli wyłączono z porównania. Pomiary na procesorze — na Intel Core i7-9750H, trzy gęste strony ДАК 312-1-27.