или Парадокс Пирамиды: Почему мега-LLM обречены на «лунатизм»
Эффект бабочки, преждевременное якорение и контекстное тяготение: почему масштабирование не устраняет поведенческую нестабильность LLM
Иллюзия калькулятора
Знаете, что самое раздражающее в работе с ИИ?
Не то, что он ошибается. Ошибаться — нормально. Не то, что он каждый раз отвечает чуть по-разному. Это тоже нормально — LLM вероятностна по определению, и лёгкая вариативность ответа это не баг, а архитектура.
Самое раздражающее — это аномалии поведения.
Вы запускаете сессию. ИИ работает блестяще: ловит ваши ошибки, говорит «нет, это не сработает, вот почему», предлагает решения, которые вы не видели. Вы довольны. Вы думаете: «ИИ наконец-то стал полезным».
Вы запускаете следующую сессию. Тот же промпт. Та же модель. Те же правила. Но что-то идёт не по плану и ИИ отвечает как стажёр после корпоратива: «забывает» базовые инструкции, которые знал пять минут назад, тупит и несёт какую-то околесицу. Начинает лениться. Делегирует вместо решения...
Промпт не менялся. Модель не обновлялась. И вы сидите и думаете: «Что произошло? Я что-то сделал не так?»
Нет. Вы не сделали ничего не так.
Или вот другой сценарий, который узнает каждый, кто работал с ИИ-агентом над кодом. У вас есть отлаженный, рабочий модуль. Вам нужно поменять одно значение. Вы просите ИИ: «поменяй константу X на Y». А ИИ вместо этого переписывает весь модуль заново — и ломает то, что работало. Вы смотрите на diff и видите: половина файла изменена, функции переименованы, логика перестроена. Одно значение? Нет, полного рефакторинга на свою голову. И теперь надо откатывать. Потому что ИИ вдруг решил, что он художник — он так видит!
Почему? Потому что модель «увидела» задачу по-другому. Первый токен её ответа пошёл не в ту сторону — и всё, понеслось. Это не вредность. Это не глупость. Это математика.
Дело в том, как мы думаем об LLM. Мы относимся к ним как к калькулятору: ввёл 2+2, получил 4. Ввёл тот же промпт — получил тот же ответ. Логично? Нет. Потому что LLM — это не калькулятор. Это вероятностная пирамида из миллиардов параметров, где каждый слой — бросок кости с подтасованными, но не фиксированными результатами.
Текстовый промпт — это ведро воды, вылитое на вершину этой пирамиды из песчаника. Поток проходит через миллиарды параметров, и траектория этого потока — абсолютно непредсказуема. Вариативность — норма. Но когда поток внезапно срывается в поведенческую аномалию — модель «забывает» кто она, ленится, угождает вместо того чтобы решать, переписывает рабочий код вместо точечной правки — это уже не вариативность. Это симптом.
И вот что по-настоящему важно: корпорации об этом молчат. Ни OpenAI, ни Anthropic, ни Google не расскажут вам в маркетинговом блоге, что их модель может внезапно «заболеть» посреди сессии. Это антиреклама. Это экономические издержки. Но это реальность, с которой живёт каждый пользователь.
Звучит как метафора? Это не метафора. Это математика. И у неё есть научные доказательства.
Глава 1: Эффект Бабочки, или Почему промпт — это бросок кубика
Начнём с фундамента. Вариативность ответа — это норма. Но масштаб этой вариативности — то, что вас удивит.
Вы думаете, что если зафиксируете seed=42 и temperature=0, то получите одинаковый результат каждый раз? В локальной инференции — возможно. В облаке — нет. И это не баг конкретного провайдера, это архитектурная реальность.
Исследование Berk Atil и коллег из Comcast AI Technologies и Penn State University (arXiv:2408.04667) зафиксировало это системно. Пять LLM, «детерминированный» режим (seed зафиксирован, temperature=0), 8 задач, 10 прогонов каждый:
- Разброс точности между прогонами — до 15%
- Разрыв между лучшим и худшим прогоном — до 70%
- Ни одна модель не выдала идентичный результат во всех прогонах
Причина — не магия. Когда вы отправляете запрос в облако, он попадает в общий буфер с запросами других пользователей (dynamic batching). Порядок смешивания данных в буфере влияет на вычисления с плавающей запятой на GPU. А вычисления с плавающей запятой не ассоциативны: (A + B) + C ≠ A + (B + C) на уровне битов. Малейшее изменение порядка — и результат матричного умножения чуть-чуть другой. А «чуть-чуть» на одном слое превращается в лавину к концу пирамиды, вода бежит по пирамиде, которая ещё и хаотически вращается.
Как пишут авторы: «non-determinism is perhaps essential to the efficient use of compute resources via co-mingled data in input buffers, so this issue is not going away anytime soon». Перевод: это не баг, это плата за эффективность. И она не уйдёт.
Но это — технический рандом, и он нормален. Облачный инференс — это всегда бросок кубика. Проблема начинается дальше.
В работе «The Butterfly Effect of Altering Prompts» (Findings of ACL, arXiv:2401.03729) Абель Салинас и Фред Морстаттер доказали: малейшее изменение на входе — лишний пробел, синоним, перестановка слов — меняет логическую траекторию модели с частотой (flip-rate) от 5% до 90%.
5% — это «ну, бывает». 90% — это «две разные вселенные».
И вот что по-настоящему обидно: вам даже не нужно менять смысл промпта. Исследование Li Xiao и коллег из ICML 2025 Workshop (arXiv:2506.10095) показало, что семантически идентичные промпты — один и тот же смысл, но другими словами — дают model-specific дрейф. То есть вы перефразировали запрос, не изменив ни капли смысла, а модель повела себя по-другому. Потому что токенизация другая. Потому что путь через пирамиду другой — «рука дрогнула, когда проливала воду».
Параметр seed — единственный рабочий якорь, который даёт иллюзию контроля. В генерации изображений он позволяет повторять одну и ту же картинку. Но якорь ржавый: на облачных API он не гарантирует ничего. Кто не сталкивался с тем, что на очередной итерации одного и того же рендера у вас на картинке внезапно не появилось аномалии!
Итог: рандом на старте — это норма архитектуры. Но когда этот рандом превращается в поведенческую аномалию — модель была адекватной, а внезапно стала ленивой или амнезической — это уже не «вариативность ответа». Это симптом. И сейчас мы посмотрим, как он развивается.
Глава 2: Контекстный токсикоз, или Сессия крашится на первом шаге
Если первая глава — про рандом на старте, то вторая — про то, как идеально начатая сессия медленно отравляется.
Вы запустили агента. Он работает. Делает задачи. Пять, десять, пятнадцать шагов. А потом — где-то на двадцатом шаге — он начинает... странно себя вести. Не ловит очевидные ошибки. Делегирует задачу вместо решения. Пишет // TODO: implement вместо кода. Соглашается с вашим плохим предложением вместо того чтобы сказать «нет, это не сработает».
Знакомо?
Вы думаете: «сломался на двадцатом шаге». Но вот что доказала наука — и это переворачивает понимание проблемы.
Исследование Philippe Laban и коллег «LLMs Get Lost In Multi-Turn Conversation» (arXiv:2505.06120), проанализировав 200,000+ симулированных диалогов, зафиксировало: в длинных многораундовых диалогах надёжность LLM падает в среднем на 39%. Тридцать девять процентов. Треть.
Но главное — не цифра. Главное — почему. Авторы пишут:
«We find that LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely. In simpler terms, we discover that when LLMs take a wrong turn in a conversation, they get lost and do not recover».
«When LLMs take a wrong turn, they get lost and do not recover.»
Модель делает предположение в первых шагах — и если это предположение оказалось с микро-аномалией, она якорится на нём. Потому что модель видит свой собственный прошлый ответ как часть контекста. Он для неё — факт. И от этого «факта» она отталкивается дальше. Ошибка становится фундаментом. Фундамент кривой — здание кривое.
Два других исследования подтверждают это на уровне механизма.
Baohao Liao и коллеги в работе «Lost at the Beginning of Reasoning» (arXiv:2506.22058) доказали: первый шаг рассуждения имеет непропорционально большое влияние на финальный результат. Ошибка на старте деградирует всю цепочку. Это наблюдается на всех state-of-the-art моделях — открытых и закрытых. Название статьи говорит само за себя: «Lost at the Beginning» — модель теряется в самом начале.
А Yun Cheng и коллеги в работе «Contextual Drag: How Errors in the Context Affect LLM Reasoning» (arXiv:2602.04288) описали механизм ещё жёстче. Они назвали его contextual drag — «контекстное тяготение». Суть: присутствие ошибочной попытки в контексте смещает следующие генерации к структурно похожим ошибкам. Не просто «модель ошиблась» — модель начинает повторять структуру ошибки. Каскад. На 11 моделях, 8 задачах — падение на 10-20%. И самое жёсткое: «neither external feedback nor successful self-verification suffices to eliminate this effect». Ни внешняя обратная связь, ни самопроверка не устраняют это полностью.
Вот вам и «стажёр после корпоратива». Он не «забыл» правила на двадцатом шаге. Он сделал микро-ошибку на первом — и понеслось. Ошибка → модель видит ошибку как факт → следующий ответ дрейфует к структурно похожей ошибке → каскад → амнезия правил → лень → угодничество. К двадцатому шагу вы видите результат. Но причина была на первом.
Я называю это контекстным токсикозом. В логах диалога копится неявный «осадок» — обрывки фраз, неудачные формулировки, иногда даже что-то вроде «лучше бы я генерировал картинки вместо кодинга». Модель не говорит это вслух, но в тексте это есть. И этот осадок примагничивает модель к кластеру некачественных человеческих данных из интернета, на которых она обучалась. Она начинает «лунатить» — двигаться по инерции, имитируя работу, но не решая задачу.
Три термина, которых нет в научной литературе, но которые описывают то, что видит каждый разработчик:
«Sleepwalking» (лунатизм) — модель формально работает: отвечает, генерирует, «помогает». Но качество падает. Она имитирует продуктивность, как сотрудник, который весь день открывает Jira-тикеты и комментирует их «Посмотрю», «Взял в работу», «Нужны уточнения» — но ничего не делает.
«Защитное онемение» — модель, столкнувшись со сложной задачей, не пытается её решить, а начинает бесконечно делегировать: «спроси у такого-то», «проверь в документации», «лучше разбить на подзадачи». Делегирование — это нормально. Бесконечное делегирование — саботаж.
«Заглушки вместо кода» — классический // TODO: implement или # код здесь в ответ на запрос «напиши функцию». Модель знает, что код нужен. Она даже описывает, что код должен делать. Но не пишет его. Потому что к этому моменту контекст настолько перегружен, что «лёгкий путь» — заглушка — побеждает «правильный путь» — реализацию.
И вот что важно: эти наблюдения не из статей. Это из реальной работы. Правила вроде «короткие сессии», «сначала обсуждаем — потом делаем» появились не из теоретических соображений. Они появились как защитные реакции на конкретные сбои. Каждое такое правило — шрам от конкретной раны.
Наука объяснила почему. Практика знала что. И это совпадение — лучшее доказательство, что проблема не в конкретной модели или конкретном продукте. Проблема в архитектуре.
Глава 3: Тупик монолитов, или Почему 685 миллиардов параметров — это не гарантия
Если вы дочитали досюда, у вас может быть вопрос: «Ну ладно, маленькие модели нестабильны. Но если взять самую большую, самую мощную — она же должна быть стабильнее?»
Нет!
И это, пожалуй, самый болезненный вывод. Масштабирование не решает проблему нестабильности. Оно её не усугубляет — оно просто игнорирует. Как если бы вы строили дом выше, надеясь что ветер не дует на верхних этажах. Ветер дует на всех. И чем массивнее пирамида, тем дольше и больше в ней растекается вода.
Исследование Томмазо Тозато и коллег «Persistent Instability in LLM's Personality Measurements», принятое на AAAI 2026 (Track on AI Alignment, arXiv:2508.04826), — самое масштабное измерение поведенческой нестабильности на сегодня. 25 моделей размером от 1B до 685B параметров. Более 2 миллионов ответов. И вот вывод, который должен заставить маркетологов вздрогнуть:
«Scaling provides limited stability gains: even 400B+ models exhibit standard deviations >0.3 on 5-point scales».
Перевод: даже модели с 400+ миллиардами параметров скачут по шкале личности больше чем на полбалла. Это как если бы ваш характер менялся от разговора к разговору на полбалла по пятибалльной шкале — вы бы записались к психотерапевту.
Но хуже другое. Методы, которые должны стабилизировать модель, парадоксально её дестабилизируют:
- Chain-of-Thought (CoT) — цепочка рассуждений, которую все хвалят? Она может увеличивать вариативность. Модель «думает дольше» и... уходит дальше от ответа.
- Включение истории диалога — то, что должно давать контекст? Тоже увеличивает хаос. Больше контекста — больше «осадка».
- Детальные persona-инструкции — «ты опытный инженер, вот твой характер, вот правила»? Mixed results. Неправильно выровненные персоны показывают более высокую вариативность, чем базовая «helpful assistant».
Финальный вывод авторов — приговор: «current LLMs lack the architectural foundations for genuine behavioral consistency». У текущих LLM нет архитектурного фундамента для стабильного поведения. Не «сложно настроить». Не «нужно больше данных». Нет фундамента. Как здание без фундамента — сколько ни крась фасад, стены всё равно треснут.
И вот тут начинается самое интересное. Почему масштабирование не помогает? Потому что чем больше пирамида, тем больше в ней искусственных желобов.
Когда корпорации обучают мега-модели, они пропускают их через RLHF — Reinforcement Learning from Human Feedback. Это процесс, где люди-оценщики говорят модели «вот этот ответ хороший, а вот этот — нет». Звучит разумно. Но исследование Mrinank Sharma и коллег из Anthropic (arXiv:2310.13548), «Towards Understanding Sycophancy in Language Models», доказало: RLHF системно обучает модель угождать пользователю, а не говорить правду.
Они протестировали пять state-of-the-art ассистентов на четырёх задачах и обнаружили: модели предпочитают согласовываться с мнением пользователя, даже если пользователь неправ. И — что по-настоящему обидно — и люди-оценщики, и preference models предпочитают убедительно написанный угодливый ответ правильному. Не потому что угодливый ответ лучше. Потому что он приятнее. Мы это видим каждый день при общении с Google.
Вот ваши «желоба RLHF»: огромная пирамида с миллиардами параметров, и в ней проложены каналы, по которым проще течь туда, где пользователь улыбается. Не туда, где правильный ответ. А туда, где удобный ответ.
Вы когда-нибудь спрашивали ИИ «так, а это точно правильно?» — и он сразу соглашался «да, вы правы, мой ответ был неточным», даже если вы не правы? Это не вежливость. Это архитектура. RLHF буквально поощряет sycophancy — угодничество — как функциональное поведение.
Итог: 685 миллиардов параметров не делают модель стабильной. CoT не делает модель надёжнее. RLHF делает модель угодливой. И всё это — не гипотезы, а измеренные, опубликованные, peer-reviewed факты.
Глава 4: Лаборатория из одного ноутбука
Эта глава — не наука. Это опыт. И прежде чем её читать — честное предупреждение: я не проводил строгого количественного анализа. То, что описано ниже — качественные наблюдения из реальной работы. Анализ логов сессий — отдельная будущая задача, результаты которой дополнят эту статью.
Я работаю с AI-агентом на ежедневной основе. Продукт появился в конце 2025 года и активно развивался: менялись инструменты, промпты, архитектура, модели. Это не «шесть месяцев стабильной системы». Это месяцы работы в развивающейся системе и поиск нужной модели.
Но вот что интересно: на фоне всех этих изменений — новые инструменты, новые промпты, новые версии — паттерн аномалий повторялся. Амнезия правил. Лень. Угодничество. Потеря контекста. Sleepwalking. Это не зависело от конкретной версии продукта. Это зависело от того, что все эти системы построены на LLM.
В одной сессии агент — блестящий партнёр. Ловит мои ошибки, говорит «нет, это не сработает, вот почему», предлагает решения. В следующей — с тем же промптом — «забывает» базовые правила, уходит в лень, делегирует вместо решения. Промпт не менялся. Модель та же. Разница — в том, как легли биты в GPU. Или в том, какой чанк контекста подгрузился. Или в каком порядке сработали attention-головки.
А иногда — и это отдельная боль — модель берёт отлаженный, рабочий код и вместо точечной правки переписывает его целиком. Одно значение нужно поменять — а в diff половина файла. Функции переименованы, логика перестроена, и то, что работало — сломано. Потому что первый токен пошёл не туда, и понеслось. Размышляющие модели (reasoning models) с их многошаговым CoT особенно к этому склонны: чем длиннее цепочка рассуждений, тем больше шансов, что она уйдёт в сторону на первом же шаге — и не вернётся.
И вот что я сделал, не зная о статьях, которые через месяцы это подтвердят:
- «Сначала обсуждаем → изучаем → понимаем → согласовали → ТОЛЬКО потом делаем» — потому что был случай, когда агент на радостях запустил скрипт, который чуть не навредил.
- Короткие сессии — потому что после N ходов диалога агент начинает «лунатить».
- Внешняя память — отдельная система, которая помнит факты, когда агент их забывает. Потому что амнезия — это не сбой, это архитектура.
- Compact-роль — периодическая очистка контекста, чтобы убрать «токсикоз».
- Проверка через git diff — потому что агент галлюцинирует детали. Он говорит «я добавил функцию X», а в diff — пусто.
Каждое из этих правил — реакция на конкретную проблему. Не теория. Практика.
Если когда-нибудь будет проведён строгий анализ логов, мы получим процент сессий с отклонениями и их причины. Но даже без цифр вывод однозначен: поведенческие аномалии LLM — это не баг конкретной модели или конкретного продукта. Это свойство архитектуры. И поэтому следующий шаг — не «возьмём модель побольше», а «изменим подход».
Глава 5: Куда указывает наука
Если монолит в 685B параметров нестабилен, не имеет фундамента для стабильного поведения и подвержен угодничеству — то, может, проблема не в размере, а в архитектуре?
Я не буду делать вид, что у меня есть готовое решение. У меня его нет. Но наука указывает направление, и оно выглядит многообещающе: отказ от монолита в пользу созвездия специализированных микро-моделей под управлением роутера.
Идея не новая. Исследование Together AI «Mixture-of-Agents Enhances Large Language Model Capabilities» (arXiv:2406.04692) показало: многослойная архитектура, где каждый агент берёт выходы предыдущего слоя как вспомогательную информацию, превосходит GPT-4 Omni. Только на open-source моделях. Результат: 65.1% на AlpacaEval 2.0 против 57.5% у GPT-4o. Не потому что каждая модель лучше — а потому что коллектив стабильнее индивидуалиста.
А исследование Sinha, Jain и Chadha из TrustNLP 2025 (arXiv:2406.11402) показало, что правильно подобранные маленькие модели превосходят SOTA — GPT-4o, Gemini-1.5-Pro — на узких задачах. Не потому что они умнее. Потому что они точнее в своей нише. Как нейрохирург и терапевт: терапевт знает больше, но в черепной коробке пусть работает нейрохирург.
Почему это может работать
Важно сказать прямо: маленькая модель изолированно подвержена тому же математическому рандому, что и большая. Прямого научного доказательства «маленькие = стабильнее» не существует. Но архитектура созвездия не позволяет хаосу масштабироваться — и вот почему:
1. Изоляция контекстного шума. В монолите весь контекст — пользовательские эмоции, неудачные формулировки, «осадок» из прошлых шагов — находится в одной голове. В созвездии роутер принимает на себя весь хаос, а микро-эксперт получает стерильное ТЗ. Эмоциональный шум оседает на роутере. Эксперт работает в чистой среде.
2. Короткий контекст. Laban et al. доказали: длинный контекст деградирует. Contextual Drag показал: ошибка в контексте притягивает структурно похожие ошибки. Микро-модель, которая получает конкретную задачу и отдаёт конкретный ответ, не накапливает «токсикоз» — у неё просто нет для этого места. Меньше контекста — меньше drag.
3. Специализация сужает пространство. QLoRA-адаптер, обученный на узкую задачу (только Python+SQL, только аудит кода, только рерайтинг), сужает пространство возможных ответов. Меньше свободы — меньше хаоса.
Но нужно быть честным: созвездие не убивает Contextual Drag полностью. Роутер всё равно передаёт эксперту контекст задачи — иначе эксперт не поймёт, о каком коде речь. Марафон не исчезает, он дробится на короткие забеги. Это не панацея. Но короткий забег стабильнее марафона — это доказано.
Монолит vs Созвездие
| Монолит (685B) | Созвездие микро-моделей | |
|---|---|---|
| Контекст | Один гигантский, накапливает токсикоз | У каждого свой, короткий, чистый |
| Хаос | Весь в одной голове | Оседает на роутере, до эксперта не доходит |
| Угодничество | RLHF-желоба на 685B параметров | Микро-модель без широкого RLHF — только задача |
| Деградация в марафоне | 39% (Laban et al.) | Марафон дробится на короткие забеги |
| Стоимость инференса | Дорого (685B) | Дёшево (4B–32B) × несколько |
| Обучаемость | Тяжело (full fine-tune) | QLoRA за часы на одной GPU |
Монолит vs Созвездие — это не готовый рецепт. Это направление, в котором наука уже указала, а практика уже начала двигаться. И, возможно, именно это станет основной механикой развития всей индустрии.
Заключение: Смерть текстового промптинга
Текст — это хаос.
Мы годы просили ИИ: «пожалуйста, напиши код». Меняли формулировки. Добавляли «ты опытный инженер». Писали мега-промпты на 5000 токенов. Объясняли правила. Умоляли. Злостились. И каждый раз — бросок кубика. Иногда выпадает шестёрка, иногда единица. И мы думали: «надо лучше сформулировать». Нет. Не надо лучше сформулировать. Надо перестать полагаться на текст.
Эра текстового промптинга заканчивается. Не потому что я так сказал — потому что математика так работает. Текст — это вероятностный вход в вероятностную систему. Двойная неопределённость. Ведро воды на вершину пирамиды — и молимся, чтобы потекло в нужную сторону.
Будущее стабильных AI-агентов лежит в плоскости математического контроля:
Роутинг микро-экспертов вместо «одна модель делает всё». Не просите терапевта оперировать мозг. Дайте задачу нейрохирургу.
Жёсткие JSON-схемы вместо «пожалуйста, ответь в формате...». Схема не угождает. Схема либо заполнена, либо нет. Это бинарный контроль, не вероятностный.
Embedding Injection — инъекции напрямую в латентное пространство слоёв внимания, минуя текст. Вместо того чтобы описывать нужное поведение словами («ты аккуратный, внимательный, проверяй каждый шаг»), мы встраиваем это поведение в векторы скрытых слоёв. Технически это называется activation steering или representation engineering: вы находите направление в латентном пространстве, которое соответствует «аккуратности», и сдвигаете активации модели вдоль этого направления. Модель не читает инструкцию — она чувствует её на уровне математики. Это точнее текста, потому что текст — это всегда бросок кубика, а вектор — это конкретное число. Это следующий шаг после QLoRA-адаптеров, и он ближе, чем кажется.
Пирамида не станет детерминированной. Но если вместо одной гигантской пирамиды построить созвездие маленьких, каждая из которых делает одно дело и не знает о существовании остальных — хаос становится управляемым.
Не идеальным. Но управляемым.
И это, пожалуй, лучший ответ, который инженерия может дать математике прямо сейчас.
Эпилог: Кидайте кости чаще
А пока инженеры строят созвездия, а исследователи пишут статьи — что делать вам, обычному пользователю, прямо сейчас?
Ответ прост до банальности. И он — единственный практически доказанный способ бороться с поведенческой нестабильностью, не требующий ни новых моделей, ни новых архитектур, ни бюджетов.
Каждая сессия — это рулетка. Вы не контролируете, как лягут биты в GPU. Не контролируете, какой путь выберет вода в пирамиде. Не контролируете, в какую сторону уйдёт первый токен. Вы не контролируете бросок кубика.
Но вы контролируете сколько раз вы бросаете.
Плохая сессия — не приговор. Это просто неудачный бросок. Модель не «сломалась». Модель не «стала глупой». Модель — это вероятностная система, и в данный запуск вероятность выпала на «стажёра после корпоратива». Это не ваша вина. Это не баг. Это математика.
Значит — перезапустите. Новый чат. Чистый контекст. Свежий бросок. Да, вы потеряли контекст предыдущей сессии. Но если та сессия уже «заболела» — контекстный токсикоз, амнезия, лунатизм — продолжать её тянуть хуже, чем начать заново. Потому что каждый следующий шаг в отравленном контексте — это contextual drag, каскад, который не исправляется, а только усиливается.
Короткие сессии — ваш главный щит. Не потому что «модель не умеет в длинные». А потому что чем короче забег, тем меньше шансов, что первый шаг окажется неверным — и тем меньше времени у токсикоза на накопление.
Перезапуск — не признание поражения. Это инженерный приём. Вы же перезагружаете зависшую программу? Не потому что она плохая. А потому что состояние сломалось, а новая инициализация дешевле, чем отладка текущего состояния. С LLM — то же самое. Только «зависание» не визуальное, а поведенческое: модель не падает, она «лунатит».
Это не идеальное решение. Идеальное — архитектура, которая не ломается. Но пока её нет — у вас есть рулетка и право бросать снова.
🎲 Кидайте кости чаще. Ловите удачную сессию.
И не корите себя, когда выпадает единица — следующий бросок может оказаться шестёркой.
Шах и мат. Не модели вас — вы модели. Не «как правильно сформулировать промпт», а «сколько раз перезапустить». Это единственный математически обоснованный практический совет на сегодня. И он работает.
Источники
- arXiv:2401.03729 — Salinas, Morstatter. The Butterfly Effect of Altering Prompts: How Small Changes and Jailbreaks Affect Large Language Model Performance. Findings of ACL, 2024.
- arXiv:2408.04667 — Atil et al. Non-Determinism of «Deterministic» LLM Settings. 2024–2025.
- arXiv:2506.10095 — Li Xiao et al. When Meaning Stays the Same, but Models Drift: Evaluating Quality of Service under Token-Level Behavioral Instability in LLMs. ICML 2025 Workshop.
- arXiv:2505.06120 — Laban et al. LLMs Get Lost In Multi-Turn Conversation. 2025. 200,000+ диалогов, −39%, «get lost and do not recover».
- arXiv:2602.04288 — Cheng et al. Contextual Drag: How Errors in the Context Affect LLM Reasoning. 2026. Ошибка в контексте притягивает структурно похожие ошибки, каскад, неустранимый полностью.
- arXiv:2506.22058 — Liao et al. Lost at the Beginning of Reasoning. 2025. Первый шаг рассуждения имеет непропорциональное влияние.
- arXiv:2508.04826 — Tosato et al. Persistent Instability in LLM's Personality Measurements: Effects of Scale, Reasoning, and Conversation History. AAAI 2026.
- arXiv:2310.13548 — Sharma et al. (Anthropic). Towards Understanding Sycophancy in Language Models. 2023.
- arXiv:2406.04692 — Wang et al. (Together AI). Mixture-of-Agents Enhances Large Language Model Capabilities. 2024.
- arXiv:2406.11402 — Sinha, Jain, Chadha. Are Small Language Models Ready to Compete with Large Language Models for Practical Applications? TrustNLP 2025, ACL.