Запрос к Claude Sonnet: архитектура сервиса "Сверка договоров"

Контекст

Мы строим Flask-сервис для автоматизированной обработки договоров и допников.

Исходная постановка задачи (от заказчика):

Спецификации договоров разобрать до структурированного вида
Собрать из цепочки допников кумулятивный статус договора — состояние во времени. Важно: иногда в допнике новое состояние договора целиком, иногда — только изменения, и нужно идентифицировать изменённую строку.
(опционально, малый процент случаев) сопоставить артикул по описанию с каталогом услуг (кодов в спецификациях нет)

Критичные ограничения:

Данные строго конфиденциальны → LLM только своя (aillm.ru 120B), данные не покидают облако
На каждом этапе возможны исключения — не фантазировать, а отметить конкретную элементарную подзадачу как нерешаемую
Рассматриваем как задачку для ИИ

Ключевое требование заказчика

НЕ МОНОЛИТИТЬ. Всё делать небольшими НЕЗАВИСИМЫМИ слоями. Каждый слой — отдельный Python-файл, своя зона ответственности. Слои не должны зависеть друг от друга (или минимально).

Что уже сделано

site/
├── app.py          ← Flask-приложение, класс ContractsApp, только сборка слоёв
├── db.py            ← слой БД: connect(), query(), _pg_connect()
├── test_routes.py   ← Blueprint /test (статус БД, список таблиц, SQL, createdb)
├── parser.py        ← слой парсера: parse(bytes, mime) → полный слепок docx/pdf
├── textify.py       ← слой: elements JSON → линейный текст для LLM
├── static/
└── templates/

База: PostgreSQL, всё внутри облачного кластера. LLM: aillm.ru (120B модель).

Что предстоит сделать

Слой загрузки — приём файлов через API, сохранение в БД (original_bytes + parsed_text)
Слой LLM — отправка текста → модель → структурированные строки спецификации
Слой хранения — таблицы contracts, supplements, spec_rows, spec_history
Слой сравнения (diff) — сравнение строк между допниками, выявление изменений
Слой API — отдача истории договора, списка, etc.

Вопрос

Разъясни план архитектуры:

Правильно ли разбиты слои? Может что-то объединить или наоборот — разделить?
В каком порядке их создавать?
Как организовать поток данных между слоями, чтобы они оставались независимыми?
Как должен выглядеть основной оркестратор (app.py) — без бизнес-логики?
Какие потенциальные проблемы ты видишь с таким подходом?

Текущий код для ознакомления

parser.py (bytes → JSON elements)

Использует python-docx для docx, libreoffice для .doc, pdfplumber для PDF, zipfile для zip. Возвращает полный слепок: все абзацы (со стилями) + все таблицы (все строки). Ничего не фильтрует, не теряет.

textify.py (JSON elements → текст)

Форматирует elements в линейный текст: параграфы как [Style] text, таблицы как | cell | cell |. Тоже не фильтрует, только форматирует.

db.py (БД)

connect() в целевую БД, _pg_connect(dbname) в любую, query(sql) — выполнить произвольный запрос.

test_routes.py (/test Blueprint)

GET /test — статус БД, POST /test с действиями: status, tables, sql, createdb. Мост к БД извне для отладки.

Ожидаемый формат ответа

Структурированный план архитектуры с пояснениями по каждому пункту вопроса.

5.1 KiB Raw Blame History