Оригинал: https://timofei-ermolaev.ru/courses/open-webui/povsednevnaya-rabota/kontekst-i-szhatie-chata/ # Контекст Open WebUI: как работает сжатие длинного чата Как устроен контекст Open WebUI, когда работает Compaction и что сохраняет /compact. Проверяем важное условие по исходнику и возвращаем его в разговор. [![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_Z1x8STQ.webp)]() [Тимофей Ермолаев]() Директор по информационным технологиям (CIO) **Опубликовано** 22 октября 2026 г. **Обновлено** 22 октября 2026 г. **На урок** 20 мин **Тема** [Повседневная работа и контекст]() ## После урока вы сможете - Различать сохранённую историю, текущий вход модели и настроенное контекстное окно - Понимать условия автоматического сжатия и ручной команды /compact - Читать оценочный индикатор без обещаний точного остатка или экономии - Сверять важное условие с первоисточником и проверять фактический ответ **Проверяемый результат:** Находим исходное условие, при необходимости возвращаем его в разговор и проверяем полученный ответ. Когда вы долго обсуждаете одну задачу в чате, например по шагам правите формулировки объявления для книжного клуба, первые сообщения продолжают отображаться на экране при прокрутке. Из-за этого легко решить, что вся видимая переписка служит постоянной памятью модели. На самом деле хранение чата в интерфейсе и передача данных для очередного ответа устроены по-разному. При каждом вашем сообщении Open WebUI заново собирает запрос конечного размера. Если разговор разрастается, в этот запрос может вмешаться механизм сжатия (Compaction): он оставляет старые реплики в сохранённой истории чата для человека, но во входе модели заменяет часть прошлой переписки краткой сводкой. Поскольку любой краткий пересказ способен упустить отдельное условие, при продолжении длинной работы нужно знать, как формируется текущий вход модели, по каким правилам запускается сжатие и как сверить нужную деталь с первоисточником. ## Что модель получает вместе с новым сообщением Контекст запроса в Open WebUI включает все сведения, которые система отправляет модели для генерации одного конкретного ответа. Объём этого пакета измеряется в токенах — элементарных фрагментах текста, на которые модель разбивает входные и выходные данные, причём жёсткого коэффициента пересчёта токенов в русские слова не существует. В этой работе участвуют три стороны: человек видит на экране сохранённую переписку, Open WebUI собирает из доступных данных очередной запрос, а языковая модель отвечает исключительно по тому входу, который ей фактически поступил ([документация Open WebUI по контекстному окну]() , [общая схема архитектуры и пути сообщения]() ). В собранный вход попадает не только ваша последняя реплика. Туда входят текущая активная ветка диалога, системные инструкции, прикреплённые материалы, а также описания подключённых инструментов и результаты их работы, если они задействованы в выбранном режиме ([обработчик запросов middleware.py]() ). Активная ветка означает только выбранную цепочку реплик, по которой вы сейчас ведёте разговор, а не все альтернативные [ветки и варианты диалога]() , сохранённые в базе данных. Если в разговоре уже срабатывало сжатие или применялась дополнительная фильтрация, состав передаваемой истории тоже меняется. Объём сохранённого чата в интерфейсе, заявленное разработчиками максимальное [контекстное окно модели]() и фактически выделенный сервером контекст обозначают разные величины. Модель может поддерживать сотни тысяч токенов по паспорту, но локальный сервер или провайдер нередко ограничивает рабочий размер окна меньшим значением. Например, в серверной части Ollama длина контекста настраивается отдельно, и её увеличение напрямую повышает расход памяти ([документация Ollama по длине контекста]() , [параметры чата в документации Open WebUI]() ). Универсального безопасного числа токенов нет, а поднимать серверный лимит до паспортного максимума модели без учёта доступных ресурсов не стоит. Порог срабатывания Compaction при этом задаётся отдельно от окна сервера и определяет лишь момент попытки сжать историю. От механизма Compaction также нужно отличать пользовательскую память и поиск по прикреплённым файлам (retrieval). Память и поиск могут подставлять найденные фрагменты в собираемый запрос, но сводка Compaction работает только внутри активной ветки конкретного чата: она не превращается в общую память пользователя для других диалогов и не даёт модели прямого доступа ко всем загруженным документам. ## Как Compaction заменяет историю сводкой Если функция сжатия включена и срабатывает в вашем диалоге, процесс проходит через три состояния. Сначала в чате есть исходная активная история сообщений. Затем механизм отделяет старый блок реплик для пересказа от более свежих сообщений, которые должны остаться нетронутыми. На следующем шаге модель получает обновлённый вход: вместо старого блока в системный контекст подставляется сгенерированная сводка с внутренней служебной пометкой `[CONVERSATION SUMMARY]`, а следом идут оставшиеся недавние сообщения и ваш новый вопрос ([модуль context\_compaction.py]() ). Эту служебную пометку формирует сама система при сборке запроса, вводить её вручную в чат не нужно. При этом старые реплики не удаляются из базы данных и не исчезают с экрана. В сохранённой истории чата вы по-прежнему видите весь разговор целиком, но для сборки последующих запросов Open WebUI ставит в активной ветке сохранённую контрольную точку (checkpoint) со сводкой и начинает отсчёт передаваемых сообщений от неё ([описание работы контекстного окна и сжатия]() ). Технический способ записи такой точки зависит от пути обмена и режима работы инструментов, но для пользователя суть одна: полная переписка остаётся в архиве на экране, а в рабочий вход модели уходит пересказ прошлой части плюс хвост из недавних реплик. Разные элементы запроса ведут себя при сжатии неодинаково. Начальное системное сообщение удерживается отдельно, а описания инструментов, навыки и заново подставляемые материалы собираются на своём этапе формирования запроса. Старые же результаты вызовов инструментов, оказавшиеся внутри сжимаемого блока сообщений, во входе модели могут остаться только в виде краткого пересказа внутри сводки, хотя из сохранённой истории чата они не удаляются. Само по себе сохранение системных инструкций и повторная подстановка материалов не означают, что они перестают расходовать токены или гарантированно поместятся в окно при любом объёме. Главное следствие этого механизма связано с точностью деталей. Сводка создаётся моделью по инструкции составить краткий пересказ с сохранением важных решений и ограничений, но это сгенерированный текст, а не дословная копия. В любом пересказе отдельные числа, условия или оговорки могут сократиться или измениться. Если разговор продолжается долго и сжатие запускается повторно, генератор новой сводки получает на вход предыдущую сводку вместе с накопившимися сообщениями, а не перечитывает заново все самые первые реплики чата. Потерянная однажды деталь в цепочке пересказов сама собой не восстановится. ## Когда сжатие запускается само и что делает /compact Приведённые ниже правила и значения проверены для обычного Open WebUI стабильного релиза [v0.12.3 от 16 октября 2026 года]() по исходному коду и документации на 21 октября 2026 года (UTC). В вашей установленной версии названия пунктов, переводы интерфейса и доступность функций могут отличаться. В релизе v0.12.3 функция Compaction по умолчанию выключена ([конфигурация config.py]() ). Здесь разделяются права администратора и действия обычного пользователя. Включить Compaction и задать общие лимиты для сервера может только администратор в разделе `Settings → Admin → Interface` ([компонент настроек Interface.svelte]() , [маршруты чатов chats.py]() ). Обычному пользователю для работы или выполнения практики этого урока менять глобальные настройки не нужно: достаточно знать, включена ли функция в вашей системе. Если администратор включил Compaction, у владельца собственного уже сохранённого чата появляются два разных пути сжатия: автоматический и ручной через команду `/compact` ([документация встроенных slash-команд]() , [интерфейс чата Chat.svelte]() ). Для запуска `/compact` в своём чате права администратора не требуются, но разговор должен быть сохранённым (не временным), после последней точки сжатия в активной ветке должно быть минимум два сообщения, а текущий ответ модели должен полностью завершиться. Если вызвать ручное сжатие во время активной генерации ответа, сервер вернёт ошибку конфликта (`409`). Два режима сильно отличаются тем, когда они срабатывают и какую часть переписки оставляют без сжатия: | Условие | Автоматическое сжатие | Ручная /compact | | --- | --- | --- | | Запуск | При превышении порога токенов и наличии допустимой границы разделения | По явной команде владельца сохранённого чата после завершения ответа | | Пересказываемый блок | Старая часть активных сообщений до найденной границы разделения | Все активные сообщения после последней точки сжатия, кроме последнего единственного | | Несжатый остаток во входе модели | Целевая доля недавних сообщений с учётом ограничений целостности хода | Последнее единственное активное сообщение | Автоматическая проверка запускается в начале обработки запроса в сохранённом чате, а также между раундами встроенного цикла вызова инструментов (native tool loop). Исключение составляют запросы через stateful Responses API с передачей `last_response_id`: там межраундовая проверка идёт по отдельной ветке и автоматическое сжатие не вызывает ([логика обхода в middleware.py]() ). На временные чаты или произвольные прямые вызовы API всех типов это поведение также не переносится автоматически. Чтобы автоматическое сжатие состоялось, оценки объёма должны превысить порог, в активной ветке после последней контрольной точки должно быть больше трёх несистемных сообщений, а алгоритм должен найти корректную границу разреза. Параметр `Retained Messages` задаёт целевую долю сохраняемых недавних сообщений: по умолчанию это `40%` именно по числу сообщений, а не по числу токенов, с настраиваемым диапазоном от `10%` до `50%` и сохранением как минимум двух сообщений ([алгоритм границ в context\_compaction.py]() ). Точная доля в конкретном чате может отличаться от целевых 40%, потому что система не разрезает переписку в случайном месте, а сдвигает границу к началу хода пользователя или связанного пакета вызовов инструментов. В ручном режиме `/compact` ни процент `Retained Messages`, ни порог токенов не используются вовсе: в сводку уходят все активные сообщения, кроме самого последнего. Глобальный порог срабатывания автоматического режима (`Token Threshold`) по умолчанию в коде v0.12.3 равен `80000`. Серверный параметр `Token Cap` служит верхней границей для порога Compaction, а не физическим окном модели или сервера: если `Token Cap` не задан, вместо него берётся глобальный `Token Threshold`, после чего любой порог — включая индивидуальный `compact_token_threshold` для конкретной модели или чата — ограничивается сверху этим потолком. Число `80000` представляет собой лишь программное значение по умолчанию в коде релиза, а не размер окна вашей модели и не готовую безопасную рекомендацию для любой установки. При реальной работе порог должен оставлять запас под сам генерируемый ответ и подставляемые материалы с учётом фактической ёмкости вашего подключения. ## Как читать индикатор контекста и ошибку лимита Индикатор заполнения контекста в интерфейсе Open WebUI служит ориентиром, а не точным прибором учёта ([расчёт оценки в context\_compaction.py]() , [отображение в Chat.svelte]() ). Когда провайдер модели возвращает данные о расходе токенов (`usage`) за прошлый шаг, система берёт это последнее известное значение и прибавляет к нему приблизительную оценку новых сообщений; если данных от провайдера нет, весь объём оценивается эвристически по длине текста и надбавкам за вложения. Во всех случаях источник этого числа в коде помечен как оценочный (`estimated`). Процент на индикаторе считается относительно порога Compaction, а не относительно реального максимума контекстного окна вашей модели или биллингового счётчика провайдера. При этом порог уровня модели или чата, который использует интерфейс, может отличаться от эффективного серверного порога, ограниченного сверху `Token Cap`. Поэтому по индикатору нельзя вычислять точный остаток свободных токенов на сервере или проверять стоимость запросов. О том, что собранный вход действительно превысил доступный лимит контекста модели или сервера, говорят явные сообщения об отказе провайдера: `prompt too long` или `context length exceeded` ([раздел диагностики в документации контекстного окна]() ). Если вы столкнулись с таким отказом, стоит проверить реальный лимит контекста вашего подключения и состав текущего запроса — например, объём истории, системных инструкций или прикреплённых файлов, — вместо того чтобы наугад менять порог сжатия или требовать безусловного увеличения окна сервера. Напротив, если запрос прошёл без ошибки, но модель забыла одно из старых условий или неудачно сформулировала мысль, сам по себе такой ответ переполнения окна не доказывает. Причиной может быть обычное поведение генерации на длинном тексте, настройки ответа или пропуск детали при пересказе. В этой ситуации не нужно ставить диагноз по одному неудачному абзацу: достаточно сверить ответ с исходными фактами. ## Почему сводка не даёт бесконечного контекста и бесплатного продолжения Каждая попытка сжать переписку требует отдельной работы языковой модели. Когда запускается Compaction, Open WebUI формирует специальный нестриминговый запрос на суммаризацию, куда передаёт блок сжимаемых сообщений, недавние реплики и предыдущую сводку, если она уже была ([вызов генерации сводки в context\_compaction.py]() , [документация фоновых моделей задач task-models.mdx]() ). При автоматическом сжатии в начале обработки сообщения пользователя только после этого шага система отправляет основной запрос для получения ответа, а в цикле работы с инструментами за сжатием следуют очередные раунды (сама ручная команда `/compact` строит сводку отдельно и генерацию нового ответа не запускает). Один вызов суммаризатора относится к одной попытке построения сводки, не считая возможных сетевых повторов или других фоновых задач. Для построения сводки в v0.12.3 система выбирает специально заданную модель `CONTEXT_COMPACTION_MODEL`, если она указана в настройках и доступна в списке моделей; в противном случае суммаризацию выполняет текущая модель вашего чата. Общие фоновые модели `TASK_MODEL` и `TASK_MODEL_EXTERNAL` в качестве резервного варианта на этом пути не используются. Сокращение передаваемой истории может уменьшить объём последующих запросов, но само создание сводки тратит время, вычислительные ресурсы локального сервера или токены внешнего провайдера. Гарантировать итоговую финансовую или ресурсную экономию заранее нельзя: результат зависит от тарифов, работы кеширования у провайдера и того, сколько ещё сообщений вы отправите в этом чате после сжатия. Параметры генерации самой сводки зависят от настроек параметров фоновой задачи и выбранной модели. Сводка остаётся кратким сгенерированным пересказом, ограниченным этими настройками, а не точной копией всех фактов фиксированной длины. Числа, исключения и конкретные формулировки при таком сжатии требуют внимания человека, особенно если за время беседы сменилось несколько последовательных сводок. Наконец, Compaction не гарантирует, что запрос всегда поместится в окно модели ([обработка отказов в middleware.py]() ). Механизм спроектирован так, чтобы не блокировать чат при сбоях, но у этого есть три прямых следствия: - если в активной переписке не нашлось допустимой границы для разделения сообщений, сжатие просто пропускается; - если запрос на суммаризацию завершился ошибкой, система продолжает обычный запрос с полной несжатой историей; - если модель-суммаризатор вернула пустой ответ, вместо осмысленного резюме собирается механическая склейка из обрезанных фрагментов старых сообщений. Во всех этих случаях итоговый вход может оказаться слишком большим и вызвать ошибку лимита у провайдера. Поэтому сжатие помогает продолжать длинный разговор, но ответственность за сохранность важных условий задачи остаётся у человека. ## Как вернуть важное условие в длинный разговор Посмотрим, как контролировать детали на одной сквозной задаче из прошлого урока, где мы разбирали [параметры ответа и режим рассуждений]() . Допустим, в начале сохранённого чата вы передали модели карточку с исходными фактами для короткого объявления книжного клуба, а затем долго обсуждали тон и порядок фраз. Исходная карточка фактов в начале разговора выглядит так: - **Когда:** суббота, 15:00–16:00. - **Где:** библиотека, зал 2. - **Что происходит:** обсуждение уже прочитанной книги (название не задано). - **Условия участия:** можно прийти впервые, регистрация не нужна. - **Неизвестно и не должно выдумываться:** стоимость участия, контакты организаторов, календарная дата, точный адрес и название книги. Ниже приведена условная учебная схема краткой сводки — это намеренно неполный авторский пример для разбора, а не реальный ответ модели и не прогноз того, что именно потеряет Compaction: > Готовим короткое объявление: встреча книжного клуба в субботу, 15:00–16:00, библиотека, зал 2. Обсуждаем прочитанную книгу. Если сопоставить эту схему с исходной карточкой, сразу виден пропуск: время, место и тема встречи сохранились, но исчезли оба условия участия («можно прийти впервые» и «регистрация не нужна»). Поскольку исходное сообщение с карточкой никуда не исчезло из сохранённой истории чата или ваших заметок, вы можете быстро сверить пересказ или очередной черновик объявления с первоисточником и заметить потерю до завершения работы. Чтобы вернуть пропущенные сведения в активный вход модели, достаточно отправить в чат новое уточняющее сообщение с опорой на карточку. Например, ваш запрос может быть таким: > По исходной карточке на встречу можно прийти впервые, регистрация не нужна. Сохрани оба условия в объявлении вместе со временем и местом. Не добавляй стоимость, адрес или название книги: этих сведений в карточке нет. Такое повторение условия тоже расходует часть текущего контекста и не гарантирует безошибочной генерации или сохранения детали при последующих сжатиях, но оно заново сообщает проверенный факт в текущем разговоре для очередного ответа. Когда модель пришлёт обновлённый вариант, проверьте сам текст объявления по всем пунктам карточки, включая отсутствие выдуманных деталей. Короткая реплика ассистента вроде «учёл» или «исправил» самостоятельным доказательством не служит: оценивается только фактический текст результата. Вы можете применить этот порядок проверки в своём рабочем чате независимо от того, включён ли у вас Compaction. Если функция сжатия на вашем сервере выключена или недоступна, специально раздувать чат лишними сообщениями, просить права администратора или менять глобальный порог ради тренировки не нужно: выполните обычную сверку по исходнику и передайте уточнение новым сообщением. Помните только, что такое ручное уточнение остаётся обычной репликой человека в чате, а не запуском встроенного механизма Compaction, и не заменяет отдельные инструменты памяти или поиска по файлам. Порядок самостоятельной проверки укладывается в пять коротких шагов: 1. Сохраните исходную карточку фактов в первом сообщении чата или в отдельной заметке под рукой. 2. Выделите условие, которое обязательно должно войти в итоговый текст, и проверьте, где именно оно записано в исходнике. 3. Если в сводке или очередном ответе это условие пропало, отправьте новое сообщение с точным возвратом факта и запретом додумывать неизвестное. 4. Дождитесь нового ответа и сверьте сам готовый текст со всеми известными и неизвестными пунктами карточки. 5. Зафиксируйте для себя результат проверки по трём полям ниже (публиковать или отправлять само объявление никуда не требуется). Запись результата проверки: - **Источник и проверяемое условие:** где зафиксирован факт и какая именно деталь проверялась (например, первоначальная карточка в чате: «можно прийти впервые, регистрация не нужна»). - **Переданное уточнение:** какой текст вы отправили новым сообщением для возврата условия в разговор (или отметка «не выполнялось», если вы разбирали урок без отправки запроса). - **Проверка фактически полученного ответа:** присутствуют ли в новом тексте все нужные условия, сохранены ли время и место, не появились ли неизвестные данные вроде цены или адреса (или отметка «не выполнялось»). Такое разделение ролей помогает спокойно вести длинные диалоги в Open WebUI: сохранённая история чата остаётся вашим архивом для сверки, а Compaction удерживает разговор в рамках рабочего входа. Для следующей собственной несекретной задачи держите исходное условие под рукой, при необходимости верните пропущенную деталь коротким уточнением и проверьте фактический текст ответа; если пробу сейчас не запускали, оставьте в записи отметку «не выполнялось», не подменяя свой результат учебной схемой из урока. Отдельные записи предпочтений, их проверку и удаление разбираем в уроке [о памяти и персонализации Open WebUI]() . ## Материалы урока - [Параметры ответа и режим рассуждений timofei-ermolaev.ru]() - [Контекстное окно модели timofei-ermolaev.ru]() ## Отметить прохождение Отметьте урок после того, как получили проверяемый результат из практической части. Урок пройден ![Тимофей Ермолаев](https://timofei-ermolaev.ru/_astro/timofei-ermolaev-portrait.s0mCFw-J_2r7Nkv.webp) ## Об авторе ### Тимофей Ермолаев Директор по информационным технологиям (CIO) Пишу о больших языковых моделях, автоматизации и применении ИИ в бизнесе. В статьях разделяю личный опыт, выводы исследований и практические рекомендации. [Подробнее об авторе]()