Модели контролируют соблюдение ADRs

Пока в научных лабораториях и постфактум

В феврале 2026 появилось исследования Evaluating Large Language Models for Detecting Architectural Decision Violations, выявляющее, способность больших языковых моделей контролировать соблюдение архитектурных решений. И способность такую у LLM исследователи, в общем и целом, подтвердили. Можно ли доверять результатам такого исследования? Априори нет. Давайте разберемся с дизайном

В качестве исходной выборки взяли известный список репозиториев с github из исследования Using Architecture Decision Records in Open Source Projects – An MSR Study on GitHub Я недавно о нем рассказывал в своем видео Модернизация процесса проектирования (ссылка с 25 минуты)

Обновили список, выяснив какие из репозиториев доступны на текущий момент , выбрали из них те, где больше 30 тыс. строчек кода, больше тысячи коммитов и где ADRs напоминали какой-либо из известных форматов. В общем, в итоге получилось 109 репозиториев и 980 файлов ADRs, внутри которых исследователи насчитали 1317 решений, а дальше началась магия.

Первой работала «Большая Рассуждающая Модель» LRM (Marco-o1), которая читала код и выносила свое решение об исполнении или нарушении архитектурных решений. Код она читала не весь. Исследователи запилили маленький RAG, порезав исходник на чанки и положив эмбеддинги в векторную базу FAISS. После того, как первая модель вынесла своё решение его независимо оценивали три модели валидатора (Mistral-NeMo-Instruct-2407, Qwen3-14B-Base, Llama-3.1-8B-Instruc). Наверное, самое интересное в этой работе, что результаты таких проверок показали довольно хорошее совпадение (подробней см. в статье). На третьем этапе в игру вступали люди. По формуле Кохрейна (Cochran’s formula) для проверки такого количества экспериментов с 95% доверительным интервалом и 5% погрешностью достаточно было посмотреть 305 решений, что люди и сделали. Таблички и картинки с совпадениями мнений моделей и людей внутри работы. Интересно посмотреть, где мнения людей и машин не совпали и мнения людей почему LLM-ошиблись

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

ADR label	#	Percent
Infrastructure and Deployment-Specific	39	42.39%
Principle-Driven or Intent-Oriented	24	26.09%
System and Module Interaction	16	17.4%
Logic or Condition-Intensive	9	9.78%
Context-Dependent	4	4.35%

Где названия категорий означают:

• Infrastructure and Deployment-Specific decisions Решения касались таких технологий как Docker, Kubernetes, CI/CD pipelines или специфики развертывания у конкретного облачного провайдера. Модели не понимали семантику и некоторые подразумеваемые положения и что-то считали отступлением от архитектуры
• Principle-Driven or Intent-Oriented decisions Решения, основанные на принципах или намерениях представляли собой второй по величине источник ошибок. Они отражали архитектурные рекомендации, основанные на принципах проектирования или субъективных целях качества, которые были порой слишком абстрактны
• System and Module Interaction decisions Решения о взаимодействиях модулей, компонент и сервисов, особенно предполагающие многошаговые модели коммуникации и сложные потоки данных, приводили к ошибкам моделей
• Logic or Condition-Intensive decisions LLM-ы запутывались в решениях относительно различных релизов и веток
• Context-Dependent decisions Очевидная категория. Куда без неё в архитектуре

Еще одна табличка. Теперь по типам ошибок:

Error label	#	Percent
Semantic and Logical Misinterpretation	41	44.57%
Inability to Infer Implicit or Missing Context	26	28.26%
Insufficient Domain and Technical Knowledge	17	18.48%
Overgeneralization and Unsupported Inference	8	8.7%

• Semantic and Logical Misinterpretation Сложные ADRs, содержащие несколько условий и подразумеваемый зависимости путали ИИ
• Inability to Infer Implicit or Missing Context Подразумевалось, что человек при проверке такой контекст уловил, а LLM нет. Эх, нам бы список этих 92 ошибок посмотреть
• Insufficient Domain and Technical Knowledge Модели что-то не знали о предметной области, технологии или особенностях конкретной версии продукта
• Overgeneralization and Unsupported Inference Заключительная категория — это неверные выводы и ложные обобщения

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

1. 1. Пока речь идет о коде, который написан людьми
   2. Это же относится к записям архитектурных решения ADRs
   3. Проекты и решения – open source с github
   4. Анализируется некоторая точка в развитие проекта, а не очередной PR, например

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