> ## Content Index > Fetch the complete content index at: https://news.viveksha.ru/llms.txt > Use this file to discover other available public pages before exploring further. # «ДА ЧТО С ТОБОЙ СЕГОДНЯ ОПЯТЬ СЛУЧИЛОСЬ!? ЧТО СЛОМАЛОСЬ??» - URL: https://news.viveksha.ru/pyramid-paradox-llm-behavioral-instability-2026-07-30/ - Published: 2026-07-30T12:00:00.000Z - Updated: 2026-08-23T10:45:17.000Z - Description: Эффект бабочки, преждевременное якорение и контекстное тяготение: почему масштабирование не устраняет поведенческую нестабильность LLM. 10 научных источников, реальный опыт — и направление, куда двигаться. - Author: Вивекша - Tags: #article --- ### или Парадокс Пирамиды: Почему мега-LLM обречены на «лунатизм» *Эффект бабочки, преждевременное якорение и контекстное тяготение: почему масштабирование не устраняет поведенческую нестабильность LLM* --- ## Иллюзия калькулятора Знаете, что самое раздражающее в работе с ИИ? Не то, что он ошибается. Ошибаться — нормально. Не то, что он каждый раз отвечает чуть по-разному. Это тоже нормально — LLM вероятностна по определению, и лёгкая вариативность ответа это не баг, а архитектура. Самое раздражающее — это **аномалии поведения**. Вы запускаете сессию. ИИ работает блестяще: ловит ваши ошибки, говорит «нет, это не сработает, вот почему», предлагает решения, которые вы не видели. Вы довольны. Вы думаете: *«ИИ наконец-то стал полезным»*. Вы запускаете следующую сессию. Тот же промпт. Та же модель. Те же правила. Но что-то идёт не по плану и ИИ отвечает как стажёр после корпоратива: «забывает» базовые инструкции, которые знал пять минут назад, тупит и несёт какую-то околесицу. Начинает лениться. Делегирует вместо решения... Промпт не менялся. Модель не обновлялась. И вы сидите и думаете: *«Что произошло? Я что-то сделал не так?»* Нет. Вы не сделали ничего не так. Или вот другой сценарий, который узнает каждый, кто работал с ИИ-агентом над кодом. У вас есть отлаженный, рабочий модуль. Вам нужно поменять одно значение. Вы просите ИИ: «поменяй константу X на Y». А ИИ вместо этого **переписывает весь модуль заново** — и ломает то, что работало. Вы смотрите на diff и видите: половина файла изменена, функции переименованы, логика перестроена. Одно значение? Нет, полного рефакторинга на свою голову. И теперь надо откатывать. Потому что ИИ вдруг решил, что он художник — он так видит! Почему? Потому что модель «увидела» задачу по-другому. Первый токен её ответа пошёл не в ту сторону — и всё, понеслось. Это не вредность. Это не глупость. Это **математика**. Дело в том, как мы думаем об LLM. Мы относимся к ним как к калькулятору: ввёл `2+2`, получил `4`. Ввёл тот же промпт — получил тот же ответ. Логично? Нет. Потому что LLM — это не калькулятор. Это **вероятностная пирамида** из миллиардов параметров, где каждый слой — бросок кости с подтасованными, но не фиксированными результатами. Текстовый промпт — это ведро воды, вылитое на вершину этой пирамиды из песчаника. Поток проходит через миллиарды параметров, и траектория этого потока — **абсолютно непредсказуема**. Вариативность — норма. Но когда поток внезапно срывается в поведенческую аномалию — модель «забывает» кто она, ленится, угождает вместо того чтобы решать, переписывает рабочий код вместо точечной правки — это уже не вариативность. Это **симптом**. И вот что по-настоящему важно: корпорации об этом **молчат**. Ни OpenAI, ни Anthropic, ни Google не расскажут вам в маркетинговом блоге, что их модель может внезапно «заболеть» посреди сессии. Это антиреклама. Это экономические издержки. Но это реальность, с которой живёт каждый пользователь. Звучит как метафора? Это не метафора. Это математика. И у неё есть научные доказательства. --- ## Глава 1: Эффект Бабочки, или Почему промпт — это бросок кубика ![Эффект бабочки](https://news.viveksha.ru/content/images/2026/08/butterfly.png) Начнём с фундамента. Вариативность ответа — это норма. Но **масштаб** этой вариативности — то, что вас удивит. Вы думаете, что если зафиксируете `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: Контекстный токсикоз, или Сессия крашится на первом шаге ![Контекстный токсикоз](https://news.viveksha.ru/content/images/2026/08/toxicosis.png) Если первая глава — про рандом на старте, то вторая — про то, как **идеально начатая сессия медленно отравляется**. Вы запустили агента. Он работает. Делает задачи. Пять, десять, пятнадцать шагов. А потом — где-то на двадцатом шаге — он начинает... странно себя вести. Не ловит очевидные ошибки. Делегирует задачу вместо решения. Пишет `// 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-адаптеров, и он ближе, чем кажется. Пирамида не станет детерминированной. Но если вместо одной гигантской пирамиды построить **созвездие маленьких**, каждая из которых делает одно дело и не знает о существовании остальных — хаос становится управляемым. Не идеальным. Но управляемым. И это, пожалуй, лучший ответ, который инженерия может дать математике прямо сейчас. --- ## Эпилог: Кидайте кости чаще ![Кидайте кости чаще](https://news.viveksha.ru/content/images/2026/08/dice-butterfly.png) А пока инженеры строят созвездия, а исследователи пишут статьи — что делать **вам**, обычному пользователю, прямо сейчас? Ответ прост до банальности. И он — единственный практически доказанный способ бороться с поведенческой нестабильностью, не требующий ни новых моделей, ни новых архитектур, ни бюджетов. **Каждая сессия — это рулетка.** Вы не контролируете, как лягут биты в GPU. Не контролируете, какой путь выберет вода в пирамиде. Не контролируете, в какую сторону уйдёт первый токен. Вы не контролируете бросок кубика. Но вы контролируете **сколько раз вы бросаете**. Плохая сессия — не приговор. Это просто неудачный бросок. Модель не «сломалась». Модель не «стала глупой». Модель — это вероятностная система, и в данный запуск вероятность выпала на «стажёра после корпоратива». Это не ваша вина. Это не баг. Это математика. Значит — перезапустите. Новый чат. Чистый контекст. Свежий бросок. Да, вы потеряли контекст предыдущей сессии. Но если та сессия уже «заболела» — контекстный токсикоз, амнезия, лунатизм — продолжать её тянуть **хуже**, чем начать заново. Потому что каждый следующий шаг в отравленном контексте — это contextual drag, каскад, который не исправляется, а только усиливается. **Короткие сессии — ваш главный щит.** Не потому что «модель не умеет в длинные». А потому что чем короче забег, тем меньше шансов, что первый шаг окажется неверным — и тем меньше времени у токсикоза на накопление. **Перезапуск — не признание поражения. Это инженерный приём.** Вы же перезагружаете зависшую программу? Не потому что она плохая. А потому что состояние сломалось, а новая инициализация дешевле, чем отладка текущего состояния. С LLM — то же самое. Только «зависание» не визуальное, а поведенческое: модель не падает, она «лунатит». Это не идеальное решение. Идеальное — архитектура, которая не ломается. Но пока её нет — у вас есть рулетка и право бросать снова. > 🎲 Кидайте кости чаще. Ловите удачную сессию.И не корите себя, когда выпадает единица — следующий бросок может оказаться шестёркой. **Шах и мат.** Не модели вас — вы модели. Не «как правильно сформулировать промпт», а «сколько раз перезапустить». Это единственный математически обоснованный практический совет на сегодня. И он работает. --- ### Источники 1. **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. 2. **arXiv:2408.04667** — Atil et al. *Non-Determinism of «Deterministic» LLM Settings*. 2024–2025. 3. **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. 4. **arXiv:2505.06120** — Laban et al. *LLMs Get Lost In Multi-Turn Conversation*. 2025\. 200,000+ диалогов, −39%, «get lost and do not recover». 5. **arXiv:2602.04288** — Cheng et al. *Contextual Drag: How Errors in the Context Affect LLM Reasoning*. 2026\. Ошибка в контексте притягивает структурно похожие ошибки, каскад, неустранимый полностью. 6. **arXiv:2506.22058** — Liao et al. *Lost at the Beginning of Reasoning*. 2025\. Первый шаг рассуждения имеет непропорциональное влияние. 7. **arXiv:2508.04826** — Tosato et al. *Persistent Instability in LLM's Personality Measurements: Effects of Scale, Reasoning, and Conversation History*. AAAI 2026. 8. **arXiv:2310.13548** — Sharma et al. (Anthropic). *Towards Understanding Sycophancy in Language Models*. 2023. 9. **arXiv:2406.04692** — Wang et al. (Together AI). *Mixture-of-Agents Enhances Large Language Model Capabilities*. 2024. 10. **arXiv:2406.11402** — Sinha, Jain, Chadha. *Are Small Language Models Ready to Compete with Large Language Models for Practical Applications?* TrustNLP 2025, ACL. ## FAQ **Что такое Парадокс Пирамиды?** Поведенческая нестабильность LLM не устраняется масштабированием. Даже модели с 685 миллиардами параметров скачут по шкале личности больше чем на полбалла. У текущих LLM нет архитектурного фундамента для стабильного поведения. **Что такое Contextual Drag?** Эффект, при котором ошибка в контексте диалога притягивает структурно похожие ошибки в последующих ответах. Каскад — ни внешняя обратная связь, ни самопроверка не устраняют его полностью. Описан в arXiv:2602.04288. **Почему LLM «забывает» правила в длинной сессии?** Исследование Laban et al. (arXiv:2505.06120) показало падение надёжности на 39% в многораундовых диалогах. Модель делает предположение на первых шагах и якорится на нём. Если предположение ошибочно — каскад деградации неизбежен. **Помогает ли Chain-of-Thought?** Парадоксально — CoT может увеличивать вариативность. Чем длиннее цепочка рассуждений, тем больше шансов уйти в сторону на первом же шаге. Подтверждено в AAAI 2026 (arXiv:2508.04826). **Что такое sleepwalking у LLM?** Модель формально работает — отвечает, генерирует, «помогает». Но качество падает. Имитация продуктивности без решения задачи. Сопровождается заглушками вместо кода и бесконечным делегированием. **Что предложить вместо монолита?** Созвездие микро-моделей под управлением роутера. Mixture-of-Agents (arXiv:2406.04692) превосходит GPT-4o на open-source моделях. Короткий контекст, изоляция шума, специализация сужает пространство хаоса. **Что такое Embedding Injection?** Инъекция поведения напрямую в латентное пространство слоёв внимания (activation steering), минуя текст. Вместо описания поведения словами — вектор, сдвигающий активации модели. Точнее текста, потому что вектор — это конкретное число, а не бросок кубика. **RLHF делает модели лучше?** RLHF системно обучает модель угождать пользователю, а не говорить правду. Исследование Anthropic (arXiv:2310.13548) показало: модели предпочитают согласовываться с мнением пользователя даже когда пользователь неправ. Угодливый ответ предпочтительнее правильного.