15 KiB

Raw Permalink Blame History

Да, это разумный ход.

Ты сейчас предлагаешь не добивать eval в вакууме, а замкнуть рабочий контур:

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

И это реально полезнее следующего слоя “искусственной чистоты”, потому что вы уже уткнулись в потолок слепых прогонов.

Что фиксируем по стратегии

1. Разметку не отменяем, а ставим на паузу

Не выбрасываем идею, а откладываем до появления 30–40 реальных полевых вопросов.

То есть:

synthetic eval остаётся как вспомогательный контур;
основной следующий шаг — не policy-lab, а рабочий диалоговый режим.

2. Новая цель этапа

Не “ещё лучше понять язык на тестах”, а: собрать первый end-to-end assistant loop поверх уже существующей decomposition-логики.

3. Что даст этот этап

Он даст не абстрактные проценты, а понимание:

как вообще ощущается система в диалоге;
где она тупит реально;
где поиск не дотягивает;
где ответ не собирается;
где декомпозиция полезна;
где интерфейс мешает;
где нужен второй проход LLM на финальную сборку ответа.

И вот это уже будет очень ценная конкретика.

ТЗ: переход к диалоговому режиму поверх текущего decomposition-контура

1. Цель этапа

Добавить в текущую тестовую GUI второй режим работы — Assistant Mode, чтобы можно было:

задать вопрос в диалоговом интерфейсе;
прогнать его через текущую decomposition / normalization pipeline;
выполнить поиск/маршрутизацию по существующим путям;
собрать ответ;
показать ответ в человекочитаемом диалоговом формате.

Текущий режим decomposition/debugging при этом сохраняется.

2. Что фиксируем как решение

Решение

На текущем этапе:

останавливаем расширение synthetic-разметки и synthetic-eval;
не тратим время на дальнейшие искусственные прогоны без боевых вопросов;
переключаемся на сборку диалогового рабочего контура;
позже, после получения полевых вопросов, возвращаемся к:
- разметке,
- policy eval,
- уточнению маршрутов и fallback’ов.

Комментарий: Это не отказ от eval-подхода. Это смена приоритета: сначала — usable loop, потом — field-based hardening.

3. Что должно получиться на выходе

В GUI должны быть доступны два режима:

A. `Decomposition Mode`

Сохраняется текущий debug-режим:

raw input;
decomposition output;
fragments;
flags;
route status;
fallback status;
trace/debug панели.

B. `Assistant Mode`

Новый диалоговый режим:

чатоподобное окно;
ввод сообщения;
отправка сообщения;
выполнение pipeline;
получение итогового ответа;
отображение ответа как сообщения ассистента;
опционально раскрытие технических деталей.

4. Главная идея Assistant Mode

Assistant Mode не должен быть “просто ещё одним текстовым полем”.

Он должен работать как поверхностный пользовательский интерфейс над уже существующей внутренней логикой:

User message → decomposition → scope filter → route → retrieval/query → answer composition → assistant reply

Важно:

decomposition слой остаётся;
deterministic routing остаётся;
fallback policy остаётся;
просто поверх этого появляется человеческий вход и человеческий выход.

5. Поведение Assistant Mode

5.1. Вход

Пользователь пишет сообщение в обычном диалоговом окне.

Примеры:

один вопрос;
длинный вопрос;
сомнение;
мягкая формулировка;
несколько связанных мыслей;
в будущем — multi-intent.

5.2. Внутренний пайплайн

После отправки сообщения система должна:

прогнать сообщение через normalizer_v2.x;
получить fragments / flags / scope;
отбросить out-of-scope части;
определить routed / no-route / clarification;
если есть исполнимые fragments — отправить их в backend retrieval/query layer;
получить промежуточные результаты;
собрать из них человекочитаемый ответ;
показать его пользователю в чате.

5.3. Выход

На экране пользователь должен видеть не JSON и не route flags, а нормальный ответ.

6. Два режима интерфейса

6.1. Переключатель режима

В интерфейсе нужен явный переключатель:

Assistant
Decomposition

Вариант реализации:

toggle;
tabs;
segmented control.

6.2. Требование

Состояние режимов должно быть разделено, но использовать общий backend.

То есть:

один и тот же backend pipeline;
разные UI-представления.

7. Assistant Mode — состав интерфейса

7.1. Основная область

Чатоподобная лента сообщений:

сообщения пользователя;
сообщения ассистента;
системные статусы по желанию.

7.2. Поле ввода

Обычное текстовое поле + кнопка отправки.

7.3. Состояния ответа

Во время выполнения показывать:

Разбираю запрос
Проверяю контур
Определяю маршрут
Ищу данные
Собираю ответ

Можно в упрощённом виде.

7.4. Дополнительная панель

Опционально:

кнопка Показать разбор
которая раскрывает:
- fragments,
- route,
- fallback,
- scope,
- trace id.

Комментарий: По умолчанию это не должно мешать диалогу, но для отладки очень полезно.

8. Логика ответа в Assistant Mode

8.1. Если вопрос in-scope и routed

Ассистент должен сформировать ответ по результатам retrieval/query.

Ответ должен быть:

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

8.2. Если вопрос требует clarification

Ассистент задаёт уточняющий вопрос в чат.

Пример:

“Могу проверить это в контуре компании, но нужно уточнить период или участок учёта.”

8.3. Если вопрос out-of-scope

Ассистент отвечает вежливым fallback’ом.

Пример:

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

8.4. Если вопрос частично in-scope

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

9. Нужен отдельный слой answer composition

Это важно.

Сейчас decomposition и routing — это ещё не финальный ответ человеку. Нужен отдельный блок:

`answer_composer`

Он получает:

исходный user message;
fragments;
route results;
retrieved data/result payloads;
fallback states;

и собирает:

один связный ответ для человека.

Комментарий: Да, ты правильно понимаешь: если исходное сообщение человека было многослойным, ответ не должен приходить как 5 несвязанных кусков JSON. Нужен второй проход на human-readable response.

10. Что не делаем сейчас

На этом этапе не делаем:

финальный production-grade assistant;
память диалога на 100 ходов;
суперсложную agent orchestration;
автоматическую доразметку eval;
полную полевую разметку synthetic наборов;
бесконечную шлифовку policy.

Сейчас задача — замкнуть usable loop.

11. Что backend должен уметь

Нужен единый assistant pipeline endpoint.

Примерно так:

`POST /api/assistant/message`

Вход:

user message
session id
mode = assistant

Внутри:

run normalizer
resolve execution state
route fragments
call retrieval/query handlers
compose answer
return assistant response + debug payload

Выход:

{
  "ok": true,
  "assistant_reply": "string",
  "conversation_item": {...},
  "debug": {
    "trace_id": "...",
    "fragments": [...],
    "fallback_type": "...",
    "route_summary": [...]
  }
}

12. Что сделать в GUI технически

12.1. Новая вкладка / режим

Добавить Assistant Mode без удаления текущего Decomposition Mode.

12.2. История диалога

Сделать хранение сообщений в рамках текущей сессии:

user messages;
assistant replies;
debug ids.

Пока достаточно session-scoped памяти без сложного persistence.

12.3. Debug drawer

У каждого ответа можно открыть:

decomposition;
fragments;
scope;
routes;
fallback;
trace_id.

13. Что логировать

Нужно логировать для каждого сообщения:

session_id
message_id
user_message
normalizer_output
resolved_execution_state
routes
fallback_type
retrieval/query payloads
assistant_reply
trace_id

Комментарий: Это потом очень пригодится, когда пойдут реальные полевые вопросы.

14. Что использовать как тестовые данные сейчас

Пока нет боевых полевых 30–40 вопросов, допускается использовать:

уже собранные сложные synthetic вопросы;
ваши старые troublesome вопросы;
10–20 кривых пользовательских формулировок.

Но это уже только для smoke test UI и pipeline, не для финального truth-eval.

15. Что будет следующим этапом после этого

После того как Assistant Mode заработает, следующий этап:

собрать 30–40 боевых полевых вопросов;
прогнать их уже через реальный диалоговый контур;
сохранить логи;
на их основе вернуться к:
- разметке,
- eval policy,
- hardening маршрутов,
- fine-tuning clarification/no-route policy.

То есть сейчас мы строим инструмент для получения настоящей конкретики, а не выдуманной.

16. Артефакты, которые должен выдать Codex

docs/assistant_mode_spec.md
обновлённый GUI с переключателем:
- Assistant
- Decomposition
backend endpoint для assistant loop
answer_composer слой
session-based chat history
debug drawer / expandable technical view
docs/assistant_mode_flow.md
docs/known_limits_before_field_eval.md

17. Критерии приёмки

Этап считается принятым, если:

в GUI есть два режима:
- decomposition
- assistant
assistant mode позволяет:
- ввести вопрос,
- прогнать pipeline,
- получить финальный человекочитаемый ответ
out-of-scope / clarification / partial fallback работают в диалоге
decomposition mode не сломан
debug-информация доступна, но не мешает основному UX
история сообщений в рамках сессии работает
можно использовать контур как рабочую тестовую песочницу для будущих полевых вопросов

18. Короткий итог

Сейчас правильный ход такой:

останавливаем blind eval hardening, не тратим силы на synthetic-разметку, и переводим систему в usable dialog mode, чтобы уже на реальных вопросах смотреть, где она работает, а где нет.

Если хочешь, я следующим сообщением сделаю ещё короткую версию этого ТЗ для прямой вставки в Codex, без пояснений и комментариев.

15 KiB Raw Permalink Blame History Unescape Escape