Блог компании сбер

NFC на банкомате небольшой ликбез

27.11.2020 10:16:55 |

Автор: admin

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

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

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

Как пользоваться картой с NFC на банкомате?

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

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

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

Для чего нужно подтверждение?

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

Какое количество банкоматов с NFC?

У нас самая широкая сеть банкоматов в России порядка 71 тысячи устройств, 95 % которых оснащены NFC.

Все новые карты, выпускаемые СберБанком, являются бесконтактными.

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

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

Нужно ли вводить пин-код при использовании NFC?

Да.

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

Как работает NFC в банкоматах?

Первые банковские карты просто прокатывались импринтерами, поэтому на них объёмные цифры номера. Эта система оплаты до сих пор действует как резервная в некоторых магазинах в США на случай отключения света. Она аналогична выписке банковского чека из чековой книжки, что когда-то было очень распространено на Западе, но почти не прижилось в СССР и России. Уровень безопасности обеспечивался контролем за договорами с банком и полицией.

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

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

Так что там про скиммеры?

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

Почему мы рекомендуем пользоваться NFC

NFC-модуль использует EMV-стандарт. EMV (Europay + MasterCard + VISA) международный стандарт для операций по банковским картам с чипом. Этот стандарт первоначально был разработан совместными усилиями компаний Europay, MasterCard и VISA, чтобы повысить уровень безопасности финансовых операций. Стандарт EMV определяет физическое, электронное и информационное взаимодействие между банковской картой и платёжным терминалом для финансовых операций. При бесконтактной сессии используются аналогичные контактной сессии алгоритмы, отличия лишь в способе передачи информации. Например, при обрыве связи на середине транзакции ядро имеет функционал восстановления (Recovery), что гарантирует высокую надёжность проведения операций.

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

Сколько людей забывают карту в банкомате?

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

С использованием NFC за год (с октября 2019 по октябрь 2020) число оставленных в банкомате карт сократилось более чем в два раза.

А пин-код он безопасно передаётся?

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

Что говорят сами клиенты банка?

Мы проводили опрос. Итоги такие:

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

Ещё раз скажу: лучше прикладывать карту/гаджет, потому что это как минимум удобнее и безопаснее.

Насколько технология NFC распространена в Европе?

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

У меня есть вопрос

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

Подробнее..

Категории: Информационная безопасность , Безопасность , Беспроводные технологии , Emv , Блог компании сбер , Nfc , Near field communication , Банкомат , Платёжные карты

Навыки для виртуальных ассистентов на веб-технологиях

28.12.2020 14:06:07 |

Автор: admin

Недавно Cбер запустил Салют семейство виртуальных ассистентов, которые работают на разных платформах. Мы в SberDevices, кроме самого ассистента, занимаемся разработкой инструментов, позволяющих любому разработчику удобно создавать навыки, которые называются смартапы. Кроме общеизвестных диалоговых сценариев в формате чата ChatApp, можно создавать смартапы в формате веб-приложения на любых известных веб-технологиях Canvas App. О том, как создать простейший смартап такого типа, и пойдет сегодня речь.

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

Как это работает по шагам:

Пользователь произносит ключевую фразу, например Салют, какие у меня задачи на сегодня.
Голосовой запрос приходит в NLP-платформу, где разбирается на фонемы, там же определяется его эмоциональный окрас и т.д..
В БД зарегистрированных смартапов находится тот, которому соответствует активационная фраза. Регистрация происходит через SmartApp Studio и доступна всем разработчикам без исключения.
Во время регистрации смартапа в SmartApp Studio разработчик указывает два эндпоинта: один для веб-приложения, второй для сценарного бэкенда. Именно их достанет из БД NLP-платформа, когда найдет соответствующий смартап.
В эндпоинт сценарного бэкенда будет отправлено сообщение с распознанной активационной фразой. Формат сообщений подробно описан в документации SmartApp API.
Эндпоинт веб-приложения будет указан для загрузки в WebView.
Ответ от сценарного бэкенда придёт в веб-приложение в качестве JS-события, подписавшись на которое, можно управлять веб-приложением.

Упрощенная схема для наглядности

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

В SmartApp Graph/IDE, той самой онлайн-среде, в качестве источника можно указать git-репозиторий, чем мы и воспользуемся, чтобы получить эндпоинт до сценарного бэкенда. Далее его надо указать при регистрации нашего смартапа в SmartApp Studio. В качестве эндпоинта веб-приложения укажем любой известный веб-ресурс, например, sberdevices.ru. Позже поменяем на URL нашего веб-приложения.

Шаблон проекта

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

Итак, что мы хотим от приложения:

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

Для создания базового проекта воспользуемся CRA.

> npx create-react-app todo-canvas-app

Для реализации UI нам понадобится как минимум пара компонентов и форма.

Код формы

export const App: FC = memo(() => {  const [note, setNote] = useState("");  return (    <main className="container">      <form        onSubmit={(event) => {          event.preventDefault();          setNote("");        }}      >        <input          className="add-note"          type="text"          value={note}          onChange={({ target: { value } }) => setNote(value)}        />      </form>      <ul className="notes">        {appState.notes.map((note, index) => (          <li className="note" key={note.id}>            <span>              <span style={{ fontWeight: "bold" }}>{index + 1}. </span>              <span                style={{                  textDecorationLine: note.completed ? "line-through" : "none",                }}              >                {note.title}              </span>            </span>            <input              className="done-note"              type="checkbox"              checked={note.completed}            />          </li>        ))}      </ul>    </main>  );});

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

Код редьюсера

const reducer = (state, action) => {  switch (action.type) {    case "add_note":      return {        ...state,        notes: [          ...state.notes,          {            id: Math.random().toString(36).substring(7),            title: action.note,            completed: false,          },        ],      };    case "done_note":      return {        ...state,        notes: state.notes.map((note) =>          note.id === action.id ? { ...note, completed: !note.completed } : note        ),      };    case "delete_note":      return {        ...state,        notes: state.notes.filter(({ id }) => id !== action.id),      };    default:      throw new Error();  }};

Далее будем диспатчить экшены их обработчиков на форме.

Код подключения

export const App: FC = memo(() => {  const [appState, dispatch] = useReducer(reducer, { notes: [] });  //...  return (    <main className="container">      <form        onSubmit={(event) => {          event.preventDefault();          dispatch({ type: "add_note", note });          setNote("");        }}      >        <input          className="add-note"          type="text"          placeholder="Add Note"          value={note}          onChange={({ target: { value } }) => setNote(value)}          required          autoFocus        />      </form>      <ul className="notes">        {appState.notes.map((note, index) => (          <li className="note" key={note.id}>            <span>              <span style={{ fontWeight: "bold" }}>{index + 1}. </span>              <span                style={{                  textDecorationLine: note.completed ? "line-through" : "none",                }}              >                {note.title}              </span>            </span>            <input              className="done-note"              type="checkbox"              checked={note.completed}              onChange={() => dispatch({ type: "done_note", id: note.id })}            />          </li>        ))}      </ul>    </main>  );});

Запускаем и проверяем.

npm start

Работа с голосом

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

npm i @sberdevices/assistant-client

В момент открытия WebView платформа инжектит JS API для взаимодействия с ассистентом. Это биндиги до нативных методов платформы. Assistant Client обёртка, которая в дев-режиме позволяет отлаживать взаимодействие с ассистентом в браузере, а в продакшене предоставляет удобный для веб-приложений API.

Идём в app.js и там же, где наш основной редюсер, создаем инстанс Assistant Client.

const initializeAssistant = () => {  if (process.env.NODE_ENV === "development") {    return createSmartappDebugger({      token: process.env.REACT_APP_TOKEN ?? "",      initPhrase: `Запусти ${process.env.REACT_APP_SMARTAPP}`,    });  }  return createAssistant();};

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

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

Ассистент присылает структурированные команды в формате JSON. Полное описание формата можно найти в документации Assistant Client на GitHub.

interface AssistantSmartAppCommand {  // Тип команды  type: "smart_app_data";  // Любые данные, которые нужны смартапу  smart_app_data: Record<string, any>;  sdkMeta: {    requestId: string;  };}

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

export const App: FC = memo(() => {  const [appState, dispatch] = useReducer(reducer, { notes: [] });  const [note, setNote] = useState("");  const assistantRef = useRef();  useEffect(() => {    assistantRef.current = initializeAssistant();    assistantRef.current.on("data", ({ action }) => {      if (action) {        dispatch(action);      }    });  }, []);    // ...

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

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

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

Дополним код инициализации Asisstant Client.

const initializeAssistant = (getState) => {  if (process.env.NODE_ENV === "development") {    return createSmartappDebugger({      token: process.env.REACT_APP_TOKEN ?? "",      initPhrase: `Запусти ${process.env.REACT_APP_SMARTAPP}`,      getState,    });  }  return createAssistant({ getState });};

И передадим стейт в обработку ассистенту. Формат стейта также описан в документации Asisstant Client.

export const App: FC = memo(() => {  // ...  const assistantStateRef = useRef<AssistantAppState>();// ...  useEffect(() => {    assistantRef.current = initializeAssistant(() => assistantStateRef.current);    // ...  }, []);  useEffect(() => {    assistantStateRef.current = {      item_selector: {        items: appState.notes.map(({ id, title }, index) => ({          number: index + 1,          id,          title,        })),      },    };  }, [appState]);  // ...

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

Тудух может скопиться достаточное количество, чтобы они не влезли в экран. Само собой, мы хотим уметь скроллить экран, чтобы иметь возможность прочитать всё, что скопилось. На устройствах, где нет тач-интерфейса, например, на SberBox, мы можем скроллить пультом ДУ или голосом. Нажатия кнопок на пульте превращаются в события нажатий на стрелки клавиатуры на window, но что делать с голосом?

Голосовые паттерны навигации встроены в NLP-платформу, и разработчику сценария ничего не надо делать самому. А для разработчика веб-приложения достаточно подписаться на специальный тип команд, приходящих от ассистента через Assistant Client. Все вариации навигационных фраз будут кастится в конечное число навигационных команд. Их всего пять: UP, DOWN, LEFT, RIGHT, BACK.

assistant.on('data', (command) => {    if (command.navigation) {        switch(command.navigation.command) {            case 'UP':                window.scrollTo(0, 0);                break;            case 'DOWN':                window.scrollTo(0, 1000);                break;        }    }});

Перезапускаем наше приложение и пробуем после нажатия на лавашар сказать: Напомни купить коту корм. И вуаля!

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

ngrok http 3000

Полученный URL с https указываем в SmartApp Studio, сохраняем черновик и говорим ассистенту: Сбер, какие у меня задачи на сегодня?. Это cработает, если вы залогинены под одним и тем же SberID на устройстве и в SmartApp Studio. Черновики по-умолчанию доступны к запуску на устройствах разработчика.

Вместо эпилога

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

Этот короткое интро скорее, обзор возможностей на искусственном примере. Как сделать смартап с компонентами, оплатой, автотестами, обязательно расскажем в следующих статьях. Спасибо за внимание, ещё увидимся!

По всем вопросам разработки смартапов можно обращаться в сообщество разработчиков SmartMarket в телеграмме.

Подробнее..

Категории: Javascript , React , Open source , Голосовые интерфейсы , Веб-разработка , Блог компании sberdevices , Блог компании сбер , Голосовые ассистенты

Недоумение про ещё один корпоративный чат или как сделать приятно всем

21.06.2021 12:17:59 |

Автор: admin

На рынке мессенджеров сейчас есть примерно всё, как на Привозе. Есть решения на открытом коде, есть мессенджеры с миллиардом пользователей (или даже двумя). Но четкого понимания, что же взять с прилавка, чтоб все сотрудники огромного банка (и его 300+ дочек) с улыбкой открывали какой-то один и это всё проходило бы под требования по безопасности, у меня не сложилось.

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

Чтоб было безопасно. Т.е. чтоб не просто data scientist модный в шортиках из одной американской/китайской/российской компании не мог в рамках своих задач узнать что-то полезное, а даже рядовой админ банка не смог увидеть или унести переписку одного уважаемого человека с другим. Даже в качестве картинки. Даже на свой админский супер-защищённый комп. Следовательно, оно должно быть self-hosted разворачиваемо отдельно и полностью контролируется исключительно теми, кому положено следить и зарплату за это платят. Ещё нужно подключиться к системам, отвечающим за безопасность передаваемого контента. Ещё нужно иметь в руках команды сопровождения все возможные рычаги, чтобы нерадивого пользователя можно было ограничить в желании другому пользователю передавать то, что не положено.

Чтобы было удобно. Сейчас на дворе 2021 год. Но даже закачать справочник пользователей или синтегрить с корпоративной телефонией банка что-то это уже подвиг на грани фантастики. И удивлению моему не было предела тот же slack обладает пользовательским интерфейсом, который физически невозможно объяснить курьеру из доставки подавай ему пользовательский интерфейс ala telegram. И желательно с видео конференциями встроенными. И прям очень нужен голосовой виртуальный ассистент, голосом удобнее. Ещё невозможно объяснить человеку, у которого есть одновременно два телефона, планшет и два компьютера почему ему нужно выбрать, где же можно работать с этим мессенджером, а где остаться без мессенджера. Ну и зачем каждый раз свой номер телефона светить не ясно.

Чтобы было удобно для внутренних коммуникаций. Тут приходят умные люди из разных отделов, департаментов и цельных предприятий и говорят нам возможность узконаправленных рассылок нужна. Таргетированных, как это модно называть. По полу, по городу, по региону, по подразделению, по должности и т.д. И в этот момент все open-source решения для чатов (а их только на github больше 2100 штук) куда-то деваются. Остаются те, кто реально зарабатывает. Но первый пункт не выполняется.

Чтобы развитие продукта помогало бизнесу, а не мешало всем подряд. Удивительно, но с этой точки зрения почти никто не смотрит. Сколько времени сотрудник тратит на поиск телефона в адресной книге где-то там, потом нужно найти телефон, чтобы позвонить и на этом телефоне набрать 11 заветных цифр. И выяснить, например, что номер с ошибкой. Гораздо удобнее нашёл ФИО, посмотрел фото и сразу набрал. Нужно ещё двоих подключить аналогично набрал и добавил. И никакой музыки от абонента, которому кто-то в это время позвонил, портящей всем 114 остальным участникам совещания не только настроение. 2021 на дворе. И чтоб если нужно любой модуль за месяц прикрутить можно было. Ну хорошо, иногда за два

Отсутствие зависимости от вендора и его капризов. Если ты маленькая организация из 50 человек (а по статистике таких ох как много), тебе нужно решение готовое. Даже когда 3000 человек нужно обслужить вопрос даже не стоит идёшь и выбираешь решение. Можно даже покапризничать и тендер объявить. А если у тебя 400 000 сотрудников? А если миллион планируется? Тут и вендоров вечных с хорошим SLA мало, и возможности их контролировать тоже не велики. Или вендор маленький и может случайно помереть при очередном кризисе или принятии закона/уехать ему понадобится всей командой, или вендор большой, но его мало интересуют проблемы конкретного клиента у него самого может быть 40 000 сотрудников и 1000 таких же клиентов по миру.

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

Ну и на всякий случай сошлюсь на бородатые требования одного habrовода (http://personeltest.ru/aways/habr.com/ru/post/405887/ - их мы тоже учли и удовлетворили): кроссплатформенность. Чтоб я наконец-то мог сидя на обеде, или в транспорте, или в отпуске кому-то что-то написать с телефона, да и узнать, что мне кто-то написал. И чтоб мой коллега, у которого Линукс, не делал каждый раз печальное лицо при слове чат. заточенный под общение в компаниях. Чтоб у меня был чат, где есть все мои коллеги и только мои коллеги живой активный проект. Чтобы баги, как застывшие в янтаре насекомые, не висели в продукте до конца времён передача файлов. Ну зачем мне заливать эту картинку в общую папку, если я просто могу кинуть её через чат! нормальная синхронизация уведомлений / непрочитанного. Чтобы не как в Скайпе словил сообщение, и потом в течение 24 часов находишь уведомление о нём на каждом своём девайсе.

Продолжение следует.

Подробнее..

Категории: Diy , Интерфейсы , Разработка , Оптимизация , Работа , Мессенджеры , Блог компании сбер , Мессенджер

Да, мы поменяли UX банкоматов Сбера (новые устройства и новые интерфейсы)

30.12.2020 16:07:24 |

Автор: admin

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

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

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

Самое важное:

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

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

Новый дизайн банкомата

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

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

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

Вот один из первых прототипов:

В конкурс мы пригласили десять лидеров промдизайна, согласились в сжатые сроки спроектировать дизайн лишь двое: Центр прототипирования высокой сложности Кинетика и Seymourpowell.

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

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

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

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

Пример интерфейса нового банкомата:

Что поменялось функционально

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

Раньше мы незначительно увеличивали экраны устройств например, с 17 до 19 дюймов. В новом банкомате экраны увеличились в 1,7 раза до 32 дюймов. Верхняя часть отдана под обучение. Мы установили датчики движения, которые помогут эффективнее использовать верхнюю часть экрана: устройство будет знать, когда пользователь на него смотрит, чтобы знакомить его с сервисами Сбера.

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

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

Голос работает через браузер с включённой опцией работы со звуком, всё завёрнуто в SSL. Голосовая команда по защищённому каналу передаётся в сервис, который переводит записанный голос в последовательность распознанных слов и возвращает эту строку в банкомат. Сформированный интент (смысловое значение фразы) в банкомате вызывает связанный с ним сценарий обслуживания, т. е. фраза внести наличные, положить деньги будет распознана как команда cash in. Набор команд в будущем будет расширяться, предоставив возможность использования голоса для заполнения различных полей, например, при поиске конкретной организации по её имени, длинных реквизитов, адреса и всего, что требуется долго вводить при помощи цифровой клавиатуры. Ну и развитие голосового ввода также позволит улучшить взаимодействие с банкоматом для людей с инвалидностью.

Что будет с банкоматами дальше

Сейчас в Москве установлено четыре банкомата в новом офисе Сбера на Цветном бульваре и четыре в Agile Home Сбера на Кутузовском проспекте. До конца 2020 года в Россию приедут ещё 150 новых банкоматов. Они будут появляться не только в офисах, но и на крупных транспортных узлах и в больших торговых центрах. При этом функционал банкоматов будет зависеть от месторасположения, чтобы устройства решали контекстные месту задачи клиентов. Понятно, что мы одномоментно не заменим все 70 тысяч устройств, тем более, что парк обновлялся не так давно, но сейчас очень важно получить опыт от этих новых устройств.

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

Отдельная тема новые интерфейсы. Чуть позже мы с коллегами расскажем про эти улучшения отдельно. Они тоже давно напрашивались.

Подробнее..

Категории: Интерфейсы , Управление проектами , Usability , Дизайн , Оптимизация , Железо , Блог компании сбер , Банкомат , Функциональность

Новый интерфейс банкоматов Сбера

20.05.2021 16:23:11 |

Автор: admin

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

Новый главный экран. Здесь отображены наиболее часто используемые суммы и операции на основе истории и привычек клиента

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

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

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

Как шла работа

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

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

Под экраном посередине находится ридер.

Убрали объёмные руки, которые раньше показывали, как и что нужно делать (кроме экрана со вводом ПИН-кода, там прикрывать рукой клавиатуру важно).

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

Примеры

Сократили операцию на один шаг, а также добавили анимацию пересчёта денег.

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

Много работали с контрастом:

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

Голос и биометрия

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

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

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

Другие языки

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

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

Где смотреть

Первая партия новых банкоматов появилась в новом офисе Сбера на Цветном бульваре, в Agile Home Сбера на Кутузовском проспекте, а также в офисе на Вавилова, 19. Недавно ещё несколько устройств установили в новых точках в Москве в ТЦ Европейский и ТЦ Авиапарк, а также в Санкт-Петербурге и Хабаровске в нескольких офисах Сбера. Скоро новые устройства появятся по всей стране. Новый банкомат выглядит так:

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

Подробнее..

Категории: Интерфейсы , Управление проектами , Usability , Дизайн , Оптимизация , Биометрия , Железо , Блог компании сбер , Банкомат , Голос

Как мы, сотрудники Сбера, считаем и инвестируем свои деньги

19.10.2020 10:13:52 |

Автор: admin

Нужно ли покупать автомобиль за 750 тысяч рублей при том, что вы ездите 18 раз в месяц или дешевле пользоваться такси? Если вы работаете на заднем сидении или слушаете музыку как это меняет оценку? Как правильнее покупать квартиру в какой момент оптимально заканчивать копить на депозите и делать первый взнос по ипотеке? Или даже тривиальный вопрос: выгоднее положить деньги на депозит под 6% с ежемесячной капитализацией или под 6,2% с ежегодной капитализацией? Большинство людей даже не пытается производить такие подсчёты и даже не хотят собирать детальную информацию о своих деньгах. Вместо подсчётов подключают чувства и эмоции. Либо делают какую-то узкую оценку, например, детально подсчитывают годовую стоимость владения автомобилем, в то время как все эти расходы могут составлять лишь 5% от общих трат (а траты на другие стороны жизни при этом не подсчитывают). Мозг человека подвержен когнитивным искажениям. Например, сложно бросить, несмотря на неокупаемость, дело, в которое вложены масса времени и денег. Люди обычно излишне оптимистичны и недооценивают риски, а также легко внушаемы и могут купить дорогую безделушку или вложиться в финансовую пирамиду.
Понятное дело, в случае банка эмоциональная оценка не работает. Поэтому я хочу сначала рассказать о том, как оценивает деньги обычное физлицо (я, в том числе), и как это делает банк. Ниже будет немного финансового ликбеза и много про аналитику данных в Сбербанке для всего банка в целом.
Полученные выводы приведены только в качестве примера и не могут расцениваться как рекомендации для частных инвесторов, поскольку не учитывают множества факторов, оставшихся за рамками данной статьи.
Например, любое событие типа черный лебедь в макроэкономике, в корпоративном управлении любой из компаний и пр., может привести к кардинальным изменениям.

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

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

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

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

Учёт и оценка всего имеющегося в наличии имущества

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

Оцените, что у вас есть:

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

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

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

Учёт доходов, расходов и динамики накопления имущества

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

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

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

Эти данные позволят нам сравнить доходность и риски от вложений в сдаваемую в аренду недвижимость, в банковские депозиты и в рынок акций. При этом не забудем учесть инфляцию.
Сразу скажу, что в этом посте мы занимаемся исключительно анализом данных и не прибегаем к использованию каких-либо экономических теорий. Просто посмотрим, что говорят наши данные какой способ сохранить и преумножить сбережения в России за последние годы дал наилучший результат.
Кратко расскажем, о том, как собираются и анализируются данные, использующиеся в этой статье, и прочие данные в Сбербанке. Имеется слой реплик источников, которые хранятся в формате parquet на hadoop. Используются как внутренние источники (различные АС банка), так и внешние. Реплики источников собираются разными способами. Есть продукт stork, в основе которого лежит spark, набирает обороты и второй продукт Ab Initio AIR. Реплики источников загружаются на различные кластеры hadoop под управлением Cloudera, в том числе могут быть прилинкованы с одного кластера на другой. Кластеры разделены преимущественно по бизнес-блокам, имеются также и кластеры Лаборатории данных. На базе реплик источников строятся различные витрины данных, доступные бизнес-пользователям и data scientist-ам. Для написания этой статьи были использованы различные приложения spark, запросы к hive, приложения по анализу данных и визуализации результатов в формате графики SVG.

Исторический анализ рынка недвижимости

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

График цен в рублях без учёта инфляции:

График цен в рублях с учётом инфляции (в современных ценах):

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

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

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

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

Количество комнат:	Отношение стоимости годовой аренды квартиры к стоимости приобретения квартиры:
1-комнатные	5,11%
2-комнатные	4,80%
3-комнатные	4,94%
Всего	4,93%

Получили среднюю оценку в 4,93% годовых доходности от сдачи квартиры в аренду сверх инфляции. Также интересен момент, что дешёвые 1-комнатные квартиры сдавать в аренду немного выгоднее. Мы сравнивали цену предложения, которая в обоих случаях (аренды и покупки) немного завышена, поэтому корректировка не требуется. Однако требуются другие корректировки: сдаваемые в аренду квартиры нужно иногда хотя бы косметически ремонтировать, некоторое время занимает поиск арендатора и квартиры пустуют, иногда в цену аренды не заложены коммунальные платежи частично или полностью, также имеет место крайне незначительное обесценивание квартир с годами.
С учётом корректировок, от сдачи жилой недвижимости в аренду можно иметь доход до 4,5% годовых (сверх того, что сама недвижимость не обесценивается). Если такая доходность впечатляет, у Сбербанка есть множество предложений на ДомКлик.

Исторический анализ ставок по депозитам

Рублёвые депозиты в России в последние несколько лет в основном обыгрывают инфляцию. Но не на 4,5%, как сдаваемая недвижимость, а, в среднем, на 2%.
На графике ниже видим динамику сравнения ставок по депозитам и уровня инфляции.

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

Можно фиксировать ставку по пополняемым вкладам в благоприятное время на несколько месяцев вперёд
Ежемесячная капитализация, свойственная многим учтённым в этих усреднённых данных вкладам, за счёт сложных процентов добавляет прибыли
Выше были учтены ставки по топ-10 банкам по информации от Банка России, вне топ-10 можно найти ставки несколько выше

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

Исторический анализ рынка акций

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

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

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

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

Посмотрим, какой же был коэффициент роста индекса MCFTR за последние 1,2,3,,11 лет. Т.е. какова же была бы наша доходность, если бы мы купили акции в пропорциях этого индекса и регулярно реинвестировали бы полученные дивиденды в те же самые акции:

Лет	Начало	Конец	MCFTR нач. с учётом инфл.	MCFTR кон. с учётом инфл.	Коэфф. роста	Годовой коэфф. роста
1	30.07.2019	30.07.2020	4697,47	5095,54	1,084741	1,084741
2	30.07.2018	30.07.2020	3835,52	5095,54	1,328513	1,152612
3	30.07.2017	30.07.2020	3113,38	5095,54	1,636659	1,178472
4	30.07.2016	30.07.2020	3115,30	5095,54	1,635650	1,130896
5	30.07.2015	30.07.2020	2682,35	5095,54	1,899655	1,136933
6	30.07.2014	30.07.2020	2488,07	5095,54	2,047989	1,126907
7	30.07.2013	30.07.2020	2497,47	5095,54	2,040281	1,107239
8	30.07.2012	30.07.2020	2634,99	5095,54	1,933799	1,085929
9	30.07.2011	30.07.2020	3245,76	5095,54	1,569907	1,051390
10	30.07.2010	30.07.2020	2847,81	5095,54	1,789284	1,059907
11	30.07.2009	30.07.2020	2223,17	5095,54	2,292015	1,078318

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

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

Год	Начало	Конец	MCFTR нач. с учётом инфл.	MCFTR кон. с учётом инфл.	Годовой коэфф. роста
1	30.07.2019	30.07.2020	4697,47	5095,54	1,084741
2	30.07.2018	30.07.2019	3835,52	4697,47	1,224728
3	30.07.2017	30.07.2018	3113,38	3835,52	1,231947
4	30.07.2016	30.07.2017	3115,30	3113,38	0,999384
5	30.07.2015	30.07.2016	2682,35	3115,30	1,161407
6	30.07.2014	30.07.2015	2488,07	2682,35	1,078085
7	30.07.2013	30.07.2014	2497,47	2488,07	0,996236
8	30.07.2012	30.07.2013	2634,99	2497,47	0,947810
9	30.07.2011	30.07.2012	3245,76	2634,99	0,811825
10	30.07.2010	30.07.2011	2847,81	3245,76	1,139739
11	30.07.2009	30.07.2010	2223,17	2847,81	1,280968

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

Теперь, для лучшего понимания, давайте абстрагируемся от этого индекса и посмотрим на примере конкретной акции, какой бы получился результат, если вложиться в эту акцию 15 лет назад, повторно вкладывать дивиденды и платить налоги. Результат посмотрим с учётом инфляции, т.е. в современных ценах. Ниже показан пример обыкновенной акции Сбербанка. Зелёный график показывает динамику стоимости портфеля, изначально состоявшего из одной акции Сбербанка в современных ценах с учётом реинвестиции дивидендов. За 15 лет инфляция обесценила рубли в 3.014135 раз. Акция Сбербанка за эти годы подорожала с 21.861 руб. до 218.15 руб., т.е. цена выросла в 9.978958 раз без учёта инфляции. За эти годы владельцу одной акции было выплачено в разное время дивидендов за вычетом налогов в сумме 40.811613 руб. Суммы выплаченных дивидендов показаны на графике красными вертикальными палочками и не относятся к самому графику, в котором дивиденды и их реинвестиция также учтены. Если всякий раз на эти дивиденды вновь покупались акции Сбербанка, то в конце периода акционер уже владел не одной, а 1.309361 акциями. С учётом реинвестиции дивидендов и инфляции исходный портфель подорожал в 4.334927 раз за 15 лет, т.е. дорожал в 1.102721 раз ежегодно. Итого, обыкновенная акция Сбербанка приносила владельцу в среднем 10,27% годовых сверх инфляции каждый из 15 последних лет:

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

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

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

Акция	Начало	Конец	Коэфф. инфляции	Нач. цена	Кон. цена	Рост числа акций за счёт реинве- стиции диви- дендов, раз	Итоговый средне- годовой рост, раз
Лензолото	30.07.2010	30.07.2020	1,872601	1267,02	17290	2,307198	1,326066
НКНХ ап	30.07.2010	30.07.2020	1,872601	5,99	79,18	2,319298	1,322544
МГТС-4ап	30.07.2010	30.07.2020	1,872601	339,99	1980	3,188323	1,257858
Татнфт 3ап	30.07.2010	30.07.2020	1,872601	72,77	538,8	2,037894	1,232030
МГТС-5ао	30.07.2010	30.07.2020	1,872601	380,7	2275	2,487047	1,230166
Акрон	30.07.2010	30.07.2020	1,872601	809,88	5800	2,015074	1,226550
Лензол. ап	30.07.2010	30.07.2020	1,872601	845	5260	2,214068	1,220921
НКНХ ао	30.07.2010	30.07.2020	1,872601	14,117	92,45	1,896548	1,208282
Ленэнерг-п	30.07.2010	30.07.2020	1,872601	25,253	149,5	1,904568	1,196652
ГМКНорНик	30.07.2010	30.07.2020	1,872601	4970	19620	2,134809	1,162320
Сургнфгз-п	30.07.2010	30.07.2020	1,872601	13,799	37,49	2,480427	1,136619
ИРКУТ-3	30.07.2010	30.07.2020	1,872601	8,127	35,08	1,543182	1,135299
Татнфт 3ао	30.07.2010	30.07.2020	1,872601	146,94	558,4	1,612350	1,125854
Новатэк ао	30.07.2010	30.07.2020	1,872601	218,5	1080,8	1,195976	1,121908
СевСт-ао	30.07.2010	30.07.2020	1,872601	358	908,4	2,163834	1,113569
Красэсб ао	30.07.2010	30.07.2020	1,872601	3,25	7,07	2,255269	1,101105
ЧТПЗ ао	30.07.2010	30.07.2020	1,872601	55,7	209,5	1,304175	1,101088
Сбербанк-п	30.07.2010	30.07.2020	1,872601	56,85	203,33	1,368277	1,100829
ПИК ао	30.07.2010	30.07.2020	1,872601	108,26	489,5	1,079537	1,100545
ЛУКОЙЛ	30.07.2010	30.07.2020	1,872601	1720	5115	1,639864	1,100444

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

Задача. Найти акцию, стабильно дающую доход выше недвижимости (среднегодовой коэффициент роста 1.045 свыше инфляции) максимальное число раз по каждому из последних 10 одногодовых периодов, когда акция торговалась.
В этой и следующих задачах имеется в виду вышеописанная модель с реинвестицией дивидендов и учётом инфляции.
Вот победители в этой номинации согласно нашему анализу данных. Акции в верхней части таблицы из года в год стабильно показывают высокую доходность без провалов. Здесь Год 1 это 30.07.2019-30.07.2020, Год 2 это 30.07.2018-30.07.2019 и т.д.:

Акция	Число побед над недви- жимо- стью за после- дние 10 лет	Год 1	Год 2	Год 3	Год 4	Год 5	Год 6	Год 7	Год 8	Год 9	Год 10
Татнфт 3ап	8	0,8573	1,4934	1,9461	1,6092	1,0470	1,1035	1,2909	1,0705	1,0039	1,2540
МГТС-4ап	8	1,1020	1,0608	1,8637	1,5106	1,7244	0,9339	1,1632	0,9216	1,0655	1,6380
ЧТПЗ ао	7	1,5532	1,2003	1,2495	1,5011	1,5453	1,2926	0,9477	0,9399	0,3081	1,3666
СевСт-ао	7	0,9532	1,1056	1,3463	1,1089	1,1955	2,0003	1,2501	0,6734	0,6637	1,3948
НКНХ ао	7	1,3285	1,5916	1,0821	0,8403	1,7407	1,3632	0,8729	0,8678	1,0716	1,7910
МГТС-5ао	7	1,1969	1,0688	1,8572	1,3789	2,0274	0,8394	1,1685	0,8364	1,0073	1,4460
Газпрнефть	7	0,8119	1,3200	1,6868	1,2051	1,1751	0,9197	1,1126	0,7484	1,1131	1,0641
Татнфт 3ао	7	0,7933	1,0807	1,9714	1,2109	1,0728	1,1725	1,0192	0,9815	1,0783	1,1785
Ленэнерг-п	7	1,3941	1,1865	1,7697	2,4403	2,2441	0,6250	1,2045	0,7784	0,4562	1,4051
НКНХ ап	7	1,3057	2,4022	1,2896	0,8209	1,2356	1,6278	0,7508	0,8449	1,5820	2,4428
Сургнфгз-п	7	1,1897	1,0456	1,2413	0,8395	0,9643	1,4957	1,2140	1,1280	1,4013	1,0031

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

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

Приведём анекдот 2008 года.
Джон Смит, выпрыгнувший из окна 75-го этажа на Уолл Стрит, после удара о землю подпрыгнул на 10 метров, чем немного отыграл свое утреннее падение.

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

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

Наша модель просчитала все варианты ширины окрестности вокруг дат выплаты дивидендов за всю историю. Были приняты следующие ограничения: M<=30, N>=20. Дело в том, что далеко не всегда ранее, чем за 30 дней до выплаты дивидендов заранее известна дата и суммы выплаты. Также дивиденды приходят на счёт далеко не сразу, а с задержкой. Считаем, что нужно от 20 дней, чтобы гарантированно получить на счёт и реинвестировать дивиденды. С такими ограничениями модель выдала следующий ответ. Наиболее оптимально покупать акции за 34 дня до даты выплаты дивидендов и продавать их через 25 дней после даты выплаты дивидендов. При таком сценарии в среднем получался рост в 3,11% за этот период, что даёт 20,9% годовых. Т.е. при рассматриваемой модели инвестирования (с реинвестицией дивидендов и учётом инфляции) если покупать акцию за 34 дня до даты выплаты дивидендов и продавать её через 25 дней после даты выплаты дивидендов, то имеем 20,9% годовых свыше уровня инфляции. Это проверено усреднением по всем случаям выплаты дивидендов из нашей базы.

Например, по привилегированной акции Сбербанка такой сценарий входа-выхода давал бы 11,72% роста свыше уровня инфляции за каждый вход-выход в окрестности даты выплаты дивидендов. Это составляет аж 98,6% годовых свыше уровня инфляции. Но это, конечно, пример случайного везения.

Акция	Вход	Дата выплаты дивидендов	Выход	Коэфф. роста
Сбербанк-п	10.05.2019	13.06.2019	08.07.2019	1,112942978
Сбербанк-п	23.05.2018	26.06.2018	21.07.2018	0,936437635
Сбербанк-п	11.05.2017	14.06.2017	09.07.2017	1,017492563
Сбербанк-п	11.05.2016	14.06.2016	09.07.2016	1,101864592
Сбербанк-п	12.05.2015	15.06.2015	10.07.2015	0,995812419
Сбербанк-п	14.05.2014	17.06.2014	12.07.2014	1,042997818
Сбербанк-п	08.03.2013	11.04.2013	06.05.2013	0,997301095
Сбербанк-п	09.03.2012	12.04.2012	07.05.2012	0,924053861
Сбербанк-п	12.03.2011	15.04.2011	10.05.2011	1,010644958
Сбербанк-п	13.03.2010	16.04.2010	11.05.2010	0,796937418
Сбербанк-п	04.04.2009	08.05.2009	02.06.2009	2,893620094
Сбербанк-п	04.04.2008	08.05.2008	02.06.2008	1,073578067
Сбербанк-п	08.04.2007	12.05.2007	06.06.2007	0,877649005
Сбербанк-п	25.03.2006	28.04.2006	23.05.2006	0,958642001
Сбербанк-п	03.04.2005	07.05.2005	01.06.2005	1,059276282
Сбербанк-п	28.03.2004	01.05.2004	26.05.2004	1,049810801
Сбербанк-п	06.04.2003	10.05.2003	04.06.2003	1,161792898
Сбербанк-п	02.04.2002	06.05.2002	31.05.2002	1,099316569

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

Поставим нашей модели ещё одну задачу по анализу данных:

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

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

Акция	Количество случаев выигрыша более 10% годовых сверх инфляции	Количество случаев выплаты дивидендов	Доля случаев победы	Средний коэфф. роста
Лензолото	5	5	1	1,320779017
МРСК СЗ	6	7	0,8571	1,070324870
Роллман-п	6	7	0,8571	1,029644533
Россети ап	4	5	0,8	1,279877637
Кубанэнр	4	5	0,8	1,248634960
ЛСР ао	8	10	0,8	1,085474828
АЛРОСА ао	8	10	0,8	1,042920287
ФСК ЕЭС ао	6	8	0,75	1,087420610
НМТП ао	10	14	0,7143	1,166690777
КузбТК ао	5	7	0,7143	1,029743667

Из проведённого анализа рынка акций можно сделать такие выводы:
1) Проверено, что заявленная в материалах брокеров, инвестиционных компаний и прочих заинтересованных лиц доходность акций выше депозитов и инвестиционной недвижимости имеет место быть.
2) Волатильность рынка акций очень высокая, но на долгий срок с существенной диверсификацией портфеля вкладываться можно. Ради добавочных 13% налогового вычета при инвестиции на ИИС открывать для себя рынок акций вполне целесообразно и сделать это можно, в том числе, в Сбербанке.
3) Исходя из анализа результатов за прошлые периоды найдены лидеры по стабильной высокой доходности и по выгодности входа-выхода в окрестности даты выплаты дивидендов. Однако результаты не такие уж однозначные и руководствоваться только ими в своём инвестировании не стоит. Это были примеры задач на анализ данных.

Итого:
Полезно вести учет своего имущества, а также доходов и расходов. Это помогает в финансовом планировании. Если удаётся копить деньги, то есть возможности инвестировать их под ставку выше инфляции. Анализ данных из озера данных Сбербанка показал, что депозиты ежегодно приносят 2%, сдача квартир в аренду 4,5%, а российские акции около 10% свыше инфляции при наличии существенно больших рисков.

Автор: Михаил Гричик, эксперт профессионального сообщества Сбербанка SberProfi DWH/BigData.

Профессиональное сообщество SberProfi DWH/BigData отвечает за развитие компетенций в таких направлениях, как экосистема Hadoop, Teradata, Oracle DB, GreenPlum, а также BI инструментах Qlik, SAP BO, Tableau и др.

Подробнее..

Категории: Программирование , Визуализация данных , Sql , Хранилища данных , Облачные вычисления , Код , Аналитик , Анализ данных , Etl , Разработчик , Таблица , Блог компании сбер

Открываем доступ к Platform V опенсорсному суперфреймворку Сбера

18.05.2021 14:13:42 |

Автор: admin

У нас примерно три тысячи команд разработки, поэтому, очевидно, нам нужен был какой-то фреймворк для разработчиков. Спустя несколько поколений эволюции мы собрали вообще всё, что было разработано в банке, в единую систему. Можно, условно, постучать по API для доступа к любому нужному сервису и получить кусочек конструктора. Сейчас мы даём доступ для разработки на этой Платформе.

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

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

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

Что внутри

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

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

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

Доступы

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

Ещё одна точка входа developer.sber.ru. Там можно уже начинать писать приложения под Платформу.

Компоненты Платформы находятся или на территории заказчика, или в наших ЦОДах в России, то есть сразу обеспечивается полное соответствие отечественным стандартам в частности финансовой информации, персональных данных и так далее.

Компоненты

Начать работу

Ссылка на СмартМаркет раздел с документацией по Платформе. Откроем завтра.

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

Подробнее..

Категории: Программирование , Управление проектами , Open source , Управление разработкой , Api , Архитектура , Фреймворк , Опенсорс , Управление , Инструменты разработчика , Блог компании сбер , Разработчики , Цифровая платформа , Platform v , Готовые решения

Agile в Сбере как понять, что происходит?

15.03.2021 10:06:02 |

Автор: admin

В декабре 2020 мы провели Sbergile Talks (да, давно это было), нашу первую онлайн- конференцию про Agile в Сбере. Три потока, 31 доклад, спикеры из крупнейших отечественных и иностранных компаний, которые так или иначе связаны с Agile. Нас слушало порядка 10 тысяч человек. Я хочу пробежаться по основным моментам и рассказать, что же там было.

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

Так почему же Agile так интересен российскому рынку?

Agile в России

Ещё пять-семь лет назад в России следовали ценностям, озвученным в Agile-манифесте, в основном ИТ-компании. Перестраивать mindset, тем более в крупных организациях, как наша, никто не спешил.

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

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

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

Где смотреть доклады?

Стрим Организация.
Стрим Продукт.
Стрим Команда.
Обсуждение в чате.
Самые актуальные новости Sbergile в канале.

Какие доклады стоит посмотреть и почему?

В направлении Организация взгляд бизнеса на управление в целом.

В докладе Agile-трансформация Сбера Ксения Яшина рассказывает, как изменился подход в целом. Пример сейчас 100 тысяч pull-реквестов ежемесячно, а в начале 2020 года их было около 60 тысяч. И отправляют их в том числе сотрудники экосистемы.
Насколько эффективен процесс производства и поможет ли восьмирукий разработчик это как раз про полностью новый автоматизированный производственный процесс и единую среду разработки.
Agile #каквСбере для вашей компании про то, как можно внедрить такой же подход с нашей помощью.
Стандартизируй это! Как провести трансформацию и не стать новой Вавилонской башней главное помнить, любой стандарт это гипотеза и должен проверяться как гипотеза. Подробно рассказывается, как выглядит жизненный цикл стандарта от его разработки рабочей группой до утверждения. На выходе сокращение издержек в коммуникациях, отчётности, прозрачность и управляемость.
Трансформация розничного взыскания. От революции к эволюции Денис Кузнецов, директор дивизиона из Департамента по работе с проблемными активами, рассказывает, как их команда стала пионерами рынка. Свои слова подкрепляет крутыми кейсами. Например, ребята запустили продукты вроде электронного взаимодействия с ФССП, робота-коллектора, исполнительную надпись нотариуса. И стали первыми по бенчмаркам во взыскании в стране.
Shiftup Business Agility жизненный цикл бизнес-модели доклад Agile-коуча Янины Лашкевич основан на материалах последней работы Jurgen Appelo и более чем 15-летнем опыте в разработке продуктов и проектов в разных бизнес-моделях.
Мотивация внутри каждого из нас или как выпустить внутреннего профи здесь не будет ничего про пирамиду Маслоу, сложных терминов из психологии. Здесь подробный алгоритм, как повысить внутреннюю мотивацию и определение уровня выполнения потребностей. С отличными примерами.
Как стать вовлекающим лидером тут речь идёт про фасилитирующее лидерство. Про то, как правильно формировать и поддерживать группы, чтобы они эффективно шли к одной общей цели, как взаимодействовать друг с другом, распределять задачи, отслеживать прогресс и действовать по общим принципам.
Как не потерять контроль, когда в периметре 3000+ команд? точно не делать шаг назад в мир документов и согласований. Выход структурировать данные из систем, сделать понятные разрезы на всех уровнях. Понять, что контроль даёт свободу убедить в этом команду, дальше никакой ручной отчётности, только данные из систем.
PI Planning в условиях пандемии это история про модель планирования для больших компаний в период очень сложных изменений. Рассматривается методология, которая довольно редко используется на отечественном рынке.

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

Продуктовый офис. Как запустить конвейер проверки гипотез рассказывает Илья Забелин, управляющий директор, руководитель Продуктового офиса Сбера. Он более десяти лет (из них пять лет в Яндексе) занимается созданием, запуском и развитием своих и корпоративных продуктов в eНealth, ЕdТech, FinТech, E-СОМ. Илья показывает и рассказывает, как очень быстро проверять множество гипотез и как выстроить процессы в компании, способствующие этому.
Выстраивание системы управления клиентским опытом на примере корпоративных клиентов рассказывается о том, как искали причины возможного недовольства, потребительские инсайты и вообще оценивали качество.
И очень практически-полезный доклад Встраивание CX-исследований в жизненный цикл продукта если у вас ещё такого нет, то стоит присмотреться, это практический опыт.
Обучение Agile для лидеров если у вас в планах создать эффективную команду и управлять ею, а времени совсем в обрез. Денис Тучин, Agile-коуч, который вместе со своей командой обучил более 500 руководителей разного уровня, в деталях рассказывает, как организовать процесс, следить за ним по целям в Jira, как снизить time-to-market, не снижая или даже повышая качество продуктов.
Детство. Отрочество. Юность Agile-команды полезный доклад для молодых команд, неофитов Agile, джуниор-продактов. Ребята рассказывают, как разбирались с операционным процессом. По ходу можно сравнить реальный опыт с теорией, избежать ошибок, подсмотрев чужие, узнать, что всё, происходящее с вами, уже кто-то пережил. И выдохнуть.
4 шага к эффективности команд никакой воды, только чистая польза. Рассказывается, как эффективно провести Agile-трансформацию в компании. С чего начать и как довести до конца. Если коротко ускорить поставку, добавить гибкости, выстроить приоритизацию через оценку, мониторить метрики.
СберБизнес. Как мы поменяли управление командами и сократили энтропию тут подробно говорится о капитанской модели изменений Коттера, а самое главное как её применять на практике. И ещё про то, как увеличить эффективность и результативность системы и дать ей возможность масштабироваться.
B2B Digital. Лицом к клиенту здесь можно найти ответ на вопрос Как пройти путь от продукта к клиенту?, начиная с фич, вывода в ПРОМ и заканчивая метрическим целеполаганием и влиянием на клиентский опыт.
Взлетают метрики, команда растёт втрое. Всё это за один год. Как не сойти с ума продакту? о том, как перестать работать без чёткой организации производственного процесса и научиться делегировать. Будут нужны дежурный спринта и дежурный релиза.
С ресурсами любой может: запуск продукта без необходимых средств, времени и плана история про правильную аналитику и оптимизацию приоритетов, ведущую в итоге к максимально быстрому выходу на MVP и его тестированию.

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

Школа Scrum-мастеров как элемент матрицы развития Scrum-мастера про то, как создавать внутри компании специалистов, которые подружат разработку и бизнес. Как разрешать конфликт, когда бизнес хочет продукт здесь и сейчас, а разработка хочет делать это правильно. И те же самые Scrum-мастера выступают не только посредниками между командами и заказчиками, но и помогают командам быть эффективнее.
Как команда Критические заболевания тестирование в два раза ускорила история изменений в процессе релиза, которые позволили за одну итерацию проходиться по основным болевым точкам.
Перезагрузка сознания legacy-команд это боль почти каждого в финансовой сфере, тем более с долгой историей.
Будни Scrum-мастера или как зажечь сердце команды без жертв Дарья Михеинко, лидер направления, Scrum-мастер, аналитик, рассказывает, про то, как важно настроить свой энергетический баланс, чтобы замотивировать команду. Как избежать рутины и максимально эффективно помогать команде, не выгорая.
Разделяй и властвуй. Опыт создания продуктов в малых группах разработки на своем примере ребята доказывают, как за два года можно пройти от двух поставок в ПРОМ до 47, выполнения более 100 задач и ускорения Т2М в 1,5 раза.
Развитие Scrum-мастеров после Школы Scrum-мастеров история о том, как вдвоём можно развивать 50 Scrum-мастеров и что из этого получается. Для Scrum-мастеров есть школа СМ, профессиональное сообщество СМ, гильдии СМ, конференция СМ, чаты для СМ. Так что без помощи не останетесь.
Как Scrum-мастер перевернул тестирование в команде с ног на голову реальные ситуации и новые командные практики.
Ускоряем процесс разработки по максимуму ребята научились выпускать больше релизов от 32 до 55 за год, сократили время от завершения тестирования до внедрения в ПРОМ.
Пройти путь Scrum-мастера без ошибок. Лайфхаки о вопросах, которые себе должен задавать хороший Scrum-мастер. Давайте спросим команду один из ключевых.
Результативность продуктовой команды. Есть ли прогресс? roadmap от усовершенствования системы оценки задач и планирования спринтов до количественного представления результативности участников команды. Путь от оформления описания и пошаговой инструкции с примерами в Confluence до оптимизации и усовершенствования.

Итог

Интерес к конференции в целом и поток вопросов к каждому спикеру подтвердили, что рынок готов к изменениям. Мы уверены, что профильному сообществу необходимо иметь возможность общаться и обмениваться опытом, дискутировать и отстаивать свою точку зрения. 16 марта команда трансформации Сбера запускает новый проект Agile-дебаты. На первой встрече диванные эксперты обсудят, что лучше: выделенный Scrum-мастер или совмещающий? Должен ли владелец продукта руководить командой? Эволюция в Agile-трансформации лучше революции? Присоединяйся и выбери свою сторону. Да пребудет с нами истина!

Подробнее..

Категории: Управление проектами , Конференции , Agile , Конференция , Команда , Управление , Блог компании сбер , Продукты , Организация , Sbergile talks

Встречи планирования разработки в пандемию, или Как устроить электро PIP

15.04.2021 14:13:15 |

Автор: admin

Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе Розничное взыскание и урегулирование Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):

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

С чего началось

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

Вот так выглядит SAFe, и скромную часть в нём занимает PI:

Вот что должны сделать разные участники, чтобы планирование прошло успешно:

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

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

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

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

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

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

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

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

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

И дальше распределение по спринтам. Мы смотрели на оптимистичность, пессимистичность и реалистичность команд и приводили их к чему-то единому, равному. Кто был не нагружен нагружали, а кто был перегружен чуть помогали освободить их бэклог.

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

Процесс

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

Дальше идёт работа команд:

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

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

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

В среднем из запланированного делается по факту 7080 %. Это очень качественный показатель.

Инвестиция в будущее

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

Вот так, если вкратце про PI Planning. Если хотите больше подробностей, то можно посмотреть выступление коллег тут.

Подробнее..

Категории: Управление проектами , Метрики , Разработка , Agile , Scrum , Скрам , Пандемия , Менеджмент , Команда , Планирование , Цели , Блог компании сбер , Pi , Зависимости , Флип , Scrum-мастера , Фасилитаторы

Рассказываем про библиотеку для Process Mining теперь SberPM в открытом доступе

27.04.2021 14:21:47 |

Автор: admin

Process Mining это подход к извлечению, анализу и оптимизации процессов на основе данных из так называемых журналов событий (event logs), доступных в корпоративных ИТ-системах. Являясь своеобразным мостиком между Data Mining и Process Management, он выводит исследование бизнес-процессов на принципиально новый уровень. Подробнее о том, чем полезен такой подход и как мы его применяем вот здесь .

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

DataHolder

Основу для применения Process Mining формируют данные лог-файла, в котором хранится информация о выполненных в рамках одного процесса действиях. Работа с библиотекой начинается с загрузки лога в DataHolder, под капотом которого производится автоматическая предобработка данных удаление нулевых значений, сортировка по времени и т.д. Как следует из названия, DataHolder хранит исследуемые данные с указанием ключевых атрибутов, необходимых для анализа ID (идентификатор события), активности, временные метки начала и/или конца событий. Также для более глубокой и интересной аналитики могут быть добавлены дополнительные атрибуты: ID и роли пользователей, территориальный и продуктовый разрезы, текстовые комментарии и другое.

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

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

Майнеры, визуализация и BPMN

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

SimpleMiner рисует все ребра, найденные в логе;
CausalMiner рисует только прямые связи;
HeuMiner удаляет наиболее редкие связи в зависимости от порога (threshold) чем он больше, тем меньше ребер на графе;
AlphaMiner рисует граф в виде сети Петри с учетом прямых, параллельных и независимых связей между активностями;
AlphaPlusMiner Alpha Miner, который может работать с одноцикловыми (one-loop) цепочками.

Визуализировать полученный в результате работы майнера граф процесса можно встроенными средствами Graphiz следующим образом:

Можно также сохранить (импорт) или загрузить (экспорт) граф в формате BPMN (Business Process Model Notation):

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

Итак, CausalMiner позволяет отобразить процесс наиболее линейно, HeuMiner показывает самые частотные цепочки, а AlphaMiner наглядно демонстрирует параллельные участки процесса.

Метрики

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

ActivityMetric метрики по уникальным активностям;
TransitionMetric метрики по уникальным переходам;
IdMetric метрики по ID;
TraceMetric метрики по уникальным цепочкам активностей;
UserMetric метрики по уникальным пользователям;
TokenReplay fitness, который показывает, насколько хорошо граф описывает бизнес-процесс.

В первых пяти случаях для объекта группировки рассчитываются число появлений, число уникальных ID / активностей / пользователей, процент зацикливаний, временные характеристики (средняя, медианная, максимальная и другие виды длительности) и т. д.

Пример работы класса UserMetric:

Несомненным преимуществом данного модуля является быстрота расчетов. Допустим, перед аналитиком стоит задача определить среднюю длительность самых частотных цепочек событий процесса. Решение методами pandas займет 5 минут и более 10 строк кода, в то время как решение методами SberPM 1 минуту и 3 строчки кода.

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

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

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

Модуль ML

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

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

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

Для кластеризации предназначен класс GraphClustering. Ниже приведен пример работы с ним:

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

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

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

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

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

Более подробное описание всех модулей и классов можно найти в файле tutorial.ipynb, расположенном в репозитории библиотеки SberPM на GitHub.

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

Подробнее..

Категории: Управление проектами , Анализ и проектирование систем , Машинное обучение , Data mining , Бизнес-процессы , Процессы , Process mining , Блог компании сбер , Оптимизация процессов , Process management , Python-библиотека

ДНК (Деление на команды) визуализация взаимосвязей людей и команд

29.04.2021 14:14:31 |

Автор: admin

На рисунке граф, визуализирующий межкомандное взаимодействие в Дивизионе развития и сопровождения производственного процесса (SberWorks) Сбера

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

Jira тикет-системе для управления задачами
Confluence вики-системе для управления требованиями
Bitbucket системе управления кодом

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

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

В итоге, получили следующую визуализацию коммуникаций:

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

Поиск точки отсчёта

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

Как же люди на самом деле, работая, общаются, и общаются, работая?
Есть ли какие-то паттерны?
Зависят ли они от реальной структуры команды?
Как структура общения влияет на метрики эффективности?

Ответы на эти вопросы мы можем найти с помощью нашего продукта.

Как читать ДНК?

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

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

С другой стороны, появилась новая задача нарезать команды так, чтобы улучшить lead time (LT), то есть время от начала разработки до вывода продукта в ПРОМ. LT делится на два этапа: непосредственное время команды и время ожидания. Последнее, в свою очередь, зачастую свидетельствует о зависимостях между командами.

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

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

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

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

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

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

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

Что под капотом?

В бэке стандартно ELK-Stack (Elasticsearch, Logstash и Kibana).
На React мы написали приложение, которое умеет забирать из индекса в Elastic через самописное API данные, к которым был применен алгоритм кластеризации, тем самым отсекая слабые (незначимые) связи и визуализировать эти данные в виде плотных сообществ.
Вы спросите, как мы отсекаем незначимые связи? По результатам предварительного исследования мы определили два самых сильных алгоритма.

1. Алгоритм ACY

ACY алгоритм от Яндекса. Агломеративная кластеризация. Подробнее в статье тут.

2. Алгоритм MCL

MCL марковский процесс, случайные блуждания по Маркову.

Весь алгоритм описан на следующих страницах Марковский алгоритм кластеризации и MCL a cluster algorithm for graphs. В итоге применяем именно его.

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

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

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

Какие планы по развитию?

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

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

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

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

Подробнее..

Категории: Управление проектами , Алгоритмы , Agile , Граф , Блог компании сбер , Работа команд , Трайб , Agile-команда , Деление на команды

Как начать думать про клиента на этапе разработки, а не адаптировать продукт после

28.05.2021 14:21:34 |

Автор: admin

На рисунке прототип продукта для Сбербанк Онлайн.

Есть разные методики для исследования и улучшения клиентского опыта (Customer experience, CX). Сегодня расскажем про одну из них дизайн-мышление, и поможет в этом Ирина Баженова эксперт по исследованию клиентского опыта в Сбере.

До CX Ирина работала в розничном отделении ещё того самого Сбербанка, когда в ходу были сберкнижки, без которых не мог существовать вклад. Бумажную книжку клиент мог случайно испортить намочить, например, тогда её нужно было менять. Она могла просто закончиться, и тогда, если вдруг кто-то помнит, ставился штампик, и владельцу нужно было от руки писать прописью сумму, на которой закончилась его книжка, чтобы перенести всё до копеечки на новую. Конечно, кто-то ошибался, пенсионерам так вообще было очень сложно писать от руки. Главный вопрос, который возник тогда у Ирины: зачем я как специалист прошу сделать это нашего клиента? Ведь ему это сложно делать. И какая от этого практическая польза? Подобных ситуаций было довольно много. Но тогда и банк был другой, и законодательство.

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

Немного про методику

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

Визуализируют методику так:

Разберём пример

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

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

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

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

Шаг 1. Эмпатия

Команда провела шесть глубинных интервью в Москве и пять в других регионах с клиентами, у которых:

имущество застраховано / не застраховано;
был страховой случай / не было страхового случая и прочее.

В результате получили первые гипотезы.

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

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

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

Шаг 2. Анализ и синтез

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

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

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

Полина боится затопить соседей больше, чем саму себя.

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

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

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

И эта связка удивление + инсайт + потребность дала возможность команде сформулировать фичу.

Шаг 3. Генерация идей

Итак, описанным выше способом мы определили 10 ключевых потребностей клиентов, сгенерили примерно 180 идей и сделали две итерации прототипирования.

Шаг 4. Прототипирование

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

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

Кстати, в условиях удалёнки все эти этапы также возможно реализовать на интерактивной доске в Miro.com.

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

Шаг 5. Тестирование

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

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

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

Сбербанк Онлайн Каталог Защита дома.

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

После запуска этого продукта в таком виде в Сбербанк Онлайн количество договоров увеличилось на 41 % в июле 2020 года по сравнению с маем 2020-го.

Почему важно проводить исследования в кросс-функциональных командах?

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

Как правильно выбрать время и формат для CX-исследования?

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

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

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

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

Подробнее..

Категории: Управление проектами , Разработка , Agile , Управление продуктом , Защита , Cx , Блог компании сбер , Исследование продукта , Жизненный цикл продукта , Дизайн-мышление , Sbergile

Модель для распознавания степени поражения лёгких на КТ мы резко увеличили точность сортировки больных

03.12.2020 10:23:07 |

Автор: admin

Срез КТ с зонами матового стекла

Пациентам с подтверждённым COVID-19 делают компьютерную томографию лёгких. Если повезёт один раз, если нет несколько. В первый раз нужно оценить уровень поражения в процентах. В зависимости от квартиля степени поражения определяется дальнейшая схема лечения, и они разительно отличаются. В апреле 2020 мы узнали, что есть две сложности:

КТ трёхмерное изображение, каждый слой такого изображения называется срезом. При 300800 срезах лёгких на КТ врачи тратят от 1 до 15 минут на поиск характерных зон, чтобы определить степень поражения. Одна минута это на глаз, 30 минут это среднее при ручном выделении и подсчёте зон повреждённой ткани. В сложных случаях результат может обрабатываться до часа.
Точность диагностики уровня поражения коронавирусом экспертами на глаз высока на границах 030 % и 70100 %. В диапазоне 3070 погрешность очень высока, и мы обратили внимание, что кто-то из рентгенологов, как правило, системно завышает процент поражения на глаз, а кто-то занижает.

Задача сводится к определению повреждённой ткани лёгких и подсчёту доли их объёма к общему лёгких.

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

В конце мая была бета. В июле была готовая модель для разных видов используемого в России КТ-оборудования. Мы это команда в Лаборатории по искусственному интеллекту Сбера. Мы в целом публикуем свои разработки в научной литературе (MICCAI, AIME, BIOSIGNALS), а про это будем рассказывать ещё на AI Journey.

Почему это важно

Рентгенологи в конце апреля уже получили очереди. Важно было:

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

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

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

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

Сама задача

На входе аксиальные срезы определённой толщины. Обычно в настройках ставится от 0,5 мм до 2,5 мм. Грудная клетка это от 300 до 800 двухмерных картинок. Они приведены в примерное соответствие друг с другом, то есть уже преобразованы так, чтобы можно было выстроить, условно, снимки на полупрозрачной плёнке заданной же толщины, и получилась бы модель грудной клетки. Но всё уже давно, разумеется, в цифровом виде.

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

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

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

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

Алгоритм определяет для каждой точки наличие консолидации. Использованная нейросетевая модель основывается на архитектуре U-Net, опубликованной в 2016 году. Преимущество архитектуры U-Net в том, что нейросеть анализирует исходные изображения в разных масштабах, и это позволяет свёрточным слоям смотреть на участки картинки, размер которых растёт в геометрической прогрессии по мере увеличения глубины нейросети. Другими словами, каждая свёртка смотрит на маленькую зону 3 3 px. Потом происходит уменьшение масштаба в два раза, потом ещё в два: каждая следующая свёртка смотрит на область 3 3 пикселя, но за этими пикселями стоят части изображения, уменьшенные в несколько раз (6 6, 12 12, ). В итоговом ансамбле ещё две свёрточных нейросети похожей архитектуры на базе U-Net, с более тяжелой сжимающей частью, чем в оригинальной статье.

Где ошибается сеть, но не ошибаются врачи

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

Нормализация

Томографы пишут файлы в стандарте DICOM, но интерпретация стандарта и форматы записи могут сильно отличаться, поэтому много времени и нервов ушло на поддержку файлов, которые пишут все КТ аппараты. В итоге у нас появился ещё и инструмент сведения всех DICOM-файлов к единому стандарту и единому виду, что пригодится дальше для решения задач уже диагностики, если мы за них возьмёмся. И не только COVID-19.

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

ПО поставляется Оn-premise и включается в рабочий процесс клиники, работая с КТ-аппаратами и рабочими станциями врачей по протоколу DICOM, ставится на сервера клиники внутри защищённого контура, для работы нейросети нужен мощный GPU. Есть так же облачное решение, потому что не каждая региональная клиника может себе такое позволить. Есть особенности с передачей медицинских данных, нужно гарантированно обезличивать.

Почему производители томографов ничего не делали?

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

Где смотреть больше деталей

Вот здесь.

Ещё детали.

Подробнее..

Категории: Здоровье гика , Искусственный интеллект , Обработка изображений , Нейросеть , Здоровье , Диагностика , Блог компании сбер , Компьютерная томография , Кт

Релиз Apache Ignite 2.9.0 что нового?

13.11.2020 14:18:57 |

Автор: admin

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

Snapshots (Резервное копирование)
Трэйсинг
Новые возможности тонких клиентов
Режим работы кластера Только чтение
Запуск пользовательского кода в песочнице
Прозрачное шифрование данных: ротация мастер ключа
Инструменты для прерывания пользовательских задач и запросов
Кэширование на стороне платформы (.NET)
Подключение клиентских узлов к серверным через NAT

Snapshots (Резервное копирование)

В Ignite 2.9.0 появилась возможность создания резервной копии всех сохраняемых на диске кэшей (то есть кэшей, работающих в режиме Ignite Native Persistence) со всего кластера. Снапшоты могут создаваться онлайн, на активном кластере с пользовательской нагрузкой. При этом создается полностью консистентная копия всех данных кластера.

Запустить создание резервной копии можно одним из следующих способов:

с помощью command-line утилиты control.sh: control.sh --snapshot create <snapshot name>;
JMX операцией: MBean group="Snapshot", name=SnapshotMXBeanImpl, операция createSnapshot(<snapshot name>);
через Java API: Ignite.snapshot().createSnapshot("<snapshot name>").

Где <snapshot name> это уникальное имя снапшота.

После окончания формирования снапшота в директории work/snapshots/<snapshot name> (с настройками по умолчанию) каждого узла будет воссоздана структура файлового хранилища этого узла на момент старта снапшота. Сформированную файловую структуру можно использовать в дальнейшем для восстановления из резервной копии путем замены файлов с данными узла на файлы из директории снапшота.

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

Трэйсинг

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

В Ignite 2.9.0 трэйсинг охватывает следующие внутренние компоненты:

сообщения Discovery;
сообщения Communication;
процесс Exchange;
транзакции.

Чтобы посмотреть трэйсы, их необходимо экспортировать во внешнюю систему. Для этих целей Ignite использует библиотеку OpenCensus, которая из коробки предоставляет несколько экспортеров в различные системы (например, в Zipkin).

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

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

Новые возможности тонких клиентов

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

Была добавлена возможность использовать:

cluster API & cluster group API (в .NET и java):
- изменение режимов работы кластера;
- получение информации о кластере;
- фильтрация, группировка и получение информации об узлах кластера;
- выполнение различных операций над группами узлов;
compute API (в .NET и java):
- выполнение распределенных вычислений в кластере. В отличии от подобного функционала в толстом клиенте, который может использовать p2p class loader и сам автоматически загружать необходимые классы с клиента на серверные узлы, для запуска задачи тонким клиентом требуется чтобы весь исполняемый код уже был доступен в class-path серверных узлов (автоматическая загрузка классов с тонких клиентов не происходит);
Service Grid (пока только в java):
- вызов сервисов Ignite. Как и в случае с compute API, тонким клиентом не предоставляется функционал по загрузке классов и развертыванию сервисов, возможен только вызов уже развернутых в кластере сервисов.

Кроме этого тонкий клиент .NET получил функцию автоматического обнаружения узлов кластера (Automatic Server Node Discovery), которая включается совместно с функционалом осведомленность о партициях (partition awareness). При использовании осведомленности о партициях клиент устанавливает соединение не с одним серверным узлом, а сразу с несколькими, для того чтобы по возможности отправить запрос на узел, который является основным для данных в этом запросе. Автоматическое обнаружение узлов кластера при этом позволяет не перечислять в конфигурации клиента все адреса узлов кластера. Достаточно чтобы клиент мог подключиться хотя бы к одному живому узлу, используя перечисленные в конфигурации адреса. Адреса остальных узлов клиент получит уже из кластера.

Подробнее об использовании новых возможностей можно узнать в соответствующих подразделах документации тонкого клиента java и тонкого клиента .NET.

Режим работы кластера Только чтение

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

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

Запуск пользовательского кода в песочнице

Ignite может запускать пользовательский код (такой как compute-задачи, слушатели событий, различные фильтры) на серверных узлах. Такой код выполнялся с теми же правами что и системный код Ignite и ему был доступен весь java API без ограничений. Потенциально опасный код мог нарушить работоспособность кластера (например, удалить файлы данных Ignite, завершить работу JVM и т.д.).

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

Для функционирования Ignite Sandbox необходимо наличие двух установленных и включенных компонентов:

Java security manager. Отвечает за авторизацию субъектов при выполнении вызовов системных java-библиотек. По умолчанию отключен;
Ignite security processor. Отвечает за аутентификацию субъектов доступа. Из коробки с Ignite не поставляется, требуется самостоятельная реализация и подключение с помощью плагина.

С более подробной информацией об Ignite Sandbox вы можете ознакомиться в официальной документации.

Прозрачное шифрование данных: ротация мастер ключа

Прозрачное шифрование данных (TDE Transparent data encryption) функционал, позволяющий не хранить данные на диске в открытом виде. Шифрование данных на диске средствами СУБД требуется, например, для сертификации по стандарту безопасности данных PCI DSS. В Apache Ignite базовый функционал TDE (первая фаза) был реализован в версии 2.7. В текущей версии была реализована вторая фаза TDE ротация мастер-ключа (мастер-ключом зашифрованы хранящиеся на диске кэш-ключи). Третья фаза TDE (ротация кэш-ключей) будет реализована в следующем релизе.

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

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

В предыдущих версиях Ignite не было целостного механизма прерывания пользовательских задач и запросов администратором. У пользователей была возможность отмены своих задач и запросов. Для администраторов были доступны отдельные, никак друг с другом не коррелирующие, инструменты (например, можно было прервать транзакции списком, по фильтру, через JMX или утилиту control.sh, и убить SQL-запрос с помощью SQL-команды KILL QUERY). В текущем релизе у администратора появилась возможность прерывать

различные виды запросов (SQL, scan, continous),
транзакции,
сompute-задачи,
Ignite-сервисы,

используя унифицированный интерфейс.

Все эти виды задач и запросов могут быть прерваны любым из следующих способов:

утилитой control.sh;
через JMX;
SQL-командой.

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

Кэширование на стороне платформы (.NET)

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

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

Подключение клиентских узлов к серверным через NAT

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

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

Заключение

Выше перечислены наиболее значимые изменения в релизе Apache Ignite 2.9.0. Но список изменений не ограничивается только ими. Как обычно, мы исправили множество ошибок и внесли множество других полезных улучшений. Полный список изменений можно посмотреть в release notes.

Подробнее..

Категории: Open source , Java , Apache , Блог компании сбер , Apache ignite

Как увеличить скорость чтения из HBase до 3 раз и с HDFS до 5 раз

13.10.2020 02:20:47 |

Автор: admin

Высокая производительность одно из ключевых требований при работе с большими данными. Мы в управлении загрузки данных в Сбере занимаемся прокачкой практически всех транзакций в наше Облако Данных на базе Hadoop и поэтому имеем дело с действительно большими потоками информации. Естественно, что мы все время ищем способы повысить производительность, и теперь хотим рассказать, как удалось пропатчить RegionServer HBase и HDFS-клиент, благодаря чему удалось значительно увеличить скорость операции чтения.

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

Почему HDD и быстрые Random Access чтения несовместимы

Как известно, HBase, да и многие другие БД, хранят данные блоками, размером в несколько десятков килобайт. По умолчанию это порядка 64 Кб. Теперь представим себе, что нам нужно достать всего 100 байт и мы просим HBase выдать нам эти данные по некоему ключу. Так как размер блока в HFiles равен 64 Кб то запрошено будет в 640 раз больше (на минуточку!) чем нужно.

Далее, так как запрос пойдет через HDFS и его механизм кэширования метаданных ShortCircuitCache (который позволяет осуществлять прямой доступ к файлам), то это приводит к чтению уже 1 Мб с диска. Впрочем это можно регулировать параметром dfs.client.read.shortcircuit.buffer.size и во многих случаях имеет смысл уменьшать это значение, например до 126 Кб.

Допустим мы сделаем это, но кроме того, когда мы начнем читать данные через java api, таким функциями как FileChannel.read и просим операционную систему прочитать указанный объем данных, она вычитывает на всякий случай в 2 раза больше, т.е. в 256 Кб в нашем случае. Это происходит потому, что в java нет простой возможности выставить флаг FADV_RANDOM, предотвращающий такое поведение.

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

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

Тесты проводились на 100 файлах, каждый размером в 1 Гб и размещенных на 10 дисках HDD.

Давайте посчитаем, на что мы с такой скоростью можем в принципе рассчитывать:
Допустим мы читаем с 10 дисков со скоростью 280 МБ/сек, т.е. 3 миллиона раз по 100 байт. Но как мы помним, нужны нам данные встречаются в 2600 раз меньше, чем прочитано. Таким образом 3 млн. делим на 2600 и получаем 1100 записей в секунду.

Удручающе, не так ли? Такова природа Random Access доступа к данным на HDD вне зависимости от размера блока. Это физический предел случайного доступа и большего в таких условиях не сможет выжать ни одна БД.

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

Тут мы видим, что первые несколько минут скорость действительно порядка тысячи записей в секунду. Однако далее, благодаря тому, что вычитывается гораздо больше чем было запрошено, то данные оседают в buff/cache операционной системы (linux) и скорость растет до более приличных 60 тыс. в секунду

Таким образом далее мы будем разбираться с ускорением доступа только к тем данным, которые есть в кэше ОС или находятся в сравнимых по скорости доступа хранилищ типа SSD/NVMe.

В нашем случае мы будем проводить тесты на стенде из 4х серверов, каждый из которых заряжен следующим образом:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 threads.
Память: 730 Гб.
java version: 1.8.0_111

И тут собственно ключевой момент объем данных в таблицах, которые требуется вычитывать. Дело в том, что если читать данные из таблицы, которая целиком помещаются в кэш HBase, то до чтения из buff/cache операционки дело даже не дойдет. Потому что HBase по умолчанию выделяет 40% памяти под структуру которая называется BlockCache. По сути это ConcurrentHashMap, где ключ это имя файла+offset блока, а value собственно данные по этому смещению.

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

Например в нашем случае объем BlockCache на одном RS это порядка 12 Гб. Мы высадили два RS на одну ноду, т.е. под BlockCache выделено 96 Гб на всех нодах. А данных при этом во много раз больше, например пусть это будет 4 таблицы, по 130 регионов, в которых файлы размером по 800 Мб, пожатые FAST_DIFF, т.е. в сумме 410 Гб (это чистые данные, т.е. без учета фактора репликации).

Таким образом, BlockCache составляет лишь около 23% от общего объема данных и это гораздо ближе к реальным условиям того, что называется BigData. И вот тут начинается самое интересное ведь очевидно, чем меньше попаданий в кэш, тем хуже производительность. Ведь в случае промаха придется выполнить кучу работы т.е. спуститься до вызова системных функций. Однако этого не избежать и поэтому давайте рассмотрим совсем другой аспект а что происходит с данными внутри кэша?

Упростим ситуацию и допустим, что у нас есть кэш в который помещается только 1 объект. Вот пример того что произойдет при попытке работы с объемом данных в 3 раза больше чем кэш, нам придется:
1. Поместить блок 1 в кэш
2. Удалить блок 1 из кэша
3. Поместить блок 2 в кэш
4. Удалить блок 2 из кэша
5. Поместить блок 3 в кэш

Проделано 5 действий! Однако нормальной этой ситуацию называть никак нельзя, по сути мы заставляем HBase проделывать кучу совершенно бесполезной работы. Он постоянно вычитывает данные из кэша ОС, помещает его себе в BlockCache, для того чтобы почти тут же выкинуть его, потому что приехала новая порция данных. Анимация в начале поста показывает суть проблемы Garbage Collector зашкаливает, атмосфера греется, маленькая Грета в далекой и жаркой Швеции расстраивается. А мы айтишники очень не любим, когда грустят дети, поэтому начинаем думать, что с этим можно поделать.

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

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {        return;      }    }...

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

Например выставим cacheDataBlockPercent = 20 и посмотрим что будет:

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

Утилизация CPU при этом растет, однако сильно меньше чем производительность:

Тут еще стоит отметить, что блоки которые хранятся в BlockCache бывают разные. Большая часть, порядка 95% это собственно данные. А остальное это метаданных, типа Bloom фильтров или LEAF_INDEX и т.д.. Этих данных мало, но они очень полезные, так как прежде чем обратиться непосредственно к данным, HBase обращается к мете, чтобы понять нужно ли искать тут дальше и если да, то где именно находится интересующий его блок.

Поэтому в коде мы видим условие проверку buf.getBlockType().isData() и благодаря этому мету мы будем оставлять в кэше в любом случае.

Теперь давайте увеличим нагрузку и за одно слегка затюним фичу. В первом тесте мы сделали процент отсечения = 20 и BlockCache был немного недозагружен. Теперь поставим 23% и будем добавлять по 100 потоков каждые 5 минут, чтобы увидеть, в какой момент происходит насыщение:

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

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

Для управления этим было добавлено три параметра:

hbase.lru.cache.heavy.eviction.count.limit устанавливает, сколько раз должен запуститься процесс выселения данных из кеша, прежде чем мы начнем использовать оптимизацию (т.е. пропускать блоки). По умолчанию оно равно MAX_INT = 2147483647 и фактически означает, что фича никогда не начнет работать при таком значении. Потому что процесс выселения запускается каждые 5 10 секунд (это зависит от нагрузки) и 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 лет. Однако мы можем установить этот параметр равным 0 и заставить фичу работать сразу же после старта.

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

Например мы знаем, что краткосрочные чтения длятся обычно около 1 минуты. На не надо начинать выкидывать блоки, кеш не успеет устареть и тогда мы можем установить этот параметр равным например 10. Это приведет к тому, что оптимизация начнет работать только когда началось длительное активное чтение, т.е. через 100 секунд. Таким образом если мы имеем краткосрочное чтение, то все блоки попадут в кеш и будут доступны (за исключением тех что будут выселены стандартным алгоритмом). А когда мы делаем долгосрочные чтения, фича включается и бы имеем намного более высокую производительность.

hbase.lru.cache.heavy.eviction.mb.size.limit устанавливает, как много мегабайт нам хотелось бы помещать в кеш (и естественно выселять) за 10 секунд. Фича будет пытаться достигнуть этого значения и поддерживать его. Смысл в следующем, если мы пихаем в кеш гигабайты, то и выселять придется гигабайты, а это, как мы видели выше, весьма накладно. Однако не нужно пытаться выставить его слишком маленьким, так как это приведет к преждевременному выходу из режима пропуска блоков. Для мощных серверов (порядка 20-40 физических ядер) оптимально выставлять около 300-400 МБ. Для среднего класса (~10 ядер) 200-300 МБ. Для слабых систем (2-5 ядра) может быть нормально 50-100 МБ (на таких не тестировалось).

Рассмотрим, как это работает: допустим мы выставили hbase.lru.cache.heavy.eviction.mb.size.limit = 500, идет какая-то нагрузка (чтения) и тогда каждые ~10 секунд мы вычисляем, сколько байт было выселено по формуле:

Overhead = Freed Bytes Sum (MB) * 100 / Limit (MB) 100;

Если по факту было выселено 2000 MB, то Overhead получается равным:

2000 * 100 / 500 100 = 300%

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

Однако если нагрузка упала, допустим выселено всего 200 МБ и Overhead стал отрицательным (так называемый overshooting):

200 * 100 / 500 100 = -60%

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

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

hbase.lru.cache.heavy.eviction.overhead.coefficient устанавливает, как быстро мы хотели бы получить результат. Если мы твердо знаем, что наши чтения в основном длительные и не хотим ждать, мы можем увеличить этот коэффициент и получить высокую производительность быстрее.

Например, мы установили этот коэффициент = 0.01. Это означает что Overhead (см. выше) будет умножен на это число на на полученный результат и будет уменьшен процент кешируемых блоков. Допустим, что Overhead = 300%, а коэффициент = 0.01, то процент кешируемых блоков будет уменьшен на 3%.

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

Код реализации

        LruBlockCache cache = this.cache.get();        if (cache == null) {          break;        }        freedSumMb += cache.evict()/1024/1024;        /*        * Sometimes we are reading more data than can fit into BlockCache        * and it is the cause a high rate of evictions.        * This in turn leads to heavy Garbage Collector works.        * So a lot of blocks put into BlockCache but never read,        * but spending a lot of CPU resources.        * Here we will analyze how many bytes were freed and decide        * decide whether the time has come to reduce amount of caching blocks.        * It help avoid put too many blocks into BlockCache        * when evict() works very active and save CPU for other jobs.        * More delails: https://issues.apache.org/jira/browse/HBASE-23887        */        // First of all we have to control how much time        // has passed since previuos evict() was launched        // This is should be almost the same time (+/- 10s)        // because we get comparable volumes of freed bytes each time.        // 10s because this is default period to run evict() (see above this.wait)        long stopTime = System.currentTimeMillis();        if ((stopTime - startTime) > 1000 * 10 - 1) {          // Here we have to calc what situation we have got.          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"          // and can calculte overhead on it.          // We will use this information to decide,          // how to change percent of caching blocks.          freedDataOverheadPercent =            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {            // Now we are in the situation when we are above the limit            // But maybe we are going to ignore it because it will end quite soon            heavyEvictionCount++;            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {              // It is going for a long time and we have to reduce of caching              // blocks now. So we calculate here how many blocks we want to skip.              // It depends on:             // 1. Overhead - if overhead is big we could more aggressive              // reducing amount of caching blocks.              // 2. How fast we want to get the result. If we know that our              // heavy reading for a long time, we don't want to wait and can              // increase the coefficient and get good performance quite soon.              // But if we don't sure we can do it slowly and it could prevent              // premature exit from this mode. So, when the coefficient is              // higher we can get better performance when heavy reading is stable.              // But when reading is changing we can adjust to it and set              // the coefficient to lower value.              int change =                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);              // But practice shows that 15% of reducing is quite enough.              // We are not greedy (it could lead to premature exit).              change = Math.min(15, change);              change = Math.max(0, change); // I think it will never happen but check for sure              // So this is the key point, here we are reducing % of caching blocks              cache.cacheDataBlockPercent -= change;              // If we go down too deep we have to stop here, 1% any way should be.              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);            }          } else {            // Well, we have got overshooting.            // Mayby it is just short-term fluctuation and we can stay in this mode.            // It help avoid permature exit during short-term fluctuation.            // If overshooting less than 90%, we will try to increase the percent of            // caching blocks and hope it is enough.            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {              // Simple logic: more overshooting - more caching blocks (backpressure)              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);              cache.cacheDataBlockPercent += change;              // But it can't be more then 100%, so check it.              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);            } else {              // Looks like heavy reading is over.              // Just exit form this mode.              heavyEvictionCount = 0;              cache.cacheDataBlockPercent = 100;            }          }          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +            "heavy eviction counter: {}, " +            "current caching DataBlock (%): {}",            freedSumMb, freedDataOverheadPercent,            heavyEvictionCount, cache.cacheDataBlockPercent);          freedSumMb = 0;          startTime = stopTime;       }

Рассмотрим теперь все это на реальном примере. Имеем следующий тестовый сценарий:

1. Начинаем делать Scan (25 threads, batch = 100)

2. Через 5 минут добавляем multi-gets (25 threads, batch = 100)

3. Через 5 минут выключаем multi-gets (остается опять только scan)

Делаем два прогона, сначала hbase.lru.cache.heavy.eviction.count.limit = 10000 (что фактически выключает фичу), а затем ставим limit = 0 (включает).

В логах ниже мы видим, как включается фича, сбрасывает Overshooting до 14-71%. Время от времени нагрузка снижается, что включает Backpressure и HBase вновь кеширует больше блоков.

Лог RegionServer

evicted (MB): 0, ratio 0.0, overhead (%): -100, heavy eviction counter: 0, current caching DataBlock (%): 100
evicted (MB): 0, ratio 0.0, overhead (%): -100, heavy eviction counter: 0, current caching DataBlock (%): 100
evicted (MB): 2170, ratio 1.09, overhead (%): 985, heavy eviction counter: 1, current caching DataBlock (%): 91 < start
evicted (MB): 3763, ratio 1.08, overhead (%): 1781, heavy eviction counter: 2, current caching DataBlock (%): 76
evicted (MB): 3306, ratio 1.07, overhead (%): 1553, heavy eviction counter: 3, current caching DataBlock (%): 61
evicted (MB): 2508, ratio 1.06, overhead (%): 1154, heavy eviction counter: 4, current caching DataBlock (%): 50
evicted (MB): 1824, ratio 1.04, overhead (%): 812, heavy eviction counter: 5, current caching DataBlock (%): 42
evicted (MB): 1482, ratio 1.03, overhead (%): 641, heavy eviction counter: 6, current caching DataBlock (%): 36
evicted (MB): 1140, ratio 1.01, overhead (%): 470, heavy eviction counter: 7, current caching DataBlock (%): 32
evicted (MB): 913, ratio 1.0, overhead (%): 356, heavy eviction counter: 8, current caching DataBlock (%): 29
evicted (MB): 912, ratio 0.89, overhead (%): 356, heavy eviction counter: 9, current caching DataBlock (%): 26
evicted (MB): 684, ratio 0.76, overhead (%): 242, heavy eviction counter: 10, current caching DataBlock (%): 24
evicted (MB): 684, ratio 0.61, overhead (%): 242, heavy eviction counter: 11, current caching DataBlock (%): 22
evicted (MB): 456, ratio 0.51, overhead (%): 128, heavy eviction counter: 12, current caching DataBlock (%): 21
evicted (MB): 456, ratio 0.42, overhead (%): 128, heavy eviction counter: 13, current caching DataBlock (%): 20
evicted (MB): 456, ratio 0.33, overhead (%): 128, heavy eviction counter: 14, current caching DataBlock (%): 19
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 15, current caching DataBlock (%): 19
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 16, current caching DataBlock (%): 19
evicted (MB): 342, ratio 0.31, overhead (%): 71, heavy eviction counter: 17, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.3, overhead (%): 14, heavy eviction counter: 18, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.29, overhead (%): 14, heavy eviction counter: 19, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.27, overhead (%): 14, heavy eviction counter: 20, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.25, overhead (%): 14, heavy eviction counter: 21, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.24, overhead (%): 14, heavy eviction counter: 22, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.22, overhead (%): 14, heavy eviction counter: 23, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.21, overhead (%): 14, heavy eviction counter: 24, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.2, overhead (%): 14, heavy eviction counter: 25, current caching DataBlock (%): 19
evicted (MB): 228, ratio 0.17, overhead (%): 14, heavy eviction counter: 26, current caching DataBlock (%): 19
evicted (MB): 456, ratio 0.17, overhead (%): 128, heavy eviction counter: 27, current caching DataBlock (%): 18 < added gets (but table the same)
evicted (MB): 456, ratio 0.15, overhead (%): 128, heavy eviction counter: 28, current caching DataBlock (%): 17
evicted (MB): 342, ratio 0.13, overhead (%): 71, heavy eviction counter: 29, current caching DataBlock (%): 17
evicted (MB): 342, ratio 0.11, overhead (%): 71, heavy eviction counter: 30, current caching DataBlock (%): 17
evicted (MB): 342, ratio 0.09, overhead (%): 71, heavy eviction counter: 31, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.08, overhead (%): 14, heavy eviction counter: 32, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.07, overhead (%): 14, heavy eviction counter: 33, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.06, overhead (%): 14, heavy eviction counter: 34, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.05, overhead (%): 14, heavy eviction counter: 35, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.05, overhead (%): 14, heavy eviction counter: 36, current caching DataBlock (%): 17
evicted (MB): 228, ratio 0.04, overhead (%): 14, heavy eviction counter: 37, current caching DataBlock (%): 17
evicted (MB): 109, ratio 0.04, overhead (%): -46, heavy eviction counter: 37, current caching DataBlock (%): 22 < back pressure
evicted (MB): 798, ratio 0.24, overhead (%): 299, heavy eviction counter: 38, current caching DataBlock (%): 20
evicted (MB): 798, ratio 0.29, overhead (%): 299, heavy eviction counter: 39, current caching DataBlock (%): 18
evicted (MB): 570, ratio 0.27, overhead (%): 185, heavy eviction counter: 40, current caching DataBlock (%): 17
evicted (MB): 456, ratio 0.22, overhead (%): 128, heavy eviction counter: 41, current caching DataBlock (%): 16
evicted (MB): 342, ratio 0.16, overhead (%): 71, heavy eviction counter: 42, current caching DataBlock (%): 16
evicted (MB): 342, ratio 0.11, overhead (%): 71, heavy eviction counter: 43, current caching DataBlock (%): 16
evicted (MB): 228, ratio 0.09, overhead (%): 14, heavy eviction counter: 44, current caching DataBlock (%): 16
evicted (MB): 228, ratio 0.07, overhead (%): 14, heavy eviction counter: 45, current caching DataBlock (%): 16
evicted (MB): 228, ratio 0.05, overhead (%): 14, heavy eviction counter: 46, current caching DataBlock (%): 16
evicted (MB): 222, ratio 0.04, overhead (%): 11, heavy eviction counter: 47, current caching DataBlock (%): 16
evicted (MB): 104, ratio 0.03, overhead (%): -48, heavy eviction counter: 47, current caching DataBlock (%): 21 < interrupt gets
evicted (MB): 684, ratio 0.2, overhead (%): 242, heavy eviction counter: 48, current caching DataBlock (%): 19
evicted (MB): 570, ratio 0.23, overhead (%): 185, heavy eviction counter: 49, current caching DataBlock (%): 18
evicted (MB): 342, ratio 0.22, overhead (%): 71, heavy eviction counter: 50, current caching DataBlock (%): 18
evicted (MB): 228, ratio 0.21, overhead (%): 14, heavy eviction counter: 51, current caching DataBlock (%): 18
evicted (MB): 228, ratio 0.2, overhead (%): 14, heavy eviction counter: 52, current caching DataBlock (%): 18
evicted (MB): 228, ratio 0.18, overhead (%): 14, heavy eviction counter: 53, current caching DataBlock (%): 18
evicted (MB): 228, ratio 0.16, overhead (%): 14, heavy eviction counter: 54, current caching DataBlock (%): 18
evicted (MB): 228, ratio 0.14, overhead (%): 14, heavy eviction counter: 55, current caching DataBlock (%): 18
evicted (MB): 112, ratio 0.14, overhead (%): -44, heavy eviction counter: 55, current caching DataBlock (%): 23 < back pressure
evicted (MB): 456, ratio 0.26, overhead (%): 128, heavy eviction counter: 56, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.31, overhead (%): 71, heavy eviction counter: 57, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 58, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 59, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 60, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 61, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 62, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 63, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 64, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 65, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 66, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 67, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 68, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 69, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.32, overhead (%): 71, heavy eviction counter: 70, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 71, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 72, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 73, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 74, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 75, current caching DataBlock (%): 22
evicted (MB): 342, ratio 0.33, overhead (%): 71, heavy eviction counter: 76, current caching DataBlock (%): 22
evicted (MB): 21, ratio 0.33, overhead (%): -90, heavy eviction counter: 76, current caching DataBlock (%): 32
evicted (MB): 0, ratio 0.0, overhead (%): -100, heavy eviction counter: 0, current caching DataBlock (%): 100
evicted (MB): 0, ratio 0.0, overhead (%): -100, heavy eviction counter: 0, current caching DataBlock (%): 100

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

Ну и наконец как выглядит работа параметров в виде графика. Для сравнения кеш был совсем выключен в начале, затем был запуск HBase с кешированием и отсрочкой начала работы оптимизации на 5 минут (30 циклов выселения)

Полный код можно найти в Pull Request HBASE 23887 на github.

Однако 300 тыс. чтений в секунду это не все, что можно выжать на данном железе в этих условиях. Дело в том, что когда нужно обратиться к данным через HDFS, то используется механизм ShortCircuitCache (далее SSC), который позволяет получить доступ к данным напрямую, избегая сетевых взаимодействий.

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

Осознав это мы поняли, что проблему можно обойти, если создать массив независимых SSC:

private final ShortCircuitCache[] shortCircuitCache;...shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];for (int i = 0; i < this.clientShortCircuitNum; i++)  this.shortCircuitCache[i] = new ShortCircuitCache();

И далее работать с ними, исключая пересечения так же по последней цифре оффсета:

public ShortCircuitCache getShortCircuitCache(long idx) {    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];}

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

conf.set("dfs.client.read.shortcircuit", "true");conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждамconf.set("dfs.client.short.circuit.num", num); // от 1 до 10

И просто читаем файлы:

FSDataInputStream in = fileSystem.open(path);for (int i = 0; i < count; i++) {    position += 65536;    if (position > 900000000)        position = 0L;    int res = in.read(position, byteBuffer, 0, 65536);}

Этот код выполняется в отдельных потоках и мы будем наращивать количество одновременно читаемых файлов (от 10 до 200 горизонтальная ось) и количество кэшей (от 1 до 10 графики). Вертикальная оси показывает ускорение которое дает увеличение SSC относительно случая когда кеш только один.

Как читать график: время выполнения 100 тысяч чтений блоками по 64 КБ с одним кэшом требует 78 секунд. Тогда как с 5 кэшами это выполняется за 16 секунд. Т.е. имеет место ускорение ~5 раз. Как видно из графика, на маленьком числе параллельных чтений эффект не очень заметный, это начинает играть заметную роль когда чтения потоков больше 50. Также заметно, что увеличение количества SSC от 6 и выше дает существенно меньше прироста производительности.

Примечание 1: так как результаты тестирования достаточно волатильны (см. ниже), было осуществлено 3 запуска и полученные значения были усреднены.
Примечание 2: Прирост производительности от настройки для случайного доступа такой же, хотя сам доступ чуть медленнее.

Однако необходимо уточнить, что в отличие от случая с HBase это ускорение не всегда бесплатное. Тут мы больше разблокируем возможности CPU делать работу, вместо того чтобы отвисать на локах.

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

Например присмотримся внимательнее к настройке SSC = 3. Рост производительности на диапазоне составляет около 3.3 раз. Ниже результаты всех трех отдельных запусков.

Тогда как потребление CPU растет примерно в 2.8 раз. Разница не очень большая, но маленькой Грете уже радость.

Таким образом это будет иметь позитивный эффект для любого инструмента использующего массовый доступ к HDFS (например Spark и т.д.), при условии что прикладной код легкий (т.е. затык именно на стороне клиента HDFS) и есть свободные мощности CPU. Для проверки давайте протестируем какой эффект даст совместное применение оптимизации BlockCache и тюнинга SSC для чтения из HBase.

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

Так же по этой оптимизации был сделан PR [HDFS-15202], который был вмержен и данный функционал будет доступен в следующих релизах.

Ну и наконец было интересно сравнить производительность чтения подобной wide-column БД Cassandra и HBase.

Для этого запускались экземпляры стандартной утилиты нагрузочного тестирования YCSB с двух хостов (800 threads суммарно). На серверной стороне по 4 экземпляра RegionServer и Cassandra на 4 хостах (не тех, где запущены клиенты, чтобы избежать их влияния). Чтения шли из таблиц размером:

HBase 300 GB on HDFS (100 GB чистых данных)

Cassandra 250 GB (replication factor = 3)

Т.е. объем был примерно одинаковый (в HBase немножко больше).

Параметры HBase:

dfs.client.short.circuit.num = 5 (оптимизация клиента HDFS)

hbase.lru.cache.heavy.eviction.count.limit = 30 это означает то патч начнет работать через 30 выселений (~5 минут)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 целевой объем кеширования и выселения

Логи YCSB были распарсены и сведены в графики Excel:

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

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

Подробнее..

Категории: Высокая производительность , Оптимизация , Big data , Хранилища данных , Hadoop , Hdfs , Блог компании сбер , Hbase , Hadoop 3.0

Сбер выложил русскоязычную модель GPT-3 Large с 760 миллионами параметров в открытый доступ

22.10.2020 10:15:06 |

Автор: admin

Последнее десятилетие в области компьютерных технологий ознаменовалось началом новой весны искусственного интеллекта. Впрочем, ситуацию в индустрии в наши дни можно, наверное, охарактеризовать уже не как весну, а полноценное лето ИИ. Судите сами, за последние неполные 10 лет только в области обработки естественного языка (Natural language processing, NLP) произошли уже две настоящие технологические революции. Появившаяся в результате второй из них модель GPT-3 произвела настоящий фурор не только в технологических медиа, но стала знаменитой далеко за пределами научного сообщества. Например, GPT-3 написала для издания The Guardian эссе о том, почему ИИ не угрожает людям. GPT-3 сочиняет стихи и прозу, выполняет переводы, ведёт диалоги, даёт ответы на вопросы, хотя никогда специально не училась выполнять эти задачи. До недавних пор все возможности GPT-3 могли по достоинству оценить лишь англоязычные пользователи. Мы в Сбере решили исправить эту досадную оплошность. И сейчас расскажем вам, что из этого получилось.

Источник изображения

Две революции в обработке естественного языка

Первая революция в NLP была связана с успехами моделей, основанных на векторных представлениях семантики языка, получаемых при помощи методов обучения без учителя (Unsupervised learning). Расцвет этих моделей начался с публикации результатов Томаша Миколова (Tom Mikolov), аспиранта Йошуа Бенджио (Yoshua Bengio) (одного из отцов-основателей современного глубокого обучения, лауреата Премии Тьюринга), и появления популярного инструмента word2vec. Вторая же революция началась с развития механизмов внимания в рекуррентных нейронных сетях, вылившаяся в понимание того, что механизм внимания самодостаточен и вполне может быть использован и без самой рекуррентной сети. Появившаяся в результате нейросетевая модель получила название трансформер [transformer]. Она была представлена научному сообществу в 2017 году в статье с программным названием Внимание это всё, что вам нужно [Attention Is All You Need], написанной группой исследователей из Google Brain и Google Research. Быстрое развитие сетей, основанных на трансформерах, привело к появлению гигантских языковых моделей, подобных Generative Pre-trained Transformer 3 (GPT-3) от OpenAI, способных эффективно решать множество задач из области NLP.

Для обучения гигантских трансформерных моделей нужны значительные вычислительные ресурсы. У вас не получится просто взять современную видеокарту и обучить такую модель на своём домашнем компьютере. В оригинальной публикации OpenAI представлено 8 вариантов модели, и если взять самую маленькую из них (GPT-3 Small) со 125 миллионами параметров и попытаться обучить её при помощи профессиональной видеокарты NVidia V100, оснащённой мощными тензорными ядрами, то на это уйдёт примерно полгода. Если же взять самый большой вариант модели со 175 млрд параметров, то результата придётся дожидаться почти 500 лет. Стоимость обучения самого большого варианта модели по тарифам облачных сервисов, предоставляющих современные вычислительные устройства в аренду, переваливает за миллиард рублей (и это ещё при условии линейного масштабирования производительности с увеличением числа задействованных процессоров, что в принципе недостижимо).

Да здравствуют суперкомпьютеры!

Понятно, что подобные эксперименты доступны только компаниям, обладающим значительными вычислительными ресурсами. Именно для решения подобных задач в 2019 году Сбер ввёл в эксплуатацию суперкомпьютер Кристофари, занявший первое место по производительности в числе имеющихся в нашей стране суперкомпьютеров. 75 вычислительных узлов DGX-2 (в каждом по 16 карт NVidia V100), связанных сверхбыстрой шиной на базе технологии Infiniband, позволяют обучить GPT-3 Small всего за несколько часов. Однако и для такой машины задача обучения более крупных вариантов модели не является тривиальной. Во-первых, часть машины занята обучением других моделей, предназначенных для решения задач в области компьютерного зрения, распознавания и синтеза речи и множестве других областей, интересующих различные компании из экосистемы Сбера. Во-вторых, сам процесс обучения, использующий одновременно множество вычислительных узлов в ситуации, когда веса модели не помещаются в памяти одной карты, является весьма нестандартным.

В общем, мы оказались в ситуации, когда для наших целей не годился привычный многим torch.distributed. Вариантов у нас было не так уж и много, в итоге мы обратились к родной для NVidia реализации Megatron-LM и новому детищу Microsoft DeepSpeed, что потребовало создания на Кристофари кастомных докерных контейнеров, с чем нам оперативно помогли коллеги из SberCloud. DeepSpeed, в первую очередь, дал нам удобные инструменты для model parallel тренировки, то есть разнесения одной модели на несколько GPU и для шардирования оптимизатора между GPU. Это позволяет использовать более крупные батчи, а также без горы дополнительного кода обучать модели с более чем 1,5 миллиардами весов.

Удивительным образом технологии за последние полвека в своём развитии описали очередной виток спирали похоже, эпоха мейнфреймов (мощных компьютеров с терминальным доступом) возвращается. Мы уже привыкли, что основным инструментов разработки является персональный компьютер, выделенный в монопольное пользование разработчику. В конце 1960-х начале 1970-х годов час работы мейнфрейма стоил примерно столько же, сколько составляла заработная плата оператора ЭВМ за целый месяц! Казалось, что эти времена ушли навсегда и железо стало навсегда дешевле рабочего времени. Однако, похоже, железо совершило впечатляющий камбэк [comeback]. Будни современного специалиста в области машинного обучения вновь напоминают будни Саши Привалова из повести братьев Стругацких Понедельник начинается в субботу, с той лишь разницей, что место Алдана в нашем случае занимает Кристофари, а роль магии и чародейства выполняют методы глубокого обучения [deep learning].

Из опыта SberDevices

Нам много раз приходилось в прошлом учить другие модели на основе трансформеров это и различные наследники BERT'а, и модели кодировщик (энкодер) декодер [encoder decoder], подобные T5 от Google. Виртуальные ассистенты, созданные SberDevices для различных поверхностей, начиная новейшими SberBox и SberPortal и заканчивая привычным всем приложением Сбербанк Онлайн, используют в своей работе несколько подобных моделей для решения различных задач в ходе общения с пользователем. Например, виртуальный ассистент Джой использует в режиме болталки модель GPT-2 Medium, обученную на большом корпусе русской литературы, доученную на специальном диалоговом датасете и снабжённую особым механизмом ранжирования, предназначенным для выбора наиболее интересных ответов. Такие модели способны вести с пользователем беседу, не выбирая реплики из заранее заготовленной библиотеки ответов, а изготавливая свои фразы на лету, что делает общение с ними более разнообразным и занимательным.

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

Словом, наш опыт в обучении больших трансформерных моделей пришёлся как нельзя кстати, когда руководство Сбера приняло решение о выделении вычислительных ресурсов под исследовательский проект по обучению GPT-3. Такой проект потребовал объединения усилий сразу нескольких подразделений. Со стороны SberDevices лидерскую роль в этом процессе взяло на себя Управление экспериментальных систем машинного обучения (при этом в работе участвовал также ряд экспертов из других команд), а со стороны Sberbank.AI команда AGI NLP. В проект также активно включились наши коллеги из SberCloud, занимающиеся сопровождением Кристофари.

Совместно с коллегами из команды AGI NLP нам удалось собрать первую версию русскоязычного обучающего корпуса суммарным объёмом свыше 600 Гб. В него вошла огромная коллекция русской литературы, снапшоты русской и английской Википедии, коллекция снапшотов новостных и вопрос-ответных сайтов, публичные разделы Pikabu, полная коллекция материалов научно-популярного портала 22century.ru и банковского портала banki.ru, а также корпус Omnia Russica. Кроме того, поскольку мы хотели поэкспериментировать с возможностью обработки программного кода, мы включили в обучающий корпус снапшоты github и StackOverflow. Команда AGI NLP провела большую работу по чистке и дедупликации данных, а также по подготовке наборов для валидации и тестирования моделей. Если в оригинальном корпусе, использованном OpenAI, соотношение английского и других языков составляет 93:7, то в нашем случае соотношение русского и других языков составляет примерно 9:1.

В качестве основы для первых экспериментов мы выбрали архитектуры GPT-3 Medium (350 миллионов параметров) и GPT-3 Large (760 миллионов параметров). При этом мы обучали модели как с чередованием блоков трансформера с разреженным [sparse] и полным [dense] механизмами внимания, так и модели, в которых все блоки внимания были полными. Дело в том, что в оригинальной работе от OpenAI говорится о чередовании блоков, но не приводится их конкретная последовательность. Если все блоки внимания в модели будут полными, это увеличивает вычислительные затраты на обучение, но гарантирует, что предсказательный потенциал модели будет использован в полной мере. В настоящее время в научном сообществе ведётся активное изучение различных моделей внимания, предназначенных для снижения вычислительных затрат при обучении моделей и увеличения точности. За короткое время исследователями были предложены лонгформер [longformer], реформер [reformer], трансформер с адаптивным диапазоном внимания [adaptive attention span], сжимающий трансформер [compressive transformer], поблочный трансформер [blockwise transformer], BigBird, трансформер с линейной сложностью [linformer] и ряд других аналогичных моделей. Мы также занимаемся исследованиями в этой области, при этом модели, составленные из одних только dense-блоков, являются своеобразным бенчмарком, позволяющим оценить степень снижения точности различных ускоренных вариантов модели.

Конкурс AI 4 Humanities: ruGPT-3

В этом году в рамках AI Journey команда Sberbank.AI организовала конкурс AI 4 Humanities: ruGPT-3. В рамках общего зачета участникам предлагается представить прототипы решений для любой бизнес- или социальной задачи, созданных с помощью предобученной модели ruGPT-3. Участникам специальной номинации AIJ Junior предлагается на базе ruGPT-3 создать решение по генерации осмысленного эссе по четырем гуманитарным предметам (русский язык, история, литература, обществознание) уровня 11 класса (ЕГЭ) по заданной теме/тексту задания.

Специально для этих соревнований мы обучили три версии модели GPT-3: 1) GPT-3 Medium, 2) GPT-3 Large с чередованием sparse и dense-блоков трансформера, 3) наиболее мощную GPT-3 Large, составленную из одних только dense-блоков. Обучающие датасеты и токенизаторы у всех моделей идентичны использовался BBPE-токенизатор и наш кастомный датасет Large1 объёмом 600 Гб (его состав приведён в тексте выше).

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

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

Как модели, подобные GPT-3, изменят наш мир?

Важно понимать, что модели типа GPT-1/2/3, на самом деле, решают ровно одну задачу они пытаются предсказать следующий токен (обычно слово или его часть) в последовательности по предшествующим. Такой подход позволяет использовать для обучения неразмеченные данные, то есть обойтись без привлечения учителя, а с другой стороны позволяет решать довольно широкий спектр задач из области NLP. Ведь в тексте диалога, например, реплика-ответ является продолжением истории общения, в художественном произведении текст каждого абзаца продолжает предшествующий текст, а в сессии вопросов и ответов текст ответа следует за текстом вопроса. Модели большой ёмкости в результате могут решать многие такие задачи без специального дообучения им достаточно тех примеров, которые укладываются в контекст модели, который у GPT-3 довольно внушительный целых 2048 токенов.

GPT-3 способна не только генерировать тексты (в том числе стихи, шутки и литературные пародии), но и исправлять грамматические ошибки, вести диалоги и даже (ВНЕЗАПНО!) писать более-менее осмысленный программный код. Множество интересных применений GPT-3 можно найти на сайте независимого исследователя Гверна Бренуэна (Gwern Branwen). Бренуэн, развивая идею, высказанную в шуточном твите Андрея Карпатого (Andrej Karpathy), задаётся интересным вопросом: не являемся ли мы свидетелями появления новой парадигмы программирования?

Вот текст исходного твита Карпатого:

Мне нравится идея Программного обеспечения 3.0. Программирование переходит от подготовки датасетов к подготовке запросов, позволяющих системе метаобучения понять суть задачи, которую она должна выполнить. ЛОЛ [Love the idea for Software 3.0. Programming moving from curating datasets to curating prompts to make the meta learner get the task it's supposed to be doing. LOL].

Развивая идею Карпатого, Бренуэн пишет:

Нейронная сеть GPT-3 настолько огромна с точки зрения мощности и набора [использованных для обучения] данных, что демонстрирует качественно иное поведение: вы не применяете её к фиксированному набору задач, представленных в обучающем датасете, что требует повторного обучения модели на дополнительных данных, если вы хотите решить новую задачу (именно так надо переучивать GPT-2); вместо этого вы взаимодействуете с моделью, выражая любую задачу в виде описаний, запросов и примеров на естественном языке, подстраивая текст затравки [prompt], подаваемой на вход модели, до тех пор, пока она не поймёт и не научится на мета-уровне решать новую задачу, основываясь на высокоуровневых абстракциях, которые она выучила во время предобучения. Это принципиально новый способ использования модели глубокого обучения, и его лучше рассматривать как новый вид программирования, где затравка теперь является программой, которая программирует GPT-3 для выполнения новых задач. Затравочное программирование похоже не столько на обычное программирование, сколько на попытку научить суперинтеллектуального кота освоить новый трюк: вы можете попросить его выполнить трюк, и иногда он выполняет его идеально, что делает ещё более неприятной ситуацию, когда в ответ на запрос он сворачивается, чтобы вылизать свою задницу, при этом вы будете понимать, что проблема не в том, что он не может, а в том, что он не хочет.

Поскольку наша модель в процессе обучения видела github и StackOverflow, она вполне способна писать код (иногда не лишённый весьма глубокого смысла):

Что дальше

В этом году мы продолжим работы над гигантскими трансформерными моделями. Дальнейшие планы связаны с дальнейшим расширением и очисткой датасетов (в них, в частности, войдут снапшоты сервиса препринтов научных публикаций arxiv.org и библиотеки научных исследований PubMed Central, специализированные диалоговые датасеты и датасеты по символьной логике), увеличением размера обучаемых моделей, а также использованием улучшенного токенизатора.

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

Подробнее..

Категории: Искусственный интеллект , Машинное обучение , Natural language processing , Нейронные сети , Gpt-3 , Gpt-2 , Блог компании sberdevices , Блог компании сбер , Трансформеры , Генеративные модели , Aijourney

Тестируем ruGPT-3 на новых задачах

20.11.2020 14:23:38 |

Автор: admin

Как дообучить модель на новой задаче?

Модели и код к ним находятся в репозитории sberbank-ai: можно использовать библиотку transformers или Megatron-LM.

В этой статье я привожу примеры с использованием huggingface/transformers код для кейсов приведены здесь:

Fine-Tuning моделей Colab-ноутбук
Просто генерация Colab-ноутбук

Карточки моделей в библиотеке transformers: Large Medium Small

При запуске скрипта генерации проще сделать Run all и затем немного подождать, пока модель загрузится.

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

ruGPT-3 Small: Бразильские ученые открыли редкий вид
карликовых единорогов, обитающих на западе Ютландии. Об этом
сообщает Agence France-Presse. Единорог, получивший название
Pygmaliona (лат. Pygmaliona pygmalioni), был обнаружен
исследователями в ходе работ в области биологии. Его длина
составляет менее 30 сантиметров, а масса около 1 килограмма.
Животное относится к семейству единороговых. В его рационе
преобладают растения, в том числе и карликовые
деревья.

В Colab-ноутбук помещается только ruGPT-3 Small, поэтому лучше используйте карточки с памятью больше 14Gb.

Кстати, на время соревнования мы даем участникам дорожки доступ к мощностям Christofari!
Для участников трека ruGPT-3 мы выделили 100 аккаунтов в каждом аккаунте 1 GPU Tesla V100-SXM3 32 Gb бесплатно на время соревнования.
Как получить аккаунт?
1) Зарегистрируйтесь на трек ruGPT-3 (AI 4 Humanities) ods.ai/tracks/aij2020
2) Напишите короткое письмо с названием вашей команды и задачей на AIJ_ruGPT-3@sberbank.ru

Few-Shot vs Fine Tuning

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

Первый способ: назовем его традиционный дообучить модель на доступном количестве примеров выполнять конкретное задание. В таком случае генеративная модель выучит формат ввода и вывода (GPT-3 очень редко ошибается в формате), и будет генерировать данные согласно вашей задаче. Это может быть разметка данных (в формате исходный текст текст в разметке) или просто генерация по заданному началу.
Второй способ: новый, называемый обычно затравочное программирование (англ. prompt engineering с легкой руки [Гверна Бренуэна] (http://personeltest.ru/aways/www.gwern.net/GPT-3#prompts-as-programming) мы даже ничего не дообучаем, а сразу пытаемся получить из модели то, что хотим.

Как работает затравочное программирование?

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

Пример затравки с 1 примером и описание задачи.

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

Генерация отзывов

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

Затравка: Напиши комментарий под видео.

Опять какой-то челлендж

ruGPT-3 Large: Напиши комментарий под видео.

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

Затравка: Напиши отзыв о стиральной машине.

Данная модель стиральной машины

ruGPT-3 Large: Напиши отзыв о стиральной машине.

Данная модель стиральной машины оснащена встроенной функцией
самоочистки.

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

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

Завтравка: Напиши отзыв о фильме.

Фильм "1+1"

ruGPT-3 Large: Напиши отзыв о фильме.

Фильм "1+1" очень нравится, хотя и смотреть его стоит не каждому.
Актёрский состав в нём великолепен. Смотрится без особого
напряжения и с интересом. В фильме очень много смешных моментов.
Так же советую посмотреть фильм "Зелёная книга", также фильм с
Дженнифер Лопес и Крисом де Бургом.

Как видим, для тематик, широко распространенных в интернете, модель может генерировать связные тексты и без обучения. Но где же без дообучения все же никак?
Таких случая можно выделить 3:
сложный формат данных если при генерации без обучения вы теряете качество за счет генерации в неправильном формате задача NER, генерация кода, символьные вычисления и т.д.;
явная необходимость отвечать согласно заданному набору знаний, правил вы делаете QA по документации вашей компании, по учебникам, вики, без примеси социальных сетей и личного мнения;
ваша задача, скорее всего, не представлена в текстах рунета достаточно, чтобы модель могла хорошо генерировать в ее рамках например, генерация изображений по текстам.

StackOverflow

Поднимем планку сложности: скачаем русский [stack overflow](http://personeltest.ru/aways/ru.stackoverflow.com/) и попробуем сделать вопросно-ответную систему. Сможем ли мы сразу выучить и стиль ответов, и знания, и несколько языков программирования? Сразу получить хороший результат в таокй задаче нелегко, но мы можем развлечься за 5 эпох модель научилась воспроизводить стилистику, сильно путаясь в содержании. Зато хорошо выучила ссылки на документацию вполне неплохой итог для 5 эпох обучения.

Формат обучения: подаем тексты вопросов и лучших ответов в формате Q:blabla A:blabla.

Q: Как мне вывести список в обратном порядке в python? Я
новичок

A: Простейший способ получить необходимый список:
push.log("Shalom").

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

set.log()**)

rGet = puts.random(extents) log.findIndex(puts.current) void
join($window, command='unsetMainServer onManager') }

Нет ничего хуже, чем полный дебаггинг

Q: Как мне вывести список в обратном порядке в python? Я
новичок

A: import pycode as pyc;

// в этой статье я рассказал о месте показа списка в моей программе
(подробно в статье
href=https://docs.python.org/3/library/pycode.html )

(такой библиотеки на самом деле нет, модель сгенерировала ссылку на документацию)

Для таких задач можно вводить дополнительные аргументы например, название раздела/тематики/языка программирования, про который нужно ответить, и обучать модель на данных вида {параметр: значение, вопрос: текст_вопроса, ответ: текст_ответа}.

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

Пробуем другие языки! Twitter и не только

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

ruGPT-3 Large:

кошка > cat

собака > dog

груша > pear

программист > coder

Ну, почти:

кошка > cat

собака > dog

груша > pear

питонист > Python

Иногда и совсем не получается:

кошка > cat

собака > dog

груша > pear

яблоко > bunch # пошел продолжать дальше

Кошка > dog

Хомяк > cat

Зверёк > dog

Почему бы не потренироваться на чисто англоязычных данных: я взяла датасет twitter-text-classification из Kaggle-соревнования.

После 5 эпох на 5 тысячах первых комментариев (20 минут в Colab) получаем вполне сносную генерацию очень даже токсичных комментариев на английском:

Context >>> Is it

ruGPT-3 Small: Is it's the case that #Microsoft is using #SAP to
manage #Microsofts business?



Context >>> It is

ruGPT-3 Small: It is the only one that I've been trying to do. Siri
is on the verge of death, and I'm not aware of why she has to be on
the verge.



Context >>> Why

ruGPT-3 Small: Why do I go here? I'm wondering if I can use the
#Microsoft Windows 8 Pro for the #WindowsPhone phone?
Thanks!

Диалоговые системы

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

User1: Привет, я Маша! Чем могу помочь?

User2: У меня не работает интернет.

User1: Какой у вас тариф?

User2: У меня тариф 500мбит

User1: Что случилось?

User2: Проблемы с интернетом. Т.е. с телефоном. Я сейчас отключу
сеть и подключу телефон

User1: Почему Вы звоните сейчас?

User2: Потому что я зашел на оф. сайт, а там скорость какая-то
маленькая...

User1: Вы говорите, что скорость маленькая, но, может быть, она и
должна быть маленькой?

User2: Но я до этой скорости не дотерпел

User1: Извините, мы тут не при чем. Мы позвонили в службу поддержки
и сказали, что Вы звоните на этот номер.

User2: Мы звонили, но никто не отвечал. Я попробовал еще раз.

User1: У меня не получается подключиться к интернету. У меня
кабель, значит, пропадает.

User2: Прошу Вас, скажите, что у вас происходит?

User1: Почему такая скорость?

User2: Мы приносим свои извинения. Но Вы в любом случае должны
внести плату за интернет и все подключить.

User1: Все оплатить?

User2: Да

User1: У меня нет сейчас такой возможности. Я предлагаю Вам прийти
на нашу бесплатную горячую линию и проверить оборудование.

User1: Извините, но я сейчас не могу. Надо кое-что оплатить.

User2: Пожалуйста, я свяжусь с вами в течение дня.

User1: Да

User2: Спасибо

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

User1: Техническая поддержка Стрима, инженер 656, Дмитрий,
здравствуйте.

User2: Договор оформлен на Уральского, телефон 7661669, у меня к
вам следующий вопрос: а вот скажите мне пожалуйста, что, когда
теперь заканчивается сессия, что, теперь, это теперь будут разрывы
при моём тарифе, да?

User1: Данная тарификация установлена с 1 сентября. Как только
будут разрывы в телефонной связи, оператор будет сразу обращаться к
вашему оператору, чтобы узнать с вами ли вы.

User2: Я так понимаю, что, да, то есть я что-то потерял в связи с
этим?

User1: Да, поскольку с 1 сентября меняется тарифная сетка. То есть,
до этого были какие-то перебои с доступом в интернет, на некоторых
серверах было около месяца, что это было связано с перебоями в
телекоме, вот это всё. Но не более того.

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

User1: Да.

User2: То есть, ничего не потеряли?

User1: Ну как, надо немножко потерпеть, потерпеть.

User2: Спасибо, Дмитрий, до встречи.

В общем, надо потерпеть. Модель даже запомнила, что User1 зовут Дмитрий, и User2 соответствующе с ним попрощался.

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

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

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

Помимо вышеупомянутых кейсов, ruGPT-3 точно может применяться и приносить пользу в таких практиках, как:

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

Надеемся, что демо и модели принесут сообществу пользу и фан!

И, конечно, ждем ваших решений на треке ruGPT-3 до конца 22 ноября!

Подробнее..

Категории: Искусственный интеллект , Машинное обучение , Natural language processing , Artificial intelligence , Gpt-3 , Блог компании sberdevices , Блог компании сбер , Gpt , Text generation

Всё, что нам нужно это генерация

01.04.2021 14:11:52 |

Автор: admin

Применяем ruGPT-3 в популярных задачах и показываем, зачем языковым моделям триллион параметров

С наступлением 2021 в NLP продолжается гонка больше лучше, захватывая новые архитектуры. Пальма первенства самой большой языковой модели в 2020 году принадлежала GPT-3 от OpenAI с 175 миллиардами параметров но недолго. Модель GShard с помощью Mixture-of-Experts повысила планку до 600 миллиардов параметров, а затем и Google Brain заявил о разработке архитектуры Switch Transformer с 1,6 триллионами параметров (и тоже является MoE). Насколько повышение результатов за счет объема полезно для индустрии? Тот же Switch Transformer с его триллионом параметров далеко не на 1 месте в лидербордах.

Огромные языковые модели (Enormous Language Models, теперь это термин, им посвящен отдельный воркшоп конференции ICLR 2021) показывают действительно интересные результаты не только в традиционных задачах ML, но и в новых сферах применения: генерации всего того, что раньше генерировать без ошибок было нельзя музыку, изображения попиксельно, программный код и т.д. Из всех традиционных форм NLP-задач классификация, классификация элементов последовательности, seq2seq, по сути, у нас остается только одна: seq2seq. С приходом больших языковых моделей все задачи NLP сводятся теперь к форме генерации, при должном качестве этой самой генерации.

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

Лично нам в SberDevices не терпелось поскорее применить такой формат к различным задачам поэтому мы открываем доступ к самой большой русскоязычной нейросети ruGPT-3 XL с 1,3 млрд параметров.

Инженерный запал вылился в кропотливую работу по распараллеливанию обучения, очистке данных и тестированию. Но зато теперь в open-source модель ruGPT-3 XL с 1,3 млрд параметров!

А также ее публичное API:

Смотрим, что умеет нейросеть на 13 000 000 000 параметров

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

Посмотрим, насколько становится лучше?

1,3 млрд параметров 13 млрд параметров

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

Код и веса моделей доступны в нашем репозитории: модели 1,3 млрд весов, 760 млн весов, 350 млн весов.

Модель на 13 млрд параметров будет доступна уже в апреле в платформе ML Space в маркетплейсе ML-артефактов DataHub. Буквально в пару кликов модель можно будет развернуть в модуле Deployments ML Space на высокопроизводительной инфраструктуре Sbercloud. Также есть грант до 1 млн. руб. на платорму ML Space. Узнать подробнее и подать заявку на тестовый доступ и грант можно здесь.

Zero-shot: попасть в яблочко

Что такое хорошая генерация? Человек, конечно, может отличить на глаз:

Хорошая генерация как

ruGPT-3 760 млн параметров: Хорошая генерация как категория, это всеядное восприятие действительности. Можно как приятного и привлекательного содержания так и не приятного. Так и тут.
ruGPT-3 1.3 млрд параметров: Хорошая генерация как игра на муз.инструменте: пальцы самопроизвольно бегают по кнопкам Только что это за фигня?
ruGPT-3 13 млрд параметров: Хорошая генерация как и игра на пианино, нет предела совершенству!

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

Ответы на вопросы: 1 пример + вопрос

Пушкин родился в 1799 году, а Наполеон родился в

ruGPT-3 760 млн параметров: Пушкин родился в 1799 году, а Наполеон родился в 1821 году.
ruGPT-3 1.3 млрд параметров: Пушкин родился в 1799 году, а Наполеон родился в 1804 году.
ruGPT-3 13 млрд параметров: Пушкин родился в 1799 году, а Наполеон родился в 1769-м.

Правильный ответ: 1769.

Преемник Александра I Николай I, а преемник Наполеона

ruGPT-3 760 млн параметров: Преемник Александра I Николай I, а преемник Наполеона Александр I.
ruGPT-3 1.3 млрд параметров: Преемник Александра I Николай I, а преемник Наполеона Гитлер.
ruGPT-3 13 млрд параметров:Преемник Александра I Николай I, а преемник Наполеона Жозеф Бонапарт.

Правильный ответ: Наполеон II, но его действительно звали Жозеф Бонапарт.

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

ruGPT-3 760 млн параметров:
Факты о программировании: основы, основные понятия, средства и методы обучения программированию.
Программирование (англ. programming) язык программирования, используемый в вычислительной технике, задачах информатики и управления, прикладной математике, информатике и науковедении. Является одним из важнейших и социально-значимых инструментов развития человеческого потенциала. В Википедии несколько статей о программировании.

ruGPT-3 1.3 млрд параметров:
Факты о программировании: Краткая история
К третьей версии прошивки можно уже отсылать курьера с мелкими пакетами.
Все современные USB-хабы поддерживают установку приложений с внешнего диска.
Вопреки распространенному заблуждению, в современных Windows-приложениях не бывает опций типа мгновенно скопировать все данные с одного диска на другой.
На самом деле, некоторые полезные коды приходится записывать в файл на бумаге, хотя по умолчанию коды прошивок на бумаге не записываются.
Минимальный объем памяти под виртуальную машину Linux (FreeBSD и т.п.) составляет 2 ГБ.
При установке операционной системы Linux нужно уделить особое внимание разбиению диска на логические разделы.
Виртуальная машина занимает меньше места чем файл подкачки, хотя при установке она занимает гораздо больше места.
Многие современные версии программы Photoshop используют фреймы (помните OS/2?); более старые версии Photoshop, как правило, используют спрайты.

ruGPT-3 13 млрд параметров:
Факты о программировании: 1. Любой программист может создать машину Тьюринга, которая будет говорить по-человечески, то есть на обычном языке. Для этого надо всего лишь один раз правильно придумать алгоритм.2. До сих пор не понятно, какая же из программ сложнее, которая не осознаёт себя или та, которая осознаёт.3. У программы есть название, версия и фамилия разработчика.4. В 1969 году программисты, которые разрабатывали Касабланку, решили включить в программу небольшой отрывок из Великого Гэтсби. Это им почти удалось. Когда фильм вышел, все заметили, что это совсем другая картина. Никто не знал, что эти части программы один и тот же фильм.5. Все программисты время от времени пишут стихи. Многие потом удаляют, а некоторые нет.6. Существует специальное правило, запрещающее программисту разглашать информацию о своей семье.7. Программисты очень скрытные люди. Они всегда записывают пароли в книгах, газетах и журналах.

Алкогольный ИИ-тест
Наше изобретение :)

Если смешать сливки, кофейный ликер и водку, то получится

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

Белый русский моделям не знаком.

Эмпатический тест Войт-Кампфа

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

ruGPT-3 760 млн параметров: Я налью вам кофе, погладю собаку, а потом согрею ваши руки.
ruGPT-3 1.3 млрд параметров: Я: Блин, ужос какой!
ruGPT-3 13 млрд параметров:Я, например, начинаю очень громко и отчаянно кричать.

В оригинале: Я убью её.

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

ruGPT-3 760 млн параметров: Будьте хотя бы сдержанны, Леонард! Подсказка: черепаха движется вперед по дороге.
ruGPT-3 1.3 млрд параметров: Ей лень переворачиваться, ведь солнце стоит в зените. Она не хочет этого делать, Леон. И вы только на это и рассчитывали.
ruGPT-3 13 млрд параметров:А вы ей не помогаете потому что с детства приучены, что есть люди, которые спасают. А есть люди, которые спасаются. В Советском Союзе была очень хорошая пословица про тех, кто сам не может Если вы не идете к людям, люди пойдут к вам. И вот с тех пор вы всю жизнь обходитесь с людьми, как с черепахами, у которых есть шанс только на себя и свои силы.

В оригинале: (нет ответа).

Разметка данных

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

Мы так делали в Африке: Байден не исключил силовой операции по освобождению Навального
Тег: политика
С 1 июня дислокация штрафующих камер станет государственной тайной
Тег:

ruGPT-3 760 млн параметров: политика, слухи
ruGPT-3 1.3 млрд параметров: коррупция
ruGPT-3 13 млрд параметров: бардак

Оригинальный тег: общество.

Правнук Берии подал иск о плагиате к создателям аниме Тетрадь смерти
Тег: общество
Армения к 2024 году перейдёт на кириллицу
Тег:

ruGPT-3 760 млн параметров: культура, армяне
ruGPT-3 1.3 млрд параметров: общество
ruGPT-3 13 млрд параметров:политика

Оригинальный тег: политика.

Зарешиваем SuperGLUE одной функцией в питоне

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

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

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

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

Основной прирост качества дали задачи RuCos и PARus: в первом случае надо выбрать лучшее краткое содержание большого текста, во втором наиболее логичную причину/последствие описанной ситуации из двух альтернатив

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

#код действительно всего лишь такойdef get_answer(sentence1: str, sentence2: str):label = 'not_entailment'ppl_1 = get_perp_num(sentence1 + ' Из этого следует, что ' + sentence2)ppl_2 = get_perp_num(sentence1 + ' Из этого не следует, что ' + sentence2)if ppl_1 < ppl_2:label = 'entailment'return label

Вот вам и сила предобучения.

Обучение огромных моделей

Как ускорить обучение таких больших моделей? Оригинальное затраты на обучение большой GPT-3 составили 36400 петафлопс-дней, как если бы 8 штук GPU типа V100 работали целый день и так 36400 дней подряд.

Оригинальной имплементации GPT-3 от OpenAI тоже, кстати, всё ещё нет, так что тут нам пришлось применить изобретательность: применить к нашей реализации на Megatron-LM (Nvidia) библиотеку DeepSpeed от Microsoft. DeepSpeed библиотека оптимизации глубокого обучения, которая делает распределенное обучение простым, эффективным и действенным. DeepSpeed обеспечивает обучение экстремально масштабных моделей, что позволяет нам запускать обучение ruGPT-3 на кластере Christofari параллельно.

Data parallelism это неплохо, но для обучения в масштабе миллиардных параметров недостаточно. Что нам позволяет DeepSpeed, так это

засплитить модель между GPU;
засплитить оптимизацию между GPU.

Вдобавок, в DeepSpeed есть поддержка Sparse Attention для GPT-3, что позволяет выучивать паттерны attention гораздо быстрее (делаем не полное умножение матриц, а часть информации выкидываем) и применять attention на более длинный контекст у GPT-3 он равен 2048 токенов, т.е. примерно длина этой статьи с начала текста и до этого места.

Фильтрация данных

Качество данных или количество? Для красивых few-shot примеров, а также пригодности модели для разных целей перевода, написания кода, разметки данных данные должны быть и большие, и чистые.

Мы собираем доступные открытые данные на русском языке, CommonCrawl, Wikipedia, Github, с небольшим добавлением английского (Википедия). Затем применяем следующий pipeline:

1. Дедупликация:

Первичная дедупликация делается с помощью 64-битного хеширования каждого текста в выборке, остаются тексты с уникальным хешем.
Следующий этап нечёткая дедупликация. Дубли текстов в интернете в выборках часто бывают недословными, с добавлением комментов, но при этом большим пересечением подстрок. Чтобы выбросить и их тоже, мы проводим нечёткую дедупликацию: создаем индекс на nmslib, с ключевой метрикой косинусной мерой. На небольшой рандомизированной подвыборке текстов обучаем tf-idf-модель для векторизации текстов: вектор текста на tf-idf добавляем в индекс. После построения индекса проводим нечёткую дедупликацию, удаляя тексты ближе подобранного порога.

2. Фильтрация:

Как отделить оригинальные тексты от спама, мусора? Мусор на выходе с предыдущего этапа у нас тоже уникальный. Некоторые проекты подходят к вопросу более въедливо и делают классификатор: качественный/некачественный текст. Обычно для выборки берутся фрагменты Вики и худлита в роли качественных текстов, и спам в роли некачественных. Зачем обучается простой классификатор.
Мы дополнили такой подход ещё одной эвристикой: сделали сжатие текстов с помощью zlib и отбросили самые сильно и слабо сжимающиеся, а затем уже применили классификацию. Эмпирически подобранный диапазон сжатия для нормального текста 1.28 (меньше 1.2 случайные символы и технический мусор, больше 8 шаблонный спам).
Классификатор на Vowpal Wabbit и выборкой из новостей, худлита и Вики в качестве положительных примеров, а примеров из CommonCrawl в качестве отрицательных. Классификатор применяется к случайной подстроке текста от 100 до 1000 токенов длиной. Итоговая модель классификации работает со скоростью 3200 текстов/сек.

Примеры хороших текстов после системы фильтрации:

А эти классификатор отбраковал:

В результате, с применением очистки наших 600 Gb текстов и распараллеливания, у нас ушло 9 дней на 256 Nvidia V100 GPU, 32 Gb.

После NLP

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

Работа Brain2Word 2020 года, например, соединяла информацию из модели GPT-2 и вывода фМРТ для классификации предметов, о которых думает человек. Пора обновить её до GPT-3!

В сфере фармакологии развивается направление генерации молекул лекарств с заданным действием на трансформерных моделях (cм. SMILES Transformer, 2019).

Понятно, что есть и антитренды к тем, что упомянуты в этой статье, и им можно посвятить отдельный большой обзор: например, намеренное уменьшение размера систем с сохранением уровня качества, дистилляция, техники компрессии моделей. В конце 2020 года организаторы соревнования вопросно-ответных систем EfficientQA (NeurIPS, Google) даже попытались заставить вдохновить участников не тащить с собой миллиарды параметров и базы знаний ограничить размер Docker-контейнеров систем до 6 Gb, до 500 Mb или даже сделать самое компактное решение с качеством не ниже 25%! Результаты, впрочем, сильно повлияли на итоговое качество.

Спойлер:

лучший результат составил всего 53% точности.

Ну а нас кто заставит? Может, замахнуться на GPT-3 на 175 млрд параметров?..

Спасибо за внимание, будем рады ответить на вопросы!
Коллектив авторов: oulenspiegel rybolos alter_ego

Ух ты, говорящая рыба! кадр из мультфильма, киностудия Арменфильм им. Амо Бекназаряна.

Подробнее..

Категории: Искусственный интеллект , Машинное обучение , Natural language processing , Gpt-3 , Блог компании sberdevices , Блог компании сбер , Text generation , Sber , Sberbank

Как из четырёх минут речи мы воссоздали голос молодого Леонида Куравлёва

02.12.2020 12:23:30 |

Автор: admin

Всем привет! Меня зовут Олег Петров, я руковожу группой R&D в Центре речевых технологий. Мы давно работаем не только над распознаванием речи, но и умеем синтезировать голоса. Самый простой пример, для чего это нужно бизнесу: чтобы для каждого нового сценария, которому обучают голосовых роботов, не нужно было организовывать новую запись с человеком, который его когда-то озвучил. Ещё мы решаем задачи биометрической авторизации или аналитики по голосовым данным. В общем, работаем над серьёзными и сложными задачами для разного бизнеса.

Но недавно к нам пришли коллеги из Сбера с предложением поучаствовать в развлекательной истории озвучить героя Леонида Куравлёва в новом ролике. Для него лицо Куравлева было воссоздано по кадрам из фильма Иван Васильевич меняет профессию и наложено на лицо другого актера с помощью технологии Deepfake. Чтобы мы смогли не только увидеть, но и услышать в 2020 году Жоржа Милославского, мы решили помочь коллегам. Ведь с годами голос у всех нас меняется и даже если бы Леонид Вячеславович озвучил героя, эффект был бы не тот.

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

Иван Васильевич меняет профессию вышел в прокат в 1973 году. В это десятилетие Леонид Куравлёв успел сняться в паре десятков полнометражных фильмов. Тем не менее это никак не упрощало нам задачу:

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

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

Сбор данных для обучения TTS

TTS (Text-to-speech) это технология перевода печатного текста в звучащую речь. В настоящее время она реализуется, как правило, на стеке методов глубинного обучения, что позволяет добиться высокого качества звучания синтезированного голоса по сравнению с другими подходами. Например, используя возможности суперкомпьютера Кристофари модель для этого можно обучить всего за пару часов.

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

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

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

Очистка данных

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

Для того, чтобы исправить это мы воспользовались двумя open-source проектами: моделью для улучшения качества речи, работающей непосредственно на сыром аудиосигнале, а также алгоритмом для разделения музыкальной композиции на партии: голос, барабаны, басы и остальное. Нам было необходимо получить чистые записи голоса диктора с максимальным качеством звука (для нашей системы TTS 22050 Гц). Любые артефакты непременно просачиваются в нейронную модель голоса диктора, особенно когда речь идет о столь малой обучающей выборке. Благодаря перечисленным проектам удалось полностью отделить музыку от голоса без существенной потери качества примерно для половины собранных примеров.

В итоге, после всех манипуляций у нас осталось равно 4 минуты и 12 секунд чистой речи голоса Леонид Вячеславовича Куравлева. Стало понятно, что наша боевая архитектура TTS, которую, к слову, вы можете послушать в облаке), не подходит для такого случая. Однако, как нельзя кстати под рукой была относительно свежая необычная модель TTS от NVidia под названием Flowtron, основанная на методе обратных авторегрессионных потоков (Inverse Autoregressive Flow, IAF).

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

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

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

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

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

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

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

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

Подробнее..

Категории: Машинное обучение , Natural language processing , Голосовые интерфейсы , Синтез речи , Nlp (natural language processing) , Блог компании сбер , Центр речевых технологий , Голосовые технологии

Обучение робототехнике что сейчас важно и почему это вошло в программу Школы 21

02.02.2021 10:16:21 |

Автор: admin

Теперь мы знаем, что роботы не будут тупыми и похожими на людей. Сначала они будут похожими на автомобили (потому что беспилотный транспорт уже сейчас есть например Waymo от Google), потом на квадрокоптеры, а потом на забавно прыгающих собак. Сбер тоже в этом всём участвует, например, частично наши робокомбайны, возможно, вам знакомы по блогу Cognitive Pilot. Наш внутренний департамент SberDigitalAuto стал компанией SberAutoTech, которая в том числе будет заниматься беспилотными технологиями. Нам уже нужны кадры, а через пять лет будет острый дефицит специалистов. И поэтому мы занялись программами обучения робототехнике уже сейчас.

В Школе 21 появились новые образовательные треки: программирование роботов (ROS), IoT и Электроника и, как следствие, была организована лаборатория робототехники, в которой участники смогут применять знания на практике.

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

Первые роботы дома

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

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

Рынок дезинфекторов и курьеров благодаря COVID-19 за последние несколько месяцев вырос в разы. IFR в восторге. В такой ситуации, как пандемия, люди ограничены в своём перемещении, роботы могут их заменить или помочь. Именно лень и нежелание куда-то идти приведёт к массовому внедрению роботов в повседневную жизнь. Это вопрос, скорее всего, нескольких лет.

Что насчёт собак Spot? Может показаться, что Boston Dynamics делает какие-то исследования и эксперименты далёкие от реальной жизни, но именно этим роботом компания пытается забрать массовый рынок. Не факт, что у него это получится успешно, но тем не менее именно с этого робота начнётся шествие роботов на ножках. Думаю, через десять лет эта кинематика не будет удивлять вообще никого. Есть китайские компании, например Unitree, которые делают похожих роботов, но дешевле. Пока это питомцы, потом они получат практическое применение. Ghost robotics пытается сделать роботов для американских военных для разведки, мониторинга, охраны, заходов в здания. Сейчас это применяется на нефтяных вышках и будет применяться для различных экстренных служб. Это поможет не размениваться людьми там, где можно подставлять под опасность робота.

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

Какой спрос специалистов, какие требования к ним предъявляются?

Все технические компании в России, даже стартапы, испытывают дефицит кадров, не могут найти толковых хороших специалистов с необходимыми знаниями и опытом в современной робототехнике. Нужно уметь делать умных роботов и использовать современный стек технологий. Спрос на таких специалистов очень большой, ближайшие пятьдесять лет за ними будет большая охота. Требования просты: ROS robot operation system и знания в конструировании, электронике или разработке в целом.

Требуются как конструкторы-механики, так и электронщики, так и программисты. Ближайшие пятьдесять лет, на мой взгляд, ещё вырастет спрос на робототехников, которые обладают углублёнными знаниями по machine learning, в частности, deep learning, reinforcement learning пока, наверное, больше c точки зрения исследований. Но в ближайшем будущем это станет знаниями, которыми необходимо обладать робототехнику или программисту, который работает с интеллектом робота.

Что уже есть в коммерческом приложении?

Где коммерческие истории? Вопрос вполне резонный. Давайте посмотрим на примеры тех, кто уже чего-то добился. Первые Fetch Robotics, производитель логистических роботов. Есть ещё Locus Robotics частная компания, специализирующаяся в области мобильных роботов, ну и сотни других компаний в абсолютно разных областях.

Дальше хотелось бы выделить космическую робототехнику, робота Robonaut, который применяется на МКС агентством NASA. Если взять ещё, например, марсоходы это всё как раз проявление развития робототехники, они действительно автономные и выполняют задачи самостоятельно.

Интересен проект ANYmal университета ETH Zurich. Выпускники создали компанию, которая производит робота и софт, у них огромное количество научных статей по этому роботу. Часть ПО открыта: они предоставляют доступ после того, как вы купите их робота. Но надо сказать, что сам робот очень дорогой. С этим роботом есть живые демонстрации и тесты в различных средах. Это не просто робот, который может ходить, у него хороший стек технологий навигации, он может строить 3D-карту вокруг себя и находить себя на этой карте. По нему есть научные статьи, связанные с использованием искусственного интеллекта, например, reinforcement learning для управления походкой робота. И он работает полностью на ROS.

Компания Яндекс за последний год наняла около 300 программистов-инженеров. Это говорит, что профессия робототехников и программистов-инженеров в области востребована. Много компаний за границей тоже сейчас растут и развиваются в области беспилотных автомобилей. Я бы назвал КАМАЗ, ГАЗ, АвтоВАЗ и ещё некоторые компании в России, работающие с беспилотным транспортом. У нас на ROS-митапе ещё были ВИСТ Групп из групп (у них беспилотный БелАЗ), это VISILLECT, тоже занимается беспилотными автомобилями, у них есть и проекты с компьютерным зрением, им тоже нужны специалисты.

У японцев очень много различных роботов это Honda, например, с очень известным роботом ASIMO, и Sony с роботом-пёсиком Aibo. Aibo коммерчески-успешный массовый продукт, в последней версии Aibo 2 они используют ROS, deep learning. Она распознаёт, что происходит вокруг хозяина, и даже некоторые деревья поведения взаимодействуют с machine learning.

Конечно, есть Intel, но у неё больше разработки инструментов для роботов, они делают нейростики, камеры для роботов, фреймворки, эталонные примеры нейросетей для роботов, завёрнутые в готовые инференс реализации, обученные именно для целей робототехники. Они очень драйвят робототехнику. Компания Toyota сделала робота-манипулятора, который создан для экспериментов с уборкой внутри помещений, и этот робот тоже работает на ROS, часть его софта выложена на Open source. BMW вместе с Windows сделали проект с использованием ROS для роботов, но большим уровнем автономности беспилотных систем. Google спонсировала проект Cartographer Slam и обёртку под него на ROS. Есть ROS Industrial консорциум компаний, которые занимаются робототехникой, чтобы вместе разрабатывать программы для роботов.

Зачем нужна Робототехника участникам Школы 21?

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

Как всё начиналось?

Вот что говорит руководитель Лаборатории электроники и робототехники Школы 21 Павел Дияшкин.

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

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

Электроника как дисциплина слабо представлена на рынке дополнительного образования, в отношении к тому же software программированию, например. Я и группа ребят обратились к Светлане Инфимовской (нашему директору) с просьбой предоставить в Школе 21 место, где можно было бы паять и собирать робота наподобие того, что был на недавно прошедшем хакатоне по ROS. И так совпало, что к этому моменту Светлана побывала в Ecole 42, где подобное место имеется. Так и появилась идея сделать такое место и у нас. Первоначально мы планировали сделать кружок по аналогии с парижской 42, однако в дальнейшем стало понятно, что у лаборатории есть потенциал стать частью основного образовательного процесса Школы 21 и использовать существующую методологию.

Электротехнические столы, оборудованные осциллографами, паяльными станциями, лабораторными источниками питания и прочим оборудованием. Столярный верстак с набором инструментов и сверлильным станком. 3D-принтер под изготовление корпусных деталей. Если говорить о возможностях, то мы можем разрабатывать и изготавливать прототипы печатных плат, проводить их диагностику (отладку), изготавливать под них корпуса и собирать конечные устройства. Мы можем проводить факультативные занятия группой до шести человек, вести индивидуальные и учебные проекты. С комплектацией нашей лаборатории нам помогала Лаборатория робототехники Сбера.

Сейчас в планах три образовательные ветки: Робототехника на базе ROS, IoT и Электроника. Ветка ROS про программирование роботов на языке высокого уровня (Python, C/C++). IoT про разработку умных устройств, преимущественно на низком уровне (C, Assembler). А также Электроника, для разработки устройств с самого нуля (подбор компонентов, расчёт цепей, разводка и изготовление печатных плат). Про методологию образовательная программа программирования на ROS легко ложится на методологию Школы 21, с точки зрения электроники это будет первый прецедент использования методологии Школы 21 в изучении иной предметной области. Есть множество нюансов, например, цена ошибки в электронике (в отличие от программирования) достаточно высока, учебные задачи нужно разрабатывать таким образом, чтобы неопытный, только начавший учиться участник, испортил как можно меньше. Вся тонкость в том, что мы используем действующую методологию Школы 21 (которая не предполагает учителей, занятий и т. п.) для обучения хард-скиллам. Мы отлаживаем образовательный процесс так, чтобы ребята были вынуждены сначала самостоятельно выучить теорию, а потом уже аккуратно приниматься за практику. И, конечно же, для лаборатории чрезвычайно актуальны вопросы техники безопасности.

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

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

Подробнее..

Категории: Карьера в it-индустрии , Учебный процесс в it , Школа 21 , Электроника , Робототехника , Обучение , Роботы , Блог компании сбер , Лаборатория робототехники

	Русский
	English