Как мы превратили скан словаря ударений в машинный словарь

Зачем это вообще нужно

Коротко: без словаря имён с ударениями бот произносит фамилии наугад. Источников ударений у проекта и без того было много (accents_index.sqlite на 3,2 млн словоформ общего словаря и 119 тыс. имён, плюс silero-stress, RUAccent, properpouns), но имена собственные жили там отдельной маленькой вкладкой, а систематического русского словаря имён в открытом доступе до сих пор просто нет.

Качество синтеза здесь упирается в ударения напрямую: «Зе́леноград» и «Зеленогра́д» — это разные слова и для TTS, и для слушателя. Синтезатор без подсказки поставит ударение по правилам языка, а для фамилии это правило часто не то.

Конкретный источник: «Собственные имена в русском языке. Словарь ударений», изд. НЦ ЭНАС, 2001, 376 с., ~35 000 словарных единиц (Агеенко) — почти не используемый, и по причинам, названным выше.

Книга есть в виде DjVu-скана: 187 разворотов, 3241×2368 px @300 dpi, 4 МБ. Текстового слоя нет вообще — djvutxt возвращает 0 байт. То есть это честная OCR-задача, причём худший её вариант: словарь, где правильное написание каждой единицы — это её ударение.

Ниже — инженерный разбор того, как это было сделано и почему именно так.

Этап 0. Разведка: что вообще можно вытащить

Прежде чем писать пайплайн, мы проверили гипотезу «просто дать tesseract'у картинки» — в четырёх вариантах препроцессинга (как есть, оттенок серого, бинаризация по порогу, адаптивная бинаризация), с языками rus, rus+eng, моделью tessdata_best, --psm 6 и --psm 4.

Это не «трудный случай», это принципиальное ограничение: обучающая выборка tesseract не содержит размеченных ударений, и модель просто не предсказывает такой класс символов — даже когда штрих над гласной достаточно крупный. Проверялось и на увеличенных фрагментах: знаки в печати есть, они просто не переносятся в текст.

Отсюда архитектурное решение: OCR отвечает за буквы, компьютерное зрение — за знаки.

Второй важный вывод разведки: tesseract не просто «пропускает» ударение, он портит букву.

Это принципиально важно для дизайна: если знака ударения нет, восстановить букву нельзя — придётся гадать. Если знак есть (найден CV-детектором), букву восстановить можно: раз й оказалась в ячейке с акутом, значит это и́.

Именно поэтому порядок «OCR → починка» без CV-детектора принципиально хуже, чем «OCR → CV-детектор → починка».

Этап 1. Изображения: почему 300 dpi и почему развороты

DjVu в этом файле — это уже растр, а не векторная графика: ddjvu -format=tiff -page=N даёт картинку 3241×2368 px, 300 dpi. Апскейлить нечего, и это хорошо: качество максимально из доступного.

Разворот (2 печатные страницы) режется по центральному «жёлобу» — вертикальной полосе тени переплёта, которую видно на проекции яркости. Затем каждая страница режется на 2 колонки по белому просвету. Итого 187 разворотов → 742 колонки.

Почему колонки, а не страницы: словарь набирается в две колонки, строки в них короткие, а tesseract при работе с узкой колонкой (≈780 px шириной) ошибается заметно меньше, чем с полосой набора шириной 1600 px, где он «плывёт» по межсловным интервалам.

Колонки режутся жёстко, но с двумя страховками, потому что в развороте бывают поля с неравномерной версткой:

• белый просвет ищется в ограниченном диапазоне (центр страницы ±15 % ширины);
• если просвет не найден, колонка делится пополам по геометрии.

Этап 2. OCR и разбор TSV

tesseract <колонка> - -l rus+eng --psm 6 tsv

--psm 6 — «единый блок», для колонки это лучший режим: он не пытается искать «страницу», а разбирает её как один текстовый блок. TSV даёт по каждому слову: текст, уровень блока/абзаца/ строки, координаты и confidence — то самое число, которое нам потом пригодилось.

Мы не берём готовый текст, а разбираем TSV в собственную структуру: строки (по ключу block/par/line), токены с координатами и conf. Это принципиально: нам нужна не только строка текста, но и геометрия каждого слова — именно по ней потом распределяются знаки ударения.

Этап 3. Детектор знаков ударения (компьютерное зрение)

Это ядро всей работы. Задача: на бинарном изображении колонки найти все наклонные штрихи над гласными, отбросив всё остальное.

3.1. Бинаризация

mask = np.asarray(Image.open(path).convert("L")) < 170

Один глобальный порог. Соблазнительно взять адаптивную бинаризацию (Otsu по окну) — для качественного скан-копии это обычно выигрыш в читаемости, но здесь нам нужна не читаемость, а стабильная геометрия компонент: связность компоненты, её ширина и наклон. Адаптивный порог «съедает» тонкие штрихи над гласными у букв с высоким x-height и добавляет шум в просветлах, поэтому глобальный порог + несложная пост-фильтрация дают лучший результат именно для этой задачи.

3.2. Что считаем компонентой

labels, n = ndimage.label(mask, structure=np.ones((3, 3)))   # связность 8

Дальше по каждой компоненте считаем:

• h, w — bbox;
• area — число пикселей;
• ang — ориентацию главной оси через ковариационную матрицу:
  python

  ang = 0.5 * atan2(2·cov_xy, cov_xx − cov_yy)
  

• elong — отношение собственных значений (насколько компонента вытянута).

3.3. Какие параметры у настоящего акута

Собрали гистограммы по ~2800 найденным знакам на 10 страницах. У настоящего знака ударения:

Пороги в коде:

MIN_H, MAX_H = 4, 16
MIN_W, MAX_W = 4, 18
MIN_AREA, MAX_AREA = 18, 260
MIN_ELONG = 1.9
ANG_LO, ANG_HI = 22.0, 72.0
BODY_POS, BOTTOM_POS = 0.75, 0.80

MAX_H = 16 — ключевое число: высота строчной буквы 22–24 px, поэтому любая компонента выше 16 px — это не знак, а часть буквы. Это отсекает основной мусор «на уровне идеи», без всякой морфологии.

3.4. Три класса ложных срабатываний и как они лечатся

Ложные срабатывания были не случайными, а трех типов, и каждый лечится по-разному.

ox = min(x0 + w, lx1) - max(x0, lx0)
oy = min(y0 + h, ly1) - max(y0, ly0)
if ox > 0 and oy > 0 and ox * oy >= 0.35 * area:
    reject("inside_letter")

После этого число «знаков» упало с 2848 до ~2600 на тех же 35 колонках.

Тип 2: кавычки и апострофы. Узкие крутые штрихи (area ≈ 23, w = 7, |ang| ≈ 66°) — это двойные кавычки " в тексте передней части книги. Отсекаются связкой правил: крутой наклон и маленькая площадь.

not (abs(ang) > 48.0 and area < 30)

Тип 3: точки «ё». Самая интересная история, разбор ниже.

3.5. Главное открытие: точку «ё» нельзя отличить от акута

Первая версия детектора считала, что у знака ударения есть характерный наклон, и отбрасывала всё с наклоном близким к 90° (то есть почти вертикальное). Наивное «наклон вправо = акут» работало на 90 % мест и ломало всё остальное.

Разбор одного конкретного случая. Строка «Сён-Бернар»:

584 .....#####............      <- компонента 43–47
585 .....#####............
586 .....#######..........
587 #.....######..........
588 #......#######........
589 #........#####........
590 #..........##.........

Слева, в самой строке — не буква, а точка «ё» (диарезис) у слова «Сон». Мы её находили как знак ударения и превращали слово в «Се́н-Бернар».

Слово при этом то же самое: «Сен-Бернар» существует, и «Се́н-Бернар» — тот же самый Сен-Бернар. Ошибка не в слове, а в расстановке ударений. По Словарю географических названий зарубежных стран правильная форма — Сен-Берна́р, с ударением на втором слоге, так что знак встал не на ту букву, а получилась запись, которой в словаре ударений быть не может: у нас ключ включает позицию знака, то есть сенберна+р и се+нбернар — это два разных ключа для одного слова.

Здесь важно вот что: никакой проверки по смыслу такую ошибку не поймает. Слово-то правильное, ошибочна только разметка, а на слово любая смысловая проверка смотрит только как на набор букв. Для словаря, который про ударения, это уже поломанный словарный ключ — и в базе такой лежать не должен.

Чтобы понять, что это за штрих, мы увеличили фрагмент в 18 раз (ближайший соседний масштаб) и посмотрели глазами:

• акут — ровный наклонный штрих, по диагонали вверх-вправо, толщина 3–4 px;
• точка «ё» — короткий «штришок»/капля, толщина 5–6 px, часто с наклоном в другую сторону, чем у акута.

Дальше проверили ту же гипотезу на полной выборке и нашли два факта, которые сломали наивную модель:

1. У настоящих акутов наклон бывает разным. В строке «Мохе́нджо-Да́ро» один и тот же шрифт даёт акут над «е» с наклоном +39° и акут над «а» с наклоном −36°. Печать наклоняет знаки непоследовательно (вероятно, это ручная разметка/перенос в издательстве). Значит, знак наклона нельзя использовать как признак акута — ни «левый», ни «правый».
2. Диарезис «ё» состоит из двух точек, но видно обычно только одну. Вторая точка «съедает» верхнюю засечку соседней буквы и сливается с ней — то есть объединяется с компонентой буквы, и второй точки в списке компонент просто нет. Меняем мысль: раз «точка» осталась одна, надо смотреть не на форму, а на парность — искать рядом вторую компоненту того же размера в 8–17 px.

def has_dot_sibling(cand, dots):
    cx = cand["x"] + cand["w"] / 2
    cy = cand["y"] + cand["h"] / 2
    for (dx0, dy0, dx1, dy1) in dots:
        dcx, dcy = (dx0 + dx1) / 2, (dy0 + dy1) / 2
        gap = abs(dcx - cx) - cand["w"] / 2 - (dx1 - dx0) / 2
        if 8 <= gap <= 17 and abs(dcy - cy) <= 4:
            return True
    return False

3.6. Привязка знака к строке

Знаки и строки не лежат в одном координатном пространстве: строка tesseract может «раздуться» до высоты 50 px (склейка двух печатных строк), а знак над гласной стоит на 2–4 px выше её верха. Поэтому привязка делается по вертикали с допуском, а выбирается ближайшая строка:

cands = [i for i, b in enumerate(boxes) if b.y0 - 10 <= mcy <= b.y1]
best = min(cands, key=lambda i: abs(mcy - boxes[i].y0))

Первая версия использовала окно [y0-2, y1+2], и на строке «ГИЛЬБЕРТ» знак уезжал на предыдущую строку «Ги́лфорд». Смягчение окна до [y0-10, y1] с выбором по минимальному abs(cy - y0) дало 2848/2848 знаков привязано, 0 потерянных.

3.7. Привязка знака к букве внутри слова

Внутри слова знак распределяется по буквам пропорционально делению (это важно: в издательском наборе ширина букв разная, но близкая к равномерной для кириллицы):

p = (mark_cx - tok.x) / tok.w
idx = min(max(int(p * len(tok.text)), 0), len(tok.text) - 1)

Почему не по центру первой буквы и не «ближайшая гласная»: для многосложных слов вроде «Гине́йфа» или «А́ле́кси-Ме́схисхви́ли» реальные позиции ударений — это 3–5, и любое упрощение даёт систематический сдвиг.

Здесь же применяются правила починки букв (см. этап 4).

3.8. Итог по этапу

Для каждой колонки получаем accents.json — список знаков с координатами и метриками. На всей книге: 742 колонки, 57 741 знак ударения, 0 потерянных при привязке к строкам, 58 % признаков отбраковано фильтрами.

Этап 4. Починка букв: почему порядок «детект → починка» обязателен

После того как знаки найдены, OCR-ошибки чинятся точечно:

Статистика по всей книге: й→и́ 7 939, е́→ё 9 472, о́→б 6 287, а́→& 433.

Почему только при наличии знака? Без этого условия починка превращается в угадывание: й в слове может быть настоящей й (Гайд, Йошикава), ё — настоящей ё (Гёте), б — настоящей б. Наличие/отсутствие знака в этой ячейке — единственная доступная нам улика.

Отдельная тонкость: caps-кириллица, прочитанная латиницей, восстанавливается только для полностью прописных токенов. Мы пробовали и для смешанного регистра, но в передней части книги латинские имена (Aalto, Bing, Ape) набраны смешанным регистром, и транслитерация превращала Aalto → Аалто. Для прописных токенов риска нет: в словаре имён латиница в прописном виде не встречается, а настоящие КАПС-имена всегда кириллические.

Этап 5. Авто-фильтр: что нести на «дорогую» проверку

Очевидная идея — отдать всё подряд LLM-верификации. Практика показала, что это и дорого, и избыточно: 93 % токенов заведомо верны, а «LLM проверяет всё» — это и деньги, и риск внести ошибку в 93 % правильных мест (мы это наблюдали в реальности, см. этап 6).

Поэтому мы построили детерминированный фильтр с приоритетами, и он на удивление хорошо работает: recall по строкам 84–100 % (измерено против полной LLM-проверки на двух колонках), при 38 % отмеченных токенов.

Причины и их логика:

Отдельно стоит сказать про low_conf: 41 % отмеченных токенов — это «tesseract неуверен», и правок там почти нет (буква уже исправлена, знак уже поставлен). Мы оставили их последними в очереди, потому что это самый дешёвый по качеству и самый дорогой по объёму класс.

Этап 6. LLM-верификация по кропам: главный трюк — не доверять, а сверять

6.1. Как выглядит вход

Для NN-этапа нужны картинки конкретных строк. Строим их так, чтобы у модели не было физической возможности «додумать»:

1. crops/{col}/line_{y}.png — кроп строки целиком: в первом проходе это правильное решение, модель должна видеть контекст, иначе она начинает угадывать по смыслу. Но для аудита конкретной правки кроп строки опасен — модель отвечает про соседнюю статью (см. 6.5), и там нужен кроп одного токена с полосой над знаком ударения.
2. Склеиваем кропы в листы по 6 строк вертикально (это 100 токенов в 17 листах вместо 100 отдельных картинок — почти в 6 раз меньше вызовов инструментов).
3. Увеличиваем ×2 с LANCZOS. Это важнее, чем кажется: на родном масштабе тонкий знак над «і» в слове «ЛІ́ММТЕД» не виден — мы сами ошиблись, приняв корректное слово за ошибку. После увеличения всё читается.

Промпт — короткий и жёсткий по «правилам игры»:

Не нормализуй: в источнике бывают двойные ударения («Се́н-Берна́р») и необычные формы — воспроизводи печать, а не «правильную» орфографию. Не додумывай: неуверен — «ok», не добавляй букв. Проверяй только перечисленные токены. yo_mark: на ё/Ё встал знак — либо в печати «е́», либо это точки «ё».

Формулировка «не нормализуй» появилась после первого же прогона, где модель массово «исправляла» печать по смыслу: превращала «СЁН-ЖЮ́СТ» в «СЁН-ЖЮ́ОСТ» (добавляла букву), «Сён-Лоре́на» — в «Сён-Лора́на» (по русской норме, а в печати так), «Се́н-Берна́р» — в «Сен-Берна́р» (убирала двойное ударение из печати). Это не «ошибки OCR», это порча источника.

6.2. Опечатка издания vs ошибка OCR: где проходит граница

Самая интересная развилка во всём пайплайне — это не техническая, а смысловая. Источник 2001 года содержит собственные опечатки, и их нельзя смешивать с нашими ошибками распознавания.

Конкретный случай, статья «БАРБАДОС», колонка p018_Rc2:

Барба́дос ре́дфьюжн се́рвис ле́мнтед        <- наш результат
Барба́дос ре́дфьюжн се́рвис ЛІ́ММТЕ[Д]    <- как набрано

Что здесь произошло по шагам:

1. tesseract прочитал «ЛІММТЕД» как «лёмнтед» — две подряд идущие «М» он съел, а «І» принял за «ё» (знак акцента превратился в «две точки»);
2. наш YO_FIX честно превратил «ё» в «е́» — получилось «ле́мнтед», слово, которого нет;
3. LLM-верификация увидела в печати «І́» и заменила гласный: «ли́мнтед» — буквы совпали с печатью, но в печати две «М»;
4. правильное слово — «ли́митед» (транскрипция Limited из «Barbados Red Fusion Services Limited»), а в источнике — опечатка набора: «ММ» вместо «МИ».

Сначала мы оставили «ли́мнтед», потому что базовый принцип статьи — «воспроизводи печать, а не современную норму». Но это правило имеет исключение, и исключение важнее самого правила:

Ошибку OCR чинить нужно всегда. Опечатку издания чинить нужно только тогда, когда правильное слово подтверждается источником.

Подтверждение здесь двойное: правильная форма «ли́митед» однозначно восстанавливается из контекста (английское название компании, набранное транслитерацией), и это же правило автоматически ловится нашим же фильтром near_dup (слово отличается от частотной формы словаря одной буквой).

Практическое правило, которое мы закрепили в промпте:

Не нормализуй: печать источника — норма, в т.ч. опечатки издания. НО если слово набрано с очевидной опечаткой в буквах, а рядом в той же строке/статье встречается правильное написание — восстанови правильное.

Почему не «исправлять всё по словарю»: в этом словаре полно форм, которые современный словарь считает устаревшими или ошибочными, но для 2001 года они были нормой («с+ена», «абак+ан», «магад+ан» в базе accents_index — как раз такие). Автоматическая «коррекция по современной норме» превратила бы 34 тысячи форм источника в нашу редактуру. А вот точечная правка очевидной опечатки набора — это не редактура, а реставрация.

Отдельно про «лимитед» стоит заметить: сначала я (человек) назвал правку NN «правильной», сверив только знак над «І», не проверив сами буквы. Правильный вывод из этого — любую «подтверждённую» правку подтверждаем целиком, а не по одному признаку: NN-правка проходила через CV-фильтр, а этот фильтр проверяет позицию знака, а не правильность букв, поэтому проверка «лимитед» была отдельной ручной задачей.

6.3. Главный принцип: модель не источник истины, а второй детектор

Мы прошли через две стадии деградации качества:

• v1 (свободные правки): 51 «правка» из 75 токенов, из них заметная доля — галлюцинации: выдуманное слово («совёт» вместо печатного «ЛІММТЕД»), придуманные буквы, «нормализация».
• v2 (с жёстким промптом): 21 правка из 76 — уже существенно лучше, но галлюцинации остались: АВЕРИНЦЕ́В вместо печатного АВЕ́РИНЦЕВ (знак уехал на 6 букв вправо).

Поэтому NN-правки проходят через детерминированный фильтр приёма, где каждая правка сверяется с CV-сигналом. Правила:

Именно этот фильтр поймал ровно ту правку, которую мы независимо проверили глазами («АВЕРИНЦЕ́В» — неверно), и отклонил выдуманное «совёт». Итоговая статистика по полному проходу NN-верификации:

предложено правок: 12 251   (из 23 100 проверенных токенов)
применено:          7 253   (59 % от предложенных)
отклонено:          4 979   (4 183 removed_with_cv_mark, 388 added_without_cv_mark,
                            334 no_stress_in_fix, 41 not_vowel, 20 moved_without_cv_mark,
                            13 hallucinated_yo)
на ревью:            4 678   (906 review_rewrite, 42 review_shift,
                            3 647 added_without_cv_mark, 83 manual)

По полному прогону модель предлагает правку для 53 % проверенных токенов, 41 % предложенного отсеивается автоматически, а 59 % применяется. Из принятых 4 678 помечены как требующие повторной проверки, но на аудит по печати (6.5) пошли только 1 037 — те, где модель меняла буквы или двигала знак; остальные 3 647 — случаи «добавлен только знак ударения». Это и есть правильная архитектура: дорогой слой предлагает, дешёвый слой проверяет, человек смотрит только на спорное.

Доли выше — итоговые, по всему содержательному объёму книги. На первых пятнадцати батчах они выглядели заметно скромнее (9 % правок): алфавитный указатель в конце книги у́же, а словарная часть в начале — чище.

6.4. Экономика

Разница в 5 раз — это не генерация, а всё, что вокруг неё: рендер и запись 3 927 листов на диск, сборка батчей и очередей, паузы между генерациями (лимиты, ретраи, «инструмент вернул чужие байты») и кропы с ×10, где модель считает в 25 раз больше пикселей. Три параллельных агента тут не помогают: узкое место не в concurrency, а в подготовке. 231 батч за ~70 ч — примерно один батч каждые 18 минут.

Мы решали, делать ли полный проход. Ответ — да: 41 % предложенных правок от LLM автоматически отсекаются, а принятые 59 % дают прирост точности, и «горячие» причины (yo_mark — неоднозначность е́/ё) без NN неразрешимы в принципе.

6.5. Аудит рискованных правок: модель, которая не правит, а проверяет

Фильтр приёма помечает две группы правок как подозрительные, но всё же применяет их: review_rewrite (модель переписала слово) и review_shift (знак переставлен на другой слог). По вкусовой выборке среди них около 15 % — ошибки модели: Ба́нца → Ба́лиса, Канури → Калнтва́, Теро́н → Тетю́шн. Поймать их CV-фильтром нельзя: правка правдоподобна и не противоречит ни одному автоматическому сигналу.

Решение — второй проход с другой формулировкой задачи: не «исправь отмеченный токен», а «вот предложенная правка, подтверди или опровергни по печати». Кроп для этого нужен другой: по одному токену, ×3, с полосой 16 px над знаком ударения. Плюс страховка на приёме вердикта — исправление принимается, только если буквы совпадают с исходной правкой не менее чем на 70 %, иначе это ответ про соседнюю статью, а не про наш токен.

По 1 037 рискованным правкам:

подтверждено по печати   891
исправлено по печати      74
неразборчиво (оставлено)   56
промах мимо статьи         14

Точность рискованных правок — 92,1 % (891 верных из 967 прочитанных). Массовый класс «добавлен только знак ударения» (3 647 правок) отдельно не аудировался: риск там минимален, но и проверка стоила бы ещё одного прохода по книге.

Побочный эффект оказался непропорционально большой: на кропе строки доля применённых коррекций была около 30 %, на кропе токена — 100 % от вердиктов «no». Разница не в модели, а в том, что именно ей показывали.

Этап 7. Парсер статей → словарь

Формат вывода совпадает с уже принятым в проекте (как в dictionaries/propernouns.json.gz):

{"се́на": "се+на", "алан": "а+лан"}

то есть ключ — форма без ударения, значение — форма с + перед ударной гласной: это тот же формат, который читает silero-stress и сам сервис. Но наш парсер ставил + после ударной буквы (ааро+н вместо аар+он) — обе записи описывают ааро́н, поэтому расхождение не видно глазами, а сдвинуло бы ударение на слог во всех формах. Конвертация добавилась на этапе подключения.

Что отбрасываем при разборе колонок:

• транскрипции в квадратных скобках [дэ] и пометы в круглых скобках (Франция, гор.);
• колонтитулы (строки из 1–3 заглавных букв без знаков);
• переднюю часть книги (первая буква строки — строчная);
• падежные пометы с ведущим дефисом (-а, -ы, -его) — в эталонном словаре таких ключей нет, значит, они не нужны;
• слова с латиницей, которые не удалось перевести;
• отдельные буквы и прочие огрызки (обрезаем по Unicode-категориям P/S/N).

Итог по книге: 34 217 уникальных форм при ожидаемых ~35 000 словарных единиц — совпадение по порядку величины, значит, существенных потерь при разборе нет.

{"се́на": "се+на", "алан": "а+лан"}

Правило «первая буква строки — строчная» отсекает переднюю часть книги почти целиком, но не на 100 %: в словарь попадают единичные общеязычные слова из передней части — это не имена, и в продакшен-словарь им попасть не должны. Их вычищаем отдельным проходом.

Этап 8. Валидация: почему кросс-сверка со словарём имён врёт

Самая полезная находка этого этапа — отрицательный результат.

Мы сверили свои формы с accents_index.sqlite (names, 119 259 форм) и получили: 48 совпадений, 11 432 конфликта, 20 761 форм нет в БД. На первый взгляд — катастрофа. Но при разборе конфликтов выяснилось, что чаще неправ источник сравнения:

Это старая (дореформенная/доокончательная) норма ударения, зафиксированная в БД. По этой причине кросс-сверка в нашем пайплайне остаётся информационной: она показывает, где стоит посмотреть глазами, но не является эталоном.

Отдельно: сравнение форм надо делать по позиции ударения, а не по строке — и сравнивать их, предварительно нормализовав соглашение. Символ + не занимает позицию, поэтому «ааро+н» и «аар+он» — это одно и то же ударение, записанное двумя соглашениями, а вот «маа+стрихт» и «ма+астрихт» — уже разные ударения. Наивное сравнение строк даёт ложные конфликты и занижает метрику в разы.

8.1. Сверка с общим лексиконом: из отрицательного результата в измерение

Сверка со слоем имён дала «провал», и мы честно назвали это отрицательным результатом. Но общий лексикон (lex, 3,19 млн словоформ общеязыковых слов) ведёт себя иначе: расхождений с ним почти нет, и он годится не только как индикатор, но и как эталон.

И сверка сработала как источник правок, а не только как метрика. Она нашла два класса дефектов, которые на глаз не видны:

• Знак правее ударной гласной. В 2 489 формах знак стоял на согласной — выглядит правдоподобно, ловится только независимым источником. Гипотеза «метка привязывается к букве правее» проверилась на 574 формах, присутствующих в обоих источниках: перенос знака к ближайшей гласной слева совпал с эталоном 574 раза из 574.
• Верная буква, неверный слог. Ещё 2 415 форм исправлены по lex: а+ба → аб+а, а+бдель → абд+ель, адамо+вича → ад+амовича.

Оба класса дешёвые: это чтение уже посчитанных данных, а не новый проход по книге. Так что этап 8 стоит перечитать: врёт не кросс-сверка, а сверка с тем источником. Со слоем имён — расхождение это норма методическая, со слоем lex — лучший бесплатный тест из всех, что были в проекте: расхождение по существу — 2 формы из 15 991, это 0,01 %.

Оговорка про границы измерения. Независимым источником покрыто 48,3 % словаря — 16 513 форм, где lex или names подтверждают позицию ударения; ещё 4,0 % спорные. Оставшиеся 47,7 % — фамилии и имена, которых нет ни в одном слое: их проверяет только тот же конвейер, который их и породил. Поэтому честная формулировка точности — 98–99 % как оценка, а не как измерение. Измеренные цифры есть только для рискованных правок (92,1 %, аудит по печати) и для покрытой половины словаря (99,99 % по lex). Чтобы получить измеренную точность по всему словарю, нужен ручной аудит выборки из непроверяемой половины: 300 форм дают 95 % доверительный интервал около ±1,6 п.п.

Грабли, на которые стоит посмотреть отдельно

• Дефект скана, неотличимый от знака ударения. В передней части книги есть царапина/ пыль: одинаковый штрих в одинаковом месте колонки, повторяющийся в соседних строках. Наш детектор честно находит его как акут — и получается «Аба́,» / «Аба́ва,» с ударением над первой буквой. Морфологически это неуловимо; ловится только контекстом (одинаковый штрих в нескольких соседних строках).
• Невидимые тонкие знаки. На родном масштабе кропа знак над «і» (слово «ЛІ́ММТЕД») не виден. Мы сами приняли корректное слово за ошибку. Решение: кропы для проверки увеличиваем ×2 всегда.
• Инструментальные сбои не выглядят как сбои. Часть изображений при чтении инструментом возвращала «чужие» байты (другая картинка целиком, без ошибки). Выглядит как «картинка не такая», и легко списать на «скан плохой». Лечится программной проверкой: tesseract по кропу должен вернуть осмысленный текст.
• Соблазн «нормализовать» печать. Самый частый источник испорченных данных. Словарь ударений — это не грамматика, а фиксация набора: двойные ударения, ударения на ё, устаревшие формы — всё это надо воспроизводить, а не приводить к современной норме.
• Отладка зрения — дорого. Разбор геометрии одного знака ударения занял несколько итераций с ASCII-раскладкой бинарной маски в консоли (# и . по 22 символа) — это дешевле, чем открывать картинку в редакторе, и даёт точные координаты пикселей. ASCII-арт для быстрой проверки формы — вполне рабочий инструмент.
• Кроп строки опасен для аудита. Повторная проверка принятых правок на кропе строки дала 14 вердиктов про соседние статьи (Бамцо́ → Ба́нгай, Далейра́ка → Никола́я): выглядит правдоподобно и молча портит данные. Для перепроверки конкретной правки нужен кроп одного токена и порог похожести букв.
• Латинские омоглифы выпадают из словаря молча. Модель (и мы при переносе ответов вручную) иногда возвращает латинские буквы вместо кириллицы. Парсер словаря отбрасывает такие формы как «слова с латиницей» — и они исчезают без единой записи в логах, ни в одной метрике. По всему прогону нашлось 89 таких правок. Нормализовать омоглифы надо на входе, до записи.
• Соглашение формата проверяйте сравнением с рантаймом. Наш парсер ставил + после ударной буквы, сервис читает + перед ударной гласной: обе записи описывают ааро́н, поэтому ошибка не видна глазом — а цена её сразу во всех 34 тысячах форм.

Что получилось и что дальше

Оценка точности: что измерено, а что оценено

Текущая оценка — около 98,5 % форм несут ударение, соответствующее печати. Важно не перепутать: это оценка, а не измерение, и она имеет конкретный срок годности — пока ручная проверка выборки не доведена до конца, цифра будет уточняться, причём вниз.

Что за оценкой стоит:

Из чего складывается остаток. Это не одна ошибка, а три разные по природе вещи, и их полезно разделять, потому что лечатся они по-разному:

• Ошибки распознавания — основная часть остатка. Три класса, которые нашлись при вычистке и при первой же ручной выборке: знак не на том слоге (2 489 форм, вычищены), испорченные ключи из-за непочиненного преобразования о́→б (в выборке из 30 форм — три: шипунбво вместо Шипунóво, понизбвье вместо Понизбо́вье, симфербполь вместо Симферóполь) и потерянный второй знак в составном названии (бу+юн-узуи вместо Бую́н-Узу́и — знак был, а не отметился только один из двух).
• Опечатки самого издания. Их единицы, и они не наши: словарь воспроизводит печать, поэтому лимитед из «БАРБАДОС» остаётся такой формой, какой её набрали. Часть таких мы сознательно восстанавливаем — но только когда правильное слово подтверждается источником, иначе это была бы редактура. В оценку точности эти формы попадают как «неправильные», хотя правильность мы здесь соблюли.
• Расхождения с современной нормой. с+ена, абак+ан, магад+ан — не ошибки, но бот, получивший такую форму от пользователя, ответит непривычно. Это свойство источника, а не пайплайна.

Куда движется цифра. Вниз. Каждый следующий батч ручного аудита может найти новое, а наш опыт первых 30 форм говорит, что находит: в первой же сотне форм нашлись потерянный знак и три испорченных ключа. Оценка 98,5 % — это верхняя граница того, что мы сейчас можем обосновать; реалистично после полной проверки выборки она опустится, скорее всего, в район 98 %.

Состояние измерения. Отбор случайной выборки из непроверяемой половины сделан: 300 форм, seed фиксирован, воспроизводимый. Проверено 30 — точность 96,3 % с 95 % доверительным интервалом 81,7–99,3 п.п., то есть на таком объёме число ещё ничего не доказывает и нужно только для калибровки. Доверительный интервал сужается до ±1,6 п.п. на 300 формах; после этого оценку можно заменить измерением в статье.

Проделано после первых 15 батчей: NN-проход закончен — 231 содержательный батч. Оставшиеся 192 батча пришлись на алфавитный указатель (стр. 14–187), где из 19 188 токенов заголовков без знака ударения — 0. То есть половину очереди можно было не оплачивать, если посчитать head_no_mark по батчам до начала генерации. Общеязычные слова вычищены (46 форм из ё-словарей и 5 обрывков текста), словарь подключён к сервису третьим слоем в accents_index.sqlite (таблица ageenko, 34 217 строк) с приоритетом ageenko → names → lex.

Что это дало на живых данных. Формы, где Ageenko расходится со слоем имён:

Аарон     ageenko  аар+он    (ааро́н)     names  +аарон    (а́арон)
Абдель    ageenko  абд+ель   (абде́ль)    names  +абдель   (а́бдель)
Абрахам   ageenko  абрах+ам  (Абра́хам)   names  +абрахам  (А́брахам)
Августа   ageenko  +августа  (А́вгуста)   names  авг+уста   (авгу́ста)

Прогон таких фраз через /tts даёт age=2;age_out=2 в заголовке X-Stress-Audit: акцентор ошибался в двух формах, слой их исправил. На обычных словах (lex-fixed: 0, age_out: 0) именной словарь не срабатывает вообще — то есть наши 34 тысячи форм не задели ни одного обычного слова.

Плюс технические хвосты: юнит-тесты на парсер, кросс-сверка с names как отчёт о расхождениях (методическая норма) и кросс-сверка с lex как рабочий тест качества.

Где это ещё применимо

Словарь ударений был удобен тем, что задача проверяемая: есть готовый «правильный ответ», с которым можно сверяться. Но сам приём к проверяемости не привязан, и в этом его главная ценность. Источники, которые сохранились только как картинки, встречаются повсеместно:

• старые словари и справочники, особенно с региональными и дореформенными нормами — то, что невозможно вывести из современных словарей по построению;
• технические руководства и паспорта изделий, вышедшие из обращения, где рукописные правки и штампы наложены на типографский текст;
• архивные документы: ведомости, съезды, протоколы — особенно с рукописными полями и правками поверх машинописного текста;
• любой источник, где смысловое начертание символа не совпадает с его формой: разрядка, ручная разметка, типографские особенности набора.

Что именно переносится, а что придётся заменить:

Самый дорогой по времени кусок здесь — CV-детектор, и это не совпадение. Границы в нём подобраны под конкретный шрифт: у другого издания другая высота строчной буквы, другой наклон, другая толщина штриха, и числа в таблице 3.3 придётся снимать заново — тот же приём с гистограммами по нескольким страницам отработает на любом материале.

Зато всё, что дороже отладки одной задачи, не требует переписывания. Авто-фильтр, LLM-по-кропам и фильтр приёма правок — это конвейер, а не привязка к ударениям. Их достаточно перенастроить на другие причины подозрительности.

Словарик

Термины в том смысле, в каком они используются в этой статье. Если читаете впервые — имеет смысл держать открытым.

OCR (Optical Character Recognition)

Распознавание текста на изображении. Программа получает картинку и возвращает текст. Здесь — tesseract, open-source-движок, самый распространённый в таких задачах.

TTS / STT

Text-to-speech — превращение текста в речь; speech-to-text — распознавание речи в текст. В проекте оба направления опираются на словарь ударений.

U+0301

Комбинирующий знак «острое ударение» в Unicode. Кладётся поверх буквы отдельным символом, а не встраивается в неё — поэтому «и» и ударение занимают в строке две позиции.

DjVu, dpi, разворот

Формат хранения отсканированных книг; «точек на дюйм», то есть мелкость скана; две печатные страницы рядом, как в открытой книге.

TSV

Tab-separated values — таблица с разделителями-табуляциями. Здесь tesseract отдаёт в ней по строке на каждое слово: текст, координаты, уровень вложенности и confidence.

Confidence

Насколько распознаватель уверен в своём прочтении, от 0 до 100. В статье используется как отдельный признак подозрения на ошибку.

Бинаризация

Превращение картинки из оттенков серого в две краски: всё темнее порога становится чёрным. Дальше важна только форма, а не цвет.

Компонента связности

Группа соседних тёмных пикселей, объединённая в одну фигуру. Находятся через ndimage.label; связность по 8 направлениям означает, что учитывается и касание по углу.

bbox (bounding box)

Прямоугольная рамка вокруг компоненты: четыре числа — координаты двух углов. Отсюда берутся ширина w и высота h.

Ковариационная матрица

Математическая сводка о том, как координаты пикселей связаны между собой. Её собственные значения дают «насколько вытянуто вдоль двух взаимно перпендикулярных направлений», а собственные векторы — сами направления.

atan2

Функция, переводящая пару чисел в угол в градусах. В формуле для ang она берёт угол главной оси компоненты; двойной аргумент принципиален — так угол корректно определяется во всех квадрантах.

elong

Отношение двух собственных значений ковариационной матрицы: во сколько раз компонента вытянута сильнее в длинную сторону, чем в короткую.

Морфология

Преобразования формы изображения: размытие, эрозия, наращивание. Мощный, но «размазывающий» инструмент — здесь сознательно не используется, чтобы не размывать тонкий штрих в акуте.

Кроп (crop)

Прямоугольный фрагмент исходной картинки. Здесь — отдельная строка или склеенный лист из шести строк.

LANCZOS

Алгоритм пересэмплинга (изменения размера изображения), который лучше большинства прочих сохраняет тонкие линии при увеличении.

Батч

Порция работы, отправляемая за один вызов: здесь 100 проверяемых токенов и 15 картинок-листов.

Recall (полнота)

Доля реально существующих проблем, которые система поймала. Здесь — «из строк с ошибками фильтр отметил столько-то процентов». Обратная метрика — precision, сколько из отмеченных действительно были проблемами.

Галлюцинация

Случай, когда модель уверенно сообщает то, чего в источнике нет: дорисовывает букву, придумывает слово, «исправляет» текст по норме вместо воспроизведения печати.

Batch API

Режим обращения к моделям, где запросы накапливаются и выполняются пачкой с задержкой. Обычно вдвое дешевле обычного режима — для офлайн-задачи вроде нашей это естественный выбор.

Детерминированный фильтр

Набор жёстких правил с предсказуемым результатом: одна и та же картинка всегда даёт один и тот же вердикт. Противоположность модели, у которой ответ зависит от случайности.