TL;DR
MATS — фреймворк, который разделяет задачу генерации SQL между пятью специализированными агентами: один фильтрует схему БД и находит релевантные значения колонок, второй генерирует SQL пошагово (что выбрать → какие условия → какие таблицы), третий проверяет результат выполнения запроса, четвёртый исправляет ошибки, пятый выбирает лучший вариант из кандидатов. Каждый агент — это отдельная языковая модель, fine-tuned под свою подзадачу.
Малые модели (1-3B параметров) плохо справляются со сложными задачами вроде Text2SQL — путаются в большых схемах БД (до 65 таблиц, 455 колонок), неточно связывают вопрос с колонками, делают ошибки в логике запросов. Одна модель пытается держать в голове всю схему, рассуждать о выборе таблиц, генерировать синтаксически корректный SQL и проверять логику — получается каша. Причина: ограниченная "память" модели (контекст) и слабые способности к глубоким рассуждениям.
MATS использует divide-and-conquer: каждый агент делает одну узкую задачу, не перегружая контекст. Агенты обучаются через Reinforcement Learning with Execution Feedback (RLEF) — модель генерирует несколько SQL, выполняет их в базе данных, получает результаты (пустой ответ, ошибка, данные) и учится на реальных последствиях, а не на ручной разметке. Результат: точность как у GPT-4o при использовании моделей в 9B параметров вместо сотен миллиардов.
Схема метода
АГЕНТ 1 (Schema Insight): Фильтрация схемы БД
├─ Ранжирование таблиц и колонок по релевантности к вопросу
└─ Поиск конкретных значений в колонках через BM-25 → схема + примеры значений
АГЕНТ 2 (Planner): Генерация SQL пошагово
├─ ШАГ 1: Что выбирать (цель SELECT)
├─ ШАГ 2: Какие условия (логика WHERE)
├─ ШАГ 3: Какие таблицы нужны (FROM/JOIN)
└─ Генерирует K вариантов SQL (1 greedy + K-1 с temperature) → набор кандидатов
АГЕНТ 3 (Validator): Проверка результата выполнения
├─ Validator Selection: правильные ли колонки выбраны?
├─ Validator Condition: правильные ли условия (если результат пустой → проблема в WHERE)
└─ Фидбек: где ошибка и как исправить
АГЕНТ 4 (Fix): Исправление на основе фидбека
└─ Берёт SQL + фидбек валидатора → генерирует исправленный SQL
АГЕНТ 5 (Selection): Выбор лучшего SQL
└─ Сравнивает результаты выполнения всех кандидатов → индекс лучшего
Все агенты работают последовательно, каждый запрос требует отдельного обращения к модели.
Пример применения
⚠️ Метод требует: доступ к базе данных, выполнение SQL, технические навыки. Не для "обычного чата" — скорее для разработчиков или аналитиков, которые работают с БД через API LLM.
Задача: У вас база данных интернет-магазина (таблицы: users, orders, products, order_items, reviews). Нужно найти email пользователей, которые оставили отзывы на товары из категории "Электроника" со средней оценкой выше 4, но сами ни разу не купили товары из этой категории.
Промпт (концептуально — для разработчика системы):
[Входные данные для агента 1]
Вопрос: Найди email пользователей, которые писали отзывы на электронику с оценкой >4, но сами не покупали электронику
Схема БД: [полная схема с 15 таблицами]
[Агент 1 фильтрует → оставляет users, reviews, products, order_items]
[Агент 1 находит значения в products.category: "Ноутбуки", "Смартфоны", "Наушники"]
[Входные данные для агента 2]
Отфильтрованная схема + примеры значений
→ Генерирует 3 варианта SQL с разными подходами (подзапросы, CTE, JOIN)
[Агент 3 выполняет SQL в БД]
→ Вариант 1: пустой результат
→ Вариант 2: 15 строк
→ Вариант 3: ошибка синтаксиса
[Валидатор анализирует]
→ Вариант 1: "Пустой результат — возможно, слишком строгие условия в WHERE"
→ Вариант 2: проверяет колонки и условия → "Корректно"
→ Вариант 3: "Синтаксическая ошибка в JOIN"
[Агент 4 исправляет варианты 1 и 3]
[Агент 5 выбирает лучший SQL из всех исправленных и оригинальных]
Результат:
Система выдаст финальный SQL запрос, который прошёл через все проверки: схема отфильтрована до релевантных таблиц, логика разбита на шаги (кого ищем → что проверяем → откуда берём), запрос проверен на реальных данных, ошибки исправлены. В процессе вы увидите промежуточные рассуждения каждого агента, результаты выполнения кандидатов и обоснование выбора финального запроса.
Почему это работает
Слабость малых моделей: контекст переполняется при больших схемах БД. Модель в 1-3B параметров пытается одновременно помнить 65 таблиц, рассуждать о связях, генерировать синтаксис SQL и проверять логику — результат: путаница в колонках, неправильные JOIN, логические ошибки в WHERE. Одна модель = все задачи сразу = overload.
Сильная сторона малых моделей: справляются с узкими задачами, если контекст не раздут и инструкция чёткая. Модель может хорошо отранжировать таблицы по релевантности ИЛИ сгенерировать SQL по готовому плану ИЛИ найти ошибку в конкретном WHERE — но не всё вместе.
Механика MATS: разделяет нагрузку между агентами — каждый видит только свой кусок задачи. Schema Insight фильтрует до 5-10 релевантных таблиц вместо 65 → Planner получает компактный контекст. Planner разбивает рассуждение на три явных шага (SELECT → WHERE → FROM) вместо генерации SQL "в лоб" → проще не запутаться. Validator не пытается угадать правильность, а смотрит на факт: SQL вернул пустой результат? Значит, условие слишком строгое или не та колонка. Fix получает точный фидбек ("условие X неверное"), а не размытое "что-то не так". Selection сравнивает конкретные результаты выполнения, а не пытается "представить" какой SQL лучше.
Ключевой принцип: execution feedback — модель не гадает, а видит последствия. SQL выполнился в БД → пустой результат → валидатор анализирует → фиксер корректирует → снова выполнение. Это loop обучения, где модель учится на реальных ошибках, а не на абстрактных правилах.
Рычаги управления (для разработчиков системы):
- K (число кандидатов от Planner) → больше K = больше вариантов для выбора, но дороже по токенам. Уменьши для простых схем.
- Temperature T → выше = разнообразнее SQL, ниже = консервативнее. Для стандартных запросов снижай.
- Типы валидаторов → можно добавить валидатор на JOIN (проверяет правильность связей таблиц) или на агрегацию (COUNT, AVG).
- Условие выбора в Selection Agent → сейчас по execution response, можно добавить критерий "читаемость SQL" или "минимум JOIN".
Шаблон промпта
⚠️ Этот метод НЕ для обычного чата. Требует инфраструктуры: база данных, выполнение SQL, интеграция агентов через API. Шаблоны ниже — концептуальные, для разработчиков систем на основе LLM.
Для пошагового планирования SQL (применимо в чате с ограничениями):
Задача: сгенерировать SQL для вопроса "{вопрос}"
Схема БД:
{список_таблиц_и_колонок}
Рассуждай пошагово:
ШАГ 1 — Цель выборки (SELECT):
Что именно нужно получить? Какие колонки или агрегаты? Из какой таблицы главный результат?
ШАГ 2 — Условия (WHERE):
Какие фильтры применить? Какие значения или диапазоны? Нужна ли проверка на NULL?
ШАГ 3 — Таблицы и связи (FROM/JOIN):
Какие таблицы нужны? Как они связаны? Какие JOIN (INNER/LEFT/RIGHT)?
Финальный SQL:
[генерируй только после завершения всех шагов]
Плейсхолдеры:
- {вопрос} — вопрос на естественном языке
- {список_таблиц_и_колонок} — схема БД (релевантные таблицы с описаниями колонок)
Для валидации через execution feedback (требует выполнения SQL):
SQL запрос:
{sql_запрос}
Результат выполнения:
{execution_response}
Вопрос:
{исходный_вопрос}
Проверь:
1. Правильные ли колонки выбраны для ответа на вопрос?
2. Если результат пустой или содержит None — какие условия могут быть слишком строгими?
3. Все ли необходимые таблицы включены в JOIN?
Фидбек:
[укажи конкретные ошибки и как исправить]
Плейсхолдеры:
- {sql_запрос} — сгенерированный SQL
- {execution_response} — результат выполнения (данные, пустой результат, ошибка)
- {исходный_вопрос} — вопрос пользователя
🚀 Для продвинутых пользователей:
Если у вас есть доступ к БД и API LLM: 1. Попроси LLM отфильтровать схему БД до релевантных таблиц 2. Попроси сгенерировать SQL пошагово по шаблону выше 3. Выполни SQL в БД, получи результат 4. Верни результат в LLM с промптом валидации 5. Если найдена ошибка — попроси исправить 6. Повтори до правильного результата
Это ручная имитация MATS в цикле запросов.
Ограничения
⚠️ Требует инфраструктуры: Метод работает только при наличии базы данных для выполнения SQL и получения feedback. Без реального выполнения запросов — теряется ключевая механика обучения и валидации.
⚠️ Множество запросов к LLM: 5 агентов + генерация K кандидатов + итерации исправлений = десятки запросов на один финальный SQL. Дорого по токенам, медленно по времени. Для простых запросов — overkill.
⚠️ Технический барьер: Нужны навыки работы с БД, API интеграции, понимание SQL. Не для "обычного пользователя ChatGPT" — скорее для разработчиков data-intensive приложений.
⚠️ Узкая задача: Метод заточен под Text2SQL. Принцип мультиагентности универсален, но конкретная реализация (Schema Insight, SQL validation через execution) применима только для работы с базами данных.
⚠️ Fine-tuning обязателен: В оригинале каждый агент fine-tuned на своей задаче. Без дообучения малые модели не справляются с ролью агентов так же эффективно. Большие модели (GPT-4, Claude) могут имитировать агентов в промптах, но тогда теряется смысл использования "малых" моделей.
Как исследовали
Команда взяла два известных бенчмарка для Text2SQL — Spider (простые схемы, 10-20 таблиц) и BIRD (сложные реальные БД, до 65 таблиц, 455 колонок) — и протестировала MATS против baseline: GPT-4o с Chain-of-Thought, CHESS (state-of-the-art для Text2SQL на больших моделях), и различные fine-tuned open-source модели (CodeLlama, DeepSeek-Coder).
Суть эксперимента: для каждого вопроса система генерирует SQL, выполняет его в реальной БД, сравнивает результат с ground truth (правильным ответом). Метрика — Execution Accuracy: совпадает ли результат выполнения SQL с ожидаемым (не синтаксис SQL, а именно данные). Это жёсткий критерий — даже если SQL выглядит правильно, но вернул не те строки, считается ошибкой.
Удивительное открытие: MATS с моделями Qwen2.5-Coder-3B (всего 9B параметров на всех агентов) достиг 54.6% точности на BIRD — это сравнимо с GPT-4o (55-60%), но GPT-4o содержит сотни миллиардов параметров. На графике (Fig. 1) видно: MATS — левее всех (меньше параметров), но на уровне или выше топовых решений.
Почему так получилось: разделение на агентов позволило малым моделям не захлёбываться в контексте. Schema Insight уменьшил среднюю длину схемы БД в промпте на 70% (с 455 колонок до 20-30 релевантных) → Planner получает компактный input. Validator с реальным execution feedback поймал 40% ошибок, которые Planner пропустил (неправильные JOIN, слишком строгие WHERE). Fix Agent исправил 68% помеченных ошибок — это значит, что точный фидбек ("колонка X неверная") работает лучше, чем переделывать SQL с нуля.
Инсайт для практики: execution feedback (результат выполнения в БД) — мощнее, чем "думай правильно ли SQL". Модель видит пустой результат → понимает "условие слишком строгое". Видит синтаксическую ошибку → знает где искать. Это не абстрактная валидация, а конкретный сигнал. Такой подход можно использовать не только в SQL, но везде, где есть objective feedback: код (запустил → работает/не работает), вычисления (ответ → проверяемый результат), API запросы (response → анализ ошибок).
Адаптации и экстраполяции
Принцип для других задач
Extractable principle: мультиагентная декомпозиция + feedback loop
Применимо в чате для задач с проверяемым результатом:
Пример 1: Генерация Python кода
АГЕНТ 1 (понимание задачи):
Разбей задачу "{задача}" на шаги: какие данные на входе, какие операции, что на выходе.
АГЕНТ 2 (генерация кода):
На основе шагов выше, напиши Python код. Генерируй 3 варианта с разными подходами.
АГЕНТ 3 (валидация):
Я выполнил код, результат: {execution_output}
Ожидалось: {expected_output}
Проанализируй расхождения. Где ошибка?
АГЕНТ 4 (исправление):
Исправь код на основе фидбека: {validator_feedback}
АГЕНТ 5 (выбор):
Какой из исправленных вариантов лучше по: читаемости, эффективности, корректности?
Важно: нужно выполнять код между запросами и возвращать результат.
Пример 2: Анализ данных с проверкой
Задача: посчитать среднюю стоимость заказов клиентов из Москвы
АГЕНТ 1: Какие колонки в CSV нужны? → city, order_value
АГЕНТ 2: Как фильтровать? → city == "Москва"
АГЕНТ 3: Какую операцию? → mean(order_value)
[Выполняешь pandas код, получаешь результат]
ВАЛИДАТОР: Результат 0 — проверь:
- Точно ли "Москва", а не "Moscow" или "москва"?
- Нет ли пропусков (NaN) в order_value?
ФИКСЕР: Добавь .fillna(0) и .str.lower() для city
Ручной цикл в ChatGPT/Claude — утомительно, но принцип работает: разделяй задачу → генерируй → выполняй → анализируй результат → исправляй.
🔧 Техника: Симуляция мультиагентности в одном промпте
Если нет возможности делать execution feedback, можно попросить модель симулировать агентов:
Ты — система из 3 агентов:
АГЕНТ 1 (Planner): Разбей задачу на шаги
АГЕНТ 2 (Generator): Сгенерируй решение
АГЕНТ 3 (Critic): Найди потенциальные ошибки в решении
Задача: {твоя_задача}
Выполни последовательно роли всех агентов. После каждой роли — чёткий output в формате:
AGENT 1 OUTPUT:
[...]
AGENT 2 OUTPUT:
[...]
AGENT 3 OUTPUT:
[...]
Эффект слабее, чем реальный execution feedback, но лучше, чем один общий промпт.
Ресурсы
A Multi-agent Text2SQL Framework using Small Language Models and Execution Feedback Код и данные
Thanh Dat Hoang, Thanh Trung Huynh, Matthias Weidlich, Thanh Tam Nguyen, Tong Chen, Hongzhi Yin, Quoc Viet Hung Nguyen
Griffith University (Австралия), VinUniversity (Вьетнам), Humboldt-Universität zu Berlin (Германия), The University of Queensland (Австралия)