Новый фреймворк определяет типы колонок по заголовкам: 39 типов и 120 тысяч столбцов

Группа исследователей опубликовала на arXiv работу о фреймворке, который определяет семантический тип столбца таблицы только по его заголовку и заодно оценивает качество источника данных. Система сопоставляет заголовки с 39 интерпретируемыми типами FinalFormat и проверялась примерно на 120 000 столбцов из семи наборов данных: UCI, Prague, Kaggle, VizNet/Sato, SOTAB, T2Dv2 и трека Metadata-to-KG конкурса SemTab 2024. Главный результат неоднозначный. На официальной строгой оценке SemTab цифры скромные, но авторы настаивают, что дело не только в модели.

Задача: понять таблицу, не глядя в ячейки

Перед загрузкой в граф знаний табличные данные нужно разметить: какой столбец содержит даты, какой названия организаций, какой идентификаторы. Эта задача называется Column Type Annotation (CTA) и входит в более широкую область Semantic Table Interpretation. Обычно разметка опирается на содержимое ячеек. Но значения бывают закрытыми по юридическим причинам, зашумлёнными или просто непригодными для анализа. Тогда заголовок остаётся едва ли не единственным источником смысла.

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

Как устроен фреймворк

Заголовки сопоставляются с 39 типами FinalFormat с помощью курируемых лексических ресурсов, то есть правил и словарей, а не непрозрачной модели. Каждое решение можно проследить: поле SourceKeywords сохраняет, какие именно токены заголовка привели к выбору типа. Для задач аудита и регулируемых отраслей такая прозрачность важна не меньше точности.

Дальше работает вторая ступень. Каждый назначенный тип активирует набор проверок из таксономии Data Quality Issues (DQI). Система ищет:

• пропущенные значения;
• дубликаты;
• нарушения предметной области (domain violations);
• неверный тип данных;
• временные несоответствия.

Итоги агрегируются в метрику HeadersIQ. Это лёгкий невзвешенный показатель качества на уровне источника данных целиком, а не отдельной колонки. Параллельно работает путь сопоставления с графами знаний, который выравнивает результат с DBpedia и Schema.org.

Цифры и спорный бенчмарк

Авторы заявляют широкое практическое покрытие на реальных зашумлённых метаданных. На треке SemTab 2024 Metadata-to-KG официальная оценка по принципу GT-strict, то есть строгого совпадения с эталоном, оказалась скромной. Авторы это не скрывают.

Чтобы разобраться в причинах, они провели слепой диагностический аудит расхождений. По его выводам, многие несовпадения объясняются гранулярностью разметки в бенчмарке, алиасами и выбором онтологии. Предсказания при этом не выглядят полностью неправдоподобными для подхода, который опирается только на заголовки. Например, «город» против «населённого пункта» формально считается ошибкой, хотя по смыслу различие минимально.

Здесь есть важная оговорка. Авторы прямо пишут, что аудит служит диагностическим свидетельством о паттернах расхождений, а не пересмотренным результатом бенчмарка. Пересчитывать скор в свою пользу они не пытаются. Тем не менее аудит выполнен авторами самой системы, и независимого подтверждения у него нет.

Где это можно применять

Подход выглядит прикладным в сценариях, где значения ячеек недоступны: каталоги открытых данных, корпоративные реестры, предварительная проверка поставок данных от партнёров. Дешёвый и объяснимый скрининг по заголовкам позволяет быстро отсеять источники с очевидными проблемами, прежде чем тратить ресурсы на тяжёлый конвейер интеграции.

Команде, которая строит граф знаний или витрину данных, стоит обратить внимание на две вещи. Во-первых, трассировка через SourceKeywords упрощает ручную проверку и отладку правил. Во-вторых, наблюдения об ошибках гранулярности и выбора онтологии полезны при чтении любых результатов SemTab: низкий strict-скор не всегда означает бесполезные предсказания. Оценивать систему всё же стоит на собственных данных, потому что заголовки в реальных таблицах часто бывают неинформативными, и тогда метод по определению упрётся в потолок.