Initial import NDC_1C
This commit is contained in:
@@ -0,0 +1,479 @@
|
||||
Да, это разумный ход.
|
||||
|
||||
Ты сейчас предлагаешь **не добивать 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**, без пояснений и комментариев.
|
||||
Reference in New Issue
Block a user