Языки

Каждая команда в своей работе сталкивается с необходимостью внедрения новой технологии или языка программирования в проект. Иногда это внедрение проходит успешно, а иногда нет. В этой статье хотелось бы рассказать о нашем опыте использования C++/CLI.

Начало. Ожидается солнечная погода

Задание: разработать программный комплекс для моделирования различных процессов, протекающих на объектах в системах сбора, подготовки и транспортировки углеводородов. Объектами моделирования могут быть скважины (как добывающие, так и нагнетательные), трубопроводы, объекты подготовки нефти, газа и воды. В среднем каждое месторождение характеризуется более чем 100 объектами обустройства. Причём некоторые объекты имеют размерность либо по глубине, либо по длине в несколько километров. Приемлемое время расчёта модели одного месторождения порядка нескольких минут. Если совсем просто, то необходимо представить вот такой объект:

В виде вот такой модели и рассчитать её характеристики.

Наработки: существующие методики, существующий проект с функциональностью, частично покрывающей задачи проекта.

Команда: программист стека .NET/WPF, программист C++, методист, руководитель проекта.

На первом этапе задача состояла в том, чтобы освоиться с уже существующей кодовой базой, понять, что и как работает, убрать всё лишнее, добавить часть нового функционала в соответствии с описанием, полученным от методистов. Небольшое замечание, которое в дальнейшем будет иметь значение: все расчёты должны быть выполнены на C++, это было связано с тем, что необходимо обеспечить:

высокую скорость расчётов;

последующее использование наработок в качестве подмодулей для других приложений.

Безоблачное продолжение

Уже существующий проект, на базе которого предстояло начать работать, был выполнен с использованием .NET/WPF, методики расчёта модели реализованы при помощи .NET/C# c промежуточными вызовами плюсового кода через P/Invoke. P/Invoke (для справки) это технология, которая позволяет обращаться к структурам, обратным вызовам и функциям в неуправляемых библиотеках из управляемого кода. Т. е. примерно вот так:

Код на C# содержал описание моделей объектов, участвующих в расчёте, а также расчёт сети объектов. За расчёт параметров отдельного объекта отвечала плюсовая часть. Время выполнения расчёта соответствовало заявленным требованиям, поэтому было решено оставить расчёт сети объектов на C# и сосредоточиться на расширении расчётов параметров самих объектов на C++.

Так как предстояло значительное увеличение количества вычисляемых параметров (и, соответственно, количества параметров, которые необходимо передавать через P/Invoke), то возник вопрос: "Использовать прежнюю схему взаимодействия с неуправляемым кодом или воспользоваться другими технологиями?".

Ключевыми критериями для выбора мы определили скорость взаимодействия и удобство использования.

В качестве альтернативы использованию P/Invoke, возникла идея использования технологии C++/CLI.

Спецификация языка C++/CLI (C++ modified for Common Language Infrastructure) была создана компанией Microsoft на замену Managed Extensions for C++. C++/CLI позволяет одновременно работать как с классами и методами языков .NET, так и с обычным кодом C++.

Приставка CLI расшифровывается как Common Language Infrastructure это открытая спецификация (технический стандарт), разработанная Microsoft и стандартизированная ISO и Ecma, описывающая исполняемый код и среду выполнения, которая позволяет использовать несколько языков высокого уровня на различные компьютерных платформах без переписывания под конкретные архитектуры. Т. е. C++/CLI нужен вот для этого:

В C++/CLI, прежде всего, нам показалось привлекательной возможность вызова уже написанного на плюсах кода при помощи управляемых оберток для существующих классов на С++. Сравнительный тест скорости вызова плюсового кода при помощи C++/CLI и P/Invoke, как ни странно, также показал уменьшение времени расчёта при использовании первого.

Вызовов P/Invoke на тот момент было совсем немного и поэтому в короткий срок нам удалось перейти на использование новой технологии. Стандартный вариант использования C++/CLI в нашем проекте выглядел примерно вот так:

public ref class DeviceBaseClr : public IDisposable, public Figures::Models::IItemBase

{

#pragma region Поля и свойства

protected:

/// <summary>

/// C++ unmanaged объект декоратора

/// </summary>

DeviceBase* obj_;

#pragma endregion

#pragma region IItemBase

public:

virtual IState^ GetState(DateTime date);

virtual IState^ SetState(DateTime date, IState^ state);

#pragma endregion

#pragma region Конструкторы

public:

DeviceBaseClr(IStateFactory^ stateFactory);

virtual ~DeviceBaseClr();

protected:

!DeviceBaseClr();

#pragma endregion

};

} // Simtep::Diagrams

#endif // _DEVICEBASECLR_H_

Предполагаемая архитектура приложения, выполненного в соответствии с парадигмой MVVM, выглядела следующим образом:

Тучи сгущаются

На следующем этапе развития проекта, по мере наращивания функционала, мы начали сталкиваться с некоторыми проблемами.

Во-первых, появилась необходимость вызова расчётов реализованных на C# внутри неуправляемого кода (и, кстати, да C++/CLI и это позволяет делать тоже).

Во-вторых, нам пришлось опустить часть модели в неуправляемую часть из-за того, что возникла необходимость использования сторонних библиотек, реализованных на С++.

После этих изменений архитектура приложения приобрела следующий вид:

В результате возникли как технические проблемы:

Мы не могли просто подключать сторонние библиотеки на C++ (имеются в виду библиотеки с расчётами предоставленные нашими коллегами из параллельных проектов), нужно было пересобирать их из исходного кода, используя специальные директивы для CLI.

Существует отдельный синтаксис LINQ для CLI, его возможности ограничены по сравнению с обычным, например, в нём нет лямбда-выражений, писать отдельные методы каждый раз не очень удобно.

Отсутствие возможности использовать умные указатели.

Постоянно возникали вопросы при использовании контейнеров, например при попытке добавления в коллекцию, созданную на стороне неуправляемого кода, объекта, созданного на стороне .NET.

Управление памятью, например, что будет, если для одного нативного объекта вдруг создастся две обёртки на CLI, и в какой-то момент будет освобождена сборщиком мусора?

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

Логика классов может усложняться, что неизбежно ведёт к усложнению обёрток.

Как уже было сказано выше, рано или поздно возникает необходимость обратного использования управляемого кода в неуправляемом. C++/CLI позволяет это сделать, при этом увеличивается сложность проекта.

Так и вопросы организационного характера:

C++/CLI это всё-таки ещё один язык программирования. Т. е. если к вам в команду добавляется джуниор с базовыми знаниями по C++, нужно учитывать, что ему необходимо влиться в предметную область, чуть подтянуть свой уровень владения C++ и плюс ко всему выучить ещё один язык программирования. Ну и, соответственно, ошибки можно сделать как в нативном коде, так и в обёртке.

Программистам C# будет тяжело в случае необходимости внести изменения в обёртку.

По мере развития проекта мы стали замечать, что большая часть времени уходит не на расширение функционала, а именно на изучение самого C++/CLI, особенностей его синтаксиса и поддержание кода именно обёрток. Разумеется, к обычным ошибкам, сопутствующим процессу разработки, добавились ошибки, возникающие на стыке C# и C++/CLI.

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

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

Множественный вызов CLI. Почти на каждой строке. Это значит постоянное создание декораторов, постоянный (почти непрерывный маппинг) как в одну сторону, так и в другую.

Использование декораторов означает их создание, т. е. постоянное выделение памяти внутри расчётного цикла.

Цикл расчёта на стороне .NET, не позволявший осуществить многопоточный расчёт в полной мере.

Плюс системные затраты на преобразование типов из managed в unmanaged и обратно (речь о передаче стандартных типов).

Разгон облаков

Скорость расчёта критична для нашего приложения, поэтому нам было необходимо либо дальше оптимизировать существующий код с небольшими шансами на успех, либо попытаться отделить расчёты от интерфейса и модели (заодно отказавшись от CLI) с чуть более высокими шансами. В итоге мы выбрали второе. По сути, это означало практически переписать приложение на 70 процентов заново.

Какие факторы помогали нам верить в успешность задуманного:

сработавшаяся команда разработчиков;

высокая степень владения кодом;

высокая степень понимания разработчиками предметной области;

запас времени перед сдачей этапа;

природный оптимизм.

Новая архитектура в наших планах выглядела следующим образом:

Подобное разделение позволило бы нам избавиться от проблем с CLI и воспользоваться, наконец, в полной мере скоростью расчётов на чистом C++. Из минусов( если это можно назвать минусом) появилась необходимость создания и поддержания эквивалентной модели на стороне С++, а также обеспечения взаимодействия между моделями.

При реализации взаимодействия был соблазн воспользоваться RabbitMQ или ZeroMQ, однако, оценивая вероятность того, что мы одновременно сумеем и переписать большую часть кода, и реализовать механизм взаимодействия на основе очереди сообщений, мы решили выбрать самый простой вариант, а именно файловый обмен. На практике при грамотной реализации с ним возникло меньше всего проблем, в том числе и по скорости.

Переход на новую архитектуру занял у нас около 3-х месяцев, и если говорить о каких-то подводных камнях, то они были такими:

Мы планировали завершить рефакторинг во время Х, а закончили во время 3*Х. Значительное превышение первоначальных сроков было связано с тем, что изначально в проекте были большие фрагменты кода, написанные на C#. Во время оценки времени, необходимого на переход, мы не учли того, что у нас отсутствует формализованное описание алгоритмов для этих фрагментов, а прямой перенос не всегда был возможен.

Рефакторить 3 месяца при отсутствии навыков программирования на C++ большей части команды было тяжело.

Ожидается солнечная погода без осадков

Подводя итог, хочется сказать, что:

C++/CLI это интересный язык программирования, и в некоторых случаях он позволяет значительно упростить жизнь. Однако прежде, чем внедрять его в свой проект, мы бы посоветовали заранее на этапе проектирования очертить рамки, в которых он будет использоваться. Т. е. в случае, когда он используется для обеспечения взаимодействия с нативным кодом, по нашему мнению, это должно быть либо штучное взаимодействие крупных узлов системы, либо подключение небольшого класса или функции. В противном случае вы рискуете повторить наши ошибки. Всем спасибо!

Если у кого-то есть свой опыт использования C++/CLI, то нам было бы интересно о нём узнать.

Одним из популярных языков программирования можно назвать язык Ruby, с его не менее популярным веб-фреймворком Ruby On Rails.Однако, несмотря на его популярность, вам не стоит тратить на него время, и вот почему.

Рассвет Ruby на рельсах

В 2005 году на свет появился фреймворк Ruby On Rails, который на момент своего выхода наиболее удобно и просто реализовывал архитектурный шаблон MVC. И многие программисты осознали, что они теперь могут делать очень просто и быстро кастомные веб-приложения. Это был настоящий прорыв в сфере создания веб-приложений.

И огромное количество компаний (в основном стартапы), стали делать свои сервисы именно на языке Ruby, на фреймворке Ruby on Rails Netflix, Bloomberg, Airbnb, Groupon, Basecamp, GitHub, KickStarter и так далее.

В России и странах СНГ также огромное количество новых компаний в период 2008-2010, стали делать свои решения на ROR. Тогда были популярным в основном стартапы на туристическую тематику.

Переломный момент у Ruby

Успех Ruby On Rails не оставался незамеченным и на других языках программирования стали копировать решения из ROR. Так на Python появился Djnago, на PHP появился Laravel, а корпоративные фреймворке Spring (Java) и .Net (С#) стали брать удачные решения из ROR и внедрять в свои фреймворки.

И в какой момент на каждом языке программирования стало также удобно и просто разрабатывать кастомные веб-приложения, как в свое время на Ruby.

И тут стал появляться вопрос: Если везде также просто разрабатывать веб-приложения, то зачем выбирать именно Ruby с его рельсами. И на этот вопрос не нашелся ни один адекватный ответ.

• Java и C# - предлагали корпоративную надежность и огромное количество разработчиков, готовых работать на этом стеке.

• Python - подкупал своей универсальностью и элегантностью языка. Практически нет сферы, где нельзя было бы использовать python.

• PHP предлагал безумную скорость разработки и относительную дешевизну рабочих рук.

Ruby не имел ни одного преимущества перед этими языками. У него был лишь веб-фреймворк Ruby on Rails, который все уже давно скопировали.

Как итог, новые стартапы стали выбирать другой стек для своих систем, популярность Ruby и спрос на него стали катастрофически падать. В итоге, если посмотреть сейчас какие новые стартапы запускаются на Ruby, вы вряд ли найдете громкие имена. Ruby проиграл.

Оценка рынка вакансий на Ruby

В России и странах СНГ Ruby никогда не был особо популярным стеком. Простой поиск по вакансиям дает крайне мало результатов, и большинство вакансий идет как раз в компании, что были основаны в период его популярности. Поэтому вам нужно быть готовым к тому, что основную часть своей работы вы будете тратить на поддержку существующих решений.

Однако тут есть небольшой плюс. В силу того, что специалистов на Ruby становится все меньше и меньше, а компании, которые уже завязались на Ruby, не могут с него слезть. Зарплаты на Ruby могут быть выше, чем на Python и PHP.

США и Силиконовая Долина

В США, а именно в Силиконовой Долине, ситуация с Ruby обстоит гораздо лучше. Там есть достаточно много крупных игроков, у которых код пишется на Ruby (смотрим самые известные копании на Ruby on Rails). Поэтому там есть приток свежей крови, там есть возможность переходить с одной компании на другую.

Другими словами, если вы хотите стать Ruby программистом, то вам нужно планировать переезд в Силиконовую долину, ведь только там есть стабильный спрос на Ruby программистов и какие-то перспективы на этом стеке.

Стоит ли учить Ruby в 2020 годах и выше

Если говорить объективно, то существующие программисты на Ruby могут зарабатывать неплохие деньги, так как ситуация на рынке позволяет им запрашивать более высокие зарплаты, чем у их коллег.

Если вы начинающий программист и только выбираете свой стек, то лучше выбрать что-то из PHP/Python/Java/C#. Эти языки активно развиваются, активно поддерживаются, и активно используются, как в легаси проектах, так и новых стартапах. Нет смысла изначально брать умирающий язык, каким бы крутым он не казался на первый взгляд.

УмретлиRubyиRuby on Rails

Все зависит от того, сможет ли язык предложить какие-то решение для новых проблем программирования. Мы все помним, как в свое время node.js взорвал рынок и привел к дикой популярности JavaScript. Как итог из узкоспециализированного языка JavaScript стали использовать везде: фронт, бекенд, микросервисы, десктоп-приложения, мобильные приложения.

Если на языке Ruby придумают что-то подобное, то это может привести к его возрождению и новой популярности. Однако, если этого не произойдет, он медленно умрет, как будут закрываться компании, которые держали на нем свою бизнес-логику.

Поэтому, смотрите на вакансии в своем городе, оценивайте их число и качество. Если по какой-то причине в вашем городе все вакансии именно на Ruby, то лучше выучить его, чем сидеть без работы. Однако, в большинстве случаев вакансий на Ruby будет мало.

p.s. здраво оценивайте рынок, не введитесь на рекламные лозунги продавцов курсов.

Не так давно у автора этой статьи возник вопрос: может ли простой метод сопоставления строк в сочетании с некоторыми простыми оптимизациями конкурировать с моделью, обученной с учителем, в биомедицинской задаче распознавания именованных сущностей (NER)? Автор сравнил эти два метода между собой и предположил, что при правильном подходе даже простые модели могут конкурировать со сложными системами, а мы к старту курса "Machine Learning и Deep Learning" перевели его статью.

В начале любого нового проекта НИОКР я ищу наиболее подходящее решение поставленной задачи. Несмотря на наличие нескольких очень интересных крупных моделей, одной из моих самых больших проблем является внедрение решения в производство без ущерба для результатов, которые я хотел бы поддерживать.

Что касается системы сопоставления строк, я использовал классификатор QuickUMLS. QuickUMLS [1] как система сопоставления строк принимает на вход строку (например, документ или реферат статьи, содержащий медицинские понятия) и выводит все промежутки документа, которые соответствуют понятиям унифицированного языка медицинских систем (UMLS). Затем эти понятия могут быть повторно использованы в других условиях или в качестве исходных данных для других систем машинного обучения. По этой причине QuickUMLS можно рассматривать как удобный инструмент предварительной обработки для получения релевантных понятий из клинических и биомедицинских текстов. Однако в этой статье мы сосредоточимся на использовании QuickUMLS в качестве классификатора на сложном наборе данных MedMentions [2].

Некоторые ключевые моменты, которые необходимо знать о биомедицинском NER

Прежде чем мы погрузимся в проблему, которую пытаемся решить, полезно описать некоторые особенности биомедицинского NER. В целом проблема NER заключается в поиске именованных сущностей (например, известных мест, лиц, организаций и т. д.) в тексте. Как вы, вероятно, догадываетесь, многие из этих сущностей можно найти через контекст. Например, в таком предложении, как "Сэм и Дрю пошли в Колизей", мы можем сделать вывод, что Колизей это место, потому что вы обычно ходите в какие-то места. Аналогично, мы можем предположить, что "Сэм" это имя собственное, потому что слова в позиции подлежащего "идти", которые не являются обычными словами, это обычно имена.

В отличие от этого биомедицинская NER заключается в поиске и однозначном определении интересующих биомедицинских терминов из текста, таких как заболевания, названия лекарств, а также общих терминов, таких как "больница.роддом" (hospital), "палата интенсивной терапии/подопечный отделения интенсивной терапии" или "алкоголь/спирт" (alcohol). Это важное различие, поскольку существует очень мало контекстуальной информации, определяющей, имеет ли данное слово медицинское значение. Чтобы привести немного нагруженный пример, рассмотрим слово "alcohol" в предложении "пациент выпил много alcohol" [для ясности того, что речь идёт о неоднозначности, оставлено оригинальное alcohol]. Тяжесть этого заключения зависит от того, относится ли оно к алкоголю, такому как пиво или вино, или к чистому спирту, такому как спирт для растирания. Для более полного обзора состояния дел в области биомедицинского NER см. эту запись в блоге моего коллеги из Slimmer AI, Сибрена Янсена.

Знать, какие понятия имеют медицинское значение, сложно без большого количества обучающих данных, которые, как правило, не всегда доступны. Поэтому многие системы используют унифицированный язык медицинских систем (UMLS), которая представляет собой большую онтологию, содержащую множество различных понятий вместе с их строковыми представлениями и другой информацией. Обратите внимание, что "понятие" здесь отличается от "строки", поскольку многие строки могут ссылаться на более чем одно понятие. Например, строка "alcohol" может относиться к спирту для растирания или к алкогольным напиткам.

В UMLS каждое понятие описывается уникальным идентификатором понятия (CUI), который является символическим идентификатором для любого данного уникального понятия, и семантическим типом (STY), который, в свою очередь, является идентификатором семейства, группирующим понятия с похожими характеристиками. Одной из причин, по которой UMLS является полезным, но в то же время сложным для работы, его огромный размер. Версия UMLS 2020AB, которую мы будем использовать в дальнейшем, насчитывает более 3 миллионов уникальных английских понятий. Маловероятно, что значительная часть этих понятий появится даже в больших аннотированных наборах данных.

Работа с набором данных MedMentions

Одним из таких наборов данных является MedMentions. Он состоит из 4 392 статей (заголовки и рефераты), опубликованных в Pubmed за 2016 год; аннотировано 352 K понятий (идентификаторов CUI) и семантических типов из UMLS. В документах имеется около 34 тысяч аннотированных уникальных понятий это около 1 % от общего числа понятий в UMLS. Факт показывает, что аннотирование упоминаний в UMLS является сложной задачей, которую не всегда можно решить с помощью машинного обучения с учителем.

Особый интерес в этом отношении представляет то, что корпус MedMentions включает в тестовое множество CUI, которые не встречаются в обучающем наборе. В целом, однако, эта задача всё ещё рассматривается как задача машинного обучения с учителем и с использованием семантических типов понятий UMLS в качестве меток. Поскольку UMLS имеет 127 семантических типов, это всё равно приводит к большому пространству меток. У набора данных MedMentions тоже есть уменьшенная версия st21pv, который состоит из тех же документов, что и обычный набор, но в нём аннотирован только 21 наиболее часто встречающийся семантический тип.

Полумарковская базовая модель получает около 45,3 по F-мере на уровне сущностей [2]. Другие подходы, включая BlueBERT [3] и BioBERT [4], были протестированы и улучшили оценку до 56,3 балла, используя точное соответствие на уровне сущностей [5]. Обратите внимание, что все эти подходы являются контролируемыми и, следовательно, полагаются на определённое совпадение между обучающим и тестовым множеством в плане понятий. Если понятие или метка никогда не встречалась в процессе обучения, в подходе машинного обучения с учителем будет сложно её правильно классифицировать. Далее в качестве меток мы будем использовать семантические типы из набора данных MedMentions.

QuickUMLS: без учителя и на основе знаний

В отличие от BERT QuickUMLS по своей сути является методом без учителя, а это означает, что он не полагается на обучающие данные. Точнее, QuickUMLS это метод, основанный на знаниях. То есть модель, вместо того чтобы иметь параметры, сообщающих, что прогнозировать, для прогнозирования меток полагается на внешнюю базу знаний. Подход подразумевает две вещи:

1. Качество модели ограничено качеством базы знаний. Модель не может предсказать то, чего нет в базе знаний.

2. Модель может обобщать не только аннотированные данные. Модель, которая обучалась с учителем и во время обучения не видела конкретной метки, в целом не может точно предсказать эти вещи. Исключение из правила методы обучения zero-shot.

Zero-shot learning (ZSL) это постановка задачи в машинном обучении, когда во время тестирования алгориттм наблюдает выборки из классов, которые не наблюдались во время обучения, и должен спрогнозировать, к какому классу они принадлежат.

Исходя из этих двух фактов, мы утверждаем, что основанные на знаниях методы хорошо подходят для набора данных MedMentions. Что касается первого пункта, база данных MedMentions была аннотирована с использованием понятий UMLS, поэтому сопоставление между базой знаний и набором данных является точным сопоставлением. Что касается второго пункта, набор данных MedMentions в тестовом наборе содержит понятия, которых нет в обучающем наборе.

Архитектура модели QuickUMLS

QuickUMLS как модель проста. Сначала она анализирует текст с помощью парсера spacy. Затем выбирает словесные n-граммы, то есть последовательности слов, на основе цитат и описаний цитат, а также списков стоп-слов. Это означает, что модель отбрасывает определённые словесные n-граммы, если они содержат нежелательные токены и знаки препинания. Подробные сведения об этих правилах можно найти в оригинальной статье [1]. После выбора кандидатов вся база данных UMLS запрашивается, чтобы найти понятия, частично соответствующие словам n-грамм. Поскольку точное сопоставление в такой огромной базе данных неэффективно и сложно, авторы выполняют приблизительное сопоставление строк с помощью simstring [6]. При задании текста QuickUMLS, таким образом, возвращает список понятий в UMLS вместе с их сходством со строкой запроса и другой связанной информацией. Например, текст У пациента было кровоизлияние, используя (по умолчанию) порог сходства строк 0,7, возвращает следующих кандидатов:

Для слова patient:

{term: Inpatient, cui: C1548438, similarity: 0.71, semtypes: {T078}, preferred: 1},{term: Inpatient, cui: C1549404, similarity: 0.71, semtypes: {T078}, preferred: 1},{term: Inpatient, cui: C1555324, similarity: 0.71, semtypes: {T058}, preferred: 1},{term: *^patient, cui: C0030705, similarity: 0.71, semtypes: {T101}, preferred: 1},{term: patient, cui: C0030705, similarity: 1.0, semtypes: {T101}, preferred: 0},{term: inpatient, cui: C0021562, similarity: 0.71, semtypes: {T101}, preferred: 0}

Для слова hemmorhage:

{term: No hemorrhage, cui: C1861265, similarity: 0.72, semtypes: {T033}, preferred: 1},{term: hemorrhagin, cui: C0121419, similarity: 0.7, semtypes: {T116, T126}, preferred: 1},{term: hemorrhagic, cui: C0333275, similarity: 0.7, semtypes: {T080}, preferred: 1},{term: hemorrhage, cui: C0019080, similarity: 1.0, semtypes: {T046}, preferred: 0},{term: GI hemorrhage, cui: C0017181, similarity: 0.72, semtypes: {T046}, preferred: 0},{term: Hemorrhages, cui: C0019080, similarity: 0.7, semtypes: {T046}, preferred: 0}

Как вы можете видеть, слово patient имеет три соответствия с корректным семантическим типом (T101) и два соответствия с корректным понятием (C0030705). Слово кровоизлияние также имеет лишние совпадения, включая понятие "No hemmorhage". Тем не менее кандидат с самым высоким рейтингом, если исходить из сходства, является правильным в обоих случаях.

В приложении QuickUMLS по умолчанию мы сохраняем только предпочтительные термины, то есть термины, для которых предпочтительным является 1, а затем сортируем по сходству. После мы берём семантический тип (семтип) кандидата с самым высоким рейтингом в качестве прогноза мы называем это базовой моделью (baseline model). Мы использовали seqeval со строгой парадигмой соответствия, которая сопоставима с предыдущей работой [5].

    BERT  QUMLS  P   .53    .27  R   .58    .36  F   .56    .31 Таблица 1  производительность базовой модели

Не слишком впечатляюще, правда? К сожалению, базовая модель страдает от плохого случая, когда она не оптимизирована для конкретной задачи. Таким образом, давайте оптимизируем её с помощью простой эвристики.

Улучшение QuickUMLS с помощью некоторых простых оптимизаций

Есть несколько способов улучшить QuickUMLS помимо его первоначальной производительности. Во-первых, отметим, что стандартный синтаксический анализатор, используемый QuickUMLS, по умолчанию является моделью spacy, т. е. en_core_web_sm. Учитывая, что мы имеем дело с биомедицинским текстом, нам лучше применить модель биомедицинского языка. В нашем случае мы заменили spacy на scispacy [7], en_core_sci_sm. Это уже немного повышает производительность без каких-либо затрат.

    BERT  QUMLS  + Spacy  P   .53    .27      .29  R   .58    .36      .37  F   .56    .31      .32 Таблица 2  Замена на scispacy

Другие улучшения можно получить, используя некоторую информацию из учебного корпуса. Хотя это действительно превращает QuickUMLS из метода без учителя в метод с учителем, зависимости от большого количества конкретных аннотаций по-прежнему нет. Другими словами, нет явного подходящего шага для конкретного корпуса: улучшения, которые мы собираемся сделать, также могут быть оценены с помощью небольшого набора аннотаций или знаний врача, которыми он владеет по определению.

Оптимизация порога QuickUMLS

Настройки по умолчанию для QuickUMLS включают пороговое значение 0,7 и набор метрик. Метрика определяет, как подсчитывается сходство строк, и может быть установлена в Jaccard, cosine, overlap и dice. Мы выполняем поиск по сетке, по метрике и различным пороговым значениям. Наилучшими результатами оказались пороговые значения 0,99, а это означает, что мы выполняем точные совпадения только с помощью SimString и метрики Jaccard, которая превосходит все другие варианты с точки зрения скорости и оценки. Как видите, мы всё ближе и ближе подходим к производительности BERT.

    BERT  QUMLS  + Spacy  + Grid  P   .53    .27      .29     .37  R   .58    .36      .37     .37  F   .56    .31      .32     .37 Таблица 3  Поиск по сетке параметров

Преимущество добавления априорной вероятности

Напомним, что выше мы просто выбрали лучшего подходящего кандидата, основываясь на том, была ли это предпочтительная строка, и на их сходстве. Однако во многих случаях разные понятия будут иметь одно и то же строковое представление, как, например, в вышеупомянутом примере с alcohol. Это затрудняет выбор оптимального кандидата без модели устранения неоднозначности, которая требует контекста, и снова превращает проблему обучения в проблему обучения с учителем или по крайней мере требующую примеров контекстов, в которых встречаются термины. Один из простых выходов из этой головоломки состоит в том, чтобы учесть, что при прочих равных условиях некоторые семантические типы просто более вероятны и, следовательно, более вероятны в данном корпусе. Такая вероятность называется априорной вероятностью.

В нашем случае мы оцениваем априорную вероятность принадлежности к классу через обучающий набор данных, как это было бы сделано в хорошо известном наивном Байесовском классификаторе. Затем для каждого семантического типа, который мы извлекаем, в свою очередь, для каждого набора кандидатов, мы берём максимальное сходство, а затем умножаем его на предыдущий. В терминах нейронной сети вы можете представить это как максимальное объединение на уровне класса. Оно также означает, что мы игнорируем приоритетность кандидатов.

    BERT  QUMLS  + Spacy  + Grid  + Priors  P   .53    .27      .29     .37       .39  R   .58    .36      .37     .37       .39  F   .56    .31      .32     .37       .39 Таблица 4  Добавление приоров

К сожалению, это всё, что мы могли бы получить, используя простую систему в QuickUMLS. Учитывая, что мы в конечном счёте использовали порог 0,99, это означает, что мы вообще не используем функциональность приблизительного сопоставления QuickUMLS. Удаление приблизительного сопоставления также значительно ускорит работу всей системы, так как большая часть времени алгоритма теперь тратится на сопоставление в QuickUMLS.

Глубокое погружение в анализ ошибок: соответствовало ли наше решение поставленной задаче?

Когда мы выполняем задачу распознавания именованных сущностей, мы можем допустить ошибки нескольких типов. Во-первых, мы можем извлечь правильный промежуток, но неправильный класс. Это происходит, когда мы находим правильный термин, но даём ему неправильную метку: например, мы думаем, что alcohol относится к напитку, в то время как он относится к дезинфицирующему средству. Во-вторых, мы также можем извлечь промежуток частично, но при этом всё равно сопоставить его правильной метке. В этом случае возможно рассматривать совпадение как частичное совпадение. В нашем скоринге мы считали правильными только точные совпадения. Пример извлечение мягкого анестетика, когда золотым стандартом является анестетик. Мы также можем полностью пропустить какие-то промежутки, например потому, что UMLS не содержит термина, или извлечь не соответствующие упоминаниям золотого стандарта промежутки. На рисунке ниже показано, какие виды ошибок допускает наша система:

Это показывает, что ошибки, которые делает QuickUMLS, не относятся к одной конкретной категории. Она извлекает слишком много элементов, но, когда она делает это, то также часто присваивает им неправильную метку. Это показывает, что QuickUMLS можно использовать в качестве системы предварительного извлечения, после чего для назначения правильной метки можно применить систему устранения неоднозначности.

Заключение

Как вы можете видеть из результатов, готовая система извлечения терминологии может быть использована в качестве эффективной системы NER без обучения. Получение обучающих данных для конкретных случаев применения часто может быть трудоёмким, снижающим скорость R&D процессом. Построенный нами классификатор QuickUMLS показывает, что мы можем многого добиться с очень небольшим количеством обучающих примеров. И, будучи разумными в том, как использовать ресурсы, мы в процессе исследований и разработок для биомедицинских исследований сэкономили много времени. Модифицированный классификатор QuickUMLS можно опробовать здесь, на github. Преимущество подхода может означать, что мы нашли решение, достаточно надёжное для достижения конечного результата, простое в разработке и тестировании, а также достаточно небольшое, чтобы легко внедрить его в разработку продукта.

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

Вместе с тем одни из самых успешных моделей так или иначе комбинируют подходы из разных областей ИИ, например мы писали о визуализации пения птиц, чтобы ИИ работал со звуком так же, как работает с изображениями и если вам интересна не только обработка естественного языка, но и эксперименты с ИИ в целом, вы можете обратить внимание на наш курс "Machine Learning и Deep Learning", партнёром которого является компания NVIDIA.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering