Комментарии

Создание надежного набора данных для обучения моделей машинного обучения сопряжено со значительными трудностями. Например, в то время как технологии искусственного интеллекта, такие как ChatGPT, процветают благодаря сбору огромных объемов данных, доступных в Интернете, данные о здравоохранении не могут быть собраны таким образом свободно из соображений конфиденциальности. Создание набора данных о здравоохранении предполагает интеграцию данных из нескольких источников, включая врачей, больницы и международные данные.

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

Таким образом, сотрудничество становится важнейшим элементом безопасного использования потенциала ИИ в наших обществах. Однако часто упускаемым из виду аспектом является фактическая среда выполнения искусственного интеллекта и базовое оборудование, которое его поддерживает. Современные продвинутые модели искусственного интеллекта требуют надежного оборудования, включая обширные ресурсы ЦП / GPU, значительные объемы оперативной памяти и даже более специализированных технологий, таких как TPU, ASIC и FPGA. И наоборот, тенденция к созданию удобных интерфейсов с простыми API набирает популярность. Этот сценарий подчеркивает важность разработки решений, позволяющих ИИ работать на платформах сторонних производителей без ущерба для конфиденциальности, и необходимость в инструментах с открытым исходным кодом, которые облегчают эти технологии сохранения конфиденциальности.

Решения по обеспечению конфиденциальности для обучения моделей машинного обучения

Для решения проблем конфиденциальности в ИИ было разработано несколько сложных решений, каждое из которых ориентировано на конкретные потребности и сценарии.

Федеративное обучение (FL) позволяет обучать модели машинного обучения на нескольких децентрализованных устройствах или серверах, каждое из которых хранит локальные выборки данных, без фактического обмена данными. Аналогичным образом, безопасные многосторонние вычисления (MPC) позволяют нескольким сторонам совместно вычислять функцию по своим входным данным, сохраняя эти входные данные конфиденциальными, гарантируя, что конфиденциальные данные не покинут исходную среду.

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

Наконец, гомоморфное шифрование (HE) позволяет выполнять операции непосредственно с зашифрованными данными, генерируя зашифрованный результат, который при расшифровке совпадает с результатом операций, выполненных с открытым текстом.

Фундаментальным вопросом в области конфиденциальности данных является следующий: какой объем конфиденциальных данных может восстановить противник из модели машинного обучения с добавленным в нее шумом?

Дифференциальная конфиденциальность (Differential Privacy), одно из популярных определений конфиденциальности, гласит, что конфиденциальность достигается, если противник, наблюдающий за выпущенной моделью, не может сделать вывод о том, использовались ли данные произвольного человека для обработки при обучении. Однако для того, чтобы доказать, что противник не сможет отличить использование данных, часто требуется большое количество шума. Этот шум снижает точность модели.

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

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

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

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

Преимущества выбора Azure включают в себя его экономичность, гибкость, понимание больших данных и популярность продуктов Microsoft. Azure, в отличие от других поставщиков облачных услуг, имеет высокую доступность и избыточность из-за глобального присутствия Microsoft. Это означает, что в случае нарушения работы ИТ-систем ваш бизнес может продолжать работать в обычном режиме.
Преимущества выбора AWS

AWS является лидером рынка и была им с момента своего создания. Она опережает и Azure, и Google Cloud. AWS имеет огромный глобальный охват и помогла создать на тысячи рабочих мест больше, чем GCP. Если вам нужно много функций для вашей работы, нет сомнений, что AWS предоставит вам все необходимое.

Другая часть глобальной инфраструктуры AWS — это точки присутствия (POP). POP используются для доставки контента конечным пользователям на высоких скоростях. AWS также имеет сети VPC в разных регионах, которые можно связать с помощью VPC Peering. Затем VPC могут взаимодействовать друг с другом, как если бы они находились в одной частной сети.

Все облака имеют свои сильные и слабые стороны:

— Google – отличную систему дисконтирования, которая включается автоматически и, на первый взгляд, действительно дает большой бонус.
— Amazon – очень сильный с точки зрения доверия к бренду и наиболее популярная платформа.
-Azurе – имеет преимущество в производительности за счет продажи настоящих ядер, а не виртуальных hyper-threading threads (vCPU).

При пересчете мощности в денежном выражении, картина несколько меняется и Google с 30% скидкой начинает проигрывать платформе Azure в среднем на ~10%, хотя при сравнении в лоб калькуляторов обоих платформ может показаться совсем обратная картина. Amazon, к сожалению, начинает проигрывать на 28% в деньгах за производительность по тестам GeekBench.

В российской экспертной практике рекомендации по управлению рисками ИИ содержатся в Кодексе этики искусственного интеллекта. В частности, субъектам, использующим системы ИИ, рекомендуется проводить оценку потенциальных рисков применения ИИ, в том числе – с помощью независимого аудита, и выработать соответствующие методики оценки рисков.

Кроме того, Кодексом рекомендуется разработка методик, руководств, «чек-листов» и иных методических материалов.

С учетом того, что искусственный интеллект, равно как и традиционные программные технологии, подвержен быстрым инновациям, Кодексом этики предусмотрена возможность создания сводов наилучших/наихудших практик решения вопросов, возникающих в жизненном цикле ИИ.

Национальный институт стандартов и технологий (NIST) выпустил новый документ, который поможет организациям управлять рисками, связанными с искусственным интеллектом, обеспечивая безопасность и прозрачность технологий.

В июле 2024 года NIST представил результаты своей работы по созданию «Рамки управления рисками в области ИИ». Этот документ стал результатом сотрудничества с различными заинтересованными сторонами и нацелен на помощь организациям в оценке и снижении рисков, связанных с системами ИИ.

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

Основные моменты рамки:

— Структурированный подход: Включает четыре ключевые функции — картирование, измерение, управление и управление — для охвата полного жизненного цикла систем ИИ.

— Цели надежного ИИ: Подчеркивает важность принципов прозрачности, объяснимости, надежности и конфиденциальности.

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

— Инструменты и ресурсы: Включает практические инструменты для оценки систем ИИ, что позволяет организациям внедрять рекомендации на практике.

Что дальше? Ожидается, что различные сектора начнут интегрировать эту рамку в свои практики управления ИИ, особенно в свете продолжающихся глобальных дискуссий о регулировании ИИ. Организациям стоит начать адаптировать свои внутренние процессы в соответствии с этими рекомендациями, чтобы оставаться на шаг впереди.

Универсальность генеративного искусственного интеллекта не знает границ в области творчества, в прикладных сферах пока идет отстование. Например в творческих он нашел применение в широком спектре творческих деятельностей:

— Создание текста: генеративные модели могут сочинять стихи, придумывать истории, генерировать код или даже составлять электронные письма, которые выглядят так, будто их написали люди.
— Генерация изображений: от реалистичных пейзажей до абстрактного искусства, генеративные модели создают визуальные чудеса.
— Создание музыки: с помощью AI музыканты и композиторы могут сочинять мелодии, гармонии и ритмы.
— Перевод: генеративные модели революционизировали процесс перевода, предлагая быстрые и контекстуальные переводы.
— Персонализация контента: AI поддерживает рекомендательные системы, предлагающие книги, фильмы и музыку, соответствующие индивидуальным предпочтениям.

Генеративный искусственный интеллект представляет собой синтез искусства и науки — область, где машины учатся на творчестве людей и затем сами включаются в творческий процесс.

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

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

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

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

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

Точно так же генеративные модели изображений изучают цвета, формы и фактуры изображений, которые они видели. Когда их просят создать изображение, они предлагают что-то уникальное — произведение искусства, отражающее эстетику обучающих данных, но не копирующее ни одного конкретного изображения.

Интересно узнать как генеративные модели учатся?

Модели разграничения доступа бывают разные.

Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)

более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.

Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)

более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам.

— Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.

Подскажите, пожалуйста, какие есть способы реализовать это? Дело в том, что мы это реализовываем в своих проектах через т.н. реализацию МРД (модели разграничения доступа, но, возможно, это наш внутренний термин).

МРД — это документ в котором мы прописываем для каждого объекта правила доступа нему со стороны каждого субъекта. Потом эту МРД реализуем в коде на Java. Но получается жутко сложно, много ошибок и косяков.

Может есть какая-то книжка или бест-практика как это реализовывать проще?

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат кри­тичес­кие уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

В заключении приведу несколько общих выводов:

— Нужно держать круговую оборону и защищаться со всех сторон. Как ни банально звучит, но безопасность системы определяется самым слабым звеном. И если мы забыли защитить даже незначительную часть, последствия могут быть весьма печальными.
— Разработчик API должен не только уметь программировать, но и разбираться в безопасности систем и приложений. Или в команде должен быть сотрудник, отвечающий за безопасность.
— Нужно следить за актуальным положением дел с безопасностью, т.к. даже относительно свежая информация может быстро устареть, и система окажется неработоспособной или беззащитной перед атаками.

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

Приложение на Симфони совсем не виснет даже в праздники, когда запросы возрастают. Каждый модуль упакован в контейнер на сервере и может быть горизонтально масштабирован в зависимости от нагрузки.

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

Приложение на Симфони совсем не виснет даже в праздники, когда запросы возрастают. Каждый модуль упакован в контейнер на сервере и может быть горизонтально масштабирован в зависимости от нагрузки.

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

Создает новые компоненты быстро и не утяжеляет систему. Благодаря Symfony framework разработчику не нужно писать много кода, чтобы подключить новые функции к системе. Symfony не копирует сам себя при создании новых components, а работает как единый фреймворк благодаря минимально функциональному ядру.

Помогает использовать один и тот же код и допускать меньше ошибок. Многим проектам не на Симфони требуется раз за разом использовать некоторые решения между различными компонентами — например, способы хранения данных для разных платформ.

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

Например, Симфони-бандл, с помощью которого различные приложения бэкенда взаимодействуют между собой, а также между клиентскими приложениями в JSON-формате с предопределенными схемами сущностей.

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

Создает новые компоненты быстро и не утяжеляет систему. Благодаря Symfony framework разработчику не нужно писать много кода, чтобы подключить новые функции к системе. Symfony не копирует сам себя при создании новых components, а работает как единый фреймворк благодаря минимально функциональному ядру.

Помогает использовать один и тот же код и допускать меньше ошибок. Многим проектам не на Симфони требуется раз за разом использовать некоторые решения между различными компонентами — например, способы хранения данных для разных платформ.

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

Например, Симфони-бандл, с помощью которого различные приложения бэкенда взаимодействуют между собой, а также между клиентскими приложениями в JSON-формате с предопределенными схемами сущностей.

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

Хорошая CRM-система, особенно подходит для управления персоналом и клиентами, в нашем случае мы используем DSR CRM в нашем ИТ отделе

Если такие вопросы задаются при собеседовании человека с >3 лет реального опыта — возможно да. Для новичков в отрасли тестирования они просто могут помочь понять произошла-ли уже проф. деформация мышления, т.е. остановится-ли человек на условной перепроверке шагов воспроизведения из дефекта или все же полезет щупать потенциально затронутые области.

Создаётся впечатление, что вопросы типа «QA vs QC» и «верификация vs валидация» больше нужны, чтобы на собеседованиях умничать