75 lines
5.2 KiB
Markdown
75 lines
5.2 KiB
Markdown
# ТЗ: Агент «Сверка договоров»
|
|
|
|
## Контекст
|
|
|
|
Есть договоры и дополнительные соглашения (допники) с клиентами. Файлы в форматах Word (.docx) и PDF. Данные строго конфиденциальны — обработка только на локальной модели (без внешних API).
|
|
|
|
---
|
|
|
|
## Задача 1: Разбор спецификации в структурированный вид
|
|
|
|
**Вход:** файл договора или допника (docx / pdf)
|
|
|
|
**Что делать:**
|
|
- Извлечь текст из файла
|
|
- Найти и распарсить спецификацию (таблица услуг/товаров)
|
|
- Вывести структуру: номер строки, наименование, количество, единица измерения, цена, сумма
|
|
- Если таблица не найдена или не поддаётся разбору — отметить задачу как **нерешаемую** с указанием причины (нет таблицы / нечитаемый PDF / нестандартный формат)
|
|
|
|
**Выход:** JSON или таблица со строками спецификации
|
|
|
|
---
|
|
|
|
## Задача 2: Кумулятивный статус договора по цепочке допников
|
|
|
|
**Вход:** базовый договор + список допников в хронологическом порядке
|
|
|
|
**Что делать:**
|
|
1. Взять спецификацию базового договора как начальное состояние
|
|
2. Для каждого допника определить тип изменений:
|
|
- **Полная замена** — допник содержит новую полную спецификацию → заменить текущее состояние целиком
|
|
- **Частичное изменение** — допник содержит только изменённые строки → идентифицировать строку (по наименованию / номеру позиции) и применить изменение
|
|
3. Строить историю состояний: дата допника → что изменилось → текущее состояние
|
|
4. Если строку из допника невозможно сопоставить с текущим состоянием — отметить эту строку как **нерешаемую** (нет совпадения), не применять изменение, продолжить обработку остальных
|
|
|
|
**Выход:**
|
|
- История изменений (timeline): дата / документ → изменения
|
|
- Итоговое состояние спецификации на последнюю дату
|
|
|
|
---
|
|
|
|
## Задача 3: Сопоставление позиций с каталогом услуг (опционально)
|
|
|
|
**Вход:** спецификация договора (из задачи 1) + каталог услуг (артикул + описание)
|
|
|
|
**Что делать:**
|
|
- По текстовому описанию строки спецификации найти ближайший артикул в каталоге
|
|
- Использовать семантическое сравнение (embedding / fuzzy match)
|
|
- Если уверенность совпадения ниже порога — отметить строку как **нерешаемую** (нет уверенного совпадения), не назначать артикул
|
|
|
|
**Выход:** спецификация с добавленным полем `артикул` (или пометкой `не определено`)
|
|
|
|
**Примечание:** задача реализуема только в части случаев. Приоритет — не ошибиться, а не охватить всё.
|
|
|
|
---
|
|
|
|
## Общие требования
|
|
|
|
| Требование | Описание |
|
|
|---|---|
|
|
| Модель | Только локальная (без внешних API) |
|
|
| Конфиденциальность | Файлы не покидают локальную среду |
|
|
| Обработка исключений | На каждом шаге — явная пометка нерешаемых подзадач с причиной. Не фантазировать, не домысливать |
|
|
| Форматы входа | .docx, .pdf |
|
|
| Формат выхода | JSON + человекочитаемый отчёт (md или html) |
|
|
| Логирование | Каждый шаг (файл → задача → результат / ошибка) фиксируется |
|
|
|
|
---
|
|
|
|
## Критерии успеха
|
|
|
|
- Структурированная спецификация получена или задача явно помечена как нерешаемая
|
|
- История изменений по допникам построена корректно
|
|
- Ни одно изменение не применено «наугад» без идентификации строки
|
|
- Итоговый отчёт читаем и проверяем вручную
|