Intent Recognition
intent recognition — определение, что пользователь хочет получить
Распознавание намерений помогает понять, зачем человек написал сообщение: хочет заказать еду, узнать статус доставки или отменить заказ. Параметры — адрес, время, номер заказа — извлекаются отдельно. Если смысла не хватает, полезнее задать вопрос, чем выбрать действие наугад.
Коротко
Intent Recognition — распознавание намерения пользователя по сообщению. «Где моя пицца?» и «Курьер ещё не приехал» могут означать одну задачу: узнать статус заказа. Адрес, время и номер заказа — отдельные данные, которые нужны для её выполнения.
Система не читает мысли. Она выбирает подходящее объяснение фразы с учётом доступного контекста и может ошибиться.
Зачем отделять намерение от слов
В сообщениях «хочу отменить заказ» и «не хочу отменять заказ» почти одинаковые слова, но разные цели. Поиск одного слова «отменить» здесь не поможет. А фраза «всё, больше не надо» без предыдущей переписки вообще не объясняет, что именно нужно сделать.
Распознавание намерений помогает направить запрос в нужный сценарий: открыть форму, найти заказ, подключить сотрудника поддержки. Оно также подходит для анализа обращений: сколько людей спрашивают о доставке, оплате или возврате.
Обычно приложение задаёт список поддерживаемых намерений. Это не список всех человеческих желаний, а перечень задач, с которыми оно умеет работать.
Какие задачи идут рядом
- Классификация намерения: определить цель — например,
check_order, проверка заказа. - Извлечение сущностей: найти упомянутые данные — например, номер «12345».
- Заполнение полей, или slot filling: собрать нужные параметры из сообщения, истории и других разрешённых источников.
- Обнаружение запросов вне возможностей системы: отличить неподдерживаемую задачу от знакомой.
- Распознавание нескольких намерений: разобрать просьбу «проверь заказ и измени адрес».
Это связанные задачи, но не одно и то же. Приложение может правильно понять желание отменить заказ и при этом не знать, какой именно заказ имеется в виду.
Как устроено распознавание
Правила и обучаемый классификатор
Для простого меню бывает достаточно кнопок и нескольких правил. Если формулировки разнообразнее, используют классификатор: собирают сообщения, размечают их по намерениям и обучают модель.
Текст можно представить числовыми признаками или эмбеддингами. Поверх них работает классификатор; другая модель или набор правил извлекает параметры. Есть и модели, которые решают обе задачи совместно.
Объём примеров зависит от сходства классов, разнообразия речи и требований к ошибкам. Несколько почти одинаковых фраз хуже показывают реальные трудности, чем набор с отрицаниями, опечатками, короткими ответами и неоднозначностью.
Языковая модель с описанием задачи
LLM можно передать список намерений, их границы и примеры. Отдельное дообучение при этом не обязательно. Но тестовые сообщения с известными правильными ответами всё равно нужны: без них непонятно, помогает ли очередная правка инструкции.
Модель может вернуть структурированный результат. Приложение проверяет его формат, допустимые значения и полноту данных. Просьба «верни JSON» сама по себе не гарантирует ни правильный JSON, ни верное понимание запроса.
Пример инструкции
Представим бот пиццерии. Для первого варианта хватит нескольких понятных задач и двух отдельных состояний: «не хватает ясности» и «не умеем это делать».
Определи намерение по сообщению клиента.
Допустимые значения intent:
- order_food: оформить новый заказ;
- check_order: узнать статус существующего заказа;
- cancel_order: отменить существующий заказ;
- contact_support: обратиться к сотруднику;
- unclear: нельзя уверенно определить, чего хочет клиент;
- out_of_scope: понятная, но неподдерживаемая задача.
Не выполняй действия. Не придумывай недостающие параметры.
Если клиент отрицает действие, не считай его просьбой выполнить это действие.
Верни объект JSON с полями intent, slots, clarification.
Для отсутствующих данных используй null или пустой объект.
clarification — вопрос клиенту при необходимости, иначе null.
Для фразы «Где заказ 12345?» ожидаемая структура может быть такой:
{
"intent": "check_order",
"slots": {"order_id": "12345"},
"clarification": null
}
А для «Отмени его» без предыдущего контекста:
{
"intent": "cancel_order",
"slots": {"order_id": null},
"clarification": "Какой заказ вы хотите отменить?"
}
Это примеры желаемого поведения, не обещание результата любого вызова. Код приложения отдельно проверяет существование заказа и право клиента его менять. Перед необратимым действием может понадобиться подтверждение.
Где появляются неоднозначности
«Хочу пиццу к восьми» ещё не задаёт дату и адрес. «Как обычно» требует истории, причём история может содержать несколько разных заказов. «На пятницу» зависит от текущей даты; при записи на удалённую встречу важен и часовой пояс.
Некоторые неоднозначности решаются контекстом. Другие лучше превратить в короткий вопрос. Если бот предлагает отменить заказ, а клиент отвечает «нет», это отказ от предложенного действия, а не новый запрос, который нужно классифицировать в отрыве от диалога.
Отдельный случай — несколько просьб. В «отмени бронь и верни деньги» нельзя выполнить вторую часть, не проверив результат первой и правила возврата. Классификация лишь выделяет задачи; порядок и разрешения определяет приложение.
Как проверить качество
Удобнее оценивать несколько вещей отдельно:
- Выбор намерения. Какие классы система путает и как часто?
- Параметры. Верно ли она извлекает номер, адрес и время, не дописывая их от себя?
- Неизвестные запросы. Умеет ли она отказаться от неподходящего класса?
- Уточнения. Задаёт ли вопрос там, где ответ без него рискован?
- Рабочие последствия. Может ли ошибка привести к отмене, оплате или раскрытию чужих данных?
Общая доля верных ответов скрывает редкие, но важные ошибки. Если почти все сообщения — проверка статуса, модель может хорошо выглядеть в среднем и плохо распознавать отмену. Таблица перепутанных классов помогает это увидеть.
Тестовый набор лучше отделить от примеров в инструкции и обучении. Проверка на тех же фразах показывает, что система справилась с ними, но мало говорит о новых обращениях. В исследовании CLINC150 распознавание запросов вне поддерживаемых задач оказалось отдельной трудностью даже для классификаторов, успешных на знакомых классах.
Почему число confidence не решает проблему
Модель может написать "confidence": 0.99, но это ещё не измеренная вероятность правильного ответа. Такую самооценку нельзя без проверки использовать как основание для оплаты или отмены.
Даже вероятности обычного классификатора требуют проверки на отложенных данных, если по ним принимают решения. Порог выбирают с учётом последствий: лишнее уточнение и ошибочная отмена заказа стоят по-разному.
Частые заблуждения
«Достаточно добавить out_of_scope». Название класса не учит автоматически распознавать всё неизвестное. Нужны разнообразные примеры неподдерживаемых запросов и отдельная проверка.
«Непонятный запрос — это small talk». Человек может просить важное действие, просто неудачно его сформулировав. Состояния «хочет поболтать», «не хватает данных» и «система этого не умеет» полезно различать.
«Чем больше классов, тем точнее». Похожие классы могут мешать друг другу. Если два намерения ведут к одному действию, отдельные категории не всегда нужны. Для большого списка бывает полезна иерархия, но ошибка на первом уровне влияет на все последующие.
«Распознать намерение — значит получить разрешение». Текст о переводе денег ещё не подтверждает, что пользователь имеет право его выполнить. Проверка доступа, условий и подтверждения остаётся за приложением.
Частые вопросы
Нужна ли большая языковая модель?
Не обязательно. При стабильном наборе задач компактный классификатор может дать подходящее качество с небольшой задержкой. LLM удобна для прототипа и более разнообразных формулировок. Сравнение имеет смысл на одних и тех же обращениях, включая сложные случаи.
Сколько примеров добавить в инструкцию?
Фиксированного минимума нет. Особенно полезны примеры на границах похожих классов: отмена и вопрос об отмене, новый заказ и повтор старого. Их пользу видно по отдельному тестовому набору, а не по длине инструкции.
Что делать с разными языками?
Проверять каждый рабочий язык и смешанные сообщения. Хорошее распознавание намерения не означает такое же качество адресов, дат и имён.
Можно ли оставить данные локально?
Да, если модель и все части обработки работают в вашей инфраструктуре. Сам локальный интерфейс этого не гарантирует: он может обращаться к внешней модели или отправлять журналы запросов.
Главное
Распознавание намерений помогает превратить сообщение в понятную задачу. Хорошая система не только выбирает действие, но и замечает нехватку данных, неподдерживаемые просьбы и несколько целей в одной фразе. Самый полезный следующий шаг иногда — не запуск функции, а один точный вопрос.
