.ml

Эволюция Attention: S4 и работа с длинным контекстом Продолжаем серию постов про путь линейного внимания. После RWKV стало понятно: чтобы уйти от дорогого Attention, память должна уметь работать с длинным контекстом. Нужно не просто хранить информацию, а обновлять её во времени. 📌 Параллельно с RWKV развивалась архитектура State Space Models (SSM) Изначально SSM пришла из физики и математики — там использовали такие модели, чтобы описывать системы с памятью. x'(t) = Ax(t) + Bu(t) y(t) = Cx(t) + Du(t) Что происходит внутри: Входной сигнал преобразуется → смешивается с текущим состоянием (памятью) → состояние обновляется → из него формируется выход. То есть память становится не просто суммой прошлого, а динамическим состоянием. Так как язык — это дискретная последовательность, в SSM добавили параметр Δ. Он отвечает за «шаг времени» между токенами: то, как сильно должна измениться память при переходе от одного токена к другому. 🎨🎨🎨🎨🎨🎨🎨 🎨🎨🎨🎨🎨🎨🎨 📌 Одной из первых успешных реализаций SSM стала архитектура S4 В ней внесли два важных изменения: • Специальная инициализация матрицы A (HIPPO): позволила модели лучше удерживать длинный контекст и не забывать информацию. • Параллельные вычисления через свёртки: чтобы не считать состояние для каждого токена по очереди (как в RNN). Такая модель могла работать с длинными последовательностями, но ей всё ещё не хватало гибкости: каждый входной токен модель обрабатывала одинаково. Как получилось исправить этот недочёт — расскажем в следующем посте. 💜 Этот пост написал Владислав Попов, 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 один раз обучает модель и один раз калибрует порог. После этого для новых объектов он использует уже готовую модель и готовую калибровку, поэтому работает намного быстрее. 💜 Этот пост написал Виталий Прахов, дата-сайентист в Точка Банк

Эволюция Attention: переход к линейным моделям Это продолжение серии постов про путь линейного Attention. В прошлый раз мы выяснили, что трансформеры имеют квадратичную сложность, из-за чего плохо масштабируются на длинные последовательности и требуют много памяти. 📌 Linear Attention впервые поменял подход к вычислению. Он позволил разложить kernel-функцию и вместо exp(QKᵀ) использовать φ(Q) · φ(K). Благодаря этому получилось: • перегруппировать вычисления; • сначала посчитать K · V; • потом применить Q. Но главное: сложность стала линейной по длине последовательности (вместо квадратичной). Модель работала быстрее и экономнее по памяти, но вместе с этим теряла точность. Обычный Attention хранит токены по отдельности, а линейный — складывает информацию в общую «сводку» контекста. Благодаря этому модель хорошо понимает общий смысл, но плохо запоминает детали. Встала задача: сохранить эффективность линейного Attention, но вернуть локальный контекст. 📌 Эту проблему частично решила RWKV-архитектура. Она не отказалась от идеи компактной памяти, но добавила механизмы, которые делают её более чувствительной к текущему контексту: • Token shift Вместо того чтобы рассматривать токен изолированно, модель смешивает его с предыдущим состоянием. Поэтому каждый новый шаг содержит информацию о ближайшем контексте. • Управление памятью Память в RWKV не просто накапливается. На каждом шаге часть старой информации забывается, а новая — добавляется. Если ничего не забывать, память быстро превратится в шум. А если забывать слишком агрессивно — потеряется контекст. Модель учится сама находить баланс между крайностями. • Гейт при извлечении Когда нужно достать информацию из памяти, используется гейт. Он работает как фильтр: смотрит на текущий токен и решает, какие части памяти сейчас важны, а какие можно игнорировать. RWKV стала своеобразным гибридом предыдущих идей. Она не сделала модель такой же точной, как классический Attention, но при этом вернула локальный контекст. Параллельно с ней развивались другие архитектуры — SSM и Mamba. Подробнее о них расскажем в следующих постах. 💜 Этот пост написал Владислав Попов, ML-инженер в Точка Банк

Мы на AHA’26 и в AI Talent HUB Лиза Афанасьева выступит на AHA’26 с докладом про данные для обучения LLM: Мы обучили Qwen 235B так, что на наших задачах модель работает на уровне GPT-4.1, при этом существенно снижая затраты компании. В докладе расскажу, как мы готовим и фильтруем данные для обучения inhouse LLM, какие пайплайны используем на разных этапах и какие ошибки успели собрать по пути. В результате слушатели получат практический рецепт, который поможет дообучить open-source LLM под свою задачу с упором на главное — качественные данные. Влад Попов в AI Talent HUB расскажет, как чинить ретривы без покупки нового железа: Мы долго работали над улучшением ретривы: тестирование различных архитектур, построение бенчмарков, поиск и создание качественных данных. Теперь готов рассказать, почему ретривы со временем перестают работать, как правильно измерять их качество и какие подходы реально улучшают выдачу без усложнения пайплайна. Это будет разбор нашего кейса из продакшена с минимумом теории — так поймёте, что стоит делать, а что не имеет смысла. Будем рады ответить на ваши вопросы, приходите!

Эволюция 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-инженер в Точка Банк

Верите ли в надёжный 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-модели, нейросети и кастомные пайплайны. 💜 Этот пост написал Виталий Прахов, дата-сайентист в Точка Банк

Блайндбоксы в мире 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: как мы разработали и внедрили микросервис 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-процесса, которым пользуемся в команде ML Core Возможно, с шаблоном вам будет проще начать собирать док: 1) Составить схему основных этапов разработки, принятых в вашей команде, например: • постановка задачи; • исследование данных; • формулировка задачи в ML-терминах; • MVP-решение; • тестирование решения; • выкатка в прод; • мониторинг. 2) Описать каждый этап: • что нужно сделать; • как должен выглядеть результат для перехода к следующему шагу. Старайтесь избегать лонгридов — используйте схемы, таблицы, инфографику. 3) Добавить к каждому этапу: • шаблоны, которые позволят быстрее выполнить этот этап; • полезные советы; • стандарты и требования, если они есть; • ссылки на ресурсы, статьи, документы, которые могут помочь на этом этапе; • ответы на популярные вопросы; • требования к документации — что и где нужно описать, чтобы считать этап пройденным. После сборки ML-процесса не забудьте запросить обратную связь от коллег, которые не участвовали в его разработке. А ещё сообщить всем заинтересованным о появлении нового полезного инструмента. И помните, что ML-процесс нельзя написать один раз. Принятые в компании практики меняются, появляются новые инструменты на замену или в дополнение к старым, обновляются версии. Важно регулярно поддерживать актуальность вашего ML-процесса, менять его под новые потребности. Не вы подстраиваетесь под процесс, а он подстраивается под вас! 💜 Этот пост написала Светлана Астафьева, ML-разработчик в Точка Банк

Нужен ли вашей команде ML-процесс? Возникают ли у вас как у руководителя или специалиста ML-команды эти вопросы? • Как помочь новичкам быстрее вкатиться в процессы, принятые в команде? • Как объединить все инструкции, стандарты, правила, рекомендации, полезные и опасные практики так, чтобы их хоть кто-то прочитал? • Можно ли сделать так, чтобы в проектах разных команд появилось единообразие, и не задушнить правилами? • Как поделиться результатами работы с другой командой без лишних вопросов? Если да, то этот пост для вас. А ещё это значит, что вашей команде нужен ML-процесс. ML-процесс — это мета-инструкция, которая становится «точкой входа» для поиска ответов на вопросы по разработке проекта. Он обладает такими свойствами: • Содержит все необходимые для разработки ссылки на ресурсы. • Объясняет, как делать надо и как не надо. • Имеет структуру, которая повторяет процесс разработки с исчерпывающим и актуальным описанием всех этапов. • Становится основой для создания будущей документации по проекту • Подходит для 95% процессов. • Упрощает жизнь, а не задаёт рамки. ML-процесс не должен и не может быть написан одним человеком, иначе никто не будет им пользоваться. Стоит собрать рабочую группу из разных команд и создать решение, которое будет полезно и понятно всем. Что вы получите, если поработаете над ML-процессом: • Увидите «белые пятна» в разработке, напишите новые инструкции, которых не хватало. • Соберёте в одном месте навигатор по всем ресурсам, инструментам и инструкциям, принятым в вашей команде. • Облегчите онбординг новичков в вашей команде, передачу проектов коллегам, понимание результатов руководителю. • Сократите время на разработку проекта. В следующем посте дадим шаблон ML-процесса, по которому мы собираем документацию по проектам. 💜 Этот пост написала Светлана Астафьева, ML-разработчик в Точка Банк