Развитие ИИ переворачивает привычные подходы к работе с данными, и дело не только в пресловутом Garbage in — Garbage out. Да, плохие данные заставляют ИИ ошибаться, но это только вершина айсберга. Отсутствие понятных для LLM смыслов и связей в данных приводит к тому, что модели отвечают уверенно и правдоподобно, но часто не на тот вопрос, что был задан, и опираясь не на ту информацию, которая нужна в конкретном случае. Что с этим делать и какие технологические решения придут в дополнение к уже известным инструментам, размышляет Никита Назаров, CTO IT-компании HFLabs.
Работа с LLM: контекст решает
Еще недавно путь от запроса пользователя к полю в конкретной табличке с данными был весьма прозрачным и фиксировался в конкретном отчете, ETL или ML-модели. Но современные LLM дают ощущение магии: можно простым языком задавать любые вопросы, а LLM достроит недостающий контекст и выдаст быстрый и понятный ответ.
Но в этой простоте кроется главная ловушка: в поиске ответа модель может придумывать что‑то свое и выдавать совсем не то, что просил пользователь. Усугубляет проблему общая недетерминированность модели: каждая следующая итерация обработки конкретного вопроса дает разный результат, поэтому определить причину галлюцинаций и «отладить» поведение модели очень сложно.
Одновременно мы видим, что развитие ИИ резко увеличило стоимость семантического долга — несоответствие между тем, что данные формально означают, и тем, что они на самом деле представляют или их фактической интерпретацией в системе, стремительно растет. До активного использования LLM проблема семантического долга, конечно, тоже была, но решалась, как правило, в диалоге, чья же версия правильная. С машинами все сложнее: модель бодро рапортует, что она разобралась, и уличить ее в потере или замене смысла не всегда просто. Данные могут пройти формальные проверки и массово распространиться по организации, запуская цепочки неверных решений.
Американский ученый, профессор Массачусетского технологического университета Майкл Стоунбрейкер в одной из статей говорит о том, что без дополнительных знаний, которые существуют только в виде локального контекста, достоверная работа LLM невозможна. Простой пример: корпусы университета в повседневной жизни именуются локальными алиасами, при этом в любой документации или отчетности фигурируют в виде полноценных адресов. Провести между ними связь невозможно без носителя маппинга алиас<->адрес.
Посмотрим на это с точки зрения крупного российского бизнеса. Что, например, значит запрос руководителя в банке «покажи мне клиентов под риском ухода»? Для начала нужно понять, кто такой клиент — физлицо, домохозяйство, компания или вообще речь о договорах? Что значит риск ухода — закрытие продукта, вывод денег или прекращение всех отношений? Данные, которые при ответе на такой запрос возьмет LLM из внутренних систем, могут быть совершенно корректны, но без заранее заданных смыслов запрос не имеет единственного ответа.
Онтология и семантика: главные принципы
Нельзя сказать, что эту проблему до сих пор не пытались решить. И гардрейлы, и харнессы — известные инструменты, цель которых — проверить ответ модели на достоверность и так или иначе ограничить ее «творчество». Но система ограничений способна сама по себе накапливать семантический и технический долг, поэтому, на мой взгляд, эти инструменты не должны быть первой линией защиты: им нечего проверять, если модель изначально не понимает, о чем ее спрашивают. Естественное решение — сначала добавить контекст, который уменьшает неоднозначность, и только потом, на конкретном плане исполнения, оставить точечный контроль там, где цена ошибки высока (например, требуется одобрение человека перед действием).
Сложность в том, что сегодня ни одна из традиционных систем не может это обеспечить (за исключением, пожалуй, решений от Palantir, не представленных на российском рынке). MDM отвечает за единую, согласованную и достоверную версию ключевых бизнес-сущностей (клиент, продукт и др), Data Catalog — за то, где лежат данные, КХД — за их хранение и анализ. BI semantic layer хорошо стандартизирует показатели для отчетности, граф показывает связи между разными сущностями. А для успешного использования LLM нужно собрать все это в один пайплайн или продукт.
Речь про особые категории решений — онтологию и семантический слой. И если онтология — знакомый бизнесу инструмент с проверенными стандартами, то подходы к семантическому слою для LLM только формируются. Сразу задам определения, которыми руководствуемся мы в HFLabs.
- Онтология — машиночитаемое описание предметной области: какие сущности есть, какие отношения между ними допустимы и что они означают.
- Семантический слой — исполняемый переводчик между языком пользователя, онтологией и реальными данными (или графом знаний)
Ключевая задача онтологии и семантического слоя — дать LLM тот самый контекст, чтобы она не догадывалась о контенте таблиц и не трактовала по своему усмотрению неструктурированные объекты (например, истории переписки в чате поддержки банка), а имела управляемую трансляцию в виде:
- вопрос,
- общий маппинг слов из него на объекты и таблицы,
- план исполнения,
- одобрение,
- исполнение.
Возвращаясь к примеру с «клиентами под риском ухода»: при наличии онтологии система не пытается угадать, а на шаге маппинга либо понимает, кто спрашивает и какой контекст для него задан, либо явно уточняет — «под клиентом вы имеете в виду физлицо, договор или домохозяйство? под риском ухода — закрытие продукта или полный отток?.
Отдельно стоит сказать о неявных связях — это дополнительный эффект от связки MDM, графа и семантики: способность системы самой предлагать выводы, которые никто явно не запрашивал. Так, при наличии графа связей и онтологии, описывающей значимые атрибуты (состав семьи, история перемещений), система может сама заметить, что семья многодетная, и предложить соответствующую пакетную услугу, то есть работать не только реактивно (отвечая на вопросы), но и проактивно (подсказывая, о чем стоило бы спросить). Или она оценит, что смена оператора телефона на номер с другим регионом и покупка авиабилетов в один конец иногда может означать переезд, а иногда турпоездку, и сделает предложения для конкретной жизненной ситуации.
Как мы учим ИИ понимать клиентов
Мы в HFLabs строим исполняемый семантический слой поэтапно. Начали с фундамента и хорошо знакомого нам домена — клиентских данных. В основе семантического слоя — решение «Орбита», которое собирает полный контекст о клиенте в единый профиль и граф связей. Именно на граф опирается слой трансляции: когда сейл-менеджер спрашивает «кто в этой компании может заблокировать сделку», система сопоставляет вопрос с полем «роль» в профиле и отвечает по конкретным записям, а не додумывает.
В профиль «Орбиты» попадают бизнес-атрибуты (сделки, транзакции, история обращений и другие данные, важные для конкретной компании), контекст взаимодействия, дополнительная информация о юрлицах и связанных с ними физлицах. При этом «Орбита» не только накапливает атрибуты клиентов, но и строит граф связей между ними. Для LLM это наиболее удобный тип данных: граф делает связи доступными для обхода, не скрывая их в соединениях таблиц. Это помогает выявлять скрытые закономерности, строить больше гипотез и быстрее их проверять.
Чтобы убедиться в этом, мы сделали пилотный проект с нашими партнерами — компанией DaData. Для этого собрали для сейл-команды единый интерфейс по корпоративным клиентам из пяти разрозненных систем. В него вошли данные из тикет-системы, регистрационная информация по юрлицам, использование продуктов, история оплат, внешние данные из ЕГРЮЛ. В результате вместо 40 тикетов теперь требуется анализ лишь одного саммари по группе клиентов, а время на подготовку письма квалифицированному лиду сократилось вдвое.
Для нас было важно, что саммари строится не по «додуманным» LLM связям, а по зафиксированным в графе фактам. Это и есть первая проверка гипотезы: экономия времени возможна именно потому, что модели не приходится каждый раз заново реконструировать контекст из разрозненных данных. Сейчас мы в поиске других реальных кейсов и приглашаем компании вместе с нами проверять свои гипотезы.
Подводные камни семантики
Есть ли у проектов по онтологии и семантике свои риски и подводные камни? Безусловно. На мой взгляд, они могут скрываться в желании внедрить очередной глоссарий и охватить семантикой сразу весь бизнес.
Вот какие шаги могут завести вас в семантический тупик:
- попытка построить глоссарий, который выглядит как вики-статья и не встроен в реальные процессы;
- стремление распространить принцип «единой версии правды» с базовых атрибутов сущности (как это делает MDM) на ее интерпретационные характеристики — риск ухода, ценность клиента, стадия жизненного цикла. Здесь единственно верного значения часто просто не существует, оно зависит от того, кто и зачем задает вопрос;
- генерация онтологии по таблицам реально существующих систем — получится не описание реальности, а повторное «переваривание» того, что уже было сделано айтишниками и реализовано в виде этих таблиц.
Мы в HFLabs предлагаем концентрироваться на конкретных задачах:
- Выбрать реальный бизнес-процесс: кто, в какой момент и какое решение должен принять на основе данных.
- Собрать реальные вопросы разных ролей к данным.
- Выделить минимальный набор сущностей, событий, отношений, показателей и действий.
- Зафиксировать не одно «правильное» значение терминов, а их значения в разных контекстах.
- Связать понятия с физическими источниками, идентификаторами, периодами действия и происхождением фактов.
Читатель может возразить, что такая последовательность действий для каждого процесса может быть трудоемкой, и от централизованного глоссария — словаря терминов, помогающего людям одинаково понимать или явно различать употребление понятий — все‑таки не уйти. На мой взгляд, такой словарь устареет раньше, чем запустятся процессы по нему, поэтому куда более перспективным выглядит направление «множественной правды», когда мы не согласовываем годами значения терминов через гладиаторские бои департаментов, а позволяем каждому иметь собственную правду и на программном уровне уметь маппировать эти правды друг на друга. При этом у каждого факта всегда должны быть источник, период действия и степень доверия. Множественны здесь не факты, а контексты и правила интерпретации.
Из этого следует и практическое переопределение самой онтологии. Вместо одного согласованного описания предметной области на уровне всей компании мы получаем сеть локальных онтологий — по процессу, по департаменту, по продукту — с явными правилами перевода между ними. Маппинг здесь— работающий эквивалент общего глоссария, только не статичный, а исполняемый.
Допустим, маркетинг решает запустить эксперимент на 5% клиентской базы. А продажи в этот момент видят этот подсчет согласно своему определению клиента и говорят, вы чего — это же 50% наших платящих клиентов! Автоматический маппинг в этот момент позволит подсветить противоречие, и договориться все‑таки придется. Иными словами, мульти-правда не отменяет необходимости договариваться, но переносит договоренность из плоскости «значение термина» в плоскость принятия конкретных решений.
В завершение добавлю, что узкие бизнес-задачи могут решаться и без семантики — RAG или ассистент по одному регламенту прекрасно работают уже сейчас. Но если бизнес развивается, меняются законы, экономическая ситуация и другие условия, то RAG и ассистент по отдельно взятому регламенту будут худшим вариантом «застывшего прошлого». Или же в этот регламент нужно будет постоянно добавлять контексты и исключения из всего, что на него потенциально влияет. Именно поэтому, на мой взгляд, будущее не за единым корпоративным языком, а за сетью (mesh) локальных моделей и переводов между ними.
Эту статью я написал для исследования дата-каталогов и систем управления метаданными центра «Круги Громова». Полную версию исследования можно заказать на russianbi.ru, а за новыми выпусками следить в Telegram-канале.
Если хотите обсудить «Орбиту», пишите на ask@hflabs.ru.
