contracts/hz/univ.md

этот проект - имеет какую то коммерческую ценность ? как универсальный продукт для подобных документов

Список задач обновлен

Честная оценка, на основе того, что я видел в коде и архитектуре.

Что это по сути

Движок сверки спецификаций по цепочке «договор + допсоглашения»: парсинг → извлечение строк (услуга/цена/кол-во/сумма/дата) → LLM-диф (ADD/UPDATE/DELETE) → event-sourced актуальное состояние с привязкой каждого изменения к документу-источнику. Плюс классификация документов и группировка. Это не «ещё один чат с PDF», а конкретная боль с понятной ценностью.

Где реальная ценность

• Боль настоящая и дорогая. Ручная сверка договора с десятком допников в закупках/финансах/юридическом — медленно и с ошибками в деньгах. Автоматизация с аудит-следом — это то, за что платят.
• Ядро обобщаемо. Паттерн «базовый документ + поток изменений к таблице позиций» покрывает не только договоры: прайс-листы и их обновления, тарифы, страховые полисы + эндорсменты, аренда + доп.соглашения, SLA. Движок event-sourcing под это годится почти как есть.
• Сильные стороны архитектуры под продукт уже заложены: аудит изменений (source_document_id), UNRESOLVED как human-in-the-loop, арифметические проверки, генератор тест-кейсов (testgen/), симулятор (sim/). Это редко делают на ранней стадии — хороший знак зрелости.

Что мешает быть «универсальным продуктом» прямо сейчас

• Захардкожено под РФ-спецификацию услуг: промпты, поля классификации (own_number/parent_number), понятие «спецификация». Для универсальности нужна конфигурируемая схема документа + промпты под тип (договор / прайс / полис), а не один зашитый сценарий.
• Точность = главный риск. Одна неверная сумма/строка → потеря доверия, в финансах это критично. Нужны: обязательный человеческий контроль спорных строк (основа есть), метрики качества на эталонном датасете (заготовка в testgen есть — надо довести до бенчмарка с цифрами «точность X%»).
• Робастность и контроль затрат — ровно то, что обсуждали (тихие провалы парсинга, дубли, лимиты, стоимость LLM на документ). Для внутреннего инструмента терпимо, для продукта — обязательно.
• Интеграции: экспорт в 1С/ERP/учётные системы. Без этого результат сверки «висит в вебе» и ценность ниже.

Рынок и позиционирование

• Большие CLM/contract-analytics (Ironclad, Evisort, Luminance, Kira) — это про весь жизненный цикл и поиск рисков, а узкую задачу «сверка позиций по допникам» они толком не закрывают. Здесь есть незанятая ниша.
• На РФ-рынке (СБИС/Контур и т.п.) — локальная специфика и язык как преимущество.
• Реалистичное позиционирование: не «платформа», а вертикальный SaaS / модуль для закупок и финансов SMB/mid-market: «загрузи договор и допники — получи актуальную спецификацию с аудитом изменений». Либо как встраиваемый компонент в чужой CLM/документооборот.

Вердикт

Да, коммерческая ценность правдоподобна — как сфокусированный нишевый продукт, а не платформа. Ядро обобщается на класс «базовый документ + изменения к таблице», но для «универсальности» нужны три вещи по порядку: (1) конфигурируемые схемы/промпты под тип документа, (2) доказанная точность с метриками + обязательный ревью спорных строк, (3) интеграции/экспорт. Архитектурно фундамент под это уже правильный — event sourcing с аудитом и заготовки под тестирование/симуляцию дают серьёзное преимущество перед «обёрткой над LLM».

Главный нерешённый вопрос продукта — не технологии, а доверие к цифрам: кто несёт ответственность за ошибку в сумме и как это показать клиенту. Кто решит это через прозрачный аудит + ревью — тот и продаёт.

может не именно универсальный, запустил и работает а с возможностью перестройки ядра под запросы конкретного заказчика

Список задач обновлен

Хорошо — это другая модель: «настраиваемое ядро + кастомизация под заказчика». Проверю, насколько ядро уже готово к перенастройке (промпты в БД, версионирование).

Read , lines 1 to 80

Подтвердилось важное: промпты уже вынесены в БД и версионируются (prompts.py, таблица prompts с ролями extract/diff, is_active, выбор активного), а prompt_version пишется в каждое событие. То есть значительная часть «перестройки ядра» уже делается данными, а не кодом. Это сильно меняет оценку в плюс.

Почему эта модель — правильная (и лучше «универсальной»)

«Универсальный, запустил и работает» в B2B-документах почти не существует — у каждого заказчика свои формы, поля, правила. «Конфигурируемое ядро + настройка под заказчика» — это проверенная и доминирующая модель корпоративного софта (весь экосистема 1С построена ровно на ней). Заказчик такого ждёт и за это платит. Так что вы целитесь в реалистичную нишу, а не в утопию.

Что уже играет на вас

• Промпты = данные, с версиями. Перенастроить извлечение/диф под клиента — это правка записи в prompts, не релиз. Огромный задел.
• Воспроизводимость/аудит: prompt_version и raw_llm_response пишутся в события → можно объяснить клиенту любое решение и откатить промпт. Это и тюнинг, и доверие.
• Заготовка под качество: testgen/ + метрики → можно собирать эталонный датасет под каждого заказчика и мерить точность его конфигурации.
• Event sourcing с привязкой к источнику — ядро не зависит от доменной специфики, оно про «база + поток изменений к таблице».

Где сейчас «настройка = код» (это надо вынести в конфиг)

• Схема позиции захардкожена: поля name/price/qty/sum/date_start — в колонках spec_current и в spec_events.py. У другого заказчика будут иные поля (артикул, НДС, период, ед.изм.). Сейчас это правка кода/миграции.
• Таксономия классификации (own_number/parent_number/counterparty) — зашита.
• Валидаторы (арифметика sum=price·qty) и экспорт — под конкретный домен.

Пока это код — каждый новый заказчик тянет за собой разработку. Цель — сделать вариативные точки конфигурацией («доменный пакет»: схема + промпты + правила + маппинг экспорта), чтобы новый клиент = настройка, а не форк.

Экономика модели — честно

• Плюсы: выше средний чек, выше «прилипчивость» (настроенное ядро не выкинут), естественный апсейл на новые типы документов.
• Минусы: services-heavy — внедрение/настройка тянут маржу вниз и хуже масштабируются, чем чистый SaaS. В РФ-энтерпрайзе это норма (интеграторы на этом и живут).
• Ключевая метрика бизнеса: «время вывода нового заказчика». Если настройка — это дни конфигурации, экономика продуктовая. Если месяцы разработки — вы консалтинг с кодовой базой, а не продукт.

Главный риск и как его держать

Не плодить ветки под заказчиков. Один core + набор «доменных пакетов»-конфигов. Как только появляется if customer == X в коде ядра — модель сломалась. Дисциплина: всё клиентское — в данные/конфиг, ядро остаётся общим. И второе — качество промптов под клиента нужно мерить (testgen как first-class инструмент онбординга), иначе «настройка» превратится в бесконечный ручной тюнинг.

Вердикт

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

Создано задач: 5

есть ли подобные фреймворки или системы

Список задач обновлен

Кратко, по категориям:

Contract analytics / CLM (готовые продукты):

• Evisort, Ironclad, ContractPodAi, Luminance, Kira Systems, DocuSign CLM, Icertis — извлечение полей и рисков из договоров. Но сверку позиций по цепочке допсоглашений с event-sourcing они напрямую не делают — это про метаданные и риски, не про «актуальная спецификация после N изменений».

Document AI / IDP (извлечение таблиц/полей):

• AWS Textract, Google Document AI, Azure Document Intelligence, ABBYY FlexiCapture/Vantage, Rossum, Docsumo — парсинг и извлечение структурированных данных. Это «слой парсинга», без вашей логики диффа/состояния.

LLM-фреймворки «собери сам» (то, на чём строят такое):

• LangChain / LlamaIndex, Unstructured.io (парсинг документов), Instructor / Outlines (structured JSON от LLM). Дают кирпичи, но не доменное ядро.

Российский рынок:

• Контур, СБИС, Directum, ЭОС — документооборот/ЭДО с элементами анализа. Локальная специфика, но узкой «сверки спецификаций» как продукта нет.

Diff / редлайн:

• Litera Compare, Draftable, Workshare — сравнение версий документов текстуально, не семантически по строкам спецификации.

Вывод: компонентов-аналогов много (парсинг, извлечение, CLM, structured-LLM), но именно вашей связки — «базовый документ + поток допников → event-sourced актуальная таблица позиций с аудитом» как готового продукта/фреймворка я не знаю. Это и есть незанятая ниша: вы не конкурируете с CLM, а закрываете то, что они оставляют ручным.