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

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

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

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

Какие задачи решает:

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

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

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

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

Платформа не предназначена для роли транзакционной СУБД или аналитического хранилища. Она не хранит временные, одноразовые или быстро меняющиеся данные, которые не подходят под определение справочной информации.

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

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

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

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

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

В Handbooks уже заведено более 400 активных справочников. Раньше они использовались для HR-процессов, а сейчас ими пользуются и другие команды: DWH, BI-аналитики, SME. Справочники не просто хранят данные — на них строится повседневная работа сервисов, автоматизация процессов и контроль качества.

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

Переход на централизованное управление справочниками:

• Сокращает затраты на добавление и поддержку справочников в каждой команде. Не нужно каждый раз писать код для хранения и раздавать данные через свои API.
• Ускоряет интеграцию и распространение обновлений. Если раньше изменение списка статусов нужно было синхронизировать по десятку систем вручную, теперь достаточно обновить справочник, и все подписанные сервисы получат новые данные через API или Kafka.
• Повышает качество и консистентность данных. Единый источник правды исключает ситуации, когда в одной системе должность называется «продакт-менеджер», в другой — «продуктовый менеджер», а в третьей — «руководитель продукта».

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

Со всеми этими проблемами справляется Robocoach — наш диалоговый тренажер, который думает как методолог, говорит как клиент и учит как живой тренер.

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

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

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

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

Отработка стрессовых ситуаций. Тренажер может имитировать голоса и тон раздраженных клиентов.

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

В редакторе сценариев можно выбрать голос для виртуального клиента — у нас их более 15, с разными тембрами и интонациями. Для каждого шага диалога прописываются реплики клиента и варианты ответов оператора (правильные и неправильные). К любому ответу можно добавить обратную связь. В одной тренировке можно собрать до восьми разных кейсов, а в каждом кейсе — до 50 шагов. После настройки остается только нажать «Опубликовать».

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

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

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

В основе тренажера — только наши собственные технологии. Распознавание и синтез речи работают на платформе VoiceKit, что дает нам полный контроль над качеством голоса и скоростью ответа. А диалоговое ядро построено на T-Pro — нашей LLM с гибридным режимом рассуждений на 32 млрд параметров. Такой стек обеспечивает стабильность, независимость от сторонних решений и позволяет тонко настраивать логику диалога под наши конкретные задачи.

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

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

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

Мы выявили четыре основные проблемы:

1. При запуске новых продуктов и изменений не всегда заранее учитываются все точки влияния на клиентский опыт и потребности клиента.
2. Значительная часть ресурса уходит на ручную подготовку инструментов и процессов обслуживания.
3. Неизвестно точное количество запусков или продуктовых изменений, иногда обслуживание узнает о них не сразу.
4. Даже известные запуски не всегда покрываются аналитикой обращений и проблем клиентов.

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

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

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

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

Наша цель — сделать платформу единым центром управления всеми запусками компании и автоматизировать их создание и подготовку.

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

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

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

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

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

В платформе есть набор метрик, по которым оцениваем запуски:

• Contact Rate: как много клиентов столкнулось с проблемами или вопросами.
• Решена ли проблема клиента, как быстро она решается.
• Сколько клиентских проблем удалось решить с первого раза.
• Доля сложных и нестандартных клиентских проблем после запуска.

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

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

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

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

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

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

У нас всегда был клиентоориентированный подход: мы запрашиваем минимум данных, необходимых для открытия продукта. Но изначально вся логика — какие поля показывать, какие скрывать, как обогащать данные — реализовывалась на фронтенде. Это приводило к проблемам: любое изменение требовало релиза, мобильные приложения обновлялись медленно, а масштабирование на новые продукты означало дублирование логики и рост техдолга. Особенно остро это ощущалось при A/B-тестировании — мы не могли быстро экспериментировать, если зависели от релизного цикла. Было понятно: нужно вынести управление флоу за пределы фронтенда.

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

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

Это освобождает продуктовые команды от рутины: больше не нужно вручную искать данные в CRM и реестрах, реализовывать сложные условия показа на фронте или решать вопросы соответствия ИБ-требованиям на уровне обработки персональных данных.

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

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

Масштабируемость Prefill построена на конфигурационном подходе. Мы поддерживаем настройки по продукту, каналу поступления заявки (мобильное приложение, веб), версии клиентского приложения и A/B-экспериментам. Бизнес-правила применяются точечно — под конкретный сценарий, без дублирования. Это позволяет переиспользовать логику и данные между продуктами.

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

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

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

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

В статье рассказываем, как устроены кубики и Т-Лего-Маркет и почему разработчикам теперь выгоднее брать готовое, чем писать свое.

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

Это набор принципов, процессов и инструментов, включающих:

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

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

Кубиком в T-Лего называют любое решение, которое можно переиспользовать. Это может быть платформа, сервис, библиотека, UI-компонент или бизнес-процесс. Главное, решение должно быть полезно не только разработавшей его команде, но и другим.

У кубиков есть четыре уровня зрелости:

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

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

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

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

25 решений вышли за рамки отдельных проектов и стали общебанковскими стандартами. Среди них — STORM, платформа автоматизации Chaos Engineering. С ее помощью команды тестируют устойчивость систем в нестабильных условиях, причем делают это регулярно, а не от случая к случаю. Другое решение — Prefill. Это сервис, который предзаполняет заявки, скрывает ненужные поля и помогает тестировать UX. Еще одна платформа — Varys, которая позволяет создавать сложные онлайн-сценарии без написания кода. В список также вошли Akira (платформа внутренних коммуникаций), CAEN (настройка коммуникаций с клиентами), Spirit Deploy (централизованный деплой), Телефонные книги (единый контакт-центр) и Origination Start (быстрое подключение продуктов).

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

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

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

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

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

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

• Фокус на владельце логики

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

• Удобство без лишней рутины

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

• Гарантии корректности изменений

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

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

Команды постоянно сталкиваются с повторяющимися операциями в классическом процессе поставки:

• завести задачу в таск-трекере;
• перевести ее по статусам;
• уведомить коллег;
• собрать аппрувы;
• запустить тесты.

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

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

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

• Активных пользователей в месяц: более 1000
• Подключенных сервисов: более 100
• Изменений, поставляемых через сервис за месяц: 550+
• SDK для популярных стеков: Kotlin, Python, .NET, Go, Scala (в разработке)

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

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

Мы сделали AutoDoc — готовый шаблон на Docusaurus, который подключается добавлением одного пайплайна. Дальше можно писать Markdown и получать портал с поиском, диаграммами, OpenAPI-схемами и статистикой.

В cтатье разобрали, как это устроено и какие функции доступны из коробки.

AutoDoc — это zero-code-решение для Docs as Code. Оно помогает автоматически генерировать портал документации в любом репозитории простым добавлением пайплайна. В основе — Docusaurus с доступом ко всем его Markdown-возможностям.

Все, кто работает с документацией:
→ разработчики;
→ системные и бизнес-аналитики;
→ QA-инженеры;
→ технические писатели;
→ архитекторы.

Ничего не нужно настраивать: дизайн, структура, поиск, плагины для диаграмм — все уже готово. Нужно знание Markdown, базовые навыки работы с Git и умение коммитить файлы в IDE.

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

→ готовый дизайн и структуру;

→ встроенный поиск по документации;
→ превью в merge request — можно показать коллегам, как выглядят изменения до слияния веток;
→ обратную связь в формате виджета;
→ поддержку GitLab Pages из коробки;
→ локальную сборку для проверки;
→ возможность вести блог продукта рядом с документацией.

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

AutoDoc поддерживает основные инструменты для диаграмм:

→ Mermaid — для блок-схем, графов, диаграмм последовательностей;
→ PlantUML — для UML-диаграмм;
→ Kroki — универсальный рендерер, который покрывает все: от BlockDiag и GraphViz до C4, D2 и Excalidraw;
→ LikeC4 — для интерактивных C4-диаграмм архитектуры.

Все диаграммы хранятся как текст в репозитории, их можно версионировать и смотреть изменения в MR.

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

Мы решили это через глобальный поиск: все публичные документации индексируются с помощью Search-as-a-Service, а с каждого autodocs можно перейти на страницу сквозного поиска, который позволяет найти контент среди всех документаций, использующих autodocs. Также там сейчас доступны поиск по репозиториям Gitlab и Wiki, а свой вопрос вместе с контекстом страницы можно отправить ИИ-ассистенту.

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

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

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

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

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

Ручная оценка в платформе никуда не делась — она просто стала удобнее. Оценщик выбирает звонки по заданным критериям (например, сотрудники с низким баллом или проблемные темы) и заполняет форму в интерфейсе. Также есть отчеты, в которых можно смотреть динамику изменения метрик по фильтрам по оператору, группе операторов или направлению. А модуль «Развитие качества» используется, чтобы оспорить оценку, которую выставили оператору или дать обратную связь после оценки. В обсуждении могут участвовать руководитель, оператор и оценщик, а также можно запросить мнение высоких руководителей в случае длительного оспаривания.

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

Insights отвечает на частые вопросы руководителей: почему клиенты покупают или не покупают товары и услуги, зачем обращаются в поддержку, чем бывают недовольны. В отличие от словарей и отчетов Речевой аналитики, Insights не просто показывает, где возникает проблема, а помогает разобраться в ее причине. Инструмент работает без интернета и внешних сервисов — на базе T-Pro, нашей LLM-модели на 32 млрд параметров. Диалоги с клиентами обрабатываются внутри банка и не используются для обучения ИИ. Модель учитывает контекст и особенности русского языка, чтобы делать точные и глубокие выводы.

За распознавание речи отвечает VoiceKit — наша собственная технология, которая дает до 96% точности даже на некачественных аудио с просторечиями и дефектами произношения. Производительность платформы позволяет обрабатывать тысячи звонков за пять минут. Архитектура построена так, чтобы масштабироваться под нагрузку контакт-центра с 40 тысячами операторов. При этом интерфейс остается интуитивным и не требует специальных навыков для администрирования.

Речевая аналитика закрывает три ключевые задачи:

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

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

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

Thermostat реализует парадигму Feature Toggles и Remote Config. Вместо того, чтобы жестко зашивать значения в код или дергать разрозненные админки, разработчики оборачивают функционал в параметры, значения которых управляются через единую административную панель. Это дает несколько ключевых возможностей: гибко включать и выключать функционал без перезапуска приложения, постепенно раскатывать новые фичи на целевую аудиторию, экстренно откатывать проблемные изменения и таргетировать доставку согласно бизнес-сценариям.

Доменная модель Thermostat строится вокруг трех основных сущностей:

• Application — это приложение или сервис, который создает логическую группировку для параметров.
• Parameter — тоггл или конфигурационная переменная с определенным типом данных (int, bool, string, json).
• Environment — виртуальное окружение (dev, stage, prod и т. д.) с привязкой к определенному контуру test, prod, или public, что определяет сетевой сегмент доступа и ролевую модель для управления конфигурацией в админке.

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

Пользователи получают единый UX независимо от того, с каким контуром работают — test, prod или public. Параметр и его возможные значения создаются один раз и становятся доступны на всех окружениях. Для boolean параметров опции не требуются, для остальных нужно явно определить допустимые значения, которые уже можно выбрать при конфигурации определенного окружения (create once, use anywhere). Предусмотрена возможность задавать in-code default — значение по умолчанию из кода, которое всегда доступно для выбора и позволяет передать контроль над параметром в конкретную сборку приложения.

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

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

В основе клиентской части — спецификация OpenFeature, которая дает единый интерфейс для работы с параметрами независимо от стека. SDK работает с конфигурацией in-memory и периодически обновляет ее в фоне, получая только изменившиеся параметры (инкрементальное обновление), а для динамических параметров делает индивидуальные запросы и кеширует. В ответе передаются метаданные из админки (поскольку все версионируется), которые можно пробросить в логи и метрики для получения observability, чтобы было понимание, что и в какой момент доехало до приложения в runtime.

Для сценариев, где значение параметра зависит от контекста вызова (например, от пользователя или версии приложения), Thermostat поддерживает динамические правила. Каждое состоит из выражений, объединенных по И/ИЛИ. В выражениях используются атрибуты контекста из заранее определенного списка. Это сознательное ограничение, чтобы не заводить бизнес-логику в сервисе фича-тогглов. На один параметр можно назначить до трех правил с соответствующими им опциями.

Для реализации А/Б-тестирования и персонализации Thermostat будет интегрирован с бизнес-платформой Hippo. Такое разделение позволяет использовать разные доменные модели и пользовательские сценарии (UX) для задач, связанных с разработкой и бизнес-персонализацией, а также развивать системы независимо, с фокусом на потребности своей аудитории. При этом Thermostat выступает в роли «мостика» к Hippo и, по сути, является технической платформой.

Сервис построен на Java и архитектурно разделен на два основных компонента: административную панель (control-desk) и сервис раздачи конфигураций (provider). Данные хранятся в PostgreSQL и S3, для управления очередями используется Kafka, для аналитики — Clickhouse. Интерфейс административной панели разработан на React и встроен в IDP Spirit. API описано в спецификации OpenAPI с применением подхода API-first. Поддерживаются SDK для большинства основных языков и фреймворков: Java, Kotlin, Scala, Go, Python, C++, TypeScript, JavaScript, Node.js, .NET, Nest.js, React, Angular. Недавно добавилась поддержка Rust — благодаря иннерсорсу и OpenFeature.

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

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

Мы столкнулись с тремя ключевыми ограничениями:

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

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

Мы задались вопросом: можем ли мы запускать полноценный пентест по кнопке, как пайплайн в CI/CD? Классические сканеры не подходили: они пропускали логические уязвимости, которые находят багхантеры. Масштабировать ручные проверки человеческими силами было невозможно. Решением стало объединение опыта наших команд AppSec, Red Team, SOC и других в единую базу знаний и передача ее AI-агенту. Так Nulla научился думать как пентестер: анализировать код, выдвигать гипотезы атак и проверять их.

1. Мышление вместо правил: агент задает вопрос «Как это можно сломать?» и исследует исходный код и бизнес-логику.
2. Практическая безопасность: он применяет техники реальных хакеров, заложенные нашими экспертами.
3. Доказательство вместо предположений: на выходе всегда воспроизводимый Proof-of-Vulnerability с оценкой влияния на бизнес.
4. Полный контроль над процессом, а не черный ящик.

Детерминированность и стабильность результата — в отличие от непредсказуемых ИИ-инструментов общего назначения.

Архитектура Nulla модульная и ориентирована на безопасность. Планировщик анализирует код, генерирует гипотезы атак и распределяет задачи между пулом специализированных ИИ-агентов, каждый из которых фокусируется на своем классе уязвимостей. Все потенциально опасные операции — проверка гипотез, запуск эксплойтов — выполняются в изолированной песочнице, чтобы не влиять на реальные сервисы. Результат работы — воспроизводимый Proof-of-Vulnerability, который сопровождается полным аудит-логом.

Одно из направлений работы Nulla — автономный анализ API-контрактов (OpenAPI, GraphQL). Агент не просто сканирует схему, а читает исходный код, чтобы понять бизнес-логику и контекст. Это позволяет находить архитектурные и логические уязвимости из OWASP API Top 10, которые часто невидимы для статических анализаторов (SAST). Например, проблемы с авторизацией (IDOR, Auth Bypass) или инъекции. На валидационном датасете Nulla показывает точность 86% при обнаружении таких уязвимостей.

Другая задача — автоматизация регрессионного тестирования. Когда в Jira попадает описание уязвимости, Nulla может автоматически преобразовать его в работающий эксплойт. Агент синтезирует Proof-of-Concept на основе шаблона и контекста, безопасно запускает его в изоляторе и генерирует подтвержденный PoV. Это позволяет проверять, действительно ли разработчики закрыли уязвимость после фикса или просто поставили заглушку.

Многие legacy-сервисы не имеют актуальной документации API. Nulla решает и эту проблему: сканирует исходный код, идентифицирует роутеры, контроллеры, DTO-модели и схемы авторизации, а затем автоматически генерирует OpenAPI-спецификацию (OAS). Это не только возвращает документацию, но и создает структурированную точку входа для последующего глубокого аудита безопасности самим же агентом.

Мы контролируем качество работы Nulla через набор практических метрик:

• Pass@3 показывает долю уязвимостей, которые агент успешно эксплуатирует за три попытки.
• Signal/Noise и FPR (False Positive Rate) отражают соотношение реальных находок и ложных срабатываний.
• Time-to-First-PoV измеряет скорость реакции системы.
• Cost-per-PoV — экономическую эффективность.
• Coverage оценивает полноту анализа кода и сервиса в целом.