Как составить словарь данных с помощью ИИ: соберите описания полей у владельца таблицы, передайте их модели отдельным промптом с фиксированным набором колонок, получите черновик и вручную сверьте каждое значение с исходником. Итог — таблица, где для каждого столбца указаны смысл, тип, единицы, допустимые значения, поведение при пропусках и источник определения. Ниже — назначение документа, порядок сбора данных, готовый промпт, учебный пример и способ проверки.
Назначение словаря и его границы
Словарь данных отвечает на вопрос, что означает конкретное поле в конкретной таблице. Издание Atlan описывает его как место, где ИИ-агент смотрит, что поле значит на самом деле, — общие определения, которые удерживают одинаковые ответы у разных команд. Там же отмечено, что словарь легко спутать с каталогом или бизнес-глоссарием, и различие важно до начала работы. Практический вывод для читателя: словарь полей одной таблицы — это локальный документ, который описывает физические столбцы и их допустимые значения.
Границы задаются тремя ограничениями. Первое: определите конкретную таблицу или набор связанных таблиц, которые покрывает словарь. Второе: он описывает физический уровень — имена столбцов, типы, ограничения, — а бизнес-термины уровня подразделений живут в глоссарии. Atlan указывает, что организации обычно начинают со словарей для критичных систем, затем расширяются до бизнес-глоссариев для кросс-функционального согласования и только потом внедряют каталоги, объединяющие всё в поисковую управляемую платформу. Третье: словарь фиксирует текущее состояние и открытые вопросы. Предложения будущих изменений схемы храните отдельно.
Издание Dataedo определяет словарь данных как перечень элементов данных в базе или модели с подробным описанием формата, связей, смысла, источника и использования. Там же сказано, что словарь — это таблица, где элементы данных (столбцы) идут строками, а их атрибуты — столбцами, и конкретный набор атрибутов зависит от назначения документа. Это снимает вопрос о «правильном» числе колонок: набор подбирается под задачу.
Отдельно стоит развести активный и пассивный словарь. По Dataedo, активный словарь встроен в большинство СУБД и доступен пользователю через системные таблицы или представления с информацией о таблицах, столбцах, типах данных и скриптах; изменения в структуре базы автоматически отражаются в нём, и администратору не нужно вести его вручную. Пассивный словарь живёт отдельно от базы, и изменения структуры вносятся в него вручную или отдельным программным обеспечением. ИИ-помощник работает именно с пассивным словарём: модель формирует черновик документа, который затем поддерживается людьми.
Граница по объёму тоже практическая. Atlan отмечает, что словарь может быть простой таблицей в электронной таблице, PDF или полноценным веб-приложением. Для одной таблицы достаточно таблицы в редакторе: её легко согласовать и передать коллеге. Поисковый интерфейс нужен в сложных многосистемных средах с точными техническими спецификациями, и это уже следующий этап.
Наконец, словарь — живой документ. Atlan пишет, что статичная документация быстро устаревает, и современные организации внедряют «живые словари», которые обновляются автоматически при участии человека. Там же сказано, что при добавлении новых столбцов словарь отражает изменения сразу. Для ИИ-цикла это означает регулярный перезапуск: структура таблицы меняется, черновик пересобирается, ручная сверка повторяется.
Сбор и проверка исходных данных
Исходные данные для словаря соберите у владельца таблицы: нужны подтверждённые описания каждого поля. Порядок сбора такой.
Шаг первый: выписать все столбцы таблицы в том порядке, в котором они идут в файле. Спецификация Table Schema проекта Frictionless Data указывает, что табличные данные состоят из строк, каждая строка имеет набор полей, и обычно ожидается, что у всех строк один и тот же набор полей. Для CSV и электронных таблиц первая строка обычно трактуется как строка заголовков, дающая имена полей; в SQL-таблицах имена полей заданы явно. Это определяет, откуда берётся список столбцов.
Шаг второй: получить у владельца смысл каждого поля. Формулировка вопроса: «что означает этот столбец, в каких единицах, какие значения допустимы, что значит пустое значение». Ответы владельца становятся источником определения. Модель не должна выводить смысл из имени: source может означать канал поступления, а может означать что угодно другое, и решает владелец.
Шаг третий: зафиксировать типы и ограничения. Atlan относит к обязательным компонентам подробные свойства элементов данных, бизнес-правила и диаграммы сущностей и связей. Там же сказано, что бизнес-правила определяют, что считается допустимыми данными: первичные ключи обеспечивают уникальную идентификацию, внешние ключи поддерживают ссылочную целостность между таблицами, проверочные ограничения валидируют данные по бизнес-логике. Эти три категории и переносятся в словарь.
Шаг четвёртый: описать происхождение данных. Atlan указывает, что словарь прослеживает источники и преобразования данных, и понимание того, откуда данные приходят и как меняются, помогает командам доверять аналитическим результатам. Для одной таблицы это обычно строка о системе-источнике и о том, кто пишет данные.
Шаг пятый: собрать примеры значений. По одному корректному примеру на поле достаточно, чтобы читатель понял формат. Примеры берутся из реальных строк или из описания владельца.
Шаг шестой: отметить открытые вопросы. Всё, на что владелец не ответил, идёт в отдельную колонку со статусом «открытый вопрос». Это защищает от подстановки правдоподобных догадок.
Проверка собранного перед передачей модели: список столбцов совпадает с заголовком файла; у каждого поля есть хотя бы смысл и тип; обязательность отмечена явно; для полей с ограниченным набором значений перечислены все варианты; для необязательных полей описано, что означает пропуск. Если чего-то не хватает, лучше вернуться к владельцу, чем позволить модели заполнить пробел.
Отдельно проверяется формат данных. Table Schema различает физическое представление данных — то, как данные записаны текстом на диске, например в CSV или JSON, — и логическое представление, то есть идеальную форму в терминах примитивных типов, структур и связей. В CSV все данные представлены в строковой форме, в JSON доступны примитивные типы. Это объясняет, почему в словаре для CSV-файла тип integer описывает логическое значение, а физически в файле лежит текст.
Готовый учебный артефакт: словарь для reservations.csv
Ниже — учебный пример. Таблица reservations.csv и правила её владельца вымышлены для разбора; аудит реальной базы не проводился.
Владелец сообщил следующее. reservation_id — уникальный строковый номер. created_at — время создания в UTC по ISO 8601. seats — положительное целое количество мест. status принимает значения new, confirmed или cancelled. source хранит канал поступления, а его пустое значение значит «не указан». В этих учебных правилах владелец также явно установил, что reservation_id, created_at, seats и status обязательны и не могут быть пустыми.
Заполненный словарь выглядит так:
reservation_id | string | required | уникальный номер брони | R-101
created_at | datetime UTC | required | время создания брони | 2026-11-11T09:00:00Z
seats | integer | required | количество мест, >= 1 | 2
status | string enum | required | new, confirmed, cancelled | confirmed
source | string | nullable | канал поступления | пусто = не указан
Разбор по колонкам. reservation_id — строковый идентификатор с требованием уникальности. Из учебного описания ещё не следует, что в базе для него настроено ограничение первичного ключа; это уточняют отдельно. created_at — момент времени в UTC; часовой пояс зафиксирован владельцем и входит в определение поля. seats — целое число с нижней границей; ограничение >= 1 относится к проверочным ограничениям, которые валидируют данные по бизнес-логике. status — перечисление из трёх значений; полный список вариантов обязателен, иначе словарь не отвечает на вопрос о допустимых значениях. source — необязательное строковое поле; пустое значение имеет явный смысл «не указан», и это записано в определении.
Допустимый справочник для source владелец не задал. Это открытый вопрос, и он остаётся открытым в документе. До ответа владельца список каналов остаётся неизвестным. Модель должна сохранить этот пробел в словаре.
Каждый смысл в этом словаре связан с описанием владельца. Ни одно значение не выведено из имени столбца. Это и есть проверяемое свойство готового артефакта: для каждой строки можно указать, кто и когда дал определение.
Полезно заранее решить, где хранится словарь. Atlan относит справочную документацию к случаям, где эффективно работают простые форматы. Для одной таблицы подходит таблица в редакторе или PDF. Если словарь нужно передать вместе с данными, спецификация Data Package проекта Frictionless Data описывает простой контейнерный формат для связной коллекции данных: метаданные хранятся в дескрипторе, а сам пакет включает файлы данных и другие ресурсы. Там же отмечено, что спецификация не накладывает требований на форму и структуру этих ресурсов, а дополнительные файлы вроде README и скриптов могут прилагаться. Это даёт способ упаковать таблицу и её словарь в один набор.
Копируемый промпт с указанными входами
Задача промпта — получить черновик словаря полей одной таблицы с фиксированным набором колонок и с приоритетом описания владельца.
Ты помогаешь составить словарь данных для одной таблицы.
Вход 1. Список столбцов таблицы [имя таблицы] в порядке следования:
[перечислите столбцы через запятую]
Вход 2. Описание владельца по каждому столбцу:
[для каждого столбца: смысл, единицы, допустимые значения, что значит пустое значение, обязательность, пример]
Вход 3. Известные ограничения и ключи:
[первичный ключ, внешние ключи, проверочные ограничения, формат даты и часовой пояс]
Построй таблицу со столбцами:
name, meaning, type, unit, nullable, allowed, example, source of definition, open question.
Правила:
1. Приоритет отдавай описанию владельца из входа 2.
2. Смысл поля бери из описания владельца. Имя столбца не используй как источник смысла.
3. Если владелец не задал допустимые значения или справочник, поставь в столбец open question пометку «открытый вопрос» и не подставляй правдоподобный список.
4. Пустое значение описывай так, как его определил владелец.
5. Часовой пояс и формат времени переноси в словарь в том виде, в каком их задал владелец.
6. Не считай пустое значение в поле source органическим трафиком.
7. Не меняй UTC на локальное время.
8. Для каждого поля укажи, откуда взято определение: имя владельца или название документа.
Верни только таблицу словаря и список открытых вопросов отдельным блоком.
Что менять под себя: [имя таблицы], список столбцов, описание владельца, ограничения и ключи. Если таблица большая, промпт запускается по группам столбцов, а результаты сводятся в один документ.
Вариации той же задачи, если тема требует другого входа:
- Промпт для таблицы без описания владельца: попросить модель перечислить вопросы к владельцу по каждому столбцу и не заполнять смысл до получения ответов.
- Промпт для проверки готового словаря: передать словарь и выборку строк, попросить найти строки, которые нарушают объявленные типы и допустимые значения.
- Промпт для CSV-файла: попросить вывести словарь в формате Table Schema с массивом дескрипторов полей.
- Промпт для нескольких связанных таблиц: попросить отдельно описать ключи и связи между таблицами и отдельно — поля каждой таблицы.
- Промпт для согласования: попросить сформулировать по каждому полю один вопрос владельцу, ответ на который снимет неоднозначность.
Отрицательный пример и неизвестные данные
Разберём строки, которые нарушают учебный словарь. Эти проверки иллюстрируют словарь и не являются аудитом реальной базы.
Первая строка: seats = "2 места". Словарь объявляет seats целым числом с ограничением >= 1. Значение содержит текст и пробел, поэтому проверка типа не проходит. Возможная причина — данные писались вручную в свободное текстовое поле. Исправление: после проверки исходной записи сохранить целое число в поле, а единицу измерения указать в его описании.
Вторая строка: status = done. Словарь объявляет перечисление из трёх значений: new, confirmed, cancelled. Значение done в списке отсутствует. Возможная причина — в системе-источнике есть собственный набор статусов, который не согласован со словарём. Исправление: либо расширить перечисление по решению владельца, либо привести источник к объявленному набору.
Третья строка: пустой source. Словарь объявляет это поле необязательным и говорит, что пустое значение значит «не указан». Расшифровка пустого значения как «органический трафик» противоречит определению владельца. Возможная причина — привычка аналитика трактовать пропуски в маркетинговых полях по-своему. Исправление: оставить пустое значение пустым и не подставлять смысл.
Отдельная категория — неизвестные данные. В учебном примере владелец не задал допустимый справочник для source. Это открытый вопрос, и в словаре он остаётся открытым. Модель может предложить правдоподобный список каналов, и такое предложение опасно тем, что выглядит как определение. Правило простое: всё, что не подтверждено владельцем или документом, попадает в колонку открытых вопросов.
Ещё одна частая ошибка — вывод смысла из имени. Столбец created_at легко прочитать как «дата создания», и это совпадёт с описанием владельца. Столбец source так прочитать нельзя: имя не говорит, канал это поступления, источник записи или что-то третье. Правило «имя столбца — не источник смысла» защищает от цепочек правдоподобных, но неверных определений, которые потом расходятся по отчётам.
Третья ошибка — подмена словаря бизнес-глоссарием. Atlan прямо указывает, что словарь данных и бизнес-глоссарий — взаимодополняющие инструменты, и путаница между ними ведёт к дублирующим системам. Словарь описывает поля таблицы; глоссарий описывает термины организации. Смешение уровней делает документ непригодным для обеих задач.
Четвёртая ошибка — отсутствие источника определения. Если в словаре не указано, кто дал смысл поля, при расхождении невозможно решить, какое определение верное. Колонка source of definition обязательна именно поэтому.
Ручная проверка результата по исходнику
Черновик от модели проверяется вручную, поле за полем, по исходным данным. Порядок такой.
Сверка списка полей. Каждый столбец из заголовка файла присутствует в словаре ровно один раз. Спецификация Table Schema отмечает, что имя поля должно быть уникальным, и хотя файл может содержать несколько столбцов с одинаковым именем, это очень плохая практика. Дубликат в словаре означает, что один из столбцов остался неописанным.
Сверка смысла. Для каждой строки найдите подтверждение смысла в описании владельца. Если описание владельца отсутствует, строка переносится в открытые вопросы.
Сверка типов. Для каждого поля проверяется, что объявленный тип соответствует значениям в файле. Table Schema различает физическое и логическое представление: в CSV значение записано текстом, а логический тип описывает идеальную форму. Проверка идёт по логическому типу: значение 2 в поле seats соответствует целому числу, значение 2 места — нет.
Сверка допустимых значений. Для полей с перечислением проверяется, что все значения из файла входят в объявленный список. Любое значение вне списка — либо ошибка данных, либо неполный словарь.
Сверка пропусков. Для каждого необязательного поля проверяется, что поведение при пропуске описано и совпадает с решением владельца. Для обязательных полей проверяется, что пустых значений в файле нет.
Сверка ключей и ограничений. Если первичный ключ задан в подтверждённой схеме, проверьте его состав, уникальность и отсутствие пропусков. Если ключ не задан, сохраните этот статус и отдельно проверьте объявленные владельцем требования уникальности. Проверяется, что проверочные ограничения записаны в виде, допускающем машинную проверку: >= 1 проверяемо, «положительное количество» — нет.
Сверка примеров. Каждый пример из словаря должен быть допустимым значением по объявленным правилам. Пример, нарушающий собственный словарь, — сигнал об ошибке в определении.
Сверка открытых вопросов. Каждый вопрос должен быть сформулирован так, чтобы владелец мог ответить одним предложением. Спросите владельца конкретно: какие значения может принимать source и что означает его пропуск. Ответ перенесите в соответствующие колонки словаря.
После ручной проверки черновик становится версией для согласования. Правки, внесённые человеком, фиксируются в колонке источника определения: если смысл уточнил владелец, это записывается.
Сохранение и согласование результата
Согласование начинается с владельца таблицы. Ему показывается словарь и список открытых вопросов. Ответы вносятся в документ, вопросы закрываются или остаются с пометкой.
Формат сохранения выбирается по аудитории. Atlan пишет, что словарь может быть простой таблицей в электронной таблице, PDF или полноценным веб-приложением. Для одной таблицы подходит таблица в редакторе: её видно в истории версий и легко согласовать построчно. Если словарь передаётся вместе с данными, применяется контейнерный формат Data Package: метаданные в дескрипторе, файлы данных и дополнительные материалы рядом. Спецификация Data Package отмечает, что дескриптор может включать дополнительные свойства помимо обязательных и необязательных, и эта гибкость позволяет сообществам расширять пакет под свои данные.
Если словарь ведётся в системе с API, сначала уточните, какие операции относятся именно к словарю и как согласуются изменения. В API Release Notes Alation перечислены операции Data Products API; этот документ сам по себе не подтверждает API обновления словаря. Перед принятием правки словаря сверяйте его с актуальной схемой таблицы и подтверждёнными определениями владельца.
Поддержание актуальности — отдельная задача. Atlan указывает, что статичная документация быстро устаревает, и современные организации внедряют словари, обновляемые автоматически при участии человека. Практический регламент: при изменении структуры таблицы словарь пересобирается тем же промптом, а ручная сверка повторяется по изменившимся полям.
Передача коллеге. Вместе со словарём передаются: сам документ, список открытых вопросов, имя владельца определений и примеры значений. Этого достаточно, чтобы новый человек прочитал таблицу одинаково с автором.
Частые вопросы
Как составить словарь данных с помощью ИИ, если описания полей нет?
Соберите у владельца таблицы смысл, единицы, допустимые значения и поведение при пропусках по каждому столбцу. Передайте эти ответы модели вместе со списком столбцов и ограничениями. Если ответов нет, попросите модель сформулировать вопросы владельцу и не заполняйте смысл до получения ответов.
Чем словарь данных отличается от бизнес-глоссария?
Словарь описывает поля конкретной таблицы: типы, ограничения, допустимые значения, пропуски. Бизнес-глоссарий описывает термины организации и служит кросс-функциональному согласованию. Издание Atlan указывает, что организации обычно начинают со словарей для критичных систем и затем расширяются до глоссариев.
Можно ли вести словарь в обычной электронной таблице?
Да. Atlan отмечает, что словарь может быть простой таблицей в электронной таблице, PDF или полноценным веб-приложением. Для одной таблицы таблица в редакторе удобна: её видно в истории версий и легко согласовать построчно. Поисковый интерфейс нужен в сложных многосистемных средах.
Что делать с полями, для которых владелец не задал допустимые значения?
Оставить их в колонке открытых вопросов и не подставлять правдоподобный список. В учебном примере допустимый справочник для source не задан, и это остаётся открытым вопросом. Подставленный список выглядел бы как определение и разошёлся бы по отчётам.
Как проверить черновик словаря от модели?
Сверьте список полей с заголовком файла, смысл — с описанием владельца, типы — со значениями, перечисления — с полным списком вариантов, пропуски — с решением владельца. Проверьте, что примеры не нарушают собственные правила словаря. Всё, что не подтверждено, перенесите в открытые вопросы.