Месяц назад в посте я рассказывал о проектах для магистрантов, в которых хочу продолжить развивать свои архитектурные подходы и AACT (инструменты автоматизации моих подходов — например, прогона архитектурных тестов). Сейчас к запуску готовятся три проекта. У каждого своя задача, но в перспективе их результаты можно будет использовать вместе. ⏺ Тренажёр архитектурных решений. Пользователь предлагает архитектурное решение конкретной задачи и объясняет, почему выбрал его. ИИ-оппонент ищет слабые места, а ИИ-судья оценивает, насколько хорошо решение обосновано. Хотим понять, получается ли у нейросети давать полезную обратную связь и насколько её оценки совпадают с экспертными. ⏺ Бенчмарк архитектурных изменений. Проверим, как нейросети при доработке проекта меняют его архитектуру: соблюдают ли принятые ограничения на связи между компонентами и доступ к их внутренностям. Посмотрим, помогает ли явно передать агенту архитектурные правила. ⏺ ИИ-ревьюер. Попробуем находить нарушения этих правил в предложенных изменениях. Сравним агента, который читает документы с ADR (архитектурными решениями), проверку через AACT и их связку. Посчитаем пропущенные нарушения и ложные замечания. Для экспериментов мы с проектными командами соберём архитектурные задачи с понятными условиями. В них будет описано, какие части системы можно менять независимо, кто к кому может обращаться и какие договорённости (ADR) нужно сохранить при доработке. Подготовим варианты с нарушениями и без, чтобы было с чем сравнивать ответы инструментов. Часть таких ситуаций пригодится всем трём командам. В тренажёре можно обсудить решение и его последствия. В бенчмарке — проверить, соблюдает ли нейросеть ADR, когда вносит изменения. Затем предложить ревьюеру найти нарушения в полученном результате. При этом правильные ответы придётся определять независимо от проверяемого инструмента. Если взять вывод AACT за эталон и сравнивать с ним агента — мы заранее назначим мой инструмент правым. С ИИ-судьёй похожая задача: нужно разобраться, что он оценивает и почему расходится с экспертами. В перспективе я вижу совместное применение примерно так. Разработчик разбирает архитектурное решение в тренажёре, уточняет обоснование и ограничения. По результатам бенчмарка команда выбирает агента и условия его работы, при которых он лучше соблюдает архитектурные договорённости. Агент вносит изменения, ревьюер проверяет их перед слиянием. А найденные и разобранные ошибки пополняют учебные задачи и следующие версии бенчмарка. До такой связки ещё надо дойти: сначала каждый проект должен показать, что его результату можно доверять в известных нам пределах. Может выясниться, что в выбранных случаях агенту достаточно документов и AACT ничего не добавляет. Или что судья завышает оценки за многословие. Меня такие результаты тоже устроят, если мы сможем показать, как их получили и где они повторяются. Для меня это продолжение работы над доказательной архитектурой. Хочется разобраться, какую часть проверки архитектурных решений уже можно поручить нейросети, какие правила стоит проверять автоматически, а где пока требуется участие человека. 😛 _______ Источник | #rsa_enc