TL;DR
LLM отвечает по-разному на одну и ту же задачу — в зависимости от того, как она сформулирована. Не от того, знает ли модель ответ, а от формата подачи. Одни формулировки — привычные "шаблоны" из обучения, другие — слабые места, где модель начинает ошибаться.
Проблема в том, что когда задача записана в непривычном для модели виде, цепочка шагов к решению становится длиннее и символьно плотнее. Каждый дополнительный шаг — новая точка для накопления ошибки. Модель часто знает правильный высокоуровневый подход (называет верную формулу, верный принцип), но "ломается" на механическом исполнении — неверные знаки, перепутанные компоненты, пропущенные операции.
Convert-then-Solve — двухшаговая техника: сначала попросить модель перевести задачу в более привычный ей формат, затем решить переведённую версию. В исследовании это дало прирост точности до 52 процентных пунктов на сложных форматах.
Схема метода
(Оба шага — в одном промпте)
ШАГ 1: Дать задачу → попросить переформулировать в более простой/привычный вид
ШАГ 2: На основе переформулированной версии → решить задачу
Пример применения
Задача: Вы — основатель стартапа. Получили term sheet от российского венчурного фонда. Документ написан юридическим языком: liquidation preference 1.5x non-participating, pro-rata rights, drag-along clause, anti-dilution ratchet. Нужно понять, что это значит лично для вас и стоит ли подписывать.
Промпт:
Вот term sheet от венчурного фонда:
[вставить текст документа или ключевые условия]
Шаг 1. Переведи условия на язык конкретных сценариев:
что происходит с моей долей и деньгами если стартап продадут за 50 млн рублей,
за 500 млн рублей, за 5 млрд рублей. Опиши каждый сценарий простыми словами —
кто сколько получает, в каком порядке.
Шаг 2. На основе этих сценариев: какие условия в документе работают против меня
как основателя? На что стоит попросить фонд поменять условия?
Результат:
Модель сначала покажет три конкретных сценария выхода в рублях — без юридических конструкций, просто "фонд получает X, вы получаете Y". Потом, опираясь на эту конкретику, укажет какие пункты системно ущемляют основателя и сформулирует альтернативные формулировки для переговоров. Качество анализа второго шага заметно выше, чем если бы вы сразу спросили "что не так в этом term sheet" — потому что модель работает с уже привычным ей форматом рассуждений.
Почему это работает
LLM не хранит знания — она генерирует текст по паттернам из обучения. Чем чаще определённый формат встречался в обучающих данных, тем надёжнее шаблоны рассуждений для него. Привычные форматы — устойчивые шаблоны, редкие форматы — хрупкие цепочки.
Когда задача в непривычном формате, модель часто "знает" правильный принцип (называет верную формулу, правильный подход), но "ломается" на механическом исполнении — длинная цепочка вычислений, каждый шаг которой добавляет вероятность ошибки. Ошибки накапливаются, финальный ответ неверен. Как если бы хирург знал операцию в теории, но работал нехирургическими инструментами.
Convert-then-Solve использует сильную сторону: модель хорошо умеет переводить между форматами (это тоже паттерн из обучения). После перевода — рассуждает в привычной системе координат, где шаблоны крепкие. Два шага вместо одного — но суммарно точнее, чем один шаг напрямую.
Рычаги управления:
- Явно назови целевой формат ("переведи в конкретные числа / в список шагов / в бытовые аналогии") — чем конкретнее инструкция перевода, тем качественнее второй шаг
- Оба шага в одном промпте — модель держит переведённую версию в контексте и не теряет её при переходе к решению
- Попроси показать оба шага — если хочешь проверить качество перевода перед анализом
Шаблон промпта
Вот задача / документ / ситуация в формате {исходный_формат}:
{задача}
Шаг 1. Перепиши это в формате {целевой_формат}: {что должно быть понятно после перевода}.
Шаг 2. На основе этого переформулированного варианта: {конкретный вопрос для решения}.
Что подставлять:
- {исходный_формат} — откуда пришла задача: юридический язык, технический регламент, финансовая отчётность, формулы, статистика
- {целевой_формат} — в какой вид переводим: конкретные сценарии, бытовые аналогии, список шагов, таблица с числами
- {что должно быть понятно} — критерий качества перевода: "кто что получает", "что происходит если X", "в чём суть каждого пункта"
- {конкретный вопрос} — то, что реально хочешь решить
🚀 Быстрый старт — вставь в чат:
Вот шаблон Convert-then-Solve. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: в каком формате пришла задача, какой формат было бы проще анализировать, и что именно нужно решить в итоге — потому что без этого невозможно правильно выбрать целевой формат перевода и сформулировать второй шаг.
Ограничения
⚠️ Только для достаточно мощных моделей: слабые модели (малые открытые LLM вроде LLaMA 8B) не получают никакого прироста от техники. Перевод сам по себе им не помогает — там другие, более глубокие проблемы. С GPT-4, Claude, Gemini — работает хорошо.
⚠️ Качество перевода критично: если модель неправильно перевела задачу на шаге 1, шаг 2 даст уверенно неверный ответ. Для важных задач — проверяй шаг 1 перед тем как доверять шагу 2.
⚠️ Больше токенов: два шага = примерно вдвое длиннее ответ. В длинных документах это упирается в контекстное окно. Дроби задачу на части.
⚠️ Исследование в геометрии: принцип экстраполируется, но конкретные цифры прироста — из математических задач. В других доменах эффект будет, но его величина неизвестна.
Как исследовали
Команда из BITS Pilani взяла 158 задач по геометрии из школьных учебников (NCERT, RD Sharma, RS Aggarwal) и для каждой вручную создала три математически идентичных версии: евклидова (словесная, "треугольник со сторонами..."), координатная (декартова система координат) и векторная (через скалярные и векторные произведения). Итого 474 экземпляра — и каждая модель отвечала на все три варианта одной задачи.
Проверяли 11 моделей — от LLaMA 8B до GPT-5, Claude и Gemini. Главный вопрос: даёт ли одна и та же модель одинаковый ответ на семантически идентичные задачи в разных форматах? Результат оказался неожиданно резким: разрыв точности между форматами достигает 14 процентных пунктов — и это не шум, статистические тесты подтвердили устойчивость эффекта. Векторный формат — стабильно самое слабое место у почти всех моделей. При этом Invariance@3 (доля задач, решённых верно во всех трёх форматах) у LLaMA 8B составила 0.044 — то есть меньше 5% задач модель решает корректно независимо от формулировки.
Затем проверили Convert-then-Solve: модели давали задачу в векторном формате, но сначала просили перевести в евклидов, а потом решать. Gemini 2.5 Flash прыгнула с 0.45 до 0.97 на векторных задачах. Это самый неожиданный результат: проблема была не в незнании, а в формате. Модель умела решать — просто не умела работать с непривычной записью.
Оригинал из исследования
We evaluate CTS on a representative subset of six models...
CTS dramatically improves accuracy for mid- and high-capacity models —
vector accuracy jumps by up to 52 pp (Gemini-2.5-Flash: 0.45 → 0.97),
and accuracy gaps narrow from 14 pp to 2–3 pp — confirming that
direct-evaluation failures reflect representation sensitivity rather than
inability to solve the underlying problems. Crucially, LLaMA-3.1-8B shows
no meaningful gains (vector: 0.13 → 0.16), indicating that conversion
scaffolding cannot compensate for fundamental capacity limitations.
Контекст: Это описание Convert-then-Solve — основного промптингового вмешательства в исследовании. Модели давали задачу в сложном формате (векторы) и просили сначала перевести в Евклидов вид, потом решать.
Адаптации и экстраполяции
💡 Адаптация: Convert-then-Solve для анализа данных
Когда данные в Excel/SQL структуре — попроси сначала превратить их в нарратив ("это данные о продажах в 3 магазинах за полгода, магазин А падает, Б растёт..."), потом анализировать.
Вот данные: {таблица или описание данных}
Шаг 1. Перескажи что здесь происходит простым языком —
как будто объясняешь коллеге по телефону.
Выдели 3 главных тренда.
Шаг 2. На основе этого объяснения: какой вывод следует сделать
и что предпринять в первую очередь?
🔧 Техника: Явный формат перевода → точнее второй шаг
Чем конкретнее целевой формат, тем лучше:
| Исходное | Лучше | Ещё лучше |
|---|---|---|
| "переведи проще" | "переведи на бытовой язык" | "переведи в 3 сценария с конкретными суммами в рублях" |
| "объясни" | "объясни как список шагов" | "объясни как инструкцию из 5 пунктов для человека без опыта" |
🔧 Экстраполяция: Format-First для любого сложного ввода
Принцип шире геометрии. Везде, где входной формат непривычен для стандартного рассуждения модели — выгодно добавить шаг "сначала переведи":
- Юридический документ → "переведи в список прав и обязанностей каждой стороны"
- Технический регламент → "переведи в последовательность действий для исполнителя"
- Финансовая отчётность → "переведи в бизнес-историю: что росло, что падало"
- Академическая статья → "переведи в три конкретных вывода для практика"
Ресурсы
Работа: Measuring Representation Robustness in Large Language Models for Geometry
Авторы: Vedant Jawandhia, Yash Sinha, Murari Mandal, Ankan Pal, Dhruv Kumar
Учреждения: BITS Pilani (Department of Computer Science and Information Systems; Department of Mathematics), KIIT University (School of Computer Science)
Датасет и промпты: github.com/vedjaw/GeoRepEval