93 lines
15 KiB
Markdown
93 lines
15 KiB
Markdown
этот проект - имеет какую то коммерческую ценность ? как универсальный продукт для подобных документов
|
||
|
||
Список задач обновлен
|
||
|
||
Честная оценка, на основе того, что я видел в коде и архитектуре.
|
||
|
||
## Что это по сути
|
||
Движок **сверки спецификаций по цепочке «договор + допсоглашения»**: парсинг → извлечение строк (услуга/цена/кол-во/сумма/дата) → 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 [](file:///home/naeel/nubes/contracts/contracts-flask/deploy/db/prompts.py#1-1), 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, а закрываете то, что они оставляют ручным. |