AI Project Manager Assistant: Как обучить AI агента понимать различия между Backend и Frontend и сделать долговременную память
Чтобы лучше понимать, о чем пойдет речь дальше, советую сначала вернуться к первым статьям и ознакомиться с ними, а мы двигаем дальше.
Сегодня я расскажу, как цифровой собрат научился учитывать различия между описанием Backend и Frontend и обрёл необходимую долговременную контекстную память.
Как появилась идея разделить бэк, фронт и дизайн
Я показал первые созданные задачи коллегам и получил пачку комментариев с пожеланиями. По каждому компоненту у ребят были свои комментарии. Дизайнерам нужен один формат, фронтендерам (*_*) другой, бэкендерам (-_-) третий.
Я дополнил системный промпт жёсткой маршрутизацией по компонентам с конкретными режимами генерации.
Ниже пример, как это может выглядеть:
СТРУКТУРА ЗАДАЧИ И МАРШРУТИЗАЦИЯ (ID КОМПОНЕНТОВ):
Сначала проанализируй текст и определи component. В зависимости от компонента, включи соответствующий режим генерации и используй правильный ID («Цифры 1, 2, 3 здесь для примера, в реальности туда вшиваются системные ID компонентов из вашей Jira»):
После внесения этих режимов ИИ стал адаптироваться под нужды того или иного компонента и описание задач стало уникальным для разных команд разработки
А что насчёт долговременной памяти?
Я понял, что для описания связанных задач и в целом для понимания цифрового собрата необходимы данные о том, какие задачи мы уже поставили, чтобы можно было опереться на их контекст, какие изменения в них вносили в продукте и тд. Без долговременной памяти и возможности найти уже решённые задачи в проекте качество описания сильно страдает. Больше контекста — лучше понимание связей.
Представьте: нейронка поставила задачу на фронт по добавлению кнопки. Следующей задачей я говорю: «Для фронтовой задачи такой-то нужна на бэке ручка, которую будет дергать фронт». Нейронка должна найти ту задачу, проанализировать её описание и сформировать задачу на бэк с учетом фронтовой задачи.
Еще один частый кейс это решение типовых задач и было бы супер искать уже закрытые задачи из истории и брать схожий сценарий реализации для однотипных фич.
Чтобы все это реализовать, я добавил в автоматизацию Make несколько модулей.
Модуль-экстрактор: вытаскиваем ключевые слова
Первый модуль с AI Gemini. Он берёт мой оригинальный запрос и достаёт из него ключевые слова для поиска.
Ниже пример, как это может выглядить:
После того как экстрактор достал ключевые слова, мы парсим JSON для удобства и корректной работы.
Поиск в Jira по ключевым словам
Результаты из JSON мы отправляем в поиск задач в Jira через модуль Search Issue. Ищем только успешно закрытые задачи за последний год, чтобы не было старых, неактуальных и незакрытых.
Важный момент: модуль анализирует не только описание задачи, но и технический дизайн (то, как разработчик делал задачу). Так описание новых задач становится более точным, потому что ИИ не придумывает, а берет уже готовый и описанный путь реализации.
Google Sheets как долговременная память
Дальше идёт модуль поиска в Google Sheets. Но чтобы эта память всегда была актуальной, я добавил запись: сразу после создания задачи и отправки её в Slack она автоматически попадает в Google Sheets.
Вот какие столбцы в таблице:
Получается замкнутый цикл.
После постановки задачи он заполняет все столбцы, актуализируя свою память. При следующей постановке он смотрит в этот файл, достаёт задачи, которые ставил раньше, и передаёт их в основной ИИ-модуль.
Как цифровой собрат использует память в основном промпте
В основном промпте я прописал специальные правила
Ниже пример, как это может выглядить:
Теперь нейронка видит не только текущий запрос, но и историю. Она может связать две задачи, опереться на уже принятые технические решения и не изобретать велосипед.
На скриншоте ниже выделены модули отвечающие за память, а именно Модуль-экстрактор -> Поиск в Jira -> Поиск в Google Sheets -> Сохранение новой поставленной задачи в Google Sheets.
Что дальше?
Мы получили агента, который учитывает специфику команд и помнит, что делал раньше. Но это еще не все, полностью со всех сторон описать продукт и быть уверенным в задачах на 100% быть около невозможно, как же быть?
В следующей статье я расскажу о том, как я научил ИИ задавать вопросы, если не хватает контекста, а не галлюцинировать и позориться. Как его научить работать с ответами и вшить это в архитектуру цифрового раба))
P.S. Леха, прошу прощения за долгое отсутствие
Апрельская погода и минцифры уронили меня в тильт и желания писать статьи пропало, спасибо, что зарядил меня мотивацией продолжать писать