7.2 KiB
Ответ Опуса — режим «исправление ошибок / обучение»
Дата: 26.06.2025 | В ответ на обсуждение feedback-цикла.
Суть
Режим: юзер загружает документы → система выдаёт результат → юзер правит ошибки → правки сохраняются.
Это не «обучение модели», а накопление эталонных данных (golden dataset) через естественный интерфейс исправления. Юзер не размечает абстрактно — он правит конкретный неверный результат.
Что уже есть под это
- LLM возвращает поток операций:
ADD/UPDATE/DELETE/UNRESOLVED - Применяются через событийную модель (
apply_events.cfm) - Правка юзера = исправленный поток операций
- Разница «LLM выдал» vs «юзер поправил» = чистый сигнал ошибки
Три уровня (не путать)
| Уровень | Что | Когда |
|---|---|---|
| Регрессия | Правки → golden-набор → прогон промпта → % ошибок | Сразу |
| Prompt-learning | Анализ частых ошибок → правка промпта (few-shot/глоссарий) | Периодически |
| Fine-tuning | Дообучение модели на сотнях/тысячах примеров | Не сейчас |
Чего НЕ делать
- Автоматически вкручивать правки в промпт — переобучение, конфликты, рост токенов
- Правильно: правки → накопитель → куратор анализирует агрегаты → batch-обновление промпта → регрессия
Что заложить в дизайн
- Структурировать тип ошибки: «пропущена строка», «неверная цена», «UPDATE вместо ADD», «ложный дубликат»
- Версия промпта при каждом результате — чтобы знать актуальность ошибки
- Конфиденциальность — реальные договоры с реквизитами копятся в БД, обсудить с заказчиком
Решение: отложить. Позже вернуться и спроектировать.
Часть 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 — Текст для заказчика
Этап опытной эксплуатации (обучение системы)
На первое время предлагаем режим проверки: вы загружаете реальные документы, система выдаёт результат, а вы отмечаете ошибки — что распознано неверно (пропущена строка, неверная цена, неправильное сопоставление и т.п.).
Эти отметки в обезличенном виде (без названий компаний, ФИО, реквизитов и иных персональных данных) накапливаются в базе и используются для дальнейшей настройки и обучения системы.
Это позволит откалибровать сервис на ваших реальных договорах, а не на тестовых примерах, и системно повышать точность.