Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
AIR научили находить случаи, когда вопрос на обычном языке допускает несколько SQL-запросов с разными ответами. В работе Capital One система получила F1 0,679 против 0,618 у IntentRL при передаче модели только схемы базы; это нерецензированный препринт, где все числа получили сами авторы. Подход позволяет не отправлять содержимое базы в LLM, но сохраняет доступ к ней для исполнения SQL.
Как AIR доказывает, что вопрос неоднозначен
Обычная система Text-to-SQL выбирает одну трактовку фразы и сразу строит запрос. Если пользователь сформулировал условие неточно, синтаксически корректный SQL может вернуть не те данные, которые он ожидал.
AIR сначала разделяет поиск смысла и генерацию SQL. Опорный агент предлагает наиболее вероятную трактовку, а агент-оппонент получает её как запрет и должен найти другой правдоподобный смысл. Он не редактирует первый ответ, а пытается опровергнуть предположение, что тот единственный.
Затем отдельный агент переводит каждую трактовку в SQL. Система исполняет запросы и сравнивает наборы строк. Если результаты совпали, альтернативу отбрасывают; если различаются, AIR считает неоднозначность существенной и готовит уточняющий вопрос.
В примере «Покажите wellness-программы и дневные спа за $150» цена может относиться ко всему перечню или только к wellness-программам. Первый SQL вернул две строки, второй — шесть. Вместо общего вопроса «Что вы имели в виду?» система показывает обе трактовки и объясняет, как меняется ответ.
Такая проверка находит неоднозначность, которая влияет на текущий результат. Если два разных SQL-запроса случайно возвращают одинаковые строки на имеющихся данных, AIR оставляет одну трактовку. Это осознанная граница метода: он защищает ответ здесь и сейчас, а не доказывает смысловую однозначность фразы для любого будущего состояния базы.
Схема базы оказалась полезнее полного содержимого
Метрика F1 объединяет точность и полноту. Точность показывает, какая доля предложенных трактовок верна, а полнота — какую долю эталонных трактовок система смогла найти. Это полезнее обычной доли правильных запросов, когда у вопроса может быть несколько допустимых ответов.
На AMBROSIA AIR с Claude Sonnet 4.5 лучше IntentRL работала со схемой без строк данных. При доступе модели ко всей базе IntentRL сохранила преимущество, поэтому AIR нельзя считать безусловной заменой обученному решению: её сильная сторона проявляется именно при ограниченном контексте.
На AmbiQT, где двусмысленность создаёт устройство схемы, а не формулировка пользователя, AIR также перенеслась без специального обучения. При контексте только со схемой её F1 составила 0,675 против 0,570 у IntentRL.
AIR генерировала в среднем 1,76 варианта на вопрос, тогда как IntentRL всегда выпускала 5. Это почти втрое сокращает число кандидатов, которые приходится исполнять, фильтровать или показывать пользователю.
Метод проверяли на AMBROSIA и AmbiQT с Claude Sonnet 4.5, Gemma 4 26B A4B и gpt-oss-20b. Оба набора состоят из одиночных вопросов, поэтому результаты не описывают накопленный эффект уточнений в длинном диалоге; качество самих уточняющих вопросов пользователи отдельно не оценивали.
Когда AIR стоит закладывать в продукт
Работа меняет планы команд, которые собираются давать пользователям прямой доступ к аналитике через естественный язык. Одного этапа «вопрос — SQL» недостаточно: между ними нужен явный поиск альтернатив, а после генерации — исполнение кандидатов в контролируемом контуре.
Схема не устраняет доступ к данным полностью. LLM может видеть только таблицы, столбцы и связи, но сервер AIR всё равно исполняет SQL против полной базы и передаёт результаты агенту, который составляет уточнение. Значит, архитектуре потребуются обычные права доступа, журналирование запросов и ограничения на возвращаемые строки.
Главный практический барьер — задержка. Последовательная реализация с Claude Sonnet 4.5 занимала около 40 секунд на вопрос. Для фонового отчёта это может быть приемлемо, но для интерактивной аналитики понадобится параллельно запускать независимые вызовы, кешировать схему и заранее ограничивать число трактовок.
AIR особенно уместна там, где ошибочный ответ дороже дополнительного вопроса пользователю: в финансовых отчётах, внутренних реестрах и операционных панелях. Если продукт требует мгновенного ответа и допускает приблизительную трактовку, несколько обращений к LLM и базе могут стоить больше, чем дают.
Практический вывод не в том, чтобы заменить текущую модель набором агентов. Стоит вынести неоднозначность в отдельный этап конвейера и проверять её исполнением SQL. AIR показывает рабочую конструкцию без специального обучения, но её задержку и поведение в многошаговом диалоге придётся проверять уже на сценариях конкретного продукта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
