Amazon Lex добавил Assisted NLU: как LLM повышают точность ботов без ручного тюнинга — VogueTech

Что нового

Amazon добавила в Amazon Lex функцию Assisted NLU — это надстройка над стандартным NLU, которая использует большие языковые модели (LLM), чтобы лучше понимать естественную речь пользователей.

Ключевые факты:

Assisted NLU работает поверх существующего Amazon Lex и входит в стандартную цену сервиса — отдельной оплаты за LLM нет.
Поддерживаются два режима работы:
- Primary — все пользовательские сообщения обрабатывает LLM.
- Fallback — сначала работает классический NLU Lex, LLM подключается только при низкой уверенности или перед переходом к FallbackIntent.
Заявленные средние метрики Assisted NLU по реальным сценариям:
- 92% точности классификации интентов.
- 84% точности извлечения слотов.
По отзывам клиентов после включения Assisted NLU:
- рост точности классификации интентов на 11–15%;
- 23,5% меньше ответов‑заглушек (fallback);
- 30% лучше обработка «шумных» запросов с опечатками и ошибками.
Assisted NLU включает три связанных компонента:
- режимы Primary и Fallback;
- улучшенную работу со слотами (многослотные фразы, сложные формулировки);
- дизамбигуацию интентов (выбор между несколькими подходящими интентами с понятным вопросом пользователю).

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

Как это работает

Assisted NLU — это не отдельный бот, а режим работы Amazon Lex, где к классическому ML‑движку добавляется LLM.

Архитектура на высоком уровне

Пользователь отправляет фразу в бота Amazon Lex.
Lex применяет обычную ML‑модель NLU, которая обучена на ваших примерах (utterances), интентах и слотах.
В зависимости от режима:
- Primary: LLM сразу анализирует фразу и решает, какой интент выбрать и какие слоты извлечь.
- Fallback: сначала работает стандартный NLU. Если уверенность низкая или результат ведёт к FallbackIntent, Lex вызывает LLM как «второе мнение».
LLM жёстко ограничен определением бота:
- он может выбрать только один из уже существующих интентов;
- он может заполнить только заранее описанные слоты;
- он не может создать новый интент, вызвать произвольный код или сгенерировать открытый текстовый ответ пользователю.
Результат (интент + слоты) возвращается в Lex, который продолжает сценарий, как обычно.

Как LLM использует описания интентов и слотов

Assisted NLU трактует описания интентов и слотов как промпт для LLM. Ключевой принцип:

Интент описывается как цель действия.
Слот описывает конкретный кусок информации, который нужно вытащить из фразы.

Рекомендуемый формат описания интента:

«Intent to [глагол‑действие] [объект] [контекст/ограничения]»

Примеры:

Intent to book a hotel room for overnight accommodation
Intent to cancel an existing hotel booking
Intent to modify dates of an existing hotel reservation

LLM читает эти описания и сравнивает их с пользовательской фразой. За счёт этого он лучше различает похожие действия:

«book», «cancel», «modify», «check» — разные группы интентов;
«hotel», «flight», «car» — разные объекты;
контекст вроде «due to medical emergency» против «for schedule conflict» позволяет по одной и той же фразе «cancel my flight» понять, какие бизнес‑правила применить.

Слоты как подсказка для извлечения данных

Слот в Assisted NLU — это не только тип (AMAZON.Number, AMAZON.Date и т.п.), но и текстовое описание, которое помогает LLM понять, что именно нужно вытащить.

Шаблон описания слота:

[Что слот захватывает] [контекстные ограничения] [подсказка по формату/значениям]

Примеры:

Check-in date for the hotel reservation, not the checkout or booking date — LLM понимает, что в фразе «December 15th through the 18th» нужно взять именно дату заезда.
Three-letter ISO currency code such as USD, EUR, or JPY — LLM может преобразовать «euros» в EUR без списка всех валют в кастомном слоте.
Для AMAZON.AlphaNumeric с аэропортами: A valid IATA airport code (for example, SEA, JFK, LAX) — LLM сможет из «I'm flying out of Seattle» извлечь SEA.

Режимы Primary и Fallback

Primary mode:

LLM — основной движок для каждой фразы.
Подходит для новых ботов, где у вас мало примеров (меньше 20 примерных utterances на интент).
Упрощает старт: не нужно долго собирать корпус фраз, достаточно аккуратно описать интенты и слоты.

Fallback mode:

Сначала работает классический NLU Lex.
LLM вызывается только если:
- уверенность в предсказанном интенте низкая;
- или запрос ушёл бы в FallbackIntent.
Подходит для уже обученных ботов с высокой точностью (например, ~95%), где вы хотите закрыть только «хвост» сложных формулировок.

Amazon предлагает мониторить метрику fulfilledByAssistedNlu в CloudWatch:

если в Fallback‑режиме LLM подключается более чем в 30% запросов, стоит подумать о переходе на Primary ради стабильности поведения.

Дизамбигуация интентов

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

Для этого:

Lex использует описания интентов как основной сигнал, какие варианты показать;
вы задаёте понятные display names, которые видит пользователь (например, Change my reservation dates вместо ModifyReservationDates);
вы ограничиваете число вариантов (рекомендуют 3–4), чтобы не перегружать выбор.

Пример сообщения пользователю:

«I can help you with hotel reservations. Did you want to:»

— Change my reservation dates
— Cancel my reservation
— View my reservation details

Что это значит для вас

Для каких задач Assisted NLU полезен

Assisted NLU закрывает типичные проблемы продакшн‑ботов:

Пользователи формулируют один и тот же запрос десятками способов.
В одной фразе смешаны несколько слотов: даты, тип комнаты, локация.
Много опечаток и разговорной речи.
Часто звучат двусмысленные фразы вроде «I need help with my reservation».

Где это особенно полезно:

Новые боты без большого корпуса фраз
- Вы только запускаете голосового или текстового ассистента.
- У вас нет исторических логов, чтобы собрать 50+ примеров на каждый интент.
- Включаете Primary, аккуратно описываете интенты и слоты — и получаете рабочий NLU без долгой разметки.
Сложные домены с богатым языком
- Здравоохранение: «I need to see someone about my knee», «Book me with a cardiologist next week».
- Туризм и отели: «Book me a suite at your downtown Seattle location for December 15th through the 18th».
- Финансы: разные формулировки запросов баланса, переводов, историй операций.
Уже работающие боты, которые спотыкаются на краевых кейсах
- Бот банка уже даёт ~95% точности.
- Но иногда падает в fallback на фразы вроде «What's my balance looking like?» вместо «Check balance».
- Включаете Fallback, и LLM подбирает корректный интент в этих ситуациях.
Проекты, где важно быстро улучшить UX без полной переразметки
- Вы хотите снизить число повторных вопросов пользователю.
- Уменьшить долю FallbackIntent.
- Сделать разговор ближе к естественному языку, не переписывая весь бот.

Где Assisted NLU не спасёт

Assisted NLU не заменяет хорошую архитектуру диалогов.

Не стоит рассчитывать, что LLM решит такие проблемы:

Плохой дизайн интентов: один интент «book and manage hotel reservations» вместо разделения на Book, Modify, Cancel.
Слишком пересекающиеся описания: «Check account balance» и «Check account transactions» без чёткого разграничения.
Отсутствие бизнес‑логики: LLM не знает ваши правила отмены, лимиты, тарификацию — он только выбирает интент и слоты.
Нарушение безопасности: LLM не может выйти за рамки бота, но если вы дадите неверные описания или доступы, риски остаются на вашей стороне.

Ограничения по доступности

Amazon Lex — облачный сервис AWS. Для России доступ к AWS может требовать VPN и юридическую проверку со стороны вашей компании. Перед использованием нужно оценить риски, требования комплаенса и хранение данных за рубежом.

Практический чек‑лист: как использовать Assisted NLU

Решите, какой режим вам нужен:
- Новый бот или мало данных → начинайте с Primary.
- Стабильный бот с хорошей точностью → включайте Fallback и смотрите на fulfilledByAssistedNlu.
Перепишите описания интентов:
- Стартуйте с шаблона Intent to [глагол] [объект] [контекст].
- Берите формулировки из реальных пользовательских фраз.
- Не смешивайте несколько действий в одном интенте.
Настройте описания слотов:
- Объясните, что именно слот захватывает.
- Уточните, как отличить его от других похожих слотов (например, два AMAZON.Number).
- Добавьте примеры форматов значений, если это помогает (IATA, ISO‑коды и т.п.).
Протестируйте через Test Workbench:
- Соберите набор фраз с опечатками, разговорными выражениями и неполными запросами.
- Прогоните через локаль бота и alias, где включён Assisted NLU.
Внедряйте через версии и alias:
- Меняйте описания в Draft.
- Тестируйте на TestBotAlias.
- Создавайте версию и выносите на BETA/PROD через alias.
Следите за метриками в проде:
- Включите conversation logs.
- Мониторьте fulfilledByAssistedNlu и nluConfidence.
- Смотрите, какие интенты чаще всего попадают в дизамбигуацию.

Место на рынке

Amazon в этом релизе делает с Lex примерно то же, что уже происходит в других платформах диалоговых ассистентов: добавляет LLM как дополнительный слой понимания.

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

Роль LLM:
- В Assisted NLU LLM работает только как классификатор и экстрактор в рамках заранее заданной схемы бота.
- Он не генерирует свободный текст и не может сам «придумать» новый интент или действие.
- Это ближе к классическим enterprise‑ботам, чем к «чату с GPT‑4».
Модель оплаты:
- Assisted NLU идёт в составе стандартного тарифа Amazon Lex, отдельная поминутная или потоковая тарификация за LLM не описана.
- Для команд, которые уже платят за Lex, это добавление функциональности без пересмотра бюджета под LLM.
Интеграция с экосистемой AWS:
- Логи и метрики через CloudWatch.
- Контроль доступа через IAM (ограничение lex:UpdateBotLocale, lex:UpdateIntent, lex:UpdateSlot).
- Версионирование и alias‑подход для безопасного деплоя.

С точки зрения продуктовой стратегии это ближе к «умному NLU внутри существующего конструктора ботов», чем к универсальному LLM‑чату. Если вы уже на AWS и строите ботов через Lex, Assisted NLU логично использовать как стандартную опцию.

Как настроить Assisted NLU

Включение через консоль

Откройте Amazon Lex Console.
Зайдите в нужный бот и выберите локаль (locale), с которой вы работаете.
В настройках локали найдите раздел Assisted NLU.
Включите Assisted NLU переключателем.
Выберите режим:
- Primary или
- Fallback.
Сохраните и пересоберите бота.

Подробные шаги, включая скриншоты и параметры, описаны в разделе Enabling Assisted NLU в Amazon Lex Developer Guide.

Включение через API

Для программной конфигурации Amazon предлагает использовать NluImprovementSpecification в API Lex. Вызовы с этим параметром позволяют включить Assisted NLU и задать режим на уровне локали бота.

(Сам код и конкретные примеры запросов в материале не приводятся. За синтаксисом и всеми полями нужно идти в API Reference для NluImprovementSpecification.)

Практика: как писать описания интентов и слотов

Интенты: что делать, а что нет

Делайте:

Начинайте с Intent to... и чёткого глагола действия:
- Intent to book a hotel room for overnight accommodation.
Собирайте описание из реальных фраз пользователей:
- «book a room», «reserve a suite» →
- Intent to book or reserve a hotel room or suite for an overnight stay.
Добавляйте доменный контекст, если есть похожие интенты:
- Intent to book a hotel room on StayBooker.
Используйте лексику, которой пользуются ваши клиенты:
- если они говорят «reservation», а не «booking», пишите «reservation».
Проверяйте описания на краевых кейсах:
- убедитесь, что «I need a place to stay» попадает в BookHotel.

Не делайте:

Не оставляйте пустые описания или заглушки:
- TBD, Intent 1 — бесполезны для LLM.
Не смешивайте несколько действий в одном интенте:
- Intent to book and manage hotel reservations — разбейте на Book, Modify, Cancel.
Не используйте пересекающийся язык без дополнительных уточнений:
- «Check account balance» и «Check account transactions» должны чётко различаться по описанию.
Не вшивайте конкретные значения слотов в описание интента:
- Intent to book a hotel in Seattle for 2 nights — слишком узко, усложняет обобщение.

Слоты: как помочь LLM извлекать правильные значения

Делайте:

Используйте описания, чтобы заменить длинные списки значений, когда это возможно:
- AMAZON.AlphaNumeric + A valid IATA airport code (for example, SEA, JFK, LAX).
Чётко различайте слоты одного типа:
- Number of nights for the hotel stay vs Number of guests checking in.
Привязывайте слот к роли в интенте:
- Date of check-in for the hotel booking intent.
Описывайте бизнес‑ограничения:
- Number of nights in the hotel stay — это длительность, а не количество комнат.
Для кастомных слотов с расширенным разрешением значений объясняйте смысл каждого значения:
- Slot RoomType со значениями Standard, Deluxe, Suite и описанием:
  - Type of hotel room. Standard is a basic room, Deluxe is a mid-tier room with extra amenities, Suite is the top-tier luxury room with the most space and best features and kitchen attached.
- Тогда фразы «a room with a kitchen» или «largest room» будут резолвиться в Suite.

Не делайте:

Не оставляйте кастомные слоты без описания:
- слот Payment без пояснений не даёт LLM понимания форматов.
Не рассчитывайте только на тип слота:
- AMAZON.Number без описания не скажет, это ночи, гости, комнаты или номер брони.
Не противоречьте типу слота в описании:
- писать «account number», но использовать AMAZON.Number, если номер содержит буквы.
Не забывайте обновлять описания при изменении бизнеса:
- если вы начали работать не только по США, уберите из описания «United States only`.

Тестирование и итерации

Что тестировать в Test Workbench

Фокус — на том, где LLM даёт наибольший выигрыш:

Краевые кейсы формулировок:
- Опечатки и ошибки: i wanna book an hotell.
- Разговорные выражения: hook me up with a room downtown.
- Двусмысленные запросы: I need transportation.
- Неполные фразы: booking for next week.
Вариации слотов:
- Для встроенных слотов:
  - разные форматы дат: next Tuesday, the 15th;
  - синонимы локаций: NYC, New York City;
  - имена: Bob vs Robert;
  - имейлы в разных форматах: john dot doe at gmail dot com.
- Для кастомных слотов:
  - соответствие пользовательских формулировок вашим значениям, особенно в режиме расширенного резолвинга (например, largest room → Suite).
Защита от «злых» промптов:
- LLM не может выйти за рамки определения бота, но всё равно полезно проверить, что странные или враждебные фразы стабильно попадают в FallbackIntent.

При запуске тестов в Test Workbench нужно выбрать бот и alias, где включён Assisted NLU (Primary или Fallback). Иначе вы будете тестировать старый NLU.

Как разбирать результаты

После прогона тестов смотрите на pass rate по интентам:

0–30% — высокий приоритет:
- переписывайте описание интента;
- ищите пересечения с интентами, куда чаще всего ошибочно попадают фразы.
30–70% — средний приоритет:
- анализируйте, какие типы фраз чаще всего проваливаются;
- уточняйте описания, добавляйте контекст.
70–100% — низкий приоритет:
- можно ограничиться мелкой доводкой.

Полезно выгрузить детальный отчёт и поработать с такими полями:

Expected Intent vs Actual Intent — где именно произошла ошибка классификации.
Actual Output Slot values vs expected — какие слоты извлеклись неверно.
User Utterance — исходная фраза пользователя.
Error Message — причина провала.
Conversation Result — прошла ли вся беседа целиком, а не только один шаг.

Итеративное улучшение описаний

Рабочий цикл выглядит так:

Экспортируете результаты теста.
Фильтруете по проваленным фразам.
Смотрите, в какой интент они попали вместо ожидаемого.
Сравниваете описания обоих интентов.
Переписываете описание «провального» интента так, чтобы сильнее отличать его от «конкурента».
Запускаете тот же тестовый набор ещё раз и проверяете изменения.

Версионирование и безопасность изменений

Amazon рекомендует использовать стандартный механизм версий и alias в Lex:

Правите описания в Draft‑версии бота.
Тестируете через TestBotAlias.
Когда качество устраивает — создаёте номерную версию.
Переключаете alias BETA на новую версию для пилота.
После успешного пилота переводите alias PROD.
Если что‑то пошло не так — возвращаете PROD на предыдущую версию.

Для контроля доступа используйте IAM‑политики:

ограничьте права на lex:UpdateBotLocale, lex:UpdateIntent, lex:UpdateSlot только доверенным разработчикам;
не давайте широкие права на изменение описаний всем подряд — это напрямую влияет на точность NLU и поведение бота.

Мониторинг в продакшене

Включите conversation logs для прод‑alias и отслеживайте ключевые поля:

fulfilledByAssistedNlu — флаг, показывающий, обрабатывал ли LLM классификацию или слоты;
nluConfidence — числовая уверенность в выбранном интенте.

По этим данным можно понять:

как часто Assisted NLU реально помогает;
не выросла ли доля низкоуверенных ответов;
какие фразы чаще всего уходят в дизамбигуацию или FallbackIntent.

Assisted NLU в Amazon Lex — это инструмент для тех, кто уже строит или планирует строить ботов на AWS и хочет повысить точность понимания естественной речи без полного перехода на «чистый LLM‑чат». Вы получаете улучшенную классификацию и извлечение слотов, но при этом сохраняете предсказуемость и контроль над сценариями, которые так важны в продакшн‑средах — от банков до медицины и туризма.