Русский
Русский
English
Статистика
Реклама

Abbyy

Чем занимается главный архитектор в ABBYY? Интервью с Владимиром Юневым

06.08.2020 14:19:11 | Автор: admin
Так устроена наша компания, что она не может не развиваться. В прошлом году ABBYY приобрела TimelinePI разработчика платформы для анализа бизнес-процессов и вышла на новый рынок. А сейчас мы активно переходим на современные облачные архитектуры.

Конечно, пока за рубежом cloud-сервисами пользуются активнее, чем в России. По данным Gartner, в 2019 года мировой рынок публичных облаков составил $242,7 млрд, а в нашей стране пока 73 млрд рублей (~$1 млрд), следует из отчета ТМТ Консалтинг, хотя в России этот рынок растет быстрыми темпами.

Наши международные клиенты уже пользуются решениями, которые работают в облаке, например, ABBYY FlexiCapture и Cloud OCR SDK. Они помогают заказчикам автоматически распознавать штрихкоды, извлекать из товарных накладных суммы и даты и многое другое и делать все это со всевозможных устройств, различных операционных систем, удобно и безопасно. Нам бы хотелось, чтобы наши интеллектуальные решения становились еще доступнее для пользователей. Ведь даже в пандемию компаниям во всем мире все равно нужно обрабатывать счета, готовить налоговую отчетность, сравнивать написанное мелким шрифтом в разных версиях кредитных договоров, а также внедрять решения для удаленного обслуживания клиентов. Чтобы все эти задачи можно было решить в любое время, где угодно и в необходимом объеме, мы взяли курс на интеграцию наших продуктов с облачными технологиями.

Именно поэтому в 2019 году в нашей команде появился главный архитектор человек с хорошим знанием подходов к созданию архитектуры программного обеспечения в компании сегмента B2B и с большим опытом в построении и развитии облачных сервисов. Им стал Владимир Юнев, в прошлом облачный архитектор и эксперт по стратегическим технологиям Microsoft, известный в сообществе на Хабре как @XaocCPS.

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

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

Я начал работать в 17 лет в компании, которую образовали преподаватели ВУЗа, где я учился. Там на C++ и ассемблере мы уже в 1998 году делали то, что сегодня называют IoT. Мы автоматизировали процессы по обеспечению безопасности шахт: для этого собирали десятки метрик, анализировали их, предсказывали взрывоопасные ситуации. Набравшись опыта низкоуровневого программирования, я ушел работать в финансовое учреждение, где занимался клиент-серверной разработкой. Затем перешел в крупную IT-компанию, где начал разрабатывать первые продукты на базе веб-технологий. Примерно в 2005 году я перебрался в Свердловскую область и там работал над крупным публичным банковским порталом, который функционирует и сейчас.

В Екатеринбурге я познакомился с тусовкой разработчиков, использующих технологии Microsoft, а затем и с техническими представителями компании. Мы много общались и однажды с одним из сотрудников решили написать книгу про новую на то время технологию ASP.NET MVC. Книга вышла через год, и тираж раскупили за пару недель.

Я продолжал тесно общаться со специалистами Microsoft, мы делали совместные проекты, и вскоре я получил приглашение на работу. В 2011 году я стал экспертом по стратегическим технологиям Microsoft и за 6 лет получил все основные навыки, которыми обладаю сейчас. Сложно переоценить, как много дает работа в крупной глобальной ИТ-компании. Набравшись опыта в веб- и облачных технологиях, помогая внедрять и использовать их в стартапах, партнерах и клиентах Microsoft, я перешел на главную для себя роль облачного архитектора.

Облачный архитектор помогает клиентам компании эффективно применять купленные облачные сервисы и технологии. Я работал над проектами в таких крупных компаниях, как Сбербанк, Лаборатория Касперского, Тандер (сеть Магнит), Балтика и других. Кроме того, мы общались и с ABBYY, где у нас было много добрых знакомых.

Как ты попал в ABBYY и почему именно на должность главного архитектора?

На самом деле, это забавная история. На тот момент я проработал более трех лет архитектором в Microsoft. Осенью 2019 года я отдыхал с семьей в Турции и как-то просматривал на пляже уведомления на телефоне. Одно из них, судьбоносное, было от LinkedIn со списком подходящих для вас вакансий, среди которых я заметил должность Chief Architect в ABBYY. Ответить на предложение можно было в один клик, и я решил испытать судьбу, не особенно рассчитывая на результат. Работы я не искал, но всегда смотрел на рынок, изучая, какие в наше время требуются технологии и навыки. Позиция Chief Architect в одном из лидеров рынка тогда сразу показалась мне логичным развитием карьеры. В результате я стал главным архитектором и подключился к работе над очень интересными проектами компании.

Насколько я знаю, в ABBYY до твоего прихода не было должности главного архитектора. Получается, ты начал выстраивать работу в ABBYY c нуля? Расскажи об этом подробнее.

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

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

Чем ты занимаешься в ABBYY каждый день?

Мы в ABBYY разрабатываем решения, которые помогают компаниям автоматизировать процессы и быстрее решать рутинные задачи, например, обрабатывать информацию из сотен тысяч товарных накладных, счетов-фактур, актов и вносить данные из них в учетные системы.
Сегодня наш стек технологий построен на базе современных платформ и инструментов с открытым исходным кодом. Это такие платформы как Kubernetes и Docker c обширным набором инструментов из экосистемы, средства хранения и обработки данных Redis и PostgreSQL, платформа и языки разработки .NET Core и C#, средства обмена сообщениями RabbitMQ и так далее.

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

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

Расскажи про NeoML: как вы готовились к запуску библиотеки на GitHub и какие вызовы стояли перед вами?

NeoML масштабный проект, над которым команда ABBYY работала не один год. О том, как происходило создание библиотеки и о ее технических подробностях, мы рассказали в недавнем посте на Хабре.

Я пришел в компанию 19 декабря и мне поручили руководить выпуском фреймворка в open source. Над этим работала по-настоящему классная команда из самых разных департаментов. 16 июня мы официально опубликовали NeoML на GitHub. Работы за полгода было проделано много: подготовка и инспекция исходного кода, создание примеров приложений, перевод документации и комментариев, организация маркетинговой кампании, юридическое сопровождение и множество других мелких задач. Самым интересным и довольно сложным занятием оказался выбор названия библиотеки. Это заслуживает отдельной статьи, но, если кратко довольно тяжело в наши дни подобрать название ИТ-продукта так, чтобы оно не нарушило торговые марки других участников рынка.

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

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

Расскажи немного о своей команде: много ли в ней человек, как вы взаимодействуете?

Команда NeoML небольшая, но очень профессиональная, и я горжусь, что работаю с ней. У нас 5 разработчиков, включая тимлида, менеджера проекта и девопс-инженеров, которые помогают нам с инфраструктурными задачами. С составлением и переводом документации нам помогают опытные технические писатели. Кроме того, нашу команду поддерживает руководство департамента Product Development, куда входит и R&D. Оно активно участвует в стратегическом планировании развития библиотеки.

Какие у тебя впечатления об атмосфере работы в ABBYY? Компания чем-то отличается от других мест, в которых ты работал?

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

ABBYY международная компания. Многие коллеги работают в зарубежных офисах, и мы периодически общаемся онлайн. Кроме того, меня и других сотрудников приглашают сопровождать встречи с крупнейшими клиентами по всему миру из США и стран Европы, где мы общаемся и отвечаем на вопросы, рассказываем о наших архитектурных и технических решениях. Сегодня заказчики обладают глубокими техническими знаниями и хотят знать подробности продуктов.

На твой взгляд, какими знаниями, навыками и опытом важно обладать хорошему главному архитектору?

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

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

Для того чтобы быть в курсе трендов, потребуется тщательно отобрать источники информации, которые будут ежедневно поставлять новости. Это могут быть аккаунты инфлюенсеров (еще один термин из евангелизма, который означает ключевых персон в том или ином направлении) в социальных сетях; блоги крупнейших вендоров компаний, которые влияют на рынок своими продуктами и вкладом в технологии (например, блоги AWS, Google и Azure на тему новинок в облаках); новостные агрегаторы по темам как от крупных изданий, так и от энтузиастов, которые публикуют подборки новостей и технических статей. Наконец, заведите подписку на один из сервисов технической литературы, чтобы получить доступ к самым свежим книгам и публикациям.

Что бы ты посоветовал тем, кто хочет стать главным архитектором?

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

Мой топ-3 книг для начинающих архитекторов распределенных систем:


Есть ли у тебя видение, какое будущее ждет рынок интеллектуальной обработки информации и анализа бизнес-процессов лет через 5-10?

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

Вместе с этим, объемы информации будут расти еще быстрее. Согласно исследованию IDC Data Age 2025, к 2025 году общий объем новых данных увеличится до 175 ЗБ по сравнению с 33 ЗБ в 2018 году. Нам кажется, что вокруг много информации, но ее станет еще больше. Что с ней делать? Анализировать, сортировать, выделять значимое и автоматизировать все эти процессы, чтобы видеть только самое полезное. И здесь пригодится опыт компании ABBYY. Наши клиенты получают самые современные инструменты для извлечения информации, интеллектуальной обработки данных и автоматического анализа процессов. С каждым годом мы делаем наши продукты все более интеллектуальными и умными, а наши клиенты пользуются этим, чтобы управлять потоком информации.

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

Как главный архитектор, как ты думаешь, за какой архитектурой ИТ-проектов будущее? К чему все движется?

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

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

Ваш звонок очень важен для нас как перестать разочаровываться в контакт-центрах и начать жить

15.03.2021 16:12:10 | Автор: admin
Как часто вы разочаровывались в контакт-центрах? Как это бывает, позвонили узнать о минимальном платеже по кредитке или выяснить, как разблокировать доступ в интернет-банк. Но сразу решить вопрос не удалось. Запутались в дебрях голосового меню. Поняли, что любая кнопка все равно приведет в никуда к замученному неправильным скриптом оператору. Ждали на линии первого освободившегося сотрудника. Затем 8 раз слушали Blue Da Ba Dee, когда он ставил звонок на удержание. В результате бросили трубку и запланировали поездку в офис банка.

Вы никогда не задумывались о том, почему в век мессенджеров люди пользуются голосовой связью? По данным Национальной ассоциации контактных центров (НАКЦ), в России за время пандемии 25% контакт-центров не зафиксировали уменьшения количества звонков, а 27% отметили рост объема обращений на 25%. Понятно, из-за COVID-19 у всех появилось больше поводов для беспокойства: Когда доставят мой заказ?, Что с моими ваучерами?, Вернут ли мне деньги?. Компании вкладывают сотни тысяч рублей в автоматизацию контакт-центров и обучение сотрудников, но что-то идет не так.

Возможно, проблема в подходе. Решения об автоматизации принимаются интуитивно, на основе наблюдений или методом научного тыка. Между тем в работе контакт-центра много неочевидных закономерностей, за которыми полезно наблюдать не в ручном режиме, а с применением технологий интеллектуального анализа бизнес-процессов (Process Intelligence). В информационных системах контакт-центров собирается много полезных данных блуждания клиентов по IVR (Interactive Voice Response), логи телефонных разговоров (время и длительность, с какого номера звонили) и др.

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

Немного статистики


По данным НАКЦ, сильнее всего на эффективность общения сотрудников контакт-центров с клиентами в условиях пандемии влияют:

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

Как говорится в исследовании аналитического агентства iKS-Consulting, клиенты до сих пор предпочитают общаться с компанией по телефону. Правда, количество звонков в контакт-центры не растет. А вот сообщений по электронной почте, через чаты и мессенджеры становится больше на 2% ежегодно: их доля от общего количества обращений 20%. Роботы помогают клиентам не висеть долго на линии, а сотрудникам избежать монотонной обработки простых запросов. Но, несмотря на внедрение технологий искусственного интеллекта и роботизацию, пока в основном в контакт-центрах работают люди. Только они могут помочь клиентам решить сложный вопрос или разобраться в нетипичной ситуации. Более того, в век развития искусственного интеллекта (а также необходимости оставаться дома) эмпатия и живое общение становятся еще более ценными.

Например, до пандемии в Сбербанк поступало около 17 млн звонков в месяц и примерно 3 млн чатов. Половина клиентов получали помощь от ботов голосового на номере 900 и текстового в чатах. С апреля 2020 года каждый месяц банк получает до 23 млн звонков (+30%), а уже 60% всех вопросов решается в IVR.

Но так ли все прекрасно в работе контакт-центров в банках? По данным аналитического центра Национального агентства финансовых исследований (НАФИ), лояльность россиян к банкам снижается пятый год подряд. Своим банком, согласно последнему опросу, не удовлетворены 35,4% жителей страны. Они не порекомендуют его знакомым и, возможно, скоро найдут альтернативу.

Индекс NPS в динамике (2016-2020 гг.). Данные НАФИ

По оценке НАФИ, клиенты обращают больше всего внимания на стоимость счетов, депозитов, кредитов и качество обслуживания. Им важно быстро получать услуги и ощущать, что о них заботятся. Как полагают в НАФИ, в сознании клиентов банки все больше становятся обезличенными ИТ-сервисами и приложениями. А любой сервис сегодня должен быть быстрым, понятным и приятным в использовании.

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

Порочный круг IVR


IVR (Interactive Voice Response), или интерактивное голосовое меню, решает вроде бы благородные задачи:

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

Но почему клиенты часто недовольны голосовым меню? Приведем в пример несложный кейс с IVR:

Клиент звонит в банк выяснить, почему ему приходят подозрительные SMS-ки о попытке провести операции по его дебетовой карте. Блокировать ее он не хочет, ему важно сначала разобраться в ситуации. На звонок заранее записанным голосом отвечает IVR и предлагает прослушать голосовое меню: Добро пожаловать в Демьянкредитбанк. Для получения информации по адресам отделений и банкоматов нажмите 1. Для экстренной блокировки карты нажмите 2. Для получения пин-кода нажмите 0. Далее следует перечисление еще нескольких цифр, а затем тишина. В главном меню нет нужной ему цифры и пункта связаться с оператором. Он волнуется: прослушал меню, зашел в тупик, так и не решил вопрос. Чтобы связаться с оператором, нужно зайти в одну из веток, потом прослушать Оставайтесь на линии и дождитесь, когда вам ответит первый освободившийся сотрудник. А клиент-то уже на нервяке: у него с карты кто-то хочет списать деньги, а ему тут квест устраивают.

По данным IT-дистрибутора ICE Partners, людей больше всего раздражают длинные и сложные голосовые меню. Возможно, банку структура IVR кажется удобной и тщательно продуманной, но клиент может считать иначе.

На практике многим приходится бросать трубку, перезванивать в контакт-центр и снова прослушивать одну и ту же информацию. И даже тогда клиент не всегда может понять, что ему делать дальше.
Психолог Джордж Миллер, работавший на Bell Laboratories, в 1956 году установил, что человек способен удержать в кратковременной памяти от 5 до 9 элементов. Современные психологи снизили оценку объема кратковременной памяти до 4.
Кстати, все это лишний трафик 8-800, а в объемах крупной компании десятки тысяч долларов убытков в месяц. Кроме того, если после длинного и сложного IVR клиент не попадёт на нужного специалиста, то, скорее всего, он положит трубку и больше не вернется к этому банку. Поэтому лучше заранее проанализировать эффективность IVR, чтобы не раздражать людей. Как это сделать?

  • Один из самых простых вариантов позвонить в свою компанию. Это может быть познавательно. Так, можно прослушать IVR много раз, в частности, проверить, есть ли в конце выход на живого оператора. Затем удалить все лишнее, убрать зацикливания и тупиковые ветки меню.
  • Можно провести опрос своих сотрудников: насколько у них выросла или снизилась нагрузка с точки зрения ответов на самые простые вопросы, сколько раз за день им звонил один и тот же клиент, сколько вызовов они переводили на других специалистов и т.п.
  • Устроить опрос клиентов. Обычно после разговора с оператором включается система IVR (post-call опрос), в которой абоненту задаются 5-10 вопросов. Предлагается в баллах оценить качество обслуживания, уточнить, была ли решена проблема, посоветует ли он компанию своим близким и друзьям и т.п.


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

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



так и показать детали по каждому конкретному случаю:





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

ABBYY Timeline помогает объединять данные логов, полученные из нескольких систем, и анализировать все составляющие процесса в едином пространстве. Все события, которые произошли в различных IT-системах, но относились к одному конкретному звонку, платформа объединяет в цепочку, которая называется маршрутом.

Каждый маршрут может быть уникальным, но ABBYY Timeline может легко находить в них закономерности или проверять различные гипотезы. Например, можно посмотреть, сколько времени у клиента занимает решение его вопроса в IVR. Сначала воспользуемся инструментом Запрос, чтобы отобрать те звонки, в которых клиент дошел до узла голосового меню, который не является промежуточным, а затем звонок был окончен.
Промежуточные узлы IVR это те, на которых от клиента ожидается некоторый выбор, и они не являются целевыми для клиента.

image

А теперь посмотрим статистику Длительность маршрута для отобранных звонков:

Самый долгий разговор занял 9 минут, а подавляющая часть звонков укладывалась в 3 минуты.

Этот показатель поможет определить, насколько проста и удобна навигация в меню для клиента. Если задача решается через IVR за 10 минут, а через оператора за минуту, то лучше переключать такой звонок на оператора. Автоматизированный информационный сервис не должен занимать у клиента больше 6 минут.

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

image

Теперь посмотрим нарушения этого регламента:
image
Можно не только отобрать звонки, которые нарушают время исполнения регламента, но и настроить автоматические уведомления по таким нарушениям. При появлении новых звонков, не укладывающихся в сроки обработки, ABBYY Timeline будет присылать email с прямыми ссылками на маршруты таких звонков.

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

image
Мы отобрали все звонки, которые закончились попаданием в целевой (не промежуточный) узел меню IVR и отобразили распределение звонков по имени узла IVR.

ABBYY Timeline позволяет измерить статистику брошенных трубок: на каких ветках IVR и сколько клиентов бросили трубку, не дойдя до конца. Это один из важных индикаторов проблем с IVR:

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

image
Теперь мы видим пункты меню IVR, на которых клиенты чаще всего решали повесить трубку, а не углубляться дальше.

Контакт-центр может работать не только с историческими данными, но и проверять гипотезы. Инструменты прогнозирования в ABBYY Timeline позволяют смоделировать ситуацию, когда будущий клиент звонит вам и идет по лабиринту IVR. Если прогнать все возможные варианты действий, то вы обнаружите, где будет основной затык, и придумаете, как это исправить.

Вас много, а я одна


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

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

Задача специалистов, которые планируют количество сотрудников на линии, сделать так, чтобы клиент не ждал, а операторы не сидели без дела. Как добиться идеальных пропорций?

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

Еще один вариант проанализировать, как изменяется нагрузка на контакт-центр в режиме реального времени и какие узкие места есть в этом процессе. Например, можно воспользоваться инструментом Очереди в ABBYY Timeline и посмотреть, что по факту сейчас происходит с нагрузкой на линию:


ABBYY Timeline дает возможность отследить распределение заданий между командами обработки запросов в реальном времени. Картинка кликабельна

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


ABBYY Timeline вычисляет статистику простоев запросов в очередях. Картинка кликабельна


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

Есть показатели, которые говорят именно о качестве обслуживания. Например, клиента не должны переключать больше 5 раз на другого менеджера банка. Абонента гоняют туда-обратно и оставляют без ответа? Такую ситуацию можно отследить:

imageИнструмент Запрос использован для поиска маршрутов с множественными переадресациями.

Далее интересно посмотреть распределение таких звонков по конкретным сотрудникам, чтобы побеседовать с ними и, возможно, узнать что-то новое о вашем бизнес-процессе:


Картинка кликабельна

База, база, ответьте!


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

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

Что происходит? Самый большой поток звонков в контакт-центр как раз бывает в тот момент, когда происходят массовые обновления, сбои, или, например, когда президент объявляет о кредитных каникулах для малого бизнеса. И банк накрывает валом звонков на эту тему, а в базе знаний дырка от бублика!

Что делает оператор? Ставит звонок на удержание и ищет ответы на вопросы. Спросит коллегу за соседним столом, старшего консультанта, напишет команде в чат. Тем временем количество и среднее время удержания обычно отслеживаются и не должны превышать, например, 2 минуты и 2 удержания за вызов. Иначе санкции и плакала премия. Хотя в данном случае не хватает просто Q&A по теме.

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

Как быть?
  • Многие контакт-центры предлагают самим клиентам доступ к своей базе знаний, и таким образом переводят часть абонентов на самообслуживание. Но есть нюансы: это не отменяет регулярного обновления базы и сбора недостающей информации по самым актуальным вопросам, по которым обращаются в контакт-центр.
  • Еще один вариант собирать данные о тематике самых долгих звонков, вводить информацию в Microsoft Excel и постепенно пополнять базу данных новыми темами.
  • Можно сделать удобнее: анализировать и повышать эффективность базы знаний с помощью современных/цифровых технологий или технологий анализа бизнес-процессов. Например, проанализировать, как обновление базы отражается на времени ожидания клиента.

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


Среди этих звонков найдем те, которые содержали более 3-х поисков по базе знаний:
image

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

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

imageСравнение двух запросов. В одном из них больше обращений к базе знаний.

Далее можно анализировать: по каким темам звонили люди, когда приходится долго искать ответ, чего не хватает сотрудникам (обучения или информации) и так далее.

Вместо заключения


Конкурентное преимущество любого контакт-центра качество обслуживания. А когда бизнес-процессы в компании налажены и совершенствуются в реальном времени, то ничто не мешает оператору четко и понятно отвечать клиенту, проявлять участие и заботу. А когда клиент доволен отношением к себе, он точно вернется к вам. И не так важно, что ему помогло в итоге: он быстро все нашел через IVR, оператор ответил на вопрос или клиент спросил голосового помощника. Важно то, что и сотрудник, и компания отнеслись к человеку и его ситуации неравнодушно.
Подробнее..

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

28.01.2021 12:17:06 | Автор: admin

В последнее время все чаще слышно про RPA или Robotic Process Automation. С одной стороны, говорят о его эффективности для банковского сектора и крупных корпораций, с другой про применимость и в среднем, и даже в малом бизнесе. На днях на Хабре вышла обзорная статья про интеллектуальную обработку документов с помощью RPA и мы подумали, что хабравчанам также будет интересен рассказ про наш опыт реализации такого проекта в деталях.

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

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

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

С чем предстояло работать

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

Описанные выше проблемы возникали на этапе обработки документов. На стороне заказчика каждый день на эту задачу тратилось 72 часа. Это 9 полноценных бухгалтерских рабочих дней! Роботизации этого проекта от нас и ждали.

Подробное описание процесса сверки, с которым мы должны были работать:

Итак, что нужно сделать бухгалтеру, чтобы сверить доки? По готовым к сверке заказам в учетной системе формируется еxcel-отчет реестр заказов с их номерами, номерами приемки, магазином, наличием расхождений по количеству и стоимости и т.д. Чтобы сэкономить время, при работе с бумажными первичными документами бухгалтер выгружает их сканы из ЭХД (поиск в Directum по штрихкоду из отчета). Сканы нужны для того, чтобы сверить цены в заказе с ценами из документа поставщика.

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

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

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

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

В качестве платформы роботизации был выбран UiPath: абсолютный лидер на рынке РФ и один из лидеров глобального рынка RPA, кроме того, уже обкатанный в головном офисе нашего партнера в Европе.

Чего мы хотели от робота?

У этой роботизации было несколько основных и вспомогательных целей. Основные цели были достаточно стандартные: процесс нужно было автоматизировать не менее чем на 90% (звучит впечатляюще, но для мира RPA это норма), сократив затраты на него по сравнению с ручным трудом. Второстепенные цели были любопытнее:

выявить аномальные расхождения, которые человек может пропустить;

снизить риск ошибки специалистов по товарному предложению;

предотвратить расширение штата бухгалтеров при увеличении объемов поставок;

ускорить проведение оплат поставщикам.

На основе всего этого мы поставили перед собой такие задачи:

разработать роботов, которые будут выполнять работу бухгалтеров;

разработать сервис их взаимодействия с бухгалтерами и СТП; не допускающий использования вил и факелов

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

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

Ну и как же без дополнительных требований от заказчика:

runtime-лицензии роботов должны использоваться максимально эффективно. Лишние действия, задержки все это должно быть сведено к минимуму;

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

отсутствие у роботов дублирования функций;

приоритизация срочных задач (например, отчетов);

минимизация поддержки решения после ввода в эксплуатацию;

автоматический онлайн-расчет окупаемости (дэшборд в Confluence);

и еще, чтоб участников процесса письмами/уведомлениями не спамило.

Подход к проблеме и проект

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

Итак, сформулировав процесс AS-IS, мы декомпозировали его на подпроцессы для роботизации. Получилось вот так:

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

Однотипные задачи мы сразу стали собирать в совместную обработку, помня о требовании об эффективном расходовании runtime-лицензии. На практике это значило, что если нужно выгрузить из ЭХД 10 доков, то открывать его мы будем 1 раз, выгружать нужное и 1 раз закрывать, а не открывать и закрывать для каждого документа.

Архитектуру системы полностью определило решение формировать списки задач для каждого роботизируемого процесса в СУБД (MS SQL). Тем более что, как мы выяснили, отчёт из учетной системы (на базе СУБД ORACLE) можно выгружать запросом. Поэтому мы решили сделать Link к БД учетной системы и настроить Job в БД для регулярной выгрузки новых приемок, готовых к сопоставлению. Этот Job будет также анализировать полученные данные и переводить приемки на нужный этап обработки: Требует согласования с СТП, Требует выгрузки в систему распознавания, Передать в оплату и т.д.

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

Что еще нужно было определить перед тем, как приступить к работе?

Архитектура распознания документов

Наш робоподопечный должен был уметь распознавать документы такое зрение ему мы сделали на известной платформе ABBYY FlexiCapture. У нее есть, во-первых, готовые шаблоны распознавания для первичных документов (мы лишь немного докрутили их под примеры заказчика). Во-вторых, она предоставляет удобный интерфейс для верификации результатов распознавания, а это экономит время тому, кто верифицирует.

В этом процессе было несколько критически важных точек: качественное извлечение табличной части документа; проверка артикулов в БД (да, номенклатура также выгружалась из БД ERP-системы); сверка суммы документов; проверка совпадения штрихкода на документе и в ERP.

В общем виде процесс распознавания получился следующий:

1. Робот получает сразу все задачи по выгрузке бумажных документов из ЭХД. При этом в базе данных для каждого процесса подготовлена соответствующая вьюха, возвращающая список приемок и необходимые атрибуты для конкретного процесса.

2. Робот открывает ЭХД и начинает выгрузку сканированных образов бумажных документов в горячую папку ABBYY FlexiCapture. Для каждого документа формируется файл описания, чтобы система ABBYY понимала, о какой приемке идет речь, и могла корректно выполнять запросы к справочникам ERP.

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

3.5. Если же ошибки присутствуют, то бухгалтеру ответственного за этот документ отдела приходит через e-mail напоминание о необходимости верифицировать документ. В приложении верификации видно документы с ошибками.

4. ABBYY FlexiCapture экспортирует проверенные данные в БД и устанавливает статус для соответствующих приемок Готово к дальнейшей обработке.

Формирование интерфейса

Для взаимодействия с пользователями изначально планировали использовать Jira, но затем мы приняли решение упростить интерфейс. Мы разработали собственный сервис по взаимодействию с пользователями. Если требуется согласовать расхождение, робот присылает сотруднику по товарному предложению ссылку в письме. При переходе по ней формируется web-страница, при этом проверяется, не был ли этот заказ уже согласован, а также имеет ли данный человек все необходимые права. На этой странице сотрудник выполняет согласование и вводит комментарий. После этого приемка в БД получает соответствующий статус для дальнейшей обработки роботом.

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

Формирование отчетности

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

Всего отчетов было реализовано четыре:

отчет по задачам бухгалтеров (требуются ли действия от бухгалтера?);

отчет главного бухгалтера (по задачам всех бухгалтеров);

общий отчет по выявленным расхождениям;

детальный отчет по расхождениям (с суммами по приёмкам и по поставщикам).

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

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

Формирование графиков в Confluence

Помимо отчетов, робот также должен был строить real-time графики окупаемости самого себя. Для этого был разработан набор представлений в БД, в которых рассчитываются ключевые метрики робота. Методология расчета метрик включает в себя все затраты на роботизацию процесса, в том числе стоимость лицензий, серверов, стоимость наших услуг, а также зарплату бухгалтеров, ведь полностью мы их не исключили из процесса. Для отображения графика на странице в Confluence используется плагин Database Query.

С какими трудностями мы столкнулись

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

Проблемы при заказе отчетов как сделать так, чтобы робот выполнял приоритетные задачи раньше других?

После реализации персонализированных отчетов мы столкнулись с проблемой приоритизации задач.

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

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

Таким образом, при наличии в очереди задач на формирование отчета, робот практически сразу брался за их выполнение.

Как заставить робота самого себя поднимать

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

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

В качестве основы всех процессов мы использовали Enhanced REFramework. Нас устраивали его расширенное логирование и централизованная обработка исключений.

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

Переиспользование частоиспользуемых процессов (инвоуков)

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

Кастомные активности

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

работа с БД (получение данных по приемкам, по отчетам, сохранение статусов и т.д.);

работа с почтой (получение запросов от бухгалтеров, отправка уведомлений);

работа с Excel (форматирование, группировка, сортировка и т.д.);

работа с учетными системами (авторизация, проверка ошибок).

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

Курьезный случай исчезновение штрихкодов

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

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

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

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

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

Результаты

Как мы говорили в самом начале, от нас требовалась оптимизация рабочего процесса на 90%. Как вычислить этот показатель? Для этого нужно сравнить время, которое будет потрачено на нужный процесс с роботом и без него. Мы определили, сколько занимали все составляющие роботизированной работы выгрузка актов, работа в ABBYY, составление отчетов и даже написание писем; задали резерв на обслуживание робота.

И выяснили, что с задачами, на которые штат бухгалтеров ежедневно тратил время девяти полностью занятых профессионалов, робот справляется примерно за половину одного рабочего дня (0,47 рабочего дня, если быть точным). Точный показатель 94% оптимизации. Это была победа!

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

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

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

Спасибо всем дочитавшим до этого момента. Если у вас возникли вопросы, мы будем рады на них ответить!

Подробнее..

Победители соревнований Dialogue Evaluation о задачах, языковых моделях, ML и о себе

06.07.2020 16:22:04 | Автор: admin
Недавно завершился Диалог 2020, международная научная конференция по компьютерной лингвистике и интеллектуальным технологиям. Традиционно одно из ключевых событий конференции это Dialogue Evaluation, соревнования между разработчиками автоматических систем лингвистического анализа текстов. Мы уже рассказывали на Хабре о задачах, которые участники состязаний решали в прошлом году, например, о генерации заголовков и поиске пропущенных слов в тексте. Сегодня мы поговорили с победителями двух дорожек Dialogue Evaluation этого года Владиславом Корзуном и Даниилом Анастасьевым о том, почему они решили участвовать в технологических соревнованиях, какие задачи и какими способами решали, чем ребята интересуются, где учились и чем планируют заниматься в будущем. Добро пожаловать под кат!

Владислав Корзун, победитель дорожки Dialogue Evaluation RuREBus-2020



Чем ты занимаешься?


Я разработчик в NLP Advanced Research Group в ABBYY. В данный момент мы решаем задачу one shot learning для извлечения сущностей. Т. е. имея небольшую обучающую выборку (5-10 документов), надо научиться извлекать специфические сущности из похожих документов. Для этого мы собираемся использовать выходы обученной на стандартных типах сущностей (Персоны, Локации, Организации) NER-модели в качестве признаков для решения этой задачи. Также мы планируем использовать специальную языковую модель, которая обучалась на документах, схожих по тематике с нашей задачей.

Какие задачи ты решал на Dialogue Evaluation?


На Диалоге я участвовал в соревновании RuREBus, посвященном извлечению сущностей и отношений из специфических документов корпуса Минэкономразвития. Данный корпус сильно отличался от корпусов, используемых, например, в соревновании Conll. Во-первых, сами типы сущностей были не стандартные (Персоны, Локации, Организации), среди них были даже неименованные и субстантивы действий. Во-вторых, сами тексты представляли собой не наборы выверенных предложений, а реальные документы, из-за чего в них попадались различные списки, заголовки и даже таблицы. В итоге основные трудности возникали именно с обработкой данных, а не с решением задачи, т.к. по сути это классические задачи Named Entity Recognition и Relation Extraction.

В самом соревновании было 3 дорожки: NER, RE с заданными сущностями и end-to-end RE. Я пытался решить первые две. В первой задаче я использовал классические подходы. Сперва я попробовал в качестве модели использовать рекуррентную сеть, а в качестве признаков словные эмбеддинги fasttext, шаблоны капитализации, символьные эмбеддинги и POS-тэги[1]. Затем я уже использовал различные предобученные BERT-ы [2], которые довольно сильно превзошли предыдущий мой подход. Однако этого не хватило, чтобы занять первое место в этой дорожке.


А вот во второй дорожке мне это удалось. Для решения задачи извлечения отношений я свел её к задаче классификации отношений, схожей с SemEval 2010 Task 8. В данной задаче для каждого предложения дана одна пара сущностей, для которой нужно классифицировать отношение. А в дорожке в каждом предложении может быть сколько угодно сущностей, однако она просто сводится к предыдущей путем сэмплирования предложения для каждой пары сущностей. Также при обучении я брал отрицательные примеры случайно для каждого предложения в размере, не большем удвоенного числа положительных, чтобы сократить обучающую выборку.

В качестве подходов к решению задачи классификации отношений я использовал две модели, основанные на BERT-e. В первой я просто конкатенировал выходы BERT с NER-эмбеддингами и затем усреднял признаки по каждому токену с помощью Self-attention[3]. В качестве второй модели была взята одна из лучших для решения SemEval 2010 Task 8 R-BERT[4]. Суть данного подхода в следующем: вставить специальные токены до и после каждой сущности, усреднить выходы BERT для токенов каждой сущности, объединить полученные вектора с выходом, соответствующим CLS-токену и классифицировать полученный вектор признаков. В итоге данная модель заняла первое место в дорожке. Результаты соревнования доступны здесь.


[4] Wu, S., He, Y. (2019, November). Enriching pre-trained language model with entity information for relation classification. In Proceedings of the 28th ACM International Conference on Information and Knowledge Management (pp. 2361-2364).

Что показалось тебе наиболее сложным в этих задачах?


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

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

Ты раньше участвовал в Диалоге и дорожках?


В прошлом году выступал со своим магистерским дипломом на студенческой сессии.

А почему в этом году решил участвовать в соревнованиях?


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

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

А в других соревнованиях ты участвовал?


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

Еще участвовал в ABBYY-шном хакатоне, в ACM icpc соревнованиях по спортивному программированию на первых курсах. Мы тогда особо далеко не прошли, но было весело. Подобные соревнования сильно отличаются от представленных на Диалоге, где есть достаточно много времени, чтобы спокойно реализовать и проверить несколько подходов. В хакатонах же нужно все делать быстро, времени расслабиться, попить чай нет. Но в этом и вся прелесть подобных мероприятий в них царит специфическая атмосфера.

Какие самые интересные задачи ты решал на соревнованиях либо на работе?


Скоро будет соревнование по генерации жестов GENEA, и я собираюсь туда пойти. Мне кажется, это будет интересно. Это воркшоп на ACM International Conference on Intelligent Virtual Agents. В данном соревновании предлагается генерировать жесты для 3D-модели человека на основе голоса. Я выступал в этом году на Диалоге с похожей темой, делал небольшой обзор подходов для задачи автоматической генерации мимики и жестов по голосу. Нужно набираться опыта, ведь мне еще диссертацию защищать по схожей теме. Я хочу попробовать создать читающего виртуального агента, с мимикой, жестами, и конечно, голосом. Текущие подходы синтеза речи позволяют генерировать довольно реалистичную речь по тексту, а подходы генерации жестов жесты по голосу. Так почему бы не объединить эти подходы.

Кстати, где ты сейчас учишься?


Я учусь в аспирантуре кафедры компьютерной лингвистики ABBYY в МФТИ. Через два года буду защищать диссертацию.

Какие знания и навыки, полученные в вузе, тебе помогают сейчас?


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

Даниил Анастасьев, победитель дорожки Dialogue Evaluation GramEval-2020



Чем ты занимаешься?


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

Расскажи про задачу, которую ты решал в этом году на одном из треков Dialogue Evaluation.


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

image

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

А похоже ли это на то, чем ты занимаешься на работе?


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

Участвовал ли ты в Dialogue Evaluation до этого?


Участвовал в дорожке MorphoRuEval-2017 на 5 курсе и тоже тогда занял 1 место. Тогда нужно было определить только морфологию и леммы, без синтаксических отношений.

Реально ли применять твою модель для других задач уже сейчас?


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

А для чего ты участвуешь в Dialogue Evaluation и других подобных соревнованиях?


Хакатоны и такие соревнования напрямую не связаны с моей деятельностью, но это все равно полезный опыт. Например, когда я участвовал в хакатоне AI Journey в прошлом году, я научился каким-то вещам, которые потом использовал в работе. Задача была научиться проходить ЕГЭ по русскому языку, то есть решать тесты и писать сочинение. Понятно, что это всё слабо связано с работой. А вот умение быстро придумать и обучить модель, которая решает какую-то задачу очень даже полезно. Мы тогда с командой, кстати, заняли первое место.

Расскажи, какое образование ты получил и чем занимался после университета?


Окончил бакалавриат и магистратуру кафедры компьютерной лингвистики ABBYY в МФТИ, выпустился в 2018 году. Также учился в Школе анализа данных (ШАД). Когда пришло время выбирать базовую кафедру на 2 курсе, у нас большая часть группы пошла на кафедры ABBYY компьютерной лингвистики или распознавания изображений и обработки текста. В бакалавриате нас хорошо учили программировать были очень полезные курсы. Я с 4 курса работал в ABBYY на протяжении 2,5 лет. Сначала в группе морфологии, затем занимался задачами, связанными с языковыми моделями для улучшения распознавания текста в ABBYY FineReader. Я писал код, обучал модели, сейчас я занимаюсь тем же, но для совсем другого продукта.

А как проводишь свободное время?


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

Есть ли у тебя планы или цели на ближайшие, допустим, 5 лет?


5 лет слишком далекий горизонт планирования. У меня ведь даже нет 5-летнего опыта работы. За последние 5 лет многое поменялось, сейчас явно другое ощущение от жизни. С трудом представляю, что еще может измениться, но есть мысли получить PhD за границей.

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


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


Кстати, мы продолжаем набор в магистратуру на кафедры ABBYY в МФТИ: распознавания изображений и обработки текста (РИОТ) и компьютерной лингвистики (КЛ). До 15 июля включительно присылайте на brains@abbyy.com мотивационное письмо с указанием кафедры, на которую хотели бы поступить, и резюме с указанием среднего балла GPA по 5- или 10-балльной шкале.

Подробности о магистратуре можно посмотреть на видео, а о кафедрах ABBYY прочитать здесь.
Подробнее..

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

06.08.2020 12:10:31 | Автор: admin
Всем привет! Надеюсь, вы помните меня по рассказам о жизни в ABBYY и Оргкомитете Сочи-2014. Давно ничего не писал, и вот наконец дошли руки. Я поменял работу в разгар коронавируса, поэтому хочу поделиться своим опытом и на личном примере рассказать о том, как компании справляются с такими нестандартными ситуациями и что менять работу в условиях высокой неопределенности совсем не страшно.



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

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

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

Так как мы (семья с 2 детьми и шотландским котиком) не были привязаны к Москве и слегка уже подустали от неё, рассматривали предложения в разных крупных городах. Мы с женой учились и довольно долго жили в Краснодаре, там же родился первый ребенок, а потом в 2012 году меня позвали работать над олимпийскими приложениями в Москву. Очень тяжело было возвращаться, например, в Краснодар и видеть абсолютно те же самые проблемы, что и 8 лет назад Поэтому этот город мы не рассматривали. Так как один ребенок в этому году заканчивал 3-й класс, а второй только родился, качество медицины, образования и услуг все-таки были очень важны. Так что рассматривали варианты из топов всяческих рейтингов и недалеко от Европы: Москву, Питер, Нижний Новгород, Калининград, Сочи, Казань и релокацию за рубеж.

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

Собеседования в Wrike


Про Wrike я был очень хорошего мнения из-за классных мероприятий Wrike TechClub и докладов на продуктовых конференциях, к тому же я интересовался системами управления проектами, борьбой с прокрастинацией и повышением производительности. Мне на глаза попалась вакансия менеджера продукта в AI, и я написал знакомому в компании, чтобы навести справки и получить рекомендацию для HR.

Так как я нахожусь в Москве, а центральный российский офис в Санкт-Петербурге, все основные собеседования проходили онлайн. Сначала было довольно простое собеседование с HR: на общую осведомленность и соответствие навыкам. Потом с продакт-менеджером. Обменявшись мыслями про развитие искусственного интеллекта и поговорив о моих навыках, мы закончили на довольно неожиданном вопросе: Что меня драйвит?. Я ответил, что хочу делать счастливыми коллег и пользователей и улучшать процессы. Я много времени посвятил этому в ABBYY (опять же ссылка на статью) и мне хотелось бы продолжать улучшать среду вокруг себя в Wrike. К счастью, никто не был против.

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

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

Последние этап собеседование с новым лидом машинного обучения из США и Head of Product. Было страшновато, потому что я не считал себя максимально продвинутым в прохождении собеседований по-западному: с обсуждением рабочих кейсов по разным нужным софт-скиллам, безупречной самопрезентацией и соблюдением тонкой грани политкорректности. Но это ощущение быстро прошло, и разговор получился дружелюбным и интересным. До Wrike лид работал в AI Evernote, про который я много знал, так что нашли общий язык.

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

Переселение в Wrike и начало работы


И вот в конце апреля я покинул работу в ABBYY (HR-службы отработали хорошо даже в разгар кризиса) и переселился в Wrike. Это было довольно забавно, потому что я просто переехал из одного ноутбука в другой. Офисы в то время были уже закрыты, так что рабочий ноут, документы и велком-пак мне прислали курьером.



Вот такую коробищу привезли из Питера в Москву для начала работы



Welcome-pack с сувениркой (MacBook Pro и аксессуары с документами я уже прибрал к рукам)



Котику большего всего понравилась серая майка

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

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



Конечно, об интернете я позаботился заранее и провел в дома родителей GPON на 200 мегабит. С мобильным (даже 4G) сигналом совещания по зуму все-таки были гораздо хуже



Наслаждался не только я

В итоге и все активности для новичка были удаленные знакомство с командой, Welcome Breakfast (завтрак-знакомство для новых сотрудников в ближайшем ресторане), Wrike Quest (набор заданий по знакомству с Wrike (продуктом, а не компанией)), обучающие тренинги, оформление ДМС (компания оплачивает страховку еще и на детей и половину от ДМС жены).



Все активности внутри компании заносятся в Wrike (ха-ха), так что в целом это был хороший тренинг по собственному продукту

Переезд в Питер




Несмотря на сворачивание рейсов, между Питером и Краснодаром регулярно летало 4 штуки и цены были гораздо дешевле прошлого года

Так как поиск школы и музыкалки для ребенка стоял у нас в приоритете, решили, что надо быть в Питере хотя бы в середине июля, чтобы неспешно найти квартиру и попытаться попасть в хорошую гимназию/лицей и музыкальную школу. К счастью, Wrike дает возможность 1 месяц пожить в корпоративной квартире и оплачивает билеты всем членам семьи + подъёмные на новом месте. Месяца вполне достаточно для поисков семейного жилья.





Корпоративная квартира в 7 минутах от офиса

В целом, привыкание далось несложно. В Питере действуют те же офигенные Самокат и Яндекс.Лавка, Деливери Клаб и Яндекс.Еда, Ситимобил и Яндекс.Такси. А еще Пятерочки, Магниты, Перекрестки и ВкусВилл. Есть возможность самоизолированно перемещаться по городу велосипеды SmartBike (60 рублей за полчаса и далее 5 рублей в минуту) и электросамокаты (больше понравились Molnia и Whoosh, правда расценки недетские и динамично меняющиеся 45 рублей за старт плюс 4/5/7 рублей за минуту и 50 рублей за старт плюс 5/7 рублей за минуту соответственно).

Погода, конечно, оказалась гораздо суровее, чем московская и тем более краснодарская. Но дни тепла и солнца были регулярно, а красивые дома и парки дарили ощущение радости. Из необычных впечатлений булочные реальном на КАЖДОМ углу, иногда по несколько на перекрестке, и, кстати, довольно вкусные и недорогие (после эклеров за 100 рублей в Москве я очень удивлялся ценам в 40-50 в Питере). Ну и, конечно, любимый Буквоед, который все такая же мимишная версия Читай-города.

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



Из этих районов города можно за 45 минут добраться до Wrike



Тепловая карта инфраструктуры для жизни и развлечений. Есть еще аналогичная для транспортной доступности

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

Мы предварительно отправили все вещи из московской квартиры на склад, и далее они уже ждали от нас сигнала, чтобы перевезти все в Питер. Так как компания давала приличную сумму на релокацию, решили воспользоваться Деликатным переездом, а не городить комбинацию из грузчиков, складов и автоперевозок. Они практически единственные предложили нормальную логистику этого процесса, к тому же у них был склад в Питере дешевле. В целом, получилось вполне неплохо. 4 человека упаковали квартиру за 6 часов (получилось 100 наименований вещей).

Музыкальные школы я искал по 2GIS (поиск по типам заведений все-таки у него работает лучше. Например, Музыкальный лицей Яндекс так и не нашел, хотя по сути это музыкальная школа). Везде нужно пройти экзамен, но и поступление тоже довольно прозрачное подавай заявку и приходи на экзамен в указанное время.

Со школами всё было сложнее. Хотелось попасть в действительно хорошую. В итоге, в качестве рабочего инструмента использовал рейтинги по ЕГЭ и рейтинги Комитета по образованию. Вычеркнул школы, не попадающие в зоны проживания выше, потом отсортировал по количеству номинаций и среднему месту и получил список из 6 классных школ, гимназий и лицеев. Дальше олдскульный обзвон, мотивационные письма, встречи с директорами, и вот нам удалось попасть в хорошую гимназию недалеко от метро и от работы.

Так как в Питере обстановка в связи с коронавирусом была так себе, офис решили открыть только для очень нуждающихся, не более 90 человек, работающих в индивидуальных кабинетах (кстати, распределение команд по кабинетам, а не тотальный опенспейс, при сравнении с другими компаниями тоже радовало). И, конечно, всем продолжали доплачивать за питание на банковскую карту, вместо специальной для обедов. Обсудив с командой, решил пока все-таки работать из дома. Но офис, в целом, уже готов к приему гостей, и желающих пока оказалось даже в 2 раза меньше доступных мест.









Адаптация


Стресс на удаленке присутствует во всех компаниях. Приятно, что современные компании пытаются сделать все возможное, чтобы это исправить. Так было и в ABBYY, и в Wrike. В ABBYY мне очень нравился TED Friday с просмотром любимого видеоролика кого-то из коллег и обсуждения идей оттуда, а также выступления коллег на разные образовательные темы.

Я там показывал одно из любимейших видео Shawn Achor: The happy secret to better work | TED Talk.



Секреты довольно простые, но и очень сложно интегрируемые в жизнь

Приятно было видеть подобные активности и в Wrike. За коронавирусный квартал прошло несколько классных мероприятий.



Знакомство с домашними животными коллег



Кулинарный мастер-класс



Музыкальный квартирник с коллегами



Подражание картинам художников



Вебинар по борьбе с прокрастинацией от Максима Дорофеева

И еще семинар по медитации и практике внимательности, встречи по культурам разных стран, турнир по Counter-Strike, классные обзоры путешествий коллег, лекции по экологии. Ну и дистанционно идут уроки английского, йога и много всего другого. Также переехали в онлайн ежемесячные All-hands meetings на все 1000+ сотрудников Wrike по всему миру с основными достижениями и проблемами месяца, открытые результаты кварталов и OKR, еженедельные продакт-менеджерские встречи, staff meetings на всю компанию.



Engineering All-hands June 2020 викторина в перерывах между рассказами

Когда я более-менее освоился, тоже провел внутри команды мини-тимбилдинг: попросил ребят записать 3 правды и 1 ложь о себе, ответить на вопрос, кем хотели стать, когда вырастут, приложить любимую песню и фотографию рабочего места. Мы много узнали друг про друга и хорошо провели время. С августа можно будет проводить такие тимбилдинги и офлайн на каждого человека выделена сумма на полугодие, которую можно потратить на мероприятие по выбору команды.



80% коллег посчитало, что это ложь, хотя это правда )

Вспоминая кудо-карточки, которые я вводил в мобилках ABBYY, был рад увидеть здесь централизованную систему благодарностей bonus.ly. Ежемесячно каждому начисляются 100 бонусных баллов, которые можно в любой доле перечислить сотруднику Wrike за какие-то классные действия. Например, понравившуюся презентацию или помощь с работой.



Потом на эти бонусные баллы можно купить сувениры Wrike или перевести их на благотворительность.



А еще мне очень нравится корпоративный аккаунт в Amazon, с которого можно покупать, читать и слушать книги, и корпоративные Kindle. Я дикий фанат чтения, и у меня у самого киндл с 2012 года.

В целом, не смотря на страхи и опасения от смены работы и переезда в другой город, получилось довольно неплохо. Опыт показал, что:
  1. Компании продолжают искать людей, в том числе расширился список удаленных вакансий. Многие впервые в своей истории стали искать сотрудников из других городов.
  2. Компании перестраивают процессы, чтобы соответствовать новому режиму работы, так что вы сможете действительно легко переключиться на новое рабочее место, даже если оно фактически находится в сотнях километров. Курьерские службы все сделают в лучшем виде.
  3. Кризис позволил сократить затраты на перемещения, а рынок аренды квартир буквально перевернулся с ног на голову, так что искать жильё и переезжать сейчас стало гораздо приятнее.

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

Как сделать поиск по документам, накопленным почти за 100 лет. Опыт НПО Энергомаш и ABBYY

29.07.2020 14:20:10 | Автор: admin
Многие знают, что ABBYY занимается обработкой и извлечением данных из разных документов. Но у наших продуктов есть и другие интересные возможности. В частности, с помощью решения ABBYY Intelligent Search можно быстро и удобно искать информацию по смыслу в электронных документах из корпоративных систем. Этим уже пользуются крупные российские компании, например, производитель ракетных двигателей АО НПО Энергомаш.

Многолетняя практика показывает, что время вывода космических двигателей на рынок от момента начала работ составляет от 5 до 7 лет. В то же время для удержания лидирующих позиций необходимо сокращать сроки разработки и изготовления до 3 4 лет. Кроме того, усиление конкуренции привело к необходимости существенного снижения стоимости выпускаемых двигателей на 30 50%.

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

За 90 лет работы НПО Энергомаш накопил вековой объем документов (как бумажных, так и электронных) с ценной информацией о наработках испытателей и конструкторов. Большая часть документов уже хранится в информационных системах компании (ИС). Согласно исследованию IDC, в среднем сотрудники крупных организаций пользуются 5-6 внутренними ИС. Около 36% времени в среднем уходит на поиск информации в масштабах крупной компании это тысячи рабочих часов в день.

Сегодня мы расскажем, как помогли НПО Энергомаш создать корпоративную интеллектуальную информационно-поисковую систему (КИИПС) на базе ABBYY Intelligent Search такую же удобную и быструю, как популярные поисковики.

Чем занимается Энергомаш и при чем тут Гагарин


Со дня основания, 15 мая 1929 года, Энергомаш изготовил более 12 тысяч двигателей для ракет-носителей не только российского, но и зарубежного производства. На этих моторах был запущен первый искусственный спутник Земли, отправился в космос Восток-1 с первым космонавтом Юрием Гагариным на борту, совершил полет космоплан Буран и до сих пор осуществляются пуски американских ракет-носителей Atlas и Antares. Например, 26 марта 2020 года ракета-носитель Atlas V, оснащенная двигателями российского производства, вывела на орбиту американский военный спутник стратегической системы связи. В первом полугодии 2020 года двигатели разработки Энергомаш успешно отработали в 11 космических пусках, что составляет 24,4% от всех пусков в мире.

Сегодня Энергомаш входит в госкорпорацию Роскосмос и возглавляет интегрированную структуру ракетного двигателестроения, в которую входят ведущие предприятия этой отрасли.

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

К примеру, в рамках проекта Цифровые технологии проектирования и производства одной из ключевых задач являлось внедрение PLM-системы (автоматизированной системы управления жизненным циклом изделий). Ее цель обеспечить создание электронной конструкторской документации (ЭКД) и моделирование на ее основе работы двигателя и других рабочих процессов в технологических и производственных подразделениях НПО Энергомаш и готовность к обмену ЭКД между предприятиями отрасли.

Зачем понадобился поиск по вселенной Энергомаша


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

Цель проекта сохранить, приумножить и поставить на службу цифровому производству знания и компетенции предприятия, накопленные за десятилетия работы.

В рамках проекта решалось две задачи:

1). Упростить для конструкторов и инженеров поиск полезной информации в документах прошлых лет.

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

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

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

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

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

В результате:

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

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

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

2). Упростить и ускорить поиск данных для служебных подразделений: бухгалтерии, юристов и других специалистов, которые составляют, редактируют, согласуют документы в учетных системах и обмениваются информацией.

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

Почему это важно? Через 7 лет более половины всех данных в мире будут храниться в корпоративных системах, следует из отчета Seagate и IDC Data age. Чтобы необходимая информация всегда была под рукой, ее надо быстро находить. Так, по данным исследования IDC и ABBYY Рынок искусственного интеллекта в России, представители ИТ (48%) и бизнес-подразделений (33%) видят большие возможности в применении ИИ для корпоративного поиска и классификации документов в ближайшие два года.

Чтобы справиться с этими задачами, компании понадобился удобный сквозной поиск по многочисленным ИС. Энергомаш рассматривал несколько поисковых систем, но в итоге решил попробовать ABBYY Intelligent Search. На выбор повлияло, во-первых, наличие технологий обработки естественного языка, которые позволяют находить документы, релевантные поисковым запросам по смыслу, а не только по ключевым словам. Во-вторых, возможность разграничивать права доступа пользователей к результатам поиска. Подробнее об этом мы расскажем чуть позже, а сейчас о том, как мы стартовали.

Первый выход в поиск


Энергомаш решил проверить работу интеллектуального поиска на 3 тысячах документов из информационной базы данных (ИБД) исследовательских, конструкторских и расчетных работ.
Для этого ABBYY разработала прототип коннектора к ИБД, который связал ABBYY Intelligent Search c базой документов. Коннектор это java-программа, которая используется для загрузки документов в индекс. Как это работает?

1). Сначала строим полнотекстовый поисковый индекс


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

image


Чтобы построить полнотекстовый индекс, нужен коннектор. Он связывает поисковое решение с определенной информационной системой и собирает (индексирует) характеристики каждого документа, например:

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

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

Создавать поисковый индекс помогает встроенный в ABBYY Intelligent Search краулер (поисковый робот). Он через равные промежутки времени опрашивает коннекторы, проверяет, появились ли в ИС новые документы, какие документы удалены, как изменились права доступа к документам. Соответственно, с заданной периодичностью индекс обновляется.

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

Кроме того, система умеет обрабатывать архивные файлы ZIP, RAR, TAR при условии, что они не защищены паролем. Архивы распаковываются, изображения из них распознаются, текст индексируется.



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

2). Затем применяем технологии обработки естественного языка


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

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



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

Приведем еще один пример:

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

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

Итоги первого запуска


Чтобы оценить работу интеллектуального поисковика, специалисты Энергомаш выполнили примерно по 30 запросов по документам ИБД с помощью встроенной в ИБД поисковой системы и с помощью ABBYY Intelligent Search. Затем сравнили результаты поисковой выдачи: какие документы удалось найти обеим системам, какие фразы подсвечивались в сниппетах. В итоге, встроенный в ИБД поиск не выдал результатов по некоторым запросам, так как способен обнаружить только ключевые, а не близкие по значению слова. ABBYY Intelligent Search выдал релевантные по всем запросам документы.

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

После успешного пилотного проекта Энергомаш принял решение использовать решение ABBYY Intelligent Search в основе Корпоративной интеллектуальной информационно-поисковой системы.

Поехали дальше


Энергомаш подключил к поиску 7 корпоративных источников: систему электронного документооборота LanDocs, файловое хранилище, ИБД, систему поддержки жизненного цикла изделия TeamCenter, систему управления ресурсами Галактика ERP и AMM, информационную систему управления проектами. Для каждой информационной системы создан отдельный индекс. Это делает поисковую систему гибкой в администрировании и дает возможность заново строить индекс по каждой системе в отдельности, задавая новые условия. Доступ в Систему корпоративного поиска организован через внутренний портал предприятия на главной странице.

Основные модули системы корпоративного поиска:

  • главная страница поисковых запросов и результатов поиска;
  • панель администратора (настройка индексов, фильтров, метаданных для каждой информационной системы);
  • статистика количества документов (отображает количество документов в индексе по каждой информационной системе за период).

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

Как обеспечить безопасность


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

1). Локальное хранение информации


Поисковое решение ABBYY развернуто на отдельном сервере во внутреннем контуре НПО Энергомаш. Там хранятся все поисковые индексы и их резервные копии на случай потерь и их настройки.

2). Ролевая модель информационной системы


Для безопасности организовано разграничение прав доступа пользователей к результатам поиска по каждой информационной системе. Все корпоративные системы, подключенные к ABBYY Intelligent Search, поддерживают доменную авторизацию. Пользователь входит в систему под доменной учетной записью, выполняет запрос, в результатах поиска видит документ с учетом настроек предпросмотра документа по каждой информационной системе и уровнем доступа, выполненными непосредственно в самой системе корпоративного поиска, и с учетом доступа к документу в самой информационной системе-источнике. Если у пользователя есть права на работу с документом в системе-источнике, то переход в оригинал документа можно осуществить непосредственно из системы корпоративного поиска, нажав на ссылку.

Планы на будущее


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

Упомянем и о планах на будущее:

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



А на ваш взгляд, какие еще задачи можно решить с помощью корпоративного поиска?
Подробнее..

Технологии для проверки Тотального диктанта что можно улучшить?

29.09.2020 14:15:47 | Автор: admin
Я состою в жюри World AI & Data Challenge. Это такой международный конкурс для разработчиков технологий для решения разных социальных задач, таких как борьба с бедностью, помощь людям с ограничениями слуха и зрения, улучшение обратной связи между человеком и государственными организациями, и так далее. Сейчас идет второй этап конкурса, он продлится до октября. В рамках этого этапа мы отбираем лучшие решения для дальнейшей реализации проектов. Поскольку мы в ABBYY много работаем с текстами и их смыслом, то меня больше всего заинтересовала проверка текстов в рамках проекта Тотальный диктант. Давайте на примере этой задачи разберёмся, почему обработка естественного языка одна из самых недооценённых областей современного машинного обучения, а на сдачу обсудим, почему, даже когда речь идёт о проверке диктанта, всё немного сложнее, чем кажется. И интереснее, естественно.

Итак, задача: сделать алгоритм проверки Тотального диктанта. Казалось бы, что может быть проще? Есть правильные ответы, есть тексты участников: бери и делай. Строчки сравнивать-то все умеют. И тут начинается интересное.

Такие разные запятые; или точки с запятой?


Естественный язык сложная штука, часто допускающая не единственную трактовку. Даже в такой задаче, как проверка диктанта (где, на первый взгляд, есть единственно верное решение) с самого начала надо учитывать, что помимо авторского могут быть другие правильные варианты. Более того, организаторы конкурса даже об этом подумали: у них есть несколько допустимых вариантов написания. По крайней мере, иногда. Важно тут то, что все правильные варианты составители вряд ли смогут указать, так что участникам конкурса, возможно, стоит подумать о модели, предобученной на большом корпусе текстов, не связанных с диктантом напрямую. В конце концов, в зависимости от понимания контекста человек может поставить запятую или не поставить точку с запятой; в некоторых случаях возможно всякое: использование двоеточия, тире (или даже скобок).

То, что надо оценивать именно диктант, а не сочинение, это не баг, а фича. Автоматические системы оценки эссе очень популяры в США. 21 штат использует автоматические решения для проверки эссе в рамках GRE. Только вот недавно выяснилось, что эти системы ставят высокие оценки более объемным текстам, в которых используется более сложная лексика (даже если сам текст бессмысленный). Как это выяснилось? Студенты MIT разработали специальную программу Basic Automatic B.S. Essay Language (BABEL) Generator, которая автоматически генерировала цепочки из сложных слов. Автоматизированные системы оценивали такие эссе очень высоко. Тестировать современные системы на базе машинного обучения одно удовольствие. Другой не менее горячий пример: бывший профессор MIT Лес Перельман предложил системе e-rater от ETS, которая производит и оценивает экзамены GRE и TOEFL, проверить эссе на 5000 слов от Ноама Хомского. Программа обнаружила 62 несуществующих грамматических ошибки и 9 пропущенных запятых. Вывод алгоритмы пока плохо работают со смыслом. Потому что мы сами очень плохо можем определить, что это такое. Создание алгоритма, проверяющего диктант, имеет прикладной смысл, но задачка эта не так проста, как кажется. И дело тут не только в неоднозначности правильного ответа, про который я тут сказал, а еще и в том, что диктант диктует человек.

Личность диктатора


Диктант это сложный процесс. То, как читает текст диктатор так организаторы тотального диктанта в шутку называют тех, кто помогает его проводить, может влиять на итоговое качество работы. Идеальная система проверки могла бы соотносить результаты пишущих с качеством диктовки, используя text to speech. Более того, подобные решения в образовании уже используются. Например, Third Space Learning это система, созданная учеными из Университетского колледжа Лондона. Система использует распознавание речи, анализирует, как преподаватель ведет урок, и на основе этой информации дает рекомендации, как можно улучшить процесс обучения. К примеру, если учитель говорит слишком быстро или медленно, тихо или громко, система отправляет ему автоматическое уведомление. Кстати, на сдачу по голосу ученика алгоритм может определить, что он теряет интерес и заскучал. Разные диктаторы могут влиять на итоговые результаты диктанта у разных участников. Налицо несправедливость, которую может устранить что? Правильно! Искусственный Интеллект Диктатор! Покайтесь, наши дни сочтены. Ладно, если серьёзно, то в онлайне можно просто или всем давать одну и ту же звуковую дорожку, или заложить в алгоритм оценку качества Диктатора, как бы крамольно это не звучало. Те, кому диктовали быстрее и менее чётко, могут рассчитывать на дополнительные баллы за вредность. Так или иначе, если у нас есть speech-to-text, то в голову приходит ещё одна идея.

Робот и человек: кто напишет диктант лучше?


Если уж делать распознавание звука в трансляции, то само собой просится создание виртуального участника диктанта. Было бы круто сравнить успехи ИИ и человека, тем более что подобные эксперименты в разных образовательных дисциплинах уже активно проводятся в мире. Так, в Китае в 2017 году ИИ сдавал в городе Чэнду государственный экзамен гаокао это нечто вроде российского ЕГЭ. Он набрал 105 баллов из 150 возможных то есть сдал предметы на твердую тройку. Стоит отметить, что, как и в задаче Тотального диктанта, самым сложным для алгоритма оказалось понимание языка в данном случае, китайского. В России Сбербанк в прошлом году проводил соревнования по разработке алгоритмов прохождения испытания по русскому языку. ЕГЭ состоял из тестов и сочинения по заданной теме. Тесты для роботов были составлены с повышенным уровнем сложности и состояли из трех этапов: непосредственно выполнения задания, выделения примеров по заданным правилам и формулировкам, а также правильной записи ответа.

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

Карта ошибок


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

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

В общем, как говорит мой отец: Все задачи делятся на фуфло и глуховые. Фуфло это задачи, которые уже решил, или ещё не начал решать. Глуховые задачи, которые решаешь в данный момент. Даже вокруг задачи проверки текста машинное обучение позволяет задать массу вопросов и создать кучу надстроек, которые могут качественно изменить опыт конечного пользователя. Что получится у участников World AI&Data Challenge, узнаем ближе к концу года.
Подробнее..

Как создавать и изменять интерактивные PDF-формы, или новый скилл ABBYY FineReader PDF

18.06.2020 18:21:58 | Автор: admin
Мы регулярно обучаем ABBYY FineReader PDF новым навыкам. Две недели назад мы рассказали на Хабре, как научили ABBYY FineReader PDF редактировать целые абзацы. Этот пост о еще одном продвижении нашего продукта на пути к совершенству: программа теперь умеет создавать и редактировать интерактивные PDF-формы.

Раньше ABBYY FineReader PDF мог только заполнять такие формы заявления на отпуск или визу, резюме, согласие на обработку персональных данных, исследования, опросы и т.д. Но что если компании нужно создать в формате PDF анкету, разработать шаблон документа или отредактировать в готовом бланке несколько полей, чтобы затем отправить его сотрудникам или клиентам? Теперь все это можно сделать в одной программе. О том, как это работает, для чего и кому может понадобиться такая функциональность, мы сегодня и расскажем. Поехали!

Что такое интерактивная PDF-форма?


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

PDF-формы могут выглядеть по-разному. Приведем несколько примеров:


Слева направо: первая страница анкеты на получение шенгенской визы; согласие на обработку персональных данных; PDF-форма для запроса сервисных услуг. Картинка кликабельна.

Если PDF-файл сам по себе это статичная сущность, которая в первую очередь предназначена для передачи информации, то формы в PDF предназначены для получения информации от пользователей или организаций.
С технической точки зрения интерактивная форма в PDF это набор виджетов. Виджеты это поля, которые можно создавать, редактировать и заполнять. Термин взят из спецификации PDF (международные стандарты PDF ISO, где описываются все стандартизированные возможности формата PDF). В спецификации сказано, как устроены интерактивные элементы, чтобы это понимал PDF-просмотрщик, то есть программа для работы с PDF. На основе этой спецификации мы и разработали фичу создания и редактирования форм в ABBYY FineReader PDF. Таким образом, интерактивные формы, созданные в нашей программе, будут доступны для заполнения или редактирования и в других редакторах PDF, если они поддерживают PDF ISO.

В чем преимущество интерактивных PDF-форм?


  • PDF-форма будет одинаково отображаться в любой операционной системе, любой программе и на любом устройстве;
  • PDF-форму легче и быстрее заполнить, чем бумажный документ. Меньше вероятность допустить ошибку;
  • PDF-форму можно заполнять без доступа к интернету;
  • PDF-форму легко напечатать;
  • Отправить форму можно несколькими способами: кнопкой действия (ниже мы расскажем об этом), по электронной почте, загрузить на сервер;
  • Данные из PDF-форм цифровые, и поэтому их можно сразу отправить в системы обработки данных;
  • PDF-формы легко интегрировать в системы электронного документооборота организаций.

Приведем пример. Допустим, вам нужно оформить страховой полис для поездки за рубеж. Чтобы не приезжать в офис компании и не заполнять бумажное заявление, можно прямо у себя дома заполнить PDF-форму и отправить ее на почту менеджеру. Кроме того, сотруднику компании не придется перепечатывать данные. Информацию из PDF можно сразу вносить в корпоративные базы данных.

Как создать PDF-форму


ABBYY FineReader PDF помогает как создавать формы с нуля, в т. ч. в новом документе, так и отредактировать уже имеющиеся в форме поля.

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

Либо можно открыть существующий PDF-документ с полями формы или без них и зайти в Редактор форм. Если в документе уже есть интерактивные поля, то пользователь увидит сообщение:


В режиме Редактор форм рядом с полями формы отобразятся их имена.



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

Принимать разные формы? Запросто


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


Текстовое поле. Позволяет ввести строчку или несколько строк текста. К вводимому тексту можно применить форматирование, например, сделать из него дату. Если такое форматирование характерно для поля, то в окошке поля можно вызвать календарик и выбрать дату там. Пользователь сам может выбирать формат даты (например, 18.12.1987 или 1987/18/12).


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

Флажок (check box). Позволяет поставить галочку, например, дать согласие на обработку данных, указать специальные условия при выборе номера в отеле, оформить подписку на новости и др.


Примечательная особенность: если вы думаете, что галочка в check box нарисована (векторными командами или картинкой), то это не всегда так. При создании check box в ABBYY FineReader PDF галочка это символ. Есть специальный символьный шрифт, ZapfDingbats, и состоит он не из букв, а из вот таких специальных символов. И в нашем check box просто получается текст из одного символа этого шрифта.

Переключатель (его еще называют радиокнопка). Этот элемент позволяет выбрать только один из возможных вариантов в списке.


Переключатель в PDF это наиболее яркий пример, как одно поле может содержать несколько виджетов. У каждого из них есть choice name (имя выбранного состояния), которые предустановил PDF-просмотрщик. Именно это имя прописывается в поле, когда какая-то кнопка выбрана. Каждый виджет имеет несколько предустановленных состояний (ChoiceName/Off, Normal/Down). И в зависимости от того, в каком состоянии виджет находится, такое состояние и будет показываться пользователю. Никакой анимации, просто подмена одной картинки на другую.

Раскрывающийся список. Дает возможность выбрать одно из заранее заданных значений или, если позволяет форма, ввести свое (произвольное )значение.



Список. Можно выбрать несколько вариантов.



Кнопка. Позволяет установить действие, которое выполняется при определенном событии (то есть взаимодействии с кнопкой). Например, при клике на кнопку или наведении курсора можно отправить форму по email, напечатать, сохранить, показать вложенные файлы, очистить форму и так далее.Вместо клика на кнопку можно выбрать и другие события, например, отпускание курсора и т.д. Вариантов действий много:



Поле подписи. Позволяет указать в документе место, где надо поставить цифровую подпись:



Совершенствуем форму дальше


Чтобы форма была понятной для пользователя, можно настраивать различные свойства для всех элементов форм и менять их в процессе редактирования.

1). Имя поля. Это внутреннее имя, которое помогает создателю формы ориентироваться в документе.



2). Подсказка. Она появляется, если навести указатель мыши на поле, и позволяет пользователю понять, что требуется сделать и какую информацию внести.





3). Можно сделать любое поле обязательным для заполнения. Тогда оно будет выделено красной рамкой, чтобы пользователь обратил внимание: в это поле необходимо внести информацию, чтобы форма была принята и рассмотрена. Красная рамка не накладывает ограничений на отправку или печать PDF-формы.



4). Опция Только для чтения. Если выбрать ее, то поле станет недоступным для редактирования. Бывает, что в форме может быть информация, которая должна оставаться неизменной. Например, в опроснике для сотрудников-мужчин о том, какие подарки они предпочитают дарить женщинам, может быть поле Пол: туда можно вписать значение Мужской и оставить его неизменным. Это как бы подразумевает, что опрос для мужчин.

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

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

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



Конечно, когда мы разрабатывали редактор форм в FineReader PDF, то оценивали, какие задачи нужно решать конечным пользователям. Расскажем о них.

Нужно разработать шаблоны для документов


С помощью ABBYY FineReader PDF государственные организации, а также юридические, страховые, медицинские и другие компании могут создавать в PDF шаблоны документов, которые необходимо заполнять в электронном виде:

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

Исходный документ, как правило, создается в MS Word. Он содержит текст и пробелы для добавления полей. Затем пользователь конвертирует документ в PDF, чтобы в редакторе форм создать поля, которые будет удобно заполнять.

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



После того как пользователь заполнил этот документ, он может напечатать его и подписать от руки, либо добавить цифровую подпись и отправить по почте.

Нужно собрать данные и отправить информацию в другую организацию


В программе ABBYY FineReader PDF компании и государственные организации могут создавать и редактировать различные электронные бланки для сбора данных, например:

  • заявления на визу,
  • заявления на патент,
  • заявления на регистрацию лекарственного средства,
  • налоговые декларации,
  • заявление на прием к врачу,
  • формы согласия на медицинские манипуляции и т. д.


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

Нужно провести опрос внутри компании, обеспечив конфиденциальность данных


Для проведения внутренних исследований, опросов и аудитов в компаниях не всегда возможно использовать онлайн-сервисы типа SurveyMonkey и Google Forms. Они могут не подойти из-за требований к безопасности и политики управления персональными данными. В таком случае можно заменить онлайн-инструменты на интерактивные PDF-формы.


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

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

О молодой, но мудрой ФПМИ и её последователе ABBYY

24.09.2020 12:15:14 | Автор: admin
Сентябрь волнительное время не только для школьников и студентов, но и для нас в ABBYY. Осенью студенты наших кафедр на Физтехе вернулись к учебе, а десятки наших коллег к преподаванию. Каким будет этот учебный год не загадываем. Просто пусть все будет хорошо. А в этом посте мы расскажем интересные подробности о Физтех-школе прикладной математики и информатики (ФПМИ МФТИ) и о том, как вместе с ней мы уже не первый год готовим крутых специалистов в области Natural Language Processing (NLP) и Computer Vision (CV).

image
Первокурсники ФПМИ на фоне самого популярного корпуса МФТИ для совместных фотографий.

Формально ФПМИ молод. Но уже очень мудр. Поясним: физтех-школа появилась в 2016 году, объединив факультет инноваций и высоких технологий (ФИВТ), созданный в 2006 году, и факультет управления и прикладной математики (ФУПМ), открытый более 50 лет назад.

Эти факультеты, ставшие основой ФПМИ, окончили многие известные люди. Перечислим часть из них:


Среди совсем молодых звезд:

  • Юрий Гарнов, основатель стартапа TimeAdge. Интервью с ним можно почитать здесь.
  • Иван Глушенков основатель популярного сообщества разработчиков Russian Hackers, сооснователь компании по организации хакатонов Phystech Genesis, многократный победитель и призёр международных и российских хакатонов.

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

Чем ФПМИ отличается от других Физтех-школ? Физтех-школа прикладной математики и информатики специализируется на образовании и исследованиях в области соприкосновения математики, физики, программирования и компьютерных наук. Это сочетание позволяет предлагать своим абитуриентам выбор из большого количества программ и кафедр по самым разным направлениям.

Ежегодно в ФПМИ поступают более 460 первокурсников, большинство из них на бюджетные места. 90% заканчивающих бакалавриат остаются учиться в магистратуре. В этом году в магистратуру поступило около 470 студентов, а в аспирантуру около 73. Всего на ФПМИ более 50 магистерских программ по пяти основным направлениям: машинное обучение, программирование, математика, физическое моделирование и экономика/консалтинг.

В Физтех-школе открыты 30 базовых кафедр различных научно-исследовательских центров (МИАН РАН, ИППИ РАН, ИСП РАН, ФИЦ ИУ РАН и др.) и компаний-партнеров, например, ABBYY, Яндекса, SberTech, Huawei, Tinkoff, S7 Group и других. При их поддержке создана 21 научная лаборатория. Всего на ФПМИ обучаются 2450 студентов это треть от общего числа учащихся на Физтехе.

image
Корпус прикладной математики (КПМ), где расположены почти все кафедры ФПМИ

В ФПМИ студентов и их научно-исследовательскую работу поддерживают разнообразными стипендиями. Помимо государственной, есть грант президента, Абрамовская стипендия, а также поддержка от компаний-партнеров. Например, в этом году ABBYY учредила стипендию для поощрения научных исследований в области мультимодальности и анализа социальных сетей. Кстати, еще можно успеть подать заявку на этот грант до 27 сентября, детали можно найти по ссылке.

Так, и, кажется, мы еще не упомянули о главном. Физтех-школой прикладной математики и информатики руководит Андрей Михайлович Райгородский, доктор физико-математических наук, профессор, лауреат Премии Президента России, заведующий двумя лабораториями и одной кафедрой.


А.М.Райгородский студентам: Ботайте, друзья мои, ботайте!

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


Чем на самом деле занимаются на кафедрах ABBYY


Две кафедры ФПМИ созданы совместно с ABBYY: кафедра компьютерной лингвистики (КЛ), открытая 9 лет назад, и кафедра распознавания изображений и обработки текста (РИОТ), которая существует уже 14 лет. Почему появились эти кафедры? Наша цель находить талантливых ребят с нестандартным мышлением и развивать их способности. В будущем они будут заниматься сложными и амбициозными задачами, которые до них еще никто не решал. И не исключено, что эти ребята будут работать именно в ABBYY.

Обе кафедры ABBYY расположены на территории компании. Здесь ребята и учатся, и участвуют в стажировках и проектах компании, чтобы приобрести опыт, необходимый для дальнейшей работы. Это удобно и для наших сотрудников, которые преподают: им не нужно тратить время на дорогу из института до работы и обратно. А еще офис ABBYY находится не так далеко от Долгопрудного, где расположен Физтех.

image
Результаты работы кафедр ABBYY

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

В этом году к нам на бакалавриат подали заявки 137 студентов, и в результате конкурсных испытаний поступило 28 из них. Учиться на кафедре они начнут в следующем году, в весеннем семестре. Всего обучение продлится 1,5 года. Вот что ребята говорят о выборе кафедры:

Тимур и Артем Нургалиевы, кафедра КЛ:

Тимур: Мы с братом вместе с детства: учились в одном классе, затем в одной группе, а теперь будем учиться на одной кафедре. При поступлении в МФТИ я хотел заниматься наукой, но программирование зацепило сильнее. При этом для меня необходимым условием в будущей профессии является возможность для творчества. Так что через несколько лет вполне могу совместить технологии с рисованием мультфильмов или карьерой блогера!

Артем: Когда все выбирали кафедру, мы с братом и другом создали общий документ, в который каждый вписал критерии для оценки. В процессе мы вместе тщательно оценивали все кафедры, и кафедры ABBYY победили. Мне бы хотелось, чтобы моя работа приносила пользу, и я надеюсь, что в этом у нас с ABBYY много общего. Мне нравится программирование, потому что оно открывает возможности создавать что-то необычное. Если объединить это с долей креатива и удачи, можно добиться многого!


Роман Галкин, кафедра РИОТ: Кафедра ABBYY одна из немногих, где можно на бакалавриате погрузиться в область компьютерного зрения. Это и стало ключевым фактором при выборе. Сейчас мне наиболее интересно машинное обучение, хочу углубиться в Computer Vision. В будущем хочу запустить продукт, основанный на машинном обучении. Среди идей бизнеса есть такие, где нужны навыки работы с изображениями и видео. Надеюсь, знания, которые получу на кафедре, помогут мне в этом!


В магистратуру на кафедрах ABBYY в этом году подали заявки 46 студентов, из них к нам поступили 18 ребят.

Никита Честнов, 5 курс, кафедра РИОТ: До поступления на кафедру РИОТ я учился на кафедре лазерных систем и структурированных материалов (Физтех-школа физики и исследований им. Ландау). Я выбрал магистратуру ABBYY, потому что это лучшее место для участия в ведущих исследованиях в области компьютерного зрения.

Я бы хотел погрузиться в исследования и стать специалистом в области компьютерного зрения. Сейчас мне интересна задача NAS (поиск нейронной архитектуры) в приложении к области CV. Это направление позволяет намного эффективнее проектировать нейронные сети, из-за чего они лучше справляются с поставленными задачами, чем спроектированные человеком.


Ксения Клокова, 5 курс, кафедра КЛ: Я получила экономическое образование, но через какое-то время после окончания бакалавриата поняла, что хочу развиваться в data science. Меня всегда интересовал язык как феномен и обработка текстовой информации, и именно поэтому я начала читать различные статьи, проводить эксперименты. В итоге я приняла решение, что хочу строить научную карьеру в сфере компьютерной лингвистики. Обучение на кафедре это возможность продвинуться к этой цели и перенять знания у лучших специалистов и ученых.

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


Среди наших выпускников есть те, кто учился на кафедре ABBYY, работал у нас, а затем перешел в более крупные международные IT-компании. Например, наш выпускник и бывший коллега Игорь Холопов закончил кафедру РИОТ, в ABBYY прошел путь от младшего до старшего разработчика, а сейчас занимается облачными технологиями в Google в Европе. В американского гиганта также перешла Наташа Болоболова, до этого она училась на кафедре РИОТ. Алексей Журавлев, выпускник и аспирант кафедры РИОТ, бывший руководитель группы Computer Vision Research в ABBYY и автор двух патентов, сейчас работает в компании Х. Звучит таинственно, но компания настолько крута, что мы пока не раскроем ее.

Похимичим в ABBYY Lab



image
Корпус Физтех.Цифра, где находятся большая часть научных лабораторий ФПМИ, включая и ABBYY Lab

Мы в ABBYY уделяем большое внимание направлению исследований и разработок. Более 25% всех затрат на R&D компания инвестирует в исследования в области обработки естественного языка и компьютерного зрения. Это необходимо, чтобы разрабатывать сложные наукоемкие технологии, которые приносят реальную пользу компаниям разных отраслей и людям во всем мире.

Именно поэтому в 2019 году на базе ФПМИ мы создали лабораторию ABBYY Lab. Там студенты и сотрудники МФТИ занимаются передовыми разработками в сфере обработки естественного языка и анализа изображений и исследуют новейшие методы анализа данных.

Какими задачами занимаются сотрудники лаборатории?

Распознавание сложных текстов (например, рукописных, текстов в естественной сцене);
физика цвета и ее применение в задачах сегментации;
синтез реалистичного видео;
нетематическая классификация текстов;
понимание языка социальных медиа;
обнаружение текстовых ориентиров;
межмодальные связи;
дифференцируемые алгоритмы;
автоматизация поиска архитектуры нейронных сетей;
обучение на недостаточных данных: без учителя, с частичным привлечением учителя, по нескольким примерам.

Какими проектами занимаются в ABBYY Lab прямо сейчас?

Автоматизация поиска архитектуры нейронных сетей в задачах комплексного распознавания текста;
иерархические нейронные сети для классификации на большое количество классов;
синтез читающего видео-агента заданной стилистики;
управление вектором стиля при синтезе обучающей выборки для обучения распознаванию рукописного текста.

Лабораторию возглавляет Александр Жуковский, руководитель Computer Vision Research Group в ABBYY.

Александр: Несмотря на пандемию, мы выступили на нескольких международных конференциях: 26-ой международной конференции по компьютерной лингвистике и интеллектуальным технологиям "Диалог", а также 14th IAPR International Workshop on Document Analysis Systems и 17th International Conference on Frontiers of Handwriting Recognition это две конференции про распознавание документов, не столь давно выделенные из основной конференции в области ICDAR. Мой коллега по ABBYY Lab недавно участвовал в воркшопе по моделированию естественной артикуляции человека по произносимой им речи и тексту GENEA (Generation and Evaluation of Non-verbal Behaviour for Embodied Agents) Workshop и получил хорошие результаты.



Если у вас остались вопросы о ФПМИ, кафедрах ABBYY и ABBYY Lab, задавайте их в комментариях!

Кстати, те, кто закончили ФИВТ, ФУПМ или уже ФПМИ, рассказывайте в комментах, чем вам запомнилась учеба в Физтех-школе и что бы вам хотелось улучшить!
Подробнее..

ABBYY FineReader Server против хаоса. Как наше решение удаляет дубликаты и наводит порядок в бизнес-документах?

09.09.2020 12:15:30 | Автор: admin

image


Привет, Хабр! Наверняка вы помните посты о том, как наш ABBYY Recognition Server помогал в оцифровке материалов и каталогов библиотек на Сахалине, в Латвии, Великобритании и в других странах. Мы давно не рассказывали об этом продукте, а ведь все это время он развивался. Мы обучили его новым способностям, прокачали его навыки с помощью интеллектуальных OCR-технологий последнего поколения и даже дали новое имя ABBYY FineReader Server. Объясняем: под общим брендом FineReader мы объединили все продукты для распознавания, конвертации и редактирования документов.


Сегодня ABBYY FineReader Server помогает не только оцифровывать материалы из библиотек и архивов, но и упорядочивать хранение информации в крупных компаниях. Например, группа FESCO оцифровывает бухгалтерские счета и транспортные накладные и отправляет их в единый электронный архив, чтобы быстрее проводить транзакции, а сотрудники PwC прямо с мобильного телефона конвертируют фотографии счетов, договоров и других документов в PDF с возможностью полнотекстового поиска и отправляют их в корпоративные системы. В США юридическая фирма Kantor & Kantor использует это решение, чтобы быстрее находить значимую информацию в тысячах страниц судебных дел.


В этом посте мы расскажем о нескольких новых возможностях ABBYY FineReader Server: как они технически реализованы и для чего крупные компании пользуются ими.


Читать дальше

По данным исследования OReilly Состояние качества данных в 2020 году, большинство крупных компаний испытывают трудности при работе с корпоративной информацией. Например, 60% опрошенных отметили большое число корпоративных источников и дублирование информации в них, а 49% отсутствие контроля над качеством входящих данных. Дубликаты не единственная проблема. Информация устаревает, а объемные и уже не актуальные файлы замедляют поиск информации, затрудняют работу корпоративных систем, да и занимают место, что напрямую влияет на стоимость хранения данных. Это не тот балласт, который стоит переносить в новенькие DMS или ECM-системы.


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


image


Справиться с этими проблемами управлять потоками документов, хранить только нужные данные и в необходимом вам формате помогают технологии интеллектуальной обработки информации. Ниже мы расскажем о нескольких возможностях, которые появились в ABBYY FineReader Server и помогут избавиться от хаоса:


Автоматическое удаление полных дубликатов;
Предварительная обработка документов;
Улучшенное распознавание большинства популярных штрих-кодов, включая ISBN, PDF417, Aztec и QR;
Единый веб-интерфейс для распознавания и конвертации файлов;
Улучшенное сжатие цветных изображений.


Полные дубликаты: найти и остановить


image


В компаниях любого размера, как правило, есть электронные архивы, которые наполнялись в течение многих лет. Допустим, в вашем SharePointе исторически накопилось много файлов. Что там хранится и как можно быстро найти нужный документ иногда большая тайна даже для его создателей. Но не для ABBYY FineReader Server. В нем есть режим работы Аудит, который позволяет посмотреть, какие документы размещены в хранилище и сколько их.


Сначала вы получите общую статистику по файлам: сколько изображений в графическом формате, скан-копий документов, PDF с текстовым слоем, документов MS Word. Кроме того, вы увидите и общее количество файлов в других, не текстовых форматах: видео, аудио, исполняемые файлы, системные файлы приложений и т.д. Их ABBYY FineReader Server не обрабатывает, но они существуют в архиве и это стоит учитывать. Аудит также определит, сколько всего документов стоит конвертировать, какие в хранилище есть группы дубликатов и где они лежат. Расскажем о них подробнее.


Хэш-сумма это уникальный идентификатор файла. Он высчитывается компьютером путем математических преобразований информации, содержащейся в нем. Если файлы являются дубликатами, то хэши у них будут совпадать, даже если у файлов разные имена и расширения. По умолчанию ABBYY FineReader Server использует 128-битный алгоритм хэширования MD5.

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


image


На скриншоте видна статистика: сколько картинок и сканов нужно распознать перед конвертацией, сколько текстовых документов можно перевести в PDF и сколько в хранилище файлов, которые невозможно обработать с помощью FRS. Под табличкой есть отчет по дубликатам и по файлам, чей размер больше 20 МB.


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


Второй режим работы FRS Обработка. Если компания не хочет отправлять в новое хранилище дубликаты документов, то в программе можно поставить галочку Исключить файлы-дубликаты.


image


image


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


Когда обработка завершена, FRS снова выведет отчет по дубликатам. Это сделано для тех пользователей, которые не знают про аудит, не хотят его запускать или случайно пропускают этот этап. У них может появиться вопрос: А были ли вообще в хранилище дубликаты? А какие это файлы? Много ли их?. В отчете будет показана группа дубликатов.


image


Как повысить качество изображения


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


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


image


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


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


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


Поколдовали со штрихкодами


imageПо сравнению с предыдущей версией решения наши разработчики значительно улучшили распознавание ISBN, PDF-417, Aztec и QR-кодов. В некоторых категориях качество повысилось на 15%. При этом скорость обработки увеличилась на 20%.


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


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


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


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


Распознавание и конвертирование прямо в вебе


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


Раньше в FRS было две возможности для такой конвертации.


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


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


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


image


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


image


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


Качество изображения лучше, а вес меньше


В FRS мы усовершенствовали алгоритмы сжатия MRC, чтобы обеспечить высокое качество цветных изображений при сжатии тяжелых файлов. Во-первых, подобрали более оптимальные параметры сжатия MRC для режимов минимального размера и сбалансированного. Во-вторых, использовали нестрогий детектор определения цветности: это значит, что почти черно-белые изображения обрабатываются как черно-белые. Это позволяет заметно уменьшать их размер. Тестирование фичи на образцах из базы изображений ABBYY показало, что уровень сжатия файлов с цветными картинками стал лучше на 10-30%.


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


В качестве заключения


Эта статья рассказывает о самых интересных и необходимых на наш взгляд новых фичах ABBYY FineReader Server. Попробовать их можно уже сейчас скачайте триал-версию продукта бесплатно. Если вам интересно узнать больше подробностей о FRS, то пишите в комментариях свои вопросы!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru