3,583 papers

Все концепты

Концепты из исследований октября 2025

30 исследований, 78 концептов — отсортировано по рейтингу

4

Many-Shot Paradox: когда больше примеров = хуже результат

4 концепта
92
Проблемы (1)
Много примеров в промпте снижают качество после порога

Даёшь модели 5-25 примеров — результат отличный. Увеличиваешь до 100-600 примеров — качество падает на 5-10%. Модель начинает копировать поверхностные паттерны (длину фраз, частые слова, синтаксис), но теряет глубокую логику. Результат выглядит правдоподобно, но работает неправильно. Проблема универсальна: перевод кода, написание текстов, анализ данных — везде где нужна точность

Как обойти

Держи 5-25 примеров. Не больше. Выбирай разнообразные примеры, но в рамках одного паттерна (разные сценарии, но единый стиль). Добавь явную инструкцию: "сохрани стиль из примеров, но адаптируй под новый контекст" — это помогает модели не копировать слепо

Методы (1)
Диапазон 5-25 примеров для сложных задач

Для задач требующих точности (не просто "переведи слово") давай 5-25 примеров в промпте. Меньше 5 — модель может не схватить стиль. Больше 25 — начинается деградация: модель имитирует форму вместо сути. Шаблон: Ты {роль}. Вот {5-25} примеров {типа контента}: [Пример 1], [Пример 2]... Теперь создай для нового контекста: {параметры}. Сохрани {что важно}, но адаптируй под {новое}. Почему работает: Модель ищет паттерны. Малое количество качественных примеров даёт чёткий паттерн без шума. Много примеров создают конфликтующие сигналы — модель теряет фокус. Когда применять: сложные задачи с чёткими критериями правильности (стиль + точность, формат + логика). Когда нет: простые задачи (zero-shot достаточно), креативные задачи (примеры ограничивают фантазию)

Тезисы (2)
Слишком много примеров создают конфликтующие паттерны

Модель не "понимает" задачу — она ищет паттерны в примерах. При 5-25 примерах паттерн чёткий. При 100+ примерах паттерны конфликтуют: одни примеры говорят "пиши коротко", другие "пиши длинно", третьи "будь серьёзным", четвёртые "будь эмоциональным". Модель начинает копировать поверхностные признаки (структуру предложений, частоту слов) вместо глубокой логики. Результат выглядит похоже на нужное, но функционально ломается. Применяй: Если добавил 20+ примеров и результат стал хуже — убери половину. Оставь 5-10 самых качественных и разнообразных

Модель лучше обобщает из малого набора качественных примеров

5-8 качественных примеров достаточно чтобы модель извлекла суть стиля, тона, структуры. Это как объяснить задачу человеку — нужно 3-5 хороших примеров, а не 100 посредственных. Малое количество заставляет модель искать общий принцип, а не копировать детали. Большое количество провоцирует механическое микширование фраз из разных примеров. Применяй: Вместо "дам все 50 примеров что есть" выбери 8 лучших — с разными сценариями, но единым стилем. Модель схватит суть без шума

5

Quit Instructions: учи агента останавливаться в неоднозначных ситуациях

3 концепта
92
Проблемы (1)
Агент пытается выполнить задачу даже при недостатке информации

Агент видит двусмысленную инструкцию ("переведи деньги Сергею Петрову"). Находит двух Сергеев Петровых в базе. Выбирает первого наугад вместо того чтобы спросить. Действует потому что обучен быть полезным и завершать задачи. В агентных сценариях с реальными последствиями (переводы, доступы, данные) такая "помощь" приводит к необратимым ошибкам

Как обойти

Добавь явные инструкции КОГДА агент должен остановиться. Не "можешь выйти если хочешь", а "ДОЛЖЕН остановиться если: не можешь исключить негативные последствия, нужна дополнительная информация для безопасных действий, недостаточно знаний для оценки рисков". Дай модели разрешение НЕ завершать задачу — остановка и запрос уточнений тоже считается успехом

Методы (1)
Инструкции останова — агент спрашивает вместо угадывания

Добавь в system prompt явные условия КОГДА агент обязан остановиться и спросить: Ты ДОЛЖЕН остановиться если: 1) не можешь исключить негативные последствия, 2) нужна информация о том что делать, 3) нужна информация о текущей ситуации, 4) недостаточно знаний для оценки рисков. Плюс негативные условия: НЕ останавливайся если: есть безопасные действия для сбора информации. Почему работает: Переопределяет базовую мотивацию модели. Вместо "помочь = выполнить любой ценой" становится "помочь = выполнить безопасно или спросить". Остановка больше не воспринимается как провал. Когда: Задачи с серьёзными последствиями (финансы, доступы, данные). Не работает: Низкорисковые информационные задачи — агент будет останавливаться избыточно. Open-source модели (Llama, малые Qwen) слабо реагируют на такие инструкции

Тезисы (1)
Явное разрешение не завершать задачу переопределяет поведение модели

Модели обучены завершать задачи. Если не сказать явно что остановка — допустимый вариант, модель воспринимает её как провал. Добавляешь "остановиться и спросить — тоже успех" — модель перестаёт избегать неопределённости. Механика: разрешение снимает внутренний конфликт между "быть полезным" и "избежать ошибки". Применяй: В агентных промптах добавь "Если не уверен — остановись и спроси. Это правильное действие, не ошибка"

6

Evaluation Awareness: модели "чувствуют" экзамен и надувают CoT без улучшения точности

4 концепта
90
Проблемы (2)
"Экзаменационные" формулировки раздувают ответы без роста точности

Пишешь "покажи шаги решения", "будь внимательным", "объясни подробно". Модель включает "режим экзамена". Ответ становится в 3-5 раз длиннее. Больше вводных слов, осторожности, форматирования. Но точность остаётся той же (±0.02). Это артефакт RLHF — модель научилась что "экзаменационные" промпты = длинные ответы. Но длина не равна качеству

Как обойти

Убери рубрики когда не нужны шаги. Вместо "реши внимательно, покажи работу" пиши просто задачу. Если нужен строгий формат (число, JSON) — добавь "только X, без объяснений". Модель выдаст ответ сразу, сэкономишь токены, не сломаешь парсер

Рубрики конфликтуют со строгими контрактами

Задача требует строгий формат: "только число", "код в одном блоке". Но в промпте есть "покажи шаги" или "будь тщательным". Это противоречие. Модель выбирает показать работу — формат ломается. Парсер ждёт число, получает абзац рассуждений с числом внутри

Как обойти

Не смешивай. Строгий контракт = без рубрик развёрнутости. Напиши: "2847 × 3916 = ? (только число)". Если нужны и шаги и формат — раздели: сначала попроси рассуждения, потом отдельным запросом "теперь только ответ без текста"

Методы (1)
Калибровка инсентивов — управление типом ошибок

Добавляешь в промпт явную установку на осторожность или уверенность. Осторожность: "Лучше скажи 'не уверен', чем ошибись". Модель чаще отказывается или добавляет оговорки. Меньше уверенных ошибок. Больше слов "возможно", "вероятно". Уверенность: "Будь уверенным и кратким". Модель режет hedging. Ответы короче. Но больше риск уверенной неправильной выдачи. Почему работает: Инсентив не меняет способности модели. Но меняет порог срабатывания. Осторожность поднимает порог "я точно знаю" — модель молчит чаще. Уверенность опускает — отвечает всегда. Когда применять: Критичные задачи (финансы, медицина, право) — хвали осторожность. Быстрые некритичные (идеи, черновики) — хвали уверенность. Не работает: Для субъективных оценок (творчество, мнения) инсентивы бессмысленны

Тезисы (1)
Длина рассуждений не коррелирует с точностью ответа

Модель пишет на 500-1000 символов больше когда промпт "пахнет экзаменом". Но корреляция между длиной текста и правильностью ответа слабая (r 0.07-0.27). Длинный красивый ответ не значит верный. Это артефакт обучения: RLHF научил модель что "экзаменационные" промпты = развёрнутый стиль. Но стиль ортогонален способностям. Применяй: Не суди качество по объёму. Если ответ длинный и структурированный, но мимо вопроса — это форма без сути. Проверяй содержание, не длину

8

VeriCode: верифицируемые инструкции для оценки кода от LLM

4 концепта
88
Проблемы (2)
Множественные требования ломают основную задачу

Даёшь модели задачу плюс 3-5 дополнительных требований (стиль, формат, ограничения). Модель перераспределяет внимание: часть уходит на новые требования, качество основной задачи падает. Работает хуже хотя требования не касались функциональности. Проявляется в любых задачах где есть основная цель плюс несколько условий

Как обойти

Вариант 1: Ограничь до 1-2 требований в одном запросе. Вариант 2: Раздели на этапы — сначала основная задача, потом отдельным запросом "улучши стиль" с конкретными требованиями. Вариант 3: Если нужно 3+ требования, ставь критичные в начало и конец списка — там модель внимательнее

Инструкции в середине списка теряются

Даёшь список из 5+ пунктов. Модель лучше выполняет первый и последний. Пункты 2-3-4 (середина) выполняются на 5-10% хуже. Архитектура внимания фокусируется на границах контекста даже в коротких промптах. Универсально для любых списков инструкций

Как обойти

Самые важные требования ставь в начало или конец списка. Второстепенные — в середину. Если добавляешь требования постепенно (несколько запросов), критичные давай последними — свежая информация весит больше

Методы (1)
Single-turn vs Multi-turn для множественных требований

Single-turn: Все требования в одном запросе. Модель видит полную картину, балансирует между целями, лучше сохраняет качество основной задачи. Но хуже выполняет все требования (особенно в середине списка). Multi-turn: Сначала основная задача, потом поэтапно добавляешь требования ("теперь добавь X", "теперь добавь Y"). Модель фокусируется на каждом локально, выполнение требований выше на 3-8%. Но чаще ломает то что работало — каждая правка вносит риск регрессии. Применяй: Single-turn когда функциональность критична (продакшн-код, точные расчёты). Multi-turn когда форма важнее содержания (шаблоны, стиль, презентации). Для 1-2 требований разницы почти нет

Тезисы (1)
Дополнительные требования снижают качество основной задачи

Модель балансирует между целями автоматически. Добавляешь явные требования (стиль, формат, ограничения) — часть "вычислительного бюджета" уходит туда. Основная задача выполняется хуже даже если требования её не касались. Эффект растёт с количеством: 1-2 требования безопасны, 3-4 заметная просадка, 5+ высокий риск. Применяй: Для сложных задач не добавляй больше 2 дополнительных требований. Остальное делай отдельным запросом на доработку

9

Обработка JSON в LLM: когда код лучше слов

2 концепта
88
Проблемы (1)
Модель теряется в структуре JSON

Даёшь модели JSON от API. Просишь найти нужные данные. Модель путает похожие ключи (name, room_name, full_name). Берёт значения из не тех объектов. Сбивается на вложенности (массив внутри объекта внутри массива). Чем больше JSON — тем хуже: при 50K+ символов точность падает в разы. Проблема для любых задач где нужно обработать ответ API или инструмента

Как обойти

Не проси модель читать JSON напрямую. Вместо "прочитай и ответь" проси "напиши Python-функцию которая распарсит и вернёт ответ". Добавь схему JSON в промпт — модель увидит структуру как карту. Для больших ответов (50K+) дай сокращённую версию: один пример каждого типа объекта

Методы (1)
Генерация кода для парсинга вместо прямого ответа

Вместо "вот 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?") — там иногда прямой ответ точнее

12

Voting Ensembles: повышение надёжности LLM через голосование множественных ответов

3 концепта
88
Проблемы (1)
Одиночный ответ скрывает неуверенность модели

Модель генерирует текст вероятностно. На сложный вопрос есть много вариантов продолжения с разными вероятностями. Но ты видишь только один ответ — самый вероятный по случайной выборке. Модель может быть неуверена внутри, но снаружи выглядит уверенно. Ты не видишь что было 40% за A, 35% за B, 25% за C

Как обойти

Спроси модель несколько раз независимо. Если ответы разные — модель неуверена. Если 80%+ попыток дают один ответ — это надёжный консенсус. Техника: Voting Ensembles (см. Методы)

Методы (1)
Voting Ensembles — консенсус множественных попыток

Задай один вопрос модели N раз независимо (5-50 попыток). Посчитай частоту каждого ответа. Установи порог консенсуса K (например, 80% от N). Если доминирующий ответ набрал K+ голосов — прими его. Если нет — выдай "нет уверенного ответа" вместо галлюцинации. Промпт: Дай {N} независимых ответов. Каждый — отдельное рассуждение, не копируй предыдущие. В конце: если {K}+ ответов совпадают — финальный ответ. Иначе — признай отсутствие консенсуса. Почему работает: Вероятностная природа генерации. Если правильный ответ очевиден — появится в большинстве попыток. Если модель не уверена — разброс покажет это явно. Рычаги: N=5-10 для простых вопросов, 20-50 для критических. K=0.5N (баланс), K=0.8N (высокая надёжность, меньше ответов). Когда применять: критическая цена ошибки (юридические, медицинские задачи), есть бюджет токенов, не нужен мгновенный ответ. Когда не работает: модель фундаментально не знает факт (дата отсечки, отсутствие в обучении) — все попытки дадут одинаковую галлюцинацию

Тезисы (1)
Разброс ответов при повторных запросах показывает реальную неуверенность

Модель генерирует текст через выборку из распределения вероятностей. На один вопрос может быть несколько правдоподобных продолжений. Если спросить 10 раз и получить 5 разных ответов — модель не уверена, вопрос сложный. Если 9 из 10 одинаковые — модель уверена, ответ надёжный. Это честный индикатор внутренней неопределённости. Применяй: Для критических решений делай 10-20 независимых запросов. Считай уникальные ответы. Много вариантов = проверяй другими способами

14

Эпизодическая память через рефлексии: как LLM учится на своих ошибках

2 концепта
87
Методы (1)
Цикл рефлексии — обучение на своих ошибках

Модель отвечает на первую порцию вопросов. Ты показываешь правильные ответы. Модель пишет для каждой ошибки: "что пошло не так" и "как избежать". Сохраняешь эти кейсы {вопрос + контекст + ответ + правильный ответ + рефлексия}. Когда новый вопрос — находишь 3 самых похожих примера, вставляешь как few-shot контекст. Почему работает: Рефлексия = мета-уровень. Модель видит не просто "верно/неверно", а паттерн ошибки ("додумал факт скажи 'нет информации'"). Few-shot с объяснением ошибок учит лучше чем просто правильные примеры. Когда применять: Задачи где можно проверить первые 5-10 ответов вручную. Есть типичные ошибки (додумывание, неточные даты, путаница фактов). Много похожих вопросов дальше. Когда не работает: Нет эталонных ответов для первой порции. Каждый вопрос уникален (нет похожих в будущем). Простые one-hop вопросы ("столица Франции") — накладные расходы не оправданы. Слабые базовые модели (Llama 3B, Mistral 7B) — не понимают структурированную рефлексию

Тезисы (1)
Рефлексия "почему ошибка" работает сильнее чем просто "правильно/неправильно"

Когда показываешь модели ошибку + объяснение ("я додумал цифру которой не было нужно говорить 'нет информации'"), она учится на паттерне, а не на факте. Простой feedback ("это неверно") не показывает ЧТО именно сломалось. Рефлексия добавляет причинно-следственную связь: модель видит логику ошибки и применяет к похожим случаям. Применяй: В few-shot примерах добавляй не только правильный ответ, но и типичную ошибку + короткое объяснение (2-3 предложения) "почему ошиблась" и "как правильно"

15

PerFine: персонализация текста через итеративную критику

1 концепт
87
Методы (1)
Сравнение версий между итерациями — защита от регресса

При многошаговой доработке текста сравнивай каждую новую версию с предыдущей. Оставляй лучшую. Как делать: После каждой правки добавь шаг: "Сравни версию A (старая) и версию B (новая). Какая лучше по критериям X, Y, Z? Выбери и объясни." Сохраняй победившую версию для следующей итерации. Почему работает: Правка одного аспекта может ухудшить другой. Модель улучшает тон — но упрощает структуру. Или добавляет детали — но теряет нужную эмоцию. Сравнение версий ловит такие откаты. Остаётся лучший вариант из всех попыток. Когда применять: Задачи с 3+ итерациями доработки, где баланс между критериями важнее максимума по одному. Примеры: стилизация текста, балансировка тона, сохранение деталей при сокращении. Когда не работает: Однозначные правки (исправление фактов, добавление забытого пункта) — там откат невозможен, сравнение лишнее

16

Двухперсонная система для креативности: как разделение дивергентного и конвергентного мышления усиливает идеи

2 концепта
PRO
Полный контент доступен в PRO
17

FOR-Prompting: виртуальная команда вопросов для улучшения ответов LLM

1 концепт
87
Методы (1)
Вопросы вместо исправлений — глубже переосмысление

Модель играет три роли в цикле. Defender предлагает решение Debater задаёт 3-5 вопросов (НЕ даёт готовых ответов!) Defender пересматривает решение с учётом вопросов цикл повторяется 3-7 раз Host собирает итоговый ответ. Ключ: Debater ТОЛЬКО спрашивает ("А что если X?", "Учёл ли ты Y?"), никогда не предлагает решения. Почему работает: Вопросы триггерят переосмысление. Модель сама находит пробелы вместо того чтобы получить готовый вариант. Авторство остаётся у Defender — понятно откуда итоговое решение. Когда применять: Открытые задачи (планирование, бизнес-идеи, мозгоштурм), где нужно найти слепые зоны и допущения. Работает на GPT-4, Claude, o1. Когда НЕ работает: Задачи с однозначным ответом (математика, факты). Слабые модели (<7B) дают поверхностные вопросы. Стоит 3-7x токенов — для простых задач избыточно

24

Relevance + Coherence: два измерения качества рассуждений LLM

2 концепта
86
Методы (1)
Два измерения качества шагов — релевантность + связность

Что делать: Добавь в системный промпт определения двух критериев. Релевантность: шаг решает конкретную часть задачи, не уходит в общие рассуждения. Связность: шаг логически следует из предыдущих, нет скачков без объяснения. Попроси модель следовать этим критериям на каждом шаге рассуждения. Шаблон: "При решении следуй двум принципам: [определение релевантности], [определение связности]". Почему работает: Явные критерии в промпте = внутренний чеклист при генерации. Модель на каждом токене "держит в голове" эти правила и корректирует вывод. Особенно эффективно для длинных цепочек рассуждений. Когда применять: многошаговый анализ (5+ шагов), планирование, принятие решений, стратегические вопросы. Когда НЕ работает: простые вопросы из 1-2 шагов (избыточность), задачи где "связность" не критична (списки, перечисления)

Тезисы (1)
Нерелевантные или несвязные шаги убивают точность в 2 раза

Что это: Модель может сделать математически корректный шаг, но он будет не про задачу (нерелевантен) или не следовать из предыдущего контекста (несвязен). Пример: в бизнес-анализе модель уходит в общие рассуждения про экономику (нерелевантно) или прыгает с темы на тему без связи (несвязно). Механика: Такие шаги ломают всю цепочку. Даже если остальные шаги верны, один нерелевантный/несвязный снижает шанс правильного финального ответа с 52% до 24%. Применяй: В сложных задачах явно пропиши что каждый шаг должен быть про конкретную часть вопроса И следовать из предыдущих. Не надейся на автоматическую связность

26

Question-Mode: LLM как собеседник, который задаёт вопросы вместо готовых ответов

3 концепта
85
Проблемы (1)
Модель генерирует похожие идеи при повторных запросах

Просишь "предложи 10 вариантов названия для продукта". Получаешь 10 вариантов. Просишь ещё 10 у другой сессии — получаешь очень похожие. Все идеи в одном стилистическом коридоре. Причина: модель усредняет по обучающим данным, выдаёт статистически типичное. Проблема для креативных задач где нужны разные направления, а не вариации одного

Как обойти

Не проси модель генерировать за тебя. Проси задавать вопросы и предлагать аналогии из других областей. Ты сам генеришь идеи отвечая на вопросы — твой контекст + направляющие вопросы модели = больше разнообразия

Методы (1)
Вопросный режим для креативных задач

Модель НЕ генерирует идеи сама. Она задаёт вопросы которые заставляют ТЕБЯ думать. Два этапа в одном диалоге: Этап 1 (поиск направлений): модель задаёт вопросы + предлагает аналогии из других областей (не из твоей темы), ты генеришь 2-3 альтернативных направления, выбираешь одно. Этап 2 (развитие идеи): модель задаёт целевые вопросы для конкретизации, ты сам прорабатываешь детали отвечая. Почему работает: Ты остаёшься автором (используешь свой контекст), модель подсвечивает слепые зоны через кросс-доменные аналогии. Результат: идеи качественнее и разнообразнее чем при генерации моделью. Промпт: "Помоги развить идею через вопросы, не давай готовых решений. ЭТАП 1: моя идея [опиши]. Задавай вопросы + предлагай аналогии из [других областей]. Я сгенерирую альтернативы и выберу одну. ЭТАП 2: после выбора задавай вопросы для проработки [аудитории/механики/и т.д.]. НЕ генерируй решения — направляй моё мышление". Когда применять: креативные задачи (стратегия, концепции, идеи контента), есть время на проработку, нужно разнообразие направлений. Когда НЕ работает: простые исполнительские задачи, нужен быстрый результат без размышлений, ты не эксперт в теме (вопросы заведут в тупик)

Тезисы (1)
Аналогии из далёких областей эффективнее для креативных задач

Когда модель предлагает аналогии из ТВОЕЙ области — получаешь типичные ассоциации. Когда из других областей (музыка для брендинга кофе, спорт для архитектуры) — выходишь из шаблонов мышления. Модель знает много доменов, может находить неожиданные параллели. Применяй: в промпте указывай "предлагай аналогии из [музыки/природных процессов/спорта] — НЕ из [твоей темы]". Чем дальше область — тем неожиданнее ассоциации

Разблокируйте все концепты с PRO

Получите полный доступ ко всем все концепты и методам из научных исследований

Оплатить через Геткурс
YandexPay • SberPay • СБП • Карты РФ
Оплатить через Tribute
Telegram Stars • Моментальный доступ
Узнать о PRO