Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Блог компании втб

Код ваш, призы наши принимаем заявки на онлайн-хакатон ВТБ More.Tech

25.09.2020 18:15:34 | Автор: admin
Привет! Мы начали приём заявок на ВТБ More.Tech онлайн-хакатон для молодых амбициозных айтишников. От вас профессиональные навыки, желание участвовать в web- или mobile-треках соревнования и умение работать в команде. От нас призовой фонд 900 тыс. рублей и возможность начать карьеру в системообразующем российском банке.

image

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


Первый трек хакатона для специалистов в web-разработке, второй для разработчиков под iOS/Android. ВТБ More.Tech командное состязание, поэтому лучше заранее собрать под свои знамёна коллег-единомышленников. Впрочем, мы без проблем принимаем заявки от отдельных участников, из которых в дальнейшем сформируются команды.

Задача web-трека создание антифрод-системы для web-приложений банков. Оптимальный, на наш взгляд, состав команды для защиты от мошенников включает frontend- и backend-разработчиков, DevOps-инженера, системного аналитика и product/project-менеджера.

Участникам mobile-трека предстоит разработка приложения, которое сможет распознать модель и марку автомобиля, подобрать актуальное предложение для его продажи и сформировать кредитную заявку. Помимо мобильного и backend-разработчиков mobile-команде явно не помешают дизайнер, а также специалист по компьютерному зрению. И product/project-менеджер, куда же без него.

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

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

Проанализировав опыт крупнейших хакатонов, в том числе знаменитый Tech Fest Munich, мы решили выстроить работу над конкурсными проектами по принципу Dive-Create-Impact: 15 % времени на изучение условий задачи и мозговой штурм, 60 % непосредственно на реализацию, 25 % на доработку и создание презентации. Мы считаем, что такой тайминг способствует принятию наиболее эффективных решений. К тому же участники смогут освоить этот подход и использовать его в своей дальнейшей работе.

Несмотря на режим удалёнки, все четыре дня хакатона насыщены активностями, при этом деятельность каждой команды будут курировать наши менторы. В программе серия митапов с экспертами ВТБ (методология DevOps, гибкие технологии/Agile и другие темы) и мастер-класс по подготовке презентаций. Ознакомиться с расписанием, а также почитать о задачах и условиях участия подробнее можно на официальном сайте хакатона. Там же вы найдёте форму для подачи заявки. Решайтесь скорее: последний день приёма заявок 4 октября.
Подробнее..
Категории: Информационная безопасность , Разработка мобильных приложений , Разработка , Ios разработка , Хакатон , Карьера в it-индустрии , Конкурс , Блог компании втб , Втб , Безопасность веб-приложений , Фрод , Android разработка

Ещё один шаг в сторону open source как и почему мы внедрили Arenadata DB

22.04.2021 10:12:30 | Автор: admin

Привет, Хабр! Меня зовут Станислав Маскайкин, я архитектор аналитических систем ВТБ. Сегодня я расскажу о том, почему мы перевели нашу систему подготовки отчётности с Oracle SuperCluster на российскую Arenadata DB. Как мы выбирали решение, почему не взяли чистый опенсорс, а также о некоторых результатах такой миграции под катом.

Зачем нужен был переход?

Несколько лет назад банк ВТБ объединился с Банком Москвы и ВТБ 24. Каждый из банков имел собственную ИТ-инфраструктуру с отдельным аналитическим контуром. После объединения получилось, что в банке одновременно существуют три разных ИТ ландшафта.

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

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

Исторически ВТБ24 был ориентирован на работу с физическими лицами, ВТБ на работу с юридическими лицами, а Банк Москвы на работу и с первыми, и со вторыми.

На момент объединения этих банков обязательная отчётность формировалась в следующих системах:

  1. Единое хранилище данных (ЕХД) хранилище данных Банка Москвы, реализованное на SuperCluster M8 и ETL-инструменте Informatica Power Center.

  1. Система подготовки отчётности хранилище данных ВТБ24, реализованное на Oracle SuperCluster M8 с программным обеспечением Diasoft Flextera BI. Данные для этой системы готовились в другом хранилище корпоративном хранилище данных (КХД), реализованном на СУБД Teradata и ETL-инструменте SAS Data Integration. КХД, в свою очередь, получало данные из оперативного хранилища данных, реализованного на Oracle SuperCluster M8. А туда они реплицировались из автоматизированных банковских систем при помощи инструмента Oracle Golden Gate.

  1. Корпоративное информационное хранилище хранилище данных ВТБ, реализованное на Oracle Exadata X8-2 и ETL-инструменте Informatica Power Center.

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

Это привело к ещё двум большим проблемам:

  1. Увеличилось время получения данных, что часто приводило к срыву сроков предоставления информации.

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

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

Ещё один момент: многие компоненты нашей инфраструктуры, такие как Oracle SuperCluster, на котором у нас реализована большая часть аналитического ландшафта, попали под End of life. Они были сняты с поддержки производителем и больше не развивались, т.е. обновление необходимо было в любом случае.

Проблема окончания поддержки коснулась не только системы подготовки отчётности, но и озера данных на платформе Oracle Big Data Appliance. К тому моменту а происходило все в 20182019 годах сотрудники ВТБ уже в полной мере оценили data-driven подход и потребляли достаточно много данных. Поэтому с точки зрения бизнеса банка система была критичной. Т.е. перед нами стояла более глобальная задача масштабов всей инфраструктуры.

Параллельно в объединённом ВТБ началась масштабная цифровая трансформация, охватившая все уровни IT, начиная от создания новых ЦОДов и объединения сетей, и заканчивая унификацией автоматизированных банковских систем и созданием омниканальной платформы для фронтальных решений. Всё это кардинально меняло внутренний IT-ландшафт банка.

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

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

Что такое платформа данных? Для себя мы определили её так: это набор сквозных интегрированных технологических решений (технологическое ядро), которые являются основой для разработки и функционирования сервисов по работе с данными банка ВТБ.

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

Мы выделили 6 компонентов технологического ядра:

  1. Управление данными.

  2. Управление качеством данных.

  3. Управление доступом.

  4. Аналитические справочники.

  5. Корректировки.

  6. ETL Framework.

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

Ядром платформы данных является СУБД, на которой реализовывается хранилище данных. Далее расскажу об этом подробнее.

Выбор новой платформы

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

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

Мы рассматривали всех крупнейших производителей подобных решений: Oracle Exadata, Teradata, Huawei. Оценили отечественные разработки практически все, что есть на рынке. Нам показался интересным опенсорс, тем более для банка это не первый заход в тему открытого исходного кода.

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

При выборе платформы мы учитывали следующие критерии:

  • функциональность

  • качество поддержки

  • отсутствие санкционных рисков

  • возможность гибкого масштабирования

  • надёжность

  • безопасность

  • наличие Road Map развития платформы и возможность на него влиять

  • стоимость владения совокупные затраты на программно-аппаратный комплекс на горизонте 10 лет (TCO5).

Если взять последний критерий, то даже с учётом стоимости всех контуров Arenadata DB и самого проекта миграции мы получали существенную экономию на фоне Oracle SuperCluster.

В итоге по совокупности факторов мы выбрали Arenadata DB.

Тестирование платформы

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

В итоге нами были проведены следующие проверки.

  • Функциональное тестирование:

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

  • Отказоустойчивость и отключение компонентов:

  • Отключение дисковых устройств на уровне БД для проверки стабильности работы кластера.

  • Отключение питания одного блока питания на серверах для проверки стабильности работы кластера.

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

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

    • Проведение цикла резервного копирования и восстановления БД на СРК Veritas Netbackup:

      • Полное резервное копирование БД

      • Инкрементальное резервное копирование БД

      • Восстановление БД

  • Управление и качество работы системы:

    • Перезагрузка кластера: фиксация успешного выполнения процедуры перезагрузки.

    • Мониторинг и управление: субъективная балльная оценка от 0 до 5.

    • Генерация тестового отчёта: прогон запроса изсистемы подготовки отчётности в Arenadata DB для анализа качества результата генерируемого отчёта результаты выполнения отчёта должны быть идентичны.

  • Нагрузочное тестирование:

    • Скорость загрузки данных

  • Интеграционное тестирование:

    • Интеграция с ПО Infomatica Power Center

    • Интеграция с Oracle BI

    • Интеграция с QlikView 12.

Результаты тестирования

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

Ниже приведено сравнение скорости выполнения запросов по сравнению с текущим Oracle Super Cluster T5-8.

Тестирование проводил системный интегратор IBS Platformix.

Скорость выполнения синтетического запроса Jmeter (сек)

Arenadata DB (сек.)

Oracle (сек.)

160.3

1291

Кластер показал высокую скорость загрузки данных через ETL-инструмент Informatica Power Center: 200 Мбит/с.

В ходе тестирования была также осуществлена интеграция с основными BI-инструментами, используемыми в Банке ВТБ (Oracle BI и QlikView), и протестирован их функционал.

В QlikView на простейших SQL-запросах протестированы соединение с БД и выборка данных с последующей загрузкой в модель BI-инструмента.

Результаты выполнения представлены в таблице ниже.

Тест 1

Тест 2

Драйвер

ODBC PostgreSQL35W

ODBC PostgreSQL35W

Запрос

select * from user.test1

// 3 коротких поля

select e.* from dds.accounts e

where

e.entry_dt ='2019-02-03'

-and e.partition_source_system_cd ='00006'

and e.src_deleted is null

Строк

20480000

45 920

Затраченное время

0:58

2:59

Скорость загрузки в модель, строк в сек.

353103

257

При выполнении тестов была замечена особенность: получение первых строк данных из БД происходило с задержкой примерно в 23 секунды. После этого скорость выборки данных из БД и их доставки в QlikView становилась очень высокой.

Предположительно данная особенность связана c неоптимальной настройкой коннектора.

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

Цель теста

Предварительные условия

Процедура

Результат

Тестирование отказа диска с данными

Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового уст-ва из работающего сервера.

Подключиться к серверу

Провести процедуру unmount для физического диска

Проверить доступность данных

Данные доступны

Тестирование отказа кэширующего диска

Отказ диска эмулируется физическим извлечением диска или логическим отключения дискового устройства из работающего сервера

Подключиться к серверу

Провести процедуру unmount для физического диска

Проверить доступность данных

Данные доступны

(Отказ кэширующего диска не приводит к потере данных)

Тестирование включения кластера после эмуляции аварии

Отказ сервера при выполнении SQL запроса к базе данных, эмулируется отключением электропитания работающего сервера

Подключиться к серверу

Выполнить SQL запрос

Выключить 1 ноду

Перезапустить выполнение SQL

Данные получены при повторном SQL запросе

Благодарю Дениса Степанова и Никиту Клименко, экспертов IBS Platformix, за предоставленные результаты тестирования.

Сбор отчётности как пилот

Наша цель это миграция на Arenadata DB всех существующих хранилищ банка ВТБ.

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

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

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

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

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

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

Поскольку мы уже видим результаты и детали взаимодействия, около полугода назад стартовал наш основной проект - миграция на продукты Arenadata центрального единого хранилища данных и озера данных. Помимо Arenadata DB, мы используем Arenadata Streaming на базе Apache Kafka и Arenadata Hadoop на базе Apache Hadoop. В ближайшее время первые результаты пойдут в продакшен.

Целевая архитектура платформы данных к концу 2022 годаЦелевая архитектура платформы данных к концу 2022 года

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

Подробнее..
Категории: Информационная безопасность , Администрирование баз данных , Open source , Big data , Аналитика , Базы данных , Oracle database , Блог компании втб , Втб , Ит-инфраструктура , Отчетность , Миграция , Arenadata

Любовь, смерть и роботы рассматриваем рассказы Азимова глазами разработчика

15.09.2020 10:12:59 | Автор: admin


В честь Дня программиста мы решили немного расслабиться и перечитать любимые рассказы Айзека Азимова. И тут нас ждало открытие: оказывается, писатель-фантаст более полувека назад достаточно точно описал многие реалии современной разработки. Как это возможно, спросите вы? Давайте разберёмся вместе.

Из множества рассказов знаменитого фантаста показательна серия о компании Ю. С. Роботс и её сотрудниках. Несколько историй повествуют о буднях испытателей Пауэлла и Донована своего рода тестировщиков роботов, другие о главном робопсихологе, докторе Кэлвин. Спектр проблем, с которыми они сталкиваются, широк и знаком многим современным их коллегам по сей день.

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

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

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

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

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

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

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

Господин сначала создал людей самый несложный вид, который легче всего производить. Постепенно он заменил их роботами. Это был шаг вперёд. Наконец, он создал меня, чтобы я занял место ещё оставшихся людей. Отныне Господину служу Я!

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

Не верит, грустно согласился Пауэлл. Это же рассуждающий робот, чёрт возьми! Он верит только в логику, и в этом-то всё дело
В чём?
Строго логическим рассуждением можно доказать всё что угодно смотря какие принять исходные постулаты. У нас они свои, а у Кьюти свои.

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

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

Конечно, но дело-то не в этом. Нельзя же, чтобы он продолжал нести эту чепуху про Господина.
А почему бы и нет?
Потому что это неслыханно! Как можно доверить ему станцию, если он не верит в существование Земли?
Он справляется с работой?
Да, но
Так пусть себе верит во что ему вздумается!

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

Лучше всего проблему испытателей описывает цитата из самого рассказа:

Правильно. Теперь слушай тут вот какая логика! Донован начал загибать волосатые пальцы. Первое: новый робот прошёл все испытания в лаборатории. Второе: Ю. С. Роботс гарантировала, что он пройдёт и полевые испытания на астероиде. Третье: вышеупомянутых испытаний робот не выдерживает. Четвёртое: если он не пройдёт полевых испытаний, Ю. С. Роботс теряет десять миллионов наличными и примерно на сотню миллионов репутации. Пятое: если он не пройдёт испытаний и мы не сможем объяснить почему, очень может быть, что нам предстоит трогательное расставание с хорошей работой.

Под угрозой потери хорошей работы тестировщик способен на многое факт. Герои рассказа перебрали и отвергли множество вариантов проверки от unit-тестирования на месте (можно было бы разобрать его на части и проверить по отдельности, но есть всего 10 дней и ещё неизвестно, даст ли это что-нибудь) до специального тестового окружения (которое есть, но на далёкой Земле и весит 10 тонн). Что остаётся? Имитировать условия, при которых появляется баг, и искать, искать причину. Такова, увы, доля многих тестировщиков современности. Правда, им повезло больше в отличие от героев рассказа, нынешним специалистам хотя бы не приходится для этого умышленно взрывать шахту вместе с собой. Зато под завалом камней человек и думает куда эффективнее, и хорошо, что разработчики пока не взяли на вооружение этот приём.

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

Я и говорю. Команды, отдаваемые одновременно по шести каналам! В обычных условиях один или несколько пальцев выполняют несложную работу, которая не требует пристального наблюдения за ними. Ну, точно так же, как наши привычные движения при ходьбе. А в чрезвычайных обстоятельствах нужно немедленно и одновременно привести в действие всех шестерых. И вот тут что-то сдаёт. Остальное просто. Любое уменьшение требуемой от него инициативы, например появление человека, приводит его в себя. Я уничтожил одного из роботов, и Дейву пришлось командовать лишь пятью, инициатива уменьшилась, и он стал нормальным!

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

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

Мы с вашим молодым мистером Блэком приготовили небольшой сюрприз. Видите ли, пространство между мной и роботами было залито не гамма-лучами, а инфракрасными. Обычным тепловым излучением, абсолютно безобидным. Нестор-10 знал это и ринулся вперёд. Он ожидал, что и остальные поступят так же под действием Первого закона. Только через какую-то долю секунды он вспомнил, что обычный НС-2 способен обнаружить наличие излучения, но не его характер. Что среди них только он один может определять длину волны благодаря обучению, которое он прошёл на Гипербаэе под руководством обыкновенных людей. Эта мысль не сразу пришла ему в голову, потому что была слишком унизительной для него. Обычные роботы знали, что пространство, отделявшее их от меня, гибельно для них, потому что мы им это сказали, и только Нестор-10 знал, что мы лгали. И на какое-то мгновение он забыл или просто не захотел вспомнить, что другие роботы могут знать меньше, чем люди Комплекс превосходства погубил его.

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

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

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

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

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

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

И если бы робот не был надёжнее человека, всё было бы в порядке. К сожалению, на Ю. С. Роботс считали своим долгом сделать робота надёжнее человека. Роботу было приказано крепко схватить рычаг, притянуть его к себе и держать. Крепко! Это слово было выделено, повторено, подчёркнуто. И робот выполнил приказ. Но вот незадача: робот раз в десять сильнее человека, в расчёте на которого был сконструирован рычаг.
Вы хотите сказать
Я не хочу сказать, а говорю, что рычаг погнулся. Погнулся вполне достаточно для того, чтобы сместить спусковой механизм. И когда тепло рук робота сместило термоэлемент, контакта не произошло

Подобных рассказов, отчасти кажущихся устаревшими, но во многом предвосхитивших события будущего, немало и у Азимова, и у других писателей. Жаль только, что таких высокоразвитых роботов у нас всё ещё нет, а проблемы и дедлайны всегда с нами, это великий фантаст подметил верно.
Подробнее..
Категории: Научно-популярное , Разработка , Тестирование , Читальный зал , Робототехника , Блог компании втб , Азимов

Как ВТБ помогает снизить комиссию за приём платежей до 0,4 с помощью QR-кода

03.12.2020 10:23:07 | Автор: admin

С 2019 года в России работает система быстрых платежей (СБП) возможность переслать деньги в любой банк участник системы по номеру телефона и, что не менее важно, новый способ для юрлиц принимать платежи по QR-коду. Мобильный банк сейчас в кармане у многих, и мы подумали: почему бы не сделать такой продукт, который позволит легко, быстро и c низкой комиссией принимать платежи от покупателей и делать это там, где удобно?

Сказано сделано. За три месяца полностью на удалёнке мы разработали мобильное приложение и провели пилот, в рамках которого обкатали сервис в четырёх городах, а уже сейчас он доступен по всей России. Платежи можно принимать через обычный смартфон, просто сгенерировав QR-код и показав его покупателю для оплаты. Размер комиссии, в зависимости от вида деятельности, составляет 0,4% или 0,7% от суммы платежа. О концепции продукта, его разработке и многом другом мы хотим рассказать в этой статье. Заходите, будет интересно.

Как возникла идея

Не будем лукавить приём платежей через QR-код не является чем-то инновационным. У всех на виду Китай, где этот вариант оплаты стал чуть ли не главным. И когда Центробанк заявил о подобной возможности как одной из важных фич своей СБП, мысль стала работать.

QR-коды уже давно используются повсеместно даже банально на квитанциях ЖКХ. И у нас родилась идея: а что если платёж через СБП поможет снизить комиссию за обслуживание? Надо просто сделать правильную и удобную обёртку сервиса так клиенты смогут принимать платежи от физических лиц по QR-коду. Win-Win!

Как идея реализовывалась

Увы (кому-то ура), но тотальная удалёнка наша новая реальность. Поэтому и набирать команду, и работать пришлось дистанционно. Изначально на проекте было около 10 человек. Мы внедрили Scrum и постепенно наращивали численность команды. Сейчас над проектом трудится около 30 человек, поделённых на 3 команды так проще планировать спринты.

Всего от старта разработки до выхода в App Store и Google Play у нас ушло чуть больше 3 месяцев. В бэкенде, написанном на Kotlin, реализована микросервисная архитектура. Он размещён на серверах ВТБ, а фронтендом является само приложение в версиях под iOS и Android.

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

Что получилось

Новый продукт получил название ВТБ Бизнес QR. Для работы с ним предпринимателю нужно а) иметь расчётный счёт в ВТБ; б) установить на смартфон приложение и и, в общем-то, всё.

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

Две чашки кофе и один QR-кодДве чашки кофе и один QR-код

Покупатель считывает код из мобильного приложения любого банка, подключённого к СБП (полный список банков, работающих в системе, можно посмотреть здесь во вкладке Оплата по QR), и оплачивает счёт. Статус платежа сразу отображается в ВТБ Бизнес QR, а зачисление на расчётный счёт происходит в течение 15 секунд.

Историю транзакций можно посмотреть на отдельном экранеИсторию транзакций можно посмотреть на отдельном экране

Приложение является бесплатным для клиента он платит только комиссию в размере 0,4% для образовательных, потребительских и ещё ряда категорий товаров (полный список на сайте продукта) и 0,7% для всех остальных.

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

Тестирование

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

Немного статистики: за два месяца после масштабирования количество пользователей выросло в 15 раз до 1500, а география расширилась ещё больше до 300 населённых пунктов. В топ-6 регионов входят Москва, Санкт-Петербург, Новосибирск, Барнаул, Красноярск и Хабаровск. Наиболее активно приложение используется для оплаты покупок в розничной торговле, парикмахерских, салонах красоты и туристических агентствах. Размер максимальной транзакции составил 200 000 руб., средний чек 3 000 руб.

Поддержка

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

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

Что дальше

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

Подробнее..
Категории: Разработка мобильных приложений , Разработка под android , Разработка под ios , Qr-коды , Блог компании втб , Втб , Сбп

MLOps DevOps в мире Machine Learning

25.06.2020 10:15:49 | Автор: admin
В 2018 году в профессиональных кругах и на тематических конференциях, посвященных AI, появилось понятие MLOps, которое быстро закрепилось в отрасли и сейчас развивается как самостоятельное направление. В перспективе MLOps может стать одной из наиболее востребованных сфер в IT. Что же это такое и с чем его едят, разбираемся под катом.



Что такое MLOps


MLOps (объединение технологий и процессов машинного обучения и подходов к внедрению разработанных моделей в бизнес-процессы) это новый способ сотрудничества между представителями бизнеса, учеными, математиками, специалистами в области машинного обучения и IT-инженерами при создании систем искусственного интеллекта.

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

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

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

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

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

  • определение бизнес-идеи;
  • обучение модели;
  • тестирование и внедрение модели в бизнес-процесс;
  • эксплуатация модели.

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

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

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



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


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

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



Как заставить такую продвинутую модель работать?

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

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

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

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

Новый процесс новые вызовы


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

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



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

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

Весь цикл требует большого количества высококвалифицированных специалистов. В определенной точке развития и степени проникновения ML-моделей в бизнес-процессы оказывается, что линейно масштабировать число специалистов пропорционально росту количества задач становится дорого и неэффективно. Поэтому возникает вопрос автоматизации процесса MLOps определение нескольких стандартных классов задач машинного обучения, разработка типовых пайплайнов обработки данных и дообучения моделей. В идеальной картине для решения таких задач требуются профессионалы, одинаково хорошо владеющие компетенциями на стыке BigData, Data Science, DevOps и IT. Поэтому самая большая проблема в индустрии Data Science и самый большой вызов при организации процессов MLOps это отсутствие такой компетенции на имеющемся рынке подготовки кадров. Специалисты, удовлетворяющие таким требованиям, в настоящий момент единичны на рынке труда и ценятся на вес золота.

К вопросу о компетенциях


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

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

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

Что уже сейчас сделано нашей командой


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

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

Вопросы на будущее


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

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

От ответов на эти вопросы во многом будет зависеть, насколько быстро MLOps раскроет свой потенциал полностью.
Подробнее..
Категории: Devops , Машинное обучение , It-компании , Финансы в it , Блог компании втб , Втб , Mlops

Акселератор ВТБ стартапы учатся взлетать

13.08.2020 16:14:35 | Автор: admin
По статистике, выживает около 8 % стартапов, а успех приходит всего к 1 % из них. Главная причина неудачи нет спроса на товары или услуги: технология, может, и крутая, но потенциальные клиенты о ней не знают. Получается, чтобы не выстрелить вхолостую, надо ориентироваться на спрос с самого начала. Один из вариантов корпоративные акселераторы, которые создаются специально для поиска новых технологических решений, полезных компании-организатору.

По такому принципу уже третий год работает акселератор ВТБ, организованный при поддержке Фонда развития интернет-инициатив (ФРИИ). Мы помогаем запуститься стартапам, продукты которых изначально представляют для нас интерес, например могут увеличить прибыль или оптимизировать затраты. О том, как попасть к нам в акселератор и что может из этого выйти, рассказываем под катом.




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

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

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

С 2018 года мы запустили 32 пилотных проекта, 20 из которых успешно завершены. Не менее 10 решений находятся на различных стадиях внедрения в промышленную эксплуатацию. Получается, что выживаемость стартапов, участвующих в нашем акселераторе, примерно в 4 раза выше среднестатистических 8 %. И это вполне объяснимо: начнём с того, что стартап представляет своё решение большому количеству подразделений банка, а значит, имеет высокие шансы найти правильного заказчика. ВТБ крупнейший банк с 1,6 тыс. розничных отделений в РФ, так что после успешного пилота у стартапа есть все возможности для выхода на федеральный уровень.

Как это было


В 2019 году на участие в акселераторе была подана 581 заявка. Условиям отбора соответствовал 301 стартап, из них мы выбрали 12 самых перспективных: сервисы для розничных клиентов и малого бизнеса, инструменты b2c-маркетинга, решения для контакт-центров, технологии оценки потенциальных заёмщиков, инструменты сбора и анализа данных и другие решения:

  • Andata: цифровой паспорт клиента технология для идентификации потенциального клиента на сайте.
  • HintEd конструктор для создания интерактивных подсказок для пользователей корпоративных систем.
  • SweetCard.Stories платформа персональных Stories в мобильном банке с использованием Machine Learning.
  • MobileScoring сервис оценки заёмщиков на основе анонимизированных поведенческих данных клиентов, агрегированных по банкам-партнёрам.
  • OpenTRM автоматическое извлечение данных из сканов первичных документов.
  • KVINT платформа по созданию виртуальных голосовых операторов.
  • Neurodata Lab решение для Customer Experience Management на основе эмоционального искусственного интеллекта.
  • Botman.one визуальный конструктор, позволяющий создавать веб-приложения без помощи программистов.
  • HighTouch Lab удалённая верификация пользователей мобильных сервисов.
  • ТурбоКонтракт конструктор документов с возможностью работы множества пользователей.
  • Cyberatonica Platform платформа транзакционного фрод-мониторинга и адаптивной аутентификации пользователей.
  • WeHire оценка кандидатов с помощью игровых тестирований и эмоционального искусственного интеллекта.

Акселератор глазами участников


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

Артем Таганов, СЕО HintEd:

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

Через несколько дней после того, как мы подали заявку на сайте акселератора, с нами связался представитель ФРИИ. Мы пообщались по Skype, рассказали, что из себя представляем, какие у нас есть наработки. После этого прошли экспертную сессию с разными подразделениями ВТБ. Такой 3-часовой speed-dating: несколько десятков столиков с представителем отдельного подразделения банка за каждым из них. Мы рассказывали, что можем предложить, а представители банка решали, нужна ли им эта технология. Следующий этап Demo Day. Это был питч продолжительностью 3 минуты, мы рассказывали о своём проекте высшему руководству банка. Ну и финальный этап отбор в акселератор.
В своём проекте мы предложили заменить традиционное обучение сотрудников как очное, так и по инструкциям или видео, интерактивным форматом. Он совместим с системами, с которыми работают пользователи. А в банке как раз внедрялось несколько новых систем, так что для обучения работе с ними нужно было подготовить сотрудников.
Нашу технологию, которая помогает обучаться быстро и без отрыва от работы, протестировали корпоративное подразделение банка, департамент малого и среднего бизнеса, а также розничное подразделение. Тестирование прошло отлично, планируем сделать HintEd общебанковской системой.

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

Василий Кузнецов, СЕО SweetCard:

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

На мой взгляд, решающим этапом стал speed-dating именно там решалось, кого пропустить дальше, к выступлению перед жюри. Хочу отметить поддержку ФРИИ: представители фонда не только помогали участникам подготовить выступления, но и содействовали тому, чтобы все презентации были услышаны.
На акселератор мы пришли с платформой для встраивания в мобильное приложение банка ленты персональных Stories, которую можно настроить с учётом интересов и трат конкретного клиента. В результате мы запустили с ВТБ проект персональных анимированных итогов 2019 года.
Клиенты получили детальный персональный отчёт о тратах в различных категориях и зарубежных поездках. Иногда такой отчёт становится большим сюрпризом для человека, который не особо контролирует свои траты. Это реальная забота о клиентах: банк становится ближе к своим пользователям. Нашим главным заказчиком стало CRM-подразделение банка. В планах внедрение в банке полного функционала платформы.

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

Акселератор-2020: не пропустите третий набор


Несмотря на пандемию и связанные с ней сложности, мы открываем третий набор технологических компаний в корпоративный акселератор ВТБ и ФРИИ. Заявки принимаются до 24 августа включительно. Нам нужны:

  • Инструменты маркетинга
  • Сервисы для работы с клиентами
  • Сервисы для b2с-клиентов
  • Сервисы для b2b-клиентов
  • Решения в области HR
  • Сервисы для сотрудников
  • Решения для сбора и анализа данных клиентов
  • Решения в области кибербезопасности

Вполне может быть, что мы ждём именно ваш продукт. Главное соответствовать условиям:

  • Понятное ценностное предложение
  • Готовый к тестированию продукт
  • Готовность доработать продукт под наши требования
  • Юрлицо или ИП в России или за рубежом

Этапы акселератора:

  • До 24.08 приём заявок.
  • С 25.08 по 18.09 заочный отбор проектов экспертами ВТБ и ФРИИ.
  • До 01.10 отборочный интенсив.
  • С 05.10 подготовка к пилотированию и реализации пилота.

Полный перечень направлений, подробности об условиях и этапах акселератора на официальном сайте.
Подробнее..
Категории: Развитие стартапа , Стартап , Финансы в it , Блог компании втб , Втб , Акселератор

Чтобы потолка не стало, а крышу не снесло о чем новый подкаст ВТБ

08.06.2021 22:04:34 | Автор: admin

Привет, Хабр! Команда ВТБ запустила серию подкастов о передовых решениях финтеха Деньги любят техно. Журналист, технологический обозреватель Марина Эфендиева будет обсуждать с экспертами банка, рынка, учеными и бизнесменами перспективы и сложности финтеха: внедрения технологий на основе Big Data, машинного обучения, искусственного интеллекта, вопросы кибербезопасности и защиты данных, перспективные технологические специальности, голосовых помощников и многое другое.

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

Откуда взялся банковскийData Science

Тривиальный, но важный вопрос: почему именно банковский Data Science сегодня занимает передовые позиции?

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

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

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

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

Data Science за 3 месяца без SMS и регистрации

Андрей Райгородский ответил на ещё один очень важный вопрос: можно ли стать дата сайентистом за 3 месяца, как сейчас предлагают многие онлайн-платформы. Он также рассказал о том, какова сейчас потребность в этих специалистах.

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

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

МФТИ (Московский физико-технический институт) лидер этого направления в России фокусируется на фундаментальном обучении и готовит кадры для будущего. При этом есть и специальные нишевые программы например,Школа глубокого обучения, которая заработала в онлайн-формате ещё до того, когда это стало ковидным мейнстримом.

Главной особенностью МФТИ можно считать взаимодействие прикладного и фундаментального. В наши дни это связка между коммерческой индустрией, которая формирует запрос, и академической наукой, которая даёт фундаментальные математические решения. Отличный пример такого симбиоза созданная в начале 2021 года лаборатория ВТБ при МФТИ.

Резюме

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

А вот и сам подкаст:

Деньги любят техно
podcast.ru
Подробнее..
Категории: Искусственный интеллект , Data science , Big data , Финансы в it , Bigdata , Data engineering , Кибербезопасность , Блог компании втб , Защита данных , Подкасты , Финтех

Сегментация потоков документов используем BERT

05.10.2020 16:20:50 | Автор: admin

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


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


В классификации документов модель BERT (Bidirectional Encoder Representations for Transformers) уже применялась ранее. Но для задачи сегментации, насколько нам известно, это первая работа с использованием этой языковой модели.



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


Как это работает


Cегментация потоков документов (Page Stream Segmentation PSS) и сопутствующая задача классификации (Document Image Classification DIC) исследовались многими авторами. В работе Wiedemann, Heyer (2019) сделан обзор многих таких исследований, и среди них выделены два подхода к PSS и DIC: с помощью системы правил (Rule-Based Systems RBS) и с применением машинного обучения.


Системы RBS (Karpinski and Belaid, 2016; Hamdi at el. 2017) подразумевают выделение из распознанного текста с помощью регулярных выражений специальных дескрипторов, определяющих границы документов в потоке. Дескрипторами могут быть приветственные фразы, названия частотных сущностей, номера страниц, layout-признаки: размеры шрифтов, расположение сущностей на странице и др. RBS может оказаться довольно эффективным для однородных (homogeneous) датасетов с хорошим качеством сканов и определённой структурой документов, встречающихся, в частности, в бизнес-документации (счета, накладные, письма и т.п.). Но для RBS необходимо составлять вручную правила для выделения дескрипторов, что является несомненным минусом на датасетах с сильно разрозненными тематиками (heterogeneous datasets).


Подходы с применением машинного обучения (Rusinol at el. 2014; Daher, Belaid, 2014; Agin at el. 2015) и глубокого машинного обучения (Harley at el. 2015; Noce at el. 2016; Gallo at el. 2016; Wiedemann, Heyer, 2019) кажутся более привлекательными, поскольку не требуют глубокого погружения в суть текстов документов, как в RBS. Обучение в этих подходах в основном проводилось на текстовых и визуальных признаках и их комбинациях. Также применялось объединение (fusion) отдельных моделей на текстовых и визуальных признаках, когда одна модель может уточнить результат другой модели и в итоге улучшить общий результат.


В работе Harley at el. (2015) для классификации документов из датасета RVL-CDIP, введённого в этой же работе, используются глубокие свёрточные нейросети CNN на визуальных признаках. В работах Noce at el. (2016) и Gallo at el. (2016) для классификации документов применяются нейросети и трансфер-лёрнинг. В работе Gallo at el. (2016) классификация (DIC) строится только на визуальных признаках, но для повышения качества используются признаки соседних страниц. При этом автоматически решается задача сегментации (PSS): если предсказанный класс текущей страницы отличается от класса предыдущей, значит, начался новый документ. Стоит отметить, что сегментация (PSS) на основе классификации (DIC) имеет большой недостаток: она не разделяет документы одного и того же класса. Если в датасете сильно доминирует какой-либо класс, то сегментация (PSS) на основе классификации (DIC) практически бесполезна, поскольку уже разделённые потоки одного класса необходимо повторно разделять.


В работах Daher, Belaid (2014), Agin at el. (2015), Hamdi at el. (2018), Wiedemann, Heyer (2019) для нахождения границ документов в потоках довольно эффективно используется бинарная классификация: для каждой пары соседних страниц из потока модель предсказывает, является ли следующая страница в паре продолжением документа (SD Same Document) или начался новый документ (ND New Document). В работе Wiedemann, Heyer (2019) задача PSS решается с помощью бинарной классификации (SD/ND) с использованием комбинации текстовых и визуальных признаков и с применением глубоких нейросетей.


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


Идея использования модели BERT в задаче сегментации


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


Модель BERT сначала предобучают на широких корпусах текстов, а затем используют для решения конкретных задач, в том числе и на небольших датасетах. Во время предобучения модель решает две задачи: MLM (Masked Language Model) и NSP (Next Sentence Prediction). В задаче MLM случайно метится (маскируется) определённая доля токенов (слов или частей слов) входной последовательности, и задача состоит в том, чтобы восстановить значения токенов, которые были замаскированы. Задача NSP это бинарная классификация на парах предложений (или спанов текстов), когда нужно предсказать, является ли второе предложение (или спан текста) логичным продолжением первого. При решении конкретных задач предобученный BERT используют для трансфер лёрнинга, извлекая признаки из текста. В случае файн-тюнинга модель BERT делают составной частью специализированной модели, и его вес меняется вместе с весом этой модели. Более подробно о принципах построения этой модели мы рассказывали в нашем предыдущем посте о классификации документов.


Касательно нашей задачи: зачастую начало текста текущей страницы многостраничного документа является логичным продолжением конца текста предыдущей страницы и модель BERT, предобученная на задаче NSP, может улавливать сложные контекстные зависимости этих кусков текстов. Мы предполагаем, что сможем извлекать с помощью BERT сильные текстовые признаки на парах страниц для бинарной классификации (SD/ND).


Генерация входов модели


Мы будем решать задачу сегментации PSS на нашем закрытом датасете (Documents for Credit Dataset DCD), составленном из документов, предоставляемых компаниями для получения кредита в Банке ВТБ.


DCD был накоплен за продолжительный период. Сканирование документов проводилось потоками, как правило, один поток это набор документов от одной компании. Потоки сегментировались в полуавтоматическом режиме. DCD включает около 63 тыс. уже сегментированных одностраничных и многостраничных документов, суммарно около 232 тыс. страниц.


Бизнес-подразделениями банка были выделены около 300 категорий документов. Из них 10 базовых категорий: договор аренды, выписка из реестра участников, устав компании, свидетельство о постановке на учет в налоговом органе, вопросник для юридических лиц, паспорт РФ, лист записи ЕГРЮЛ, свидетельство о государственной регистрации юридического лица, приказы/распоряжения, решения/протоколы, а другие менее значимые документы отнесем к категории Иное.


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


  • Каждый поток должен содержать по одному документу из каждой базовой категории.
  • Каждый поток должен содержать три документа из категории Иное.
  • К 2% потоков из каждой выборки добавляются ещё по два документа из каждого базового класса.
  • 81% одно- и многостраничных документов датасета использовались для генерации потоков Train, 9% для генерации потоков Dev, и 10% для генерации потоков Test.
  • Для формирования потока отдельные документы внутри потока перемешиваются случайным образом с сохранением порядка страниц внутри документа.

Согласно этим правилам мы сгенерировали 10000 потоков для Train, 2000 потоков для Dev, 2000 потоков для Test.


Потоки из Train мы случайным образом перемешали, выставили потоки друг за другом и получили один длинный поток, в котором пары соседних страниц (вернее, извлечённые из них признаки) и их метки (Same Document или New Document) будут, соответственно, входами и целевыми метками нашей будущей модели бинарной классификации. Аналогично из потоков получаем входы и целевые метки для Dev и Test.


Таблица 1. Количественные показатели датасета DCD
Document lengths (pages) Train Test Dev
1 24953 3075 2752
2 10170 1251 1135
3 3680 452 422
4 2549 310 279
5 1857 221 187
6 1246 165 153
7 895 116 105
8 912 89 98
9 968 120 92
>=10 4453 536 515
Single-page documents 24953 (48%) 3075 (49%) 2752 (48%)
Multi-page documents 26730 (52%) 3260 (51%) 2986 (52%)
Total documents 51683 6335 5738
Total pages 188504 22553 21022
# new document (gen. pairs) 133539 (49%) 26879 (62%) 26879 (64%)
# same document (gen. pairs) 136817 (51%) 16218 (38%) 15284 (36%)

Наш подход


Для решения задачи сегментации PSS мы будем использовать бинарную классификацию SD (Same Document) и ND (New Document), описанную выше во введении. В качестве признаков наша модель получает эмбеддинг пары соседних страниц, составленный из визуальных эмбеддингов каждой из страниц, и одного общего текстового эмбеддинга, полученного сразу для пары. Число пар страниц по каждой выборке Train/Dev/Test можно посмотреть в таблице 1.


Визуальный эмбеддинг каждой страницы вектор длины 512 мы получаем как выход предпоследнего слоя CNN ResNet34, He at al. (2015).


Текстовый эмбеддинг, общий для пары страниц, получаем с помощью модели RuBERT (Russian, cased, 12-layer, 768-hidden, 12-heads, 180M parameters) от DeepPavlov. Для этого на вход модели подаем вектор из 512 токенов следующего вида: на первом месте CLS-токен, потом N (информационных) токенов, соответствующих спану текста конца первой страницы из пары, далее (разделяющий) SEP-токен, потом M (информационных) токенов, соответствующих спану текста начала второй страницы из пары, и потом снова SEP-токен. Суммарное число информационных токенов, которое можно разместить во входном векторе, не более 509: N + M <= 509. Мы хотим как можно эффективнее использовать возможности модели BERT, поэтому стремимся максимально заполнить входной вектор модели токенами.



Схема получения текстовых признаков для пары страниц. Ti,j токен с номером i в тексте страницы j. Для удобства отображения отсчёт токенов страницы 1 идёт с конца.


Поскольку RuBERT предобучен на задачу NSP, то CLS-эмбеддинг (вектор длины 768) должен содержать в себе наиболее полную информацию, является ли второй текст логическим продолжением первого. Его и возьмём в качестве общего эмбеддинга для пары страниц.


Бейслайн
Итак, для каждой пары страниц два визуальных эмбеддинга (два вектора длины 512) и один текстовый эмбеддинг (вектор длины 768) объединяются в один общий визуально-текстовый эмбеддинг (вектор длины 1792). Далее на таких эмбеддингах строится бинарная классификация SD (Same Document) / ND (New Document) на основе MLP (Multi Layer Perceptron) с одним скрытым слоем нейронов длины 896, dropuout 0.3. Это наш бейслайн.



Общая схема модели


Основная модель
Следующим шагом мы провели дообучение (further-pretraining) модели RuBERT на обеих задачах MLM и NSP на нашем датасете DCD. Повторно сняли визуально-текстовые признаки, как в бейслайн, и на них построили бинарную классификацию на основе модели MLP с одним скрытым слоем нейронов длины 896 и dropout 0.3. В итоге получили основную модель улучшенного качества.


Результаты


Таблица 2. Результаты бейслайн модели на Test
Число пар Accuracy Kappa
43097 0.9669 0.9294
Пары хотя бы c одним одностр. док-м 19188 0.9771 -
Пары с обеими страницами из многостр. док-тов 23909 0.9587 0.9072

Таблица 3. Результаты основной модели на Test
Число пар Accuracy Kappa
43097 0.9819 0.9615
Пары хотя бы c одним одностр. док-м 19188 0.9898 -
Пары c обеими страницами из многостр. док-тов 23909 0.9756 0.9450

Даже без дообучения модель BERT даёт приемлемое качество 0.9669. А после дообучения на нашем датасете, как и ожидалось, качество ещё немного улучшилось до 0.9819, при этом существенно увеличилась kappa.


Заключение


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

Подробнее..
Категории: Машинное обучение , Natural language processing , Блог компании втб , Bert , Pss , Сегментация изображений

Гонка воображений как развивается финтех в России

04.08.2020 10:19:03 | Автор: admin
Почему финтех в России круче, чем на Западе, как скоро мы начнём управлять счетами через голосовых помощников и кто такие цифровые сотрудники? Всё это обсудили в рамках подкаста Большая Дата его ведущий, директор по технологиям больших данных Билайна Константин Рогов, и заместитель президента председателя правления банка ВТБ Вадим Кулик. В этом посте мы собрали самые интересные ответы Вадима, в которых он рассказал, как технари стали драйвером развития финтеха и как кризисы дали импульс к развитию этой отрасли.



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

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

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

Решились ли вы в ВТБ на какие-то изменения в период самоизоляции?

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

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

В период самоизоляции мы перевели 98% сотрудников на удалёнку, а с ними, разумеется, удалили и процессы. И почти не встретили сопротивления второй стороны. Когда понадобилось, все спокойно перешли на электронку.

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

Звучит прогрессивно. Вообще интересно, что в целом в России банковская отрасль очень продвинутая. Помню, я как-то попытался в центре Берлина расплатиться смартфоном на меня посмотрели как на сумасшедшего. А в России в каком регионе ни окажусь любой предприниматель если не Apple Pay, то перевод на карту точно принимает. Как думаешь, почему так сложилось?

Финансовые сети в России развивались позже, чем в Европе и США. Формирование банковской отрасли совпало с периодом бурного развития технологий.
При этом в тот период (90-е) в России появилось достаточно много людей с хорошим техническим образованием и с высоким IQ, которые остались без работы. Банковскую отрасль в нашей стране сформировали бывшие технари с крутым фундаментальным образованием и опытом разработки инноваций.
Да я и сам бывший технарь.

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

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

Дальше больше. Появился фронт-мониторинг, затем фронт-платёж, после биометрия, компьютерное чтение

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

Хм Ну ладно Запад, а почему такой сценарий не повторился, скажем, в Восточной Европе?

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

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

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

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

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

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

Надеюсь, что это светлое будущее с нативным банком без надоедливой рекламы наступит как можно скорее. А пока я вижу, что многие компании развивают экосистемы, партнёрства. Не так давно ВТБ и Ростелеком объявили о создании совместного предприятия по работе с данными. Чего вы ждёте от этой кооперации?

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

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

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

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

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

Говоря о движении рынка, нельзя не поговорить про технологические стартапы есть ли у вас в ВТБ какая-то система по работе с ними?

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

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

Именно. Но, повторюсь, главное команда.

Ну и, пожалуй, последний вопрос на сегодня: изменится ли продуктовая составляющая банкинга? Появится ли что-то новое или ничего лучше, чем накопил, сохранил, взял кредит, пока не придумано или не востребовано?

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

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

То есть базово платёж это всё равно платёж. Но то, как он обрабатывается, насколько транзакция становится дешевле и для продавца, и для покупателя, меняется радикально. Так что базовые продукты остаются собой, но с процедурной точки зрения они могут переосмысляться и меняться до неузнаваемости.
Подробнее..
Категории: Финансы в it , Блог компании втб , Втб , Финтех

Категории

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

  • Имя: Макс
    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