Тезисы

Генерация с нуля: модель ищет в пространстве всех возможных решений. Проверка: есть конкретный объект для анализа. Для LLM это значит: при генерации первая ошибка создаёт каскад (эгоцентризм). При проверке — можно найти противоречие и остановиться. Даже слабая модель хорошо критикует. Применяй: Для сложных задач не проси сразу "реши". Дай черновой ответ (свой или сгенерированный) и попроси проверить

Модель сильнее не гарантирует лучший результат. Даже если оппонент слабее и его аргументы не всегда верны — сам факт вызова заставляет пересмотреть позицию. Работает как внешний триггер: "а точно ли я прав?". Модель пересматривает логику, находит пробелы, которые не заметила в первый раз. Механика: Важен не качество критики, а её наличие. Структурированное несогласие включает режим проверки. Применяй: Не нужна вторая модель или сложный оппонент. Достаточно попросить ту же модель сыграть роль критика: "Теперь найди слабые места в этом ответе". Простая смена роли даёт эффект

LLM генерирует текст на основе паттернов из обучающих данных, не из явной базы знаний. Если паттерн сильный (модель видела факт много раз) — она даст одинаковый ответ на прямой вопрос и на переформулировку. Если паттерн слабый или отсутствует — модель додумает правдоподобную деталь, но при переспросе "забудет" что именно выдумала. Каждая генерация независима.

Применяй: Спроси модель про важный факт несколькими способами. Пример: сначала "Когда основан Яндекс?", потом "В каком году появился Яндекс?", потом "Год создания компании Яндекс?". Если ответы разные — высокий риск галлюцинации.

В few-shot промптах ты даёшь модели примеры: "вот задача → вот решение". Раньше считалось: главное — выбрать хорошие примеры, порядок вторичен. Оказалось нет. Один набор примеров в разном порядке даёт разброс точности ~2% — столько же, сколько при замене примеров на другие. Механика: Позиция примера в промпте влияет на его "вес" в механизме внимания. Примеры в начале и конце получают больше фокуса, средние — меньше. Применяй: Не останавливайся на выборе примеров. Протестируй 3-5 разных порядков на реальных задачах. Выбери лучший

Модель обучена на массиве данных, включая уязвимый код и документацию по безопасности. При прямой генерации она воспроизводит типичные паттерны — включая небезопасные. Но если явно попросить "найди проблемы" — переключается в режим анализа и применяет знания о безопасности. Почему: Генерация и критический анализ — разные режимы работы. Модель не смешивает их автоматически. Применяй: Для задач с проверяемым результатом (код, факты, расчёты) используй двухшаговый процесс: (1) "Напиши код", (2) "Проверь этот код на [конкретный список проблем], исправь". Указывай ЧТО искать — конкретный чеклист работает лучше абстрактного "проверь качество"

Без рассуждений модель "прыгает" от промпта к ответу. Синонимы и порядок слов меняют результат. С рассуждениями схема другая: промпт → цепочка шагов → ответ. Цепочка фиксирует логику задачи. Ответ строится из цепочки, а не из промпта. Поэтому конкретные слова в промпте перестают сильно влиять. Разница: основной прирост даёт переход к рассуждениям, дальнейшая оптимизация формулировок даёт минимум. Применяй: Не трать время на подбор "идеальной" формулировки. Добавь "рассуждай пошагово" — этого достаточно

Когда модель получает микс полезного и мусора, итоговый ответ хуже чем вообще без документов. Точность падает на 6%, полнота на 5%. Причина: модель не умеет игнорировать шум — воспринимает всё в контексте как "подсказки". Нерелевантные куски перебивают внутренние знания. Применяй: Лучше дать меньше контекста (только проверенное), чем больше (со всем подряд). В промпте: "Если фрагмент не подходит — не используй его, даже если он в контексте"

Когда задаёшь JSON-схему с обязательными полями, модель не может "перепрыгнуть" через шаги. Чтобы заполнить final_judgment, модель должна сначала заполнить evidence_for, evidence_against, reasoning. Это работает как жёсткий вариант цепочки рассуждений. Механика: структура создаёт последовательность — каждое следующее поле зависит от предыдущих. Применяй: Для сложных задач используй JSON с явной последовательностью: сначала факты, потом анализ, потом вывод

Когда добавляешь в контекст примеры "как не надо", модель понимает границы. Но случайный плохой пример ("иди в жопу, клиент") не учит — модель и так знает, что это плохо. Похожий неправильный пример ("нам очень жаль, пожалуйста не обижайтесь") — выглядит правдоподобно, но нарушает критерий (заискивающий тон). Модель учится ловить тонкую разницу. Механика: Контраст создаёт якоря — вот граница "слишком мягко", вот "слишком сухо", между ними правильная зона. Без якорей модель стреляет вслепую. Применяй: Для задач с нюансами (тон текста, стиль, выбор между похожими вариантами) добавляй в few-shot не просто "делай так", а "делай так, НЕ делай вот так (похоже, но не то)". Генерируй похожие негативы через LLM: "создай вариант, который выглядит правильно, но нарушает критерий X"

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

Когда модель должна записать "Интерпретация 1: ..., Интерпретация 2: ..." — вынуждена артикулировать то что иначе осталось бы внутри. Формат превращает внутреннее рассуждение во внешний вывод. Связь "интерпретация → ответ" становится прозрачной для пользователя и самой модели. Применяй: Для критичных запросов требуй структурированный вывод с явным разделением вариантов. Шаблон: "1. [Вариант А] Ответ: ... 2. [Вариант Б] Ответ: ..."

Показать модели все 50 попыток = перегрузка. Показать только последние 5 = потеря ранних инсайтов. Выборка "лучшие + худшие + недавние" даёт баланс: модель видит что работает (топ), чего избегать (провалы), что пробовали недавно (свежесть). Размер выборки — рычаг: увеличь лучших для фокуса на успехе, увеличь худших чтобы учиться на ошибках, увеличь недавних для разнообразия. Применяй: Вместо "вот вся история на 5000 токенов" делай Топ-3 (скор 8-9): [варианты]. Худшие-2 (скор 2-3): [варианты]. Последние-2: [варианты]

Когда модель делает всё в одном потоке (думает + проверяет + действует), правила из начала промпта забываются к моменту действия. Отдельная фаза "проверка правил" перед каждым действием возвращает фокус на ограничения. В экспериментах это дало ноль нарушений там, где слитный промпт давал 15-25% ошибок. Применяй: Для задач с условиями добавь явный шаг: "Проверь: соблюдены ли все правила? Если нет — вернись к рассуждению"

Механизм: LLM обучена на текстах где стилистика коррелирует с контекстом. Разговорный тон в обучающих данных чаще встречался в субъективных текстах. Формальный язык — в осторожных анализах. Модель усвоила паттерн и воспроизводит его. Это alignment by mimicry — модель мимикрирует под предполагаемые ожидания автора запроса. Применяй: Для нейтральных выводов убирай эмоциональные маркеры и диалект из промпта. Для креатива наоборот — добавляй стилистику чтобы задать направление

Когда задаёшь строгую JSON-схему, модель тратит часть "внимания" на соблюдение формата. На простых задачах (извлечь имена, даты, факты) это не мешает — структура даже помогает. На сложных задачах требующих многошаговых рассуждений (планирование, анализ, выводы) жёсткий формат забирает ресурсы у самого рассуждения. Модель думает "как правильно заполнить поля" вместо "как решить задачу глубже". Применяй: Для извлечения данных используй строгую схему. Для задач требующих глубокого анализа сначала попроси подумать свободно, потом структурируй результат отдельным запросом. Или упрости схему до минимума

LLM отлично решает задачу "вот утверждение А, вот данные Б — соответствуют ли они друг другу". Это классификация. Но плохо справляется с задачей "найди информацию чтобы проверить А". Это поиск + отбор релевантности. Даже с web search модель часто пропускает нужные источники или находит, но криво интерпретирует. Разница в точности: без готового контекста ~20%, с готовым ~92%. Причина: сопоставление = работа с уже структурированными данными, поиск = неструктурированная среда где модель теряется. Применяй: Не пиши "проверь утверждение X". Сам найди 2-3 релевантных источника с конкретными цифрами, дай модели, попроси сопоставить и вынести вердикт. Формат: "Утверждение: {X}. Данные: {источник 1}, {источник 2}. Соответствует ли утверждение данным?"