Почему одна и та же таблица называется по-разному
Корпоративные базы данных, ИИ и проблема вавилонской башни имён
Представьте: вы аналитик крупного университета. Вам нужны данные о студентах. Вы открываете базу данных и видите таблицы: SIS_STUDENT, STUDENT_REGISTRY, STU_MASTER, PERSONS_ACADEMIC, ENROLLMENT_SUBJECTS. Где из них — «студенты»?
Правильный ответ: в каждой из них — немного. И ни в одной полностью.
Это не техническая ошибка. Это естественное состояние любого крупного хранилища данных, которое живёт дольше нескольких лет. И именно это делает работу ИИ с корпоративными данными принципиально сложнее, чем кажется.
Как данные теряют имена
Большое хранилище данных — это не единое целое. Это слоёный пирог из систем, написанных в разное время разными командами с разными представлениями о том, «как правильно».
В 1990-х университет внедрил систему учёта студентов. Разработчики назвали главную таблицу STUDENT_REGISTRY. Логично. Понятно. В 2005-м университет купил новую ERP-систему — она называет тех же людей SIS_STUDENT (SIS — Student Information System). В 2015-м появилась система аналитики, которая агрегирует данные из обеих и хранит результат в STU_MASTER. В 2022-м добавили модуль работы с персоналом, который видит студентов как «людей с академическим статусом» — отсюда PERSONS_ACADEMIC.
Каждое имя абсолютно разумно в своём контексте. Вместе они образуют вавилонскую башню: все говорят об одном и том же, но на разных языках.
Не только имена таблиц
Проблема не ограничивается именами таблиц. Внутри таблиц она становится ещё острее.
«Идентификатор студента» в STUDENT_REGISTRY называется STUDENT_ID. В SIS_STUDENT — SIS_ID. В PERSONS_ACADEMIC — PERSON_GEOID. В STU_MASTER — STUDENT_NUMBER. Это четыре разных имени для одного и того же: уникального числа, которое университет присваивает каждому студенту при поступлении.
Или возьмём год обучения. В одной системе это ACADEMIC_YEAR в формате 2024. В другой — AY_CODE в формате 2024-2025. В третьей — YEAR_PERIOD в формате AY24. Три поля, одна концепция, три несовместимых представления.
И это не патология — это норма. В MIT Data Warehouse, с которым работает бенчмарк BEAVER, таблиц очень много. За десятилетия их создавали десятки команд. Согласованность имён в таком масштабе — скорее исключение, чем правило.
Почему это сложно для людей — и катастрофа для ИИ
Опытный аналитик, проработавший в организации несколько лет, знает: «ах, SIS_ID — это то же самое, что STUDENT_NUMBER, просто в другой системе». Это знание живёт в голове, в коридорных разговорах, в корпоративных вики, которые никто не обновляет.
Для человека это решаемо. Неудобно, требует времени на освоение, но решаемо.
Для ИИ это принципиальная проблема.
Нейросеть, которую просят «найти данные о зачислении студентов», видит тысячи таблиц. Она не знает корпоративной истории. Она не ходила на совещания, где обсуждалось, почему новый модуль назвали иначе. Ей нужно самостоятельно понять, что ENROLLMENT_DETAIL, SIS_ENRL_SEMESTER и REGISTRATION_HISTORY — это три разных взгляда на один и тот же процесс.
И не просто понять, что они «похожи». Понять, что именно нужно для конкретного вопроса — и выбрать правильную.
Три вида несовпадения
Когда исследователи изучают эту проблему, они выделяют несколько уровней несоответствия между именем в базе данных и тем, как человек формулирует вопрос.
Первый уровень — лексическое несовпадение: слова разные, смысл похожий. «Студент» vs STUDENT, «записался» vs ENROLLED. Это самый простой случай — современные языковые модели справляются с ним неплохо.
Второй уровень — сокращения и аббревиатуры: SIS_STUDENT, STU_MASTER, SUBJ_ENR_SEM. Имя содержит намёк на смысл, но расшифровать его без контекста сложно. SUBJ_ENR_SEM — это «предметное зачисление за семестр» или «субъект энергетики в семестровой программе»?
Третий уровень — семантически несвязанные имена: GEOID, PERSON_NUMBER, ENTITY_KEY. Эти поля ничем не намекают на то, что хранят. Узнать их смысл можно только из документации — которой часто нет — или из примеров данных.
Чем дальше в список, тем сложнее задача. И тем чаще ИИ выбирает не ту таблицу.
Когда имя — не идентификатор
Есть ещё один случай, о котором говорят реже: одно имя для разных вещей.
В большой организации слово «бюджет» может означать совершенно разное в зависимости от контекста. BUDGET_AMOUNT в таблице финансов — это утверждённая сумма. BUDGET_AMOUNT в таблице грантов — это запрошенная сумма. BUDGET_AMOUNT в таблице проектов — это фактически потраченное. Одно имя, три концепции.
Такое происходит, когда разные команды независимо называют свои поля, не зная о чужих решениях. Результат: синонимия (разные имена, одна вещь) и омонимия (одно имя, разные вещи) одновременно.
Для ИИ это особенно коварно: найти «правильную» таблицу по имени — и взять из неё не то значение.
Доменные знания как ключ
В 57 из 100 вопросов бенчмарка BEAVER ответ невозможно найти без специфических знаний о том, как устроена именно эта организация.
«Покажи данные по Курсу 18» — что такое Курс 18? Без знания что в MIT это математика, и что в базе она хранится как DEPARTMENT_NAME = 'Mathematics', запрос написать невозможно.
«Резидент первого года» у медиков — это не просто «студент». Это врач на стажировке с конкретным кодом контракта в конкретной таблице кадровой системы.
«Основной проект» в финансовой таблице — это поле IS_PRIMARY или это PROJECT_TYPE = 'CORE' или это что-то третье?
Такие знания не лежат в именах полей. Они живут в головах людей, которые работают с этими данными годами. Передать их ИИ — одна из самых сложных нерешённых проблем в области работы с корпоративными данными.
Почему это нельзя «просто исправить»
Логичный вопрос: почему бы не переименовать всё единообразно?
Ответ прост и печален: потому что каждое имя — это живая зависимость. Тысячи запросов, отчётов, скриптов, интеграций ссылаются на SIS_ID. Переименовать поле в STUDENT_ID — значит сломать всё, что его использует. В большой организации это буквально невозможно без многолетнего проекта миграции, который стоит дороже, чем жить с несовместимостью.
Поэтому хранилища данных не становятся чище с годами. Они становятся сложнее. Новые слои накладываются на старые, имена умножаются, семантика расплывается.
Единственный честный ответ на этот лабиринт — не переименовывать, а видеть связи: какой запрос, отчёт и скрипт опирается на каждое имя. Это и есть анализ зависимостей данных — карта, собранная из самого кода.
Что это значит для ИИ
Когда языковая модель работает с корпоративными данными, она сталкивается с результатами десятилетий таких решений.
Успех здесь требует не просто знания SQL. Требуется понимание того, как конкретная организация называет конкретные вещи. Это знание — не в схеме базы данных. Оно в истории компании, в головах аналитиков, в устаревших вики-страницах и рабочих встречах, которые никто не записывал.
Именно поэтому «просто подключить ИИ к базе данных» работает плохо. А бенчмарки, которые честно воспроизводят эту сложность, важны: они показывают, где именно ИИ теряется в этом лабиринте имён.
В реальных корпоративных данных нет вавилонского смешения языков. Есть что-то хуже: один язык, который каждая команда говорит немного по-своему.