Агенты искусственного интеллекта терпят неудачу, когда упускают из виду «невидимые данные». Нитин Сингхал, вице-президент по инжинирингу данных и монетизации компании GitLab, рассказывает на портале The New Stack о том, почему необходимо фиксировать институциональную логику, лежащую в основе решений, прежде чем она исчезнет.

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

Я наблюдал этот шаблон во всех отраслях, в которых работал. Моя команда в одной крупной компании социальных сетей провела аудит метаданных, который показал, что большинство производственных наборов данных были «осиротевшими», не имеющими принадлежности или избыточными. Ни у кого не было достоверного подсчета работающих API. Традиционные инструменты каталогизации предоставляли устаревшие метаданные по мере их поступления. Чтобы решить эту проблему, мы с нуля создали коннекторы на основе графов, сшили воедино цепочки активов и вернули сотни миллионов долларов экономии.

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

В течение десятилетий потеря этой логики была приемлемой ценой. Команды могли восстановить ее благодаря опыту и адаптации сотрудников. Однако решения становились непоследовательными, и эта непоследовательность оставалась невидимой. Теперь ИИ-агенты выявляют эти несоответствия.

Стена, в которую утыкается каждый агент

Рассмотрим, что происходит, когда ИИ-агент, обрабатывающий продление договора с клиентом, должен решить, одобрить ли 20%-ную скидку, даже если политика ограничивает скидку при продлении 10%. Хорошо оснащенный агент может получить данные о доходах клиента из CRM, проверить открытые заявки в службу поддержки, просмотреть недавние инциденты и оценить соответствующий документ политики. Это видимый слой.

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

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

Почему действующие игроки рынка не могут закрыть этот пробел

Описанная проблема носит архитектурный характер, а не является продуктовым пробелом, который любой поставщик может закрыть с помощью пункта дорожной карты.

Операционные системы учета — CRM, ERP и HRIS — сохраняют текущее состояние. Когда исключение утверждается, контекст, который его обосновывал, исчезает. Вы можете видеть, что скидка изменилась, но вы не можете воспроизвести состояние мира в момент, когда кто-то совершил звонок, запросил скидку или использовал ее в качестве прецедента для будущих обоснований.

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

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

Отсутствующее измерение

Большинство корпоративных систем управления знаниями отслеживают, какие сущности существуют, как они связаны друг с другом и как их состояния меняются со временем.

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

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

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

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

Что со всем этим делать?

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

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

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

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

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

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

Заключение

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

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

Организационный айсберг реален, и агенты уже здесь. Каждое решение, принятое вашей организацией без фиксации его логики, — это институциональные знания, которые вы никогда не сможете вернуть.