Часть 1. Зачем делить задачу на контуры

Привет, друзья!👋

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

Давайте начнем с самого начала. Вообще почему такая проблема появилась и как к ней пришли?

Первое, с чем столкнулись в разработке, — это проблема перекидывания инфы из одного чата в другой. Сессия открыта, контекст от старта анализа до разработки уже достиг 40%, и возникла необходимость открыть новое окно и продолжать там общаться. Зачем переключаться после заполнения 40% контекстного окна? Для достижения максимальной точности работы LLM (больших языковых моделей) лучше всего использовать до 40–50% от заявленного контекстного окна модели.

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

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

Второй контур — это описание архитектуры. Тут мы работаем с бизнес-доками относительно нашего продукта. На вход отправляем то, что получилось на первом контуре, и уже в новом контекстном окне работаем над метчингом всего, что есть, с точки зрения архитектуры. Описываем новый/старый функционал уже на основе кодовой базы продукта. АПИшки, бизнес-объекты, их атрибуты и т.п. Уже этот результат мы можем направить на новый контур.

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

Четвертый контур — тестирование. Тут пишем тесты API и UI, проверяем код на соответствие требованиям, заранее установленным по вашему продукту. Читал, что у некоторых есть практика по написанию кода по предыдущим этапам, а потом разработка этого кода, но уже по TDD, и в финале их сравнивают. Интересно, но мне кажется, вначале это избыточно.

Что получается? На каждом контуре у вас отдельная сессия в чате, контекстное окно не успевает заполниться до тех самых 40–50%. Также мы можем ревьюить результаты и править на каждом контуре. Не сразу кидаем задачу, а дробим ее на этапы.

Руками все это собирать долго, но есть инструмент, который сильно упрощает жизнь. Про него расскажу во второй части)