R2ABench: от требованиям к архитектуре или почему умения в PlantUML ещё не делает LLM архитектором (Рубрика #Architecture)
Прочитал свежую версию статьи про R2ABench. Авторы пытаются ответить на хороший вопрос: может ли LLM превратить требования в архитектурное представление системы, а не просто нарисовать правдоподобную схему? Короткий ответ: компоненты модели находят неплохо, но архитектура начинает рассыпаться на связях, обоснованиях этих связей и трассировки решений от требований (traceability).
R2ABench состоит из 68 проектов: 17 магистерских учебных работ с формализованными требованиями и 51 open-source проекта с GitHub. Для каждого есть
- Нормализованная спецификация требований (SRS, Software Requirements Specification) - это стандарт из 1983 года
- Эталонное архитектурное представление в PlantUML
- Ссылки от требований к исходным свидетельствам
Причем в учебных проектах SRS были изначально, а вот для GitHub проектов его восстановили из README, документации, интерфейсов, entry points и конфигурации репозитория. Черновик собирал GPT-5.4, Claude Opus 4.8 искал противоречия и неподтверждённые утверждения, затем замечания проверяли три человека. Согласие между рецензентами получилось существенным: Fleiss' κ = 0.763. То есть это не совсем greenfield-задача «сырой PRD → новая архитектура», а частично реконструкция уже реализованной системы.
В эксперименте четыре модели - GPT-5, Claude Sonnet 4.6, DeepSeek V3.2 и Qwen3-Coder 480B-A35B - запускали напрямую и через MetaGPT, OpenHands и Mini-SWE. Получилось 1088 архитектурных представлений. Проверка шла в три слоя:
- Рендерится ли PlantUML и разбирается ли он в граф;
- Совпадают ли компоненты, связи, слои и топология с reference view;
- Покрывает ли схема требования и ASR (значимые архитектурные требования), можно ли проследить решения до evidence, разумна ли декомпозиция и легко ли читать результат.
Последний слой оценивал GPT-5.4-mini. Чтобы не принимать LLM-as-a-Judge на веру, авторы сопоставили его оценки с независимой разметкой 272 работ: 72.77% оценок отличались от человеческого консенсуса не больше чем на один балл, средняя абсолютная ошибка составила 0.53 по пятибалльной шкале.
Главный результат - резкий разрыв между существительными и глаголами архитектуры (компонентами и связями их между собой). Покрытие эталонных компонентов у разных конфигураций было от 0.669 до 0.849, а Edge F1 ни разу не поднялся выше 0.176. А Edge F1 тут измеряет, насколько правильно модель восстановила направленные связи между архитектурными компонентами: вызовы, зависимости и потоки данных. Например, эталон содержит:
API → Order Service → Payment Adapter → Payment Gateway
Если модель пропустила связь с Payment Adapter или придумала Order Service → Redis, это ухудшает оценку.
Авторы отдельно проверили часть пропущенных связей: 27.9% действительно нельзя было вывести из SRS. Но даже после исключения таких случаев агрегированный Edge F1 остался около 0.11. В общем, если говорить простыми словами, то модель часто понимает, что в системе должны быть API, сервис платежей и база данных, но не восстанавливает, кто кого вызывает, где проходит поток данных и каким требованием оправдана зависимость. Среди структурных ошибок 39.1% пришлось на выдуманные связи и ещё 30.2% - на выдуманные компоненты. На семантическом уровне чаще всего терялись traceability и архитектурно значимые требования.
Ещё один полезный результат: агентная обвязка не дала устойчивого выигрыша. Qwen3-Coder с OpenHands показал лучшие Edge F1 и graph-edit score, но успешно сгенерировал разбираемый PlantUML только в 54.4% случаев и уступил прямому GPT-5 по всем семантическим измерениям. Агентская обвязка меняла профиль ошибок, а не превращала модель в надёжного архитектора.
Для меня здесь два практических вывода.
1️⃣ Архитектурную диаграмму от LLM стоит считать гипотезой, а не решением. Проверять нужно не наличие знакомых коробок, а каждую важную связь: какое требование или ADR её подтверждает, какой quality attribute она реализует и что сломается при её изменении. 2️⃣ Eval для AI-архитектора нельзя сводить к валидному PlantUML, похожести графа или одной оценке judge-модели. Нужны раздельные проверки синтаксиса, структуры, покрытия ASR, evidence grounding и двусторонней traceability. Иначе мы измерим аккуратность рисунка, а не качество архитектурного рассуждения.
У работы есть значимые ограничени - Размер всего в 68 проектов - Лдин reference view на систему - Более полные SRS (Software Requirements Specification), чем обычно бывают в начале разработки - Модели семейства GPT-5.4 одновременно участвуют в подготовке данных, выравнивании графов и оценке результата (same-family bias) - Ну и почти 100% вероятность попадания GitHub-проектов в pretraining моделей
Но как инженерный сигнал R2ABench полезен. LLM уже может быстро собрать первый архитектурный черновик. Самая дорогая часть работы остаётся прежней: доказать связи, удержать ограничения и объяснить, почему система устроена именно так.
P.S. Для любителей покрутить аналитику самим - данные бенча доступны здесь
#Architecture #AI #AI4SDLC #Engineering #Research #Evals