Complexity-Based Prompting

Коротко

Техника отвечает на вопрос: какие примеры класть в few-shot prompt для многошаговой задачи?

Ответ: часто лучше брать примеры с более длинным и содержательным reasoning, а не только с поверхностным сходством.

Выбери 3 few-shot примера для сложной математической задачи. Отдай приоритет тем примерам, где reasoning длиннее и включает несколько явных промежуточных шагов.

Complexity-Based Prompting нужен там, где качество few-shot больше зависит от глубины демонстрации, чем от поверхностного совпадения темы.

Что именно оптимизирует техника

Обычный подбор few-shot примеров часто идёт по двум линиям:

• ручной выбор;
• retrieval по семантическому сходству.

Complexity-Based Prompting добавляет третью ось: сложность reasoning. Авторы показывали, что для multi-step задач более "богатые" reasoning demonstrations часто обучают модель лучше, чем просто похожие, но короткие.

Это полезно, потому что модель копирует не только содержание примеров, но и их стиль решения.

Когда техника особенно полезна

Подход хорошо работает для:

• математики;
• логики;
• word problems;
• rule-based reasoning;
• задач, где итог зависит от нескольких явных шагов.

Если task family по природе многошаговая, complexity-aware selection почти всегда стоит хотя бы проверить.

Почему похожесть не всегда спасает

Семантическая похожесть полезна, но у неё есть ограничение. Пример может быть тематически близким, но слишком коротким и не показывать нужный паттерн reasoning. Тогда модель видит задачу "про то же", но не видит, как именно развернуть сложное решение.

Complexity-Based Prompting закрывает именно этот разрыв.

Ограничения

Более сложный пример не всегда лучше.

• слишком длинные traces могут создавать шум;
• overly complex demos могут переносить ненужные шаги на простую задачу;
• если examples синтетически раздуты, complexity signal будет ложным.

Поэтому техника полезна не как догма "чем длиннее, тем лучше", а как controlled preference for richer reasoning.

Как применять в 2026

Сегодня это особенно актуально в prompt libraries и eval-driven pipelines. Если у вас есть банк примеров, их уже недостаточно просто хранить. Нужно управлять тем, какие examples попадают в prompt на разные классы задач.

Complexity-Based Prompting хорошо ложится на такую систему:

• route task family;
• retrieve relevant examples;
• rerank by reasoning complexity;
• build final prompt.

Это делает few-shot более инженерным, а не магическим.

Техническая реализация

const ranked = examples
  .filter(isRelevantTo(task))
  .sort((a, b) => scoreComplexity(b) - scoreComplexity(a))
  .slice(0, 3)

Хороший practical metric для старта: число смысловых reasoning steps плюс coverage ключевых типов операций. Просто длина текста слишком шумная.