Повышение точности ботов в Amazon Lex с Assisted NLU

Повышение точности ботов в Amazon Lex начинается с того, как клиенты формулируют запросы в естественной речи. Пользователи выражают один и тот же запрос десятками способов, объединяют несколько деталей в одном предложении и нередко говорят двусмысленно. Функция Assisted NLU в Amazon Lex помогает повысить точность бота, учитывая такие языковые вариации. Традиционные системы понимания естественного языка с этим часто не справляются, из-за чего клиентам приходится повторяться или они прерывают диалог.

Проблема: правила NLU требуют от разработчиков вручную описывать все возможные варианты фраз, а это долго и всё равно оставляет пробелы в покрытии. Бот для бронирования отеля, обученный на фразе «book a hotel», может не сработать, если клиент скажет: «I’d like to reserve accommodations for my trip». Сложные запросы вроде «Book me a suite at your downtown Seattle location for December 15th through the 18th» часто теряют важные детали — тип номера, местоположение и даты. Неясные фразы вроде «I need help with my reservation» заставляют бота гадать, хочет ли пользователь забронировать, посмотреть, изменить или отменить бронь.

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

Assisted NLU, включая Primary mode, Fallback mode и intent disambiguation, входит без дополнительной платы в стандартное ценообразование Amazon Lex.

В этом материале вы узнаете, как эффективно внедрить Assisted NLU. Вы увидите, как улучшить дизайн бота с помощью качественных описаний intents и slots, как проверить реализацию с помощью Test Workbench и как спланировать переход с традиционного NLU на Assisted NLU для новых и уже существующих ботов.

Требования: предполагается, что вы знакомы с концепциями Amazon Lex, включая intents, slots и utterances. Если вы только начинаете работать с Amazon Lex, начните с руководства Getting Started Guide.

Введение в Assisted NLU

Amazon Lex Assisted NLU использует LLM для улучшения классификации intents и разрешения slots. Функция использует имена и описания intents и slots, чтобы понять пользовательский ввод. Она справляется с опечатками, сложными формулировками и извлечением нескольких slots без необходимости вручную описывать каждую вариацию. В среднем Amazon Lex Assisted NLU повышает качество задач natural language understanding, достигая 92% точности классификации intents и 84% точности разрешения slots. Сотни активных клиентов, подключивших Assisted NLU, подтверждают эти улучшения на практике. По отзывам пользователей, точность классификации intents выросла на 11–15%, число fallback-ответов сократилось на 23,5%, а обработка шумного ввода улучшилась на 30%. Ранние пользователи отмечают значимый рост качества своих conversational AI-реализаций, а некоторые уже планируют более широкое внедрение на основе результатов первых тестов. Assisted NLU работает в двух режимах:

• Primary mode: использует LLM как основной механизм обработки каждого пользовательского ввода
• Fallback mode: сначала использует традиционный NLU, а вызов LLM происходит только при низкой уверенности или когда запрос был бы направлен в FallbackIntent

Включить Assisted NLU можно несколькими действиями в консоли Amazon Lex. Откройте настройки локали вашего бота, включите Assisted NLU, выберите нужный режим и соберите бота.

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

Для программной настройки см. справочник API NluImprovementSpecification.

1. Лучшие практики внедрения Assisted NLU

Следующие рекомендации помогут извлечь максимум из Assisted NLU и охватывают выбор режима, написание описаний, оптимизацию slots и intent disambiguation.

1.1 Режимы работы: Primary и Fallback

Primary mode использует LLM для каждого пользовательского ввода. Fallback mode сначала использует традиционный NLU, а вызов LLM происходит только при низкой уверенности или когда запрос был бы направлен в FallbackIntent.

Нужно:

• Используйте Primary mode, если создаёте нового бота или у вас ограничено обучающее данные — менее 20 примеров utterances на intent.
  • Пример: медицинский бот для записи на приём, где пациенты говорят: "I need to see someone about my knee" или "Book me with a cardiologist next week", без необходимости в глубокой инженерии utterances.
• Используйте Fallback mode, если у вас уже есть бот, который и так хорошо работает.
  • Пример: банковский бот с точностью 95%, который иногда ошибается на вариантах вроде "What's my balance looking like?" вместо "Check balance", и LLM помогает закрыть такие крайние случаи.
• Отслеживайте метрику fulfilledByAssistedNlu в Amazon CloudWatch Logs, чтобы выбрать подходящий режим для вашего сценария. Если в Fallback mode LLM обрабатывает более 30% запросов, стоит подумать о переходе на Primary mode ради более предсказуемого поведения.

Не нужно:

• Переходить на Primary mode без A/B-тестирования, если бот уже хорошо работает: можно получить лишнюю задержку без выигрыша в точности.
• Предполагать, что один режим подходит для любого сценария: правильный выбор зависит от распределения данных и языковых паттернов ваших пользователей.

1.2 Создание эффективных описаний intents

Описания intents — это не документация для команды, а запросы к LLM. Это основной сигнал для классификации, и их качество напрямую влияет на точность, так же как качество prompt влияет на результат LLM. Надёжные результаты даёт единый шаблон: Intent to [action verb] [object/entity] [context/constraints]

• «Intent to…» задаёт цель и помогает LLM оценивать, чего пользователь пытается достичь.
• Глаголы действия создают чёткое разделение. Book, cancel, modify и check однозначны и позволяют LLM уверенно различать intents.
• Объекты и сущности уточняют цель. "Book a hotel" vs. "book a car" vs. "book a flight" соответствуют разным пользовательским целям.
• Контекст снимает пограничные случаи. Добавление ограничений вроде "Intent to cancel a flight due to medical emergency" vs. "Intent to cancel a flight for schedule conflict" помогает определить право на освобождение от сборов и правила возврата.

Нужно:

• Начинайте описание с "Intent to...", затем указывайте ясный глагол действия.
  • Пример: "Intent to book a hotel room for overnight accommodation".
• Выводите описания из уже имеющихся sample utterances. Они отражают реальную речь пользователей и дают LLM самый сильный сигнал.
  • Пример: описания вроде "book a room" и "reserve a suite" можно превратить в "Intent to book or reserve a hotel room or suite for an overnight stay".
• Добавляйте контекст домена, если есть похожие intents, которые нужно различать.
  • Пример: "Intent to book a hotel room on StayBooker" помогает уточнить понимание LLM.
• Используйте словарь, который реально применяют пользователи, на основе аналитики разговоров.
  • Пример: если клиенты говорят "reservation", используйте это слово последовательно.
• Проверяйте описания на пограничных формулировках до запуска.
  • Пример: убедитесь, что "I need a place to stay" корректно маршрутизируется в BookHotel.

Не нужно:

• Оставлять описания пустыми или использовать шаблонный текст.
  • Плохой пример: "TBD" или "Intent 1" не дают LLM никакого сигнала.
• Объединять несколько действий в одном intent.
  • Плохой пример: "Intent to book and manage hotel reservations" — лучше разделить на отдельные intents.
• Использовать пересекающуюся лексику в разных intents.
  • Плохой пример: "Check account balance" и "Check account transactions" будут мешать классификации.
• Включать значения slots или конкретные примеры в описание.
  • Плохой пример: "Intent to book a hotel in Seattle for 2 nights" слишком жёстко ограничивает сопоставление.

1.3 Улучшение описаний slots

Описания slots дают LLM контекст о том, какую информацию нужно извлечь и как её интерпретировать. Чем сильнее и конкретнее описание, тем лучше LLM приоритизирует релевантные значения. По мере развития Assisted NLU описания slots будут играть всё более важную роль в решениях по извлечению. Если писать точные описания уже сейчас, бот автоматически будет готов к будущим улучшениям. Эффективный шаблон такой: [Что slot извлекает] [контекстные ограничения] [подсказка по допустимым значениям]

• Что извлекает slot определяет конкретный фрагмент информации, который slot должен взять из пользовательского ввода, например название города, дату или количество.
• Контекстные ограничения сужают область. "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» или «Japanese yen» со стандартным кодом без необходимости хранить полный каталог валют в slot type.

Нужно:

• Используйте описания slots, чтобы извлекать значения без отдельного встроенного slot type.
  • Пример: чтобы захватывать коды аэропортов, используйте AMAZON.AlphaNumeric с описанием "A valid IATA airport code (for example, SEA, JFK, LAX)". LLM использует этот контекст, чтобы извлечь код из естественной речи и сопоставить "I'm flying out of Seattle" с SEA, не перечисляя все значения в пользовательском slot type.
• Если у вас есть два slots AMAZON.Number — например, ночи и гости, — описание важно, чтобы LLM различала похожие slot types.
  • Пример: "Number of nights for the hotel stay" vs "Number of guests checking in" — без них LLM может не понять, в какой slot назначить "3".
• Уточняйте роль slot внутри intent.
  • Пример: "Date of check-in" для intent бронирования отеля снимает неоднозначность между датой заезда, выезда и бронью.
• Задавайте ограничения, которые соответствуют вашим бизнес-правилам.
  • Пример: "Number of nights in the hotel stay" уточняет, что речь идёт о длительности, а не о количестве комнат или гостей.
• Используйте описания slots, чтобы определить смысл каждого значения в пользовательских slots с расширенным разрешением значений.
  • Пример: custom 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" помогает LLM сопоставлять естественную речь с нужной категорией. Если клиент скажет «a room with a kitchen» или «largest room», LLM отнесёт это к Suite на основе смыслового контекста в описании.

Не нужно:

• Оставлять описания slots пустыми, особенно для пользовательских slots.
  • Плохой пример: "Payment" без описания не даёт LLM подсказок о том, какие форматы валюты ожидать.
• Считать, что сам slot type уже даёт достаточно контекста.
  • Плохой пример: AMAZON.Number без описания может означать ночи, гостей, комнаты или номера подтверждения.
• Использовать описания, которые противоречат slot type.
  • Плохой пример: описание "account number" при типе AMAZON.Number может вызвать проблемы при извлечении форматированных номеров счетов.
• Забывать обновлять описания при изменении бизнес-логики.
  • Плохой пример: расширение на международные города при сохранении текста "United States only" в описании.

1.4 Лучшие практики intent disambiguation

Когда один и тот же ввод пользователя может соответствовать нескольким intents, Assisted NLU показывает варианты для уточнения цели. Хорошо спроектированное уточнение снижает трение и удерживает диалог в нужном русле.

Нужно:

• Используйте ясные, разные имена intents и описания без пересечений. Это основные входные данные, по которым LLM принимает решение об уточнении.
  • Пример: "BookHotelRoom" с описанием "Reserve a hotel room for future dates" против "CancelHotelReservation" с описанием "Cancel an existing hotel booking" — чётко разделённые цели.
• Давайте понятные пользователю display names для технических имён intents. Убедитесь, что display names соотносятся с реальным названием intent и ясно его отражают.
  • Пример: имя intent "ModifyReservationDates" с display name "Change my reservation dates" делает вариант сразу понятным пользователю.
• Осознанно настраивайте максимальное число вариантов intent. Проверяйте баланс между достаточным выбором и «параличом выбора» с помощью тестирования.
  • Пример: ограничьте disambiguation 3–4 вариантами; если "book hotel" может совпадать с 6 intents, значит, структура intents слишком раздроблена.
• Пишите короткие сообщения для уточнения, которые признают ввод пользователя. Ведите пользователя к правильному варианту естественно.
  • Пример: "I can help you with hotel reservations. Did you want to:" с понятными вариантами вместо "Please select an intent:".
• Тщательно тестируйте двусмысленные utterances. Проверьте, что flow уточнения выглядит естественно и стабильно предлагает правильные варианты intent.
  • Пример: тестируйте фразы вроде "I need help with my reservation" на intents бронирования, изменения и отмены, чтобы убедиться, что появляются правильные варианты.

Не нужно:

• Игнорировать паттерны уточнения. Отслеживайте, какие intents чаще всего вызывают disambiguation, и дорабатывайте их, чтобы уменьшить путаницу.
  • Плохой пример: если "check my reservation" постоянно вызывает уточнение между "ViewReservation", "ModifyReservation" и "VerifyReservation", объедините или уточните эти intents.
• Использовать disambiguation как универсальное решение. Если большинство диалогов доходит до уточнения, значит, сама структура intents требует серьёзной переработки.
  • Плохой пример: если большинство запросов пользователей вызывает уточнение, это говорит о пересечении определений intents, которое нужно пересмотреть, а не просто улучшать текст сообщений.
• Забывать о неудачах disambiguation. Нужна понятная fallback-стратегия на случай, если пользователь не выбирает ни один вариант.
  • Плохой пример: снова и снова показывать те же варианты, когда пользователь отвечает "neither" или "something else", вместо эскалации на человека.
• Считать disambiguation настройкой «поставил и забыл». Постоянно анализируйте выбор пользователей, чтобы находить точки путаницы и со временем улучшать разделение intents.
  • Плохой пример: никогда не смотреть, какие варианты выбирают пользователи; если все выбирают второй вариант, когда им показывают три, возможно, варианты один и три не нужны.

После применения этих практик проверьте конфигурацию системным тестированием.

2. Тестирование реализации Assisted NLU

Когда описания intents и slots готовы, следующий шаг — проверка. Используйте Amazon Lex Test Workbench, чтобы оценить, насколько конфигурация Assisted NLU справляется с реальными вариациями utterances.

За настройкой и использованием Test Workbench см. документацию Test Workbench и демо-видео.

Важно: при настройке набора тестов обязательно выберите bot и alias, где включён Assisted NLU. Тест будет задействовать Assisted NLU только если выбранный alias указывает на версию с настроенным режимом Fallback или Primary.

2.1 Что тестировать

Сосредоточьтесь на том, где Assisted NLU даёт максимум пользы: на крайних случаях. Тестируйте ввод, который отличается от стандартных формулировок, чтобы проверить, как функция справляется с реальной «грязной» речью:

• Опечатки и грамматические ошибки: "i wanna book an hotell"
• Разговорные выражения: "hook me up with a room downtown"
• Двусмысленные запросы: "I need transportation"
• Неполные utterances: "booking for next week"

Вариации slots

Для встроенных slots тестируйте вариации форматов дат («next Tuesday», «the 15th»), алиасы локаций («NYC», «New York City»), варианты имён («Bob» против «Robert») и форматы email («john dot doe at gmail dot com»).

Для пользовательских slots проверяйте, что формулировка пользователя сопоставляется с заданными значениями, особенно в режиме expand. Например, убедитесь, что «largest room» корректно разрешается в «Suite» для slot RoomType.

В отличие от открытых generative AI-приложений, где LLM генерирует свободный текст прямо для пользователя, в Assisted NLU LLM работает строго как механизм классификации и извлечения, ограниченный определением вашего бота. LLM может только выбрать intent и извлечь значения slots, определённые в описании бота. Он не может придумать новые intents, запустить действия вне определения бота или вернуть пользователю сырой сгенерированный текст. Такая архитектура, ограниченная definition бота, заметно уменьшает поверхность атаки prompt injection, но всё равно нужно проверять, что злонамеренные вводы предсказуемо маршрутизируются в FallbackIntent.

2.2 Анализ результатов тестов

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

• 0–30%: высокий приоритет. Перепишите описание intent и проверьте, не пересекается ли оно с теми, которые система путает.
• 30–70%: средний приоритет. Проанализируйте неудачные utterances на предмет паттернов и доработайте описания.
• 70–100%: низкий приоритет. Достаточно минимальной настройки или вообще ничего не нужно делать.

Скачайте детальные результаты и изучите:

• Expected Intent vs. Actual Intent: помогает выявить ошибки классификации
• Actual Output Slot values vs expected: помогает найти ошибки извлечения и разрешения
• User Utterance: ввод, который не прошёл проверку
• Error Message: объясняет причину ошибки
• Conversation Result end-to-end: общий pass/fail для всего сценария, а не только отдельных ходов

2.3 Итерации над описаниями

Если результаты тестов показывают ошибки классификации, используйте следующий итеративный процесс для доработки описаний:

1. Экспортируйте детальные результаты и отфильтруйте неудачные utterances
2. Определите, к какому intent они были ошибочно отнесены
3. Сравните описания обоих intents
4. Перепишите описание неудачного intent, чтобы сильнее подчеркнуть различие
5. Запустите тот же набор тестов ещё раз, чтобы подтвердить улучшение

2.4 Безопасная итерация через версионирование

Используйте версионирование и aliases в Amazon Lex, чтобы безопасно тестировать изменения описаний, не затрагивая production-трафик:

1. Внесите правки в описания в Draft version
2. Протестируйте через TestBotAlias
3. Создайте пронумерованную версию, когда результаты станут приемлемыми
4. Направьте BETA alias на проверку, затем переведите на PROD
5. При необходимости откатите PROD на предыдущую версию, переназначив alias

Подробности см. в руководстве Versioning and Aliases Guide.

Контроль доступа: используйте политики AWS Identity and Access Management (IAM), чтобы ограничить круг тех, кто может менять определения бота, intents и descriptions slots. Ограничьте права lex:UpdateBotLocale, lex:UpdateIntent и lex:UpdateSlot только авторизованным разработчикам. Это предотвращает несанкционированные изменения, которые могут ухудшить точность NLU или привести к нежелательному поведению. Подробности см. в Identity and Access Management for Amazon Lex в Amazon Lex Developer Guide.

2.5 Мониторинг в production

Включите conversation logs на production alias, чтобы отслеживать работу Assisted NLU на реальном трафике. Для настройки см. Configuring Conversation Logs.

Ключевые поля для мониторинга

• fulfilledByAssistedNlu: логический флаг, показывающий, когда LLM обработала классификацию или разрешение slot
• nluConfidence: оценка уверенности для выбранного intent
• missedUtterance: логический флаг, указывающий, что был классифицирован Fallback Intent

Что отслеживать

• Частоту вызовов Assisted NLU: высокие значения в Fallback mode могут означать, что нужно расширить набор sample utterances.
• Точность распознавания intents: сравнивайте традиционный NLU и NLU с включённым Assisted NLU.
• Точность разрешения slots: сравнивайте традиционный NLU и NLU с включённым Assisted NLU.
• Паттерны missed utterance: группируйте по темам, чтобы находить пробелы в покрытии intents или описаниях.
• Частоту disambiguation: отслеживайте, какие пары intents чаще всего требуют уточнения.

Чтобы сравнить Primary и Fallback mode, создайте отдельные версии бота для каждого режима, направьте на них разные aliases и сравнивайте метрики между alias в CloudWatch.

3. Рекомендуемая стратегия внедрения

Когда описания улучшены, а тестирование пройдено, можно планировать production-релиз. Если вы создаёте новый бот, начинайте с Primary mode. Начните с 10–15 sample utterances на intent и сосредоточьтесь на качественных описаниях intents и slots. Если у вас уже есть хорошо работающий бот, начните с Fallback mode, чтобы LLM вмешивалась только тогда, когда традиционный NLU не уверен. Перед переходом на Primary mode проведите A/B-тесты и сохраните возможность отката, поддерживая предыдущую версию бота, к которой можно вернуться.

Контрольный список перед запуском

• [ ] Зафиксированы базовые метрики
• [ ] В development протестированы крайние случаи
• [ ] Включены conversation logs
• [ ] Настроен CloudWatch Dashboard
• [ ] Определена процедура отката

Заключение

В этом материале мы показали, как повысить точность ботов с помощью Amazon Lex Assisted NLU. Вы узнали, как писать эффективные описания intents и slots, как проверять конфигурацию через Test Workbench и как безопасно выводить Assisted NLU в production, используя Primary или Fallback mode.

Готовы начать? Включите Assisted NLU в своём боте уже сегодня!

Материал — перевод статьи с английского.

Оригинал: Improve bot accuracy with Amazon Lex Assisted NLU