Что мы поняли о роли AI/ML в защите данных за последний год?

Сегодня, на Positive Security Day состоится долгожданный коммерческий релиз PT Data Security — продукта для защиты корпоративных данных, независимо от их типа и места хранения.
Наша команда разрабатывала одну из ключевых фич - ML-модуль классификации данных. Прошли путь с нуля — от идеи и конкурентного анализа до интеграции в продукт и оптимизации инференса.

Поэтому делимся нашим взглядом на роль AI/ML в классификации данных:

⚡️1. Метаданные ≠ данные

Мы провели конкурентный анализ и поняли, что большинство решений на рынке анализируют только метаданные — названия файлов/колонок/таблиц, расширения и описания к объектам.
Но в реальных компаниях данные часто выглядит так: “новый документ финал.docx” или "column123"

Так что “аналитика по названиям” быстро разбивается о реальность корпоративного хаоса.

⚡️2. Реальность рушит простые гипотезы

Мы собрали валидационную выборку, имитирующую корпоративные данные, и прогнали по ней несколько вендоров и open-source решений.
Результат: полнота <= 40% у regex-пайплайнов.
Регулярки просто не видят такие сущности, как имена, организации, телефоны, даты и многие другие — особенно в естественном тексте.

⚡️3. Значит, идем глубже — в контент

С первых итераций мы сделали ставку на анализ содержимого.
Для прототипов использовали Microsoft Presidio — удобный фреймворк, который позволил без интеграции в продукт опробовать наши ML-модели на сценарии защиты данных (но производительность фреймворка не позволяет использовать его в production).

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

⚡️4. Идеальный баланс: ML + регулярки

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

⚡️5. А LLM?

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

LLM имеют потенциал в качестве копайлотов для ИБ-специалиста, но не станут ядром системы, которая должна работать на масштабе и в реальном времени.

---

Поздравляем команду продукта в релизом и уходим готовить новые фичи, которые позволят еще надежнее защитить компании от утечек!


____________________________________

Вадим Безбородов, ML-инженер AppSec
Максим Митрофанов, ML-лид AppSec

Один из способов ускорить инференс LLM — это использовать спекулятивное декодирование (Speculative Decoding), чтобы оптимизировать генерацию ответа. Маленькая модель генерирует черновые токены, а большая — их валидирует. Причём чем длиннее принятый фрагмент, тем больше прирост к скорости работы.

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

В эту пятницу специалист ML-команды Екатерина Синькова разберёт статью «TETRIS: Optimal Draft Token Selection for Batch Speculative Decoding». Ее авторы предлагают способ динамически выбирать число генерируемых черновых токенов на основе батча запросов, чтобы максимизировать число принятых токенов.

Катя расскажет:
🛑как работает спекулятивное декодирование,
🛑как авторы «TETRIS» обошли проблему фиксированного чернового окна,
🛑как размер батча и запросы в нём влияют на количество генерируемых черновых токенов,
🛑как это влияет на инференс LLM на практике.

📅 Ждём всех в Толке в пятницу, 17 октября, в 15:00 (GMT+3).
🔗 Ссылка для подключения: Ктолк

#reading_group #llm #deployment

Мы начинаем🎃