Рішення сутності стає інфраструктурою штучного інтелекту, а не очищенням даних

Кілька років тому я спостерігав, як агент штучного інтелекту дав впевнену, але неправильну відповідь на досить банальну причину. У компанії були дві записи про одного й того самого корпоративного клієнта. Один запис містив стару торгову назву та контактну інформацію фінансового відділу. Інший запис містив нову юридичну назву компанії, яку вона прийняла після придбання, разом із різною адресою для оплати. Агентові було поставлене просте питання: чи знаходиться цей рахунок у доброму стані? Він знайшов один запис, побачив, що немає заборгованості з оплатою рахунків, і сказав «так». Заборгованість з оплати рахунків була записана під іншим ім’ям.

Нічого не було вигадано. Модель логічно виводила висновки на основі отриманих даних. Дані просто випадково описували двох клієнтів, де в реальному світі був лише один. Помилка не була в мовній моделі. Вона була в з’єднанні.

Я прийшов до висновку, що це одна з найбільш недооцінених ризиків у корпоративному штучному інтелекті, і одна з найменш обговорюваних. Ми безупинно говоримо про точність моделей, проектування запитів і управління. Ми говоримо набагато менше про те, чи знає система, на яку реальну клієнтку, постачальника або рахунок вона діє. Це питання має назву – вирішення сутності, і після шістдесяти років на другому плані воно тихо перетворюється на елемент живої інфраструктури.

Проблема змінила час

На більшій частині свого робочого життя «чи ці два записи належать одній сутності?» було питанням очищення. Ви запускали його в пакетному режимі, за розкладом, десь всередині програми управління мастер-даними, складу або аналітичного конвеєра. Це ніколи не було ідеальним, але це було виживаним, оскільки результатом була звітність, яку хтось читав на наступний тиждень. Якщо два записи одного й того самого постачальника не були об’єднані, сума витрат вийшла трохи неправильною, аналітик помітив це, і все виправили в наступному циклі. Система мала певний запас часу. Час поглинав помилки.

Агент штучного інтелекту усуває цей запас часу. Він змінює час питання з «згодом» на «зараз». Коли агент готується схвалити повернення коштів, направити справу, оновити профіль або відповісти на питання про дотримання вимог законодавства, вирішена сутність вже не живиться у звіті. Вона живиться діями. Вартість неправильного з’єднання переходить від числа, яке трохи неправильне, до чогось, що відбувається у світі відразу ж, часто без участі людини, яка могла б це помітити.

Це той зсув, про який варто подумати. Сама проблема стара і добре зрозуміла. Що нового, так це те, що ми підключили її безпосередньо до систем, які діють самостійно.

Статистична проблема 1960-х років

Вирішення сутності не з’явилося разом з великими мовними моделями. Воно з’явилося разом з перфокартами. У 1959 році Г. Б. Ньюкомб і його колеги опублікували коротку статтю у виданні Science про автоматичне зв’язування реєстрових даних, описуючи, як комп’ютер може вирішити, чи належить запис про народження і запис про шлюб одній і тій самій людині. Через десятиліття Іван Феллегі та Алан Сантнер дали цій ідеї формальну математичну теорію, визначаючи три результати, які будь-яка система зіставлення все ще видає сьогодні: зв’язок, незв’язок і можливий зв’язок, який людина повинна переглянути.

Є одна деталь у цьому походженні, про яку варто подумати, оскільки це частина, яку люди найчастіше неправильно розуміють. Зв’язування записів ніколи не було просто точним збігом за електронною адресою або спільним ідентифікатором. З самого початку це було ймовірнісним. Воно зважувало докази того, що два записи погоджувалися щодо прізвища, дати, місця та видавало оцінку, оскільки дані, введені людиною, були нечіткими, а точні ключі постійно виходить з ладу. Сучасне вирішення сутності все ще працює tímto чином. Воно поєднує детерміновані правила, де спільний стабільний ідентифікатор є вирішальним, з ймовірнісним і розмитим машинним навчанням, яке справляється з друкарськими помилками, прізвиськами, поміщеними в неправильне місце полями, абревіатурами та десятком малих способів, як одна й та сама людина чи компанія виглядає по-різному в різних системах. Гарний огляд галузі проводить незламну лінію від тих 1950-х реєстрових даних до методів кластеризації та машинного навчання, які використовуються зараз.

Що дійсно змінилося, так це те, коли нам потрібна відповідь. Дослідники писали про вирішення сутностей під час виконання запиту, а не просто заздалегідь, ще до поточної хвилі штучного інтелекту. Тоді це було цікавим оптимізуванням. Тепер це ближче до вимоги.

Чому агенти перетворюють це в інфраструктуру

Більшість корпоративних систем штучного інтелекту не відповідають з пам’яті моделі. Вони витягують. Шаблон, популяризований як генерація, доповнена витяганням, має агент, який витягує відповідний контекст у момент питання та виводить висновки на основі нього. Це, в цілому, хороша справа. Воно ґрунтує відповіді у ваших даних, а не у навчанні моделі.

Але це має наслідок, який легко пропустити. Агент успадковує все, що йому передає витягальне крок. Якщо витягування повертає фрагментованого клієнта, три неповних записи, які ніколи не були пов’язані, агент буде виводити висновки про трьох клієнтів. Якщо витягування повертає неправильно об’єднаний запис, два різних підприємства, злиплених у один профіль, агент буде виводити висновки про одного клієнта. Неоднозначність, яка вже сидить у ваших джерельних системах, передається прямо далі та подається моделі як встановлений факт. Модель не має жодного способу знати, що з’єднання було неправильним, так само, як і ви, читач, не знаєте, прочитавши охайний підсумок записів, яких ви ніколи не бачили.

Таким чином, вирішення сутності не може бути післядумом, який запускається раз на квартал і приземляється в окремій таблиці. Сутність повинна бути зібрана під час інгестування даних, а поточний вирішений вигляд її повинен бути витягуваним у той самий момент, коли агент запитує. Це залежність часу виконання. Воно поводиться набагато більше, як база даних або служба аутентифікації, ніж як періодичний проект очищення даних, і воно повинно бути спроектованим, моніторованим та довіреним так само, як ви ставитеся до будь-якої іншої системи, яку ваше застосування викликає в режимі реального часу.

Пропуск готовності, якого ніхто не назвав точно

Галузь вже відчуває, що щось відсутнє тут. Індекс готовності штучного інтелекту Cisco 2025 року виявив, що 83 відсотка організацій планують розгортати автономних агентів, тоді як лише близько третини відчувають, що їхня інфраструктура дійсно готова до цього, і лише близько чверті відчувають, що вони обладнані для контролю та управління тим, що ці агенти насправді роблять. Останній опит щодо стану штучного інтелекту, проведений компанією McKinsey, описує подібний пропуск з іншого боку: близько 88 відсотків організацій зараз використовують штучний інтелект хоча б в одній функції, проте більшість із них не розгорнули його на всьому підприємстві.

Коли люди пояснюють цей пропуск, вони схильні вживати дві слова: якість даних та управління. Обидва важливі, і жодне з них не є необов’язковим. Але є вужче питання, яке лежить під ними, яке чисті, добре керовані дані не відповідають самостійно. Чи може система визначити, на яку реальну сутність певний запис посилається, у всіх місцях, де цей запис існує, прямо зараз? Ви можете тримати високоякісні дані в кожній окремій системі та все одно провалитися цього тесту, оскільки провал не живе всередині однієї системи. Він живе в просторі між ними, де одна й та сама клієнтка носить три трохи різні обличчя.

Що перевірити, перш ніж дозволити агенту діяти

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

Практичний тест готовності не вимагає нового моделі чи нового постачальника. Зіберіть набір сутностей, яких ви дійсно розумієте. Пропустіть його через той самий шлях витягування, який використовує ваш агент, а не окрему чисту копію, створену для демонстрації. Потім виміряйте речі, які дійсно визначають результати: скільки неправильних злиттів і неправильних розділень, як система обробляє справжню неоднозначність, де розташовані її пороги впевненості, коли вона передає управління людині замість того, щоб здогадуватися, і як чисто вона передається вашим існуючим контролям мастер-даних та управління. Якщо команда не може відповісти на ці питання, агент діє на основі ідентичності, яку він не може підтвердити, і впевненість у його виході є помилковою.

Жодне з цього не замінює управління мастер-даними, управління, платформи клієнтських даних або склад. Вони відповідають на різні питання та залишаються необхідними. Управління визначає, що агент дозволено робити. Вирішення сутності визначає, кому або чому він це робить. Перше вже зріло у більшості великих організацій. Друге – це шар, який багато організацій ось-ось виявлять, що їм потрібно поруч з ним, в режимі реального часу, у той самий момент, коли вони дозволять агенту діяти, а не радити.

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