From c8605b3cb673416925287c8e31713f7200ea4d66 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CNaeel=E2=80=9D?= Date: Thu, 18 Jun 2026 18:13:33 +0400 Subject: [PATCH] =?UTF-8?q?v1.0.11:=20differ.cfm=20=E2=80=94=20=D1=81?= =?UTF-8?q?=D1=80=D0=B0=D0=B2=D0=BD=D0=B5=D0=BD=D0=B8=D0=B5=20spec=5Frows?= =?UTF-8?q?=20=D0=BC=D0=B5=D0=B6=D0=B4=D1=83=20=D0=B4=D0=BE=D0=BF=D0=BD?= =?UTF-8?q?=D0=B8=D0=BA=D0=B0=D0=BC=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Files/TZGemini.md | 80 +++++++++++++++++ Files/tz-sverka-dogovorov.md | 74 +++++++++++++++ differ.cfm | 168 +++++++++++++++++++++++++++++++++++ index.cfm | 2 +- 4 files changed, 323 insertions(+), 1 deletion(-) create mode 100644 Files/TZGemini.md create mode 100644 Files/tz-sverka-dogovorov.md create mode 100644 differ.cfm diff --git a/Files/TZGemini.md b/Files/TZGemini.md new file mode 100644 index 0000000..2e95ed6 --- /dev/null +++ b/Files/TZGemini.md @@ -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) | Интерфейс, где выводятся результаты сверки и подсвечиваются «проблемные» зоны, которые ИИ-агент отметил как нерешаемые | \ No newline at end of file diff --git a/Files/tz-sverka-dogovorov.md b/Files/tz-sverka-dogovorov.md new file mode 100644 index 0000000..472fdff --- /dev/null +++ b/Files/tz-sverka-dogovorov.md @@ -0,0 +1,74 @@ +# ТЗ: Агент «Сверка договоров» + +## Контекст + +Есть договоры и дополнительные соглашения (допники) с клиентами. Файлы в форматах 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) | +| Логирование | Каждый шаг (файл → задача → результат / ошибка) фиксируется | + +--- + +## Критерии успеха + +- Структурированная спецификация получена или задача явно помечена как нерешаемая +- История изменений по допникам построена корректно +- Ни одно изменение не применено «наугад» без идентификации строки +- Итоговый отчёт читаем и проверяем вручную diff --git a/differ.cfm b/differ.cfm new file mode 100644 index 0000000..f899c9e --- /dev/null +++ b/differ.cfm @@ -0,0 +1,168 @@ + + + + + + + + + + + + + + SELECT id, type, created_at + FROM supplements + WHERE contract_id = + ORDER BY created_at DESC + LIMIT 2 + + + + + + + + + + + SELECT row_num, name, price, qty, sum, date_start + FROM spec_rows + WHERE supplement_id = + ORDER BY row_num + + + + SELECT row_num, name, price, qty, sum, date_start + FROM spec_rows + WHERE supplement_id = + ORDER BY row_num + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + INSERT INTO spec_history (contract_id, supplement_id, row_num, change_type, old_values, new_values) + VALUES ( + , + , + , + , + ::jsonb, + ::jsonb + ) + + + + + + + + + + + + + + + + +#serializeJSON(result)# diff --git a/index.cfm b/index.cfm index 632f1e9..6e7d5a7 100644 --- a/index.cfm +++ b/index.cfm @@ -1 +1 @@ -OK v1.0.10 +OK v1.0.11