568 lines
27 KiB
Markdown
568 lines
27 KiB
Markdown
Да, тут уже напрашивается не просто “ещё одно поле в автопрогонах”, а **нормальная управляющая схема**.
|
||
То есть у вас должно быть не только “модель ответила / оценка 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**, без пояснений и лирики.
|