TL;DR
Группа исследователей взяла самые популярные советы по промптингу — добавлять роль ("ты эксперт"), просить рассуждать пошагово (Chain-of-Thought), давать примеры — и в контролируемом эксперименте проверила, работают ли они на самом деле для задач классификации текста. Результат разрушает привычные представления: нет ни одной техники, которая стабильно улучшает результат. Взаимодействие факторов важнее любого отдельного трюка.
Пользователи, которые аннотируют, сортируют или маркируют тексты с помощью LLM, часто добавляют в промпты обе техники сразу — "ты опытный аналитик, думай шаг за шагом." Кажется, это должно улучшать результат. Но на практике персона-промпт даёт случайный эффект — иногда чуть помогает, иногда заметно вредит. Chain-of-Thought (CoT) ведёт себя так же: в одних задачах улучшает, в других снижает точность, и всегда увеличивает длину ответа. Хуже всего — эффект непредсказуем и зависит не от техники, а от сочетания модели, задачи и конкретного набора текстов.
Выход — подход Validation-First: не гадай какой промпт сработает, а проверяй на малом наборе примеров с известными ответами ДО применения в масштабе. Начинай с простого промпта без украшений, тестируй варианты (с CoT / без, с персоной / без), выбирай лучший — и фиксируй его. Любая правка промпта требует нового теста.
Схема метода
ШАГ 1: Сформулируй задачу → промпт с чёткими определениями категорий
ШАГ 2: Подготовь тестовый набор → 20–50 текстов с известными правильными ответами
ШАГ 3: Прогони варианты промпта → стандартный / с персоной / с CoT / с примерами
ШАГ 4: Сравни точность → выбери лучший вариант для этой конкретной задачи
ШАГ 5: Зафиксируй промпт → не меняй без нового теста на отложенном наборе
Все шаги выполнимы в обычном чате.
Пример применения
Задача: Ты отвечаешь за поддержку сервиса доставки. Нужно классифицировать входящие тикеты по типу проблемы, чтобы роутить их в нужный отдел. Обращений тысячи — хочешь автоматизировать через LLM, но не знаешь какой промпт брать.
Что обычно делают (и почему стоит проверить):
❌ Типичный промпт "со всеми улучшениями":
Ты опытный специалист по клиентскому сервису с многолетним
опытом работы в логистике. Внимательно обдумай обращение
шаг за шагом и определи его тип.
→ Персона + CoT. Звучит разумно. Но исследование показывает:
эффект непредсказуем. Может помочь. Может сделать хуже.
Validation-First подход:
ШАГ 1 — Сначала создаём базовый промпт без украшений:
Определи тип обращения клиента. Выбери одну категорию:
- Задержка доставки: клиент жалуется что посылка не пришла вовремя
- Повреждение товара: товар пришёл разбитым, испорченным, не в той упаковке
- Ошибка в заказе: привезли не то, не тот размер, не то количество
- Возврат и отмена: клиент хочет вернуть деньги или отменить заказ
- Другое: всё, что не входит в категории выше
Обращение: "{текст тикета}"
Категория:
ШАГ 2 — Берёшь 30 реальных тикетов, которые уже вручную отсортированы.
ШАГ 3 — Прогоняешь базовый промпт → считаешь ошибки.
ШАГ 4 — Прогоняешь тот же промпт + 3 примера (few-shot) → сравниваешь.
ШАГ 5 — Прогоняешь с "ты опытный специалист..." → снова сравниваешь.
ШАГ 6 — Берёшь победителя. Фиксируешь.
Результат: Ты видишь конкретные числа по каждому варианту на своих данных. Не гадаешь — знаешь. В большинстве случаев базовый промпт с чёткими определениями или few-shot версия окажется не хуже "украшенной". А если CoT всё же помогает — увидишь это в тесте.
Почему это работает
Слабость LLM в задачах классификации: когда модель генерирует рассуждения (CoT), она производит промежуточный текст, который может уводить в сторону от нужного критерия. Для задач "что это за категория" длинная цепочка мыслей — лишний шум, а не фильтр. Персона ("ты эксперт") не даёт модели новых знаний о задаче — она не меняет критерии, по которым модель разбивает текст на категории.
Сильная сторона LLM: модель хорошо следует чётким инструкциям с определениями и образцами. Когда она видит: "категория А — это вот что, пример: ... ; категория Б — это вот что, пример: ..." — она опирается на структуру, а не на свои предположения o том, что имел в виду аналитик.
Как метод использует это: убираешь шум (персону, CoT), оставляешь сигнал (определения, примеры), и проверяешь на данных, а не веришь "лучшим практикам" на слово. Взаимодействие модели, задачи и формата всегда важнее любой отдельной техники — это и есть ключевой инсайт.
Рычаги управления: - Количество примеров (few-shot) → 3–5 примеров хорошо работают для бинарных задач ("позитив / негатив"), для задач с 8+ категориями прирост меньше - Определения категорий → чем чётче граница между категориями, тем меньше нужны примеры - CoT "включить / выключить" → тестируй, не принимай по умолчанию — особенно если задача требует однозначного ярлыка - Персона "включить / выключить" → тестируй отдельно, эффект случаен
Шаблон промпта
Определи {что делаем: категорию / тональность / тип} для текста ниже.
Выбери одну из категорий:
- {Категория 1}: {чёткое определение что сюда входит}
- {Категория 2}: {чёткое определение что сюда входит}
- {Категория 3}: {чёткое определение что сюда входит}
Примеры:
Текст: "{пример текста 1}"
Ответ: {Категория N}
Текст: "{пример текста 2}"
Ответ: {Категория N}
Текст: "{пример текста 3}"
Ответ: {Категория N}
Теперь определи категорию:
Текст: "{твой текст}"
Ответ:
Что подставлять:
- {что делаем} — категорию темы, тональность, тип обращения, приоритет
- {Категория N} — твои реальные классы, минимум 2, максимум разумное количество
- {определение} — конкретно что включает и что исключает категория
- {пример текста} — реальные тексты из твоих данных, по одному на категорию
Совет: начни без примеров (zero-shot) → оцени точность → добавь 3 примера (few-shot) → сравни. Добавляй CoT или персону только если тест покажет прирост.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для классификации текстов. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит про категории и их определения — потому что без чётких границ между классами модель будет угадывать. Она возьмёт структуру шаблона и заполнит по твоей задаче.
Ограничения
⚠️ Нужны размеченные примеры: Validation-First требует хотя бы 20–30 текстов с правильными ответами. Если такого набора нет — фреймворк не запустить в полную силу. Можно разметить вручную небольшую выборку, но без неё тест будет субъективным.
⚠️ Результаты не переносятся между задачами: то, что CoT помогло в одной задаче классификации, не значит, что поможет в другой. Каждая новая задача — новый тест.
⚠️ Few-shot хуже работает для сложных многоклассовых задач: если категорий много и они концептуально близки, примеры помогают меньше чем для простых бинарных задач.
⚠️ Выводы про размер модели: исследование показало, что "больше = лучше" не работает стабильно. Это актуально при выборе между платными тарифами (GPT-4o vs GPT-4o mini, Sonnet vs Haiku) — тестируй для своей задачи, не плати за самое дорогое по умолчанию.
Как исследовали
Команда взяла шесть открытых языковых моделей разного размера (от 270 млн до 72 млрд параметров) и прогнала их через четыре задачи классификации политических текстов: оценка одобрения, психологическая дистанция, экономическая тональность, тематика манифестов. Четыре задачи намеренно разные — по типу текста, количеству категорий и уровню сложности.
Умный ход: все модели запускали на одинаковом железе, с одинаковым квантованием (упрощением весов для ускорения), в одинаковых шаблонах промптов. Это убрало технические различия — осталась только разница от промптинга. Каждую комбинацию "модель × размер × стиль промпта × zero/few-shot" тестировали отдельно. Всего — сотни комбинаций.
Главный сюрприз: взаимодействия между факторами оказались важнее самих факторов. Нельзя сказать "CoT помогает" — правда звучит иначе: "CoT помогает модели X на задаче Y, но вредит модели Z на задаче W." Это означает, что любое исследование, которое тестировало только одну модель или только один стиль промпта, давало вводящие в заблуждение выводы. Ещё одна неожиданность: более крупная модель из одного семейства иногда проигрывала средней из другого семейства — и при этом потребляла больше энергии. "Купи самую большую" — плохой совет.
Адаптации и экстраполяции
💡 Адаптация: "Свой тестовый набор за час"
Если нет готовых размеченных примеров, можно создать быстро. Возьми 20–30 текстов из своего реального потока (письма клиентов, отзывы, тикеты, посты). Разметь их сам — это займёт 30–40 минут. Этого достаточно для первичного теста промптов. Ключевое: размечай ДО того как начнёшь экспериментировать с промптами — иначе подсознательно будешь подгонять разметку под тот результат, который хочешь увидеть. Это та же "заморозка промпта" из Validation-First, только для данных.
🔧 Техника: Тест "минимальный промпт" как базовая линия
Перед добавлением любой техники (CoT, персона) сначала проверь насколько хорошо работает голый промпт:
Определи тональность отзыва. Выбери: позитивный / негативный / нейтральный.
Отзыв: "{текст}"
Ответ:
Запиши точность на тестовом наборе. Потом добавляй технику и сравнивай. Если прироста нет — не добавляй. Усложнение ради усложнения только увеличивает расход токенов.
💡 Экстраполяция: Validation-First для любых повторяющихся задач
Принцип фреймворка работает за пределами классификации. Если ты регулярно используешь один промпт для однотипных задач (резюмировать встречи, оценивать резюме, проверять тексты по чек-листу) — стоит один раз потратить время и проверить промпт на известных примерах. Не потому что промпт "плохой" — а потому что не знаешь когда он начнёт давать сбои. Validation-First это страховка от накопленных ошибок, которые незаметны пока не сравниваешь с эталоном.
Ресурсы
Magic Words or Methodical Work? Challenging Conventional Wisdom in LLM-Based Political Text Annotation Lorcan McLaren, James P. Cross, Zuzanna Krakowska, Robin Rauner, Martijn Schoonvelde University College Dublin, University of Groningen — март 2026
Смежные работы упомянутые в статье: - Alizadeh et al. (2024) — практическое руководство по open-weight моделям для аннотации - Atreja et al. (2025) — влияние дизайна промпта на точность аннотации - Halterman and Keith (2025) — пятиэтапный фреймворк "codebook LLM" - Baumann et al. (2025) — "LLM hacking": как парафраз промпта делает любую гипотезу значимой - CodeBook Studio (McLaren 2026b) — инструмент для стандартизации кодбуков