VTORNIK.Вечер #11: саммари выступлений

На прошлой неделе провели 11-ый VTORNIK.Вечер — бесплатное оффлайн мероприятие о внедрении AI в организациях. На мероприятии присутствовали руководители компаний и подразделений, тимлиды, AI-leaders, аналитики, ML-инженеры и разработчики. В программе традиционно было два доклада.

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

Команда Сергея разрабатывает платформу поиска и рекомендаций для порядка десяти сервисов экосистемы МТС, включая KION и «Строки». Платформа предоставляет общие инструменты рекомендательным командам и позволяет быстро запускать end-to-end рекомендательные сценарии.

Как устроены современные рекомендации
Типичный рекомендательный пайплайн включает генерацию кандидатов, ранжирование и применение бизнес-правил. Из миллионов объектов система сначала отбирает несколько сотен или тысяч потенциально интересных пользователю, затем определяет порядок их показа. Весь процесс обычно должен укладываться в 200–300 миллисекунд. Трансформеры уже активно используются в рекомендациях для анализа последовательности действий пользователя. При этом, как отметил Сергей, чаще всего речь идет не о больших языковых моделях, а о значительно меньших трансформерах, которые хорошо справляются с этими задачами.

Что ограничивает использование LLM
Сергей выделил пять основных ограничений: задержка ответа (latency), пропускная способность (RPS), стоимость, безопасность и надежность. Если классические рекомендации работают за сотни миллисекунд, то LLM обычно требуются секунды. Кроме того, их использование в высоконагруженных системах требует значительных вычислительных ресурсов.

Где LLM могут применяться
Спикер рассмотрел несколько сценариев и дал каждому свою оценку применимости по десятибалльной шкале.
Обогащение данных — 9/10. Один из наиболее эффективных сценариев. LLM используются для обработки описаний объектов, выделения атрибутов, категоризации и генерации тегов. Все это выполняется в офлайн-контуре, а полученные данные используются классическими рекомендательными алгоритмами. В экспериментах команды даже относительно небольшие языковые модели обеспечивали значительную часть качества более крупных моделей.
Генерация кандидатов — 6/10. LLM могут формировать потенциальные рекомендации и помогать выходить за пределы привычных интересов пользователя. Сергей рассмотрел подход Spotify, при котором языковая модель генерирует гипотезы и персональные подборки, передаваемые затем в обычную рекомендательную систему. Результаты экспериментов оказались неоднозначными: наряду с существенными улучшениями были и отрицательные результаты.
Ранжирование — 2/10. Пока LLM в этой роли чаще встречаются в исследованиях. Сергей привел эксперимент Netflix, где применение LLM-ранкера дало небольшой положительный результат, но потребовало сложной доработки модели и инференса. По оценке спикера, практическое применение такого подхода пока ограничено, хотя потенциал существует.
Объяснение рекомендаций — 6/10. LLM могут формировать понятные пользователю объяснения, почему ему предложен определенный контент. При этом объяснение не обязательно отражает реальные причины выбора рекомендательного алгоритма. Подход работает технически, но не всегда оправдан с продуктовой точки зрения.
Оценка качества рекомендаций — 3/10. В отличие от поиска, использование LLM as a judge в рекомендациях пока показывает слабые результаты. Основная проблема — отсутствие обратной связи по объектам, которые пользователь еще не видел. В экспериментах команды корреляция оценок LLM с обычными метриками качества оказалась слабой.
Разговорные сценарии — 9/10. Одно из наиболее перспективных направлений. LLM позволяют обрабатывать сложные и абстрактные запросы, уточнять текущие интересы пользователя и передавать полученную информацию классическим алгоритмам. Например, пользователь может описать свое настроение, а система — уточнить предпочтения и подобрать соответствующий контент.

AI-инструменты для рекомендательных команд
Отдельно Сергей рассказал об использовании LLM во внутренних инструментах. Команда экспериментировала с автоматическим анализом A/B-тестов и генерацией гипотез о причинах результатов. Пока эксперимент не принес ожидаемой пользы: модель предлагала слишком тривиальные гипотезы, поэтому дальнейшую работу над этим сценарием приостановили.

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

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

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

Data Governance как основа защиты информации
Инструменты Data Governance позволяют связать данные с их бизнес-контекстом. Каталог данных должен содержать не только информацию о расположении объектов, но и их классификацию, владельцев и происхождение (data lineage).
При этом владельцем данных, по мнению Константина, должен быть не технический специалист, обслуживающий систему, а владелец продукта, понимающий ценность информации и контекст ее использования. Такой подход позволяет быстрее оценивать последствия инцидентов безопасности. Например, при компрометации учетной записи сотрудника можно определить, к каким чувствительным данным он имел доступ, какие системы и бизнес-процессы потенциально затронуты.

От управления ролями к политикам доступа
Традиционная ролевая модель доступа (RBAC) плохо масштабируется в сложных системах хранения данных. Чем подробнее разграничиваются права на уровне схем, таблиц, колонок и строк, тем сложнее становится процесс согласования.
Вместо этого Константин предлагает строить безопасность вокруг единой политики использования информационного актива, учитывающей четыре составляющие: Identity × Data × Context × Policy.

При принятии решения важно понимать, кто обращается к данным, какие именно данные запрашивает, с какой целью и какое действие собирается выполнить.
Например, один и тот же SQL-запрос к таблице заказов может требовать разных мер безопасности в зависимости от сценария: расследование мошенничества, бизнес-аналитика или использование данных через API. В одном случае допустим временный доступ к полным данным, в другом необходимы маскирование, агрегация или ограничение экспорта. При этом единая политика не требует единой технической точки доступа: контроль может выполняться непосредственно в базах данных, BI-системах и API.

Как отслеживать изменение рисков
Еще одна задача — контролировать изменения в потоках данных. Например, если к BI-витрине, ранее не содержавшей чувствительной информации, подключается новая таблица с персональными данными, должна автоматически пересматриваться политика доступа. Для этого используются информация о происхождении данных (lineage), каталогизация и мониторинг фактических обращений к информационным активам. Если появляется неописанный поток данных или новый потребитель за пределами разрешенного контекста, такое расхождение может становиться событием безопасности и передаваться в процесс Vulnerability Management.

Безопасность ИИ начинается с данных
Отдельно Константин остановился на безопасности ИИ-систем. По его словам, недостаточно проверять языковые модели на уязвимости с помощью промпт-инъекций и red teaming. Необходимо также понимать, какие данные использовались при обучении модели, какие документы доступны через RAG и с какими правами ИИ-агенты обращаются к внешним инструментам. Каталоги и классификация данных позволяют учитывать эти риски. При этом спикер считает, что простые запреты на использование ИИ не работают. Если небезопасный инструмент удобнее разрешенного, сотрудники найдут способ им воспользоваться. Вместо запретов необходимо развивать средства контроля: AI gateway, guardrails, единую авторизацию и логирование, отслеживание обращений моделей к данным и сервисам. Особенно внимательно, по мнению Константина, нужно относиться к сценариям, в которых ИИ с недетерминированным результатом получает возможность напрямую вызывать API, принимающие критичные бизнес-решения.

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

Константин также рассказал об опыте внедрения таких подходов. Вместо попытки сразу описать все данные вплоть до отдельных атрибутов команда начала с каталогизации на уровне объектов. По его словам, работа с первыми 10–20 продуктами позволила выявить и устранить ряд устаревших объектов и процессов.
Важную роль играет и взаимодействие с другими подразделениями безопасности, прежде всего SOC и командами, отвечающими за SIEM. Задача направления Data Security — определить и описать события безопасности, которые затем могут отслеживаться в масштабах компании.

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

Отдельная благодарность нашим партнерам ГК «Солар» за возможность проводить митапы в их красивом и гостеприимном офисе.

Если вы хотите провести образовательную программу в своей компании или получить консультацию наших экспертов, пожалуйста, пишите на info@vtornik.company.