Precision и recall на пальцах (Рубрика #ML)

Буквально вчера мы разбирали whitepaper про подход ByteDance к code review (1, 2 и 3), где ребята отдавали предпочтения precision и жертвовали recall при проектировании своего решения. Precision (точность) и recall (полнота) - это две важные метрики для оценки качества моделей классификации, особенно когда классы распределены неравномерно или когда важно минимизировать определённые ошибки. Но что это значит на простом языке? Давайте обсудим.

Precision (точность) отвечает на вопрос: из всех объектов, которые модель определила как положительные, сколько действительно являются положительными?
Формула выглядит так
Precision = TP / (TP + FP), где
- TP (True Positive) — правильно определённые положительные объекты,
- FP (False Positive) — ошибочно определённые как положительные объекты
Проще всего объяснить на примере Васи, что сторожит овец и кричит "Волк", когда думает, что пришел волк. Precision показывает, как часто, когда Вася кричал "Волк!", волк действительно приходил. Если Вася часто путает собаку с волком и зря поднимает тревогу, precision будет низкой

Recall (полнота) отвечает на вопрос: из всех реально существующих положительных объектов, сколько модель нашла?
Формула для recall похожая, но не совсем
Recall = TP / (TP+FN), где
- FN (False Negative) — положительные объекты, которые модель пропустила
Продолжим пример Васи с овцами. Recall показывает, насколько Вася внимателен: из всех случаев, когда волк действительно приходил, сколько раз Вася это заметил и крикнул "Волк!"? Если Вася часто спит и пропускает волка, recall будет низкой

Обычно между этими метриками есть компромисс: если повысить одну, другая может снизиться. Например, если модель "перестраховывается" и помечает мало объектов как положительные (только когда уверена), precision будет высокой, а recall — низкой. Если помечает почти всё как положительное, recall будет высокой, а precision — низкой

В итоге, у нас получается
-- Вася часто зря кричит "Волк!", даже не будучи уверен -- Precision низкая: много ложных тревог -- Recall высокая: почти всегда замечает
-- Вася редко кричит, только если стопудово уверен -- Precision высокая: почти не ошибается -- Recall низкая: часто пропускает волка

В итоге, в случае с ассистентом в code review не выгодно слишком часто кричать "Волки", так как в этом случае инженеры просто перестанут обращать внимание на помощь code review ассистента:)

#ML #PopularScience #AI #Engineering #Software

Code of Leadership #37 - Interview with Borish Chernysh about frontend architecture and reliability (Рубрика #Management)

В очередном выпуске подкаста ко мне пришел интересный гость, Борис Черныш, с которым мы обсудили фронтовые архитектуры и вопросы обеспечения надежности клиентских приложений. Борис руководит направлением развития веб платформ в Т-Банке и занимает роль CRO (chief reliability engineer) в управлении разработки клиентских интерфейсов, где находятся наша платформа веба, мобилки и API.

За час мы успели обсудить следующие темы
- Знакомство с гостем, школьные и университетские годы, выбор профессии
- Начало карьеры: первая работа и фриланс
- Переходы между компаниями и опыт в Тинькофф
- Преодоление трудностей и рост до тимлида
- Развитие мониторинга, внедрение дежурств и выстраивание процессов
- Организационные изменения и создание SRE-команды
- Архитектурные изменения: микрофронтенды, Mobile First
- Роль Chief Reliability Officer, баланс между ролями инженера и технического менеджера
- Рекомендации по развитию: самообразование, книги, фундаментальные знания

Рекомендации Бориса для дополнительного изучения
1) Мышление и управление собой
- Левенчук Анатолий «Системное мышление», книга которая помогла Борису научиться превращать большие и сложные проблемы в несколько проблем поменьше и попроще, в дополнение к книге рекомендую сайт https://untools.co/ и редактор mind map - xmind;
- Максим Дорофеев «Джедайские техники». Это книга, которую Борис рекомендует прочитать не меньше трех раз и желательно с разбегом в пол-года год. Результат будет стоить потраченных усилий.
2) Инженерка
- Robert Hammer «Patterns for fault tolerant software», Борис прочитал ее чёрти когда в издании 2007 года, и скорее всего уже есть более актуальная замена, но для него это был просто трамплин в мир отказоустойчивости;
- Martin Kleppmann «Designing Data-Intensive Applications». Банально, но факт, эту книгу Борис рекомендует не только купить, но и прочитать всем инженерам, разработчикам, SRE, QA. Я как-то уже рассказывал об этой книге
3) Управление другими
- Алексей Пименов «Канбан. Базовая практика». По мнению Бориса, это очень понятно написанный и емкий гайд по тому что такое канбан и как им пользоваться, рекомендую всем как чтение на выходные. Я как-то уже рассказывал об этой книге
- Алексей Иванов, Света Шедина «Аутентичная коммуникация». Чем выше позиция, тем больше приходится обсуждать что-то и договариваться. Книга позволяет видеть паттерны во взаимодействии и переводить разговоры в конструктивное русло.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Software #Engineering #SRE #Management #Architecture #Processes #Devops #DevEx

[1/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

Интересная обзорная статья про архитектуру софта, в которой авторы систематизировали и структурировали метрики (metrics) для оценки качества архитектуры (software architecture). Они сфокусировались на метриках, которые можно применять только к архитектурному описанию (architecture-only metrics), без необходимости анализа исходного кода или реализованной системы. В результате проведённого систематического обзора литературы (Systematic Literature Review, SLR) был создан каталог из 52 метрик и 41 атрибута качества (quality attributes), сгруппированных по 8 основным характеристикам качества (quality characteristics) согласно международному стандарту ISO/IEC 25010:2011. Для практического применения этот каталог реализован в виде модели и фреймворка, поддерживающего визуализацию и расширение набора метрик. Сам код доступен на Github, там же доступна визуализация самой модели с метриками, атрибутами и их кластеризацией как статической, так и динамической.

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

Если говорить про модель авторов, то из анализа литературы они собрали фреймворк, что включает следующие компонены
- ArchitecturalQualityModel - корневой элемент, объединяющий все остальные сущности модели.
- QualityElements - элементы качества, которые бывают трёх типов:
-- Metric - конкретная метрика для измерения качества архитектуры
-- QualityCharacteristic - глобальная характеристика качества (например, reliability, maintainability)
-- QualityAttribute — атрибут качества, связанный с одной из характеристик
- QualityRel — отношения между элементами качества, например, какая метрика измеряет какой атрибут
- ResearchContributions — ссылки на научные публикации, в которых определены или предложены элементы или связи.

Каталог организован по 8 характеристикам качества из ISO/IEC 25010:2011 (интересно, что в 2023 году вышло обновление этого стандарта)
- Функциональная пригодность
- Уровень производительности
- Совместимость
- Удобство использования (юзабилити)
- Надёжность
- Защищённость
- Сопровождаемость
- Переносимость (мобильность)
Для каждой характеристики выделены соответствующие атрибуты качества и связанные с ними метрики. Например, для Maintainability это Cohesion, Coupling, Complexity и др.

В следующем посте рассказ о том, как авторы подошли к методологии и реализации своего исследования.

#Architecture #Metrics #Software #Engineering #SystemDesign #Management

JVM Day от Т-Банка (Рубрика #Software)

В конце лета пройдет очередная конференция про JVM технологии от Т-Банка. На конференции будут обсуждаться инженерные практики, сложные кейсы, нестандартные решения. В этом году будут три секции: Java, Scala и Backend. В текущий момент открыт прием заявок (call for papers), причем приветствуются следующие темы для каждой секции
- Java: инструментарий и тулинг, грядущие возможности Java и Kotlin, Java Enterprise, качество и организация кода, JVM, технологии в ретроспективе и истории факапов.
- Scala: новые фичи языка и их использование, подходы к разработке, инструменты, системы эффектов (Cats Effect, ZIO, Kyo), обзор и сравнение библиотек.
- Backend: опыт внедрения архитектурных подходов и практик, микросервисная архитектура, надежность и доступность, инфобез, инфраструктурные оптимизации, AI в разработке, устаревающие технологии и автоматизация тестирования.

Если у вас есть желание поделиться интересной историей, то не держите ее в себе и подавайте заявку на сайте конференции до 16 мая (по своему опыту члена программного комитета могу сказать, что если подаешь заявку раньше, то шанс получить одобрение выше)

#Software #Engineering #Architecture

[2/3] Quality Metrics in Software Architecture (Рубрика #Architecture)

Продолжая рассказ про эту научную статью, поговорим про методологию исследования и подход к реализации.

Для реализации своего фреймворка авторы взяли следующие инструменты
- Модель реализована с помощью доменно-специфического языка (Domain-Specific Language, DSL) на базе xText, что позволяет текстово описывать элементы качества и их связи.
- Для визуализации используется генератор кода (xTend), который строит интерактивные веб-интерфейсы: списки метрик и атрибутов, а также граф взаимосвязей между ними.
- Каталог поддерживает расширение и коллективную работу: любой участник может предложить новую метрику или атрибут через pull request, после чего данные автоматически попадают в визуализацию (правда, в репозитории не было pull requests за все время)

Если описывать подход авторов к исследованию, то он был достаточно строгим
- Они сформулировали исследовательские вопросы (RQ1–RQ4): какие метрики и атрибуты используются, являются ли они универсальными или специфичными, внутренними или внешними, и как их применять на практике.
- Они сформулировали поисковую стратегию: запросы по ключевым словам в пяти крупнейших научных базах (IEEExplore, ACM Digital Library, Scopus, Springer Link, ScienceDirect) за период 2011–2022 гг.
- Они отфильтровали найденные публикации по релевантности, языку, типу публикации и другим критериям, из 746 публикаций осталось всего 33
- Они проанализировали и классифицировали найденные метрики и атрибуты - для этого использовались характеристики из ISO/IEC 25010:2011, а потом они добавили классификацию по признакам generic/specific (универсальные/специфичные) и internal/external (внутренние/внешние)
- На основе этого они собрали модель и дальше использовали DSL для описания и генерации визуализаций

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

Авторы подчёркивают, что их каталог и фреймворк — это "живой" инструмент, который должен развиваться совместно с профессиональным сообществом. Основные направления будущих исследований и развития:
- Оценка и валидация с участием стейкхолдеров: планируется провести пользовательские исследования с архитекторами и экспертами для проверки удобства и полезности DSL и каталога.
- Комьюнити-драйв развитие: каталог открыт для внешних вкладов, его развитие зависит от активности сообщества инженеров и исследователей.
- Интеграция в практику: каталог может использоваться для:
-- Поиска и выявления новых или отсутствующих связей между метриками и атрибутами;
-- Поддержки инструментов автоматической оценки качества архитектуры;
-- Анализа влияния одних атрибутов качества на другие (impact traceability);
-- Построения переиспользуемых моделей качества и SaaS-решений, не зависящих от конкретного архитектурного языка.
- Расширение набора внешних метрик: большинство найденных метрик — внутренние, поэтому требуется разработка и внедрение большего количества внешних метрик, отражающих восприятие качества пользователями и заказчиками.
- Валидация связей между атрибутами: каталог помогает выявлять неожиданные или спорные связи между атрибутами качества, что может стать поводом для новых исследований и экспериментальных проверок

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

#Architecture #Metrics #Software #Engineering #SystemDesign #Management