Сущность разрешения становится ИИ-инфраструктурой, а не очисткой данных

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

Ничего не было вымышлено. Модель рассуждала чисто над данными, которые были ей предоставлены. Данные просто случились описывать двух клиентов, где в реальном мире был один. Ошибка не была в языковой модели. Она была в соединении.

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

Проблема изменила время

На протяжении большей части своей рабочей жизни вопрос “являются ли эти две записи одной и той же сущностью?” был вопросом очистки. Вы запускали его в пакетном режиме, по расписанию, где-то внутри программы управления мастер-данными, склада или аналитического конвейера. Это не было идеальным, но это было терпимо, потому что вывод был отчетом, который кто-то читал на следующей неделе. Если две записи для одного и того же поставщика не были объединены, цифра расходов была немного неверной, аналитик заметил это, и это было исправлено в следующем запуске. Система имела запас по времени. Время поглощало ошибки.

Агент ИИ удаляет этот запас. Он меняет время вопроса с “в конце концов” на “сейчас”. Когда агент собирается одобрить возврат, направить дело, обновить профиль или ответить на вопрос соблюдения, разрешенная сущность больше не подается в отчет. Она подается в действие. Стоимость неправильного соединения переходит от цифры, которая немного неверна, к чему-то, что происходит в мире, сразу и часто без участия человека, который мог бы поймать это.

Это сдвиг, который стоит рассмотреть. Основная проблема старая и хорошо понятная. Что нового, так это то, что мы напрямую подключили ее к системам, которые действуют самостоятельно.

Статистическая проблема 1960-х годов

Разрешение сущности не появилось с большими языковыми моделями. Оно появилось с перфокартами. В 1959 году Х. Б. Ньюкомб и его коллеги опубликовали короткую статью в журнале Science об автоматическом соединении записей, описывая, как компьютер может решить, относится ли запись о рождении и запись о браке к одному и тому же человеку. Через decade Иван Феллеги и Алан Сунтер дали этой идее формальную математическую теорию, определяющую три результата, которые любая система сопоставления до сих пор производит сегодня: соединение, несоединение и возможное соединение, которое человеку нужно просмотреть.

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

Что действительно изменилось, так это когда нам нужен ответ. Исследователи писали о разрешении сущностей во время запроса, а не только заранее, задолго до текущей волны ИИ. Тогда это было интересным оптимизационным методом. Теперь это ближе к требованию.

Почему агенты превращают это в инфраструктуру

Большинство корпоративных систем ИИ не отвечают из памяти модели. Они извлекают. Шаблон, популяризированный как генерация с извлечением, имеет агент, который извлекает актуальный контекст в момент вопроса и рассуждает над ним. Это в целом хорошая вещь. Она основывает ответы на ваших данных, а не на обучении модели.

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

Итак, разрешение не может быть после мысли, которая запускается раз в квартал и приземляется в отдельной таблице. Сущность должна быть собрана, когда данные вводятся, и текущий разрешенный вид ее должен быть доступен в момент, когда агент спрашивает. Это(runtime-зависимость). Оно ведет себя гораздо больше как база данных или служба аутентификации, чем как периодический проект очистки данных, и оно должно быть спроектировано, отслежено и доверено так же, как вы бы относились к любой другой системе, которую ваше приложение вызывает в реальном времени.

Пробел готовности, которого никто не называет точно

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

Когда люди объясняют этот пробел, они склонны прибегать к двум словам: качество данных и управление. Оба важны, и ни один из них не является необязательным. Но есть более узкий вопрос, лежащий под ними, который чистые, хорошо управляемые данные не отвечают сами по себе. Может ли система сказать, какая реальная сущность данная запись относится, во всех местах, где эта запись существует, прямо сейчас? Вы можете содержать высококачественные данные в каждой отдельной системе и все равно не пройти этот тест, потому что неудача не живет внутри какой-либо одной системы. Она живет в пространствах между ними, где один и тот же клиент носит три немного разных лица.

Что проверить, прежде чем позволить агенту действовать

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

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

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

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