Перейти к основному содержимому

Этапы конвейера

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

Порядок этапов​

Порядок фиксирован и одинаков для каждой генерации:

User input
→ Macros
→ Character/persona data
→ Lorebook
→ Memory/RAG
→ Token counting
→ Context shifting
→ Plugin interceptors
→ Instruct format rendering
→ Provider serialization
→ Request
→ Streaming response
→ Post-processing hooks
→ Save message

Этап за этапом​

  1. Ввод пользователя — фиксируются черновик сообщения и параметры генерации для этого запроса.
  2. Макросы — {{user}}, {{char}} и пользовательские переменные разрешаются через replaceMacros. Неизвестные макросы остаются как есть.
  3. Данные персонажа/персоны — поля карточки персонажа и активная персона собираются в массив сообщений.
  4. Лорбук — совпавшие записи лорбука вставляются согласно их правилам активации. Записи, помеченные как обязательные, защищены от удаления.
  5. Память/RAG — блоки памяти и векторного поиска извлекаются и ранжируются.
  6. Подсчёт токенов — локальный профиль токенизатора считает собранный контекст.
  7. Контекст-шифтинг — контекст вписывается в бюджет токенов. См. Контекст-шифтинг.
  8. Перехватчики плагинов — плагины могут просматривать и изменять массив сообщений. После последнего перехватчика конвейер пересчитывает токены и повторно применяет бюджет, поэтому ни один плагин не может его обойти.
  9. Рендер instruct-формата — чистый массив сообщений рендерится в выбранный instruct-формат или остаётся структурированным. См. Instruct-форматы.
  10. Сериализация провайдера — адаптер строит запрос провайдера: чат-адаптеры получают структурированный массив сообщений, текстовые — отрендеренную строку промпта.
  11. Запрос — запрос отправляется с AbortSignal, таймаутами и обработкой отключения клиента.
  12. Стриминг ответа — ответ стримится по SSE. Необязательный assistantPrefill добавляется в начало первой дельты ровно один раз.
  13. Хуки пост-обработки — плагины могут обработать стриминговый ответ до его сохранения.
  14. Сохранение сообщения — финальное сообщение, его варианты и метаданные генерации сохраняются одной транзакцией.

Правила хуков​

Каждый хук плагина определяется одним и тем же контрактом:

  • Порядок и приоритет — хуки выполняются по приоритету; равные приоритеты упорядочиваются детерминированно.
  • Таймаут — у каждого хука есть таймаут. Превысивший его хук прерывается.
  • Отмена — хуки получают AbortSignal генерации и должны прекращать работу при его срабатывании.
  • Разрешения — хук выполняется, только если плагин обладает разрешениями, которые требуют его объявленные возможности.
  • Изоляция исключений — ошибка в хуке одного плагина перехватывается, логируется и пропускается. Конвейер продолжает работу; сломанный перехватчик никогда не должен молча ломать всю генерацию.
  • Диагностический журнал — каждое изменение промпта записывается. Журнал изменений возвращается в диагностике генерации и хранится в meta ответного сообщения, поэтому всегда видно, что именно было отправлено.

Пост-обработка промпта​

В чат-режиме массив сообщений перед сериализацией может пройти через необязательный этап пересборки — перенос классического алгоритма mergeMessages. Режимы включают merge, semi, strict и single, плюс варианты _tools, сохраняющие сообщения инструментов. В текстовом режиме этот этап пропускается, потому что instruct-рендер уже свёл роли в одну строку.

См. также​