Самым известным мультиязыковым корпусом является LANG-8, в котором содержатся тексты на восьмидесяти языках. Этот массив данных был создан людьми, изучающими иностранные языки; пользователи исправляли чужие ошибки, и данные об этом автоматически попадали в систему. Однако количественное соотношение текстов на различных языках в корпусе колеблется. Так, на английском языке присутствуют свыше миллиона различных примеров, а для некоторых других языков их около десяти тысяч. Стоит также отметить тот факт, что данные собирались без какой-либо фильтрации и верификации, из-за чего в некоторых "правильных" предложениях могут присутствовать ошибки. Всё же этот корпус также крайне мал, что приводит к необходимости использования синтетических данных.
В статье "Corpora Generation for Grammatical Error Correction"[1] описывается, как с помощью истории исправлений страниц на Википедии получить параллельный корпус достаточного размера для обучения моделей на основе трансформеров. Даже при использовании минимальной фильтрации авторам удалось собрать более четырех миллиардов токенов. Также они добавили небольшой процент синтетических опечаток, то есть с вероятностью 0.003 для каждого токена они применяли случайно выбранную операцию: удаление, замену, вставку или перестановку с ближайшими символами. В этом объеме данных содержалось большое количество грамматических ошибок, а также различный "шум", связанный как с серьезными смысловыми изменениями текста и не совсем корректными исправлениями, так и с пропущенными ошибками и спамом. Фильтрация (исключались тексты больше 64 мегабайт и с количеством исправлений свыше log1.5(n) пар, где n — количество исправлений на страницу); а также удаление всех мультимодальных элементов, — помогли авторам лишь отчасти. Далее были убраны примеры длиной свыше 256 и 99% пар, где исходный текст идентичен выходному. В результате получилось, что лишь часть корпуса оказалась посвящена грамматическим ошибкам.
Вследствие авторам пришлось самим "портить" правильные тексты. Для этого они брали "правильные" предложения из Википедии и создавали ошибочные путем перевода их на другие языки и обратно. Такой способ порождал более чистые ошибочные данные без большого процента мусора. Однако у такого рода ошибок есть существенный недостаток: они получались довольно однообразными, несмотря на то, что весь корпус был полностью переведен на четыре языка (французский, немецкий, японский и русский) и обратно. Более того, перевод привел к тому, что только малая часть корпуса была репрезентативна в плане соответствия синтетических ошибок настоящим. Чтобы справиться с этой проблемой, часть с настоящими ошибками была расширена на 2.5%. Затем, по аналогии с простым парсингом, авторы случайным образом добавили в текст орфографические ошибки и опечатки. Помимо этого случайным образом были добавлены частотные ошибки из Википедии, вычисленные на первом корпусе. Для этого в истории исправлений Википедии выбирались исправления длиной не более трех слов, исходные и измененный текст которых был довольно близок по расстоянию редактирования и в которых не содержались заглавные буквы или цифры, после чего для каждого такого исправления рассчитывалась его вероятность по формуле Байеса.
После создания таких корпусов на основе этих данных была построена модель seq2seq, созданная таким образом, чтобы учитывать тексты, в которых содержится больше одной ошибки. Для этого в модели используется алгоритм последовательного декодирования, при выполнении которого лучевой поиск с длиной луча 4 (эвристический алгоритм поиска, который исследует граф, расширяя перспективные узлы в ограниченном наборе) может выбирать только такие варианты, в которых вероятность выше заранее установленного порога. Использование порога хорошо подходит в данной ситуации по причине того, что то, в чем модель сомневалась при одной итерации, может быть правильно выбрано в следующей с гораздо большей уверенностью.
В процессе обучения модели seq2seq были перепробованы разные модификации данных. Так, корпус из чистой Википедии был дважды преобразован с помощью расстояния Левенштейна с максимальным расстоянием редактирования равному 28 и 6, а потом еще представлен в четвертой конфигурации, где из текстов с большим количеством исправлений выбирались не log1.5(n) пар, где n — это общее количество исправлений на страницу, как в исходной конфигурации, а log1.35(n). Однако наилучших результатов модель достигла, когда для обучения использовался ансамбль из всех моделей. При анализе ошибок было выявлено, что при последующем дообучении на реальных данных LANG-8 такая модель успешно распознаёт не только "редакторские правки", которые не совсем подходят для задачи Grammatical Error Correction (GEC), но и реальные ошибки.
Упомянутые выше методы, впрочем, не являются новаторскими. Так, в 2017 году в статье "Artificial Error Generation with Machine Translation and Syntactic Patterns"[2] также поднимался вопрос о генерации ошибок, однако там предлагался более простой способ, когда ошибки создавались на основе их частотного распределения в уже размеченных данных. Для того, чтобы получить данные, также использовалось расстояние Левенштейна. С помощью него удавалось сопоставить предложения и вычислить слова, являющиеся ошибочными. В то же время предлагалось учитывать частеречную разметку и на ее основе генерировать тот или иной тип ошибок. Такой подход довольно прост, так как он не требует сложного парсинга данных, а частеречную разметку легко получить с помощью различных лемматизаторов, например, spacy. Однако подобные алгоритмы могут плохо работать по причине недостатка данных для сбора статистики по распределению типов ошибок; а также подход к поиску ошибок только с помощью расстояния Левенштейна может давать не совсем точные данные.
Концепция тэгов была блестяще реализована в статье "GECToR — Grammatical Error Correction: Tag, Not Rewrite"[3]. Подход, реализованный авторами, заключался в трансформации токенов и присваивании им тэгов $KEEP, $DELETE, $APPEND, $REPLACE и других (всего их было 33). Все трансформации делились на две группы: базовые, где осуществлялись самые частотные операции редактирования и g-трансформации, которые были больше заточены под каждый токен (например, часть речи, к которой токен относился). Этот подход удачен тем, что он существенно ускоряет скорость генерации предсказания. Основным же его недостатком является заточенность только под английский язык.
Идея обучения через теги также впоследствии была развита в статье "Synthetic Data Generation for Grammatical Error Correction with Tagged Corruption Models"[4] 2021 года, написанной исследователями из команды Google Research. В ней предлагалась идея использования генеративных нейронных сетей для того, чтобы на основе специальных тегов ошибок и чистых предложений создавать не какие-то случайные ошибки, а ошибки того или иного типа в зависимости от частоты встречаемости ошибки и частей речи, связанных с ней. Такой гибкий подход помог справиться с мультидоменной проблемой, а именно с тем, что распределение типов ошибок сильно разнится от языка к языку, а также от сферы к сфере (ошибки в литературном языке сильно отличаются о тех, которые люди могут допускать в медицинских текстах), а такой фреймворк позволяет легко адаптировать этот параметр под различные задачи. Его суть состоит в том, что на модель подается тэг ошибки t, принадлежащий множеству T и который описывает нужную ошибку. Множеством T здесь является набор из двадцати пяти типов ошибок, который поддерживается фреймворком ERRANT. В результате, модель обученная на корпусе данных [7], размеченных с помощью описанного выше фреймворка, по качеству может даже обойти модели, обученные на реальных данных хорошего качества. В процессе обучения у модели также есть определенный набор ограничений, например, во время лучевого поиска ветви графа существенно обрезаются, заставляя модель склоняться к той или иной ошибке. Специальные наборы тэгов также ограничивают модель в том, чтобы сделать ошибку, несовместимую с определенной языковой ситуацией. Однако существенным недостатком этого подхода является необходимость в большом объеме вычислительных ресурсов, который доступен только большим корпорациям.
Подводя итоги, хочется отметить, что проблема генерации ошибочных текстов стоит особенно остро для задач обработки поисковых запросов, когда несмотря на ошибки пользователя, системе необходимо выдать ему правильные результаты поиска. Так, подход в статье "Synthetic Data Generation for Grammatical Error Correction with Tagged Corruption Models" кажется мне наиболее удачным, так как он учитывает мультидоменность текстов, что существенно облегчает процесс. Подход в статье "Corpora Generation for Grammatical Error Correction", как отмечали и сами авторы, нерепрезентативен по сравнению с реальными данными, поэтому, как мне кажется, для решения реальных задач, он будет подходить в меньшей степени.
Список литературы:
Lichtarge J. et al. Corpora generation for grammatical error correction //arXiv preprint arXiv:1904.05780. – 2019.
Rei, Marek, et al. "Artificial error generation with machine translation and syntactic patterns." arXiv preprint arXiv:1707.05236 (2017).
Omelianchuk, Kostiantyn, et al. "GECToR—Grammatical Error Correction: Tag, Not Rewrite." arXiv preprint arXiv:2005.12592 (2020).
Stahlberg, Felix, and Shankar Kumar. "Synthetic Data Generation for Grammatical Error Correction with Tagged Corruption Models." Proceedings of the 16th Workshop on Innovative Use of NLP for Building Educational Applications. 2021.
https://ai.googleblog.com/2021/08/the-c4200m-synthetic-dataset-for.html?m=1
http://nlpprogress.com/english/grammatical_error_correction.html
Rothe, Sascha et al. “A Simple Recipe for Multilingual Grammatical Error Correction.” ACL/IJCNLP (2021).
OlegZH
А почему задачу нельзя поставить противоположным образом: найти (при помощи, разумеется, какого-нибудь особо «глубокого» обучения) способ оптимального взаимодействия с пользователем (последовательность вопросов, сочетания поиска в ширину и поиска в глубину, выделение и группировка/отсечение дубликатов, распознавание картинок и т.д. и т.п.)?
В стародавние времена, когда интернет был текстовым, поисковая строка очень хорошо работала. Для более сложных случаев можно было использовать расширенный поиск. А зачем сегодня заставлять систему ИИ обрабатывать простые текстовые запросы, гадать на кофейной гуще и предлагать кучу никому не нужных картинок (если нужны картинки)?
Пользователю нужен механизм хорошо структурированных запросов. Система ИИ должна у пользователя точно узнать, что ему нужно. Для этого, все силы нужно бросить на индексацию страниц, чтобы индекс был насколько полным и глубоким, чтобы задача поиска нужной информации решалась простыми запросами. Самое большее, GraphQL! Вот основное требование. Причём, это должна быть система обучения с подкреплением, когда уже сгруппированные результаты можно выборочно отправлять в утиль и, тем самым, подсказать системе, что «это совсем не те дроиды, которые Вы ищете».