TL;DR
Когда задачу нужно описать одной фразой, но в ней спрятано пять условий сразу — модель теряет часть логики. Исследователи заметили: чем сложнее запрос к базе данных, тем хуже модель справляется с ним "в один присест", потому что естественный язык слишком сжат для сложной логики, а SQL-запрос — слишком длинный и многослойный, чтобы держать его целиком "в голове" за один шаг.
Решение — разбить сложный запрос на граф пошаговых узлов: каждый узел — маленькая подзадача ("отфильтровать по дате", "объединить таблицы") с описанием на обычном языке и локальным результатом. Узлы связаны зависимостями — что нужно сделать раньше, что позже. Модель собирает финальный результат, проходя по графу шаг за шагом, а не пытаясь угадать всё сразу.
Метод показал: чем сложнее исходная задача, тем сильнее выигрыш от разбивки на граф. Для простых запросов эффект небольшой, для по-настоящему сложных — прирост точности резкий.
Схема метода
ШАГ 1: Раздели сложную задачу на подзадачи (узлы)
→ каждый узел = короткое описание на обычном языке + локальный результат
ШАГ 2: Определи зависимости между узлами
→ что должно быть сделано раньше, что зависит от чего (граф, не просто список)
ШАГ 3: Собери финальный результат, проходя граф по порядку зависимостей
→ итоговый ответ строится из промежуточных шагов, а не угадывается целиком
Всё выполняется в рамках одного диалога — можно попросить модель сделать граф и сборку за один запрос или разбить на два шага (сначала граф, потом сборка).
Пример применения
Задача: Нужна сложная сводная таблица в Google Sheets — выручка по менеджерам за квартал, без учёта возвратов, с разбивкой по регионам и сортировкой убывания, плюс отдельно выделить тех, кто просел больше 20% к прошлому кварталу.
Промпт:
Мне нужна сложная формула/логика для сводной таблицы. Не пиши сразу готовую формулу.
Сначала построй граф рассуждений:
- Раздели задачу на узлы (подзадачи). Каждый узел — короткое описание,
что он делает, и что на выходе.
- Укажи зависимости: какой узел должен быть готов, прежде чем перейти к следующему.
Вот задача: посчитать выручку по менеджерам за 3-й квартал, исключить возвраты,
разбить по регионам, отсортировать по убыванию суммы, и отдельно пометить
менеджеров, у которых выручка упала больше чем на 20% к прошлому кварталу.
После того как построишь граф — пройди по нему шаг за шагом и собери
финальную формулу/логику, объясняя на каждом узле, что добавляется.
Результат: Модель сначала выдаст список узлов вроде "1. Отфильтровать возвраты → 2. Сгруппировать по менеджеру и региону → 3. Посчитать сумму за Q3 и Q2 → 4. Посчитать % изменения → 5. Отсортировать и пометить упавших". Дальше — сборку итоговой формулы или логики по этим шагам, с объяснением на каждом этапе. Точность итога будет выше, чем если попросить готовую формулу одним предложением.
Почему это работает
Модель плохо держит в "голове" длинную цепочку условий, если всё нужно решить одним скачком от фразы к результату. Пропущенное условие или потерянная зависимость — обычная причина ошибок в сложных запросах.
Зато модель хорошо умеет двигаться шаг за шагом, когда каждый шаг маленький и понятный — это тот же принцип, что стоит за Chain-of-Thought. Разница здесь в том, что шаги не просто идут друг за другом, а образуют граф с зависимостями — некоторые подзадачи можно решать параллельно, некоторые обязательно после других.
Рычаги управления: - Количество узлов → для простых задач не нужно разбивать глубоко, 2-3 узла достаточно - Явное требование "укажи зависимости, не просто список" → заставляет модель думать о порядке, а не просто перечислять шаги - Просьба "объясняй на каждом узле" → показывает логику и помогает поймать ошибку раньше финала
Шаблон промпта
Не отвечай сразу. Сначала построй граф рассуждений для этой задачи:
{задача}
Граф рассуждений:
- Раздели задачу на узлы (подзадачи). У каждого узла: короткое описание
на обычном языке + что получается на выходе.
- Укажи зависимости между узлами: какой узел должен быть готов раньше другого.
После построения графа — пройди по нему в порядке зависимостей и собери
итоговый результат, показывая, что добавляется на каждом шаге.
Подставь в {задача} описание своей многоусловной задачи — сложный запрос к данным, многошаговый расчёт, документ с зависимыми условиями.
🚀 Быстрый старт — вставь в чат:
Вот шаблон разбивки сложной задачи на граф рассуждений. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы понять зависимости между шагами.
[вставить шаблон выше]
LLM спросит, какие условия у твоей задачи связаны друг с другом и в каком порядке их нужно решать — потому что без этого граф не построить правильно. Она возьмёт структуру "узлы + зависимости + сборка" и подгонит её под твою ситуацию.
Ограничения
⚠️ Для простых задач не даёт эффекта: если запрос короткий и однозначный (например "покажи всех клиентов из Москвы"), разбивка на граф — лишняя работа, точность не растёт заметно.
⚠️ Ошибка в графе тянет за собой финал: если модель неправильно определила зависимости или пропустила узел, итоговый результат наследует эту ошибку. Метод снижает, но не убирает риск ошибки — просто делает её более заметной и локализуемой.
⚠️ Не спасает от нехватки знаний о предметной области: если модель не знает специфику твоих данных (названия колонок, бизнес-логику), граф рассуждений не компенсирует этот пробел — нужно давать контекст отдельно.
Как исследовали
Команда создала бенчмарк DBLifeBench — проверила 11 моделей (среди них GPT-4o, Llama3, DeepSeek, специализированные SQL-модели типа SQLCoder) не только на генерации запросов, но и на всём цикле работы с базой данных: дизайн схемы, создание таблиц, запросы, отладка ошибок, поддержка системы.
Главный неожиданный результат: модели, дообученные специально под SQL (SQLCoder, Llama3-sqlcoder), сильно проседают в задачах вне генерации запросов — дизайне схемы, поддержке, устранении неполадок. Исследователи назвали это "проклятием специализации" — узкая заточка под одну задачу стирает более широкие навыки. General-purpose модели (GPT-4o) оказались устойчивее и сбалансированнее по всем фазам.
Для Progressive-Text2SQL данные строили сразу несколько LLM (GPT-4o, Claude, Gemini, DeepSeek) — каждая независимо генерировала свой вариант графа рассуждений, чтобы не привязываться к стилю одной модели. Три студента вручную перепроверяли графы без подсказок от модели, и совпадение оценок оказалось высоким (80%+ согласия) — это подтвердило, что структура графа не случайна, а отражает реальную логику разбора задачи.
Отдельно проверили устойчивость: специально "ломали" узлы графа (искажали SQL, убирали логику, вставляли противоречия) и смотрели, насколько упадёт точность. Даже с поломанными узлами модель с графом почти всегда обгоняла модель без графа вовсе — то есть даже несовершенная декомпозиция лучше, чем её отсутствие.