Grab: LLM-классификация данных — 20 000+ сущностей за первый месяц и 360 человеко-дней экономии в год

• LLM-powered data classification for data entities at scale — Grab Engineering Blog (Caspian & Data Governance), 2023-10
• Metasense V2: Enhancing, improving and productionisation of LLM powered data governance — Grab Engineering Blog (Buhrer, Parbat, Zeng), 2024-11-14
• Grab: LLM-Powered Data Classification System for Enterprise-Scale Metadata Generation (сторонний разбор) — ZenML LLMOps Database

Контекст

Grab — ведущий суперапп Юго-Восточной Азии: райдшеринг, доставка еды и финансовые сервисы в одном приложении. Суперапп-модель означает суперапп-данные: компания управляет ландшафтом петабайтного масштаба — бесчисленными таблицами баз данных и схемами сообщений Kafka, которые непрерывно создаются и меняются десятками продуктовых команд.

Для соблюдения требований регуляторов и внутренних политик каждую сущность данных нужно классифицировать по чувствительности: содержит ли она персональные данные, к какому уровню конфиденциальности относится. Это не бюрократическая формальность, а фундамент всей системы защиты: по тегам чувствительности в Grab определяется уровень доступа к таблице, работают политики атрибутного контроля доступа (ABAC) и динамическое маскирование данных в запросах. Неразмеченная или неверно размеченная таблица — это либо дыра в защите персональных данных, либо избыточные ограничения, мешающие командам работать.

Задачу решали команды Caspian (data engineering) и Data Governance. В октябре 2023 года они описали в инженерном блоге, как перевели классификацию данных с ручного процесса на LLM — став одним из первых публичных кейсов применения генеративных моделей в data governance. Характерная деталь: оркестрационный сервис, через который LLM встроена в платформы данных, называется Gemini — и не имеет отношения к одноимённой модели Google, пост вышел до её анонса. В ноябре 2024 года команда опубликовала продолжение — Metasense V2 — о доработке системы до покрытия всего дата-лейка, что делает этот кейс редким примером задокументированной эволюции LLM-системы через два поколения.

Проблема

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

Альтернативы у команды были неидеальные. Жёсткие эвристики (регулярные выражения по именам колонок) не понимают семантику: колонка user_note может содержать что угодно — от технического комментария до адреса и телефона. Сторонний сервис классификации, который команда оценивала параллельно с LLM, требовал заранее заданных правил и плохо понимал смысл колонок в контексте бизнеса Grab. Обучать собственную ML-модель — значит сначала собрать большой размеченный датасет, то есть решить ту же задачу разметки, только ещё и с ML-инфраструктурой в придачу.

Генеративные модели предложили третий путь: у LLM достаточно «общих знаний», чтобы по именам и описаниям колонок понять, что перед ней — телефон, адрес или идентификатор устройства, а требования к классификации можно выразить обычным текстом промпта — без кода и без обучения моделей. Но за этот путь пришлось платить инженерными ограничениями: контекст GPT-3.5 всего 4000 токенов (примерно 3000 слов), а квота Azure OpenAI — 240 тысяч токенов в минуту на все деплойменты компании сразу.

Решение

Команда встроила GPT-3.5 в Gemini — оркестрационный сервис, который принимает запросы на классификацию от платформ данных. Архитектура сделана под квоты и масштаб: запросы агрегируются в очереди сообщений, на уровне воркфлоу работает rate limiter, удерживающий поток в пределах лимита Azure OpenAI (240K токенов в минуту), а метаданные сущности — имена и описания колонок — упаковываются в промпт с учётом контекста в 4000 токенов; слишком широкие таблицы обрабатываются частями. Параллельно с LLM в период оценки работал сторонний классификатор — прямое сравнение движков на одном потоке данных.

Качество вытянули инженерией промптов, без обучения кастомных моделей: чёткая формулировка требований к каждому тегу, few-shot-примеры, приведение вывода к жёсткой схеме через DTO-определения и — важная деталь — дефолтный тег <None> для случаев неуверенности, чтобы модель не «натягивала» сомнительные классификации. Итоговую точность команда охарактеризовала как «на удивление высокую». Результаты уходят через Kafka обратно в платформы данных, а владельцы данных получают еженедельные уведомления для верификации: подтвердить или поправить предложенные теги. Человек остался в контуре, но его роль сменилась с разметчика на валидатора.

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

Второе поколение системы — Metasense V2 (ноябрь 2024) — доработало слабые места, найденные на живом трафике: модель путалась на больших смешанных выборках, где персональные данные прятались среди неперсональных (рабочие письма с именами, вложенные JSON, переписка пассажиров). Решения показательны своей простотой: одну модель разделили на две — отдельно PII-теги, отдельно остальные; число тегов в PII-части сократили с 21 до 8; промпт ужали с 1254 до 737 слов; таблицы шире 150 колонок стали резать на части. Для быстрых экспериментов с промптами команда перешла на LangChain и LangSmith, а на случай деградации качества настроила автоматические алерты по порогам мисклассификации.

Результат

За первый месяц после запуска система просканировала более 20 000 сущностей данных — в среднем 300–400 в день, темп, физически недостижимый для ручного процесса. В опросе в сентябре 2023 года 80% владельцев данных ответили, что новый процесс помогает им в тегировании, а для подтверждённых таблиц пользователи правили в среднем меньше одного тега — то есть подавляющее большинство предложений модели принималось без изменений. Из расчёта двух минут ручной классификации на сущность автоматизация экономит примерно 360 человеко-дней в год. К версии V2 система покрыла весь дата-лейк Grab с, по формулировке команды, «исключительно низким» уровнем мисклассификаций — впрочем, точные проценты компания не публикует, и все цифры кейса являются самоотчётом без внешнего аудита.

На наш взгляд, этот кейс — образец трезвого выбора задачи для LLM. Классификация метаданных — сценарий, где генеративная модель почти идеальна: вход компактный (имена и описания колонок), выход структурированный (теги из фиксированной таксономии), цена единичной ошибки ограничена (человек-валидатор и еженедельные уведомления), а альтернатива — не «другая модель», а тысячи часов ручного труда. При этом экономика посчитана консервативно и понятно: 2 минуты × 20 000+ сущностей в месяц — арифметика, которую примет любой финдиректор, в отличие от абстрактных «процентов продуктивности».

Второе наше наблюдение: history V1→V2 честно показывает, что LLM-система — не «настроил и забыл». Первая версия, «на удивление точная» в 2023-м, на живом трафике накопила список слабых мест, и лечились они не более мощной моделью, а декомпозицией задачи, сокращением промпта вдвое и наблюдаемостью (LangSmith, алерты по порогам). Это, пожалуй, самый переносимый урок кейса: в продакшен-LLM-системах инженерия вокруг модели — оркестрация, квоты, схемы вывода, версионирование промптов, мониторинг — значит больше, чем выбор самой модели.

Уроки для индустрии

1. Data governance — недооценённый сценарий для LLM: классификация чувствительности по метаданным не потребовала кастомных моделей — хватило GPT-3.5 и инженерии промптов.
2. Считайте эффект в человеко-днях: 2 минуты на сущность × 20 000+ сущностей в месяц = ~360 человеко-дней в год — понятная руководству арифметика.
3. Человек остаётся в контуре как валидатор: владельцы данных подтверждают теги, и метрика «меньше одной правки на таблицу» показывает зрелость системы.
4. Проектируйте под квоты API с первого дня: лимиты Azure OpenAI (240K токенов/мин) и контекст 4K токенов — жёсткие ограничения архитектуры, а не мелкий шрифт; отсюда очереди и rate limiter в Gemini.
5. Дайте модели право сказать «не знаю»: дефолтный тег <None> для неуверенных случаев защищает от натянутых классификаций лучше, чем принуждение к ответу.
6. Версионируйте промпты как код: аналитические пайплайны оценки каждой версии промпта плюс LangSmith в V2 — основа управляемой эволюции LLM-системы.
7. LLM-система требует второй итерации: V2 лечила реальные слабости V1 декомпозицией задачи (PII/непII), сокращением промпта с 1254 до 737 слов и алертами мисклассификации — а не более мощной моделью.

Частые вопросы