1. Нормализация и план

Статус: реализовано в Workbench v0.6.0. Общая схема находится в разделе «AI Workbench: подготовка данных».

Цель этапа — превратить естественную реплику в проверяемый граф задач. На этом шаге Workbench ещё не ищет доменные документы и не собирает итоговый prompt.

Вход

Этап получает:

• неизменяемый текст текущего сообщения;
• идентификаторы Conversation и Interaction;
• ограниченный набор релевантных сообщений истории;
• открытое уточнение, если Workbench продолжает ранее сохранённый Interaction.

Исходный текст никогда не перезаписывается нормализованной формой. Оба представления сохраняются: оригинал нужен для смысла, нормализованная форма — для поиска.

Детерминированная нормализация

Workbench формирует NormalizedRequest:

{
  "originalText": "Покажи „Пример композиции Альфа“ и его Store",
  "normalizedText": "покажи „пример композиции альфа“ и его store",
  "quotedMentions": ["Пример композиции Альфа"],
  "identityLikeTokens": [],
  "commandTokens": ["покажи"],
  "referenceTokens": ["его"]
}

Операции нормализации идемпотентны: повторная обработка даёт тот же результат.

Первичный parser

Parser выделяет гипотезы, а не утверждённые факты:

• возможные intent;
• типы целевых сущностей;
• текстовые упоминания;
• команды и запрашиваемый результат;
• возможные зависимости между частями запроса.

Строка вида example-composition-alpha повышает вероятность identity, но не доказывает его. Слово «папка» задаёт вероятную область поиска, но не доказывает, что пользователь ищет Composition.

Декомпозиция задач

Первичный parser делит запрос по поддерживаемым связкам «затем»/«после этого», точкам и ;. Если такое разбиение или ссылка на историю неоднозначны, окончательную структуру предлагает Planner. Каждая задача содержит:

{
  "id": "task-2",
  "intent": "inspect_entity",
  "sourceMode": "domain",
  "mentions": [],
  "requestedAspects": [],
  "dependsOn": ["task-1"],
  "confidence": 0.93,
  "status": "planned"
}

Граф не может содержать циклы, ссылки на неизвестные задачи или intent вне реестра.

Planner gate

LLM Planner не вызывается для одного однозначного запроса без ссылок на историю. Вызов разрешён, когда:

• детерминированный parser выделил несколько задач;
• между задачами есть неявная зависимость;
• важна ссылка на историю;
• пользователь неявно исправляет предыдущую задачу.

Planner получает оригинал, нормализованную форму, реестр intent и минимально необходимую историю. Он не получает весь ExportLive.

Если adapter поддерживает строгую схему, выход Planner ограничивается ею. Иначе JSON разбирается и валидируется Workbench. Допустима не более одной попытки исправить структуру.

Выход этапа

Этап завершается одним из результатов:

• planned — граф задач валиден;
• unsupported — намерение вне реестра возможностей;
• fallback к валидному детерминированному плану — Planner или его repair не вернул допустимую структуру.

Уточнение формируется на следующих gates, когда невозможно разрешить сущность или подтвердить достаточность контекста.

Следующий этап: «Источники и извлечение».