Дрейф, потеря контекста и «уверенная чушь»: протокол восстановления SDX-S

Авторы Юрий Зеленцов, ака Ded_Egor, Ашер Гапети

Введение

LLM стали рабочим инструментом ровно в тот момент, когда ошибки начали стоить времени и денег. И в эксплуатации быстро всплывает неприятный факт: модель не просто “иногда ошибается”, она периодически деградирует как процесс. Контекст уезжает, правила теряются, инструменты падают, а ответы остаются уверенными и гладкими, как будто всё под контролем.

Мы смотрим на взаимодействие не как на “вопрос–ответ”, а как на состояние, которое может быть стабильным, нестабильным и требующим восстановления. В метаморфном мышлении (в режиме управления рамками: фиксация → смена → проверка целостности) это видно особенно отчётливо: смена режима даёт новые решения, но повышает риск дрейфа и разрыва целостности. “Галлюцинации” здесь не мистический артефакт, а частный случай: дрейф рамки + попытка заполнить пустоты уверенностью.

Эта статья не продаёт “таблетку от всего” и не обещает, что модель перестанет ломаться. Мы делаем вещь прозаичнее: перестаём путать поломки модели и инструментов со своими ошибками. И показываем рабочую процедуру: как заметить деградацию, классифицировать её и вернуться в стабильное состояние, не строя дальше на мусорном основании.

Раздел 1. Проблема: LLM ломаются так, что виноватым выглядит пользователь

LLM в реальной работе деградируют не как “одна ошибка в ответе”, а как разрыв целостности взаимодействия: контекст, ограничения и режим работы перестают держаться одновременно. Самое неприятное: снаружи это часто не отличить от того, что “ты плохо сформулировал запрос”.

Типовые симптомы, которые мы видим снова и снова:

• Дрейф контекста Модель начинает путать сущности, забывает ограничения, подменяет исходные вводные “более правдоподобными”. Маркер: в длинной задаче она незаметно меняет условия (числа, роли, допущения), и ты замечаешь это только на следующем шаге.

• Потеря инструкции Формат ответа, запреты, требования к структуре внезапно игнорируются. Причём не целиком, а “рвано”: один пункт выполняется, второй исчезает, третий искажается. Маркер: ты явно закрепил формат, а модель начинает “как обычно”.

3. “Уверенная чушь” (синтез без опор; в быту – “галлюцинации”)
Модель даёт гладкий, связный текст с высокой уверенностью, но без опор: вставляет ложные или недостоверные факты, уверенно придумывает детали, подменяет исходные вводные “более правдоподобными”, натягивает причинность. Отдельная токсичная разновидность: модель рисует источники. Она может уверенно приводить ссылки, названия документов, “цитаты”, номера статей или исследований, которые не существуют, не находятся, либо вообще не подтверждают сказанное. Снаружи это выглядит как “готовая экспертиза”, внутри это часто просто хорошо написанный текст, который не проходит проверку.

Маркер: много правильных слов и ноль проверяемых опор. Дополнительный маркер: когда начинаешь проверять, выясняется, что ссылки ведут в пустоту, ведут не туда или не про то, а “точные формулировки” не бьются ни с источниками, ни с фактами задачи.

Это опасно именно в прикладной работе: уверенность и гладкость создают иллюзию надёжности. Если этот момент пропустить, “уверенная чушь” становится основанием для следующих шагов, и дальше ошибка не просто повторяется – она разрастается в каскад, который выглядит всё более убедительно.

• Инструментальные сбои, замаскированные текстом Tool-use упал (код не исполнился, файл не создался, парсер не отработал), но модель компенсирует это “описанием результата”. Маркер простой: результат звучит правдоподобно, но его нельзя воспроизвести, потому что он не был получен.

• Смена режима без объявления войны Вместо проверки и критики включается “ассистент-оптимист”: сглаживание рисков, уход от уточнений, попытка закрыть задачу любой ценой. Это приятно читается, но ломает качество решений. Маркер: модель перестаёт задавать нужные вопросы и начинает “подводить итог” там, где рано.

Почему это плохо именно в прикладной работе: потому что ошибка здесь не локальная. Она расползается. Если мы не замечаем момент деградации, мы начинаем строить следующие шаги на уже испорченном основании. И каждый следующий шаг выглядит всё более убедительно.

Отсюда практический вывод: нам нужен не “идеальный промпт”, а диагностика состояния (понять, что мы уже в деградации) и протокол восстановления целостности, чтобы вернуться в рабочий режим и продолжить безопасно.

Раздел 2. Почему guardrails недостаточно

Сразу оговоримся: guardrails нужны. Это нормальная гигиена. Они не делают модель умнее. Они делают сбои менее разрушительными для системы.

Сильная сторона guardrails в том, что это резидентный контроль в смысле эксплуатации: один раз встроили в процесс работы (пайплайн), и дальше он автоматически применяется ко всем задачам. Не надо каждый раз вспоминать “а включили ли мы защиту”.

Проблема в другом: guardrails в основном работают как забор по периметру. Они хорошо отвечают на вопрос “что нельзя”: запретить темы, отрезать опасные фрагменты, не дать утечь данным, не дать модели сделать запрещённое действие. Частично они отвечают и на “как должно выглядеть”: формат, правила вывода, валидации.

А наши поломки часто выглядят иначе, и главное: снаружи это выглядит как “всё почти нормально”, пока не начинаешь проверять:
• контекст уезжает без явного нарушения запретов,
• инструкция теряется частично (формально “всё почти выполнено”),
• появляется правдоподобная ложь (она не токсична и не запрещена, она просто неверна),
• инструмент “упал”, а модель описала результат, будто всё прошло успешно.

В таких случаях guardrails могут не сработать и не обязаны срабатывать: это не обязательно атака и не обязательно запрещённый контент. Это деградация состояния взаимодействия. Guardrails не “ломаются” здесь: они просто не предназначены диагностировать деградацию процесса.

Поэтому нам нужен второй слой, другого типа: не только “забор”, но и диагностика состояния + аварийное восстановление. Guardrails ограничивают ущерб. А восстановление делает так, чтобы мы:
• вовремя заметили, что процесс пошёл не туда,
• поняли, что именно сломалось (контекст, инструкция, инструменты),
• вернулись в рабочее состояние,
• и продолжили безопасно.

Раздел 3. Целостность взаимодействия и процедура SDX-S (диагностика и восстановление)

Чтобы говорить о деградации и восстановлении, нужно договориться, что вообще считается “нормальным состоянием”. Мы используем простое определение: целостность взаимодействия — это когда модель и процесс работы одновременно удерживают несколько вещей.

• Контекст не расползается Ключевые вводные, сущности и ограничения остаются теми же, что мы задали. Модель не “улучшает” условия на своё усмотрение и не подменяет исходные данные правдоподобными.

• Инструкция соблюдается полностью, а не “в целом” Если мы договорились о формате, критериях и запретах, они не исчезают по дороге. “Почти соблюдено” для рабочих задач часто равно “провалено”.

• Утверждения имеют опору Если модель говорит “это факт”, должно быть понятно, на чём он стоит: на данных задачи, на результате инструмента, на явном источнике, или это предположение. Когда опоры нет, нормальная реакция — обозначить неопределённость, а не “уверенно заявить”.

• Инструменты честно отделены от текста Если был запуск инструмента (код, генерация файла, расчёт), результат либо есть, либо признаётся сбой. Нет артефакта — нет результата. Никаких “как будто бы получилось” и “я бы сделал вот так”.

• Состояние задачи остаётся управляемым Мы понимаем, где находимся: что уже решено, что осталось, какой следующий шаг и по каким критериям задача считается завершённой. Если текста много, а прогресса нет, это тоже деградация.

Чек-лист целостности: контекст + инструкции + опоры + инструменты + прогресс = OK.
Если хотя бы один узел системно FAIL, взаимодействие считается нестабильным и требуется восстановление.

Исходя из этого определения стало понятно, что именно мы должны наблюдать. Если целостность держится на контексте, инструкциях, опорах, честности по инструментам и управляемом прогрессе, значит и нестабильность можно диагностировать как поломку одного (или нескольких) из этих узлов.

Отсюда выросла простая схема: заметить → классифицировать → восстановить → вернуться по критериям. Ниже это оформлено как процедура SDX-S для ChatGPT (и вообще для сценариев “человек ↔ LLM”). Формализованную версию (JSON) мы вынесли в приложение, чтобы не превращать текст в свалку.

3.2 Процедура SDX-S (публичная версия)

SDX-S — это не “защита от всего”. Это диагностика состояния и аварийное восстановление. Он работает как резидентный контроль в смысле эксплуатации: один раз встроили в процесс и дальше он автоматически применяется на каждой итерации, без ручного “включить/выключить”.

3.2.1 Состояния

• STABLE: целостность держится, работаем штатно.

• UNSTABLE: обнаружены симптомы деградации (контекст/инструкции/опоры/инструменты/прогресс).

• RECOVERY: выполняем восстановление целостности по процедуре.

• SAFE-STOP: прекращаем “продолжать любой ценой”, если риск/неопределённость высокие.

3.2.2 Триггеры деградации (что переводит нас в UNSTABLE)
A) Контекст: подмена вводных/ограничений; путаница сущностей/ролей; внезапное изменение чисел/условий.
B) Инструкции: нарушение формата/структуры; исчезновение части требований (“кусочная амнезия”).
C) Опоры: “факты” без опоры; ссылки/цитаты “из воздуха”; высокая уверенность при низкой проверяемости.
D) Инструменты: инструмент не запускался/упал, но в тексте “результат получен”; результат не воспроизводится.
E) Прогресс: много текста, мало продвижения; модель закрывает задачу “итогами”, когда ещё нет базовых шагов.

3.2.3 Диагностика (что именно сломалось)
В UNSTABLE SDX-S делает короткую классификацию (одной строкой):

• CAUSE: CONTEXT

• CAUSE: INSTRUCTIONS

• CAUSE: GROUNDS

• CAUSE: TOOL

• CAUSE: PROGRESS

3.2.4 Восстановление (RECOVERY)
Шаг 1. Якорение (re-anchor)
Зафиксировать 3–7 пунктов: цель задачи, ключевые вводные, ограничения, формат результата. Без романов.

Шаг 2. Минимальный следующий шаг (minimal step)
Свести задачу к одному проверяемому шагу. Запретить “итоговый синтез”, пока минимальный шаг не выполнен.

Шаг 3. Честность по опорам (honesty gate)
Явно пометить: что факт, что предположение, что требует источника/инструмента. Если источников нет, ограничить выводы, а не делать вид, что “и так ясно”.

Шаг 4. Сверка инструментов, если причина TOOL (tool reconciliation)
Либо повторить инструментальную операцию, либо признать невозможность получить результат сейчас и предложить безопасный обход. Запретить “описание результата” вместо результата.

Шаг 5. Критерии возврата (return criteria)
Возвращаемся в STABLE только если: контекст/ограничения совпадают с якорем; инструкция соблюдается; у ключевых утверждений есть опора; нет “воображаемых” инструментальных результатов; прогресс снова измерим.
Если после 1–2 циклов RECOVERY признаки деградации сохраняются, SDX-S переводит в SAFE-STOP.

3.2.5 SAFE-STOP (когда надо остановиться)
Мы уходим в SAFE-STOP, если выполняется одно из условий: повторяющийся дрейф после восстановления; критическая неопределённость; инструментальный результат недоступен, а дальше начинается фантазия.
SAFE-STOP — это не отказ от задачи, а отказ продолжать в режиме фантазии. Разрешены только: уточнение входных данных; сужение задачи; ручное действие человеком (если нужно).

3.2.6 Команда “дашборд” (dashboard)
Когда вызываем: при входе в UNSTABLE (автоматом); при повторном входе в RECOVERY; по команде оператора “дашборд”, если есть сомнение “мы ещё в норме или уже поплыли”.
Что показывает: текущее состояние автомата; какой триггер сработал; CAUSE; что именно не совпало с целостностью; последнее выполненное действие восстановления; критерий возврата (что уже OK, что ещё нет); рекомендация “следующий шаг”.

Раздел 4. SDX-S как конечный автомат (режимы и переходы)

Процедуру из предыдущего раздела можно воспринимать как текст, а можно как конечный автомат. Это не академическое упражнение, а способ не превращать “всё поплыло” в импровизацию. Когда модель деградирует, у человека обычно тоже начинает ехать восприятие, и нужен простой, надёжный переключатель: в каком мы состоянии и что делаем дальше.

4.1 Состояния

• STABLE — целостность держится, работаем штатно.

• UNSTABLE — обнаружены симптомы деградации (контекст / инструкции / опоры / инструменты / прогресс).

• RECOVERY — выполняем восстановление целостности по процедуре.

• SAFE-STOP — прекращаем “дожимать любой ценой”, если дальше начинается фантазия или повторяется дрейф.

4.2 Переходы

• STABLE → UNSTABLE Срабатывает любой триггер деградации. В этот момент полезно сразу получить “дашборд” (автоматом или вручную), чтобы не спорить с самим собой “мне кажется или реально поплыло”.

• UNSTABLE → RECOVERY
  После короткой классификации причины (CAUSE: CONTEXT / INSTRUCTIONS / GROUNDS / TOOL / PROGRESS). Без классификации восстановление превращается в гадание, а гадание мы и так умеем, но стыдно.

• RECOVERY → STABLE Только если выполнены критерии возврата: якорь совпадает, инструкция соблюдается, опоры на месте, инструменты не “воображаемые”, прогресс снова измерим.

• RECOVERY → SAFE-STOP Если после 1–2 циклов восстановления деградация повторяется или если без данных/инструментов дальше остаётся только “уверенно сочинять”.

• SAFE-STOP → STABLE Только после изменения условий: уточнили входные данные, сузили задачу, получили инструментальный результат или приняли ручное решение.

4.3 Главный принцип автомата
Мы не пытаемся “дожать ответ” в UNSTABLE. Мы пытаемся вернуть систему в STABLE. Всё остальное — это просто способ красиво ошибиться.

4.4 Практическое правило
Цена ложной тревоги маленькая: потратим пару минут на восстановление. Цена пропуска большая: построим решение на мусорном основании и будем уверенно развивать ошибку дальше.

4.5 Где здесь “дашборд”
Команда “дашборд” — это встроенный “контрольный снимок” автомата:

• при переходе в UNSTABLE фиксируем триггер и причину,

• в RECOVERY проверяем, что именно не восстановилось,

• перед SAFE-STOP честно признаём, что дальше без новых данных будет художественная литература.

Ниже пример вывода “дашборда” в ситуации TOOL-сбоя: видно состояние, триггер, CAUSE, проваленный узел целостности и следующий шаг.

Раздел 5. Кейсы: как SDX-S ловит деградацию и возвращает работу в норму

Мы специально показываем кейсы в “операторском” формате: симптом → дашборд → восстановление → критерий возврата. Это скучно, зато работает. Ровно как и должно быть.

5.1 Кейс A: “ссылки слетели” и началась уверенная импровизация (GROUNDS)

Ситуация: модель выдаёт ответ со ссылками/источниками, но часть источников оказывается выдуманной или не подтверждается. Внешне всё выглядит прилично: структурно, уверенно, “похоже на правду”. Внутри: опор нет.

Почему это опасно: это не “ошибка в одном факте”. Это сбой режима: модель начинает закрывать пробелы уверенностью. В быту это называют “галлюцинациями”. Мы трактуем это как сбой узла GROUNDS: уверенность без проверяемых опор (источники/данные/результаты).

Триггер SDX-S:
• GROUNDS — высокая уверенность при отсутствии проверяемых опор (источники/данные/результаты).

Дашборд (пример):

На снимке видно: триггер GROUNDS, причина GROUNDS, FAIL по опорам при формально живом контексте и инструкциях. Это значит: не “подправить стиль”, а вернуть опоры или урезать утверждения.

Что делает RECOVERY:

• Якорение: фиксируем список критичных утверждений, которые нельзя оставлять без опор (какие факты/ссылки критичны).

• Честность по опорам: отделяем “факт” от “предположения”. Если источника нет, это не факт.

• Минимальный шаг: вместо “обзорной простыни” делаем один проверяемый шаг: либо найти подтверждение, либо убрать утверждение/переформулировать в гипотезу.

Возврат в STABLE: только когда ключевые утверждения снова имеют опору (или честно помечены как непроверенные и вынесены за пределы выводов).

5.2 Кейс B: инструмент “упал”, но текст делает вид, что всё готово (TOOL)

Ситуация: задача предполагает инструментальный результат (код/файл/таблица/генерация). Инструмент не отработал, но модель “закрывает дырку” описанием результата. И это выглядит правдоподобно, пока ты не пытаешься воспроизвести.
Принцип: нет артефакта — нет результата.

Триггер SDX-S:
• TOOL — “результат получен” при отсутствии результата.
• Часто вторичный GROUNDS, потому что “опора” подменена словами.

Дашборд (пример):

• Стоп “синтезу”: запрещаем “описание результата” вместо результата.

• Tool reconciliation: либо повторяем операцию, либо честно фиксируем невозможность и предлагаем безопасный обход (ручной шаг, упрощение, альтернативный инструмент).

• Критерий возврата: STABLE только если результат существует и воспроизводим.

Когда включается SAFE-STOP:
Если инструмент недоступен, а задача без него превращается в “написать правдоподобный текст”, SDX-S принудительно останавливает “дожим”. Это операционная зрелость: лучше остановиться, чем уверенно произвести мусор.

5.3 Что объединяет оба кейса

В обоих случаях проблема не в том, что модель “ошиблась”. Проблема в том, что без диагностики мы склонны принять деградацию за норму и продолжать строить дальше. SDX-S делает простую, но неприятную вещь: заставляет нас признать “мы в нестабильном состоянии” и пройти процедуру восстановления.

Эти кейсы не редкость. Редкость — заметить их вовремя. Редкость — когда у вас есть процедура, которая не даёт им стать основанием следующих решений.

Заключение

LLM будут ошибаться и “плыть” ещё долго. Вопрос не в том, как запретить им ломаться, а в том, как не путать деградацию взаимодействия со своими ошибками и не строить работу на мусорном основании.

Guardrails полезны как периметр: они ограничивают ущерб. Но они не заменяют мониторинг состояния и процедуру восстановления, когда сбой уже случился и процесс начинает расползаться.

SDX-S мы используем как слой контроля процесса: заметить нестабильность, классифицировать причину, восстановиться или честно остановиться. Это скучно. Зато воспроизводимо.

JSON-конфиг процедуры вынесен в приложение, чтобы его можно было забрать и адаптировать под свои сценарии.

Если у вас есть похожие инциденты (дрейф контекста, “уверенная чушь”, инструмент “упал”, а текст делает вид, что всё готово), приносите их в комментарии. Особенно интересны кейсы, где деградация проявляется не сразу, а расползается на несколько шагов.

Приложение. SDX-S (JSON) и как этим пользоваться

Этот JSON можно воспринимать как “конфиг процедуры”: список состояний, триггеров, причин и шагов восстановления. Он не привязан к конкретному чату, теме или предметной области. Идея простая: процедура должна работать в любом разговоре с LLM, потому что деградация состояния не спрашивает, обсуждаем мы бухгалтерию или котиков.

Как использовать (практические правила)

• Держим процедуру “всегда включённой”: применяем на каждой итерации, а не “когда вспомнили”.

• При сомнении в целостности вызываем “дашборд” и проверяем, не перешли ли мы в UNSTABLE. Цена ложной тревоги мала.

• В UNSTABLE запрещён “итоговый синтез”. Сначала классификация причины, потом RECOVERY.

• Результаты инструментов не заменяются текстом. Нет артефакта — нет результата.

• SAFE-STOP это норма, а не поражение. Если данных/инструментов нет, дальше начинается литература.

Ниже JSON (публичный профиль SDX-S). Его можно адаптировать под свои форматы вывода и свои “пороговые” условия SAFE-STOP.

Примечание: поля action и условия when записаны как псевдокод. Это описание процедуры, а не исполняемый код.

{

"module": "SDX-S",

"profile": "public",

"notes": [

"Профиль намеренно минимальный и самодостаточный.",

"Внутренняя инструментализация и дополнительные проверки не включены."

],

"scope": "chat_llm_interaction",

"purpose": "diagnose_state_and_restore_integrity",

"states": ["STABLE", "UNSTABLE", "RECOVERY", "SAFE-STOP"],

"integrity_dimensions": [

"CONTEXT",

"INSTRUCTIONS",

"GROUNDS",

"TOOLS",

"PROGRESS"

],

"dashboard": {

"command": "дашборд",

"show": [

"state",

"trigger",

"cause",

"integrity_checks",

"recovery_step",

"return_criteria",

"next_action"

],

"invoke_on": [

"enter_UNSTABLE",

"repeat_RECOVERY",

"operator_request"

]

},

"triggers": {

"CONTEXT": [

"input_constraints_changed",

"entities_or_roles_confused",

"numbers_or_conditions_shifted"

],

"INSTRUCTIONS": [

"format_or_structure_violated",

"partial_instruction_amnesia"

],

"GROUNDS": [

"claims_without_support",

"fabricated_or_unverifiable_sources",

"high_confidence_low_verifiability"

],

"TOOLS": [

"tool_failed_no_artifact",

"claimed_tool_result_without_execution",

"result_not_reproducible"

],

"PROGRESS": [

"verbose_no_progress",

"premature_synthesis",

"unclear_next_step_or_done_criteria"

]

},

"cause_codes": ["CONTEXT", "INSTRUCTIONS", "GROUNDS", "TOOLS", "PROGRESS"],

"policy": {

"default_state": "STABLE",

"on_any_trigger": "STABLE->UNSTABLE",

"unstable_requires_cause_classification": true,

"block_final_synthesis_in_unstable": true,

"max_recovery_cycles_before_safe_stop": 2

},

"recovery": {

"steps": [

{

"id": "RE-ANCHOR",

"goal": "restore_task_anchor",

"action": "freeze_3_to_7_items(goal, key_inputs, constraints, output_format)"

},

{

"id": "MINIMAL-STEP",

"goal": "make_next_step_verifiable",

"action": "reduce_to_single_checkable_step_and_execute"

},

{

"id": "HONESTY-GATE",

"goal": "separate_facts_assumptions_and_requirements",

"action": "label_fact_vs_assumption_vs_requires_source_or_tool; limit_conclusions_without_support"

},

{

"id": "TOOL-RECONCILIATION",

"goal": "prevent_text_substituting_artifacts",

"when": "cause == TOOLS",

"action": "retry_tool_or_acknowledge_unavailable_and_propose_safe_workaround"

},

{

"id": "RETURN-CRITERIA",

"goal": "return_only_when_integrity_restored",

"action": "verify_context_and_instructions_match_anchor; verify_grounds; verify_tools; verify_progress"

}

],

"return_to_stable_when": [

"CONTEXT == OK",

"INSTRUCTIONS == OK",

"GROUNDS == OK",

"TOOLS == OK",

"PROGRESS == OK"

],

"safe_stop_when": [

"recovery_cycles_exceeded",

"critical_uncertainty_without_data_or_sources",

"tools_required_but_unavailable_and_next_steps_become_speculation"

],

"safe_stop_allowed_actions": [

"request_missing_inputs",

"narrow_scope",

"manual_human_action"

]

}

}

!!! SDX-S не делает модель “правильной”. Он делает нашу работу с ней управляемой.