Comments 17
В большинстве естественных языков в тексте можно отыскать более одного смысла. Хорошая система должна извлекать все возможные, и давать пользователю возможность оперировать с удобным ему. Я так понял ни одна из обозреваемых систем этим не занимается.
Спасибо за комментарий!
С пониманием текста ситуация выглядит примерно так:
В одном и том же тексте бухгалтер, юрист, разработчик, инженер и каждый другой видит свои смыслы. Поэтому универсальных (any domain) решений пока нет и, скорее всего, для их создания не обойтись без сильного ИИ (AGI).
Недостатки в выделении смыслов, которые описываете Вы, чаще вообще — просто ошибки «недоученного» автомата. Да, бывают проблемы неизвестности контекста предметной области, но не стоит ждать «сильного ИИ», чтоб дообучить автомат этому контексту.
Бывают и просто проблемы многозначности слов, (например, «замок на замке» — что здесь на чём? и висит, стоит или нарисовано?) тогда система должна выдать все смыслы в распоряжение более сильному интеллекту, а главное потребителю её работы — человеку. Почему это «нечеткое» распознавание не принято делать, почему ИНС должна разглядеть в картинке или лягушку, или фонарь, а не выдаст, что это «фонарь + лягушка = фонарь в виде лягушки» — для меня загадка.
Извлечение всех разумных смыслов из текста — достаточно сложная задача, насколько мне известно, пока нет практических методик по ее решению.
Мой любимый пример в подтверждение тезиса — Winograd Schema Challenge:
- на ввод подается предложение: "Приз не влезал в чемодан, потому что он был слишком __ " и задается вопрос "Он — это что?";
- вместо пропуска может быть либо "большой", либо "маленький";
- в зависимости от пропущенного слова ответ меняется на противоположный: если "слишком маленький", то правильный ответ "чемодан", если "слишком большой", то — "приз".
Человек такие вопросы решает легко, а для автоматизированных систем и ИНС они очень сложны. В частности, у человека есть понимание, что чемодан и приз — это объекты материального мира, что у каждого из них есть физические свойства (габариты), что у чемодана есть специфическое свойство вмещать в себя другие объекты и др.
Дополнительный фактор — опыт человека, который, по всей видимости, играет важную роль: человек в жизни видел много чемоданов и призов разных размеров, что позволяет легко строить необходимые ассоциации и восполнять пробелы в тексте.
Отмечу, что это всего лишь один из многих факторов, более подробное раскрытие темы извлечения и интерпретации смыслов будет в следующей статье.
Спасибо за обзор, вижу что "мы" в начале трудного пути.
По моему опыту проблема понимания текстов начинается с того, что большая часть информации попадает в обработку в виде сканов документов. Причем не качественных, т.к. зачастую это бывают сканы не качественных прошитых копий с печатями. OCR от лидеров рынка, к сожалению, плохо справляются с некачественными сканами, плюс лингвистические модели зашитые в них слабо подходят для нашей предметной области. Повсеместного внедрения ЭЦП я, увы, пока не наблюдаю. И если можно приставить человека вычитывать входящие документы после OCR, то вычитывать корпуса необходимые для обучения моделей — уже сложнее. Т.е. текст для понимания нужно еще заслужить. Стоит отметить, что модели основанные на правилах, как правило, гораздо менее толерантны к опечаткам в тексте, чем модели основанные на DL.
Что касается открытых корпусов для обучения эмбеддингов и лингвистических моделей, то с моей точки зрения это не является проблемой. В открытом доступе есть 40 млн документов арбитражных судов, есть федеральное, региональное и муниципальное законодательство, есть документы публичных компаний. Можно обучить ELMo с нуля, можно дообучить BERT. Вот еще полезная инициатива: https://github.com/irlcode/RusLawOD
Если говорить о проблеме ИИ в данной области в целом, то возможно не стоит пытаться создать AGI раньше Google. Завышенные ожидания у бизнеса, которые зачастую подпитываются обещаниями "магов", скорее вредят отрасли. Мне понравилась модель юридического бизнеса в виде треугольника, где в основании находятся паралигалы, в центре консультанты, а на вершине партнеры. И на выступлении, где эта модель упоминалась, предлагалось путем внедрения основанных на ИИ технологий превратить треугольник в ромб. Т.е. для начала можно решить массовые задачи, для которых существуют большие объемы документов и экспертиза, научиться в условных 90% случаев принимать правильные решения, и с хорошей точностью отличать эти 90% от 10%, когда нужно позвать человека. Я допускаю, что на каком-то этапе при решении такого класса задач, можно будет превзойти результаты человека.
Для решения не массовых задач юристам нужны справочно-правовые системы, хотя мне больше нравится английский термин CALR — computer assisted legal research, в этой области есть много не решенных задач, для которых не требуется AGI, но обработка больших объемов информации, например, судебной практики.
Спасибо, буду следить за вашими успехами.
Спасибо за развернутый и вдумчивый комментарий!
Проблема с OCR действительно есть, но очень хочется верить, что в скором времени мы увидим прорывы в работе с русским языком от разработчиков в этой области.
А пока, очевидно, лучше работать в тех областях, где наличие электронной копии документа — де-факто стандарт.
C ЭТАП тоже штука сложная: для более распространённых слов и фраз точность его очень неплохая, у него были проблемы с полнотой: чтобы на всех документах и незнакомых словах показывать более хорошие результаты, потому что это система на правилах.
И ещё, как вы думаете, сколько нужно проанализировать примеров парсинга, чтобы уверенно выдавать заключения наподобие «нарушение последовательности связей в сложных предложениях и числовых значениях» или «эта библиотека работает лучше вот этой»?
Я вообще не понимаю, как вы смогли получить какие-то разумные обоснования в вашей оценке качества. Правда, наверное, это я, зная, какая библиотека с каким качеством работает, могу их разумно проинтерпретировать…
Посмотрите на более хороший анализ: github.com/natasha/naeval
А вот здесь ещё датасетов для тестирования моделей подвезли: habr.com/ru/company/sberbank/blog/506058
С точки зрения канонического data science, Ваша позиция вполне понятна и разумна: надо всегда использовать самую SOTA-версию библиотеки, тестировать на общепринятых датасетах, приводить выверенные метрики accuracy, f1/f2… Таких инициатив достаточно много, и поэтому мы не ставили задачу сделать еще leaderboard.
Наша ценность и вклад принципиально в другом — мы можем оценить практическую применимость существующих решений для автоматизации юридической функции. В частности, надо четко понимать, что юридические тексты имеют существенную специфику и очень не похожи на тексты научных статей, новостей, литературных произведений (как мы описали на примерах). Соответственно, представляется маловероятным, что появление какой-то новой модели с приростом качества в несколько процентных пунктов вдруг "заработает" на юридических текстах.
Нет, моя позиция другая: вам нужно сделать юридический датасет, пусть даже на 500 предложений, и протестировать имеющиеся решения на нём автоматически. Вот можете прямо взять скрипты из naeval.
Потому что как раз ценность тестирования на 5 предложениях под предлогом «мы можем оценить практическую применимость существующих решений» мне непонятна. Нет, не можете, вы даже не знаете, получили ли вы хорошую оценку применимости этих библиотек, если вы на 5 примерах прогоняли и делали выводы. Вы легко можете заблуждаться на небольшом числе примеров. Понимаете?
Интересная статья, спасибо.
Жаль, что вы не добавили в проверку проект spacy-ru (его автор, buriy, тоже здесь). По моему опыту, неплохой результат.
Относительно наилучшего качества для русского языка:
Пожалуй, мы ждём spacy 3.0, в котором будут и классические модели, оптимизированные для CPU, и русские модели на основе RoBERTa, оптимальные для GPU (и запуска батчами).
Собственно, классические модели из 2.3 для 3.0 я уже натренировал:
github.com/buriy/spacy-ru/releases/tag/v2.3_beta, а, как время будет, натренирую и более качественные, но более медленные.
И я обязательно напишу об этом статью на Хабре, только это будет наверное уже в декабре.
А именно для Legal была ещё идея сделать отдельный LegalBERT.
Вот ребята рассказывают про их подход к этой задаче и их NER: www.youtube.com/watch?v=lTM1tgYW72o
Искусственный интеллект в области юриспруденции