​​Новые вакансии в Embedika🎉

Наша команда растёт, и сейчас мы ищем разработчиков сразу в два офиса — в Москве и Екатеринбурге. Успешным кандидатам предстоит работать над корпоративными системами для крупного бизнеса, погружаться в сферу data science, machine learning и других перспективных технологий.

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

Переходите по ссылкам, знакомьтесь с вакансиями, откликайтесь:

- Scala разработчик, г. Москва
- Scala Junior+ разработчик, г. Москва
- Scala разработчик, г. Екатеринбург
- Scala Junior+ разработчик, г. Екатеринбург
- Angular Junior разработчик, г. Екатеринбург

​​Наш юрист-аналитик Диана Хакимова написала колонку для vc.ru об образовании в LegalTech.

В ней Диана объясняет, зачем профессиональному юристу получать знания в этой сфере, делится личным опытом и рассказывает, куда пойти учиться.

​​Быстрый и точный поиск корпоративных знаний, автоматическая проверка договоров, совместное создание и согласование документов — лишь часть наших решений, в основе которых — технологии data science.

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

​​В новом выпуске рубрики «Просто о Data Science» Антона Балтачева разберем задачи, которые стоят перед NLP-инженерами.

🗒 Какие задачи стоят перед NLP-инженерами

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

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

➝ Чат-боты стали обычным явлением: они помогают решать самые частые проблемы клиентов компаний без участия человека.
Сейчас такие инструменты создаются для решения конкретных проблем пользователя. Например, понять, почему при переводе на карту другого банка появилась комиссия, поможет «Олег» из банка «Тинькофф», а оказать эмоциональную поддержку от небезразличного собеседника в любую минуту может Replica AI.

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

Эта нейросеть способна автоматически создавать крайне правдоподобные тексты. Это и возможность, и угроза — разработчики GPT-3 не опубликовали исходный код нейросети, опасаясь, что ей могут воспользоваться злоумышленники для создания правдоподобных фейковых новостей, сненерированных отзывов на маркетплейсах или агрессивных и оскорбительных комментариев в социальных сетях.

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

Зачастую проверенную информацию от ложной трудно отличить даже тогда, когда ее создал человек: так, журналисты некоторых СМИ копировали новости с сатирического издания «Панорама», пока не поняли, что это фейк ньюс. У алгоритмов фальшивые новости скоро будут получаться лучше, чем у человека. Посмотреть на генерацию и детектор фальшивых статей на английском языке можно здесь.

➝ Еще одна NLP-задача — выделение ключевых фраз из текста. Речь идет об автоматическом создании кратчайшей выжимки из большого объема информации.

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

В следующих постах рассмотрим, как инженеры решают описанные выше задачи — какие инструменты используют и с какими проблемами сталкиваются.
#простооdatascience

​​В очередном выпуске рубрики Ивана Меньших «Data Science в реальном мире» рассказываем о данных и о том, насколько важно подготовить их до начала работы над data science-решением.

🗒 Данные — это все, что у нас есть

Данные — это новая нефть. Сейчас мы можем хранить и агрегировать разнородную информацию, — это открывает бизнесу доступ ко всему спектру решений на основе машинного обучения (ML). Еще 20 лет назад компании, которые занимались исключительно разработкой ML-решений, можно было пересчитать по пальцам. Сейчас их тысячи, — а тех, у кого есть компетенции для создания решений на основе машинного обучения, еще больше.

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

Чтобы избежать такой ситуации, перед внедрением стоит предпринять ряд шагов:

➝ Заранее проконсультироваться со специалистами по машинному обучению на предмет того, какие данные можно собирать прямо сейчас.
➝ Собирать данные в автоматическом режиме. Потенциальная польза, как правило, существенно выше, чем затраты на их хранение.
➝ Собирать данные в наиболее «сыром» виде. Преобразовать их можно в любой момент, а обратить изменения не всегда возможно.
➝ Делиться данными с исполнителем как можно раньше, давая ему возможность лучше подготовиться к конкретному кейсу.
➝ Самое главное — проводить пилотный запуск перед интеграцией для реальной оценки пользы, рисков и возможной адаптации моделей исполнителя к вашим данным (если он предоставляет такую опцию).

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

​​Руководитель продуктового направления в нашей компании Артем Низамов написал колонку для «Хайтека» о внедрении data science-решений в России.

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

​​Юрист-аналитик Диана Хакимова и руководитель R&D Геннадий Штех обсуждают новую разработку Сбербанка в издании Rusbase — поможет ли запатентованная система проверки юрлиц на базе искусственного интеллекта специалистам и есть ли в решении ноу-хау с точки зрения технологий.

Кстати, мы уже писали о трендах и барьерах в сфере LegalTech в нашем блоге — почитать можно здесь.

​​20 октября DataStart проведет онлайн-конференцию, посвященную большим данным, машинному обучению и внедрению технологий в бизнес. В мероприятии примет участие руководитель R&D в нашей компании Геннадий Штех — он представит гайдлайн о том, как проще и быстрее всего получить работающий алгоритм, классифицирующий тексты.

Вот что Геннадий говорит об этом: «На данный момент есть много модных алгоритмов, много разных подходов для работы с текстами. Я выбрал наиболее применимые в широком кругу задач и подготовил примеры. Такого материала лично мне не хватало еще 5-7 лет назад. Будет весьма полезно тем, кому нужно быстро получить приемлемый результат».

Участие бесплатное, регистрация — по ссылке.

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

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

Часть 1. Правильная постановка задачи — залог успеха

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

Очень важно “на берегу” договориться, какое качество работы системы будет считаться приемлемым. Допустим, сервис извлечения ключевых фраз должен выдавать в топ-5 фразы, которые непосредственно относятся к теме документа и дают понять, о чем он, даже не читая его. Хотя это довольно расплывчатая формулировка, она задает некоторый стандарт качества.

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

Итак, прежде чем приступать к решению задачи, сосредоточьтесь на правильной её постановке. В следующем посте поговорим о подготовке данных и выборе метрик.
#простооdatascience

​​В сегодняшнем выпуске рубрики «Просто о 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 в нашей компании, о естественном языке и его влиянии на результаты работы машинного обучения.

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

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

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

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

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

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