Наши Макс Афанасьев и Илларион Иов выложили препринт статьи про Preference Optimization!

Макс у себя в канале пишет ⬇️

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

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

* В PO-задачах есть такая штука, как Unlearning - когда мы может и выучиваем какие-то относительные различия между chosen-ом и rejected-ом, но абсолютное качество генерации падает. Это довольно легко решается добавлениям 'якоря' на chosen-сиквенс. Наши аблейшены это подтвердили.

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

* Ну и для более точного контроля над относительной оптимизацией, мы вместо стандартной logsigmoid'ы используем кастом функцию, которая настраивается двумя параметрами. Первый - soft margin, второй - это hard margin. Hard margin - это своего рода victory condition, - если последовательности оттянуты друг от друга на вот столько, то мы уже вообще ничего оптимизировать там не хотим, совсем - хотим там нулевые градиенты. Soft margin - это способ приоритезировать оптимизацию тех сэмплов, которые хуже растянуты друг от друга. Аблейшены тоже подтвердили, что оно работает🥸 (но здесь мы мало экспериментов поставили, можно было больше).

Overall, метод рабочий, мы его активно юзали до популяризации групповых методов (GRPO и его дети). Сейчас юзаем чуть менее активно, т.к. в целом Pairwise PO задач стало меньше, - везде где можно было, уже перешли на групповые методы. Ну а мы варим потихоньку групповую версию нашего алгоритма, которая до этой статьи не успела доехать, - значит либо будет отдельная статья, либо статьи не будет (если решим, что оно не работает, и всё что наделали чуваки с GRPO - just works fine).

Кстати, если заглянете в статью - увидите очень забавные метрики у Qwen'ов - явно странные для 4B модели, - довольно интересный повод для обсуждения.

Читать здесь:
https://huggingface.co/papers/2602.02383

Дайджест Data-вакансий в Точка Банк 🤝

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

Аналитик данных
🏆 до 300к рублей

Тебе предстоит оцифровывать бизнес-процессы банка, автоматизировать системы мотивации, строить риск-портреты и проверять гипотезы по оптимизации операционки.

Старший продуктовый аналитик
🏆 до 550к рублей

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

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

Продуктовый аналитик
🏆 до 390к рублей

Ищем опытного аналитика, который будет проектировать и проводить A/B-тесты, проводить исследования, разрабатывать продуктовую и маркетинговую отчётность.

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

Техлид команды аналитиков данных
🏆 до 550к рублей

Тебе предстоит развивать команду аналитиков HR Data team и поддерживать её эффективность, а ещё делиться экспертизой с другими командами.

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

Deep Learning инженер
🏆 до 510к рублей

Ищем разработчика, который будет работать с проектами, связанными со звуком. Предстоит адаптировать и разрабатывать SOTA подходы для задач realtime ASR, TTS, VAD. А ещё предобучать кодировщики вроде SpeechTokenizer и собирать прототипы аудио-сервисов, которые затем внедряются во всем банке.

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

А ещё мы обновили наш карьерный сайт, там больше вакансий!

Привет, скучали? А мы весь месяц готовились к конференциям 🫠

Вот, где будем выступать в апреле:

📌 Data Fusion, 8–9 апреля, Москва

Наш лидер ML Андрей Румянцев будет участвовать в двух дискуссиях: про ИИ-трансформацию в бизнесе и развитие рынка данных.

📌 Dump, 24 апреля, Екатеринбург

От нас будет три доклада:

• Аналитик Таня Бородина расскажет, как построить полезный мониторинг из того, что под рукой.

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

• Руководитель ML-команды Антон Земеров расскажет про процесс выстраивания разметки данных от постановки задач ассесорам и оценки согласованности разметки до автоматического поиска ошибок и экспериментов с GPT.

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

• ML-разработчик Влад Попов расскажет, как изменились подходы к разработке семантического поиска и какие паттерны брать в пример в 2026 году.

На выходе получите рецепт по улучшении ретривы, подходы, которые работают на практике, и подходы-антипаттерны.

💜 Приходите знакомиться и задавать вопросы!

Нужен ли вашей команде ML-процесс?

Возникают ли у вас как у руководителя или специалиста ML-команды эти вопросы?

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

Если да, то этот пост для вас. А ещё это значит, что вашей команде нужен ML-процесс.

ML-процесс — это мета-инструкция, которая становится «точкой входа» для поиска ответов на вопросы по разработке проекта. Он обладает такими свойствами:

• Содержит все необходимые для разработки ссылки на ресурсы.
• Объясняет, как делать надо и как не надо.
• Имеет структуру, которая повторяет процесс разработки с исчерпывающим и актуальным описанием всех этапов.
• Становится основой для создания будущей документации по проекту
• Подходит для 95% процессов.
• Упрощает жизнь, а не задаёт рамки.

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

Что вы получите, если поработаете над ML-процессом:

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

В следующем посте дадим шаблон ML-процесса, по которому мы собираем документацию по проектам.

💜 Этот пост написала Светлана Астафьева, ML-разработчик в Точка Банк

Шаблон ML-процесса, которым пользуемся в команде ML Core

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

1) Составить схему основных этапов разработки, принятых в вашей команде, например:
• постановка задачи;
• исследование данных;
• формулировка задачи в ML-терминах;
• MVP-решение;
• тестирование решения;
• выкатка в прод;
• мониторинг.

2) Описать каждый этап:
• что нужно сделать;
• как должен выглядеть результат для перехода к следующему шагу.

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

3) Добавить к каждому этапу:
• шаблоны, которые позволят быстрее выполнить этот этап;
• полезные советы;
• стандарты и требования, если они есть;
• ссылки на ресурсы, статьи, документы, которые могут помочь на этом этапе;
• ответы на популярные вопросы;
• требования к документации — что и где нужно описать, чтобы считать этап пройденным.

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

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

Не вы подстраиваетесь под процесс, а он подстраивается под вас!

💜 Этот пост написала Светлана Астафьева, ML-разработчик в Точка Банк

Блайндбоксы в мире ML: как мы разработали и внедрили микросервис Labubu, который автоматизирует разметку коммуникаций

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

📌 Как микросервис Labubu решил проблему с коммуникациями

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

1) Менеджер связывается с компанией. ASR-модель превращает разговор в текст, а Labubu получает расшифровку.
2) Labubu отправляет текст в маскиратор. Она скрывает персональные данные и чувствительную информацию, а после возвращает обратно.
3) Labubu отправляет зашифрованный текст в LLM. Она проводит анализ и возвращает в микросервис.
4) Labubu отправляет результаты разметки обратно в систему пользователя — она заполняет контекст по коммуникации.

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

Проблема: ASR-модель работала нестабильно. Её WER был 21%, то есть искажено каждое пятое слово. А если во время разговора работала кофемолка, вместо текста мы получали пустой лист.

Решение: текст, который выдавала ASR, отправляли в модель разметки для анализа. Она понимала контекст коммуникации и выдавала его описание с потребностями предпринимателя.

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

Решение: команда Точка Банка разработала маскиратор. Он шифрует персональные данные перед отправкой информации в модель. При этом доступ к данным не имеет даже соседняя команда разработки.

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

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

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

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

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

Как выглядит итоговый пайплайн коммуникаций в Labubu:

1) Проводим префильтеринг по нужным темам диалога.
2) Заполняем критерии отбора.
3) Отправляем отобранные данные в модель разметки.

Что такое префильтеринг и почему он важен

Анализ 100 000 коммуникаций занимает целую видеокарту. Чтобы сэкономить ресурсы, важно сократить количество запросов до самых нужных. Для этого разработчики Labubu каждые 10 тысяч размеченных коммуникаций дообучают небольшой классификатор, который дёшево инферить на CPU. Это позволяет экономить до 60% обращений к основной модели.

В итоге микросервис поднимает конверсию в успешное вовлечение предпринимателя до 10%. Но не всё так гладко.

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

💜 Этот пост написал Макс Умутаев, бэкенд-разработчик в Точка Банк

Блайндбоксы в мире ML: насколько Labubu поднял конверсию, и как разработчики чуть всё не уронили

В прошлом посте мы разобрали, как работает микросервис Labubu. Теперь разберём, к чему привело внедрение Labubu в компанию.

📌 Как обработка коммуникаций едва не заняла все ресурсы

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

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

В итоге у Labubu есть две задачи:

1) Быстро выдать 20 коммуникаций для проверки.
2) Быстро обработать весь запрашиваемый объем.

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

Почему это критично? В сервисе запущено 8 воркеров. Каждый отправляет запросы с параллелизмом в 10 единиц. В сумме они могут создавать нагрузку до 4800 RPM, что анимало больше половины лимитов на весь инференс компании вместе взятой. Из-за этого другие команды получали ошибки.

Решение: пришлось ограничить ресурсы для Labubu до 600 RPM, чтобы микросервис больше не перетягивал на себя все мощности.

Новая задача — не выйти за пределы лимита в 600 RPM

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

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

Код:

import asyncio

async def worker(i, sem):
    async with sem:
        return await job(i)

async def main():
    sem = asyncio.Semaphore(10)
    await asyncio.gather(*(worker(i, sem) for i in range(10_000)))

asyncio.run(main())

Вариант 2. Закидываем все таски в очередь и создаём воркеры

Проблема. Способ оказался сложнее по реализации, чем предыдущий.

Код:

import asyncio

async def worker(q):
    while (i := await q.get()) is not None:
        try: await job(i)
        finally: q.task_done()

async def main():
    q = asyncio.Queue()
    for i in range(10_000): q.put_nowait(i)

    workers = [asyncio.create_task(worker(q)) for _ in range(100)]
    for _ in workers: q.put_nowait(None)

    await q.join()
    await asyncio.gather(*workers)

asyncio.run(main())

В итоге выбрали вариант 2. Способ сработал: воркеры не кидали больше 10 потоков, а сервис не выходил за 600 RPM. Задача выполнена? Оказалось, что нет.

Что пошло не так:
• Labubu постоянно превышал 600 RPM. Примерно 15 секунд из каждой минуты он стабильно натыкался на 429-ю ошибку.
• Back off плохо реализовали. Он сразу ретраил итерацию — сервис после 429 ошибки сразу шёл искать новую 429 ошибку.
• У соседней команды легла ручка проверки квот — она начала отвечать по 300–500 мс из-за бесконечного цикла итераций.

Проблему решили на лету, а соседняя команда переехала на выделенный кластер СУБД.

📌 Какую ценность принёс Labubu?
Несмотря на инфраструктурные сложности, сервис оправдал вложения в разработку и поддержку.

Благодаря таргетированным коммуникациям, Labubu помог найти и привлечь 174 новые компании в комьюнити и поднять конверсию с 1% до 3,91%.

А ещё он подарил бесценный опыт своей команде разработчиков.

💜 Этот пост написал Макс Умутаев, бэкенд-разработчик в Точка Банк

Верите ли в надёжный ML так же, как в него верим мы?

Наверняка вам приходилось сталкиваться с требованиями калибровки модели, интерпретируемости, объяснимости. Но что делать, если в какой-то момент нужно получить ответ на вопрос:

Насколько можно доверять этому конкретному предсказанию?

Тут нам на помощь приходит conformal prediction. Это подход, который добавляет к предсказаниям модели оценку неопределённости.

Обычная модель говорит: спрос завтра будет 100 единиц.

Conformal prediction говорит: спрос завтра, скорее всего, будет от 80 до 125 единиц.

В случае классификации обычная модель говорит: на фотографии объект А.

Conformal prediction говорит: наиболее вероятно, что на изображении объект A или C.

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

Где это может быть полезно?

• Медицина. В медицинских задачах один уверенный, но неправильный диагноз может стоить дорого. Conformal prediction позволяет модели не притворяться всезнающей. Вместо одного диагноза она может выдать несколько вероятных вариантов. Для врача это дополнительная подсказка, куда смотреть внимательнее.
• Предиктивное обслуживание. Вместо точечной оценки мы получаем окно риска, когда важное оборудование выйдет из строя.
• Ритейл. Прогноз вида «завтра мы продадим 407 упаковок мороженого» выглядит слишком магически и не даёт полноты картины спроса. Диапазон прогнозов же удобнее для управления запасами: можно оценить риск дефицита или переполненного склада.

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

1. У нас есть обученная модель. Мы берём отдельную часть данных, которую модель не видела во время обучения. Обычно её называют калибровочной выборкой.
2. На этой выборке мы смотрим, насколько сильно модель ошибается.
3. Мы собираем такие ошибки и выбираем порог, который покрывает нужную долю случаев. Например, хотим 90% надёжности — берём такую величину ошибки, чтобы примерно 90% прошлых правильных ответов попадали внутрь соответствующего интервала.
4. После этого для нового объекта модель делает предсказание, а мы добавляем вокруг него интервал.

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

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

Как это использовать?

Для быстрого старта можно посмотреть на MAPIE. Это библиотека в стиле scikit-learn, которая позволяет строить prediction intervals для регрессии и prediction sets для классификации. Ещё один хороший вариант — PUNCC. Она более гибкая и позволяет применять conformal prediction поверх разных моделей, включая sklearn-модели, нейросети и кастомные пайплайны.

💜 Этот пост написал Виталий Прахов, дата-сайентист в Точка Банк

Эволюция Attention: от RNN к Transformer

Открываем серию постов, в которых расскажем про путь к линейному Attention.

До трансформеров в задачах перевода и классификации в основном использовали рекуррентные модели (RNN). В 2014 году появился механизм Attention. Он позволил не просто читать текст последовательно, а смотреть все входные токены и оценивать, какие из них важны для генерации.

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

Двунаправленная RNN кодировала входную последовательность → для каждого шага декодера считалась релевантность входных токенов → получались веса через softmax → на их основе формировался контекст для генерации следующего токена.

Это дало заметный прирост качества в машинном переводе. Но главная проблема RNN оставалась — они работали плохо на длинных последовательностях. Чтобы «понять» слово, модели нужно было пройти весь текст и дойти до него.

Трансформеры стали следующим шагом эволюции

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

• Отказались от рекуррентности — последовательность считается параллельно.
• Добавили self-attention — помимо энкодера внимание начинает применяться непосредственно к декодеру.
• Добавили Bahdanau Attention выразительности — вместо однослойного перцептрона используется dot product из обучаемых Q,K,V матриц.

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

Это пытались исправить разными способами:
• уменьшали число голов для экономии кэша;
• делали вычисление по части последовательности;
• создавали кернелы для эффективного вычисления Attention (например, Flash Attention).

Эти методы ускоряли вычисления, но не меняли саму формулу Attention.

Про то, как получилось преодолеть это ограничение — в следующем посте.

💜 Этот пост написал Владислав Попов, ML-инженер в Точка Банк

Мы на AHA’26 и в AI Talent HUB

Лиза Афанасьева выступит на AHA’26 с докладом про данные для обучения LLM:

Мы обучили Qwen 235B так, что на наших задачах модель работает на уровне GPT-4.1, при этом существенно снижая затраты компании.

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

Влад Попов в AI Talent HUB расскажет, как чинить ретривы без покупки нового железа:

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

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

Будем рады ответить на ваши вопросы, приходите!

Эволюция Attention: переход к линейным моделям

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

📌 Linear Attention впервые поменял подход к вычислению. Он позволил разложить kernel-функцию и вместо exp(QKᵀ) использовать φ(Q) · φ(K). Благодаря этому получилось:

• перегруппировать вычисления;
• сначала посчитать K · V;
• потом применить Q.

Но главное: сложность стала линейной по длине последовательности (вместо квадратичной). Модель работала быстрее и экономнее по памяти, но вместе с этим теряла точность.

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

Встала задача: сохранить эффективность линейного Attention, но вернуть локальный контекст.

📌 Эту проблему частично решила RWKV-архитектура. Она не отказалась от идеи компактной памяти, но добавила механизмы, которые делают её более чувствительной к текущему контексту:

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

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

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

RWKV стала своеобразным гибридом предыдущих идей. Она не сделала модель такой же точной, как классический Attention, но при этом вернула локальный контекст. Параллельно с ней развивались другие архитектуры — SSM и Mamba.

Подробнее о них расскажем в следующих постах.

💜 Этот пост написал Владислав Попов, ML-инженер в Точка Банк

В предыдущем посте мы рассказали, что такое conformal prediction и зачем он нужен. Но наверняка у вас появились вопросы:

1. А как именно модель понимает, насколько конкретный объект «странный» или «рискованный»?
2. Как обучается конформный предиктор?

Ответ на первый вопрос: через меру некомфортности.

Мера некомфортности — это функция, которая показывает, насколько плохо конкретная пара (x, y) согласуется с моделью и уже известными данными.

Мерами некомфортности могут быть как простые функции, например, MAE или hinge_loss:

nonconformity_mae = |y_true - y_pred|
nonconformity_hinge = 1 - P(true_class)

так и более сложные, например, оценка Брайера.

Интуитивный пример

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

Barbie: 0.02
Ken: 0.97
Oppenheimer: 0.01

А для размытой картинки животного в лесу:

Barbie: 0.2
Ken: 0.42
Oppenheimer: 0.38

Обычный классификатор во всех случаях выберет класс Ken. Conformal prediction во втором случае может сказать:

{Ken, Oppenheimer}

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

Далее поговорим про то, как это обучать.

TCP: Transductive Conformal Prediction

TCP в строгом смысле не «обучается» как обычная модель. Лучше сформулировать это так:

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

Давайте рассмотрим пошагово алгоритм TCP.

Допустим, есть выборка:

D = {(x1, y1), ..., (xn, yn)}

и новый объект

x_new.

• Шаг 1. Берём один из классов, например, Barbie. Делаем предположение:

y_new = Barbie

• Шаг 2. Добавляем его в существующий датасет:

D_Barbie = D ∪ {(x_new, Barbie)}

• Шаг 3. Обучим модель на новом наборе данных.
• Шаг 4. Считаем меру некомфортности, например, hinge_loss, для всех объектов, включая новый.
• Шаг 5. Сравниваем новый объект с остальными. Смотрим, насколько некомфортность нового объекта велика относительно остальных объектов в D_Barbie. Упрощённо:

p_value(Barbie) = доля объектов, у которых score ≥ score_x_new

Шаги с первого по пятый повторяются для каждого класса. Финальный prediction set формируется из классов, у которых p_value > α, где α — желаемый уровень значимости.

ICP: Inductive Conformal Prediction

Опытные ML-инженеры, прочитав предыдущую часть, наверняка ужаснулись. Для предсказания на 1000 объектов в 10 классов нам понадобится 10 000 переобучений модели!

Эту проблему решает метод ICP за счёт выделения отдельной калибровочной выборки:

• Шаг 1. Делим данные на train и calibration:

D_train  
D_calibration

• Шаг 2. Обучаем модель на D_train. После этого модель больше не переобучается для каждого нового объекта.
• Шаг 3. Считаем меры некомфортности на D_calibration. Для каждого объекта из D_calibration считаем, насколько плохо модель предсказала правильный ответ. Получаем набор calibration scores:

scores = [α1, α2, ..., αm]

• Шаг 4. Задаём уровень значимости α и выбираем порог q. Теперь выбираем такой порог скора q, чтобы нужная доля calibration scores была не больше него. Упрощённо:

q = 90-й процентиль calibration scores

• Шаг 5. Применяем к новому объекту. Для нового объекта считаем score для каждого возможного класса:

score(Barbie) = 1 - P(Barbie)  
score(Ken) = 1 - P(Ken)  
score(Oppenheimer) = 1 - P(Oppenheimer)

В prediction set попадут те классы, у которых score ≤ q.

Главное отличие от TCP:

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

💜 Этот пост написал Виталий Прахов, дата-сайентист в Точка Банк

CancelledError — всего лишь очередное исключение. Или не совсем?

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

В статье разобрали:

• что на самом деле происходит при отмене задачи в asyncio;
• что такое CancelledError с точки зрения event loop;
• как устроен протокол cancel/uncancel и как это связано с TaskGroup и asyncio.timeout;
• какие подводные камни возникают при ипользовании asyncio.shield.

Статья для всех, кто пишет на Python и хочет лучше понимать внутренности asyncio ⬇️

Эволюция Attention: эра гибридных моделей

Это завершение серии постов про путь линейного attention. После S4 архитектуры прошли несколько этапов развития:

📌 Mamba — впервые для SSM сделала параметры зависимыми от входа. Благодаря этому модель умеет хранить контекст в памяти и адаптивно решает, что забывать, а что помнить в зависимости от контекста. Поэтому при селективном копировании информации выигрывает у стандартной S4.

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

📌 DeltaNet — смогла решить проблему «грязной памяти». Каждый раз, когда модель добавляет новую информацию, то выполняет проверку:

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

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

📌 Гибридные модели — направление, в котором пошёл ряд крупных лабораторий, так как они позволяют совместить сильные стороны разных подходов. Например, Kimi Linear, Qwen3 Next, MiniMax-Text-01 сочетают линейный attention с обычным:

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

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

💜 Серию постов про линейный attention написал Владислав Попов, ML-инженер Точка Банк

Как продвигать банковские продукты и не превратить коммуникации в спам?

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

Как обычно выглядит процесс продвижения:

Менеджер с аналитиком придумывают гипотезу → выбирают аудиторию по бизнес-фильтрам (например, «клиенты с оборотом больше X рублей») → загружают список в Excel → запускают рассылку.

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

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

Например, у Точка Банка в 2025 году было 66 продуктов. Мы посчитали, что если увеличить количество подключений на 1%, то мы:

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

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

• Какой продукт сейчас релевантен клиенту?
• Через какой канал с ним лучше коммуницировать?
• Стоит ли вообще сейчас выходить на коммуникацию?

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

Подробнее о построении ML-модели расскажем в следующих постах.

💜 Этот пост написал Евгений Наговицын, ML-разработчик в Точка Банк

Как посчитать пользу коммуникации?

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

Чтобы выбрать коммуникацию, которая принесёт максимум пользы, используем формулу ожидаемой ценности (Expected Value):

EV(x,C,Pr) = Δ(x,C,Pr)*LTV(x,Pr)-Cost(C)

x — признаки клиента;
С — канал коммуникации;
Pr — продукт;
Δ(x,C,Pr) — инкремент к вероятности подключения продукта Pr через канал С для клиента х;
Cost(C) — стоимость одной коммуникации в канале С.

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

Δ(x,C,Pr) = P(Y_Pr=1|At=1,C,x)-P(Y_Pr=1|At=0,C,x)

Y_Pr=1 — факт подключения продукта Pr;
At — факт коммуникации.

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

• Что произошло после того, как клиент получил предложение?
• Что произошло бы, если бы он его не получил?

Для сбора статистики используют А/Б-тесты. Аудиторию случайным образом делят на две группы: одной отправляют коммуникацию, второй — нет. Затем смотрят на разницу в конверсии.

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

Как мы решили эту проблему — расскажем в следующем посте.

💜 Этот пост написал Евгений Наговицын, ML-разработчик в Точка Банк

Построение модели Next Best Action

Это продолжение серии постов о построении NBA. В прошлом посте мы рассказывали, что классическое uplift-моделирование плохо подходит для банковских продуктов. Чтобы получить статистически значимый результат, нужно провести кучу A/B-тестов и отправить миллионы сообщений.

Поэтому мы сделали несколько инженерных допущений:

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

P(Y_Pr=1|Z=0, At=1,C,x) ≈ P(Y_Pr=1| At=0,x)

Z — {0, 1} — факт клика на коммуникацию.

Это допущение упрощает дальнейшее моделирование и позволяет отказаться от сложного персонального Uplift. Теперь его можно рассчитать по формуле:

Δ(x,C,Pr) ≈ P(Z=1|At=1,C,x) * (P(Y_Pr=1|Z=1, At=1,C,x) - P(Y_Pr=1| At=0,x))

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

logit (P(Y_Pr=1|Z=q, At=1,C,x)) = logit (P(Y_Pr=1| At=0,x))+ δ_C,Pr

δ_C,Pr — добавка к логиту подключения от канала C для продукта Pr.

После этого значение снова переводится в обычную вероятность, а Expected Value рассчитывается через обновлённую формулу:

EV(x,C,Pr) ≈ P(Z=1|At=1,C,x) * [σ(logit (P(Y_Pr=1|At=0,x)) + δ_C,Pr) - P(Y_Pr=1|At=0,x)] * LTV(x, Y_Pr) - Cost(C)

Формула для сигмоиды (σ):

sigma(x)=\frac{1}{1+e^{-x}}

sigma(x) — результат функции (значение от 0 до 1);
e — математическая константа (число Эйлера, ≈2.71828);
x — входное число, например, результат линейного уравнения модели.

3. Разделили задачу на компоненты. После всех преобразований большая задача фактически распалась на три отдельные модели:

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

P(Y_Pr=1 | At=0,x)

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

P(Z=1 | At=1,C,x)

• Модель эффекта канала — оценивает, насколько канал способен увеличить вероятность подключения.

δ_C,Pr

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

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

💜 Этот пост написал Евгений Наговицын, ML-разработчик в Точка Банк