Я такую задачу решил на С# в проекте Pullenti Unitext с конвертацией в Java, Javascript и Python. Пытался конвертировать на Rust, но это не получилось. Понимаю всю сложность этой задачи и желаю автору удачи!
Немного запоздало, но всё-таки. В версии 4.14 это "побеждено" - теперь регистр символов не важен, также возможен пропуск ключевых слов. Варианты типа "г. москва кржижановского 15-2-1" теперь обрабатывает корректно.
Индекс ГАР ФИАС достраивать нет смысла - он фиксирован и полностью перестраивается от версии к версии. Там объекты имеют вполне определённую структуру, уникальные GUID и пр. Но он - лишь вспомогательный инструмент при анализе адресов, который даёт возможность убедиться в существовании того или иного объекта, а также убрать неопределённость в ряде случаев.
Для Вашей задачи больше подойдёт Адрессарий - в него можно неограниченно добавлять новые адреса. Правда, только в рамках существующего алгоритма.
Поясню на примере. В недавней загрузке было много вот так оформленных адресов: "196620,Санкт-Петербург г,Пушкин г,Анциферовская(Гуммолосары) ул", которые на самом деле "город Санкт-Петербург муниципальный округ город Пушкин территория Гуммолосары улица Анциферовская", то есть в скобках внутри улицы уровня 8 указывался объект уровня 7. После доработки алгоритма эти случаи стали обрабатываться корректно. Но без доработки алгоритма внешними настройками решить эту задачу проблематично.
Так алгоритм Pullenti совершенствуется от загрузки к загрузке.
Согласен. Думаю, в следующей версии SDK это будет учтено. Просто в тех довольно больших массивах адресов из разных регионов, которые мне приходилось обрабатывать, случаев названий полностью в нижнем регистре исчезающе мало, и я пока ими пренебрёг.
Человек всегда может придумать пример (в области обработки текстов), который будет не по зубам самому лучшему алгоритму. Здесь всегда останется процент ошибок, для этого и используются разные метрики - полнота, точность и F-мера. Если сравнивать разные системы, то по этим метрикам на некотором количестве адресов (аналогично как проводят конкурсы по NER и т.п.). А так всегда можно найти пример адреса, понимаемый одной системой и не понимаемый другой.
Да, с регистром пока неважно - алгоритмы ищут адреса в произвольных текстах, и если учитывать все слова в нижнем регистре, то можно зацепить много мусора. Планирую убрать это требование при обработке текста из одного адреса (в SDK две основные функции - выделение из произвольных текстов и обработка одного адреса из "поля ввода").
Насчёт разделителей - это вообще больная тема. 15-2-1 - это что? Тут даже человек не разберёт. Например, в Забайкальском крае 10/1 обычно обозначают дом 10 и квартиру 1. В других местах это просто номер через дробь. Часть неопределённости снимается при использовании информации из ГАР ФИАС. Но в общем случае неопределённость в таких случаях неразрешима.
В отличие от DaData, здесь стоимость за всё SDK без ограничений, так как обработка производится локально, без обращения к внешним ресурсам. Цена - договорная.
Как раз сейчас на Диалог-2022 проходит конкурс по Few-Shot NER (RuNNE: https://github.com/dialogue-evaluation/RuNNE). Вы в нём собираетесь принять участие, чтобы подтвердить вышеизложенное практически?
Результат — это сущности с атрибутами, две сущности равны, если у них атрибуты полностью совпадают. Например, для персоны к атрибутам относятся фамилия, имя, отчество, должность и пр. Значения атрибутов могут быть как строковыми, так и ссылками на другие сущности, то есть имеем а общем случае на выходе граф. И вот эти конструкции должны полностью совпадать.
Автотест содержит пару {T, R0}, где T — текст, R0 — эталонный результат (сущности с их атрибутами). Пусть R1 = A(T) — результат применения алгоритма A к тексту T. Тест считается удачным, если R0 = R1. Проверка сравнения строк идёт штатными функциями конечного языка, тут ошибки быть не может. Если R0 = R1 на всех конечных языках, то конвертер работает неплохо. Как минимум, результирующие SDK одинаково функционируют на автотестах.
Разумеется, проверяет человек. Берётся текст, на нём отрабатывает алгоритм, и человек оценивает (в первый раз, при создании теста), правильный ли результат. После утверждения тест является рабочим.
Так и есть — для входного текста проверяется именно выход алгоритма, чтобы результат анализа полностью совпадал с ожидаемым. Это не тесты типа Assert.IsTrue(...), а полноценное сравнение сложных структур (например, выделенных сущностей), всё должно полностью совпадать.
Вы правы, но в случае генерируемого SDK пользователю не надо туда влезать и разбираться с кодом, а достаточно использовать внешние функции, которые для Java и JavaScript мало отличаются от оригинала, для Python и Rust получается немного коряво.
Да и любой переводчик с естественного языка на язык представляется таким «Франкенштейном», особенно на ранних этапах своего развития. Понятно, что носитель обоих языков переведёт лучше. Но это дорого, и где их взять то, на всех?
Постараюсь ответить на последний абзац. Rustbook я открывал, знакомство с Rust весьма поверхностное, ограниченное месяцем, реальных проектов на нём не делал. С языком C# знаком чуть больше. Да, я сам стараюсь object не использовать, но иногда без него никак. Например, object Tag в классах WinForm (это пришло ещё из Delphi, кажется), чтобы пользователь мог записать туда что угодно. Про generic я тоже кое-что слышал, даже иногда использую их, когда настроение хорошее :).
Если тест выдаёт результат, полностью совпадающий с ожидаемым, то это и есть гарантия (не 100%, разумеется, но близко к этому). А для чего же ещё нужны автотесты!?
Я такую задачу решил на С# в проекте Pullenti Unitext с конвертацией в Java, Javascript и Python. Пытался конвертировать на Rust, но это не получилось. Понимаю всю сложность этой задачи и желаю автору удачи!
А сама OCR система какая именно была выбрана?
Немного запоздало, но всё-таки. В версии 4.14 это "побеждено" - теперь регистр символов не важен, также возможен пропуск ключевых слов. Варианты типа "г. москва кржижановского 15-2-1" теперь обрабатывает корректно.
Индекс ГАР ФИАС достраивать нет смысла - он фиксирован и полностью перестраивается от версии к версии. Там объекты имеют вполне определённую структуру, уникальные GUID и пр. Но он - лишь вспомогательный инструмент при анализе адресов, который даёт возможность убедиться в существовании того или иного объекта, а также убрать неопределённость в ряде случаев.
Для Вашей задачи больше подойдёт Адрессарий - в него можно неограниченно добавлять новые адреса. Правда, только в рамках существующего алгоритма.
Поясню на примере. В недавней загрузке было много вот так оформленных адресов: "196620,Санкт-Петербург г,Пушкин г,Анциферовская(Гуммолосары) ул", которые на самом деле "город Санкт-Петербург муниципальный округ город Пушкин территория Гуммолосары улица Анциферовская", то есть в скобках внутри улицы уровня 8 указывался объект уровня 7. После доработки алгоритма эти случаи стали обрабатываться корректно. Но без доработки алгоритма внешними настройками решить эту задачу проблематично.
Так алгоритм Pullenti совершенствуется от загрузки к загрузке.
Согласен. Думаю, в следующей версии SDK это будет учтено. Просто в тех довольно больших массивах адресов из разных регионов, которые мне приходилось обрабатывать, случаев названий полностью в нижнем регистре исчезающе мало, и я пока ими пренебрёг.
Человек всегда может придумать пример (в области обработки текстов), который будет не по зубам самому лучшему алгоритму. Здесь всегда останется процент ошибок, для этого и используются разные метрики - полнота, точность и F-мера. Если сравнивать разные системы, то по этим метрикам на некотором количестве адресов (аналогично как проводят конкурсы по NER и т.п.). А так всегда можно найти пример адреса, понимаемый одной системой и не понимаемый другой.
Да, с регистром пока неважно - алгоритмы ищут адреса в произвольных текстах, и если учитывать все слова в нижнем регистре, то можно зацепить много мусора. Планирую убрать это требование при обработке текста из одного адреса (в SDK две основные функции - выделение из произвольных текстов и обработка одного адреса из "поля ввода").
Насчёт разделителей - это вообще больная тема. 15-2-1 - это что? Тут даже человек не разберёт. Например, в Забайкальском крае 10/1 обычно обозначают дом 10 и квартиру 1. В других местах это просто номер через дробь. Часть неопределённости снимается при использовании информации из ГАР ФИАС. Но в общем случае неопределённость в таких случаях неразрешима.
Думаю, здесь дело в том, что раньше был какой-нибудь аул или посёлок Михайловский, а потом стал поселением, но название менять не стали.
В отличие от DaData, здесь стоимость за всё SDK без ограничений, так как обработка производится локально, без обращения к внешним ресурсам. Цена - договорная.
Как раз сейчас на Диалог-2022 проходит конкурс по Few-Shot NER (RuNNE: https://github.com/dialogue-evaluation/RuNNE). Вы в нём собираетесь принять участие, чтобы подтвердить вышеизложенное практически?
Да и любой переводчик с естественного языка на язык представляется таким «Франкенштейном», особенно на ранних этапах своего развития. Понятно, что носитель обоих языков переведёт лучше. Но это дорого, и где их взять то, на всех?