124 lines
7.2 KiB
Markdown
124 lines
7.2 KiB
Markdown
# Ответ Опуса — режим «исправление ошибок / обучение»
|
||
|
||
Дата: 26.06.2025 | В ответ на обсуждение feedback-цикла.
|
||
|
||
---
|
||
|
||
## Суть
|
||
|
||
Режим: **юзер загружает документы → система выдаёт результат → юзер правит ошибки → правки сохраняются**.
|
||
|
||
Это не «обучение модели», а **накопление эталонных данных** (golden dataset) через естественный интерфейс исправления. Юзер не размечает абстрактно — он правит конкретный неверный результат.
|
||
|
||
## Что уже есть под это
|
||
|
||
- LLM возвращает поток операций: `ADD` / `UPDATE` / `DELETE` / `UNRESOLVED`
|
||
- Применяются через событийную модель (`apply_events.cfm`)
|
||
- Правка юзера = **исправленный поток операций**
|
||
- Разница «LLM выдал» vs «юзер поправил» = **чистый сигнал ошибки**
|
||
|
||
## Три уровня (не путать)
|
||
|
||
| Уровень | Что | Когда |
|
||
|---------|-----|-------|
|
||
| **Регрессия** | Правки → golden-набор → прогон промпта → % ошибок | Сразу |
|
||
| **Prompt-learning** | Анализ частых ошибок → правка промпта (few-shot/глоссарий) | Периодически |
|
||
| **Fine-tuning** | Дообучение модели на сотнях/тысячах примеров | Не сейчас |
|
||
|
||
## Чего НЕ делать
|
||
|
||
- **Автоматически вкручивать правки в промпт** — переобучение, конфликты, рост токенов
|
||
- Правильно: правки → накопитель → куратор анализирует агрегаты → batch-обновление промпта → регрессия
|
||
|
||
## Что заложить в дизайн
|
||
|
||
1. **Структурировать тип ошибки:** «пропущена строка», «неверная цена», «UPDATE вместо ADD», «ложный дубликат»
|
||
2. **Версия промпта** при каждом результате — чтобы знать актуальность ошибки
|
||
3. **Конфиденциальность** — реальные договоры с реквизитами копятся в БД, обсудить с заказчиком
|
||
|
||
---
|
||
|
||
**Решение:** отложить. Позже вернуться и спроектировать.
|
||
|
||
---
|
||
|
||
# Часть 2 — Конкретный UI для отметки ошибок
|
||
|
||
Дата: 26.06.2025 | Опус изучил реальный вывод (карточка + таблица операций) и предложил привязку к элементам интерфейса.
|
||
|
||
## Привязка: не к абзацам, а к строкам таблицы операций
|
||
|
||
Результат — **таблица операций** (`Действие / Услуга / Цена / Кол-во / Сумма / Дата`), а не текст-простыня. Замечание цепляется к строке таблицы, а не к абзацу исходника.
|
||
|
||
### Как выглядит (на реальном примере)
|
||
|
||
```
|
||
✓ допник-1-XXX002-01200_3.docx — 2 оп., partial (14с) [✓ всё верно]
|
||
+2 ~0 -0
|
||
|
||
Действие Услуга Цена Кол-во Сумма Дата ⚠
|
||
ADD WAF: Positive Technologies, в составе… 104021.67 1 104021.67 2026-03-30 [⚠]
|
||
ADD Облачный диск Valo Cloud, в составе… 68700 1 68700 2026-02-01 [⚠]
|
||
|
||
[ ➕ Система пропустила позицию ]
|
||
```
|
||
|
||
### Клик по `[⚠]` → мини-форма под строкой
|
||
|
||
```
|
||
Тип ошибки: ( ) неверная цена/сумма
|
||
( ) неверное кол-во
|
||
( ) неверное наименование услуги
|
||
(•) лишняя строка — этой операции быть не должно
|
||
( ) неверное действие (должно быть UPDATE/DELETE, а не ADD)
|
||
( ) неверная дата
|
||
Правильное значение: [_____________] (необязательно)
|
||
Комментарий: [_____________] (необязательно)
|
||
[ Сохранить ]
|
||
```
|
||
|
||
### `[✓ всё верно]` — вверху карточки
|
||
|
||
Один клик = положительный сигнал, без расписывания.
|
||
|
||
### `[➕ Система пропустила позицию]` — под таблицей
|
||
|
||
Для случая, когда услуга была в документе, но LLM её не извлекла. Открывает форму ввода пропущенной строки.
|
||
|
||
## Что уходит в базу (обезличенно)
|
||
|
||
```
|
||
operation: ADD
|
||
service: "Облачный диск Valo Cloud, в составе…" ← без названия клиента
|
||
field: price
|
||
llm_value: 68700
|
||
correct: 68000
|
||
error_type: wrong_price
|
||
prompt_version: v1.0.178
|
||
```
|
||
|
||
Никаких названий компаний, ФИО, № договора — только структура услуги и числа.
|
||
|
||
## Почему так, а не поле у каждого абзаца
|
||
|
||
- Реальный вывод — **таблица**, а не текст. Абзацев нет, есть операции
|
||
- Привязка к операции даёт агрегацию по типу ошибки
|
||
- Готовая дельта «LLM выдала X → правильно Y» как обучающий сигнал
|
||
- Ровная укладка в событийную модель (`apply_events.cfm`)
|
||
|
||
---
|
||
|
||
**Решение:** отложить. Ждать «делай» для реализации.
|
||
|
||
---
|
||
|
||
# Часть 3 — Текст для заказчика
|
||
|
||
**Этап опытной эксплуатации (обучение системы)**
|
||
|
||
На первое время предлагаем режим проверки: вы загружаете реальные документы, система выдаёт результат, а вы отмечаете ошибки — что распознано неверно (пропущена строка, неверная цена, неправильное сопоставление и т.п.).
|
||
|
||
Эти отметки **в обезличенном виде** (без названий компаний, ФИО, реквизитов и иных персональных данных) накапливаются в базе и используются для дальнейшей настройки и обучения системы.
|
||
|
||
Это позволит откалибровать сервис на ваших реальных договорах, а не на тестовых примерах, и системно повышать точность.
|