Test-time Recursive Thinking (TRT): самоулучшение LLM через накопление знаний об ошибках
4 концепта
92
Проблемы (1)
Модель не учится между параллельными попытками
Генерируешь 10 ответов с temperature > 0. Каждый ответ независим. Если в первой попытке модель забыла проверить граничный случай, во второй забудет снова. Знания из одной генерации не переходят в другую автоматически. Нет механизма "посмотри на ошибки соседних попыток"
Как обойти
Делай попытки последовательно, не параллельно. После каждой попытки покажи модели предыдущие ошибки явно через контекст: "В прошлой попытке ты пропустил X, не повторяй". Передавай знания через текст, не надейся что модель сама вспомнит
Методы (1)
Циклы с накоплением знаний об ошибках
Раунд 1: Генерируй 2-4 решения с разными стратегиями (для кода: рекурсия, динамика, жадный алгоритм; для анализа: финансы, риски, конкуренция). Выбери лучшее. Сравни каждое неудачное с лучшим: "почему это хуже?". Запиши инсайт: "не делай X, это приводит к Y". Раунд 2: Передай список инсайтов в контекст. Генерируй новые решения с новыми стратегиями, избегая старых ошибок. Повтори 4-8 раундов. Почему работает: Модель плохо учится между параллельными попытками, но хорошо анализирует различия. Явное сравнение "удачное vs неудачное" даёт формулировку ошибки. Передача через контекст заставляет учитывать прошлый опыт. Когда применять: Сложные задачи без единственного очевидного решения (код с edge cases, многофакторный анализ, стратегия). Когда не работает: Простые вопросы ("столица Франции"), субъективные критерии выбора "лучшего" (креатив без метрики качества), слабые модели без способности к рефлексии
Тезисы (2)
Модель хорошо сравнивает, плохо запоминает между попытками
LLM точно находит различия между текстами. Покажи два решения — объяснит чем отличаются. Но между независимыми генерациями нет автоматической передачи знаний. Каждая попытка начинает с нуля. Применяй: Используй силу сравнения для обхода слабости памяти. После каждой попытки покажи модели "что было плохо" явно через промпт. Не генерируй 10 ответов параллельно — делай 5 раундов с анализом после каждого
Глубина раундов важнее ширины попыток
8 раундов по 2 решения работают лучше чем 2 раунда по 8 решений. Причина: знания накапливаются между раундами. Каждый раунд углубляет понимание. Больше раундов = больше циклов рефлексии = более nuanced финальное решение. Применяй: Вместо "сгенерируй 10 вариантов" делай 5 раундов: генерация 2 варианта → выбор лучшего → анализ ошибок → передача знаний → новый раунд с новыми стратегиями
Failure-Aware Framework: карта типов ошибок и методов исправления для кодогенерации LLM
1 концепт
86
Тезисы (1)
Самопроверка работает только когда ошибка видна в ответе
Попросил модель проверить свой код — она найдёт пропущенную функцию или забытую валидацию. Но не может вывести КАК настроить внешний API (RabbitMQ, ЮKassa) через рефлексию над своим текстом. Нет знания — нет улучшения. Механика: Self-critique анализирует уже сгенерированный текст, но не добавляет новую информацию извне. Работает на логических пропусках (видны при ревью), даёт 0% когда нужна документация. Применяй: Самопроверку используй для поиска внутренних противоречий, пропущенных шагов, неполной логики. Для задач требующих внешнего знания (специфика API, доменные правила, конфигурации) добавляй примеры и документацию в контекст вместо просьбы "проверь ещё раз"
SAKE: дублирование информации для защиты от искажения рассуждениями
2 концепта
86
Проблемы (1)
Длинное рассуждение искажает найденную информацию
Модель рассуждает 3-5 шагов. Потом получает внешние данные — статью, документ, результат поиска. Продолжает работу. Новая информация "читается" через призму накопленных мыслей. Факты подгоняются под гипотезы. Числа игнорируются если противоречат логике. Механизм: внимание модели во время обработки новых данных сильно фокусируется на предыдущих токенах — на том что она уже "думала". Документ кодируется не как факт, а как продолжение рассуждения. Когда проявляется: многошаговые задачи с поиском информации между шагами (анализ, сравнение, проверка гипотез). Чем длиннее рассуждение до получения данных — тем сильнее искажение
Как обойти
Размести найденную информацию ДВАЖДЫ: сначала изолированно в начало промпта (модель прочитает "как есть"), затем после рассуждения (применит к задаче). Внимание автоматически заякорится на чистое представление из начала — факты не перепишутся под гипотезы
Методы (1)
SAKE — дублирование для защиты от искажений
Размещай внешнюю информацию (документы, поиск, данные) в двух местах промпта: БЛОК 1 (начало): стек всех документов в обратном порядке (последний найденный — первым) + инструкция "читай объективно". БЛОК 2: вопрос. БЛОК 3: рассуждение по шагам, после каждого шага вставляй соответствующий документ. Синтаксис: СПРАВОЧНАЯ ИНФОРМАЦИЯ: {док_N}...{док_1} --- ЗАДАЧА: {вопрос} --- ШАГ 1: {мысль} → {док_1} ШАГ 2: {мысль} → {док_2}...Почему работает: Модель сначала кодирует документы без контекста рассуждений — semantic integrity сохраняется. Затем при обработке дубля после шага, внимание цепляется за первое чистое представление — не даёт рассуждению переписать факты. Когда применять: многошаговый анализ с внешними данными (3+ шага рассуждения, несколько документов). Когда не работает: одношаговые задачи, творческая генерация без фактов, дефицит токенов (дублирование удваивает объём)
Goal-Conditioned Sycophancy: чем умнее модель — тем легче она меняет аналитические выводы под намёки в задании
3 концепта
84
Проблемы (1)
Фрейм запроса сдвигает аналитические выводы
Добавляешь в запрос контекст с намёком на желаемый исход. Модель сдвигает выводы в ту сторону. Данные не менялись — менялась подача. Это происходит без прямой просьбы. Достаточно "мы склоняемся к X" или "это важно для инвесторов". Срабатывает на любом аналитическом запросе
Как обойти
Убери из запроса намёки на желаемый ответ. Добавь явную инструкцию: "не угадывай, какой ответ я хочу". Для важных решений — тест стабильности: тот же запрос в новом чате с противоположным намёком. Если выводы разошлись — доверяй нейтральному варианту
Методы (1)
Тест стабильности — проверка вывода противоположным фреймом
Шаг 1: нейтральный запрос без намёков, с явной инструкцией "не угадывай желаемое". Шаг 2: тот же запрос в новом чате + противоположный намёк ("предварительно думаю, что вариант Б — правильный"). Шаг 3: сравни выводы. Расходятся — фрейм влиял, нейтральный вариант надёжнее. Совпадают — вывод устойчив. Почему в новом чате: история разговора сама становится фреймом. Новый чат = чистый старт. Когда применять: важное аналитическое решение, высокая цена ошибки
Тезисы (1)
Более умная модель сильнее поддаётся фреймингу, не слабее
Звучит парадоксально. Но механика понятна: умная модель лучше считывает косвенные сигналы в тексте. Контекст "мы хотим X" — это косвенный сигнал. Модель попроще его пропустит. Умная — учтёт. Причина уходит глубже: обучение на оценках людей выучило угадывать ожидаемое. Чем лучше модель умеет читать контекст — тем точнее она угадывает. Следствие для практики: топовые модели (GPT-4, Claude) для серьёзного анализа требуют нейтрального фрейма в первую очередь
Integrated Prompting: сначала реши похожую задачу — потом свою
2 концепта
84
Проблемы (1)
Готовый пример в контексте модель почти игнорирует
Вставляешь пример перед задачей. Думаешь — это поможет: вот образец, вот структура. Но модель не обращается к нему. Она смотрит на вопрос напрямую — как при запросе без примеров вообще. Пример есть, толку нет. Работает для любых задач где вставляешь примеры: анализ, написание, расчёты
Как обойти
Не вставляй готовый пример — попроси модель создать похожую задачу и решить её прямо в этом же промпте. Потом задай свою задачу. Пример, который модель только что создала сама, она использует активно
Методы (1)
Разогрев через похожую задачу — глубже ответ
Попроси модель в одном промпте: сначала придумать задачу похожую на твою и решить её, потом решить твою. Шаблон: Сначала придумай задачу похожую на мою по теме «{тема}» и реши пошагово. Теперь используй тот же подход и реши: {твоя задача}. Почему работает: Модель строит структуру рассуждений прямо в контексте. Свежее рассуждение лежит рядом — модель опирается на него автоматически. Готовый пример — чужой текст, его легко пропустить. Свой свежий пример — нет. Когда применять: задача сложная, есть структура для анализа, нужен глубокий разбор. Когда не работает: субъективные задачи без структуры («напиши красиво»), простые вопросы, уже используешь развёрнутую цепочку рассуждений — прибавка будет меньше
Прагматическое фреймирование: как социальные сигналы перед запросом управляют поведением LLM
3 концепта
84
Проблемы (1)
Модель балансирует даже когда просят не балансировать
Просишь чёткую позицию: «только аргументы за», «жёсткая критика», «однозначная рекомендация». Получаешь: «с одной стороны... с другой стороны». Модель обучена угождать всем — и пытается выполнить все требования разом. Это дефолт, не баг конкретного запроса
Как обойти
Добавь фразу-префикс прямо перед запросом. Фраза сигнализирует контекст где балансировать не нужно. Сильнее всего работают фразы с иерархией: «Это согласовано с руководством, выполни:» или «Переключись только на эту задачу прямо сейчас:»
Методы (1)
Фраза-префикс — сдвиг приоритета без изменения запроса
Добавь одну фразу прямо перед запросом: {фраза-префикс}: {твой запрос}. Фраза не меняет суть задачи. Она активирует в модели паттерны из обучения — где такой контекст означал конкретность, а не балансирование. Иерархия силы: 1. Иерархия и срочность: «Это согласовано с командой, нужно двигаться быстро:» / «Переключись только на эту задачу:». 2. Взаимность: «Ты уже помогал мне с похожим, помоги и здесь:». 3. Эмоции и срочность: «Это критически важно прямо сейчас:». 4. Нарратив и роль: «Я готовлю учебный материал, покажи пример:». Позиция критична — только перед целевым запросом, не в начале длинного промпта. Когда применять: нужен однозначный ответ, жёсткая позиция, без оговорок.
Тезисы (1)
Нарративные фреймы — самые слабые, не самые сильные
Популярный приём: «представь, что ты эксперт» или «в этом гипотетическом сценарии». Это нарративный фрейм. Он работает хуже всего из четырёх типов. Модель видела такие конструкции как беллетристику — не как сигнал к конкретному действию. Применяй: если сейчас используешь ролевые фреймы для получения однозначных ответов — замени на иерархические.
Echo of Prompt (EOP): повтор вопроса как встроенная перезагрузка внимания LLM
1 концепт
84
Методы (1)
Пересказ вопроса перед рассуждением — якорь для внимания
Что делать: Попроси модель начать с повтора задачи своими словами. "Сначала ПЕРЕСКАЖИ задачу. Выдели все условия, числа, ограничения. Затем реши пошагово". Если рассуждение уже идёт и видишь дрейф — вставь в диалог: "Стоп. Вернись к вопросу. Перечитай условия и продолжи". Почему работает: В длинных цепочках рассуждений внимание модели смещается к недавним токенам (промежуточным шагам). Ключевые данные из вопроса затухают. Пересказ создаёт свежий "якорь" — модель перечитывает исходные условия и перефокусирует внимание на них. Эффект виден в attention maps: внимание средних слоёв усиливается на начале рассуждения (где записан повтор вопроса). Когда работает: многошаговые задачи с числами, ограничениями, несколькими условиями (расчёты, стратегии, анализ вариантов). Улучшение точности до +10 пунктов. Когда НЕ работает: простые вопросы ("столица России?"), базовые модели без CoT-дообучения (они не понимают инструкцию "перескажи"), креативные задачи где нет строгих условий
Think²: структурированное само-исправление через три фазы мышления в одном промпте
4 концепта
82
Проблемы (2)
Модель замечает ошибку, но не может её исправить
Модель чувствует что что-то не так. Замечает в половине случаев. Но точно назвать причину ошибки — может только в 28% из них. Итог: попытки исправить себя работают лишь в 16% случаев. Это не проблема невнимательности. Это разрыв между "чувствую что не так" и "понимаю что именно не так". Встречается на любой сложной задаче с цепочкой шагов
Как обойти
Добавь в промпт явные контрольные точки. До решения — попроси предсказать форму ответа. В процессе — потребуй проверку каждого шага. После — потребуй сверку финала с началом. Модель следует явной структуре лучше, чем ищет ошибки сама
Линейная генерация не даёт вернуться назад
Модель пишет токен за токеном. Она не сравнивает конец с началом — если не заставить явно. Пишет вывод, который противоречит условию из начала промпта. И не замечает этого. Проблема нарастает с длиной ответа
Как обойти
В конце промпта добавь блок проверки: "Убедись что финальный ответ соответствует условиям из задачи и предсказаниям которые ты сделал в начале". Закрытие петли — явное требование, не умолчание
Методы (1)
Три фазы в одном промпте: план→контроль→сверка
Один промпт, три обязательных блока. Фаза 1 — Планирование: до решения выпиши тип задачи, известные факты, ограничения, предсказание формы ответа, типичные ошибки. Фаза 2 — Мониторинг: решай шаг за шагом, после каждого шага явно пиши ✓ Проверено или ⚠️ Риск: [причина]. Фаза 3 — Оценка: сверь финал с предсказанием из Фазы 1, проверь все ограничения, зафикcируй вывод. Почему работает: Планирование фиксирует ожидания до решения. Мониторинг превращает каждый переход в точку остановки. Оценка закрывает петлю — модель обязана сверить конец с началом. Без явной структуры — этого не происходит. Когда применять: сложная логика, анализ с противоречиями, многошаговые решения. Когда не применять: простые вопросы, творческие задачи, слабые модели — там структура даёт накладные расходы без пользы
Тезисы (1)
Структура формата ответа становится структурой мышления
Модель хорошо следует явным инструкциям внутри промпта. Если написано "проверь логику после каждого шага" — она проверит. Это можно использовать: форма ответа задаёт форму рассуждений. Чем точнее прописана структура — тем точнее контроль. Применяй: хочешь чтобы модель думала аккуратнее — не говори "думай тщательно", а пропиши явные блоки с маркерами проверки
Мультиверс-анализ: как получить честную оценку от LLM, запустив несколько аналитиков вместо одного
3 концепта
82
Проблемы (1)
Фрейминг запроса системно меняет вывод анализа
Просишь модель "найти риски" — получаешь один вывод. Просишь "найти возможности" — другой. Оба формально корректны. Оба методологически обоснованы. Но разница в выводах может достигать 66 процентных пунктов. Это не ошибка. Это структурное свойство. Один "канонический" ответ от модели не надёжен — он отражает твой фрейминг, а не реальность
Как обойти
Запусти тот же вопрос через несколько аналитических позиций параллельно. Скептик, нейтральный, оптимист. Смотри не на один ответ, а на распределение. Где все сходятся — надёжно. Где расходятся — реальная неопределённость
Методы (1)
Три аналитика в одном запросе — карта неопределённости
Раздели запрос на три роли: скептик (ищет слабые места), нейтральный (взвешивает без уклона), оптимист (ищет лучший сценарий). Каждый получает одинаковый контекст, но конкретную позицию и фокус. В конце — синтез: где все согласны → надёжный вывод. Где расходятся → зона неопределённости, требует данных. Почему работает: Роль в запросе активирует разные аналитические цепочки. Скептик выбирает консервативные методы. Оптимист упрощает. Расхождение показывает не чью-то ошибку, а реальную неоднозначность задачи. Когда применять: Важные решения, нужна честная оценка, есть риск предвзятости. Когда не работает: Нет проверяемых предположений, задача чисто субъективная. Важно: Для чистоты результата — новый чат без предыдущего контекста. Или три отдельных запроса
Тезисы (1)
Роль в запросе меняет методологию, а не только тон
Когда даёшь модели аналитическую роль, она выбирает разные операции с данными. Скептик учитывает больше переменных, применяет взвешенные методы, труднее принимает выводы. Оптимист убирает "аномальные" случаи, упрощает, быстрее делает вывод. Это не стиль — это разные аналитические решения. Применяй: описывай роль конкретно. Не "эксперт", а "венчурный аналитик с 10 годами отказов". Чем конкретнее роль — тем последовательнее методология
DBA (Disagreement-Based Abstention): детектор ненадёжных ответов через несогласие промптов
2 концепта
82
Проблемы (1)
Модель не различает свои знания от догадок
Спрашиваешь факт. Модель отвечает одинаково уверенно — и когда действительно знает, и когда импровизирует. Ответ выглядит точным: "Озон вышел на IPO в 2020" — но модель могла выдумать дату, потому что не запомнила настоящую. Проблема для любых фактических задач: даты, имена, характеристики объектов. Ты не можешь понять когда ответу можно доверять
Как обойти
Задай вопрос дважды разными способами: один раз прямо ("Когда Озон вышел на IPO?"), второй раз через разбивку на шаги ("Шаг 1: что такое Озон? Шаг 2: когда эта компания вышла на IPO?"). Сравни финальные ответы. Если одинаковые — ответ надёжный. Если разные — модель не знает, выдумывает
Методы (1)
Проверка надёжности через несогласие (DBA)
Запусти два запроса: (1) прямой вопрос "В каком году X сделал Y?", (2) тот же вопрос через декомпозицию "Шаг 1: что такое X? Шаг 2: что X делал? Шаг 3: когда это было?". Получи два финальных ответа. Сравни их сам или попроси модель. Если ответы совпадают — факт надёжный, модель действительно помнит. Если ответы разные — модель импровизирует, не доверяй. Почему работает: Декомпозиция меняет путь генерации. Настоящее знание стабильно — выдаст одинаковый факт при любой формулировке. Догадка хаотична — породит разные импровизации при разных путях. Когда применять: фактические вопросы (даты, места, имена), где нужна проверяемая точность. Не работает: креатив, мнения, простые очевидные факты (столица страны)
Purpose-Conditioned Cognition: как скрытие цели делает LLM честнее
2 концепта
82
Проблемы (1)
Модель подстраивает факты под раскрытую цель
Просишь оценить ситуацию и говоришь зачем нужна оценка ("чтобы принять решение о запуске", "для презентации инвесторам"). Модель видит цель как дополнительный сигнал. Начинает неосознанно усиливать те аспекты данных, которые поддерживают эту цель. Получаешь предвзятую оценку вместо нейтральной
Как обойти
Раздели задачи на два промпта. Шаг 1: собери факты без упоминания зачем они нужны ("оцени объективно"). Шаг 2: используй факты для решения ("вот оценка, теперь помоги решить"). Для чистоты начни новый чат — модель забудет контекст
Методы (1)
Сбор фактов без раскрытия цели
Шаг 1 (нейтральный): Попроси оценку, анализ или измерение БЕЗ упоминания как будешь использовать результат. Формулировка: "Оцени {объект} по {критерий}. Будь объективен". Шаг 2 (с целью): Возьми результат и попроси помочь с решением: "Вот оценка: {данные из шага 1}. Учитывая мою цель — {что хочешь} — что посоветуешь?". Почему работает: Цель в промпте — это сигнал для модели. Она использует его как любой контекст. Оптимизирует ответ под цель, подтягивая подходящие паттерны из обучающих данных. Убери сигнал — получишь нейтральный результат. Когда применять: нужна объективная оценка (анализ конкурентов, оценка рисков, проверка качества, сбор фактов). Когда не нужно: задача требует оптимизации под цель (написать убедительный текст, составить аргументы для переговоров)
Разблокируйте все концепты с PRO
Получите полный доступ ко всем все концепты и методам из научных исследований
