Наш зоопарк AI: Гендальф, Сэмуайз Гэмджи, Око Саурона и Midjourney

Привет, с вами снова Егор, Tech Lead компании ИдаПроджект. Помимо управления людьми и разработкой я еще занимаюсь внедрением новых инструментов в нашу компанию. И конечно же, мы не прошли мимо GPT и прочих AI-инструментов.

В статье я расскажу, что мы используем, как применяем — и что у нас осталось после экспериментов с GPT.

Погнали!

Ретроспектива по используемым инструментам

Картиночки в midjourney

Генерацию картинок мы начали использовать примерно с октября 2022 года. Конечно, сначала игрались и делали интерактивы внутри компании. Например, стилизовали всем аватарки под какой-нибудь праздник.

Ну или просто делали смешные мэшапы для внутреннего использования.

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

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

Рождение Гендальфа

Все началось 18 марта 2023 года.

Я выпил пива с ребятами в баре, поболтал о последних новостях с полей AI и загорелся идеей попробовать GPT на реальных проектных задачах. В рамках слегка похмельных исследований я понял, что на бизнесовых процессах GPT3.5 вообще не справлялся (например, если требовалось написать процесс грейдирования, или найти ошибки уже в существующем), но в плане кода и работы с текстом был неплох — особенно если дать ему задачу поправить или оптимизировать существующий код.

И тут мне стрельнула идея написать с помощью gpt чат-бот для mattermost для нашей компании. Вуаля — за пару часов я нагенерировал код, оформил подписку к API от openai и запустил.

И он заработал! Конечно, не сразу, и gpt писал много отсебятины, поскольку я тогда мало уделял внимания контексту. Более 70% кода (из 150 строк) мне пришлось самому дописать или переписать. Но сам факт, того, что он мог генерировать код по запросу, вызвал у меня восторг.

Потом я пошел к бизнесу, согласовал 100$ в месяц на подписку и микро сервер за пределами СНГ, развернул там наше простенькое приложение и выпустил Гендальфа на просторы нашего mattermost.

А как сейчас мы используем GPT в компании

Гендальф, он же чат бот от openAI

Первое и самое важное применение это, конечно же, обычный чат. Раньше он пользовался довольно большой популярностью, сейчас же потихоньку угасает, так как все нашли более удобные для себя решения. У нас под капотом используется gpt o3-mini. Для общего назначения очень удобная модель.

Также в нем сделали распознавание картинок, что, конечно, полезно в некоторых кейсах.

Еще туда завезли саммари тредов: удобно, когда не хочешь читать 300-400 сообщений двухнедельной давности.

Сразу отвечу на вопрос, почему мы не используем встроенный функционал copilot для mattermost. Причин две:

Все привыкли к Гендальфу
Для нормальной настройки и работы copilot нужно размещать сервер c mattermost у другого провайдера. А нам — по соображениям удобства и отказоустойчивости — не очень хочется это делать.

Поздравления с ДР

Холиварная и мемная корпоративная история, от которой уже пахнет нафталином. Мы подошли к ней с легкой иронией и использовали бота Eye of sauron, который отвечает за автоматизацию кучи процессов (отслеживание дедлайнов, пуш времени сотрудников, бюджеты, мониторинг, алерты по безопасности и много за что еще).

Автоматизация процессов

С появлением gpt3.5-turbo мы многое пробовали автоматизировать в наших процессах. Что-то зашло, а что-то не очень.

Но вообще с появлением новых мощных моделей — gpt o1-pro, gpt 4,5, gemini 2.5 pro — появилась возможность еще и полноценно дискутировать насчет процессов и находить в них проблемы. Например, я прописывал алгоритмы для нового грейдирования у наших сотрудников и потратил 3-4 часа на генерацию полноценного процесса. А на создание прототипа web-приложения, который закрыл все кейсы этого процесса, ушло два дня. Чуть позже выпустим статью про получившийся процесс грейдирования.

Аналитика по метрикам

Мы собираем довольно много аналитики: как по клиентам (что у них по задачам, как часто случаются проблемы с проектами, lighthouse, zap proxy и кучу другого), так и по внутренним процессам (насколько превышаются эстимейты, сколько задач было на человека в день, сколько сотрудников и человеко-часов обрабатывает менеджер и тимлиды и прочее). Все это мы складываем в наш DWH (он довольно простой, на базе clickhouse + airflow), а затем по требованию выгружаем информацию, складываем в контекст к GPT и просим провести аналитику.

В этом случае обычно используем Gemini от Google, так как он поддерживает 1 млн. контекста, и в него удобно сложить документы из google drive.

Кейсов метрик, которые можно достать, есть огромное количество, но сейчас мы их достаем только по запросу, когда нужно принять какое-то стратегическое решение, например:

Если расширяем команду, то смотрим на ФОТ, нагрузку ПМ и лидов, поток задач от клиента и прочее.
Если хотим сверстать бюджет на следующий год — тоже смотрим на ФОТ, средний % прибавки к ЗП, объем задач за прошлый год и т.д.

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

Скоринг заявок по запросам заработной платы

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

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

Пока это работает с 70-80% точностью, поскольку человеческий фактор никто не отменял. Поэтому мы проводим полный аудит сотрудника как по хардам (смотрим код, аварийность, общую работоспособность) так и по софтам (как общается и коммуницирует с коллегами, как ведет диалог с клиентом, как доносит свои мысли и прочее).

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

360 у team/tech lead

Тут уже автоматизация моей боли. Раньше (когда лидов было мало) мы просто проводили 1 на 1 созвоны со всеми сотрудниками и спрашивали, как человек себя показывает, что можно улучшить и все такое; в общем, типичный 360. Но когда лидов стало больше, потребовалось как-то автоматизировать и — самое главное — добавить какой-то пользы для всех в этот процесс.

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

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

Это позволяет сократить работу по обработке фидбека и его консолидации и сфокусироваться на планах и развитии лида.

Грейдирование

Мы еще не внедрили новую версию процесса, поскольку на момент написания статья только начали тестировать ее на новичках в формате MVP. Но — уже есть что рассказать и показать.

Весь процесс я полностью продумал и прописал с помощью GPT, для чего использовал gemini 2.0 flash thinking. Начал с простой постановки задачи в формате ФТ, а потом попросил GPT задать мне вопросы, чтобы максимально улучшить ФТ и найти проблемные моменты.

Тут начался vibe coding. Я параллельно смотрел на Reddit и заметил, что уже есть много постов по этой теме, так что решил сам все изучить. По факту оказалось, что это максимальная автоматизация процесса написания приложения. И если про код мне все было понятно, то, например, как отрисовать дизайн, я не знал. В итоге нашел сервис uxpilot.ai, который умеет «рисовать дизайн» (верстает его на tailwind), попросил GPT собрать ТЗ для дизайнера, скопировал, и получилось вот так:

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

Дальше дело было за малым: сделать django приложение, подключить туда htmx и на коленке написать функционал. Итого через 12 часов я получил полноценно описанный путь, заточенный под наши процессы, документацию для тех, кто занимается грейдированием и работающий MVP приложения на три экрана. Думаю, это довольно хороший результат — особенно с учетом того, что все сделал один человек.

ИдаЧат

Параллельно мы пытались понять, как можно помочь нашим клиентам с помощью GPT. Особенность нашей сферы (proptech) в том, что клиенты покупают квартиры не каждый день, и квартиру обычно выбирают довольно долго и кропотливо. Мы попытались закрыть проблему клиента с помощью чата, в котором клиент может спросить любую информацию по проекту или попросить подобрать ему квартиру для «Семьи из трех взрослых + кошки, и чтобы была солнечная сторона».

Мы его уже сделали; подробнее можно прочитать про него тут, а попробовать — при подборе коммерции на сайте А101.

Какие идеи в планах проверить

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

Проверка кода в Merge Request с помощью GPT

Идея, которая сразу пришла нам в голову, но мы тут же столкнулась с проблемой: для нормальной работы нужен контекст всего проекта. То есть, если мы закидываем в GPT только diff в merge request, то можем проверить:

Синтаксис
Сложность кода
Наличие тестов, и покрывают ли они весь функционал
Наличие комментариев
Безопасность методов

Но мы не можем проверить:

Правильно ли написан код с учетом стайлгайдов на проекте?
Правильно ли размещен код в файлах?
Использованы ли все нужные абстракции, принятые на проекте?
А все ли требования из ФТ учтены?

Чтобы все это реализовать, в контекст для проверки MR нужно положить весь связанный функционал, функциональные требования и поставленную задачу (желательно с комментариями). С учетом всего этого цена вопроса проверки одного MR будет довольно весомой, так как не в каждую GPT поместиться весь контекст.

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

Анализ git репозиториев: нахождение типовых решений, нахождение устаревшего функционала и прочего

В этом тоже моя персональная боль. У нас довольно большое количество проектов (более 50), в которых каждый день что-то делается, и в моменте сложно собрать по ним какую-то спецификацию. Например: в каких проектах используются устаревшие библиотеки, где используются фасетные фильтры с кешированием, и где нет стадии проверки на безопасность в ci\cd. Конечно, это можно делегировать разработчикам и ПМ, чтобы они асинхронно сделали работу, но как обычно, за таким решением кроется много проблем:

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

Поэтому есть идея, что можно каждый проект и файл прогнать через GPT, тегировать и сформировать по нему документацию. То есть, мы должны сделать псевдо функционал Cursor или Cline и реализовать его на всех проектах.

Пока мы только изучаем, как это оптимизировать: предварительный расчет показал, что один прогон по проектам обойдется нам от 200$ до 500$. Разово это не очень большая сумма, но возможно, нам понадобится много попыток, чтобы проверить множество вариантов запросов и прийти к единому формату вывода данных.

Проверка ТЗ и функциональных требований

Тут тоже все просто и сложно одновременно. У нас есть довольно большая база данных с ТЗ, ФТ и прочим, но не везде они хорошо описаны, и не всегда итоговый результат совпадает с техзаданием (это обусловлено сроком разработки и внесем изменений под релиз) — смысл подходить к этой истории серьезно пока теряется.

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

Заключение

Хочется повторить мысль, которую слышу довольно часто: вся польза от GPT определятся от двух вещей — контекста и запроса. Контекст должен содержать явную проблему, а запрос — решать ее. В противном случае GPT начнет штормить, и он подойдет к решению проблемы окольными путями. Так что вопрос его применения сейчас сводиться к promt-инжинирингу и подготовке данных, которые нужно положить в контекст.

На этом все! Ну а если вы тоже применяете GPT в своей работе или есть комментарии по статье — приглашаю к обсуждению в комментарии.

ссылка на оригинал статьи https://habr.com/ru/articles/896714/