ИИ-архитектура, ориентированная на намерения, удваивает успешность запросов

У современного клиента есть лишь одна действительно важная потребность: получить именно то, что ему нужно, и тогда, когда это нужно. Стандартная модель RAG (эмбеддинг + поиск + языковая модель) неверно истолковывает намерения, перегружает контекст и упускает из виду актуальность информации, снова и снова заводя клиентов в тупик.

Вместо этого архитектура с приоритетом намерений (intent-first) использует легковесную языковую модель для анализа запроса на предмет намерений и контекста перед тем, как обратиться к наиболее релевантным источникам контента (документам, API, людям).

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

Недавнее исследование Coveo показало, что 72% корпоративных поисковых запросов не дают осмысленных результатов с первой попытки, а по прогнозам Gartner, большинство внедрений разговорного ИИ не оправдывают ожиданий бизнеса.

Проблема кроется не в базовых моделях. Дело в архитектуре вокруг них.

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

Это облачно-нативный архитектурный паттерн, который я называю Intent-First (с приоритетом намерений). И он меняет то, как компании создают ИИ-интерфейсы.

Проблема на 36 миллиардов долларов 

По прогнозам Gartner, к 2032 году объем мирового рынка разговорного ИИ вырастет до 36 миллиардов долларов. Компании стремятся урвать свой кусок пирога. Демонстрации невероятно привлекательны. Подключите языковую модель к своей базе знаний — и вот она уже способна отвечать на вопросы клиентов на естественном языке. Магия. 

А затем начинается этап продакшена. 

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

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

Проблема заключается не в сбое технологий искусственного интеллекта. Это архитектурный сбой.

Почему стандартные RAG-архитектуры терпят неудачу 

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

1. Разрыв в намерениях

Намерение — это не контекст. Но стандартные архитектуры RAG этого не учитывают.

Допустим, клиент пишет: «Я хочу отменить». Что это значит? Отменить услугу? Отменить заказ? Отменить встречу? Во время развертывания нашей телекоммуникационной системы мы выяснили, что 65% запросов со словом «отменить» на самом деле касались заказов или встреч, а не отмены услуг. У системы RAG не было возможности понять это намерение, поэтому она неизменно возвращала документы об отмене услуг.

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

2. Затопление контекстом 

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

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

3. Слепоя зона актуальности 

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

Архитектурный паттерн Intent-First 

Архитектурный паттерн Intent-First — это зеркальное отражение стандартного развертывания RAG. В модели RAG вы сначала выполняете поиск, а затем маршрутизацию. В модели Intent-First вы сначала классифицируете запрос, а затем маршрутизируете его или ищете информацию.

Архитектуры Intent-First используют легковесную языковую модель для анализа запроса на предмет намерений и контекста перед отправкой его к наиболее релевантным источникам контента (документам, API, агентам).

Сравнение: Intent-first против стандартного RAG

Облачно-нативная реализация

Паттерн Intent-First разработан для облачно-нативного развертывания с использованием микросервисов, контейнеризации и эластичного масштабирования для обработки корпоративных объемов трафика.

Сервис классификации намерений

Классификатор определяет намерение пользователя до того, как произойдет поиск:

АЛГОРИТМ: Классификация намерений

ВХОДНЫЕ ДАННЫЕ: user_query (строка)

ВЫХОДНЫЕ ДАННЫЕ: intent_result (объект)

1. ПРЕДВАРИТЕЛЬНАЯ ОБРАБОТКА запроса (нормализация, раскрытие сокращений)

2. КЛАССИФИКАЦИЯ с помощью трансформерной модели:

   — primary_intent ← model.predict(query)

   — confidence ← model.confidence_score()

3. ЕСЛИ confidence < 0.70 ТО

   — ВЕРНУТЬ {

       requires_clarification: true,

       suggested_question: generate_clarifying_question(query)

     }

4. ИЗВЛЕЧЬ поднамерение (sub_intent) на основе primary_intent:

   — ЕСЛИ primary = «ACCOUNT» → проверить ORDER_STATUS, PROFILE и т. д.

   — ЕСЛИ primary = «SUPPORT» → проверить DEVICE_ISSUE, NETWORK и т. д.

   — ЕСЛИ primary = «BILLING» → проверить PAYMENT, DISPUTE и т. д.

5. ОПРЕДЕЛИТЬ целевые источники (target_sources) на основе маппинга намерений:

   — ORDER_STATUS → [orders_db, order_faq]

   — DEVICE_ISSUE → [troubleshooting_kb, device_guides]

   — MEDICATION → [formulary, clinical_docs] (здравоохранение)

6. ВЕРНУТЬ {

     primary_intent,

     sub_intent,

     confidence,

     target_sources,

     requires_personalization: true/false

   }

Контекстно-зависимая служба поиска

Как только намерение классифицировано, поиск становится адресным:

АЛГОРИТМ: Контекстно-зависимый поиск

ВХОДНЫЕ ДАННЫЕ: query, intent_result, user_context

ВЫХОДНЫЕ ДАННЫЕ: ranked_documents

1. ПОЛУЧИТЬ конфигурацию источника для intent_result.sub_intent:

   — primary_sources ← источники для поиска

   — excluded_sources ← источники, которые нужно пропустить

   — freshness_days ← максимальный возраст контента

2. ЕСЛИ намерение требует персонализации И пользователь аутентифицирован:

   — ПОЛУЧИТЬ account_context из сервиса учетных записей

   — ЕСЛИ intent = ORDER_STATUS:

       — ПОЛУЧИТЬ recent_orders (за последние 60 дней)

       — ДОБАВИТЬ к результатам

3. ПОСТРОИТЬ поисковые фильтры:

   — content_types ← только primary_sources

   — max_age ← freshness_days

   — user_context ← account_context (если доступно)

4. ДЛЯ КАЖДОГО источника В primary_sources:

   — documents ← vector_search(query, source, filters)

   — ДОБАВИТЬ documents в результаты

5. ОЦЕНИТЬ каждый документ:

   — relevance_score ← векторное сходство × 0.40

   — recency_score ← вес актуальности × 0.20

   — personalization_score ← соответствие пользователю × 0.25

   — intent_match_score ← соответствие типу × 0.15

   — total_score ← СУММА вышеуказанного

6. РАНЖИРОВАТЬ по убыванию total_score

7. ВЕРНУТЬ топ-10 документов

Особенности для сферы здравоохранения

В медицинских системах паттерн Intent-First включает дополнительные меры предосторожности:

Категории медицинских намерений:

• Клинические: Вопросы о лекарствах, симптомах, инструкции по уходу

• Покрытие: Льготы, предварительное согласование, рецептурный справочник

• Запись на прием: Записи, доступность врачей

• Биллинг: Претензии, платежи, выписки

• Учетная запись: Профиль, иждивенцы, удостоверения личности

Критически важный защитный механизм: Клинические запросы всегда содержат отказ от ответственности и никогда не заменяют профессиональную медицинскую консультацию. Сложные клинические вопросы система перенаправляет на живую поддержку.

Обработка крайних случаев (edge cases)

Именно на крайних случаях системы дают сбой. Паттерн Intent-First включает специальные обработчики:

Ключевые слова для определения раздражения:

• Гнев: «ужасно», «худший», «ненавижу», «абсурд»

• Время: «часы», «дни», «все еще жду»

• Неудача: «бесполезно», «никакой помощи», «не работает»

• Эскалация: «поговорить с человеком», «живой человек», «менеджер»

При обнаружении разочарования поиск полностью пропускается, и происходит перенаправление на живую поддержку.

Межотраслевое применение

Паттерн Intent-First применим везде, где предприятия развертывают разговорный ИИ для работы с разнородным контентом:

Результаты

После внедрения архитектуры Intent-First на платформах телекоммуникаций и здравоохранения:

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

Стратегическая необходимость

Рынок разговорного ИИ продолжит переживать сверхвысокий рост.

Но компании, которые строят и развертывают типичные архитектуры RAG, будут продолжать терпеть неудачу… снова и снова.

ИИ будет уверенно выдавать неверные ответы, пользователи будут отказываться от цифровых каналов из-за разочарования, а затраты на поддержку будут расти, а не снижаться.

Intent-First — это фундаментальный сдвиг в том, как предприятиям необходимо проектировать и строить ИИ-общение с клиентами. Дело не в лучших моделях или большем объеме данных. Дело в понимании того, чего хочет пользователь, прежде чем пытаться ему помочь.

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

Демонстрация — это просто. Продакшен сложен. Но формула успеха в продакшене ясна: Intent First (Сначала намерения).

Сриниваса Редди Хулебееду Редди — ведущий инженер-программист и корпоративный архитектор.

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее в рамках нашей программы гостевых постов и ознакомьтесь с нашими рекомендациями , если вы хотите написать собственную статью!