TL;DR
ReAct-SQL — техника, где модель не пишет готовый запрос к базе данных сразу, а строит его пошагово через маленький набор проверяемых операций: загрузить таблицу → отфильтровать → объединить → посчитать. Перед этим модель может "прощупать" базу — заглянуть в реальные значения колонок, — а не угадывать их по названию.
Модель ошибается в SQL-запросах по двум разным причинам. Первая: она не знает, как на самом деле называются данные внутри — путает регистр (metformin vs Metformin), не понимает сокращённые названия таблиц вроде chartevents. Вторая: задача сама по себе сложная, с кучей вложенных условий — и модель просто теряется, выдавая кривой, нерабочий запрос. Это две разные болячки, и лечить их одним и тем же способом бесполезно.
Метод разделяет лечение: для проблемы "не знаю данные" — даёт модели возможность сначала посмотреть на реальные значения в базе, прежде чем писать логику. Для проблемы "сложная структура" — заставляет строить запрос не одним куском, а маленькими именованными шагами из ограниченного набора из 15 операций, где каждый шаг проверяется, прежде чем перейти к следующему.
Схема метода
ШАГ 1: Думает → анализирует вопрос, планирует подход (текстовый блок рассуждения)
ШАГ 2: Действует → вызывает операции из ограниченного набора (загрузить таблицу, отфильтровать, объединить, "прощупать" значения) → структурированный вызов
ШАГ 3: Наблюдает → получает результат каждой операции: успех/ошибка/превью данных → обратная связь
ШАГ 4: Повтор шагов 1-3, пока не готов ответ
ШАГ 5: Финальное оформление → выбор или синтез итогового результата из истории шагов
Всё происходит в рамках одного многошагового диалога (агентский цикл), не в одном сообщении.
Пример применения
Задача: Аналитик в компании выгрузил из Битрикс24 CRM таблицы deal, contact, company и просит ChatGPT собрать запрос: "сколько сделок закрыто успешно за квартал по каждому менеджеру". Проблема — он не уверен, как именно называются статусы сделок в базе, в каком формате даты, и запрос многосоставной.
Промпт:
У меня есть выгрузка из CRM Битрикс24. Вот структура таблиц и примеры значений:
[приложить примеры строк из deal, contact, company]
Задача: посчитать количество успешно закрытых сделок за 3 квартал 2024
по каждому менеджеру.
Не давай сразу финальный SQL-запрос. Сделай так:
1. Изучи примеры значений в колонках статуса сделки и даты —
опиши, что понял (какое значение значит "успешно закрыта",
в каком формате дата).
2. Разбей построение запроса на пронумерованные шаги:
какие таблицы нужны, как их соединить, какой фильтр по дате
и статусу, как сгруппировать по менеджеру.
После каждого шага кратко проверь его логику.
3. Собери финальный запрос только после того, как все шаги проверены.
Покажи мне план и финальный запрос отдельно.
Результат: Модель сначала разберёт примеры данных и явно скажет, что, например, статус "WON" означает успешную сделку, а дата хранится в формате YYYY-MM-DD. Потом покажет план из 4-5 пронумерованных шагов с проверкой каждого. В конце — готовый SQL-запрос, собранный из уже проверенной логики, а не угаданный с первого раза.
Почему это работает
Модель не может свериться с реальными данными "в голове" — она угадывает названия статусов, форматы дат, регистр букв. Эти ошибки тихие: запрос выглядит правильным, но выдаёт неверный результат, потому что модель искала "Won", а в базе было "won".
При этом модель хорошо умеет пересматривать план, если ей показать, что не сработало, и хорошо держит внимание на маленьких шагах, если попросить объяснить каждый по отдельности — вместо того чтобы сразу выдать большой готовый ответ целиком.
Метод использует это: сначала даёт модели "посмотреть" на реальные данные, а потом заставляет строить логику маленькими проверяемыми кусками. Ошибка ловится на промежуточном шаге, а не всплывает только в готовом результате.
Рычаги управления: - Число шагов разведки → для простых задач с понятными данными можно урезать до нуля - Список допустимых операций → сузь или расширь под свою задачу (для текста договора: "добавить пункт", "изменить формулировку", "удалить пункт") - Условие завершения → замени "финальный ответ" на "покажи 2 варианта и жди подтверждения"
Шаблон промпта
Я работаю с {тип данных/задачи}. Вот структура/примеры: {данные}.
Задача: {задача}.
Не давай сразу финальный ответ. Сделай так:
1. Разведка: изучи примеры и опиши, что непонятно или нужно уточнить
(названия, форматы, единицы измерения).
2. План по шагам: разбей построение ответа на пронумерованные шаги.
После каждого шага кратко проверь: логично ли это,
нет ли противоречий с предыдущим шагом.
3. Финал: собери итоговый ответ только после проверки всех шагов,
покажи его отдельно от плана.
Подставь: {тип данных/задачи} — с чем работаешь (база данных, таблица, документ), {данные} — примеры реальных значений, {задача} — что нужно получить в итоге.
🚀 Быстрый старт — вставь в чат:
Вот шаблон разведки перед построением ответа. Адаптируй под мою задачу:
{твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие данные у тебя есть и что именно неясно в задаче — потому что без реальных примеров шаг "разведки" бессмысленен, а без понимания задачи не получится разбить её на шаги.
Ограничения
⚠️ Узкая специализация: метод проверен на генерации SQL-запросов. Для творческих или субъективных задач (тексты, идеи, оценка стиля) декомпозиция на "проверяемые шаги" работает слабо — там нет объективного критерия "правильно/неправильно" на каждом шаге.
⚠️ Без реальных данных разведка бесполезна: если не приложить примеры значений (файл, выгрузку, таблицу), модель просто гадает так же, как и без метода — шаг "посмотреть на данные" ничего не даёт.
⚠️ Избыточно для простых задач: если запрос простой и однозначный, разбиение на шаги только тратит время и не даёт выигрыша в точности.
Как исследовали
Команда сравнила ReAct-SQL с пятью существующими сложными системами перевода текста в SQL — у каждой своя многоступенчатая архитектура с отдельными модулями поиска, генерации и проверки. Тестировали на двух базах: обычных бизнес-данных и медицинских записях пациентов с непрозрачными названиями таблиц типа chartevents. Все системы работали на одной модели для честного сравнения, а точность проверял отдельный ИИ-судья, чтобы не штрафовать за формальные мелочи типа порядка строк.
Результат удивил: простой цикл "думай-действуй-смотри" с ограниченным набором из 15 операций показал точность на уровне сложных систем с десятками вызовов модели, но работал в 3-8 раз быстрее. А главный инсайт вылез из отдельного эксперимента: на медицинских данных с непонятными названиями возможность "прощупать" реальные значения дала прирост точности на 26 пунктов, а сам ограниченный набор операций почти ничего не добавил. На обычных бизнес-запросах — наоборот: разведка почти не помогла, а ограниченный набор операций дал +5 пунктов. Вывод: разные типы ошибок модели лечатся разными способами, и универсального "одного решения на всё" не существует.