ИИ считает смету: где здесь продукт, а где грабли

«Научить ИИ считать сметы» — заявка, которая приходит всё чаще. Разберу такой запрос честно: что здесь действительно продукт, где спрятаны грабли и какие вопросы надо задать до того, как написана первая строка кода.

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

Не «ИИ, который считает сметы». Конвейер:

техзадание или спецификация в любом формате → распознавание и разбор документа → извлечение позиций работ и объёмов в структурный вид → сопоставление каждой позиции с расценкой из базы → расчёт по формулам → генерация файла в форме сметы → бесплатное превью, полный файл после оплаты.

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

Это первое, что стоит осознать заказчику: доля «искусственного интеллекта» в проекте меньше, чем кажется по названию, а объём обычной работы — больше.

Правило, без которого продукт опасен

Цифры не должны приходить от нейросети.

Модель делает ровно две вещи: вытаскивает позиции работ из текста и подбирает к каждой расценку из справочника. Умножение объёма на цену, накладные расходы, прибыль, налог — считает обычный код по базе.

Как только модели разрешено «прикинуть цену», сервис становится генератором правдоподобной чуши. Смета будет выглядеть безупречно и содержать выдуманные числа. Подрядчик подпишется под этой цифрой, начнёт работу и попадёт на деньги — а виноват будет сервис.

Это не осторожность, а граница применимости технологии. Языковая модель хорошо понимает текст и плохо отвечает за точность чисел. Архитектура должна использовать первое и не полагаться на второе. Ту же логику разбирал в статье про рассуждающие модели для бизнеса.

Три вещи, которые убили бы проект

Откуда берутся объёмы. Смета — это объём, умноженный на расценку. Объёмы берутся из чертежей, ведомости работ или обмеров. Если в задании написано «отремонтировать санузлы», там нет ни метров трубы, ни квадратов плитки — и честно придумать их нельзя. Значит, на входе обязательна спецификация или форма, где пользователь сам добивает объёмы. Это надо признать в продукте, а не надеяться, что модель догадается.

Откуда берётся база расценок. Здесь развилка на два разных продукта.

Ремонт детского сада — это, скорее всего, муниципальный заказ, то есть правая колонка. Сантехника у частника — левая. Это два разных продукта, и первая версия должна быть только одним из них.

Есть ли спрос. Технически сервис делается. Гораздо больший риск — что мелкому подрядчику он не нужен за названную цену, потому что смета требуется раз в квартал и её просят у знакомого сметчика. Это проверяется до кода и стоит ноль.

Как я предложил это делать

Неделя нулевая — проверка гипотезы без единой строчки кода. Берём пять реальных пар «задание → готовая смета», которые заказчик уже делал руками. Прогоняем задания через модель с его же прайсом. Сравниваем с настоящими сметами. Расхождение стабильно в пределах десяти-пятнадцати процентов — продукт есть. Сорок процентов — надо менять постановку. Два дня работы экономят два месяца.

Первая версия — с человеком в контуре. Обещанные «два часа до письма» — это не техническое ограничение, а подарок: за два часа сметчик успевает открыть черновик и поправить. Первые месяцы так и работаем: модель делает основную часть, человек проверяет пятнадцать минут. Клиент получает качество, вы получаете размеченные данные на каждой заявке. Полная автоматизация — потом, когда доля правок упадёт.

Оферта с оговоркой. Результат — предварительный расчёт, а не оферта. Это должно быть написано и принято заказчиком до запуска, а не после первого спора.

Двадцать один вопрос

Полный список ушёл заказчику; здесь — те, что чаще всего остаются без ответа и потом дорого стоят.

Есть ли двадцать-пятьдесят реальных пар «задание → смета» и можно ли их использовать? Без них нет ни настройки, ни проверки качества.

Какое расхождение с правильной сметой считается приемлемым — десять процентов, двадцать? Без этого числа невозможно сказать, работает сервис или нет.

Кто проверяет результат первые месяцы: заказчик сам, наёмный сметчик, никто?

Что происходит, если по расчёту подрядчик занизил цену и ушёл в минус?

Откуда придут первые сто клиентов и есть ли хотя бы пять человек, сказавших «я бы за это заплатил»?

Частые вопросы

Разве современные модели не считают хорошо?

Они считают заметно лучше прежних, но вопрос не в арифметике, а в ответственности. Число, полученное детерминированным кодом по справочнику, можно воспроизвести и проверить. Число, полученное моделью, воспроизводится не всегда — и объяснить его происхождение заказчику нечем.

Зачем человек в контуре, если это дорого?

Потому что первая же кривая смета на крупную сумму убивает репутацию сервиса, а стоит проверка пятнадцать минут. Плюс каждая проверка даёт размеченный пример — то, на чём система становится лучше.

Можно ли начать сразу с нормативных смет?

Можно, но это другой продукт, другая цена ошибки и отдельный вопрос прав на использование справочников. Начинать лучше с коммерческих: там ошибка стоит маржи, а не провала экспертизы.

Сколько занимает проверка гипотезы?

Два дня, если у заказчика есть пять готовых пар документов. Если их нет — это само по себе ответ: значит, процесса, который мы автоматизируем, пока не существует.

Коротко о главном

Идея рабочая, но её ценность не в том, что «ИИ считает смету», а в том, что с мелкого подрядчика снимают рутину, которую он не умеет делать. Поэтому начинать надо не с сайта, а с двадцати старых смет заказчика и теста на пяти заданиях.

И два правила, которые я бы не менял ни при каких условиях: цифры считает код, а не модель; первые полгода за спиной у системы стоит живой специалист.

Если у вас есть похожая идея — принесите её до разработки, а не после. Разберу по тем же пунктам: где продукт, где грабли и что проверяется за два дня вместо двух месяцев. Напишите в Telegram, MAX или VK.