Оптимизация документации данных: как LLM описывают тысячи таблиц без избыточного контекста

# Как описывать тысячи таблиц с помощью LLM: опыт MWS Data Scout

Проблема автоматического документирования корпоративных данных не имеет универсального решения. Попытка передать схему базы данных в языковую модель (LLM) без должной подготовки приводит к пересказу технических фактов, а не извлечению бизнес-смыслов. Компания MWS Cloud, разрабатывающая сервис MWS Data Scout, столкнулась с этим вызовом на практике, работая с ландшафтом, включающим более 600 баз данных. Для решения задачи был разработан многослойный подход к контексту, который позволил достичь производительности в 2000 таблиц в месяц на одного сотрудника.

Почему простая передача схемы не работает

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

Для преодоления этого барьера потребовалось собирать сложный контекст, выходящий за рамки сырой схемы. Было выделено несколько критических слоев информации:

1. Примеры данных. Для анализа отбираются по 10 случайных записей на таблицу. Этого объема достаточно, чтобы отличить справочник от лога и проанализировать повторяющиеся значения в колонках. 2. Классификация по типу использования. Таблицы разделяются на категории: *Log* (события и мониторинг), *Transactional* (транзакции и ETL), *Directory* (справочники), *Bridge* (связи «многие ко многим») и *Summary* (агрегаты). Понимание типа таблицы первично, так как описывать лог событий и справочник необходимо разными способами. 3. Доменная принадлежность. Если у компании отсутствует внутреннее описание предметной области, используются отраслевые стандарты. Например, для телекома применяется eTOM, для финансов — BIAN. 4. Собственный глоссарий. В отсутствие внешних стандартов продукт строит глоссарий на основе самих данных. 5. Внешняя документация. Система подключает парсеры для Confluence, репозиториев кода и файловых форматов, используя гибридный поиск (полнотекстовый и векторный).

Эффект «шума» в промптах

Казалось бы, увеличение количества входных данных должно улучшить результат. Однако проведенный эксперимент на 93 уникальных таблицах с 1048 генерациями показал обратное. Качество оценивалось автоматическим рейтером (комбинация LLM-as-a-judge и CatBoost).

Анализ влияния различных блоков промпта выявил неожиданный результат:

* Инструкция (task): Дает прирост качества +0,60. * Примеры (examples): Приносит +0,51. * Жесткий формат вывода (output_format): Снижает качество на 0,08. * Документация: Снижает качество на 0,11.

Добавление блоков с документацией и жесткими требованиями к формату ухудшало результат. Документация часто содержит устаревшую информацию или описывает смежные системы, что заставляет модель слепо копировать эти данные в описание, создавая шум. Жесткая спецификация формата отвлекает модель от анализа сути данных. Исключение составили только полезные сочетания: контекст плюс примеры. Добавление инструкции в перенасыщенный промпт также приводило к падению качества.

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

Результаты внедрения и безопасность

Внедрение системы на продуктивных базах МТС показало значительный эффект. 8180 таблиц из 7 СУБД были полностью описаны менее чем за 3 дня. Скорость генерации составила около 25 секунд на одну таблицу, что в 144 раза быстрее ручной работы (6 часов). Производительность одного сотрудника выросла с 30 до 2000 таблиц в месяц.

Помимо текстовых описаний, система выполняет дополнительные задачи: строит ER-диаграммы с выявлением скрытых связей, формирует синонимы бизнес-терминов и размечает персональные данные (ПДн). Разметка ПДн критически важна для соблюдения 152-ФЗ, где штрафы за утечки достигают существенных сумм. Система автоматически ищет чувствительные данные по всему ландшафту.

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

Технические ограничения и работа с ИИ-агент

Сервис поддерживает более восьми коннекторов к СУБД (Oracle, PostgreSQL, MS SQL, ClickHouse и др.) и работает в архитектуре Lakehouse. Для снижения стоимости вычислений простые задачи, такие как детекция ПДн, делегируются легким классификаторам (например, DistilBERT), обученным на синтетических данных сгенерированных ИИ, что снижает время ответа до миллисекунд.

Главное применение продукта смещается в сторону поддержки корпоративных ИИ-агентов. В отличие от человека, агент не может уточнить детали у коллеги. Ему необходим четкий и систематизированный слой описаний. Без него агенты склонны путать похожие таблицы, искажать смысл метрик и случайным образом соединять данные, что может привести к утечке конфиденциальной информации. MWS Data Scout создает единый точный источник правды для всех баз данных, позволяя агентам работать в рамках задокументированной бизнес-логики.

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