480 lines
15 KiB
Markdown
480 lines
15 KiB
Markdown
Да, это разумный ход.
|
||
|
||
Ты сейчас предлагаешь **не добивать 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. Внутренний пайплайн
|
||
|
||
После отправки сообщения система должна:
|
||
|
||
1. прогнать сообщение через `normalizer_v2.x`;
|
||
2. получить fragments / flags / scope;
|
||
3. отбросить out-of-scope части;
|
||
4. определить routed / no-route / clarification;
|
||
5. если есть исполнимые fragments — отправить их в backend retrieval/query layer;
|
||
6. получить промежуточные результаты;
|
||
7. собрать из них **человекочитаемый ответ**;
|
||
8. показать его пользователю в чате.
|
||
|
||
## 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
|
||
|
||
Выход:
|
||
|
||
```json
|
||
{
|
||
"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
|
||
|
||
1. `docs/assistant_mode_spec.md`
|
||
2. обновлённый GUI с переключателем:
|
||
|
||
* `Assistant`
|
||
* `Decomposition`
|
||
3. backend endpoint для assistant loop
|
||
4. `answer_composer` слой
|
||
5. session-based chat history
|
||
6. debug drawer / expandable technical view
|
||
7. `docs/assistant_mode_flow.md`
|
||
8. `docs/known_limits_before_field_eval.md`
|
||
|
||
---
|
||
|
||
## 17. Критерии приёмки
|
||
|
||
Этап считается принятым, если:
|
||
|
||
1. в GUI есть два режима:
|
||
|
||
* decomposition
|
||
* assistant
|
||
2. assistant mode позволяет:
|
||
|
||
* ввести вопрос,
|
||
* прогнать pipeline,
|
||
* получить финальный человекочитаемый ответ
|
||
3. out-of-scope / clarification / partial fallback работают в диалоге
|
||
4. decomposition mode не сломан
|
||
5. debug-информация доступна, но не мешает основному UX
|
||
6. история сообщений в рамках сессии работает
|
||
7. можно использовать контур как рабочую тестовую песочницу для будущих полевых вопросов
|
||
|
||
---
|
||
|
||
## 18. Короткий итог
|
||
|
||
Сейчас правильный ход такой:
|
||
|
||
**останавливаем blind eval hardening,
|
||
не тратим силы на synthetic-разметку,
|
||
и переводим систему в usable dialog mode,
|
||
чтобы уже на реальных вопросах смотреть, где она работает, а где нет.**
|
||
|
||
---
|
||
|
||
Если хочешь, я следующим сообщением сделаю ещё **короткую версию этого ТЗ для прямой вставки в Codex**, без пояснений и комментариев.
|