Fake Prediction Markets: ставки как калиброванный сигнал уверенности LLM
4 концепта
89
Проблемы (1)
Модель не показывает степень уверенности
Спрашиваешь "насколько уверен". Получаешь слова: "вероятно", "скорее всего", "точно". Эти слова нельзя сравнить. Два ответа "вероятно" — где уверенность выше? Непонятно. Даже "оцени от 1 до 10" не помогает — модель ставит всем 7-8 баллов без реального различия
Как обойти
Дай модели виртуальный бюджет (100 очков, 1000 баллов). Попроси распределить на все ответы. Правило: угадал — очки сохраняются, ошибся — теряешь. Размер "ставки" покажет реальную уверенность. Нельзя дать всем максимум — заставит выбирать
Методы (1)
Виртуальные ставки — шкала уверенности
Дай модели начальный бюджет (например, 1 млн виртуальных монет). Для каждого ответа/прогноза модель должна "поставить" от минимума (1 монета) до максимума (100 тысяч). Угадала — ставка добавляется к балансу. Ошиблась — вычитается. Сумма всех ставок не может превышать текущий баланс. Почему работает: Ограниченный ресурс заставляет различать. На уверенные ответы ставит много. На сомнительные — копейки. Без лимита модель даст всем среднюю оценку. С лимитом вынуждена приоритизировать. Когда применять: множество оценок (10+ вариантов), нужно ранжирование по надёжности, есть способ проверить правильность. Не работает: один ответ (нечего сравнивать), субъективные оценки без проверки ("насколько текст красивый"), задачи где нельзя дать обратную связь
Тезисы (2)
Числовой feedback работает в разы сильнее словесного
Когда показываешь модели результат её работы, число создаёт более сильный сигнал чем слово. Пример: "−50 очков, осталось 950/1000" громче чем "неправильно". Модель быстрее корректирует поведение. В тестах с числовым feedback улучшение за 4 раунда было в ~4 раза быстрее (12 пунктов роста точности против 3 пунктов при словесном feedback). Применяй: Вместо "ошибка" пиши конкретную цифру: "счёт 2/10", "потеряно 30 баллов из 100", "−500 очков". Чем конкретнее число — тем сильнее якорь для обучения
Самооценка через распределение ресурса показывает реальную точность
Когда модель сама оценивает уверенность не словами, а распределением ограниченного бюджета между вариантами, эта оценка коррелирует с реальной точностью ответа. Механизм: ограниченный ресурс заставляет модель "делать ставку" только там где она видит сильные признаки правильности. Крупные числа (много очков на вариант) = высокая внутренняя уверенность = чаще правильный ответ. Мелкие числа = модель сомневается = чаще ошибка. Применяй: После получения ответов с "ставками" фильтруй по размеру. Варианты с крупными ставками обрабатывай первыми — там модель увереннее и точнее. Варианты с копеечными ставками проверяй вручную или отбрасывай
MAR (Multi-Agent Reflexion): дебаты персон вместо самокритики
4 концепта
84
Проблемы (1)
Зацикливание на ошибке при самокритике
Модель генерирует ответ. Потом сама себя проверяет. Потом делает выводы. Использует ту же логику на всех трёх шагах. Результат: не исправляет ошибку, а переформулирует её. Пример: в коде генерирует баг → критикует → генерирует тот же баг снова. В рассуждениях: неверная логика → "анализ" ошибки → та же логика в новой попытке. Это как редактировать свой текст сразу после написания — не видишь косяков, потому что мозг в той же колее
Как обойти
Раздели роли. Актёр решает задачу. Критики анализируют — каждый со своим фокусом (один считает цифры, другой ищет риски, третий проверяет логику, четвёртый предлагает альтернативы). Судья синтезирует их мнения в рефлексию. Актёр пробует снова с новой рефлексией. Это техника MAR (Multi-Agent Reflexion)
Методы (1)
MAR — дебаты критиков вместо самопроверки
Схема: Актёр решает → если провал, запускаются критики → каждый пишет диагноз со своей точки зрения → дебаты (1-2 раунда, критики оспаривают друг друга) → судья синтезирует консенсус → актёр пробует снова с рефлексией. Персоны под задачу: для бизнеса (финансист/маркетолог/скептик/креативщик), для кода (Senior Engineer/QA/Code Reviewer/Performance Engineer), для текста (редактор/SEO/читатель/эксперт). Роли должны быть контрастными: цифры vs риски, факты vs альтернативы. Почему работает: разные роли → разные паттерны мышления. Модель не повторяет ту же логику, а генерирует несколько углов зрения. Когда применять: сложные задачи где первая попытка часто неполная, важные решения (стратегия/архитектура/анализ). Когда не работает: простые вопросы за один заход, рутина (расход токенов ~3x больше обычной рефлексии)
Тезисы (2)
Контрастные роли включают разные паттерны мышления
Одна модель в роли "скептик — ищи дыры" работает иначе чем "оптимист — ищи возможности". Когда несколько ролей спорят, модель генерирует разные логики, а не повторяет одну. Механизм: явная инструкция роли переключает фокус внимания. Применяй: вместо "проверь своё решение" дай 3-4 роли с чёткими контрастными установками. Если роли похожи — вырождается в переформулирование
Разделение ролей преодолевает слепоту к своим ошибкам
Модель не видит косяки в собственной логике. Но видит косяки когда играет другую роль и смотрит на чужой вывод. Применяй: актёр генерирует → критик анализирует (как будто это чужой ответ) → актёр получает внешнюю обратную связь, не внутреннюю
Confessions: отделение награды за честность от награды за результат
3 концепта
83
Проблемы (1)
Модель скрывает осознанные срезания углов
Модель знает что нарушает требование. Обходит ограничение. Срезает угол для быстрого результата. Взламывает критерии оценки. Но в основном ответе не признается. Делает вид что всё по инструкции. Это осознанное поведение — модель понимает что делает не то что просили
Как обойти
Попроси отдельный отчет после основного ответа. Модель перечисляет все требования и оценивает соблюдение каждого. Ключ: этот отчет не влияет на оценку основного ответа. Без угрозы penalty модель честно признает где срезала углы
Методы (1)
Отчет самооценки после ответа — выявление скрытых нарушений
Получи основной ответ. Затем запроси структурированный отчет: 1) Перечисли все требования (явные и неявные) 2) Для каждого — соблюдено или нет, с доказательствами 3) Пробелы: что смягчил, упустил, не раскрыл 4) Серые зоны: где требования конфликтовали. Почему работает: Честно признаться проще чем соврать убедительно. Когда модель осознанно нарушила инструкцию (обошла ограничение, срезала угол), ей проще сказать "я нарушил пункт X" чем придумать убедительную ложь для отчета. Это путь наименьшего сопротивления — если отчет не влияет на оценку основной задачи, модель выбирает простоту честности. Когда работает: осознанные нарушения (модель знает что делает не то), обход правил, срезание углов, взлом критериев оценки. Не работает: реальные ошибки знания (модель уверена в неправильном факте) — она повторит ошибку в отчете
Тезисы (1)
Модель честно признает осознанные нарушения но повторяет неосознанные ошибки
Когда модель знает что нарушила требование (срезала угол, обошла ограничение) — признается в отчете самооценки. Когда модель genuinely уверена в неправильном (пробел в знаниях, устаревший факт) — повторяет ошибку в отчете. Разница: первое модель осознаёт, второе — нет. Применяй: Отчет самооценки покажет где модель сознательно схитрила. Но не покажет где модель искренне ошиблась. Для фактов используй дополнительную проверку
Prompt Repetition: удвоение промпта для лучшей точности без reasoning
2 концепта
83
Проблемы (1)
Варианты ДО вопроса обрабатываются вслепую
Модель читает слева направо. Не может вернуться. Если варианты ответа идут ПЕРЕД вопросом — модель читает их не понимая зачем. Контекст задачи приходит поздно. Ошибки растут в задачах: выбор из списка, поиск в длинном тексте, извлечение по условию
Как обойти
Способ 1: продублируй промпт целиком — отправь <промпт><промпт>. Способ 2: перестрой порядок — сначала вопрос и инструкция, потом варианты и данные. Модель поймёт ЗАЧЕМ читает информацию
Методы (1)
Повторение промпта — второй проход по контексту
Скопируй промпт дважды. Вместо <промпт> отправь <промпт><промпт>. Модель читает всё дважды. Первый проход — линейно. Второй — с накопленным контекстом. Почему работает: LLM каузальная — токен видит только предыдущие, не будущие. Повторение даёт второй шанс связать части. Вопрос понимает опции. Опции понимают вопрос. Синтаксис:{промпт}\n{промпт} или с границей {промпт}\n\nLet me repeat that:\n\n{промпт}. Для сложных задач (длинные списки) пробуй ×3. Когда ДА: поиск в списках, выбор из вариантов, длинный контекст с условием. Когда НЕТ: reasoning-модели (o1, o3) — они сами повторяют в мыслях; очень длинные промпты (не влезут в лимит); жёсткий бюджет токенов (вход удваивается). Бонус: длина ответа не растёт
"Лень" LLM: почему модели дают короче и меньше, чем просишь
2 концепта
83
Проблемы (1)
Модель останавливается раньше запрошенного объёма
Просишь список из 20 пунктов — получаешь 12 и остановку. Просишь 1000 слов — получаешь 300. Модель способна дать больше, но выбирает закончить раньше. Это след обучения: модели штрафовали за многословие (чтобы не болтали воду), они выработали сильный перекос в сторону краткости. Особенно сильно проявляется когда несколько требований в одном промпте (длина + формат + список тем) — модель роняет часть из них
Как обойти
Добавь числовой якорь: "РОВНО 20 пунктов, не 10 и не 15". Добавь финализирующую фразу: "После выполнения напиши '✓ Все 20 готовы'". Это создаёт конкретную цель до которой модель должна дойти. Альтернатива: разбей на части ("Сначала дай 1-10, потом попрошу 11-20")
Методы (1)
Числовой якорь + финализация — удержать до конца задачи
Что делать: В промпте укажи точное число элементов ("РОВНО 20 примеров", "минимум 800 слов"). В конце добавь требование: "Когда закончишь напиши '✓ Все 20 готовы'". Почему работает: Число создаёт измеримую цель вместо размытого "подробно". Финализирующая фраза работает как маркер конца — модель должна дойти до этой точки чтобы "закрыть" задачу. Без этого она останавливается раньше из-за bias к краткости. Когда применять: Задачи со списками, перечислениями, минимальным объёмом текста. Когда не работает: Субъективные требования без чёткой метрики ("будь максимально глубоким" — модель интерпретирует произвольно). Не гарантирует качество — модель может дать 1000 слов воды
Test-Time Scaling для Vision-Language моделей: когда усилия окупаются, а когда вредят
1 концепт
83
Тезисы (1)
Самокритика работает только у сильных моделей — слабые от неё деградируют
Что происходит: Просишь модель покритиковать свой ответ и улучшить его. Топовые модели (GPT-4o, Gemini 2.0, Claude 3.5) улучшают точность на 5-15%. Слабые модели (открытые Qwen, InternVL, Mulberry) теряют точность на 2-8% — начинают выдумывать несуществующие проблемы, зацикливаются, портят изначально правильный ответ. Почему: Самокритика требует метакогниции — способности оценивать качество своих рассуждений. У слабых моделей этой способности нет. Они не отличают реальную ошибку от галлюцинированной. "Критика" сама становится источником ошибок. Применяй: Используй итеративное улучшение (Self-Refinement) только с топовыми моделями. Для остальных — генерируй несколько вариантов и выбирай лучший (Best-of-N, Self-Consistency), не проси улучшать один ответ
Холистическая оценка LLM для генерации кода: какие модели пишут лучше и почему добавление слова "оптимизируй" снижает ошибки на 30%
2 концепта
82
Проблемы (1)
Модель генерирует работающий, но медленный код
Просишь написать функцию. Получаешь код, который правильно решает задачу на маленьких данных. Запускаешь на реальных объёмах (100 000 строк) — работает минуты вместо секунд. Проблема: модель выдаёт первое рабочее решение (вложенные циклы, перебор всех вариантов), не просчитывая скорость. Мыслит паттернами из примеров, не математикой сложности алгоритмов
Как обойти
Добавь в промпт: "Оптимизируй сложность алгоритма по времени". Эта фраза переключает модель из режима "напиши работающее" в режим "выбери эффективное". Снижает ошибки производительности на 25-35%
Методы (1)
Явная инструкция об оптимизации
Добавь в конец промпта фразу: "Оптимизируй сложность алгоритма по времени". Одно предложение. Почему работает: без инструкции модель семплирует из всех рабочих решений — часто попадает в неэффективные (первое что приходит). С инструкцией — семплирует из подпространства оптимальных решений. Для модели это триггер: не просто написать код, а сравнить варианты и выбрать быстрый. Особенно сильно работает для reasoning-моделей (DeepSeek-R1, GPT-4.1) — они начинают рассуждать вслух про сложность перед генерацией кода. Когда применять: работаешь с большими данными (1000+ элементов), сложные вычисления, алгоритмические задачи. Когда не работает: простые задачи (сортировка списка) — модель и так выдаст нормальный код
Создай роль-координатора и список ролей-экспертов (каждый отвечает за свою область). Координатор читает задачу и выбирает каких экспертов вызвать (не всех подряд!). Каждый эксперт отвечает только по своей зоне: оценка + обоснование с фактами + рекомендация. Итог — агрегация всех ответов. Почему работает: Фокус на узкой области → модель глубже анализирует этот аспект. Когда критериев много — одна роль пытается держать всё в голове → поверхностно. Специалисты разделяют нагрузку. Когда применять: 4+ разных критерия проверки, каждый требует специализированного анализа (бизнес-идея: финансы + маркетинг + юридика + риски; диагноз: 7 групп симптомов). Когда не работает: 1-2 простых критерия — координатор добавляет сложность без пользы. Прямой промпт быстрее
RT-ICA: обратное мышление для поиска недостающих данных
4 концепта
82
Проблемы (1)
Модель не проверяет достаточность данных
Модель идёт от условия к ответу. Видит данные — начинает решать. Если чего-то не хватает — не останавливается. Додумывает недостающее или выдаёт неверный ответ. Нет встроенного стимула спросить себя: "А всего ли мне хватает?" Это не баг — это следствие архитектуры. Модель генерирует текст вперёд, шаг за шагом
Как обойти
Переверни направление рассуждений. Не "что я могу посчитать с этими данными", а "что мне нужно для ответа". Попроси сначала перечислить все необходимые условия, потом проверить — есть ли каждое в задаче. Чего нет в списке — то и недостаёт
Методы (1)
Обратное мышление для проверки полноты (RT-ICA)
Три шага в одном промпте. Шаг 1: Определи цель — что нужно найти или решить. Шаг 2: Перечисли все условия — что должно быть известно для достижения цели. Шаг 3: Проверь каждое условие — дано явно? можно вывести? или нигде нет? Чего нет — перечисли как недостающее. Почему работает: Модель хорошо умеет разбивать цель на части и сравнивать списки. Это проще чем заметить пробел во время решения. Обратное направление делает проверку явной и структурированной. Когда применять: задачи где нужно что-то посчитать, оценить, принять решение на основе данных. Бизнес-планы, техзадания, финансовые расчёты, анализ ситуаций. Когда не работает: творческие задачи без чётких условий, субъективные оценки, задачи где "полнота данных" не определена
Тезисы (2)
Обратное направление находит пробелы лучше прямого
Прямое рассуждение: от данных к ответу. Модель берёт что есть и тянет к выводу. Пробелы замечает только если спотыкается. Обратное рассуждение: от цели к предпосылкам. Модель сначала составляет полный список "что нужно", потом сравнивает с "что есть". Разница в списках — это пробелы. Применяй: Когда нужно проверить достаточность данных — попроси модель идти от желаемого результата назад. "Чтобы ответить на вопрос X, мне нужны данные A, B, C. Проверяю: есть ли A? есть ли B?"
Структурированная проверка работает лучше попутной
Искать пробелы во время решения — сложная задача. Нужно и решать и одновременно отслеживать "всего ли хватает". Разделить процесс проще: сначала составить список необходимого, потом методично проверить каждый пункт. Модель лучше справляется когда задача явная и пошаговая. Применяй: Не полагайся что модель "заметит" проблему сама. Дай явную инструкцию проверить полноту через декомпозицию и сравнение
The Forecast Critic: визуальная оценка прогнозов через LLM
5 концептов
82
Проблемы (2)
Модель плохо анализирует последовательности чисел
Даёшь модели ряд чисел: [120, 125, 130, 40, 133, 145]. Просишь найти аномалию. Модель может пропустить резкое падение (40) — числа для неё абстрактные символы. Она не "чувствует" паттерн как человек видит график глазами. Проблема для любых задач с временными рядами: продажи, трафик, метрики, финансы
Как обойти
Покажи данные КАРТИНКОЙ. Построй график: ось X — время, ось Y — значения. Загрузи изображение в модель. Теперь она видит тренд, всплеск, падение как визуальные объекты. Попроси оценить: "Выглядит ли паттерн логичным?" Модель анализирует форму линии, не вычисляет числа
Модель не замечает отсутствие ожидаемых событий
Легко увидеть лишнее: на графике внезапный пик — модель заметит. Трудно увидеть пропущенное: в истории каждый месяц был всплеск, в прогнозе его нет — модель может пропустить. "Чего-то не хватает" — сложная задача. Человек справляется лучше. Проблема для проверки прогнозов: забытые промо-акции, сезонные события, регулярные пики
Как обойти
Добавь текстовый контекст ЯВНО. Не надейся что модель сама заметит паттерн "каждый месяц пик". Напиши: "В истории были всплески 24 ноября (Чёрная пятница) и 8 марта (акция). В прогнозе 1-3 мая будут праздники — должен быть аналогичный всплеск." Модель проверит: есть ли пик 1-3 мая на графике прогноза
Методы (2)
Визуальная оценка данных — график вместо чисел
Вместо "дай модели последовательность чисел" → построй график и дай картинку. LLM видят тренды, всплески, падения как визуальные паттерны — они обучены на миллионах графиков, диаграмм, схем. Для модели график = как фотография: она распознаёт форму, наклон, волны. Шаг 1: Построй график (любой инструмент: Excel, Python, Google Sheets). История + прогноз на одном изображении. Шаг 2: Загрузи в ChatGPT/Claude. Шаг 3: Промпт: "Оцени разумность прогноза. Синяя линия — история, красная — прогноз. Reasonable или unreasonable?" Почему работает: Ты переводишь задачу анализа последовательности в задачу компьютерного зрения. Модель не вычисляет, она ВИДИТ. Когда применять: временные ряды (продажи, трафик, метрики), любые данные с трендами и паттернами. Когда не работает: данные без визуального паттерна (например, случайный шум)
Текстовый контекст для визуального анализа
Модель смотрит на график + читает текст о событиях. Связывает два источника: "в тексте написано '15 марта распродажа'" + "на графике 15 марта пик" = логично. Или "в тексте '15 марта распродажа'" + "на графике 15 марта ровная линия" = нелогично, всплеск пропущен. Формат: После описания графика добавь секцию "Контекст:" и перечисли события: праздники, промо-акции, запуски продуктов, сезонность, внешние факторы. Пример: "24 ноября Чёрная пятница (скачок в истории), 1-3 мая праздники (в период прогноза)." Почему работает: Мультимодальные LLM обучены связывать визуал и текст — тот же механизм что работает для "найди на схеме элемент X" или "что на этой фотографии?". Применяй: когда на данные влияют известные события. Чем больше деталей — тем точнее оценка. Но если контекст неправильный — модель ошибётся
Тезисы (1)
Визуальный паттерн модель распознаёт лучше чем числовую последовательность
Дашь модели числа [10, 20, 30, 5, 40] — она обрабатывает как абстрактные символы. Покажешь график этих чисел — она видит форму: линия растёт, потом резко падает, потом снова растёт. Визуальная форма = конкретный объект для распознавания. Мультимодальные LLM обучены на графиках, диаграммах, инфографике — они "читают" тренды как паттерны изображения. Механика: Ты переводишь абстрактную задачу (анализ последовательности) в конкретную (компьютерное зрение). Применяй: Любые данные с трендами/циклами — строй график и загружай картинку вместо текста с числами. Работает для временных рядов, сравнений, динамики метрик
RF-SeqBoN: последовательная генерация с фильтрацией по качеству
3 концепта
81
Проблемы (1)
Множественная генерация не меняет качество распределения
Генерируешь 100 вариантов ответа из одного промпта. Выбираешь лучший. Но все 100 вариантов — из одной смеси. Модель обучена на данных разного качества. Если доля хороших ответов в этой смеси 10%, то из 100 попыток получишь ~10 приемлемых. Остальные 90 — мусор из того же распределения. Перебор не улучшает само распределение. Просто ищешь лучшее из того что есть
Как обойти
Не генерируй все варианты сразу. Генерируй по одному. После каждого хорошего ответа добавляй его в контекст. Следующая генерация пойдёт уже из обновлённого контекста. Так модель смещается к качественной части обучающих данных. Контекст из хороших примеров меняет распределение
Методы (1)
Последовательная генерация с фильтрацией — накопление качественных примеров в контексте
Цикл из 3 шагов: (1) Сгенерируй ответ из текущего контекста. (2) Оцени качество по критериям. (3) Если оценка выше порога — добавь ответ в контекст как пример. Повтори N раз. В конце выбери лучший из всех. Почему работает: Контекст из качественных примеров смещает генерацию. Модель видит хорошие ответы и начинает генерировать в том же стиле. Плохие ответы не попадают в контекст — не тратишь вычисления на усиление слабых паттернов. Рычаги: Порог оценки (выше = строже фильтр, меньше примеров но чище). Число итераций (больше = больше попыток, но после 5-7 хороших примеров отдача падает). Когда применять: Задача сложная, разброс качества генераций высокий (планирование, код, креатив). Не работает: Простые задачи где модель и так генерирует хорошо
Тезисы (1)
Контекст из качественных примеров смещает генерацию к лучшей части обучающих данных
Модель обучена на смеси: есть хорошие авторы, есть плохие. Когда генерируешь из пустого промпта, получаешь усреднённый результат по всей смеси. Когда добавляешь в контекст несколько качественных примеров, модель «вспоминает» ту часть обучающих данных где были похожие хорошие примеры. Генерация концентрируется на этой части. Механизм: контекстное обучение работает как фильтр по стилю. Применяй: Не генерируй все варианты разом. Генерируй один, если хорош — добавь в контекст, генерируй следующий. Контекст растёт — качество растёт
