MCTS-SQL: Легковесные LLM могут освоить Text-to-SQL с помощью поиска по дереву Монте-Карло

Исследование предлагает систему MCTS-SQL, которая позволяет небольшим и "слабым" LLM генерировать сложный и корректный SQL-код на уровне больших моделей вроде GPT-3.5. Вместо того чтобы пытаться получить правильный ответ с одной попытки, система использует метод "умного перебора" (поиск по дереву Монте-Карло), где она генерирует черновик запроса, а затем многократно его критикует, исправляет и проверяет, пока не найдет рабочий вариант.

Ключевой результат: Правильная стратегия итеративного улучшения с обратной связью позволяет даже маломощным LLM решать задачи, которые ранее были доступны только большим и дорогим моделям.

Представьте, что вам нужно поручить стажеру (маленькой LLM) сложную задачу — написать SQL-запрос для базы данных, которую он видит впервые. Если вы просто дадите ему задание, он, скорее всего, ошибется. Метод MCTS-SQL — это как если бы вы выстроили для стажера целый рабочий процесс:

1. Фильтрация шума (Selector): Сначала опытный менеджер (часть системы) смотрит на задачу и документацию по 20 таблицам базы данных и говорит стажеру: "Забудь обо всем, для этой задачи тебе понадобятся только таблицы users и orders. Вот их описание". Это резко сужает поле для ошибок.

2. Первый черновик (Direct Generator): Стажер пишет первую, возможно, неидеальную версию SQL-запроса.

3. Мозговой штурм и исправление (MCTS-Refiner): Это самый важный этап. Вместо того чтобы сразу ругать стажера, система запускает процесс "умного перебора":

   • Запуск и проверка: Система пытается выполнить SQL-запрос. Он не работает и выдает ошибку.
   • Критика: Система показывает ошибку LLM и спрашивает: "Что здесь не так? Дай конструктивную критику". LLM может ответить: "Ошибка в названии колонки, и отсутствует JOIN с таблицей frpm".
   • Генерация исправлений: Система говорит LLM: "Отлично, а теперь, учитывая эту критику, напиши исправленную версию". LLM предлагает новый вариант.
   • Оценка и выбор пути: Система оценивает, насколько новое решение лучше старого. Она может исследовать несколько "веток" исправлений (например, один вариант исправляет JOIN, другой — название колонки). Она выбирает самый многообещающий путь и продолжает его "раскручивать".

Этот цикл критики, исправления и оценки повторяется несколько раз, пока система не найдет SQL-запрос, который выполняется без ошибок и решает поставленную задачу. По сути, это автоматизированный процесс проб и ошибок, который направляет LLM к правильному решению.

• Прямая применимость: Низкая. Пользователь не может реализовать автоматический MCTS-поиск в обычном чате. Это требует написания кода, который управляет LLM через API, выполняет SQL-запросы и реализует логику дерева поиска.

• Концептуальная ценность: Высокая. Исследование дает пользователю мощную ментальную модель:

  1. LLM — не оракул, а инструмент для итераций. Не ждите идеального ответа с первого раза. Используйте модель для генерации черновиков и их последующего улучшения.
  2. Контекст — это всё. Перед решением сложной задачи "скормите" модели только релевантную информацию, отсеяв все лишнее. Это повысит ее шансы на успех.
  3. Критика — двигатель прогресса. Заставляя LLM анализировать собственные (или ваши) ошибки, вы направляете ее на правильный путь.

• Потенциал для адаптации: Высокий. Пользователь может вручную симулировать этот процесс в одном диалоге. Вместо автоматизированного цикла, пользователь выступает в роли "оркестратора", заставляя LLM последовательно выполнять роли "генератора", "критика" и "исправителя". Этот подход можно перенести из SQL на любую сложную задачу: написание текста, планирование, анализ данных.

Представим, что нужно создать контент-план для блога о здоровом питании. Вместо простого запроса, мы симулируем метод из исследования.

Ты — опытный маркетолог и контент-стратег. Твоя задача — создать контент-план для нового блога о здоровом питании.

### КОНТЕКСТ И ЦЕЛИ (Аналог "Selector")

*   **Целевая аудитория:** Занятые офисные работники 25-40 лет, которые хотят питаться правильно, но не имеют много времени на готовку.
*   **Ключевые темы:** Быстрые рецепты (до 30 минут), здоровые перекусы в офисе, мифы о диетах, основы сбалансированного рациона.
*   **Формат:** 4 статьи в месяц.
*   **Тон:** Практичный, поддерживающий, без заумной терминологии.

---

### ЗАДАЧА: ДВА ЭТАПА

**ЭТАП 1: Создай черновик контент-плана**

Сгенерируй первоначальный вариант контент-плана на один месяц (4 темы для статей) в формате таблицы.

**ЭТАП 2: Проведи критику и создай финальную версию (Аналог "MCTS-Refiner")**

После создания черновика, не останавливайся. Сразу же выполни следующие шаги:
1.  **Проведи самокритику:** Посмотри на созданный черновик и оцени его по следующим критериям:
    *   Насколько темы соответствуют интересам занятого офисного работника?
    *   Есть ли в плане практическая польза, которую можно применить сразу?
    *   Не слишком ли темы общие и "избитые"?
2.  **Сформулируй 3 пункта для улучшения.**
3.  **Создай финальную, улучшенную версию** контент-плана, учитывая собственную критику. Выведи только финальную версию в виде таблицы.

Этот промпт работает, потому что он заставляет LLM не выдавать первый пришедший в голову ответ, а следовать структурированному процессу, который имитирует логику исследования:

1. Фокусировка контекста: Блок ### КОНТЕКСТ И ЦЕЛИ работает как Selector из статьи, отсекая все лишнее и направляя модель на конкретную аудиторию и задачи.
2. Принудительная итерация: Разделение на ЭТАП 1 и ЭТАП 2 заставляет модель сначала сгенерировать базовый вариант (Direct Generator), а затем улучшить его.
3. Симуляция самокритики: Инструкция "Проведи самокритику" и "Сформулируй 3 пункта для улучшения" — это ручная имитация Critiquer и Refiner. Модель вынуждена найти недостатки в своей же работе и целенаправленно их исправить, что почти всегда ведет к более качественному и продуманному результату.

Задача: Спланировать маршрут для самостоятельного путешествия по новому городу.

Ты — эксперт по путешествиям, который составляет нетривиальные маршруты.

### ИСХОДНЫЕ ДАННЫЕ (Контекст)

*   **Город:** Лиссабон, Португалия.
*   **Длительность:** 2 полных дня.
*   **Интересы:** Историческая архитектура (но не только дворцы), аутентичная местная еда (не туристические рестораны), смотровые площадки, стрит-арт.
*   **Бюджет:** Средний.
*   **Темп:** Спокойный, без спешки.

---

### ЗАДАЧА: СОЗДАЙ И УЛУЧШИ МАРШРУТ

**ШАГ 1: Сгенерируй черновой вариант маршрута**

Составь пошаговый план на 2 дня. Включи 3-4 локации/активности на каждый день и предложи по одному варианту для обеда и ужина.

**ШАГ 2: Проанализируй и оптимизируй маршрут**

Сразу после генерации черновика, выполни его критический анализ:
1.  **Логистика:** Оцени, насколько реалистично перемещаться между предложенными точками. Нет ли слишком больших или нелогичных переездов?
2.  **Соответствие интересам:** Проверь, все ли точки соответствуют моим интересам (особенно "аутентичная еда" и "стрит-арт"). Нет ли в плане слишком "попсовых" туристических мест?
3.  **Баланс:** Сбалансирован ли план? Нет ли перегруза в один из дней?

На основе этого анализа создай **финальный, оптимизированный маршрут** на 2 дня. Представь только его.

Этот промпт эффективен, так как он переносит системный подход из исследования в творческую задачу планирования.

1. Отсечение нерелевантного: Блок ### ИСХОДНЫЕ ДАННЫЕ действует как Selector, заставляя LLM игнорировать стандартные туристические пакеты и сфокусироваться на конкретных интересах (стрит-арт, нетуристическая еда).
2. Предотвращение "ленивого" ответа: Требование сначала создать черновик, а потом его проанализировать, не дает модели выдать первый попавшийся маршрут из своих обучающих данных.
3. Встроенная проверка на ошибки: ШАГ 2 — это ручная симуляция MCTS-Refiner. Модель вынуждена проверить свой же план на логистические ошибки и несоответствия, что является ее типичной слабой стороной. Заставляя ее сначала "подумать" о логистике, а потом "исправить", мы получаем гораздо более реалистичный и продуманный план, чем при простом запросе "спланируй мне поездку".