Данные могут быть правильными. Определение может быть правильным. Но ответ искусственного интеллекта все равно может быть неверным. ИИ-аналитикам необходим контекст принятия решения до того, как поступит вопрос, пишет на портале InformationWeek Пол Вахтлер, старший вице-президент Exiger по ИИ, данным и стратегии.

Если вы работаете с данными, вы, вероятно, сталкивались с примерно с таким вопросом от вашего руководства: «Можем ли мы запустить LLM на наших данных и заставить ее проанализировать все за нас?».

Это нормальный вопрос. Руководители хотят получать ответы быстрее, не отправляя каждый вопрос через BI-очередь. Они видят, что могут делать LLM с текстом, и предполагают, что тот же принцип должен применяться и к бизнес-данным.

Проблема в том, что корпоративные данные не объясняют сами себя.

Я наблюдал это во время тестирования ИИ-аналитика на реальных бизнес-вопросах. Меня интересовало, какие клиенты представляют наибольший риск в текущем квартале или какие возможности с наибольшей вероятностью будут закрыты в следующие 30 дней. Система уверенно называла клиентов или возможности. Некоторые ответы были неверными; некоторые — вымышленными; а другие имели мало отношения к вопросу.

Система выдавала ответы, не понимая масштаба запроса или того, что бизнес подразумевает под «аккаунт подвержен риску» и «аккаунт вероятно будет закрыт». Она также не знала, означают ли «показатели текущего квартала» данные на сегодня или ожидаемые результаты к концу квартала.

ИИ-аналитик не может понять бизнес лишь благодаря потому, что у него есть доступ к хранилищу данных. Он может написать SQL-запрос и вернуть число, которое выглядит правдоподобным. Риск заключается в том, что ему приходится где-то брать бизнес-логику, лежащую в основе ответа. Если компания не определила эту логику, модель сама заполнит пробел.

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

Во многих компаниях аналитик был семантическим слоем.

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

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

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

Данные могут быть правильными. Определение может быть правильным. Ответ все равно может быть неверным.

За пределами семантического слоя

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

Этот контекст также меняется со временем. Определение, утвержденное в начале квартала, может перестать соответствовать прогнозу после его изменения или корректировки руководством принимаемого решения. Система должна знать, какой контекст актуален, а какие предположения устарели. В противном случае она может правильно применить устаревшее предположение и выдать неверный ответ.

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

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

Владельцы бизнеса не исчезают

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

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

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

Эта ответственность лежит на владельце бизнеса. Инженеры могут правильно построить систему, и система может работать точно так, как задумано, даже если лежащие в её основе предположения неверны.

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