Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Неоднозначность запроса предложили определять по тем трактовкам, которые конкретная LLM способна распознать и продолжить ответом. В препринте Technical University of Munich, который не рецензирован и где числа получили сами авторы, метод CircleClar лучше прямой генерации восстановил доступные модели ответы во всех проверенных сценариях с вопросами. Такой подход позволяет связать решение ответить, уточнить запрос или отказаться с фактическими знаниями выбранной модели.
Один запрос ставит разные модели в разные условия
Авторы разделяют мировую и модельную неоднозначность. Первая охватывает все допустимые трактовки запроса, а вторая — только те, для которых конкретная модель может получить ответ.
В статье это показано на вопросе о том, кто озвучивал змею в The Jungle Book. Ответ зависит от экранизации: для фильма 1967 года это Sterling Holloway, для фильма 2016 года — Scarlett Johansson. Обе трактовки существуют независимо от модели, но LLM может знать только одну экранизацию.
Обычный детектор пометит такой вопрос как неоднозначный при любой модели. Модельный подход различает три ситуации: LLM не может дать допустимый ответ, знает одну трактовку или поддерживает несколько. От этого зависит действие системы: отказаться, ответить сразу либо запросить уточнение.
Это не просто другая метрика для одного и того же свойства. При замене модели меняется набор доступных ответов, хотя текст запроса остаётся прежним. Поэтому правило обработки неоднозначности, настроенное на одной LLM, нельзя автоматически переносить на другую.
Как цикл ответа и уточнения проверяет трактовку
Авторы формализуют корректное уточнение через три требования. Оно должно оставлять единственный ответ, сохранять смысл исходного вопроса и считаться равнозначным другим уточнениям, которые ведут к тому же ответу.
При этих условиях каждому допустимому ответу соответствует класс уточнений. Например, разные формулировки про змею в анимационном фильме 1967 года представляют одну трактовку, потому что приводят к Sterling Holloway.
CircleClar использует это соответствие как проверку с доступом к модели только через запросы. Сначала LLM несколько раз предлагает возможные ответы на исходный вопрос. Формулировки с одинаковым смыслом объединяются, после чего для каждого кандидата модель составляет уточнённый вопрос, который должен вести именно к нему.
Затем модель независимо отвечает на уточнение. Кандидат остаётся в наборе, если исходный ответ возвращается достаточно стабильно и чаще любого другого. В основной конфигурации использовали шесть серий предложений, десять повторных ответов и порог восстановления 60%.
Такой цикл отсекает случайные варианты, которые появились при генерации, но не выдержали уточнения. Он не требует доступа к весам или внутренним вероятностям модели, поэтому подходит для закрытых API.
Проверка охватила открытые вопросы из AmbigQA и очищенной авторами версии AmbigQA-HQ, а также исполняемые запросы Text-to-SQL из AMBROSIA. Качество оценивали по тому, насколько точно и полно метод восстанавливает весь набор доступных модели ответов. CircleClar показал лучшую итоговую меру в семи из двенадцати сочетаний модели и набора данных, а на задачах с вопросами обошёл все варианты прямой генерации.
Что меняется в планах продуктовой команды
Работа предлагает не новый универсальный детектор неоднозначности, а дополнительный слой перед ответом LLM. Он особенно уместен там, где система уже может уточнять намерение пользователя: в поиске, помощниках, аналитических интерфейсах и преобразовании текста в SQL.
Практическое правило получается простым. Пустой набор проверенных ответов ведёт к отказу, один вариант — к прямому ответу, несколько — к уточнению. В экспериментах такая явная оценка набора чаще выбирала правильное действие, чем прямой запрос к модели с просьбой самой решить, отвечать ей или уточнять.
За это приходится платить дополнительными вызовами модели. CircleClar сначала собирает кандидатов, затем создаёт отдельное уточнение и несколько раз отвечает на него для каждого варианта. Если продукт рассчитан на единственный быстрый вызов API, метод не встраивается без изменения требований к задержке и расходу токенов.
Цикл также не доказывает фактическую верность ответа. LLM может стабильно повторять одну и ту же ошибку, а редкая трактовка не попадёт в первоначальный список кандидатов. Метод ориентирован на точность найденного набора и поэтому способен пропускать ответы, которые модель дала бы только после явной подсказки.
Проверки охватывают вопросы общего профиля и Text-to-SQL. Они показывают перенос идеи между обычным текстовым ответом и исполняемым результатом, но не заменяют испытания на запросах конкретного продукта. Для системы с жёсткими правилами предметной области модельную неоднозначность стоит использовать вместе со схемами данных и обязательными полями, а не вместо них.
Главное изменение для архитектуры состоит в том, что неоднозначность становится свойством пары «запрос — модель». При смене LLM команде придётся заново проверять не только качество ответов, но и политику уточнений: более знающая модель может увидеть больше допустимых трактовок и чаще обращаться к пользователю.
Источники
Иллюстрация: рисунок из статьи «What Is a Clarification? Estimating Model-Dependent Input Ambiguity», Jingqin Tang, Tim Tomov, Sebastian Schmidt и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
