Все концепты
Концепты из исследований октября 2025
30 исследований, 78 концептов — отсортировано по рейтингу
Verbalized Sampling: распределения вместо одиночных ответов для борьбы с однообразием
Many-Shot Paradox: когда больше примеров = хуже результат
Даёшь модели 5-25 примеров — результат отличный. Увеличиваешь до 100-600 примеров — качество падает на 5-10%. Модель начинает копировать поверхностные паттерны (длину фраз, частые слова, синтаксис), но теряет глубокую логику. Результат выглядит правдоподобно, но работает неправильно. Проблема универсальна: перевод кода, написание текстов, анализ данных — везде где нужна точность
Держи 5-25 примеров. Не больше. Выбирай разнообразные примеры, но в рамках одного паттерна (разные сценарии, но единый стиль). Добавь явную инструкцию: "сохрани стиль из примеров, но адаптируй под новый контекст" — это помогает модели не копировать слепо
Для задач требующих точности (не просто "переведи слово") давай 5-25 примеров в промпте. Меньше 5 — модель может не схватить стиль. Больше 25 — начинается деградация: модель имитирует форму вместо сути. Шаблон: Ты {роль}. Вот {5-25} примеров {типа контента}: Почему работает: Модель ищет паттерны. Малое количество качественных примеров даёт чёткий паттерн без шума. Много примеров создают конфликтующие сигналы — модель теряет фокус. Когда применять: сложные задачи с чёткими критериями правильности (стиль + точность, формат + логика). Когда нет: простые задачи (zero-shot достаточно), креативные задачи (примеры ограничивают фантазию)[Пример 1], [Пример 2]... Теперь создай для нового контекста: {параметры}. Сохрани {что важно}, но адаптируй под {новое}.
Модель не "понимает" задачу — она ищет паттерны в примерах. При 5-25 примерах паттерн чёткий. При 100+ примерах паттерны конфликтуют: одни примеры говорят "пиши коротко", другие "пиши длинно", третьи "будь серьёзным", четвёртые "будь эмоциональным". Модель начинает копировать поверхностные признаки (структуру предложений, частоту слов) вместо глубокой логики. Результат выглядит похоже на нужное, но функционально ломается. Применяй: Если добавил 20+ примеров и результат стал хуже — убери половину. Оставь 5-10 самых качественных и разнообразных
5-8 качественных примеров достаточно чтобы модель извлекла суть стиля, тона, структуры. Это как объяснить задачу человеку — нужно 3-5 хороших примеров, а не 100 посредственных. Малое количество заставляет модель искать общий принцип, а не копировать детали. Большое количество провоцирует механическое микширование фраз из разных примеров. Применяй: Вместо "дам все 50 примеров что есть" выбери 8 лучших — с разными сценариями, но единым стилем. Модель схватит суть без шума
Quit Instructions: учи агента останавливаться в неоднозначных ситуациях
Агент видит двусмысленную инструкцию ("переведи деньги Сергею Петрову"). Находит двух Сергеев Петровых в базе. Выбирает первого наугад вместо того чтобы спросить. Действует потому что обучен быть полезным и завершать задачи. В агентных сценариях с реальными последствиями (переводы, доступы, данные) такая "помощь" приводит к необратимым ошибкам
Добавь явные инструкции КОГДА агент должен остановиться. Не "можешь выйти если хочешь", а "ДОЛЖЕН остановиться если: не можешь исключить негативные последствия, нужна дополнительная информация для безопасных действий, недостаточно знаний для оценки рисков". Дай модели разрешение НЕ завершать задачу — остановка и запрос уточнений тоже считается успехом
Добавь в system prompt явные условия КОГДА агент обязан остановиться и спросить: Ты ДОЛЖЕН остановиться если: 1) не можешь исключить негативные последствия, 2) нужна информация о том что делать, 3) нужна информация о текущей ситуации, 4) недостаточно знаний для оценки рисков. Плюс негативные условия: НЕ останавливайся если: есть безопасные действия для сбора информации. Почему работает: Переопределяет базовую мотивацию модели. Вместо "помочь = выполнить любой ценой" становится "помочь = выполнить безопасно или спросить". Остановка больше не воспринимается как провал. Когда: Задачи с серьёзными последствиями (финансы, доступы, данные). Не работает: Низкорисковые информационные задачи — агент будет останавливаться избыточно. Open-source модели (Llama, малые Qwen) слабо реагируют на такие инструкции
Модели обучены завершать задачи. Если не сказать явно что остановка — допустимый вариант, модель воспринимает её как провал. Добавляешь "остановиться и спросить — тоже успех" — модель перестаёт избегать неопределённости. Механика: разрешение снимает внутренний конфликт между "быть полезным" и "избежать ошибки". Применяй: В агентных промптах добавь "Если не уверен — остановись и спроси. Это правильное действие, не ошибка"
Evaluation Awareness: модели "чувствуют" экзамен и надувают CoT без улучшения точности
Пишешь "покажи шаги решения", "будь внимательным", "объясни подробно". Модель включает "режим экзамена". Ответ становится в 3-5 раз длиннее. Больше вводных слов, осторожности, форматирования. Но точность остаётся той же (±0.02). Это артефакт RLHF — модель научилась что "экзаменационные" промпты = длинные ответы. Но длина не равна качеству
Убери рубрики когда не нужны шаги. Вместо "реши внимательно, покажи работу" пиши просто задачу. Если нужен строгий формат (число, JSON) — добавь "только X, без объяснений". Модель выдаст ответ сразу, сэкономишь токены, не сломаешь парсер
Задача требует строгий формат: "только число", "код в одном блоке". Но в промпте есть "покажи шаги" или "будь тщательным". Это противоречие. Модель выбирает показать работу — формат ломается. Парсер ждёт число, получает абзац рассуждений с числом внутри
Не смешивай. Строгий контракт = без рубрик развёрнутости. Напиши: "2847 × 3916 = ? (только число)". Если нужны и шаги и формат — раздели: сначала попроси рассуждения, потом отдельным запросом "теперь только ответ без текста"
Добавляешь в промпт явную установку на осторожность или уверенность. Осторожность: "Лучше скажи 'не уверен', чем ошибись". Модель чаще отказывается или добавляет оговорки. Меньше уверенных ошибок. Больше слов "возможно", "вероятно". Уверенность: "Будь уверенным и кратким". Модель режет hedging. Ответы короче. Но больше риск уверенной неправильной выдачи. Почему работает: Инсентив не меняет способности модели. Но меняет порог срабатывания. Осторожность поднимает порог "я точно знаю" — модель молчит чаще. Уверенность опускает — отвечает всегда. Когда применять: Критичные задачи (финансы, медицина, право) — хвали осторожность. Быстрые некритичные (идеи, черновики) — хвали уверенность. Не работает: Для субъективных оценок (творчество, мнения) инсентивы бессмысленны
Модель пишет на 500-1000 символов больше когда промпт "пахнет экзаменом". Но корреляция между длиной текста и правильностью ответа слабая (r ≈ 0.07-0.27). Длинный красивый ответ не значит верный. Это артефакт обучения: RLHF научил модель что "экзаменационные" промпты = развёрнутый стиль. Но стиль ортогонален способностям. Применяй: Не суди качество по объёму. Если ответ длинный и структурированный, но мимо вопроса — это форма без сути. Проверяй содержание, не длину
VeriCode: верифицируемые инструкции для оценки кода от LLM
Даёшь модели задачу плюс 3-5 дополнительных требований (стиль, формат, ограничения). Модель перераспределяет внимание: часть уходит на новые требования, качество основной задачи падает. Работает хуже хотя требования не касались функциональности. Проявляется в любых задачах где есть основная цель плюс несколько условий
Вариант 1: Ограничь до 1-2 требований в одном запросе. Вариант 2: Раздели на этапы — сначала основная задача, потом отдельным запросом "улучши стиль" с конкретными требованиями. Вариант 3: Если нужно 3+ требования, ставь критичные в начало и конец списка — там модель внимательнее
Даёшь список из 5+ пунктов. Модель лучше выполняет первый и последний. Пункты 2-3-4 (середина) выполняются на 5-10% хуже. Архитектура внимания фокусируется на границах контекста даже в коротких промптах. Универсально для любых списков инструкций
Самые важные требования ставь в начало или конец списка. Второстепенные — в середину. Если добавляешь требования постепенно (несколько запросов), критичные давай последними — свежая информация весит больше
Single-turn: Все требования в одном запросе. Модель видит полную картину, балансирует между целями, лучше сохраняет качество основной задачи. Но хуже выполняет все требования (особенно в середине списка). Multi-turn: Сначала основная задача, потом поэтапно добавляешь требования ("теперь добавь X", "теперь добавь Y"). Модель фокусируется на каждом локально, выполнение требований выше на 3-8%. Но чаще ломает то что работало — каждая правка вносит риск регрессии. Применяй: Single-turn когда функциональность критична (продакшн-код, точные расчёты). Multi-turn когда форма важнее содержания (шаблоны, стиль, презентации). Для 1-2 требований разницы почти нет
Модель балансирует между целями автоматически. Добавляешь явные требования (стиль, формат, ограничения) — часть "вычислительного бюджета" уходит туда. Основная задача выполняется хуже даже если требования её не касались. Эффект растёт с количеством: 1-2 требования безопасны, 3-4 заметная просадка, 5+ высокий риск. Применяй: Для сложных задач не добавляй больше 2 дополнительных требований. Остальное делай отдельным запросом на доработку
Обработка JSON в LLM: когда код лучше слов
Даёшь модели JSON от API. Просишь найти нужные данные. Модель путает похожие ключи (name, room_name, full_name). Берёт значения из не тех объектов. Сбивается на вложенности (массив внутри объекта внутри массива). Чем больше JSON — тем хуже: при 50K+ символов точность падает в разы. Проблема для любых задач где нужно обработать ответ API или инструмента
Не проси модель читать JSON напрямую. Вместо "прочитай и ответь" проси "напиши Python-функцию которая распарсит и вернёт ответ". Добавь схему JSON в промпт — модель увидит структуру как карту. Для больших ответов (50K+) дай сокращённую версию: один пример каждого типа объекта
Вместо "вот JSON, найди X" → "вот JSON и схема, напиши Python-функцию которая найдёт X". Модель пишет код типа def parse(data): return . Код выполняется — получаешь результат. Почему работает: Код однозначен. [item for item in data if item['price'] < 15000]if price <= 15000 не может быть понят двояко. Функция на 20 строк компактнее текстового ответа на 200 слов. Python для парсинга JSON — родная территория модели. Усиление: добавь схему JSON (+12% точности), дай пример структуры даже если полный ответ не влезает. Когда применять: фильтрация данных, агрегация (суммы, средние), множественные условия. Когда не работает: простое извлечение одного значения ("What is the price?") — там иногда прямой ответ точнее
Voting Ensembles: повышение надёжности LLM через голосование множественных ответов
Модель генерирует текст вероятностно. На сложный вопрос есть много вариантов продолжения с разными вероятностями. Но ты видишь только один ответ — самый вероятный по случайной выборке. Модель может быть неуверена внутри, но снаружи выглядит уверенно. Ты не видишь что было 40% за A, 35% за B, 25% за C
Спроси модель несколько раз независимо. Если ответы разные — модель неуверена. Если 80%+ попыток дают один ответ — это надёжный консенсус. Техника: Voting Ensembles (см. Методы)
Задай один вопрос модели N раз независимо (5-50 попыток). Посчитай частоту каждого ответа. Установи порог консенсуса K (например, 80% от N). Если доминирующий ответ набрал K+ голосов — прими его. Если нет — выдай "нет уверенного ответа" вместо галлюцинации. Промпт: Дай {N} независимых ответов. Каждый — отдельное рассуждение, не копируй предыдущие. В конце: если {K}+ ответов совпадают — финальный ответ. Иначе — признай отсутствие консенсуса. Почему работает: Вероятностная природа генерации. Если правильный ответ очевиден — появится в большинстве попыток. Если модель не уверена — разброс покажет это явно. Рычаги: N=5-10 для простых вопросов, 20-50 для критических. K=0.5N (баланс), K=0.8N (высокая надёжность, меньше ответов). Когда применять: критическая цена ошибки (юридические, медицинские задачи), есть бюджет токенов, не нужен мгновенный ответ. Когда не работает: модель фундаментально не знает факт (дата отсечки, отсутствие в обучении) — все попытки дадут одинаковую галлюцинацию
Модель генерирует текст через выборку из распределения вероятностей. На один вопрос может быть несколько правдоподобных продолжений. Если спросить 10 раз и получить 5 разных ответов — модель не уверена, вопрос сложный. Если 9 из 10 одинаковые — модель уверена, ответ надёжный. Это честный индикатор внутренней неопределённости. Применяй: Для критических решений делай 10-20 независимых запросов. Считай уникальные ответы. Много вариантов = проверяй другими способами
PARSE: автоматическая оптимизация JSON-схем для точной экстракции данных из текста
Эпизодическая память через рефлексии: как LLM учится на своих ошибках
Модель отвечает на первую порцию вопросов. Ты показываешь правильные ответы. Модель пишет для каждой ошибки: "что пошло не так" и "как избежать". Сохраняешь эти кейсы {вопрос + контекст + ответ + правильный ответ + рефлексия}. Когда новый вопрос — находишь 3 самых похожих примера, вставляешь как few-shot контекст. Почему работает: Рефлексия = мета-уровень. Модель видит не просто "верно/неверно", а паттерн ошибки ("додумал факт → скажи 'нет информации'"). Few-shot с объяснением ошибок учит лучше чем просто правильные примеры. Когда применять: Задачи где можно проверить первые 5-10 ответов вручную. Есть типичные ошибки (додумывание, неточные даты, путаница фактов). Много похожих вопросов дальше. Когда не работает: Нет эталонных ответов для первой порции. Каждый вопрос уникален (нет похожих в будущем). Простые one-hop вопросы ("столица Франции") — накладные расходы не оправданы. Слабые базовые модели (Llama 3B, Mistral 7B) — не понимают структурированную рефлексию
Когда показываешь модели ошибку + объяснение ("я додумал цифру которой не было → нужно говорить 'нет информации'"), она учится на паттерне, а не на факте. Простой feedback ("это неверно") не показывает ЧТО именно сломалось. Рефлексия добавляет причинно-следственную связь: модель видит логику ошибки и применяет к похожим случаям. Применяй: В few-shot примерах добавляй не только правильный ответ, но и типичную ошибку + короткое объяснение (2-3 предложения) "почему ошиблась" и "как правильно"
PerFine: персонализация текста через итеративную критику
При многошаговой доработке текста сравнивай каждую новую версию с предыдущей. Оставляй лучшую. Как делать: После каждой правки добавь шаг: "Сравни версию A (старая) и версию B (новая). Какая лучше по критериям X, Y, Z? Выбери и объясни." Сохраняй победившую версию для следующей итерации. Почему работает: Правка одного аспекта может ухудшить другой. Модель улучшает тон — но упрощает структуру. Или добавляет детали — но теряет нужную эмоцию. Сравнение версий ловит такие откаты. Остаётся лучший вариант из всех попыток. Когда применять: Задачи с 3+ итерациями доработки, где баланс между критериями важнее максимума по одному. Примеры: стилизация текста, балансировка тона, сохранение деталей при сокращении. Когда не работает: Однозначные правки (исправление фактов, добавление забытого пункта) — там откат невозможен, сравнение лишнее
Двухперсонная система для креативности: как разделение дивергентного и конвергентного мышления усиливает идеи
FOR-Prompting: виртуальная команда вопросов для улучшения ответов LLM
Модель играет три роли в цикле. Defender предлагает решение → Debater задаёт 3-5 вопросов (НЕ даёт готовых ответов!) → Defender пересматривает решение с учётом вопросов → цикл повторяется 3-7 раз → Host собирает итоговый ответ. Ключ: Debater ТОЛЬКО спрашивает ("А что если X?", "Учёл ли ты Y?"), никогда не предлагает решения. Почему работает: Вопросы триггерят переосмысление. Модель сама находит пробелы вместо того чтобы получить готовый вариант. Авторство остаётся у Defender — понятно откуда итоговое решение. Когда применять: Открытые задачи (планирование, бизнес-идеи, мозгоштурм), где нужно найти слепые зоны и допущения. Работает на GPT-4, Claude, o1. Когда НЕ работает: Задачи с однозначным ответом (математика, факты). Слабые модели (<7B) дают поверхностные вопросы. Стоит 3-7x токенов — для простых задач избыточно
QAgent: многораундовая оптимизация запросов через интерактивное планирование и поиск
Divide-and-Conquer + Few-shot: почему явные инструкции работают даже для reasoning-моделей
NLT (Natural Language Tools): вызов инструментов через естественный язык вместо JSON
Relevance + Coherence: два измерения качества рассуждений LLM
Что делать: Добавь в системный промпт определения двух критериев. Релевантность: шаг решает конкретную часть задачи, не уходит в общие рассуждения. Связность: шаг логически следует из предыдущих, нет скачков без объяснения. Попроси модель следовать этим критериям на каждом шаге рассуждения. Шаблон: "При решении следуй двум принципам: [определение релевантности], [определение связности]". Почему работает: Явные критерии в промпте = внутренний чеклист при генерации. Модель на каждом токене "держит в голове" эти правила и корректирует вывод. Особенно эффективно для длинных цепочек рассуждений. Когда применять: многошаговый анализ (5+ шагов), планирование, принятие решений, стратегические вопросы. Когда НЕ работает: простые вопросы из 1-2 шагов (избыточность), задачи где "связность" не критична (списки, перечисления)
Что это: Модель может сделать математически корректный шаг, но он будет не про задачу (нерелевантен) или не следовать из предыдущего контекста (несвязен). Пример: в бизнес-анализе модель уходит в общие рассуждения про экономику (нерелевантно) или прыгает с темы на тему без связи (несвязно). Механика: Такие шаги ломают всю цепочку. Даже если остальные шаги верны, один нерелевантный/несвязный снижает шанс правильного финального ответа с 52% до 24%. Применяй: В сложных задачах явно пропиши что каждый шаг должен быть про конкретную часть вопроса И следовать из предыдущих. Не надейся на автоматическую связность
Question-Mode: LLM как собеседник, который задаёт вопросы вместо готовых ответов
Просишь "предложи 10 вариантов названия для продукта". Получаешь 10 вариантов. Просишь ещё 10 у другой сессии — получаешь очень похожие. Все идеи в одном стилистическом коридоре. Причина: модель усредняет по обучающим данным, выдаёт статистически типичное. Проблема для креативных задач где нужны разные направления, а не вариации одного
Не проси модель генерировать за тебя. Проси задавать вопросы и предлагать аналогии из других областей. Ты сам генеришь идеи отвечая на вопросы — твой контекст + направляющие вопросы модели = больше разнообразия
Модель НЕ генерирует идеи сама. Она задаёт вопросы которые заставляют ТЕБЯ думать. Два этапа в одном диалоге: Этап 1 (поиск направлений): модель задаёт вопросы + предлагает аналогии из других областей (не из твоей темы), ты генеришь 2-3 альтернативных направления, выбираешь одно. Этап 2 (развитие идеи): модель задаёт целевые вопросы для конкретизации, ты сам прорабатываешь детали отвечая. Почему работает: Ты остаёшься автором (используешь свой контекст), модель подсвечивает слепые зоны через кросс-доменные аналогии. Результат: идеи качественнее и разнообразнее чем при генерации моделью. Промпт: "Помоги развить идею через вопросы, не давай готовых решений. ЭТАП 1: моя идея [опиши]. Задавай вопросы + предлагай аналогии из [других областей]. Я сгенерирую альтернативы и выберу одну. ЭТАП 2: после выбора задавай вопросы для проработки [аудитории/механики/и т.д.]. НЕ генерируй решения — направляй моё мышление". Когда применять: креативные задачи (стратегия, концепции, идеи контента), есть время на проработку, нужно разнообразие направлений. Когда НЕ работает: простые исполнительские задачи, нужен быстрый результат без размышлений, ты не эксперт в теме (вопросы заведут в тупик)
Когда модель предлагает аналогии из ТВОЕЙ области — получаешь типичные ассоциации. Когда из других областей (музыка для брендинга кофе, спорт для архитектуры) — выходишь из шаблонов мышления. Модель знает много доменов, может находить неожиданные параллели. Применяй: в промпте указывай "предлагай аналогии из [музыки/природных процессов/спорта] — НЕ из [твоей темы]". Чем дальше область — тем неожиданнее ассоциации
Bloom-Aligned Prompting: как детальные инструкции решают проблему когнитивного выравнивания в AI
Data-Model Co-Evolution: итеративное улучшение промптов через растущий тестовый набор
Разблокируйте все концепты с PRO
Получите полный доступ ко всем все концепты и методам из научных исследований
