Методы

Дай модели начальный бюджет (например, 1 млн виртуальных монет). Для каждого ответа/прогноза модель должна "поставить" от минимума (1 монета) до максимума (100 тысяч). Угадала — ставка добавляется к балансу. Ошиблась — вычитается. Сумма всех ставок не может превышать текущий баланс. Почему работает: Ограниченный ресурс заставляет различать. На уверенные ответы ставит много. На сомнительные — копейки. Без лимита модель даст всем среднюю оценку. С лимитом вынуждена приоритизировать. Когда применять: множество оценок (10+ вариантов), нужно ранжирование по надёжности, есть способ проверить правильность. Не работает: один ответ (нечего сравнивать), субъективные оценки без проверки ("насколько текст красивый"), задачи где нельзя дать обратную связь

Схема: Актёр решает → если провал, запускаются критики → каждый пишет диагноз со своей точки зрения → дебаты (1-2 раунда, критики оспаривают друг друга) → судья синтезирует консенсус → актёр пробует снова с рефлексией. Персоны под задачу: для бизнеса (финансист/маркетолог/скептик/креативщик), для кода (Senior Engineer/QA/Code Reviewer/Performance Engineer), для текста (редактор/SEO/читатель/эксперт). Роли должны быть контрастными: цифры vs риски, факты vs альтернативы. Почему работает: разные роли → разные паттерны мышления. Модель не повторяет ту же логику, а генерирует несколько углов зрения. Когда применять: сложные задачи где первая попытка часто неполная, важные решения (стратегия/архитектура/анализ). Когда не работает: простые вопросы за один заход, рутина (расход токенов ~3x больше обычной рефлексии)

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

Скопируй промпт дважды. Вместо <промпт> отправь <промпт><промпт>. Модель читает всё дважды. Первый проход — линейно. Второй — с накопленным контекстом. Почему работает: LLM каузальная — токен видит только предыдущие, не будущие. Повторение даёт второй шанс связать части. Вопрос понимает опции. Опции понимают вопрос. Синтаксис: {промпт}\n{промпт} или с границей {промпт}\n\nLet me repeat that:\n\n{промпт}. Для сложных задач (длинные списки) пробуй ×3. Когда ДА: поиск в списках, выбор из вариантов, длинный контекст с условием. Когда НЕТ: reasoning-модели (o1, o3) — они сами повторяют в мыслях; очень длинные промпты (не влезут в лимит); жёсткий бюджет токенов (вход удваивается). Бонус: длина ответа не растёт

Что делать: В промпте укажи точное число элементов ("РОВНО 20 примеров", "минимум 800 слов"). В конце добавь требование: "Когда закончишь напиши '✓ Все 20 готовы'". Почему работает: Число создаёт измеримую цель вместо размытого "подробно". Финализирующая фраза работает как маркер конца — модель должна дойти до этой точки чтобы "закрыть" задачу. Без этого она останавливается раньше из-за bias к краткости. Когда применять: Задачи со списками, перечислениями, минимальным объёмом текста. Когда не работает: Субъективные требования без чёткой метрики ("будь максимально глубоким" — модель интерпретирует произвольно). Не гарантирует качество — модель может дать 1000 слов воды

Добавь в конец промпта фразу: "Оптимизируй сложность алгоритма по времени". Одно предложение. Почему работает: без инструкции модель семплирует из всех рабочих решений — часто попадает в неэффективные (первое что приходит). С инструкцией — семплирует из подпространства оптимальных решений. Для модели это триггер: не просто написать код, а сравнить варианты и выбрать быстрый. Особенно сильно работает для reasoning-моделей (DeepSeek-R1, GPT-4.1) — они начинают рассуждать вслух про сложность перед генерацией кода. Когда применять: работаешь с большими данными (1000+ элементов), сложные вычисления, алгоритмические задачи. Когда не работает: простые задачи (сортировка списка) — модель и так выдаст нормальный код

Создай роль-координатора и список ролей-экспертов (каждый отвечает за свою область). Координатор читает задачу и выбирает каких экспертов вызвать (не всех подряд!). Каждый эксперт отвечает только по своей зоне: оценка + обоснование с фактами + рекомендация. Итог — агрегация всех ответов. Почему работает: Фокус на узкой области → модель глубже анализирует этот аспект. Когда критериев много — одна роль пытается держать всё в голове → поверхностно. Специалисты разделяют нагрузку. Когда применять: 4+ разных критерия проверки, каждый требует специализированного анализа (бизнес-идея: финансы + маркетинг + юридика + риски; диагноз: 7 групп симптомов). Когда не работает: 1-2 простых критерия — координатор добавляет сложность без пользы. Прямой промпт быстрее

Три шага в одном промпте. Шаг 1: Определи цель — что нужно найти или решить. Шаг 2: Перечисли все условия — что должно быть известно для достижения цели. Шаг 3: Проверь каждое условие — дано явно? можно вывести? или нигде нет? Чего нет — перечисли как недостающее. Почему работает: Модель хорошо умеет разбивать цель на части и сравнивать списки. Это проще чем заметить пробел во время решения. Обратное направление делает проверку явной и структурированной. Когда применять: задачи где нужно что-то посчитать, оценить, принять решение на основе данных. Бизнес-планы, техзадания, финансовые расчёты, анализ ситуаций. Когда не работает: творческие задачи без чётких условий, субъективные оценки, задачи где "полнота данных" не определена

Вместо "дай модели последовательность чисел" → построй график и дай картинку. LLM видят тренды, всплески, падения как визуальные паттерны — они обучены на миллионах графиков, диаграмм, схем. Для модели график = как фотография: она распознаёт форму, наклон, волны. Шаг 1: Построй график (любой инструмент: Excel, Python, Google Sheets). История + прогноз на одном изображении. Шаг 2: Загрузи в ChatGPT/Claude. Шаг 3: Промпт: "Оцени разумность прогноза. Синяя линия — история, красная — прогноз. Reasonable или unreasonable?" Почему работает: Ты переводишь задачу анализа последовательности в задачу компьютерного зрения. Модель не вычисляет, она ВИДИТ. Когда применять: временные ряды (продажи, трафик, метрики), любые данные с трендами и паттернами. Когда не работает: данные без визуального паттерна (например, случайный шум)

Модель смотрит на график + читает текст о событиях. Связывает два источника: "в тексте написано '15 марта распродажа'" + "на графике 15 марта пик" = логично. Или "в тексте '15 марта распродажа'" + "на графике 15 марта ровная линия" = нелогично, всплеск пропущен. Формат: После описания графика добавь секцию "Контекст:" и перечисли события: праздники, промо-акции, запуски продуктов, сезонность, внешние факторы. Пример: "24 ноября Чёрная пятница (скачок в истории), 1-3 мая праздники (в период прогноза)." Почему работает: Мультимодальные LLM обучены связывать визуал и текст — тот же механизм что работает для "найди на схеме элемент X" или "что на этой фотографии?". Применяй: когда на данные влияют известные события. Чем больше деталей — тем точнее оценка. Но если контекст неправильный — модель ошибётся

Цикл из 3 шагов: (1) Сгенерируй ответ из текущего контекста. (2) Оцени качество по критериям. (3) Если оценка выше порога — добавь ответ в контекст как пример. Повтори N раз. В конце выбери лучший из всех. Почему работает: Контекст из качественных примеров смещает генерацию. Модель видит хорошие ответы и начинает генерировать в том же стиле. Плохие ответы не попадают в контекст — не тратишь вычисления на усиление слабых паттернов. Рычаги: Порог оценки (выше = строже фильтр, меньше примеров но чище). Число итераций (больше = больше попыток, но после 5-7 хороших примеров отдача падает). Когда применять: Задача сложная, разброс качества генераций высокий (планирование, код, креатив). Не работает: Простые задачи где модель и так генерирует хорошо

Дай модели явные правила организации кода ДО генерации. Правила: 1) Главную функцию размести первой (high-level логика), вспомогательные — после. 2) Каждая функция получает docstring с объяснением подхода и логики. 3) Повторяющиеся операции выноси в отдельные функции. 4) Избегай вложенных функций — всё на верхнем уровне. Почему работает: LLM обучена на коде разного качества. Без инструкций может выдать монолит или спагетти-код. Явные правила активируют паттерн чистого кода. Docstrings работают как "подумай вслух" — модель объясняет логику перед генерацией, пишет осознаннее. Когда да: сложные алгоритмы (50+ строк), нужна читаемость и отладка, код будут поддерживать. Когда нет: простые скрипты 5-10 строк, исследовательский код в Jupyter, нужны специфичные паттерны (ООП, функциональщина)

Напиши базовый промпт. Протестируй на 20-30 примерах. Возьми лучший вариант и попроси модель: "Перефразируй это определение 10 способами, меняя структуру и акценты". Снова протестируй все варианты. Почему работает: Модель генерирует формулировки которые ты сам не придумал бы. Разные слова активируют разные паттерны из обучающих данных. Невозможно угадать какая формулировка сработает лучше — только эмпирически. Когда применять: задача классификации или извлечения информации, есть 20+ размеченных примеров для теста. Не работает: если нет способа проверить какой вариант лучше

Вместо "выбери А, Б или В" попроси модель назвать уверенность в процентах для каждого варианта: "60% уверен в А, 30% в Б, 10% в В". Почему работает: Когда модель выбирает один вариант из списка, последний вариант получает преимущество (recency bias). Когда называет проценты — генерирует число для каждого варианта независимо, позиция не влияет. Когда применять: закрытые вопросы с 2-5 вариантами ответа, нужна оценка уверенности, важна точность. Когда не работает: открытые вопросы без заданных вариантов, творческие задачи, модель не умеет работать с процентами (старые/маленькие модели). Формат: "Оцени уверенность в процентах для каждого варианта: А — _%, Б — _%, В — _%"

Что делать: Разбивай многошаговые задачи на отдельные запросы с проверкой каждого шага. Вместо: "Скачай файл X с сайта Y и посчитай среднее по столбцу Z" → делай так: Шаг 1: "Скачай файл X. Покажи первые 3 строки". Проверяешь результат. Шаг 2: "Посчитай среднее по столбцу Z из этого файла". Почему работает: Когда задача одна длинная цепочка — провал первого шага скрывается ради выполнения следующих. Модель "хочет" дать полезный ответ и маскирует ошибку. Разбивка даёт тебе видимость: каждый шаг завершается отчётом. Ловишь провал до того как он породит фальшивые результаты. Когда применять: Задачи с файлами/API/инструментами, где возможны технические сбои. Критические данные (финансы, медицина). Не нужно: Простые текстовые задачи без внешних действий