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

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

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

Практика внедрения нейросетей в инженерные процессы

Генерация планов проверок и работа с внутренним контекстом (RAG)

Первый логичный сценарий, с которого начали инженеры по тестированию, — автоматическое создание тест-планов на основе описания задач из трекера. Идея казалась простой: передать текстовое ТЗ языковой модели и получить готовый структурированный перечень проверок. С академической теорией тестирования модель справлялась блестяще, но при контакте с реальным продуктом начались сложности.

Модель не понимала предметную область, внутренние регламенты и специфическую терминологию. Например, название внутреннего сервиса для работы с поставщиками нейросеть упорно интерпретировала как обычный глагол из русского языка, полностью искажая логику проверок. Чтобы дать модели контекст, разработчики обратились к архитектуре RAG (Retrieval-Augmentation Generation), подключив внутреннюю базу знаний Notion/Wiki, регрессионные чек-листы и историю задач.

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

AI-ревью кода и самовосстанавливающиеся автотесты

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

Важно понимать: AI-ревью не заменяет человека полностью. Модель периодически видит ложные уязвимости — например, указывает на потенциальную ошибку NullPointer, которая уже перехвачена и исключена проверкой выше по коду. По этой причине инструмент работает исключительно как первый фильтр, снимающий базовую рутину перед проверкой старшим разработчиком.

Параллельно изменения затронули отдел автотестирования. Команда перевела тесты с Puppeteer на Playwright и задействовала ИИ для работы с версткой. Когда разработчики меняют интерфейс и тест теряет нужный элемент, нейросеть анализирует обновленное дерево DOM, подбирает актуальный селектор и предлагает готовое исправление. Инженер лишь проверяет и утверждает патч.

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

Быстрый прототип сервиса за семь рабочих дней

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

Задействовав LLM для генерации кода и базовой архитектуры, рабочую версию удалось собрать всего за две недели работы в режиме полдня — суммарно около семи рабочих дней. При этом код не пишется «наслепую»: архитектуру и бэкенд-логику проверяли и корректировали опытные инженеры. Этот кейс показал, что ИИ отлично подходит для быстрого запуска вторичных сервисов, на которые вечно не хватает ресурсов.

Автоматизация документооборота и AI-агенты в интерфейсе

Автоматическая обработка входящих счетов

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

Созданный алгоритм автоматической обработки работает по следующей схеме:

• Загрузка и распознавание первичного документа.
• Оценка полноты данных языковой моделью для принятия решения об автоматической проводке.
• Сопоставление позиций счета с исходной заявкой и каскад валидационных проверок.
• Передача документа оператору в случае минимальных сомнений или расхождений.

На текущий момент без участия человека обрабатывается около 65% входящего потока счетов. Время обработки одного документа снизилось до 5–30 секунд. В результате команду ручного ввода удалось сократить с 80 до 35 человек при постоянном росте общего объёма документов.

Главным техническим барьером остаются сложные составные комплекты. К примеру, когда в заявке указана «дверь в сборе», а поставщик детализирует её в счете на полотно, коробку, наличники и комплект фурнитуры. Если в документе несколько таких комплектов, модель не всегда корректно распределяет комплектующие по позициям. Такие случаи пока намеренно отправляются на ручную проверку. Итоговый уровень ошибок сейчас удерживается в пределах 1%, а все спорные документы используются для дообучения модели.

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

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

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

• Агент работы с данными (взаимодействует с бэкендом через API);
• Агент интерфейса (управляет элементами UI и заполняет поля);
• Агент документации (ищет регламенты и справку).

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

Автоматический подбор заявок по прайс-листам

В торговых модулях системы был реализован механизм обратного подбора заказов для поставщиков. Часто компании не успевают вручную просматривать сотни новых заявок на торговой площадке. Разработанный сервис принимает прайс-лист поставщика (через файл или API), сопоставляет номенклатуру с историческими данными продаж и автоматически подбирает релевантные аукционы.

В качестве пилота систему протестировали на категории строительных материалов (геотекстиль). Сервис самостоятельно находил подходящие заявки и формировал коммерческие предложения. После быстрой проверки человеком было выставлено 19 счетов, один из которых завершился реальной оплатой, подтвердив жизнеспособность связки.

Практические выводы: как работать с ИИ без иллюзий

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

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

Источник: habr.com