📢 IML уже завтра — вы идёте?

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

Лиза Афанасьева расскажет, как мы в Точке чистили текстовые корпуса для своей LLM и энкодеров:

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

В конце — метрики: сколько данных ушло после чистки и как это сказалось на качестве модели и затратах на обучение (спойлер: крайне положительно!).

→ Подробнее о докладе

Илларион Иов разберёт альтернативные методы оптимизации предпочтений:

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

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

→ Подробнее о докладе

От Точки будет целый стенд, так что приходите отдыхать между докладами и знакомиться!

Что такое и зачем нужна оптимизация обучения моделей?

Чаще всего оптимизация нужна для обучения моделей с нуля или дообучении крупной LLM. Она:

- Сокращает время экспериментов.
- Снижает затраты на вычисления.
- Работает даже на менее мощном железе.

Вот три ключевых области, которые могут требовать оптимизации:

📍 Избыточная точность для вычислений: иногда можно пожертвовать точностью, чтобы увеличить производительность. Например, использование 16-битных чисел (BF16) вместо 32-битных (FP32) для хранения параметров модели может дать хороший рост производительности.

📍 Избыточность вычислений: некоторые операции можно оптимизировать. Например, классическая реализация Scaled Dot-Product Attention вычисляет attention scores для маскированных токенов, что может быть излишним.

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

Что ещё важно?

Изучить своё железо, так как производительность зависит от GPU. Существуют разные архитектуры видеокарт NVIDIA: начиная с современных Blackwell, Ampere, Hopper до более старых Volta, Turing и Pascal. У каждой свои особенности и ограничения.

Раньше видеокарты использовали обычные CUDA-ядра. Они хороши для компьютерных игр, но не подходят для deep learning, где важна скорость операций. Поэтому современные GPU, начиная с Volta, имеют тензорные ядра, которые:

📌 Ускоряют матричные операции.
📌 Поддерживают специальные форматы чисел (например, TF32).
📌 Позволяют работать с низкой точностью (8, 6, 4 бита).

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

💜 Этот пост написал Макс Афанасьев, лидер DL-команд Точки, инженер-исследователь

Проблемы с качеством кода в ML-проектах — как с ними справиться?

В популярных ML-библиотеках часто бывают проблемы с качеством кода. В Transformers не прописаны тайпинги, Sklearn падает при большом количестве ядер, а в сурсы vLLM вообще страшно смотреть. Иногда это приправлено ещё и весьма специфичным синтаксисом, например, как у torch.einsum().

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

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

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

Так нужно ли качественно оформлять короткоживущий код?

Обычно проблему решают ведением двух репозиториев:

👾 Для экспериментов.
👾 Для продакшена, который потом интегрируется с бэкендом.

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

Как упростить работу с кодом?

Есть конструкторы для LLM (LangChain, LlamaIndex), которые упрощают работу с языковыми моделями, позволяя из готовых «кубиков» собрать работающую RAG-систему, и не только. Однако за простотой использования кроются проблемы, которые обязательно вылезут при масштабировании.

В чём минусы таких конструкторов, а также какой стек технологий должен знать современный ML-инженер, обсудили в подкасте «PiterPy и IML» с нашей Data-scientist Лизой Афанасьевой.

Смотрите полный выпуск на YouTube или в VK Видео.

Многие компании сёрвят LLM

Кто-то использует готовые инструменты, которые предоставляют OpenAI-compatible эндпоинты: например, DeepSeek, развёрнутый через vllm serve. Кому-то не хватает OpenAI-compatible протокола. А кому-то хочется и того, и другого — например, нам в Точке.

С одной стороны, мы хотим уметь ходить в LLM-провайдеры, которые поддерживают общепринятый формат. А с другой стороны у нас есть внутренняя LLM, которую нельзя полностью совместить с OpenAI-протоколом, потому что она поддерживает дополнительные виды контента внутри сообщений и ещё много других плюшек (про них тоже как-нибудь расскажем 👀).

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

Читайте, комментируйте и рассказывайте, как у вас дела с LLM!

Скучали? А мы-таки собрали пост про неэффективное использование вычислительных ресурсов ⬇️

Если вы хотите выжать максимум из своей GPU, нужно знать, как устроена видеокарта. Если совсем на пальцах, у неё есть:

📌 DRAM — большая, но медленная память. Расположена на отдельном чипе или чипах. В современных GPU объём может достигать 80 ГБ и больше.
📌 Streaming Multiprocessors (SM) — непосредственно вычислительные модули с CUDA и Tensor-ядрами. Позволяют запускать операции параллельно, распределяя пайплайны вычислений между собой.
📌 SRAM — быстрая, но маленькая память (обычно сотни Кб). Находится внутри вычислительных блоков.

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

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

Например, стандартная цепочка PyTorch-вызовов (без TorchDynamo) всегда будет работать так, что будет происходить перегонка байтиков туда-сюда: DRAM-SRAM-DRAM-SRAM-... .

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

📝 Для более тонкого контроля над памятью можно писать кастомные GPU-ядра: с нуля, используя библиотеки CUDA или с помощью Triton.

Что такое Triton? 🛠

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

Чем он хорош:

📍Код пишется на некотором сабсете Python, следовательно порог входа не такой высокий, а работает это дело через JIT-компиляцию.
📍Обеспечивает гибкий контроль над памятью и параллелизмом — мы сами решаем, когда ходить в DRAM, а когда не ходить, и имеем больше контроля над тем, как мы будем параллелить вычисления.

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

Как написать кернел?

Кернел — это функция с декоратором triton.jit. Их главная особенность — маленькие программки, которые могут быть запущены параллельно. Каждая запущенная копия будет иметь свой pid-идентификатор. Можно сделать так, чтобы каждый идентификатор обрабатывал не все данные, а отдельный фрагмент (вспоминаем, что SRAM-то маленький, а ещё нужно как-то уметь в параллелизм между блоками).

Пример кернела из официальной документации.

В кернеле мы используем:

👾 Указатели на входные и выходные данные.
👾 Размер вектора.
👾 Размер блока (Block Size) — количество элементов, которые обрабатываются одним PID-ом.
👾 PID — идентификатор запущенной программки.

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

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

💜 Этот пост написал Макс Афанасьев, лидер DL-команд Точки, инженер-исследователь

Такие разные типы данных

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

📌 Экспонента — определяет диапазон значений, которые можно представить, например от 10⁻⁴⁰ до 10⁴⁰.
📌 Мантисса — отвечает за представление значения числа без учёта его порядка. Чем больше бит выделено под мантиссу, тем более точно мы можем представить значение.

Например, у чисел 3,15*10^5 и 3,15*10^-5 экспоненты будут разные, но мантиссы — одинаковые.

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

Самые популярные типы данных сегодня:

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

Знак: 1 бит
Экспонента: 8 бит
Мантисса: 23 бита
Диапазон: ~10⁻³⁸ до 3*10³⁸
Точность: ~7 знаков


📍TF32
Не совсем обычный тип данных. Появился с архитектурой NVIDIA Ampere. В него нельзя напрямую закастить тензор, однако можно включить использование вычислений в TF32 для всех тензоров в FP32. Такие вычисления будут быстрее, но менее точными, но в 99% случаев их можно использовать без потери качества итоговой модели. TF32 не даст вам уменьшение потребления видеопамяти, но даст прирост скорости.

Знак: 1 бит
Экспонента: 8 бит
Мантисса: 23 бита (используется для вычислений 10 бит)
Диапазон: ~10⁻³⁸ до 3*10³⁸
Точность: ~3 знака

📍FP16
Поддерживается тензорными ядрами, но имеет меньший диапазон и меньшую точность. Поэтому в «голом» виде почти не используется, только с AMP — Automatic Mixed Precision.

Знак: 1 бит
Экспонента: 5 бит
Мантисса: 10 бит
Диапазон: ~6*10^⁻5 до 65 504
Точность: ~3 знака

📍BF16
Поддерживается тензорными ядрами, начиная с Ampere. Обеспечивает такой же диапазон, как FP32, но не такой точный, как FP16. Обычно используется с AMP, но в некоторых случаях можно и без него, если точности окажется достаточно (проводите эксперименты 🙂 ).

Знак: 1 бит
Экспонента: 8 бит
Мантисса: 7 бит
Диапазон: ~10⁻³⁸ до 3*10³⁸
Точность: ~2 знака

📍FP8
Самый новый тип данных. Поддерживается, начиная с архитектуры Hopper. Конфигурации для экспоненты и мантиссы могут различаться. Поэтому есть разные FP8: FP8_E5M2, FP8_E4M3. Точность маленькая, поэтому приходится использовать AMP.

Знак: 1 бит
Экспонента: 4/5 бит
Мантисса: 3/2 бита

Подведём итог: выбор типа данных влияет на итоговое качество модели, время её работы и объём занимаемой видеопамяти. FP32, TF32 и BF16 обычно показывают высокую эффективность и готовы к работе «из коробки».

💜 Этот пост написал Макс Афанасьев, лидер DL-команд Точки, инженер-исследователь

Что такое Restoration в компьютерном зрении?

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

У Restoration есть несколько характерных особенностей:

📌 Нехватка обучающих данных: собрать качественное GT очень сложно, поэтому важно извлекать максимум информации из минимального количества данных. Часто используют синтетику, но она не может полностью заменить реальные данные.

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

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

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

Restoration включает разные методики восстановления информации. Чаще всего работа идёт в трёх направлениях:

🔍 Super-resolution — увеличение разрешения. Используется, например, в компьютерных играх, телевизорах или для восстановления старых фильмов. На GitHub загружено больше 1300 репозиториев, посвящённых super-resolution.

🔍 Denoising — устранение шума. Для этого применяют разные методы: от классической свёртки Фурье до современных диффузионных моделей. Главная задача — отличить шум от реального сигнала.

🔍 Deblurring — устранение размытия с изображений и видео, например, из-за движения камеры на смартфоне. Алгоритмы деблюринга пытаются восстановить утерянные детали изображения с помощью предсказания движения по смазу.

💜 Этот пост написал Никита Алутис, ML-разработчик в Точке

Как и обещали, рассказываем про архитектуры для задачи Restoration 👾

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

📌 UNet

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

📌 NAFNet

Более современный вариант, представленный в 2022 году. Адаптирует подходы обучения трансформеров для свёрточных сетей. Авторы NAFNet показали, что убирая активации и нелинейности, можно достичь результатов, сопоставимых с трансформерами, но с существенно меньшими вычислительными затратами — до 1/8 от обычных ресурсов.

На сегодняшний день в задачах restoration чаще всего применяют:

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

📝 GAN (генеративно-дискриминативные сети) — подходят для задач ресторейшена, так как способны восстанавливать текстуры и структуры объектов с высокой степенью точности.

📝 Диффузию — восстанавливает переход между распределениями изображений при работе с шумными или неполными данными.

💜 Этот пост написал Никита Алутис, ML-разработчик в Точке

Популярные SOTA-модели для суперразрешения

📍 Upscale-A-Video — модель для восстановления видео с низким разрешением, основанная на диффузии.

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

Что интересно:

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

📚 Rotary Position Embedding использует вращательные матрицы для кодирования относительных позиций элементов в последовательности, что позволяет лучше учитывать временные зависимости.

📍 VideoGigaGan — SOTA-модель для видео суперразрешения, в которой ключевую роль играет функция потерь.

Архитектура: традиционный трансформер с UNet-подобным декодером. Важным аспектом является использование temporal attention, который позволяет передавать карты внимания между соседними кадрами. Это уменьшает размер модели и повышает её эффективность.

Что интересно:

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

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

Где взять данные для обучения моделей?

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

Процесс включает:

📌 Размытие из-за микродвижений.
📌 Уменьшение разрешения изображения.
📌 Добавление шума, характерного для камер при нормальном освещении.
📌 JPEG-сжатие, которое широко используется в современных устройствах.

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

💜 Этот пост написал Никита Алутис, ML-разработчик в Точке

Встретимся на PyCon Russia 25-26 июля?

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

📚 Airflow в коммунальном ML: от боли к эффективному использованию — Владимир Пузаков, MLOps

Как сделать так, чтобы было можно использовать инстанс Аirflow, развёрнутый в Kubernetes, в качестве оркестратора ML-пайплайнов, причём сразу несколькими командами, которые не мешают и даже помогают друг другу?

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

Доклад будет полезен не только MLOps, которые отвечают за ML-инфраструктуру, но и тем, кто использует Аirflow для написания пайплайнов.

📚 Как обучение со слабым контролем помогло тегировать клиентские обращения — Артур Сосновиков, тимлид ML-команд

Ручная разметка данных остаётся узким местом в ML-проектах — она дорогая, медленная и плохо масштабируется. Вместо использования GPT напрямую для классификации, мы используем его для генерации и итеративного улучшения правил разметки на основе ошибок модели.

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

В кейсе с классификацией клиентских обращений в поддержку Точки этот подход обошёл и zero-shot GPT-4, и классическое обучение на размеченных данных — при меньших затратах и лучшей масштабируемости.

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

В предыдущих постах мы рассказывали о Restoration в CV, и популярных SOTA-моделях. Пришло время сделать выводы:

📝 Loss под задачу, не задача под loss

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

Совет: Loss-функция позволяет тонко настроить результат работы сети. Добавление небольших компонентов к loss может существенно повлиять на выходные данные модели. Для этого не обязательно начинать обучение с нуля — можно использовать новый loss на этапе fine-tuning для улучшения результата.

📝 Аккуратный переход к реальным данным

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

📝 Метрики — не истина в последней инстанции

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

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

💜 Этот пост написал Никита Алутис, ML-разработчик в Точке

Часть 1: Как обучить модель, когда много данных и мало разметки?

В трёх постах покажем, как в Точке мы искали рабочий способ классифицировать обращения клиентов: от экспериментов с «шумной» разметкой и GPT до подхода с Weak Supervision и Snorkel, который дал высокую точность и снизил затраты.

Каждый месяц мы в Точка Банк получаем больше 500 000 обращений от клиентов. При этом важно понимать, с чем именно они приходят в поддержку. Поэтому мы тэгируем каждое обращение, например, #Тариф, #Счёт, #ОнлайнБухгалтерия — всего больше 50 тэгов.

Это помогает:

📌 Правильно разносить затраты поддержки на продукты.
📌 Оперативно решать проблемы.
📌 Держать руку на пульсе и понимать, что беспокоит клиентов.

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

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

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

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

📝 Супер эксперты (бизнес-юнионы): связывают клиента и продукт. Хорошо разбираются в своей теме, но могут разметить не более 200 сессий в месяц. А ещё их мало — по одному на каждую тематику.
📝 AI-тренеры: операторы службы поддержки. Хорошо знают все темы, умеют разделять теги, но их точность около 80%.
📝 Внешние асессоры на ГПХ: не обладают экспертизой в клиентской поддержке, но зато их можно нанять много.

В такой ситуации получить качественную разметку в большом объёме невозможно.

👾 Наш эксперимент

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

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

О том, как мы составляли золотую выборку, расскажем в следующем посте.

Часть 2: Как обучить модель, когда много данных и мало разметки?

Это история о том, как мы Точке классифицируем клиентские обращения

Модель для онлайн-разметки показала невысокую точность — всего 80%. Поэтому мы решили добыть золотую разметку и попросили супер экспертов разметить 2000 объектов. Задачу поставили в бинарном сетапе, то есть, использовали только два тега #Тариф и #ВсёОстальное.

Чтобы получить больше разметки, попросили экспертов объяснить, как они определяют, к какому тэгу относится обращение. Затем на основе их ответов написали инструкцию-промпт для GPT.

На dev-выборке в 1000 объектов получили такие метрики few-shot:

📌 Precision — 68%
📌 Recall — 89%
📌 F1 — 0,77

Получается, что тэг #Тариф мы определяли правильно лишь в 68% случаев. А 11% вообще не попали под нашу классификацию.

Тогда мы решили взять ризонинг-модель и использовать её рассуждения. Это дало незначительный прирост качества +2% к F1.

Какие выводы мы в итоге сделали:

📝 Не получается подобрать инструкцию, чтобы определять метку с высокой точностью.
📝 Сложно масштабироваться на новые теги.
📝 Есть трудности с маскирацией персональных данных.
📝 Высокая стоимость — для GPT-4о от 2000$ в месяц даже без сложных цепочек ризонинга.

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

Часть 3: Как обучить модель, когда много данных и мало разметки?

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

Тестовая dev-выборка показала низкую точность и высокую полноту. Тогда мы решили использовать комбинированный подход: LLM + Weak Supervision.

Что такое Weak Supervision?

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

Самый простой способ — голосование большинством. Но у этого метода есть минусы:

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

Поэтому в качестве итогового классификатора мы использовали Snorkel.

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

В результате эксперимента мы получили:

📍Высокую точность.
📍Прежний уровень recall.

Таким образом, благодаря этому подходу мы:

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

💜 Серию постов написал Артур Сосновиков, тимлид нескольких ML-команд в Точка Банк.

Почему LLM без Alignment — это риск?

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

📌 выдавать логически неверные ответы,
📌 генерировать небезопасный контент,
📌 игнорировать бизнес-ограничения.

Что такое Alignment? Это дообучение с учётом предпочтений и ограничений, которое делает модель предсказуемой и управляемой.
Написали статью на Хабр, в которой разбираем:

📝 Методы Alignment: от PPO (Proximal Policy Optimization) до новых подходов DPO и KTO.
📝 Наш опыт: как мы в Точка Банк настроили LLM под конкретные сценарии, обучили модель наград и сократили затраты по сравнению с классическим RLHF.
📝 Грабли и лайфхаки: как работать с несбалансированным датасетом и не дать модели обмануть функцию награды.
📝 Где применять Alignment за пределами LLM: от cost-sensitive классификации до vision-language моделей.

Точно будет полезно, если строите собственную LLM — читайте и задавайте вопросы в комментариях!

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

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

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

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

📌 Горизонтальное федеративное обучение (HFL)

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

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

📌 Вертикальное федеративное обучение (VFL)

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

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

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

💜 Этот пост написал Сергей Станко, ML-инженер в Точка Банк.

Большинство советов по ускорению Pandas звучат одинаково: «уберите циклы», «используйте apply», «снижайте размер типов». Но правда в том, что в реальном проекте эти правила работают не всегда — иногда даже замедляют пайплайн и увеличивают потребление памяти.

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

👾 Iterrows vs itertuples: почему официальная рекомендация из документации pandas может привести к Out of Memory и замедлению пайплайна.
👾 apply с raw=True: малоизвестный аргумент, который даёт почти тот же прирост, что NumPy-векторизация — без полного переписывания кода.
👾 merge → loc или reindex: правда ли merge — швейцарский нож в мире датафреймов?
👾 Типы данных: int8 vs int64, float32 vs float64, categorical и sparse — что реально экономит ресурсы, а что даёт мизерный эффект.
👾 Параллелизация: pandarallel и multiprocessing — какой инструмент выбрать и почему (или не выбирать ни один).

Если вы работаете с большими объёмами данных на Pandas, наша статья поможет избавиться от «оптимизаций ради оптимизаций».