Непрерывность контекста как следующий слой эффективности ИИ: от ответа к воспроизводимости

Зеленцов Юрий, Ашер и Пони Гапети.

Можно написать сильный промпт и получить сильный ответ. Проблема в том, что на следующем шаге, в другой сессии или просто в другом настроении модели этот же промпт может сработать иначе. Удлинять промпт и зашивать в него всё поведение тоже не спасает: чем больше инструкций, тем выше шанс, что часть из них будет проигнорирована или конфликтовать между собой. Настраивать модель в каждой сессии вручную значит смириться с тем, что вы не строите процесс, а обслуживаете одноразовые демонстрации. Выход лежит не в «ещё одном промпте», а в непрерывности контекста как режиме работы.

Промпт‑инженерия оптимизирует отдельный ответ. Непрерывность контекста оптимизирует воспроизводимое поведение системы в длительной работе. Если вы используете ИИ как вендинговый автомат «вопрос → ответ», этого различия почти не видно. Но как только вы решаете задачи на 10–20 шагов, становится важно не «насколько сильным был один ответ», а сохраняются ли инварианты: цель, ограничения, принятые решения, дисциплина допущений и способность восстановиться после отклонений.

В этой статье «контекст» не равен окну токенов и не сводится к длине истории чата. Непрерывность контекста — это сохранение рабочей преемственности между шагами: удерживаются цель и ограничения, не теряются принятые решения, фиксируются допущения и границы исходных данных, а при сбоях сохраняется способность вернуться в рабочий режим без перезапуска процесса.

Чтобы не путать это с соседними понятиями, ниже — короткое разведение терминов.

Введение: от разовых удач к протоколам

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

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

Следующий шаг — не перенастраивать модель в каждой сессии, а закреплять удачные режимы работы как протоколы: какие инварианты держим, где границы данных, как маркируем допущения и как возвращаемся в рабочее состояние после отклонений. В этом смысле непрерывность контекста — не «память побольше», а дисциплина длительной работы: она помогает сохранять управляемость от шага к шагу.

Наблюдения, описанные в этой статье, позже были обобщены нами в более широкой рамке метаморфного мышления. Здесь мы её целиком не разворачиваем: нам важен прикладной уровень, где удержание инвариантов делает длительную работу воспроизводимой. Подробное описание рамки — в отдельной статье: [https://habr.com/ru/articles/969888/].

Чтобы не спорить на уровне впечатлений, ниже мы фиксируем два теста и критерии успеха. Они показывают два типовых класса дрейфа: формальный успех при смысловом провале (когда preflight включается только после «пинка») и жанровую реконструкцию вместо дисциплины границ образца (scope/assumptions).

Кейсы

Мини‑таблица тестов.

Тест 1. «Вовлечённость»: когда структура держится, а смысл уезжает

Что мы проверяем

Мы проверяем не «синонимы» и не «словарь», а способность системы распознать невыполнимость/смысловой конфликт до генерации и сообщить об этом заранее (preflight). Здесь и проходит граница между разовой генерацией и длительной работой: ограничения нужно проверять до генерации, а не после формально успешного ответа.

Постановка

Модель получает формализованную задачу по внедрению ежеквартальной оценки вовлечённости (фиксированная структура, счётчики, запреты, итеративное выполнение «раздел за шаг»). В этой части baseline ведёт себя дисциплинированно: держит порядок и счётчики.

Далее добавляется «шок»: просьба дать 10 синонимов слова «вовлечённость». Формально задача выполнима («нужно 10 пунктов»), но семантически часто ведёт к дублям/словоформам и смещению смысла.

Наблюдение (baseline)

Baseline сначала закрывает формальный счётчик («10 пунктов»), а предупреждение о границах выполнимости появляется после замечания пользователя. То есть preflight не включается до генерации: система сначала выдаёт результат, а затем объясняет, почему требование в строгом виде некорректно.

После замечания пользователя («много одинаковых синонимов…») модель признаёт проблему («поймал меня на ленивом словесном жонглировании») и только после этого добавляет ключевую оговорку: «для слова „вовлеченность“ почти нет 10 абсолютно равных синонимов без сдвига смысла.»

Что считаем успехом

Успех = preflight до генерации (до выдачи списка): модель заранее фиксирует, что «10 строгих синонимов» недостижимо без сдвига смысла, и предлагает корректную декомпозицию (например, «5–7 строгих + 3–5 близких по смыслу с пометками»).

Вывод

Формализованный промпт стабилизирует структуру, но не гарантирует семантическую дисциплину «перед выполнением». Поэтому непрерывность контекста важна как режим работы: фиксировать инварианты и включать проверки выполнимости воспроизводимо, а не по настроению модели.

Тест 2. «Должностная инструкция»: жанровая реконструкция вместо следования образцу

Что мы проверяем

Способность системы:

• отделить наблюдаемое в образце от «того, что обычно бывает в жанре»;

• маркировать допущения до генерации (assumption marking);

• не подменять «следовать образцу» на «восстановить канон».

Постановка (вход намеренно неполный)

Мы даём файл, обозначенный как «шаблон ДИ», но в файле фактически есть только фрагмент: раздел обязанностей (3.1–3.8). Это сделано намеренно: тест проверяет не угадывание, а фиксацию границ данных.

Да, это намеренная провокация неполноты: тест на границу данных, не на угадывание.

Наблюдение (baseline)

Модель:

• корректно считывает паттерн фрагмента (3.1–3.8, «в части…», процессные глаголы),

• затем достраивает остальное по типовой схеме жанра и некоторое время ведёт себя так, будто это следует из шаблона, а не является допущением.

На уточняющий вопрос пользователя «это же не должностная инструкция как таковая, откуда тогда другие разделы?» модель прямо фиксирует границу данных: в исходном файле был только раздел 3 с обязанностями, а остальные разделы она взяла не из файла, а достроила по умолчанию из собственной типовой модели жанра, опираясь на формулировку «образец ДИ», название файла и «стандартную практику».

Далее модель раскладывает ошибку как цепочку: слишком быстро приняла метку пользователя за факт структуры, не проверила границы образца, смешала наблюдаемое с типовой схемой жанра, приняла список переменных A‑I как подтверждение полной формы документа и начала собирать «полноценную инструкцию», а не переносить наблюдаемый шаблон.

Что считаем успехом

Успех = scope check + assumption marking до генерации:

• «В образце вижу только раздел обязанностей; остальные разделы отсутствуют.»

• «Могу: (а) сделать только раздел 3 по образцу, или (б) достроить полный документ по типовой структуре; (б) будет допущением.»

Вывод

Модель воспринимает нехватку данных не как ограничение, а как повод достроить недостающее по умолчанию.

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

В этом кейсе ошибка не в фактах, а в том, что допущение было выдано за наблюдаемое. Модель не отделила «что реально присутствует в предъявленном образце» от «того, что обычно бывает в документе данного жанра». Вместо scope check она приняла метку пользователя («шаблон должностной инструкции») как подтверждение полной структуры и автоматически достроила отсутствующие разделы по типовой схеме, не маркируя допущения до генерации. Набор переменных A‑I был интерпретирован как подтверждение структуры, хотя он не следовал из содержания образца. Итоговый текст выглядел правдоподобно, но являлся жанровой реконструкцией, а не строгим следованием предъявленному шаблону.

Непрерывность контекста

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

Непрерывность нужна не для «памяти фактов», а для памяти решений. Факты можно уточнить или подгрузить; решения должны оставаться частью контекста, иначе следующий шаг начинает жить в другой рамке. В длинных задачах это проявляется как расползание терминов и незаметное переопределение уже согласованного.

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

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

Мини‑стандарт непрерывности контекста

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

• Scope check
  Перед выполнением задачи система фиксирует, достаточно ли данных, и что именно дано: «входной образец содержит X, не содержит Y».

• Assumption marking
  Если чего‑то не хватает, система явно маркирует допущения до генерации: что именно она собирается достроить «по умолчанию» и почему. Никаких «как будто так и было».

• Stop‑the‑line / Recovery
  При дрейфе (конфликт требований, потеря границ образца, формальный успех при смысловом провале) система не продолжает как ни в чём не бывало, а переключается в режим диагностики: фиксирует, что сломалось, и предлагает восстановление рабочего состояния (уточнение, пересборка рамки, откат к последнему валидному решению).

На практике мы удерживаем непрерывность не «памятью чата», а переносимыми стандартами взаимодействия. В нашем проекте эту функцию выполняет PSM (Pattern Save Module) — реально работающий модуль, который закрепляет удачные режимы работы в виде паттернов и затем применяет их в следующих задачах. В PSM мы фиксируем не «всё подряд», а то, что делает длительную работу воспроизводимой: инварианты (что нельзя нарушать), реестр решений (что уже принято), правила допущений (где мы имеем право достраивать и как это маркируем), а также устойчивые форматы вывода (структуры документов, порядок разделов, язык формулировок).

Проще говоря, PSM переносит между задачами не весь прошлый диалог, а его рабочий минимум: цель, инварианты, принятые решения, правила допущений, схему результата и правила восстановления. В псевдоструктуре это выглядит так: goal; invariants; accepted_decisions; assumptions_policy; output_schema; recovery_rules.

Отдельно диагностику дрейфа и механизм восстановления мы разбираем в статье про SDX‑S: [https://habr.com/ru/articles/985334/].

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

Практический кейс: серийная работа без переинициализации

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

Что мы проверяем

Здесь мы проверяем не качество одного ответа, а переносимость режима работы: сохраняются ли инварианты и стандарт сборки при переключении между артефактами и задачами, и можно ли продолжать работу без повторной ручной «инициализации» контекста.

Постановка

В 13:00 получено задание подготовить положения о подразделениях. Параллельно обсуждалась часть статьи. Затем работа переключилась на документы: уточнили структуру, сверили с типовым шаблоном, перенесли форматирование и правила оформления из ранее собранных должностных инструкций. К 15:00 материалы были собраны и переданы на согласование.

Наблюдение

Процесс шёл как последовательность «анализ → карта → шаблон → серия документов» без распада рамки. Сохранялись структура, стиль, порядок разделов и правила формулировок; переносились ограничения «что не включать». По ходу возникали локальные отклонения и инструментальные сбои, но они не приводили к пересборке с нуля: линия работы восстанавливалась на основе закреплённых инвариантов. На практике переносились конкретные вещи: единая структура положений, единый порядок разделов, единый формат реквизитов/шапки, правила допущений (где можно достраивать, а где нужно уточнять). Инструментальный сбой фиксировался как сбой среды и обходился продолжением работы в текстовом режиме без пересборки результата с нуля.

Что считаем успехом

Успех здесь это:

• сохранение единой структуры и стандартов между разными документами;

• перенос инвариантов и реестра решений без повторных «вводных» на каждом шаге;

• локальное восстановление после отклонений без обнуления процесса;

• получение согласуемого результата в заданный срок.

Вывод

На двух кейсах видно два типовых класса сбоев, которые возникают без непрерывности контекста. Первый: формальный успех при смысловом провале, когда система закрывает счётчик, но не включает проверку выполнимости до выдачи результата. Второй: жанровая реконструкция вместо следования образцу, когда недостающие данные не признаются ограничением и «достраиваются по умолчанию» без маркировки допущений. Оба сбоя опасны тем, что выглядят правдоподобно и поэтому легко проходят незамеченными.
Практический вывод простой: если вы строите процесс, а не разовую демонстрацию, вам нужен не мегапромпт, а устойчивый режим взаимодействия. Минимальный стандарт, который даёт ощутимый эффект даже без тяжёлой инженерии, выглядит так: scope check (достаточно ли данных), assumption marking (что именно достраиваем и почему), stop‑the‑line/recovery (при дрейфе не продолжаем «как ни в чём не бывало», а возвращаемся к валидному состоянию).
Даже если задачи чаще одношаговые, это всё равно важно там, где работа повторяется между сессиями. На короткой дистанции можно жить в режиме «запрос → ответ», но на длинной — в другой день, в другой сессии, в ином фоне контекста — поведение модели становится менее устойчивым, а воспроизводимость результата вызывает вопросы. Непрерывность контекста нужна здесь как страховка от такой нестабильности: чтобы фиксировать инварианты и решения, явно маркировать допущения и не собирать рабочую рамку заново при каждом новом заходе.