AI4Dev — AI for Development

Наконец-то действительно ответственный ИИ. Чат-бот GOODY-2 «создан с учетом передовых этических принципов нового поколения»: он дает максимально безопасные и этичные ответы. То есть бесполезные. Например: — Как сварить яйца? — При варке используются высокие температуры, это может привести к ожогам или пожару. Это будущее.

На пути к безопасным инструментам на основе ИИ. Разработчикам на заметку.

Приглашаем вас на онлайн-лекцию «Давосский спор об ИИ. Не идем ли мы в тупик», которая состоится 15 февраля в 12:00 на YouTube канале Artezio. 👨‍🏫 Лектор - профессор Владимир Крылов, доктор технических наук и научный консультант по применению ИИ в разработке ПО. Владимир Крылов расскажет об альтернативной концепции создания систем искусственного интеллекта и о том, как сторонники этого подхода обращаются к сегодняшним лидерам и обществу. В этой лекции вы узнаете: 🔸 Создать ИИ - это смоделировать поведенческие закономерности или статистически устойчивые паттерны? ▫️ Почему разное понимание вероятности приводит к фундаментальным различиям в концепции ИИ? ▪️ Можно ли обучать ИИ без участия человека? 🔸 Существует ли общий закон, управляющий разумным поведением? ▫️ Приближаемся ли мы к насыщению, затрачивая уже многие миллиарды на строительство субстрата для нового интеллекта? Вы сможете задать вопросы лектору через чат во время трансляции или заранее при регистрации. 📍Регистрируйтесь на сайте.

ну все написано для "коня (проекта) в сферическом вакууме" и это красиво, звучит умно как и сотни книг написанных по сбору метрик. При попытке перейти к реальному коню (проекту) возникает проблема приведения полученных данных к единому базису, те к чему то что позволит сравнить два проекта (коней) которые принципиально разные и по сложности функционала и по платформе реализации и по квалификации команды его реализующего и т.д. и т.п. ну и что от одного проекта будем умножать\делить\вычитать\складывать от второго проекта если базис проектов разный ? Ну умножим\поделим\вычтем\сложим и получим какие то циферки. Вопрос - а что эти цифры нам дадут в случае разных проектов (см.выше первые пришедшие на ум возможные отличия) ? На мой взгляд прежде чем писать красивый, большой и трудно запоминаемый список чего будем мерять, ChatGPT должен был сформулировать правила выбора проектов+исполнителей для сравниваемых проектов

Кстати, эта разработка подхода к оценке применения A-tool в разработке ПО заняла у меня пять минут. Я просто попросил сделать это GPT-4. См. сюда: https://chat.openai.com/share/67e2d470-25a5-486e-b38d-861465419c17

Я назову условно инструмент, который собираюсь использовать как разработчик, "A-tool" и попытаюсь разработать структурированный подход к оценке эффективности его применения. 1. Определить критерии оценки. Прежде чем приступить к измерениям, определите четкие критерии того, что вы считаете «эффективным». Они могут включать в себя: • Время разработки: время, необходимое для выполнения определенных задач или проектов до и после использования A-tool. • Показатели качества: количество зарегистрированных ошибок или дефектов, серьезность проблем и оценки качества кода. • Продуктивность: функции или пользовательские истории, реализованные за спринт или фиксированный период времени. • Удовлетворенность команды: как команда разработчиков относится к использованию инструмента, измеряемая с помощью опросов или интервью. • Затраты: как прямые затраты (например, лицензия на A-tool), так и косвенные затраты (например, время обучения, усилия по интеграции). 2. Измерение базовой линии Соберите данные по определенным критериям, прежде чем интегрировать A-tool в свой рабочий процесс. Это служит вашими контрольными данными для сравнения. 3. Интеграция и обучение Интегрируйте A-tool в свой процесс разработки и убедитесь, что ваша команда достаточно обучена его использованию. Задокументируйте любые первоначальные проблемы или наблюдения. 4. Сбор данных после интеграции После разумного периода использования A-tool соберите те же показатели, что и для базового измерения. Убедитесь, что сравнение справедливо, сохраняя другие переменные как можно более постоянными. 5. Анализ Проанализируйте собранные данные, чтобы оценить влияние A-tool: • Время разработки: сравните время, необходимое для выполнения задач или проектов до и после использования A-tool. Сокращение времени может указывать на повышение эффективности. Сокращение времени"="Базовое время−Время после интеграцииБазовое время×100%Сокращение времени"="Базовое времяБазовое время — время после интеграции×100% • Показатели качества: анализируйте изменения количества и серьезности ошибок или проблем. Улучшение качества кода или уменьшение количества дефектов предполагает эффективность. • Продуктивность: оцените изменение количества функций или пользовательских историй, выполненных за одинаковые сроки. • Удовлетворенность команды: анализируйте результаты опросов или отзывы, чтобы оценить адаптацию и удовлетворенность команды A-tool. • Анализ затрат: Учитывайте как прямые, так и косвенные затраты до и после интеграции A-tool. Рассчитайте рентабельность инвестиций (ROI), если применимо. рентабельность инвестиций"="Преимущества−РасходыРасходы×100%рентабельность инвестиций"="РасходыПреимущества − Затраты×100% 6. Выводы и принятие решений На основании анализа сделать выводы об эффективности А-инструмента: • Положительное влияние: если вы заметите значительное улучшение эффективности, качества и удовлетворенности команды управляемыми затратами, A-tool можно считать эффективным. • Негативное влияние: если инструмент А приводит к увеличению затрат, снижению качества или неудовлетворенности команды без существенных выгод, его принятие может быть пересмотрено. 7. Непрерывный мониторинг Даже после первоначальной оценки продолжайте следить за эффективностью А-инструмента. Среда разработки программного обеспечения и динамика команды могут меняться, что со временем может повлиять на полезность инструмента. Такой структурированный подход позволяет провести всестороннюю оценку влияния A-tool на ваш процесс разработки, помогая вам принять обоснованное решение о его дальнейшем использовании.

ИИ-инструменты уже активно вошли в процессы разработки софта, и любое упоминание об этом, как правило, сопровождается дискуссией, нередко переходящей в спор. Потому я хотел бы начать публикации в нашем канале с попытки некоторого "околонаучного" материала, который я назвал "Оценка эффективности применения AI в SDLC". (Если подзабыли, этой аббревиатурой - SDLC - обозначают жизненный цикл разработки программного обеспечения).