Полгода экспериментов с ИИ: RAG, AI-ревью, автотесты, агенты и автообработка счетов

Мы в Синтеке разрабатываем софт для строительства, а отрасль сейчас переживает сложный период. Когда тяжело стройке, это довольно быстро чувствуют и компании, которые делают для неё ИТ. Поэтому в начале года у нас появилась общая задача от руководства и инвесторов: пересмотреть внутренние процессы и искать способы экономить время и ресурсы без потери качества. Отдельно попросили посмотреть, где в этих процессах можно использовать нейросети и AI-агентов. 

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

К августу экспериментов накопилось достаточно для внутреннего митапа. Там говорили уже о вполне прикладных вещах: как дать модели знания о продукте, что делать с ложными замечаниями в ревью, как чинить автотесты и что происходит, когда ИИ начинает работать не с демо, а с реальными рабочими задачами.

Собрали несколько историй с митапа в один обзор. В детали здесь специально не уходим — наиболее интересные кейсы разберём отдельно.

Хотели генерировать планы проверок — пришлось разбираться с внутренним контекстом

Перед оценкой новой задачи тестировщики составляют план проверок. Первой идеей было отдать описание задачи LLM и получить такой план автоматически.

С теорией тестирования модель справлялась, а с нашим продуктом — заметно хуже. Она не знала внутренних ролей, регламентов и терминов. Например, «Продавай» — название нашего рабочего сайта для поставщиков — воспринимала как обычный глагол.

После нескольких экспериментов с внутренней Wiki команда остановилась на RAG, а затем добавила регрессионные чек-листы и задачи из трекера. Казалось бы, чем больше знаний, тем лучше. Получилось наоборот: похожая информация встречалась в разных источниках и немного различалась, поэтому ответы стали хуже и начали занимать больше времени. 

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

AI-ревью делает первый проход за минуту, а автотесты учатся чинить локаторы

Для первичного ревью кода сделали review.ai. Разработчик переводит задачу на ревью, сервис забирает коммиты и diff из GitLab, отправляет их модели и примерно за минуту возвращает список замечаний. При повторной проверке смотрит только новые изменения. 

Полностью полагаться на результат пока нельзя. Например, модель может увидеть потенциальный NPE, который на самом деле исключён проверкой выше по коду. Поэтому review.ai остаётся первым проходом перед человеком, а не заменой обычного ревью. 

В автотестах команда перешла с Puppeteer на Playwright и начала использовать AI-инструменты для работы с локаторами и разбора падений. Если после изменения интерфейса тест перестал находить элемент, модель может изучить страницу, предложить новый селектор и план исправления. Изменения при этом контролирует и подтверждает инженер. 

На второй линии поддержки LLM используют для разбора ошибок и подготовки SQL-запросов. В рабочий проект передали информацию о схемах, индексах и связях базы, чтобы модель могла помогать с запросами. 

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

Версию сервиса аккредитации с LLM собрали за семь рабочих дней

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

Строительная компания задаёт требования к контрагентам, поставщики заполняют данные и прикладывают документы, а после проверки формируется реестр аккредитаций. Внутри есть авторизация, компании, пользователи и ролевая модель.

Ручную разработку такого сервиса оценивали в несколько месяцев. Версию с LLM собрали за две недели работы по полдня — около семи рабочих дней. При этом код не оставался без проверки: решения просматривались и корректировались по ходу работы, особенно на бэкенде.

Около 65% счетов уже проходят автообработку

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

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

Так без участия оператора проходит около 65% счетов. На обработку подходящего документа уходит примерно 5–30 секунд. При этом количество счетов продолжает расти, а число людей, занятых в ручной обработке, сократилось примерно с 80 до 35. 

Самая заметная проблема пока — комплекты. Например, в заявке может быть одна дверь, а в счёте она раскладывается на полотно, фурнитуру, наличники и другие позиции. Если таких комплектов несколько, системе нужно ещё правильно понять, какая деталь к какому комплекту относится, и пересчитать количество. Такие сценарии пока в автообработку не включают. 

Ошибки остаются: сейчас их около 1%, а у некоторых заказчиков показатель бывает выше. Счета, которые пользователи отмечают как неверно обработанные, отдельно анализируют и используют для дальнейшего обучения модели.

AI-агента встроили прямо в интерфейс Синтеки

Команда разрабатывает AI-агента в виде чат-виджета внутри Синтеки. Пользователь может задать ему вопрос по данным системы, а в более сложном сценарии — попросить выполнить действие в интерфейсе. Например, агент может найти нужную информацию, открыть страницу и заполнить форму.

Запрос пользователя сначала получает LLM-оркестратор. Он определяет, что нужно сделать, и подключает специализированных AI-агентов: один работает с данными через бэкенд, другой — с интерфейсом, третий ищет информацию в документации. Такое разделение помогает не загружать одну модель всем контекстом сразу. 

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

Сервис подбирает поставщику заявки по его прайсу

Ещё один эксперимент появился вокруг Закупай. Проблему сформулировали сами поставщики: заявок на площадке много, и часть из них они просто не успевают просматривать и обрабатывать.

Поставщик может загрузить прайс вручную или передать его по API. Сервис сопоставляет номенклатуру из прайса с историческими данными и подбирает заявки, на которые поставщик может откликнуться. Этот сценарий уже используют в работе. 

Один из тестов провели на геотекстиле. Сервис находил на Закупай подходящие заявки и готовил счёт. Перед отправкой результат проверял человек.

Так выставили 19 счетов на геотекстиль. Один из них в итоге оплатили. 

Итог — сесть и разобраться

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

Как сказал один из коллег на митапе, есть третий вариант — сесть и разобраться.

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

Собственно, этим команды последние полгода и занимались. Где-то эксперимент остался экспериментом, а где-то из него получился рабочий инструмент.

Продолжение будет

Если вам интересно ИТ в стройке — подписывайтесь на наш блог. Мы рассказываем о разработке отраслевого софта и о том, как устроены строительные процессы вокруг него.

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