Без такого словаря одна и та же колонка быстро начинает трактоваться по-разному. Например, поле status может означать статус заказа, статус оплаты, статус обработки документа или внутренний этап CRM. Для человека это неудобно, а для ИИ-агента особенно рискованно: он может выбрать не ту колонку, построить неверный SQL-запрос или сделать неправильный вывод.
Хороший словарь колонок обычно включает техническое имя, человекочитаемое название, описание, тип данных, формат, примеры значений, источник данных, владельца поля, обязательность, ограничения, связь с другими таблицами и примечания по качеству данных.
В проектах с ИИ column dictionary помогает давать модели точный контекст. Агенту не нужно гадать, что такое paid_at, lead_score или normalized_amount. Он получает описание схемы и может безопаснее строить запросы, фильтровать данные, объяснять отчеты и находить ошибки в датасете.
Важно не превращать column dictionary в мертвый документ. Его нужно обновлять вместе с миграциями, изменениями ETL, новыми отчетами и интеграциями. Если словарь устарел, он начинает вредить: команда доверяет описанию, а реальные данные уже работают иначе.
Примеры
- Колонка customer_id описана как идентификатор клиента из CRM, тип integer, обязательное поле, связана с таблицей customers.
- Поле paid_at имеет тип datetime и заполняется только после подтвержденной оплаты, поэтому пустое значение не всегда ошибка.
- В словаре указано, что revenue хранится без НДС и в рублях, поэтому агент не смешивает его с gross_amount.
- Для колонки status перечислены допустимые значения: new, in_progress, paid, cancelled, refunded.
- Аналитик видит, что lead_source приходит из рекламной системы, а не вводится вручную менеджером.
- ИИ-агент перед SQL-запросом читает словарь колонок и понимает, какую дату использовать: created_at, paid_at или shipped_at.
Где используется
- документирование таблиц в SQL-базе
- подготовка данных для BI и аналитики
- безопасная генерация SQL-запросов ИИ-агентом
- описание колонок в Excel и Google Sheets
- контроль качества данных в отчетах
- онбординг аналитиков и разработчиков
- подготовка датасета для RAG или агентского поиска
- согласование смысла полей между бизнесом и IT
- проверка миграций и изменений схемы
- снижение ошибок при интеграции CRM, 1С, маркетинга и склада
Связанные термины
Частые вопросы
Чем column dictionary отличается от обычного списка колонок?
Список колонок показывает только имена полей. Column dictionary объясняет смысл, тип, источник, ограничения, примеры значений и правила использования каждой колонки.
Зачем словарь колонок нужен ИИ-агенту?
Он помогает агенту понимать данные без догадок: какую колонку брать для фильтра, что означает статус, где хранится сумма, какие значения допустимы и где возможны пропуски.
Что обязательно включить в словарь колонок?
Минимум: техническое имя, понятное название, описание, тип данных, обязательность, допустимые значения, пример, источник данных и примечания по ограничениям.
Кто должен вести column dictionary?
Обычно владелец данных, аналитик или команда data engineering. Главное правило: словарь должен обновляться вместе с изменениями схемы и отчетов.
Можно ли хранить словарь колонок в таблице?
Да. Для небольшого проекта достаточно Google Sheets или Notion. Для зрелой аналитики лучше использовать data catalog, документацию схемы или отдельную таблицу метаданных.
Какая ошибка встречается чаще всего?
Словарь создают один раз и забывают обновлять. Через несколько месяцев он расходится с реальной базой, и пользователи начинают принимать неверные решения.
