Судовые письма оказались самым содержательным источником информации для первой версии карты. В них были положение, груз, ETA, осадка, состояние движения и комментарии экипажа.
Но получить письмо и получить данные — разные задачи.
Один смысл, много форматов
Даже одинаковое ежедневное донесение разные суда оформляли по-разному. В одном письме был строгий перечень полей, в другом — нумерованные строки без названий, в третьем часть информации находилась в теме или подписи.
Дополнительно встречались:
- опечатки и сокращения;
- пропущенные пробелы;
- запятая в десятичных числах;
- переставленные пункты;
- устаревшие значения;
- несколько судов в одном тексте;
- разные формы названия одного места.
Детерминированный парсер
Первый рабочий подход был обычным: регулярные выражения и отдельные правила для известных шаблонов.
Его преимущество — предсказуемость. Если правило сработало, можно понять почему. Если не сработало, запись остаётся неразобранной.
Недостаток проявился со временем: каждый новый формат требовал нового правила. Парсер начал учитывать тему, отправителя, подпись, нумерованные пункты и известные исключения, но свободный текст всё равно создавал новые пограничные случаи.
Локальный ИИ-нормализатор
Следующим этапом стала локальная модель. Она использовалась не для генерации текста, а для нормализации сомнительных полей:
- определить водный объект;
- исправить неточное название;
- распознать груз;
- выделить числовое значение;
- предложить судно;
- восстановить структуру строки.
Для отдельных случаев это работало лучше набора регулярных выражений. Но требуемой достоверности модель не обеспечивала.
Правдоподобная ошибка опаснее явной
Если регулярное выражение не нашло значение, система может показать статус «не распознано».
ИИ способен предложить ответ и тогда, когда данных недостаточно. Упомянутое в комментарии судно может быть принято за отправителя, порт назначения — за текущую позицию, а старое значение — за новое событие.
Такой результат выглядит аккуратно и поэтому может дольше оставаться незамеченным.
Безопасное место ИИ в процессе
В проекте ИИ не стал источником истины. Для него сформировался другой порядок:
- сначала работает детерминированный парсер;
- затем применяются справочники и алиасы;
- модель вызывается для сомнительных полей;
- результат сохраняется как предложение;
- режим проверки показывает различия «было — стало»;
- подозрительные изменения требуют подтверждения;
- исходный текст сохраняется.
Если модель недоступна, основной импорт не должен останавливаться. Запись остаётся в очереди проверки.
Проблема возникала раньше
По мере работы стало понятно: береговая обработка восстанавливает структуру, которая была потеряна в момент отправки письма.
Свободный текст удобен человеку, но дорог для автоматической обработки. Каждая строка требует интерпретации, а новое написание становится исключением.
Поэтому ключевые сведения решили формировать на судне в структурированном виде.
Структурированное донесение
Основные значения в судовом приложении выбираются из НСИ:
- тип донесения;
- судно;
- атлас ЕГС и участок пути;
- километр;
- шлюз, порт или ориентир;
- груз и его состояние;
- движение или стоянка;
- причина стоянки.
Свободный комментарий остаётся, но перестаёт быть контейнером для ключевых полей процесса. Берег получает структурированное событие, а не текст, смысл которого нужно угадывать заново.
ИИ остаётся полезным
Даже при качественных справочниках остаются старые письма, документы, сканы, комментарии и редкие сообщения. ИИ подходит для предварительной классификации, поиска возможного алиаса, нормализации архивных данных и подсказки оператору.
Но это вспомогательный слой после правил и НСИ. Самым важным результатом эксперимента стала не новая версия парсера, а изменение точки формирования данных: ключевые значения нужно структурировать в момент возникновения, а не восстанавливать позднее из свободного текста.