Сначала DSS LAB делает голос-текст, потом LSTM-классификаторы, сущности Spacy + Yargy (Natasha), лемматизация Pymorphy2, правки Fasttext и Word2Vec, 3 разных суммаризатора и наши решения. Мы можем анализировать ваш голос не только для того, чтобы понимать, о чём ведётся диалог, но и для того, чтобы искать места улучшений банковских продуктов после диалога.

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

Пример:

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

Само распознавание устроено следующим образом:

1. Голос раскладывается на фонемы. Фонемы собираются в слова тем же решением.
2. Из собираемых данных удаляются различные клиентские данные: номера карт, кодовые слова и так далее.
3. Затем полученный поток слов снабжается пунктуацией (точками и запятыми) и заглавными буквами: это нужно для нейросетей, очень чувствительных к такому. Исправляются опечатки, корректируются термины (география).
4. И на выходе получаются текстовые диалоги, как в чате: их анализирует уже нейросеть, пытающаяся привязать смысл в реальном времени.
5. После окончания звонка тексты также анализируются нейросетями, отвечающими за сбор разных метрик по голосовой и чат-поддержке.

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

Комментаторская для турниров

Началось с того, что у нас было некоторое количество старых компов операторов, которые можно было списать либо на которых можно было запустить Counter-Strike 1.6. И это показалось мне идеальным способом чуть больше подружить ИТ-площадки в Обнинске и Москве, потому что надо было постоянно общаться, а друг друга люди толком не знали.

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

Ещё через два года я защищал проект перед управляющим комитетом банка (туда входят председатель правления и другие топ-менеджеры), объясняя, что киберспорт — это ровно то, что нужно, чтобы «выращивать» руководителей команд. Рабочих команд, я имею в виду.

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

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

Постоянный рост конкуренции среди Банков заставляет подстраиваться под разные категории Клиентов. Так, одним проще зайти на сайт и оформить заявку на банковский продукт онлайн, другие же привыкли выбирать новые продукты и услуги непосредственно при живом общении с банковским представителем. В сентябре 2019г. в Хоум Кредит Банке решили запустить новый процесс для Клиента, основная цель которого была в сохранении контакта «Клиент – Оператор Банка» и отказе от физической привязки оператора к офису или стойке Банка в торговом центре.

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

На пути к новой платформе

Стали смотреть в сторону планшетного решения. Реализация нового процесса на планшете на базе архитектуры текущей фронт-офисной системы Банка для работы Операторов с Клиентом выглядела нерациональной по причине устаревшего технологического стека, т.к. текущий фронт-офис представляет собой монолитное web- приложение, написанное 8 лет назад на Silverlight. Попытки работы с текущим фронтом на планшете были не успешными из-за перегруженной ui-части приложения и отсутствия адаптивной вёрстки. Кроме того, отсутствие поддержки Silverlight со стороны Microsoft тонко намекало на то, что жизненный цикл нашего текущего приложения подходит к концу и что наступил момент радикальной переработки и переход на новые технологии. Пришли к решению реализации микросервисной архитектуры. Почему было необходимо отказаться от монолита? Во-первых, из-за масштабируемости решения, улучшения общей отказоустойчивости и независимого обновления компонентов. Во-вторых, в Банке тенденция распределения функционала между продуктовыми командами и микросервисный подход дает в этом случае большую гибкость и независимость команд.

Когда мы работаем с коллекциями и их отображением, перед многими из нас часто
встает выбор между ViewPager (теперь ещё и ViewPager2) и RecyclerView. Эти
компоненты похожи друг на друга по области применения, но серьезно отличаются
интерфейсом и реализацией. Начиная с support library 24.2.0 границы между
данными компонентами стали ещё более размытыми, т.к. появился вспомогательный
класс SnapHelper для автоматического доведения сhildView до
определенного положения на экране, и без устаревшего ViewPager стало проще
обходиться. С недавним релизом ViewPager2, казалось бы, о старом ViewPager и о
практиках его имитации вообще можно забыть (ViewPager2 — это по сути
RecyclerView с дополнительными вспомогательными классами, он позволяет
практически идентично повторить поведение ViewPager и сохраняет совместимость со
старым api).

Так ли это на самом деле? Лично для меня всё оказалось не так просто. Во-первых,
в классическом RecyclerView отсутствует интерфейс PageTransformer для
анимирования сhildView в зависимости от позиции (далее по тексту используется
понятие «позиционная анимация»). Во-вторых, неприятными сюрпризами долгожданного
ViewPager2 оказались модификатор класса final, который ставит крест на
переопределении метода onInterceptTouchEvent (компонент мало пригоден для
вложения горизонтальных списков в вертикальные), и приватность поля
recyclerView.

Итак, столкнувшись в очередной раз с трудностями позиционной анимации при
отображении коллекций с помощью RecyclerView и поковырявшись в ViewPager2 и
MotionLayout, я подумал, что позаимствовать принцип работы
ViewPager.PageTransformer для классической реализации RecyclerView а-ля
ViewPager2 не самая плохая идея.

Всем привет!

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

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

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

Ежедневно наша система генерирует более 130 ГБ «сырых» логов и, несмотря на то, что мы используем ENG стек (Elasticsearch Nxlog Graylog), файловые логи содержат гораздо больше информации (например, stack trace ошибок), поэтому требуют архивирования и хранения.

Так как место хранения ограничено, встаёт вопрос: «А какой архиватор лучше всего справится с этой задачей».

Для решения этого вопроса я написал скрипт на языке PowerShell, который произвел анализ за меня.

Сегодня речь пойдет о том, как обмениваться события между Activities/Fragments и ViewModel в MVVM. Для получения данных из ViewModel, рекомендуется в Activity/Fragment подписываться на данные LiveData, находящиеся во ViewModel. Но что делать для отправки единичных (и не только) событий, таких как показать уведомление или, например, открыть другой фрагмент?

Привет Хабр!

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

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

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

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

Я давно увлекаюсь компьютерными играми, и всегда верил в их потенциал как инструмента повышения вовлеченности сотрудников ИТ, нематериальной мотивации, а в результате — повышения лояльности. Сначала я думал именно об ИТ – ведь у нас общая ИТ-платформа, и где бы ты ни работал, ты всё равно остаёшься айтишником. А компьютерные игры – сетевая история, которая может познакомить и объединить людей из разных регионов.

Опробовать формат киберспортивного тимбилдинга мы решили с небольшой группой коллег – просто оставались после работы и играли в любимые игры. В 2016 году провели первый турнир для сотрудников обнинского и московского ИТ. Играли в Counter strike 1.6 и Quake3, участвовали всего 30 человек.

О чем частенько молчат консультанты по Agile? Во что упираются большие организации, когда решают внедрить Agile-подход? Почему вместо розовых единорожек мы получаем здоровенных бегемотов? Мое выступление на конференции Enterprise Agile Russia — 2019

Привет, %username%

Передо мной была поставлена задача сравнить производительность при сериализации для .NET Core и Golang. Поискав в интернете, наткнулся на репозиторий. Рассматривается простой пример REST микросервиса. Это именно то, что нужно, подумал я. Посмотрев результаты тестирования, я был удивлен. Посмотрев исходный код, я понял, что не так. Вот что мне не понравилось:

• Для сериализации и десериализации выбран массив из 3-х элементов. Этого явно недостаточно.
• Для Golang не используются все возможности языка, а, как известно, встроенная библиотека encoding/json работает медленно.
• В итоге автор сравнивает производительность веб-серверов kestrel и net/http.

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

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

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

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

О том, как мы это делали и с какими трудностями столкнулись, мы расскажем вам в этой статье.

В каждой компании, где присутствует подразделение ИТ, есть ServiceDesk, но у всех он разный. Где-то это простой helpdesk для приема обращений, где-то anykey, у нас в Хоум Кредите первая линия поддержки — ступень к многоуровневому процессу эксплуатации, а для многих сотрудников — первая ступень в большой ИТ.

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

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

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

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

Привет, Хабр!

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

Привет, Хабр!

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

Как данные попадают в банк, и как команда аналитиков следит за этим процессом, разберём в данной статье.

Здравствуйте.

В интернете много сервисов, предоставляющих возможности облачных сервисов. С их помощью можно осваивать технологии BigData.

В данной статье мы в домашних условиях произведем установку на платформу EC2 AWS (Amazon Web Services) Apache Kafka, Apache Spark, Zookeeper, Spark-shell и научимся всем этим пользоваться.