v1.0.11: differ.cfm — сравнение spec_rows между допниками

2026-06-18 18:13:33 +04:00
parent c04b2a2fe3
commit c8605b3cb6
4 changed files with 323 additions and 1 deletions
@@ -0,0 +1,80 @@
+# Техническое задание (ТЗ)
+## Разработка ИИ-агента «Сверка договоров»
+
+---
+
+## 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) | Интерфейс, где выводятся результаты сверки и подсвечиваются «проблемные» зоны, которые ИИ-агент отметил как нерешаемые |