# Техническое задание (ТЗ)
## Разработка ИИ-агента «Сверка договоров»

---

## 1. Общие сведения и цель проекта

**Цель проекта:** Автоматизация процесса анализа, структурирования и отслеживания хронологии изменений в цепочках договоров и дополнительных соглашений (ДС) с клиентами с использованием локальной языковой модели (LLM).

**Ключевое свойство системы:** ИИ-агент должен работать строго в режиме «Экстракция и сопоставление на основе фактов». Фантазирование (галлюцинации) недопустимо. Если подзадача не может быть решена из-за нехватки данных или двусмысленности, система должна явно маркировать её как **«нерешаемую для ИИ»** и передавать на ручную обработку.

---

## 2. Архитектурные ограничения и безопасность

- **Конфиденциальность данных:** Информация в документах является строго конфиденциальной. Применение внешних облачных API (OpenAI, Anthropic и др.) **категорически запрещено**.
- **Инфраструктура:** Решение должно быть развернуто локально / в закрытом контуре компании на базе собственной (on-premise) модели.

---

## 3. Функциональные требования

Система должна последовательно выполнять три основные бизнес-задачи.

### Этап 1. Парсинг и структурирование спецификаций

| Параметр | Описание |
|----------|----------|
| **Входные данные** | Файлы договоров и ДС в форматах Word (`.doc`, `.docx`) и PDF (сканы и текстовые слои) |
| **Действие агента** | Извлечение табличных данных и текстовых спецификаций. Преобразование неструктурированного текста в JSON / базу данных |
| **Требования к выходу** | Четко структурированный массив строк (услуги, объемы, цены, условия). Если скан нечитаем или структура таблицы нарушена так, что парсинг невозможен, этап маркируется как **«Ошибка парсинга / Требуется ручной ввод»** |

### Этап 2. Построение кумулятивного статуса договора во времени

| Параметр | Описание |
|----------|----------|
| **Входные данные** | Цепочка документов (Основной договор → ДС №1 → ДС №2 → …), отсортированная по хронологии |
| **Действие агента** | Реконструкция истории изменений |

Агент должен уметь обрабатывать **два типа ДС**:

1. **Полное обновление** — ДС утверждает новую редакцию спецификации (полная замена статуса).
2. **Точечные изменения** — ДС меняет только отдельные позиции. Агент должен идентифицировать конкретную измененную строку в основном договоре и применить изменения (изменение цены, добавление позиции, аннулирование строки).

| Требования к выходу | Кумулятивная (актуальная на выбранную дату) спецификация договора + лог изменений по каждой строке. Если агент не может однозначно связать строку из ДС со строкой из договора, строка помечается статусом **«Конфликт изменений / Невозможно сопоставить»** |

### Этап 3. Мэтчинг артикулов с каталогом услуг

| Параметр | Описание |
|----------|----------|
| **Входные данные** | Текстовое описание позиции из спецификации договора (коды и артикулы в договорах отсутствуют) и Эталонный каталог услуг компании (с артикулами) |
| **Действие агента** | Семантическое сопоставление (мэтчинг) описания из договора с позицией каталога для присвоения артикула |
| **Требования к выходу** | Присвоенный артикул с коэффициентом уверенности (confidence score) |

> **Важно:** Процент успешного сопоставления на этом этапе может быть небольшим. При любых сомнениях (метрика уверенности ниже заданного порога или наличие нескольких похожих услуг в каталоге) агент обязан присвоить статус **«Артикул не определен / Требуется ручная привязка»**, избегая ложных срабатываний.

---

## 4. Требования к обработке исключений («Не-фантазирование»)

Для обеспечения надежности агент на каждом шаге должен руководствоваться правилом:

> **«Лучше отказ от распознавания, чем выдуманный результат».**

Система должна поддерживать **ролевую модель уверенности ИИ**:

| Статус | Описание |
|--------|----------|
| **SUCCESS** | Задача решена с высокой степенью уверенности |
| **UNRESOLVED** | Подзадача признана нерешаемой (причины: разрыв логической цепочки в ДС, отсутствие похожих позиций в каталоге, противоречащие друг другу пункты). Потребуется интерфейс для разбора таких кейсов оператором-человеком |

---

## 5. Ожидаемый результат и формат поставки

| Компонент | Описание |
|-----------|----------|
| **Пайплайн обработки документов** | Модули OCR / парсинга, логический блок работы с локальной LLM, модуль сборки кумулятивного статуса |
| **База данных** | Хранилище для структурированных версий договоров и истории их изменений |
| **UI / Экран оператора** (опционально, для MVP) | Интерфейс, где выводятся результаты сверки и подсвечиваются «проблемные» зоны, которые ИИ-агент отметил как нерешаемые |