​​В сегодняшнем выпуске рубрики «Просто о Data Science» Антона Балтачева продолжим рассказывать о процессе создания продукта в R&D-отделе. Теперь подробнее остановимся на подготовке и качестве данных.

🗒 Как создаются сервисы в R&D-отделе?

Часть 2. Разметка данных и выбор метрик

Зачастую решение задачи требует размеченных данных — определенным образом обработанных документов, звукозаписей или видео, язык которых понимает алгоритм. В нашем примере (сервисе извлечения ключевых фраз) — это выделение в документах конкретных словосочетаний и слов.

Если заказчик предоставил достаточно данных или готов их размечать — это отлично, но, к сожалению, пока с такими ситуациями мы сталкиваемся редко. Чаще данных недостаточно, чтобы модель выучила что-то полезное, и размечать приходится разработчикам.

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

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

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

В следующем посте, завершающем эту тему, расскажу про поиск и проверку гипотез, а также внедрение готового решения. #простооdatascience

В новом выпуске рубрики «Просто о Data Science» NLP-инженер Антон Балтачев продолжает рассказывать о процессе разработки продукта в R&D-отделе. Завершающий пост по этой теме — о процессе формирования гипотез и внедрении решения.

🗒 Как создаются сервисы в R&D-отделе?

Часть 3. Поиск, проверка и реализация гипотез

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

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

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

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

Если заказчику нравится качество, то начинается стадия внедрения сервиса. Здесь возникают новые челленджи: алгоритм должен работать быстро, почти в реальном времени, ведь пользователи не привыкли долго ждать ответ. Поэтому часто приходится оптимизировать алгоритмы и придумывать хаки, которые позволят им не проседать по качеству и быстро отвечать на запрос.

Подводя итог, можно сказать, что разработка data science-продукта сопряжена с высокой неопределенностью: большое количество гипотез оказываются нежизнеспособными. Однако успешный сервис поможет сэкономить много времени. Для примера вернемся к сервису извлечения ключевых фраз: чтение даже небольшой статьи занимает около 10 минут, а сервис сокращает это время до 10-15 секунд, позволяя понять о чём документ, даже не читая его. #простооdatascience

Через полчаса встречаемся на онлайн-конференции DataStart. 17 докладов, разделенных на 2 потока – технический и бизнес.

Ведущий технического потока – руководитель R&D в нашей компании Геннадий Штех, ведущий бизнес-потока – юрист-аналитик Диана Хакимова. Задавайте вопросы спикерам в чат, мы их обязательно озвучим.

А в 17:00 в техническом треке Геннадий расскажет про нейросети на текстах.

​​В своих решениях мы уделяем большое внимание дизайну интерфейсов — важно, чтобы работать в системе было просто и удобно. Поэтому, когда пришла пора разрабатывать корпоративный сайт, нам хотелось, чтобы он отражал наш подход.

С командой из Flat12 мы сразу нашли общий язык: разработали несколько концепций, выбрали лучшую, проработали каждый блок.

Недавно наш сайт занял 2ое место в Рейтинге Рунета — всероссийской премии, проводимой среди разработчиков и владельцев сайтов. И если вы не заходили к нам, то эта награда — ещё один повод это сделать:) embedika.ru

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

▶️Иван Меньших о самых распространенных ошибках разработчиков data science-решений
▶️Антон Балтачев о том, как создаются сервисы в R&D-отделе.

Полностью колонки авторов можно почитать, перейдя по тегам #простооdatascience и #datascienceвреальноммире.

​​Недавно завершился хакатон «Лидеры цифровой трансформации» от Агентства инноваций Москвы. Для команд-победителей хакатона организован Mosbootcamp —
онлайн-интенсив по доработке решений, где участники общаются с экспертами и работают с менторами.

В рамках кэмпа мы прочитаем две лекции:
- Пошаговый гайд по работе с крупным бизнесом.
Спикер: Артём Низамов, руководитель продуктового направления в Embedika.
25 ноября в 19:00. Ссылка.
- Типичные ошибки разработчиков DS-решений.
Спикер: Антон Балтачев, NLP-инженер в Embedika.
26 ноября в 19:00. Ссылка.

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

​​Ровно через 2 часа подключайтесь к онлайн-лекции от руководителя продуктового направления нашей компании Артема Низамова.
Артем расскажет, на что стоит обратить внимание при работе с крупным бизнесом и гос.заказчиками на каждом этапе: от инициации проекта до его закрытия.

Хотите обсудить тему или задать вопрос спикеру — присоединяйтесь по ссылке, пишите в чат или приготовьте гарнитуру — тема большая и интересная, будем рады обменяться опытом:)

​​Сегодня в 19:00 NLP-инженер Антон Балтачев поделится самым ценным опытом при разработке data science-решений, а именно — опытом того, как делать не надо:)

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

Переходите по ссылке ровно в 19:00, будем рады вашим вопросам!

​​Оценка эффективности data science-решения часто вызывает много вопросов, поскольку на этом этапе заказчик и разработчики говорят на разном языке. Как избежать недопонимания и оценить пользу продукта расскажут ведущий разработчик машинного обучения Иван Меньших и NLP-инженер Антон Балтачев в совместной рубрике “DS-метрики и бизнес”.

🗒 DS-метрики и бизнес.

Часть 1. Задавайте клиенту больше вопросов

Специалистам по машинному обучению требуется численный способ оценить качество модели, поэтому они пользуются метриками.
К сожалению, формальные метрики (precision, recall, F1, ROC AUC и прочие) не заточены под бизнес заказчика. Это может привести к недопониманию, т.к. ML-специалист оптимизирует именно ту метрику, на которую ориентируется, а бизнес ждет от него чего-то другого.

Чтобы избежать подобной ситуации, стоит как можно раньше задать вопросы заказчику:
➝ Как он в данный момент решает задачу? Почему его не устраивает текущее решение, если оно есть?
➝ Что именно он ожидает от ML-решения?
➝ Каким образом он планирует оценивать изменения? Как выглядит бизнес-метрика?
➝ Какие ошибки для него более критичны и в какой степени (False Positives/False Negatives/их пропорция)?

Ответы на данные вопросы позволят ML-специалисту:
➝ Корректно поставить задачу машинного обучения
➝ Выбрать "наиболее удачную" метрику для оценки. Конечно, она не будет полностью совпадать с "бизнес-метрикой", но очень желательно, чтобы она была хорошо с ней скоррелирована
➝ Ориентироваться на ожидания клиента при обучении моделей.

При всем этом нужно иметь в виду, что заказчик тоже может ошибаться, поэтому не пренебрегайте демонстрациями промежуточных решений и внимательно собирайте обратную связь — она определенно не будет лишней. #dsметрикиибизнес

​​Продолжаем рассказывать о выборе метрик для оценки data science-решений. В прошлой части выяснили, какие вопросы стоит задать заказчику, чтобы выбрать наиболее релевантные метрики. Сегодня обсудим, на что нужно обратить внимание самим разработчикам.

🗒 DS-метрики и бизнес

Часть 2. Задавайте больше вопросов разработчикам

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

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

1️⃣ Не пытаюсь ли я доказать свою правоту?
Иногда ML-специалисты могут не замечать проблемы своих решений и подсознательно бояться отрицательных результатов на различных метриках и демонстрациях.
Когда специалист полгода пытался реализовать свою идею, он не захочет, чтобы задумка провалилась и ушла в небытие.

2️⃣ Если после первого вопроса появились сомнения задайте еще один — использую ли я всю доступную информацию для принятия решения?
Можно доказать жизнеспособность метода, опираясь только на те метрики, которые демонстрируют положительный результат.
Поэтому важно строить все возможные формальные метрики, которые коррелируют с бизнес-задачей. Использовать не только точечные метрики, но смотреть на распределения этих метрик, различные графики, — все, что может дать дополнительную информацию.
Однако нужно помнить изначальную цель подобных исследований и не увлекаться опровержением решения — сделать это легче, чем доказать положительный результат.

3️⃣ Если же все-таки вы чувствуете, что подверглись когнитивному искажению, то необходима помощь стороннего асессора (валидатора результатов).
Важно, чтобы вы не воздействовали на него — валидация должна происходить вслепую: асессор не должен знать результат какого метода ему демонстрируют, а также он не должен быть заинтересован в получении профита, если его решение подтвердит или опровергнет гипотезу.
В данной ситуации можно прибегать к А/Б тестам на выборке случайных людей на аутсорсе. Про преимущества и недостатки А/Б тестов напишем в следующих постах.

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

​​В этом блоге мы уже много говорили о том, что такое обработка естественного языка с точки зрения технологий. Однако сам язык всегда остается за кадром, хотя именно он — предмет обработки. Представляем новую авторскую рубрику Полины Казаковой, data scientist в нашей компании, о естественном языке и его влиянии на результаты работы машинного обучения.

🗒Естественный язык против искусственного интеллекта

Почему модели обработки языка не идеальны и допускают ошибки, что стоит за этими ошибками, почему возникают те или иные языковые явления, может ли машина по-настоящему понять язык? В фокусе этой рубрики — естественный язык и его связь не только с компьютерными методами, но с лингвистическими и когнитивными процессами.

Начнем с примера. Как вы поняли, что в предыдущем абзаце речь идет о языке, на котором говорят люди, а не, например, об органе? Можно сказать, что из сочетаемости слов и контекста. Мы откуда-то знаем, что сочетания естественный язык, автоматическая обработка языка имеют смысл, когда мы имеем в виду знаковую систему, которую люди используют для общения и передачи информации.

Явление, когда одно слово имеет несколько разных значений, называется полисемией. Но почему вообще в языке существует многозначность? Язык — система не статичная, он постоянно меняется — обратите внимание, что мы не разговариваем на древнерусском! Изменениям подвержена не только внешняя форма слова, то есть его звучание / написание (например, раньше был кОфий, а теперь это кофе), но и его смысл (например, раньше слово глаз обозначало шар или камень, а сейчас это орган зрения). Новые смыслы могут выделяться из существующих посредством различных механизмов, например, с помощью метафорического переноса — как в случае с глазом, где, по-видимому, свойство шарообразности из первоначального смысла дало толчок новому значению. Пример из сегодняшних дней: груша — фрукт, и груша — боксерская, напоминающая по форме фрукт.

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

Явления, когда одному и тому же по написанию слову соответствуют разные значения (будь то полисемия, омонимия или что-то между), конечно же создают проблемы для машинных методов. Как объяснить модели, что внешне одинаковые по форме сущности на самом деле разные? Представьте, как непросто бывает обучить машину понимать человеческий язык, ведь даже у людей порой возникают сложности с восприятием родного языка.

​​От разработчиков часто можно услышать, что успех решения напрямую зависит от количества и качества исходных данных. Но как понять, сколько данных нужно и каких? Рассказывает ведущий разработчик машинного обучения Иван Меньших в новом выпуске авторской колонки «Data science в реальном мире».

🗒Какие данные нужны разработчикам
Часть 1. Плохие и хорошие данные

Любое DS-решение критически зависит от данных. В их отсутствии решить проблему, как правило, невозможно (но, конечно, бывают и исключения). Возникает вопрос: а как понять, насколько «хороши» те данные, которыми мы располагаем?

Как ни странно, чтобы ответить на него, поделитесь данными с теми, кто планирует внедрить вам ML-based решение и попросите их оценить. Таким образом, вы получите:

- Конкретные комментарии, что хорошо/плохо
- Вопросы о том, как вы их собираете и обрабатываете, что может повлечь рациональные предложения со стороны подрядчика по улучшению данного процесса — они заинтересованы, чтобы их решение работало хорошо
- Если повезёт — демо с комментариями, как именно текущие проблемы с данными влияют на результат.

Очень важно делиться наиболее репрезентативными данными, ведь вас интересует решение, которое сможет работать с реальными данными. Это поможет избежать популярной проблемы «решение хорошо работает на демо, но в ‘диком мире' выдаёт совершенно непригодный результат». #datascienceвреальноммире

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

🗒Какие данные нужны разработчикам
Часть 2. Сколько данных нужно?

Следующий возникающий вопрос: а сколько нужно данных, чтобы получить достоверное понимание о качестве решения? Короткий ответ: чем больше — тем лучше, и это сильно зависит от поставленной задачи.

На практике же, процесс происходит итерационно:
- Вы делитесь данными с подрядчиком. Как правило, это небольшой кусок данных, например 100-200 примеров
- Подрядчик готовит решение на основе этих данных
- На демо показываются как формальные метрики, так и качество работы решения «на глаз» (не стоит недооценивать популярную метрику wtf)
- Вы даёте подрядчику новые данные и процесс повторяется до тех пор, пока вы не будете довольны результатом или подрядчик сдастся.

Как правило, именно такой подход позволяет получить наилучшее решение, а также лучше понять ваши данные. #datascienceвреальноммире

​​После запуска первого сервиса мы начали искать идеи для новых онлайн-инструментов, которые могли бы упростить работу юристов, делопроизводителей и всех тех, кто работает с документами. Для создания такого решения мы объединились с командой юридического департамента компании «Сименс» и начали разработку сервиса для анализа ответственности по договору.

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

Если для вас актуален такой инструмент, и вы хотите принять участие в тестировании — напишите нам на hello@embedika.ru, и мы отправим вам ссылку на сервис.

​​Друзья, поздравляем вас с наступающими праздниками! Спасибо, что были с нами, читали наш блог, следили за авторскими колонками и новостями.
В последние дни 2020-ого хотим подвести итог — рассказать, что интересного произошло в отрасли и чем нам запомнится этот год. Новогоднюю серию постов открывает продуктовая команда.

▶️Айканыш Орозбаева руководитель направления по работе с партнерами
«2020 год запомнится тем, как неожиданно быстро вырос интерес на интеллектуализацию даже у консервативной части ИТ-мира. Общаясь с крупными компаниями и интеграторами, я заметила, что их отношение к технологиям data science изменилось — если раньше их запросы касались больше области автоматизации, то теперь появился спрос на интеллектуализацию текущих ИТ-систем, а именно — практическое решение таких задач, как анализ текстов в договорах, интеллектуализация корпоративных СЭД и т.д.

Сегодня решения на основе big data не кажутся такими «экспериментальными» — в мире, где пиццу заказывает Алиса, а автомобилями управляет программное обеспечение, внедрение в бизнес современных технологий становится новой нормой.

Здорово, что функциональные заказчики все чаще вникают в процессы и участвуют в создании решений совместно с разработчиком — интересуются, какие существуют технологии, как подготовить данные и оценить их. Такая совместная проработка позволяет получить наилучший результат».

▶️Артем Низамов, руководитель продуктового направления
«Открытием этого года стало то, что удаленно можно полноценно работать не только разработчикам и дизайнерам, но и проджектам и продактам — в том числе генерировать новые идеи вместе с командой и партнерами, проводить мозговые штурмы онлайн и даже придумывать и запускать новые продукты.

Например, за этот год мы сделали 2 бесплатных онлайн-сервиса:
- Compare — сравнивает версии документа и показывает отличия между ними. За несколько месяцев сервисом воспользовались более 7,5 тысяч человек.
- Contract — проверяет договора на риски, выявляя в тексте документа условия об ответственности. Сейчас идет тестирование сервиса среди экспертного сообщества, и скоро он станет доступен всем».


▶️Диана Хакимова, аналитик и юрист
«Это был первый год работы нашей команды как продуктовой — мы упаковывали технологии в продукты, формировали гипотезы, проводили custdev. Ранее мы занимались в основном заказной разработкой, и пришлось учиться — проходить профильные курсы и много читать.

Отмечу несколько книг и курсов, которые будут полезны и тем, кто создаёт ИТ-решения, и тем, кто их внедряет:
- Go practice — симулятор работы в продуктовой компании, где учат развивать продукты, используя метрики и аналитику
- видеокурс Яндекса по управлению продуктом и проектами
- книга Inspired Марти Кагана — находка для тех, кто развивает B2B-решения
- книга Спринт от группы авторов из Google про тестирование гипотез. Эта книга вдохновила нас провести бизнес-ужин с экспертами отрасли, где мы всего за пару часов нашли более 5 новых применений нашим технологиям».

​​Продолжаем подводить итоги 2020-ого. На этот раз R&D-команда поделится исследованиями, экспериментами и статьями, которые запомнились им больше всего.

▶️ Антон Балтачев, NLP-инженер
Этот год еще раз доказал насколько правильное использование машинного обучения в сердце продукта может повлиять на его успех. Нельзя не вспомнить тикток, который в этом году рос стремительнее, чем любая соцсеть, сильно нашумел и задал тренд для других компаний (а еще завлек меня в свои лапы). А ведь ничего бы не было без крутой рекомендательной системы, которая чутко учитывает интересы пользователя и выдает идеальный дофаминовый коктейль.

▶️ Полина Казакова, data scientist
В этом году хайп вокруг больших языковых моделей (large language models), таких как BERT и GPT-2/3, повлек за собой бурное обсуждение того, могут ли языковые модели «действительно понимать» язык. Авторы этой очень резонансной статьи показывают, что модели, обученные только на текстовых данных и не имеющие никакой иной информации о мире, не могут обладать настоящим знанием языка. Мысленный эксперимент с осьминогом, Витгенштейн и краткая инструкция по защите от медведя палками – если интересно, к чему это все, советую почитать саму статью. Так же как и этот пост, автор которого провел ее критический разбор и утверждает, что в действительности у нас пока нет оснований отвергать идею о том, что модели понимают язык, а кроме того, мы и сами на самом деле не знаем, что такое «действительно понимать».

▶️ Иван Меньших, ведущий разработчик МО
Этот год нашей команде запомнится развитием культуры разработки и реализацией смелых технологий, одной из самых запоминающихся стал «Македонский».
«Македонский» — универсальный способ проекции разнородных векторных представлений в единое пространство. В 2021 году это позволит нам получать не только качественные мультиязычные вектора для слов и целых текстов, но и мультимодальные представления, обогащенные метаданными, основываясь лишь на небольшом количестве связей.

▶️ Игорь Ляхов, старший разработчик МО
Со времени появления Трансформера (ключевой state-of-the-art нейросетевой архитектуры для задач NLP), стоит вопрос оптимизации данной архитектуры с точки зрения вычислительных ресурсов. Из-за прожорливости его довольно проблематично использовать небольшим лабораториям и компаниям для обучения больших моделей, таких как BERT. Так же пока Трансформер не особо применим к длинным последовательностям. В этом году вышла очень интересная статья «Reformer: The Efficient Transformer», которая предлагает довольно любопытную технику по оптимизации механизма attention'а в трансформере. Предложенный Locality-Sensitive Hashing Attention — оригинальный и очень элегантный способ снизить вычислительные затраты с O(N^2) до O(NlogN), что играет существенную роль на больших коллекциях длинных документов. Подобные идеи вдохновляют другие R'n'D команды на изобретения своих attention для трансформеров под свои задачи.

​​В третьем, заключительном посте об итогах этого года своими впечатлениями делится команда разработки. Ребята живут и работают в Екатеринбурге, и их команда постоянно растет, — вы можете следить за актуальными вакансиями на нашей странице hh.

▶️ Павел Худышкин, ведущий инженер-программист

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

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

▶️ Алексей Пантин, руководитель направления разработки и внедрения

В этом году я открыл для себя книгу «Несовершенная случайность. Как случай управляет нашей жизнью» Леонарда Млодинова. С помощью базовых методов статистики и теории вероятности книга научит распознавать «псевдо-последовательности» — последовательности, которые только кажутся нам реальными.

Книга не имеет прямого отношения к ИТ, но будет полезна многим и поможет сэкономить ваши силы и время.

▶️ Полную версию итогов года от трёх команд — продуктовой, RnD и разработки — можно почитать на нашем сайте. До встречи в новом году!

NLP-инженер Антон Балтачев рассказал vc.ru о 9 способах эффективной коммуникации с разработчиками. Делитесь своими в комментариях к статье:

https://vc.ru/life/214977-metch-mezhdu-razrabotchikom-i-menedzherom-9-sposobov-ne-besit-drug-druga

​​Наше решение — система интеллектуального кросс-языкового анализа текстовых данных, — опубликовано в Библиотеке эффективных кейсов AI Russia Works.

AI Russia — проект Альянса по развитию искусственного интеллекта, в который входят крупнейшие технологические компании России. Задача проекта — представить российские решения с доказанной эффективностью, в которых используется AI.

Подробнее о том, как работает наше решение и его бизнес-эффектах, читайте на карточке проекта в Библиотеке AI Russia Works.

Диана Хакимова, юрист-аналитик в нашей компании, рассказала изданию rusbase, как технология ML помогает в анализе юридических документов и какие барьеры ограничивают ее повсеместное внедрение.

Ищите в статье ссылку на наш новый онлайн-сервис, который мы разрабатываем вместе с юридическим департаментом компании «Сименс»: https://rb.ru/opinion/ml-for-document-analysis/

​​Онлайн-сервис проверки договоров на риски

Рады представить новый сервис, который мы разработали совместно с юридическим департаментом компании Siemens, — Embedika Contract!

Contract выявляет в тексте документа условия, на которые стоит обратить внимание перед заключением договора, и дает рекомендации по изменению нежелательных формулировок. Поддерживает форматы DOC, DOCX и PDF, сохраняет исходное форматирование и подсвечивает найденные риски. Работает без регистрации и полностью конфиденциальный.

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

Скорее пробуйте, оставляйте отзывы и не забудьте поделиться с коллегами:)