Как мы описываем тысячи таблиц с помощью LLM

Меня зовут Сергей Третьяков. Я product owner MWS Data Scout ^[1] — сервиса, который описывает таблицы баз данных с помощью больших языковых моделей (LLM). 

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

Проблемы описания таблиц

MWS Data Scout начался с одного эксперимента. Мы взяли систему Resource Inventory и поручили семи сотрудникам вручную описать её витрины.

Результат за три месяца: 310 витрин.

Скорость: около двух таблиц в день на одного человека.

Затраты времени: до шести часов на одну таблицу.

Такие большие затраты времени обусловлены сложностью поиска ответов на вопросы «что здесь лежит и почему»: требуется найти владельца данных, восстановить историю системы, понять, чем status_2 отличается от status_new, и проверить свои догадки SQL-запросами.

В масштабах MWS — только в одном нашем кластере находится более 600 баз данных — ландшафт данных невозможно описать вручную. Он растёт быстрее, чем люди успевают его документировать.

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

Первая попытка: передаём модели схему

Мы начали с самого очевидного пути — передали в LLM структуру данных: имена таблиц, названия колонок и типы данных.

Результат оказался разочаровывающим. Модель просто пересказывала то, что и так видно в схеме: «Таблица содержит информацию о пользователях, колонка user_id — идентификатор пользователя». Нового знания или бизнес-логики в таких текстах не было.

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

Слои контекста

Чтобы преодолеть барьер, мы начали собирать контекст из всех доступных источников:

1. Примеры данных. Берём по 10 случайных записей на таблицу. Этого мало для анализа, но достаточно, чтобы отличить справочник от лога и увидеть, что в колонке лежат не «какие-то статусы», а конкретные повторяющиеся значения.

2. Классификация по способу использования. Мы делим таблицы на типы:

• Log — события и мониторинг;

• Transactional — бизнес-транзакции и ETL (включая stage-таблицы);

• Directory — справочники с постоянными значениями;

• Bridge — связи «многие ко многим»;

• Summary — агрегаты и сводные метрики.

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

3. Доменная принадлежность. Если у компании нет своего описания предметной области, мы опираемся на отраслевые стандарты. Для телекома это eTOM (карта процессов оператора связи), для финансов — BIAN. В итоге модель соотносит таблицу с выверенной внешней схемой бизнеса.

4. Собственный глоссарий. Если готовой отраслевой модели нет, продукт сам строит глоссарий предметной области на основе данных и сопоставляет таблицы с ним.

5. Документация. Мы подключили парсер Confluence, git-репозиториев и файлов (PDF, DOCX, XLSX, MD, TXT, HTML). Страницы делятся на фрагменты, сохраняются в Elasticsearch и ищутся гибридным методом — одновременно полнотекстовым и векторным поиском.

Что в промпте работает, а что мешает

Казалось бы, чем больше контекста мы даём модели, тем лучше должен быть результат. Но эксперименты показали обратное.

Методика тестирования

Мы взяли одну и ту же модель и провели 1048 генераций для 93 уникальных таблиц из трёх разных источников. Качество оценивал автоматический рейтер — связка LLM-as-a-judge и CatBoost по шкале от 1 до 5. Влияние блоков промпта считали парным t-тестом и регрессией с фиксированными эффектами.

Мы тестировали следующие блоки промпта:

• task — инструкцию, что нужно сделать;

• examples — образцы желаемого вывода;

• output_format — жёсткое указание формата;

• documentation — найденные фрагменты документации.

Влияние блоков на качество описания

Два верхних результата ожидаемы, а нижние — нет. Жёсткое описание формата и добавление документации ухудшают качество. Причём на извлечение документации мы потратили больше всего сил!

Причина проблем

Оба этих блока добавляют шум:

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

• Спецификация формата слишком сильно отвлекает внимание ^[2] модели от анализа самих данных.

Ещё интереснее ведут себя комбинации блоков. Лучшее качество давало сочетание контекста, примеров и документации. Но если к этому набору добавить блок task, общая оценка снижалась. Блок, который сам по себе полезен, в перенасыщенном промпте начинает только мешать.

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

Результаты внедрения

Мы проверили систему на продуктивных базах МТС. Результаты автоматизации:

• 8180 таблиц из 7 СУБД были полностью описаны менее чем за 3 дня.

• Скорость генерации составила около 25 секунд на одну таблицу (вместо 6 часов ручной работы).

• Около 80% работы по документированию теперь полностью автоматизировано. Команде остаётся лишь настроить домен и утвердить результат.

• 95% описаний принимаются аналитиками вообще без правок.

• Производительность одного сотрудника выросла с 30 до 2000 таблиц в месяц.

Скорость сильно зависит от объёма собранного контекста. Систему на 634 таблицы мы прошли за 33 часа, а другую систему на 4653 таблицы — всего за 1,75 часа. Указано чистое время генерации без учёта проверки человеком.

Помимо текстов, система выполняет сопутствующие задачи:

• Строит ER-диаграммы. Включая скрытые связи, которые определяются анализом пересечений самих данных (когда связи не оформлены внешними ключами foreign keys).

• Формирует бизнес-термины и синонимы.

• Размечает персональные данные (ПДн).

Безопасность персональных данных

Разметка персональных данных — это критически важная задача с высокой ценой ошибки ^[3]. С мая 2025 года по закону № 152-ФЗ за утечки данных предусмотрены крупные оборотные штрафы: до 3% годовой выручки (до 500 млн рублей) за повторную утечку и до 15 млн рублей за первичную.

Главную опасность представляют «забытые» копии в legacy-системах. Наш продукт автоматически ищет ПДн по всему ландшафту с помощью LLM и классических методов машинного обучения ^[4]. На основе ER-диаграммы мы видим, куда именно эти данные растекаются по хранилищу.

Важно: маскирование чувствительных полей происходит на сетевом шлюзе до того, как к ним получит доступ ИИ-агент. Сами данные при этом никогда не покидают защищённый периметр компании.

Технические ограничения

1. Источники данных. Из коробки доступно более восьми коннекторов к СУБД: Oracle, PostgreSQL, MS SQL, ClickHouse, MySQL, Greenplum, Hadoop. Поддерживается архитектура Lakehouse, есть интеграция с каталогами DataHub и OpenMetadata. Выгрузить результаты можно в Excel и JSON.

2. Стоимость и инфраструктура. Каждый запрос к LLM стоит денег. Модели развёрнуты внутри контура компании на выделенных серверах с GPU A100 и A40. Это фиксированная статья расходов и одновременно «потолок» производительности — для масштабирования нужно докупать дорогое оборудование.

3. Оптимизация. Чтобы снизить расходы, мы переводим простые задачи (например, детекцию ПДн) с тяжёлых LLM на лёгкие классификаторы — от логистической регрессии до моделей класса DistilBERT. Мы обучаем их на синтетических данных, сгенерированных ИИ. Это снижает время ответа до миллисекунд и даёт стабильный детерминированный результат.

MWS Data Scout для ИИ-агентов

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

В отличие от человека, ИИ-агент не может пойти и просто «спросить дорогу» у коллеги. Он способен работать только с той информацией, которая чётко и системно задокументирована.

Без чётких описаний, глоссария и связей ИИ-агент работает вслепую: путает таблицы из сотен похожих, каждый раз по-своему трактует бизнес-метрики (например, «выручку»), соединяет таблицы случайным образом и может случайно выдать конфиденциальные данные.

Итого

MWS Data Scout ^[1] собирает многослойный контекст: примеры данных, классификацию таблиц, доменную принадлежность, глоссарий и документацию. Помимо текстовых описаний, система строит ER-диаграммы, включая скрытые связи, формирует бизнес-термины и размечает персональные данные. За счёт решения производительность одного сотрудника выросла с 30 до 2000 таблиц в месяц.

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