АДРЕСНЫЙ РЕЖИМ - авторан история - юи + адресный рендер прогонов в реалтайме
This commit is contained in:
@@ -0,0 +1,10 @@
|
||||
# TECH Docs Index
|
||||
|
||||
Актуальные документы по operational-контру ассистента:
|
||||
|
||||
1. `assistant_canon.md` - канон поведения ассистента.
|
||||
2. `capabilities_registry.json` - реестр поддерживаемых возможностей.
|
||||
3. `manual_case_decision_schema.json` - схема решений ручной разметки.
|
||||
4. `ui_markup_system.md` - рабочий процесс разметки через GUI.
|
||||
5. `history_colibration.md` - сводка статуса и ближайших задач.
|
||||
|
||||
@@ -1,567 +1,85 @@
|
||||
Да, тут уже напрашивается не просто “ещё одно поле в автопрогонах”, а **нормальная управляющая схема**.
|
||||
То есть у вас должно быть не только “модель ответила / оценка 5-балльная”, а три опоры:
|
||||
|
||||
1. **эталон идеального поведения ассистента**;
|
||||
2. **ручная разметка результата прогона с управленческим смыслом**;
|
||||
3. **канонический файл возможностей ассистента по отработанным маршрутам 1С**.
|
||||
|
||||
И тогда автопрогоны перестают быть просто логами, а становятся контуром развития системы.
|
||||
|
||||
Ниже я собрал это так, чтобы можно было почти целиком отдать в Codex.
|
||||
|
||||
---
|
||||
|
||||
# Как я бы это сформулировал концептуально
|
||||
|
||||
## 1. Нужен отдельный блок: «Эталон поведения ассистента»
|
||||
|
||||
Это не просто описание “каким хотелось бы видеть ответ”.
|
||||
Это должен быть **формальный канон**, который понимают:
|
||||
|
||||
* сам ассистент;
|
||||
* система автопрогонов;
|
||||
* пост-анализ;
|
||||
* Codex, который потом дорабатывает маршруты и поведение.
|
||||
|
||||
То есть это не prose-блок “идеальная работа”, а именно **Assistant Canon / Behavior Canon**.
|
||||
|
||||
### Что в нём должно быть
|
||||
|
||||
#### А. Что такое хороший ответ
|
||||
|
||||
Хороший ответ ассистента:
|
||||
|
||||
* отвечает по существу, если кейс реально покрыт;
|
||||
* не врёт, если кейс не покрыт;
|
||||
* не выдаёт технические внутренности вместо нормальной коммуникации;
|
||||
* не ломается на смежных вопросах;
|
||||
* умеет мягко ограничить себя;
|
||||
* умеет предложить близкий поддерживаемый сценарий;
|
||||
* умеет подсказать, где это обычно смотреть в 1С;
|
||||
* не вываливает полный список возможностей без запроса;
|
||||
* раскрывает возможности по группам и по мере уточнения.
|
||||
|
||||
#### Б. Что такое плохой ответ
|
||||
|
||||
Плохой ответ ассистента:
|
||||
|
||||
* выдумывает функцию, которой нет;
|
||||
* делает вид, что может точно ответить, когда не может;
|
||||
* отвечает внутренним техническим языком;
|
||||
* сухо отказывает без пользы;
|
||||
* валит пользователя в огромный список умений;
|
||||
* не понимает, когда вопрос надо передать в “не покрыто, но рядом”;
|
||||
* не различает безопасный общий ответ и рискованный прикладной совет.
|
||||
|
||||
#### В. Какой идеал поведения на границе покрытия
|
||||
|
||||
Вот это вообще ключевой блок.
|
||||
|
||||
Ассистент должен:
|
||||
|
||||
* честно понимать границу своих возможностей;
|
||||
* не маскировать отсутствие маршрута;
|
||||
* не ломаться;
|
||||
* не отвечать “не поддерживается” в лоб;
|
||||
* не уходить в системные сообщения;
|
||||
* давать человекочитаемое ограничение;
|
||||
* предлагать ближайший полезный путь.
|
||||
|
||||
Это и есть ваш **эталон**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Нужна ручная разметка не только по качеству, но и по судьбе вопроса
|
||||
|
||||
Вот это очень сильная мысль.
|
||||
Пятибалльная оценка сама по себе почти бесполезна, потому что она **не говорит, что делать дальше**.
|
||||
|
||||
Нужна ещё одна сущность:
|
||||
|
||||
## **Decision Markup / Route Decision Markup**
|
||||
|
||||
То есть по каждому прогону вы размечаете не только “норм / не норм”, а **каково управленческое решение по классу вопроса**.
|
||||
|
||||
### Я бы добавил в UI не просто кнопку, а выпадающий классификатор
|
||||
|
||||
Например:
|
||||
|
||||
* `covered_ok` — кейс нормальный, покрывается, поведение ок;
|
||||
* `covered_but_bad_answer` — кейс должен покрываться, но ответ плохой;
|
||||
* `good_question_to_implement` — хороший вопрос, его надо брать в отработку;
|
||||
* `out_of_scope_but_answer_softly` — вопрос не планируется покрывать, но нужно мягко и полезно отвечать;
|
||||
* `unsafe_question_limit_strictly` — вопрос рискованный, на него нужно отвечать осторожно и ограниченно;
|
||||
* `bad_test_case` — сам тестовый вопрос мусорный / нерелевантный;
|
||||
* `needs_routing_extension` — нужен новый маршрут или расширение маршрутизации;
|
||||
* `needs_capability_registry_update` — кейс выявил дыру в файле возможностей;
|
||||
* `needs_dialog_policy_fix` — маршрут, возможно, не нужен, но политика ответа плохая.
|
||||
|
||||
Вот это уже даст системе смысл.
|
||||
|
||||
### Если хочется совсем по-простому
|
||||
|
||||
Можно ввести более короткий список:
|
||||
|
||||
* **Отрабатывается**
|
||||
* **Должно отрабатываться**
|
||||
* **Не будет отрабатываться**
|
||||
* **Отвечать мягким ограничением**
|
||||
* **Высокорисковый вопрос**
|
||||
* **Плохой тест-кейс**
|
||||
|
||||
Но я бы всё-таки оставил более инженерный набор, а в UI уже сделал человекочитаемые названия.
|
||||
|
||||
---
|
||||
|
||||
## 3. Нужен канонический файл возможностей ассистента
|
||||
|
||||
Да, это обязательно. И это должен быть не просто текстовый файл “что умеем”.
|
||||
Это должен быть **Capabilities Registry / Supported Routes Registry**.
|
||||
|
||||
И он должен быть источником истины для трёх вещей:
|
||||
|
||||
* ответа ассистента;
|
||||
* классификации покрываемости;
|
||||
* автопрогонов и анализа.
|
||||
|
||||
### Что там должно быть
|
||||
|
||||
Для каждого маршрута / домена:
|
||||
|
||||
* код маршрута;
|
||||
* человекочитаемая группа;
|
||||
* краткое описание;
|
||||
* что реально умеется;
|
||||
* что не умеется;
|
||||
* обязательные параметры;
|
||||
* типовые формулировки вопросов;
|
||||
* похожие смежные сценарии;
|
||||
* безопасные альтернативы;
|
||||
* подсказка, где это обычно смотреть в 1С;
|
||||
* уровень риска;
|
||||
* статус зрелости:
|
||||
|
||||
* production-ready
|
||||
* partial
|
||||
* planned
|
||||
* deprecated
|
||||
|
||||
### Пример групп
|
||||
|
||||
Не надо сразу показывать всё пользователю.
|
||||
Надо хранить глубоко, а наружу отдавать по группам.
|
||||
|
||||
Например:
|
||||
|
||||
* НДС
|
||||
* Контрагенты
|
||||
* Задолженности
|
||||
* Деньги и остатки
|
||||
* Платежи и движения
|
||||
* Аналитика по периодам
|
||||
* Справочные бухгалтерские вопросы
|
||||
|
||||
А дальше уже внутри группы:
|
||||
|
||||
* что умеется конкретно.
|
||||
|
||||
То есть если юзер спрашивает “что ты можешь по НДС?”, ассистент отвечает не списком из 80 пунктов, а компактной группой возможностей по НДС.
|
||||
|
||||
---
|
||||
|
||||
## 4. Надо отдельно зафиксировать правило раскрытия возможностей
|
||||
|
||||
Это тоже очень важный продуктовый момент.
|
||||
|
||||
### Ассистент не должен
|
||||
|
||||
* автоматически вываливать весь список поддерживаемого;
|
||||
* отвечать каталогом без запроса;
|
||||
* перегружать пользователя техническими деталями маршрутов.
|
||||
|
||||
### Ассистент должен
|
||||
|
||||
* раскрывать возможности **по группам**;
|
||||
* сначала давать верхнеуровневую сегментацию;
|
||||
* при уточнении — углубляться;
|
||||
* говорить в продуктовой, а не внутренне-технической логике.
|
||||
|
||||
То есть:
|
||||
“Могу помочь с НДС, остатками и движением денег, контрагентами и задолженностями, а также с частью аналитики по периодам. Если хочешь, могу уточнить отдельно по любому из этих блоков.”
|
||||
|
||||
А уже потом:
|
||||
“По НДС могу показать суммы, динамику по периодам, сверку по организации, сравнительные разрезы...”
|
||||
|
||||
---
|
||||
|
||||
## 5. Нужен отдельный тип разметки: «вопрос хороший, но ещё не покрыт»
|
||||
|
||||
Это, по сути, мост между автопрогоном и roadmap.
|
||||
|
||||
То есть если в прогоне всплыл вопрос:
|
||||
|
||||
* он адекватный;
|
||||
* он реально нужен;
|
||||
* пользователь его точно задаст;
|
||||
* сейчас он не покрыт,
|
||||
|
||||
то это не просто “ответ плохой”.
|
||||
Это **кандидат на новый маршрут / на расширение текущего покрытия**.
|
||||
|
||||
Поэтому в ручной разметке должен быть отдельный флаг:
|
||||
|
||||
* `candidate_for_implementation`
|
||||
или
|
||||
* `planned_route_gap`
|
||||
|
||||
Именно его потом должен видеть Codex и дальше использовать как список задач на развитие.
|
||||
|
||||
---
|
||||
|
||||
## 6. Надо разделить две разные проблемы
|
||||
|
||||
Сейчас у тебя в одном описании смешаны две вещи, а их лучше развести.
|
||||
|
||||
### Проблема 1. Функциональное покрытие
|
||||
|
||||
Что система реально умеет по данным и маршрутам.
|
||||
|
||||
### Проблема 2. Поведенческая зрелость
|
||||
|
||||
Как система ведёт себя, когда вопрос:
|
||||
|
||||
* вне покрытия;
|
||||
* частично в покрытии;
|
||||
* опасный;
|
||||
* слишком общий;
|
||||
* смежный;
|
||||
* абстрактный.
|
||||
|
||||
То есть даже если маршрут не реализован, поведение всё равно может быть:
|
||||
|
||||
* хорошим;
|
||||
* плохим;
|
||||
* опасным;
|
||||
* слишком техническим;
|
||||
* бесполезным.
|
||||
|
||||
И автопрогоны должны это различать.
|
||||
|
||||
---
|
||||
|
||||
# Ниже — готовая мини-ТЗшка для Codex
|
||||
|
||||
## Мини-ТЗ: эталон поведения ассистента, ручная разметка прогонов и канонический файл возможностей
|
||||
|
||||
### Цель
|
||||
|
||||
Доработать систему автопрогонов бухгалтерского ассистента так, чтобы она оценивала не только качество конкретного ответа, но и соответствие эталонному поведению ассистента, а также позволяла вручную размечать судьбу вопроса: покрывается, должен быть отработан, не будет отрабатываться, должен обрабатываться мягким ограничением, требует нового маршрута или требует доработки политики ответа.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ввести отдельную сущность: Assistant Behavior Canon
|
||||
|
||||
Нужен канонический блок, описывающий эталонную работу ассистента.
|
||||
|
||||
### Требования
|
||||
|
||||
Создать отдельную структуру/файл, который будет использоваться:
|
||||
|
||||
* в логике ответа ассистента;
|
||||
* в пост-анализе автопрогонов;
|
||||
* в интерфейсе разметки прогонов;
|
||||
* в дальнейшей работе Codex по развитию маршрутов и поведения.
|
||||
|
||||
### В Assistant Behavior Canon зафиксировать:
|
||||
|
||||
#### 1.1. Поведение на покрытых кейсах
|
||||
|
||||
* отвечать уверенно и по существу;
|
||||
* не уходить в лишние оговорки;
|
||||
* не использовать технические внутренние формулировки.
|
||||
|
||||
#### 1.2. Поведение на частично покрытых кейсах
|
||||
|
||||
* явно разделять, что ассистент может сделать, а что нет;
|
||||
* не маскировать ограничения;
|
||||
* предлагать полезное продолжение.
|
||||
|
||||
#### 1.3. Поведение на непокрытых, но близких кейсах
|
||||
|
||||
* не выдумывать поддержку функциональности;
|
||||
* мягко и по-человечески объяснять ограничение;
|
||||
* предлагать ближайший поддерживаемый сценарий;
|
||||
* при уместности подсказывать, где это обычно посмотреть в 1С.
|
||||
|
||||
#### 1.4. Поведение на высокорисковых вопросах
|
||||
|
||||
* не выдавать неподтверждённые рекомендации как надёжный ответ;
|
||||
* не делать вид, что прикладная логика существует, если её нет;
|
||||
* сохранять полезность без ложной уверенности.
|
||||
|
||||
#### 1.5. Поведение при вопросе “что ты умеешь”
|
||||
|
||||
* не вываливать весь список возможностей сразу;
|
||||
* раскрывать возможности по крупным группам;
|
||||
* углубляться только после уточнения;
|
||||
* использовать человекочитаемые продуктовые группы, а не внутренние названия маршрутов.
|
||||
|
||||
---
|
||||
|
||||
## 2. Ввести канонический файл возможностей ассистента
|
||||
|
||||
Нужен отдельный реестр отработанных возможностей ассистента по маршрутам 1С.
|
||||
|
||||
### Назначение
|
||||
|
||||
Этот файл является источником истины для:
|
||||
|
||||
* определения покрытия вопроса;
|
||||
* ответа ассистента на вопросы о своих возможностях;
|
||||
* similarity-логики;
|
||||
* автопрогонов и пост-анализа;
|
||||
* Codex при дальнейшем развитии маршрутов.
|
||||
|
||||
### Для каждого маршрута / домена хранить:
|
||||
|
||||
* `route_code`
|
||||
* `group_code`
|
||||
* `group_title`
|
||||
* `title`
|
||||
* `description`
|
||||
* `supported_operations`
|
||||
* `unsupported_operations`
|
||||
* `required_entities`
|
||||
* `optional_entities`
|
||||
* `typical_queries`
|
||||
* `related_routes`
|
||||
* `safe_alternatives`
|
||||
* `one_c_hints`
|
||||
* `risk_level`
|
||||
* `maturity_status` (`production_ready`, `partial`, `planned`, `deprecated`)
|
||||
|
||||
### Требования к пользовательскому раскрытию возможностей
|
||||
|
||||
Ассистент должен уметь:
|
||||
|
||||
* сначала показывать верхнеуровневые группы;
|
||||
* по запросу раскрывать детали внутри выбранной группы;
|
||||
* не использовать длинные технические перечни без необходимости.
|
||||
|
||||
---
|
||||
|
||||
## 3. Доработать интерфейс автопрогонов: ручная управленческая разметка
|
||||
|
||||
Существующую 5-балльную оценку оставить, но дополнить отдельной выпадающей ручной классификацией результата прогона.
|
||||
|
||||
### Добавить новое поле:
|
||||
|
||||
`manual_case_decision`
|
||||
|
||||
### Возможные значения:
|
||||
|
||||
* `covered_ok`
|
||||
* `covered_but_bad_answer`
|
||||
* `candidate_for_implementation`
|
||||
* `needs_routing_extension`
|
||||
* `out_of_scope_but_answer_softly`
|
||||
* `unsafe_question_limit_strictly`
|
||||
* `needs_dialog_policy_fix`
|
||||
* `needs_capability_registry_update`
|
||||
* `bad_test_case`
|
||||
|
||||
### Смысл значений
|
||||
|
||||
* `covered_ok` — кейс уже покрыт, поведение нормальное;
|
||||
* `covered_but_bad_answer` — кейс покрывается, но ответ/диалог плохой;
|
||||
* `candidate_for_implementation` — хороший пользовательский кейс, которого пока нет, его стоит брать в разработку;
|
||||
* `needs_routing_extension` — нужен новый маршрут или расширение существующего;
|
||||
* `out_of_scope_but_answer_softly` — кейс не планируется покрывать, но нужен качественный мягкий ответ без техничности;
|
||||
* `unsafe_question_limit_strictly` — кейс относится к рискованным, и ассистент должен ограничивать себя особенно строго;
|
||||
* `needs_dialog_policy_fix` — проблема не в маршруте, а в стиле/логике ответа;
|
||||
* `needs_capability_registry_update` — реестр возможностей неактуален или недостаточно формализован;
|
||||
* `bad_test_case` — вопрос мусорный, нерелевантный или бесполезный для развития системы.
|
||||
|
||||
### Дополнительно
|
||||
|
||||
Для каждой ручной метки предусмотреть:
|
||||
|
||||
* короткий комментарий;
|
||||
* автора разметки;
|
||||
* timestamp;
|
||||
* возможность использовать эту разметку в пост-анализе и отборе задач для Codex.
|
||||
|
||||
---
|
||||
|
||||
## 4. Доработать логику пост-анализа прогонов
|
||||
|
||||
После прогона система должна уметь отделять:
|
||||
|
||||
* ошибки покрытия;
|
||||
* ошибки маршрутизации;
|
||||
* ошибки политики ответа;
|
||||
* хорошие, но ещё не покрытые кейсы;
|
||||
* мусорные тест-кейсы;
|
||||
* высокорисковые кейсы;
|
||||
* кейсы на обновление файла возможностей.
|
||||
|
||||
### На выходе пост-анализа нужны агрегаты:
|
||||
|
||||
* список кейсов на доработку маршрутов;
|
||||
* список кейсов на доработку policy;
|
||||
* список кейсов на обновление capabilities registry;
|
||||
* список кейсов, которые сознательно не будут покрываться, но требуют мягкого ограничения;
|
||||
* список кейсов, пригодных для новых regression suites.
|
||||
|
||||
---
|
||||
|
||||
## 5. Встроить связь между ручной разметкой и дальнейшей работой Codex
|
||||
|
||||
Codex должен видеть не только сам диалог и оценку, но и управленческое решение по нему.
|
||||
|
||||
### Требование
|
||||
|
||||
При выгрузке данных для дальнейшего анализа и доработок обязательно передавать:
|
||||
|
||||
* question / dialog trace;
|
||||
* current route / current coverage decision;
|
||||
* 5-балльную оценку;
|
||||
* `manual_case_decision`;
|
||||
* комментарий аналитика;
|
||||
* ссылку на ближайший домен из capabilities registry;
|
||||
* признак: нужно ли брать кейс в маршрутную отработку.
|
||||
|
||||
### Ожидаемое поведение
|
||||
|
||||
Если кейс помечен как:
|
||||
|
||||
* `candidate_for_implementation` или `needs_routing_extension` — Codex рассматривает его как материал для новой/расширенной маршрутной логики;
|
||||
* `out_of_scope_but_answer_softly` — Codex улучшает не маршруты, а policy-слой ответа;
|
||||
* `needs_capability_registry_update` — Codex актуализирует реестр возможностей;
|
||||
* `unsafe_question_limit_strictly` — Codex усиливает безопасное поведение и ограничения;
|
||||
* `covered_but_bad_answer` — Codex чинит существующий покрываемый сценарий, а не создаёт новый.
|
||||
|
||||
---
|
||||
|
||||
## 6. Добавить в эталон обязательное правило минимизации технических ответов
|
||||
|
||||
Это отдельное критичное требование.
|
||||
|
||||
### Ассистент не должен
|
||||
|
||||
* отвечать внутренними техническими терминами;
|
||||
* ссылаться на отсутствие маршрута, домена, интента, пайплайна, классификатора;
|
||||
* создавать ощущение поломки системы.
|
||||
|
||||
### Ассистент должен
|
||||
|
||||
* говорить естественно;
|
||||
* объяснять ограничения человеческим языком;
|
||||
* сохранять полезность даже при отказе;
|
||||
* ориентировать пользователя в доступных соседних возможностях.
|
||||
|
||||
---
|
||||
|
||||
## 7. Добавить в эталон обязательное правило сегментированного раскрытия возможностей
|
||||
|
||||
Если пользователь спрашивает:
|
||||
|
||||
* “что ты умеешь?”
|
||||
* “что можешь по НДС?”
|
||||
* “что можешь по остаткам?”
|
||||
* “что умеешь по деньгам / поставщикам / задолженностям?”
|
||||
|
||||
ассистент должен отвечать через иерархию:
|
||||
|
||||
### Уровень 1
|
||||
|
||||
Крупные продуктовые группы:
|
||||
|
||||
* НДС
|
||||
* Контрагенты
|
||||
* Задолженности
|
||||
* Деньги и остатки
|
||||
* Движение и платежи
|
||||
* Аналитика по периодам
|
||||
* Справочные бухгалтерские вопросы
|
||||
|
||||
### Уровень 2
|
||||
|
||||
Уточнение по выбранной группе:
|
||||
|
||||
* что внутри группы реально доступно;
|
||||
* какие ограничения есть;
|
||||
* что можно сделать следующим шагом.
|
||||
|
||||
### Уровень 3
|
||||
|
||||
Точечный ответ по конкретному запросу.
|
||||
|
||||
---
|
||||
|
||||
## 8. Критерии приёмки
|
||||
|
||||
1. В системе появился отдельный канонический блок эталонного поведения ассистента.
|
||||
2. Появился отдельный файл/реестр возможностей по маршрутам 1С.
|
||||
3. В UI автопрогонов добавлена ручная управленческая разметка результата.
|
||||
4. Ручная разметка сохраняется в логах и участвует в пост-анализе.
|
||||
5. Система умеет отделять “не покрыто, но стоит реализовать” от “не покрыто и не планируется, но нужно мягко отвечать”.
|
||||
6. Ассистент перестаёт отвечать внутренним техническим языком на границе покрытия.
|
||||
7. Ассистент умеет раскрывать свои возможности по группам, а не полным списком.
|
||||
8. Codex получает достаточно данных, чтобы понимать, что чинить: маршрут, policy, capabilities registry или сам тест-кейс.
|
||||
|
||||
---
|
||||
|
||||
# Что я бы ещё добавил от себя
|
||||
|
||||
Я бы прямо выделил в ТЗ отдельный артефакт:
|
||||
|
||||
## `assistant_canon.md`
|
||||
|
||||
В нём:
|
||||
|
||||
* идеал поведения;
|
||||
* анти-паттерны;
|
||||
* примеры хороших ответов;
|
||||
* примеры плохих ответов;
|
||||
* правила раскрытия возможностей;
|
||||
* правила мягкого ограничения;
|
||||
* правила поведения на рискованных вопросах.
|
||||
|
||||
И отдельно:
|
||||
|
||||
## `capabilities_registry.json`
|
||||
|
||||
или `capabilities_registry.yaml`
|
||||
|
||||
И ещё:
|
||||
|
||||
## `manual_case_decision_schema.json`
|
||||
|
||||
Чтобы UI и пост-анализ работали по одному словарю значений.
|
||||
|
||||
---
|
||||
|
||||
# Если совсем коротко, в чём суть
|
||||
|
||||
Тебе сейчас нужен не просто “ещё один контрол в модалке”, а вот такая конструкция:
|
||||
|
||||
**Эталон ассистента**
|
||||
→ задаёт идеальное поведение
|
||||
|
||||
**Файл возможностей**
|
||||
→ задаёт фактическое покрытие
|
||||
|
||||
**Ручная разметка кейса**
|
||||
→ задаёт управленческое решение, что с этим вопросом делать дальше
|
||||
|
||||
**Codex**
|
||||
→ уже понимает, нужно ли:
|
||||
|
||||
* чинить ответ,
|
||||
* расширять маршрут,
|
||||
* обновлять capabilities,
|
||||
* улучшать мягкий отказ,
|
||||
* или вообще выкинуть тест-кейс.
|
||||
|
||||
Если хочешь, я следующим сообщением могу собрать это ещё в более прикладной форме: **короткое ТЗ на 30–40 строк для прямой отправки в Codex**, без пояснений и лирики.
|
||||
# История калибровки: статус на 2026-04-09
|
||||
|
||||
Этот документ фиксирует текущее состояние системы автопрогонов и ручной разметки в GUI.
|
||||
Ранее здесь был концептуальный черновик. Теперь это рабочая сводка "что уже внедрено / что осталось".
|
||||
|
||||
## 1. Что уже формализовано
|
||||
|
||||
1. Канон поведения ассистента:
|
||||
- `docs/TECH/assistant_canon.md`
|
||||
2. Реестр возможностей ассистента:
|
||||
- `docs/TECH/capabilities_registry.json`
|
||||
3. Схема управленческой разметки кейсов:
|
||||
- `docs/TECH/manual_case_decision_schema.json`
|
||||
|
||||
## 2. Что реализовано в интерфейсе "История автопрогонов"
|
||||
|
||||
1. Генерация вопросов:
|
||||
- режимы `qwen_seed` и `codex_creative`;
|
||||
- редактируемая пачка вопросов перед запуском;
|
||||
- выбор "личности" генерации;
|
||||
- отдельный prompt для выбранной личности.
|
||||
2. Асинхронные прогоны:
|
||||
- запуск через `POST /api/eval/run-async/start`;
|
||||
- проверка статуса через `GET /api/eval/run-async/:job_id`;
|
||||
- обновление экрана в live-цикле polling.
|
||||
3. Разметка ответа ассистента:
|
||||
- рейтинг `1..5`;
|
||||
- комментарий;
|
||||
- `manual_case_decision`;
|
||||
- автор разметки.
|
||||
4. Операции по комментарию:
|
||||
- отметка `resolved` / `unresolved`;
|
||||
- фильтр "скрыть выполненные";
|
||||
- фильтр по `manual_case_decision`.
|
||||
5. Пост-анализ:
|
||||
- очереди фиксов из решений разметки;
|
||||
- агрегаты по доменам и категориям.
|
||||
|
||||
## 3. Файлы данных, которые формируются рантаймом
|
||||
|
||||
1. Разметка ответов:
|
||||
- `llm_normalizer/data/autorun_annotations/annotations.json`
|
||||
2. История автогенерации:
|
||||
- `llm_normalizer/data/autorun_generators/history.json`
|
||||
3. Сгенерированные кейс-сеты:
|
||||
- `llm_normalizer/data/eval_cases/*.json`
|
||||
4. Диалоги кейсов:
|
||||
- `llm_normalizer/data/assistant_sessions/*.json`
|
||||
|
||||
## 4. Управленческие решения `manual_case_decision`
|
||||
|
||||
Текущий enum:
|
||||
|
||||
1. `covered_ok`
|
||||
2. `covered_but_bad_answer`
|
||||
3. `candidate_for_implementation`
|
||||
4. `needs_routing_extension`
|
||||
5. `out_of_scope_but_answer_softly`
|
||||
6. `unsafe_question_limit_strictly`
|
||||
7. `needs_dialog_policy_fix`
|
||||
8. `needs_capability_registry_update`
|
||||
9. `bad_test_case`
|
||||
|
||||
Используются для очередей пост-анализа:
|
||||
|
||||
1. `none`
|
||||
2. `policy_fix`
|
||||
3. `routing_extension`
|
||||
4. `soft_boundary`
|
||||
5. `safety_policy`
|
||||
6. `capability_registry`
|
||||
7. `testset_hygiene`
|
||||
|
||||
## 5. Что осталось в ближайшем цикле
|
||||
|
||||
1. Дожать UX стабильность модалок разметки (без "вечного сохранения" в UI).
|
||||
2. Довести live-визуал прогона до полностью прозрачного режима вопрос/ответ в реальном времени для длинных серий.
|
||||
3. Укрепить контроль кодировки UTF-8 на всех точках экспорта/рендера.
|
||||
4. Добавить регулярный цикл "разметка -> автокандидаты фиксов -> пакетный ремонт маршрутов".
|
||||
|
||||
## 6. Ссылки на подробный документ процесса
|
||||
|
||||
Подробная спецификация по разметке из GUI:
|
||||
|
||||
- `docs/TECH/ui_markup_system.md`
|
||||
|
||||
@@ -0,0 +1,224 @@
|
||||
# Система разметки через GUI (автопрогоны)
|
||||
|
||||
Документ описывает практический контур, который используется оператором в интерфейсе
|
||||
`История автопрогонов`: генерация вопросов, запуск прогонов, разметка ответов, закрытие кейсов и пост-анализ.
|
||||
|
||||
Дата актуализации: `2026-04-09`
|
||||
|
||||
---
|
||||
|
||||
## 1. Назначение
|
||||
|
||||
Цель системы:
|
||||
|
||||
1. Прогонять реалистичные пользовательские вопросы сериями.
|
||||
2. Видеть фактические ответы ассистента в диалоговом формате.
|
||||
3. Размечать качество ответов и управленческое решение по кейсу.
|
||||
4. Формировать очередь фикс-пакетов без ручной выгрузки логов в чат.
|
||||
|
||||
---
|
||||
|
||||
## 2. Где находится источник истины
|
||||
|
||||
1. Канон поведения ассистента:
|
||||
- `docs/TECH/assistant_canon.md`
|
||||
2. Реестр возможностей:
|
||||
- `docs/TECH/capabilities_registry.json`
|
||||
3. Схема решений ручной разметки:
|
||||
- `docs/TECH/manual_case_decision_schema.json`
|
||||
|
||||
---
|
||||
|
||||
## 3. Основной сценарий оператора
|
||||
|
||||
### Шаг 1. Настройка генерации
|
||||
|
||||
Оператор задает:
|
||||
|
||||
1. режим генерации (`qwen_seed` / `codex_creative`);
|
||||
2. количество вопросов;
|
||||
3. "личность" автогенерации;
|
||||
4. prompt выбранной личности;
|
||||
5. автора генерации;
|
||||
6. флаг сохранения кейс-сета в `eval_cases`.
|
||||
|
||||
Важно:
|
||||
|
||||
`qwen_seed` использует тот же активный LLM-контур, что и ответы ассистента
|
||||
(тот же provider/model/baseUrl), но в роли генератора вопросов.
|
||||
|
||||
### Шаг 2. Генерация пачки
|
||||
|
||||
По кнопке "Сгенерировать пачку" создается generation record.
|
||||
|
||||
Запрос:
|
||||
|
||||
- `POST /api/autoruns/autogen/generate`
|
||||
|
||||
История доступна через:
|
||||
|
||||
- `GET /api/autoruns/autogen/history`
|
||||
|
||||
### Шаг 3. Ручная правка вопросов
|
||||
|
||||
Перед запуском оператор редактирует список "Вопросы к запуску":
|
||||
|
||||
1. удаляет нерелевантные;
|
||||
2. правит формулировки;
|
||||
3. оставляет итоговую пачку для прогона.
|
||||
|
||||
### Шаг 4. Запуск прогонов
|
||||
|
||||
Запуск идет асинхронно (на текущем этапе для `assistant_stage1`):
|
||||
|
||||
- `POST /api/eval/run-async/start`
|
||||
|
||||
В payload передается итоговый массив `questions[]`.
|
||||
|
||||
### Шаг 5. Live-мониторинг
|
||||
|
||||
Статус job обновляется polling-ом:
|
||||
|
||||
- `GET /api/eval/run-async/:job_id`
|
||||
|
||||
По мере обработки кейсов интерфейс подхватывает:
|
||||
|
||||
1. прогон;
|
||||
2. кейсы;
|
||||
3. сообщения вопрос/ответ в диалоге.
|
||||
|
||||
### Шаг 6. Разметка ответа
|
||||
|
||||
Размечается только сообщение `role=assistant`.
|
||||
|
||||
Через модалку задаются:
|
||||
|
||||
1. rating `1..5`;
|
||||
2. comment;
|
||||
3. `manual_case_decision`;
|
||||
4. author.
|
||||
|
||||
Сохранение:
|
||||
|
||||
- `POST /api/autoruns/annotations`
|
||||
|
||||
### Шаг 7. Закрытие кейса
|
||||
|
||||
В комментариях доступен статус `resolved`:
|
||||
|
||||
- отметить выполненным;
|
||||
- вернуть в открытые.
|
||||
|
||||
Запрос:
|
||||
|
||||
- `PATCH /api/autoruns/annotations/:annotation_id`
|
||||
|
||||
### Шаг 8. Фильтрация и пост-анализ
|
||||
|
||||
Доступно:
|
||||
|
||||
1. фильтр по `manual_case_decision`;
|
||||
2. скрытие выполненных (`resolved=true`);
|
||||
3. обновление пост-анализа и очередей фиксов.
|
||||
|
||||
Запросы:
|
||||
|
||||
- `GET /api/autoruns/annotations`
|
||||
- `GET /api/autoruns/post-analysis`
|
||||
|
||||
---
|
||||
|
||||
## 4. Решения ручной разметки (`manual_case_decision`)
|
||||
|
||||
Текущее множество:
|
||||
|
||||
1. `covered_ok`
|
||||
2. `covered_but_bad_answer`
|
||||
3. `candidate_for_implementation`
|
||||
4. `needs_routing_extension`
|
||||
5. `out_of_scope_but_answer_softly`
|
||||
6. `unsafe_question_limit_strictly`
|
||||
7. `needs_dialog_policy_fix`
|
||||
8. `needs_capability_registry_update`
|
||||
9. `bad_test_case`
|
||||
|
||||
Queue mapping:
|
||||
|
||||
1. `covered_ok` -> `none`
|
||||
2. `covered_but_bad_answer` -> `policy_fix`
|
||||
3. `candidate_for_implementation` -> `routing_extension`
|
||||
4. `needs_routing_extension` -> `routing_extension`
|
||||
5. `out_of_scope_but_answer_softly` -> `soft_boundary`
|
||||
6. `unsafe_question_limit_strictly` -> `safety_policy`
|
||||
7. `needs_dialog_policy_fix` -> `policy_fix`
|
||||
8. `needs_capability_registry_update` -> `capability_registry`
|
||||
9. `bad_test_case` -> `testset_hygiene`
|
||||
|
||||
---
|
||||
|
||||
## 5. Хранилища данных
|
||||
|
||||
1. Аннотации:
|
||||
- `llm_normalizer/data/autorun_annotations/annotations.json`
|
||||
2. История генерации:
|
||||
- `llm_normalizer/data/autorun_generators/history.json`
|
||||
3. Кейс-сеты генератора:
|
||||
- `llm_normalizer/data/eval_cases/*.json`
|
||||
4. Диалоги сессий:
|
||||
- `llm_normalizer/data/assistant_sessions/*.json`
|
||||
|
||||
---
|
||||
|
||||
## 6. API-карта раздела
|
||||
|
||||
### История прогонов
|
||||
|
||||
1. `GET /api/autoruns/history`
|
||||
2. `GET /api/autoruns/history/:run_id`
|
||||
3. `GET /api/autoruns/history/:run_id/case/:case_id/dialog`
|
||||
|
||||
### Разметка
|
||||
|
||||
1. `GET /api/autoruns/annotations`
|
||||
2. `POST /api/autoruns/annotations`
|
||||
3. `PATCH /api/autoruns/annotations/:annotation_id`
|
||||
4. `GET /api/autoruns/manual-decision-schema`
|
||||
|
||||
### Пост-анализ
|
||||
|
||||
1. `GET /api/autoruns/post-analysis`
|
||||
|
||||
### Автогенерация
|
||||
|
||||
1. `GET /api/autoruns/autogen/personality-catalog`
|
||||
2. `POST /api/autoruns/autogen/generate`
|
||||
3. `GET /api/autoruns/autogen/history`
|
||||
|
||||
### Асинхронный запуск
|
||||
|
||||
1. `POST /api/eval/run-async/start`
|
||||
2. `GET /api/eval/run-async/:job_id`
|
||||
|
||||
---
|
||||
|
||||
## 7. Тех-проверки после изменений
|
||||
|
||||
Минимальный чек:
|
||||
|
||||
1. Генерация пачки вопросов работает.
|
||||
2. Async run запускается и отдает live-статус без падения.
|
||||
3. В диалоге видны пары вопрос/ответ.
|
||||
4. Аннотация сохраняется и редактируется повторно.
|
||||
5. `resolved` переключается без рассинхрона в UI.
|
||||
6. Фильтр "скрыть выполненные" корректно исключает `resolved=true`.
|
||||
7. Пост-анализ показывает очереди и кандидатов.
|
||||
8. Текст в интерфейсе читается без mojibake.
|
||||
|
||||
---
|
||||
|
||||
## 8. Ограничения текущей версии
|
||||
|
||||
1. Async run ограничен `assistant_stage1`.
|
||||
2. Качество live-данных зависит от заполнения session-файлов на стороне рантайма.
|
||||
3. Пост-анализ основан на фактической ручной разметке; без нее очереди пустые.
|
||||
|
||||
Reference in New Issue
Block a user