Cell-based Architecture.
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
Согласно последнему отчету об архитектурных трендах от infoq, набирает популярность подход Cell-based Architecture или Клеточная Архитектура. О нем сегодня и поговорим.
Подход основан на особых принципах разделения микросервисов. Ячейки представляют собой группу инстансов микросервисов, которые обрабатывают изолированные end-to-end части сценариев работы сервиса. Например, ячейка может обслуживать конкретный регион, определенные сценарии или категории пользователей.
Рассмотрим пример классической микросервисной архитектуры:
— Есть микросервис A, обрабатывающий весь пользовательский трафик, состоящий из сотен инстансов, развернутых в разных локациях. Он ходит в микросервис B.
— Микросервис B, тоже сотни инстансов, использует базу данных, также шардированную по локациям.
Проблемы: возникает много долгих кросс-дц запросов, проблемы в одном микросервисе или базе приводят к невозможности обработать весь пользовательский трафик.
Клеточная архитектура предлагает одно из возможных решений:
Выделить инстансы микросервисов A, B и шарды данных в отдельные ячейки таким образом, чтобы они end-to-end обслуживали один пользовательский регион или один продуктовый сценарий.
Таким образом, ячейка изолирует нагрузку — она владеет своим набором данных, масштабируется независимо и не влияет на соседние ячейки, что обеспечивает более высокую надежность и легкость тестирования компонент системы.
Для продолжения углубления советую статью VK про их вариант адаптации подхода:
https://habr.com/ru/companies/vk/articles/807685/
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
https://habr.com/ru/companies/otus/articles/808205/
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
Согласно последнему отчету об архитектурных трендах от infoq, набирает популярность подход Cell-based Architecture или Клеточная Архитектура. О нем сегодня и поговорим.
Подход основан на особых принципах разделения микросервисов. Ячейки представляют собой группу инстансов микросервисов, которые обрабатывают изолированные end-to-end части сценариев работы сервиса. Например, ячейка может обслуживать конкретный регион, определенные сценарии или категории пользователей.
Рассмотрим пример классической микросервисной архитектуры:
— Есть микросервис A, обрабатывающий весь пользовательский трафик, состоящий из сотен инстансов, развернутых в разных локациях. Он ходит в микросервис B.
— Микросервис B, тоже сотни инстансов, использует базу данных, также шардированную по локациям.
Проблемы: возникает много долгих кросс-дц запросов, проблемы в одном микросервисе или базе приводят к невозможности обработать весь пользовательский трафик.
Клеточная архитектура предлагает одно из возможных решений:
Выделить инстансы микросервисов A, B и шарды данных в отдельные ячейки таким образом, чтобы они end-to-end обслуживали один пользовательский регион или один продуктовый сценарий.
Таким образом, ячейка изолирует нагрузку — она владеет своим набором данных, масштабируется независимо и не влияет на соседние ячейки, что обеспечивает более высокую надежность и легкость тестирования компонент системы.
Для продолжения углубления советую статью VK про их вариант адаптации подхода:
https://habr.com/ru/companies/vk/articles/807685/
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/why-to-use-a-cell-based-architecture.html
https://github.com/wso2/reference-architecture/blob/master/reference-architecture-cell-based.md
https://habr.com/ru/companies/otus/articles/808205/
👍15
Bulkhead.
https://en.wikipedia.org/wiki/Bulkhead_(partition)
Поговорим сегодня о кораблях. Когда готовил прошлый пост про Cell-Based Architecture наткнулся на новый термин — “Переборка” или “Bulkhead”.
Переборки — это вертикальные стенки внутри корпуса судов, разделяющие внутренние пространства на отсеки. Помимо разделения пространства внутри судна, служат они для предотвращения попадания воды внутрь судна в случае пробития наружной обшивки. Иногда переборки делаются броневыми, чтобы защитить внутренность корабля от разрыва мины.
Интересно наблюдать как инженерные решения из оффлайнового мира перекочевывают в IT — Bulkhead Pattern или Cell-Based Architecture.
https://bool.dev/blog/detail/bulkhead-pattern
https://ru.wikipedia.org/wiki/Переборка
https://news.1rj.ru/str/startup_architecture/96
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead
https://en.wikipedia.org/wiki/Bulkhead_(partition)
Поговорим сегодня о кораблях. Когда готовил прошлый пост про Cell-Based Architecture наткнулся на новый термин — “Переборка” или “Bulkhead”.
Переборки — это вертикальные стенки внутри корпуса судов, разделяющие внутренние пространства на отсеки. Помимо разделения пространства внутри судна, служат они для предотвращения попадания воды внутрь судна в случае пробития наружной обшивки. Иногда переборки делаются броневыми, чтобы защитить внутренность корабля от разрыва мины.
Интересно наблюдать как инженерные решения из оффлайнового мира перекочевывают в IT — Bulkhead Pattern или Cell-Based Architecture.
https://bool.dev/blog/detail/bulkhead-pattern
https://ru.wikipedia.org/wiki/Переборка
https://news.1rj.ru/str/startup_architecture/96
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead
👍8👎1🔥1
InfoQ Software Architecture and Design Trends Report - April 2024
https://www.infoq.com/articles/architecture-trends-2024/
Вышел очередной отчет infoq о трендах в архитектуре приложений и распределенных систем. Мы достаточно подробно разбирали отчет за 2023 год, давайте посмотрим, что поменялось за первый квартал.
— Cell-Based архитектура как попытка увеличить надежность больших и сложных систем и снизить затраты с помощью разделения микросервисной архитектуры по пользовательским сценариям и зонам доступности. Подробнее в прошлом посте. В качестве инноваторов — Roblox, Slack, DoorDash.
— Privacy engineering. Компании меняют свой майндсет с реактивного подхода в следовании законам о пользовательских данных, например GDPR, на более проактивный подход и закладывают все требования в начальном проектировании. Кажется, что в России с законами о ПД происходит та же смена майндсета.
— Social-technical architecture. Более конкретный подход пришел на замену немного невнятному “Architecture as a Team Sport”. Смысл его в размывании роли архитектора. Больше компаний приходит к тому, что архитектурные решения должны принимать все, кто причастен к созданию и поддержке систем.
— LLM стремительно проходит адаптацию, и еще больше компаний ищут применение, которое может стать геймченджером в конкретной индустрии. Скорее всего, у вас тоже в продукте есть стрим про то, как можно использовать LLM. При этом дальше чатботов и RAG дело мало у кого доходит.
— Platform architecture я бы объединил с Low/No code и подчеркнул, что последние годы идет нескончаемый тренд на понижение планки входа в IT. Затраты на разработку всегда были большими, это большой и сочный кусок PnL, вокруг которого постоянно появляются и исчезают новые платформенные решения. Рано или поздно все будем писать на JS.
Отчет — https://www.infoq.com/articles/architecture-trends-2024/
Подкаст — https://www.infoq.com/podcasts/infoq-architecture-trends-2024/
Отчет за 2023 — https://news.1rj.ru/str/startup_architecture/88
https://www.infoq.com/articles/architecture-trends-2024/
Вышел очередной отчет infoq о трендах в архитектуре приложений и распределенных систем. Мы достаточно подробно разбирали отчет за 2023 год, давайте посмотрим, что поменялось за первый квартал.
— Cell-Based архитектура как попытка увеличить надежность больших и сложных систем и снизить затраты с помощью разделения микросервисной архитектуры по пользовательским сценариям и зонам доступности. Подробнее в прошлом посте. В качестве инноваторов — Roblox, Slack, DoorDash.
— Privacy engineering. Компании меняют свой майндсет с реактивного подхода в следовании законам о пользовательских данных, например GDPR, на более проактивный подход и закладывают все требования в начальном проектировании. Кажется, что в России с законами о ПД происходит та же смена майндсета.
— Social-technical architecture. Более конкретный подход пришел на замену немного невнятному “Architecture as a Team Sport”. Смысл его в размывании роли архитектора. Больше компаний приходит к тому, что архитектурные решения должны принимать все, кто причастен к созданию и поддержке систем.
— LLM стремительно проходит адаптацию, и еще больше компаний ищут применение, которое может стать геймченджером в конкретной индустрии. Скорее всего, у вас тоже в продукте есть стрим про то, как можно использовать LLM. При этом дальше чатботов и RAG дело мало у кого доходит.
— Platform architecture я бы объединил с Low/No code и подчеркнул, что последние годы идет нескончаемый тренд на понижение планки входа в IT. Затраты на разработку всегда были большими, это большой и сочный кусок PnL, вокруг которого постоянно появляются и исчезают новые платформенные решения. Рано или поздно все будем писать на JS.
Отчет — https://www.infoq.com/articles/architecture-trends-2024/
Подкаст — https://www.infoq.com/podcasts/infoq-architecture-trends-2024/
Отчет за 2023 — https://news.1rj.ru/str/startup_architecture/88
👍8🔥1
Как Netflix обеспечивает высокую доступность stateful системам.
Вышла очень интересная статья Нетфликса о доступности в распределенных stateful системах. Всем рекомендую к прочтению.
Сервисы могут иметь одинаковое количество "девяток", но разные причины падений и методы повышения надежности. Например, один сервис редко падает, но долго восстанавливается, другой часто падает, но быстро восстанавливается — у них одинаковая метрика доступности, но разные подходы к улучшению надежности.
Вместо того, чтобы мериться количеством девяток, нужно задаться следующими вопросами:
— Как часто система выходит из строя?
— Когда система выходит из строя, насколько большой радиус поражения?
— Как долго система восстанавливается после сбоя?
И дальше нужно сфокусировать ресурсы на конкретные пункты в зависимости от ваших потребностей (например, хороший компромисс, когда система часто выходит из строя, но не причиняет ущерба большому числу клиентов). В статье приводится множество методов, чтобы заставить эти метрики двигаться в нужном направлении.
https://www.infoq.com/articles/netflix-highly-reliable-stateful-systems/
@startup_architecture
Вышла очень интересная статья Нетфликса о доступности в распределенных stateful системах. Всем рекомендую к прочтению.
Сервисы могут иметь одинаковое количество "девяток", но разные причины падений и методы повышения надежности. Например, один сервис редко падает, но долго восстанавливается, другой часто падает, но быстро восстанавливается — у них одинаковая метрика доступности, но разные подходы к улучшению надежности.
Вместо того, чтобы мериться количеством девяток, нужно задаться следующими вопросами:
— Как часто система выходит из строя?
— Когда система выходит из строя, насколько большой радиус поражения?
— Как долго система восстанавливается после сбоя?
И дальше нужно сфокусировать ресурсы на конкретные пункты в зависимости от ваших потребностей (например, хороший компромисс, когда система часто выходит из строя, но не причиняет ущерба большому числу клиентов). В статье приводится множество методов, чтобы заставить эти метрики двигаться в нужном направлении.
https://www.infoq.com/articles/netflix-highly-reliable-stateful-systems/
@startup_architecture
InfoQ
How Netflix Ensures Highly-Reliable Online Stateful Systems
Building reliable stateful services at scale isn’t a matter of building reliability into the servers, the clients, or the APIs in isolation. By combining smart and meaningful choices for each of these three components, we can build massively scalable, SLO…
👍12🔥3
Как работает Apple Intelligence под капотом.
10 июня 2024 года на конференции WWDC 2024 Apple анонсировала свою AI платформу. В качестве искусственного интеллекта выступает платформа с оркестратором, инференсом (исполнением) легких моделей на устройстве и даже интеграцией с OpenAI. Давайте разбираться с архитектурной точки зрения.
— Большую часть инференса стараются делать прямо на устройстве, куда интегрируется модель вроде OpenELM 3B — семейство “эффективных” моделей, которые Apple анонсировала в начале этого года. По качеству они, конечно, уступают LLM, но базовые сценарии на телефоне будут покрываться.
— За решение исполнять ли запрос пользователя на устройстве или отправлять на сервера Apple отвечает центральная часть системы — Оркестратор. Он определяет, потянет ли встроенная модель запрос. Если нет, то отправляет на бэкенд на более умную модель (LLM) или даже в OpenAI.
— Функциональность App Intents Toolbox позволяет Siri взаимодействовать с приложениями по определенным контрактам, предоставляя разработчикам возможность "интегрироваться" в ассистент. Как обычно, нужно задекларировать в коде поддерживаемые “интенты” и Siri будет понимать, как с вашим приложением нужно обращаться. По схеме не очень понятно, как именно выглядит сценарий обработки пользовательского запроса, но все указывает на то, что это концепция тулов в RAG схеме.
— Semantic Index, скорее всего, векторная база данных прямо на устройстве. Она необходима для реализации RAG, с помощью которого Siri начинает что-то знать не только о вещах, на которых обучена модель, но и о реальном мире (а также о том, что хранится на самом телефоне).
Технология, основанная на сочетании обработки данных на устройстве и на сервере, должна стать доступна разработчикам в конце 2024 года.
Пост написан на базе статьи с медиума и официального анонса Apple, там сильно больше интересной информации.
@startup_architecture
10 июня 2024 года на конференции WWDC 2024 Apple анонсировала свою AI платформу. В качестве искусственного интеллекта выступает платформа с оркестратором, инференсом (исполнением) легких моделей на устройстве и даже интеграцией с OpenAI. Давайте разбираться с архитектурной точки зрения.
— Большую часть инференса стараются делать прямо на устройстве, куда интегрируется модель вроде OpenELM 3B — семейство “эффективных” моделей, которые Apple анонсировала в начале этого года. По качеству они, конечно, уступают LLM, но базовые сценарии на телефоне будут покрываться.
— За решение исполнять ли запрос пользователя на устройстве или отправлять на сервера Apple отвечает центральная часть системы — Оркестратор. Он определяет, потянет ли встроенная модель запрос. Если нет, то отправляет на бэкенд на более умную модель (LLM) или даже в OpenAI.
— Функциональность App Intents Toolbox позволяет Siri взаимодействовать с приложениями по определенным контрактам, предоставляя разработчикам возможность "интегрироваться" в ассистент. Как обычно, нужно задекларировать в коде поддерживаемые “интенты” и Siri будет понимать, как с вашим приложением нужно обращаться. По схеме не очень понятно, как именно выглядит сценарий обработки пользовательского запроса, но все указывает на то, что это концепция тулов в RAG схеме.
— Semantic Index, скорее всего, векторная база данных прямо на устройстве. Она необходима для реализации RAG, с помощью которого Siri начинает что-то знать не только о вещах, на которых обучена модель, но и о реальном мире (а также о том, что хранится на самом телефоне).
Технология, основанная на сочетании обработки данных на устройстве и на сервере, должна стать доступна разработчикам в конце 2024 года.
Пост написан на базе статьи с медиума и официального анонса Apple, там сильно больше интересной информации.
@startup_architecture
🔥15
Как вы знаете, я сейчас руковожу разработкой в AI-Центр Т-Банка. Мы делаем очень крутые AI first продукты и платформы. Мне часто говорят, что тут одни ML-задачи, это совсем не так. Немного расскажу.
Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.
Мы создаем Вселенную AI-ассистентов — это финансовый, инвестиционный, шоппинг и другие ассистенты. Мы строим для этого целую LLM-платформу на базе нашего семейства языковых моделей.
Мы разрабатываем новое поколение пользовательской поддержки — это наш смелый стартаперский эксперимент по внедрению LLM в обслуживание клиентов, продажи и коллекшен. Результаты этой работы ощутят миллионы клиентов и десятки тысяч сотрудников. Мы меняем то, как работает большая компания, а возможно, и вся индустрия.
А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.
Все это разработка на передовой технологий, где какие-нибудь все меняющие новости происходят почти каждый месяц.
И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.
Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.
Мы создаем Вселенную AI-ассистентов — это финансовый, инвестиционный, шоппинг и другие ассистенты. Мы строим для этого целую LLM-платформу на базе нашего семейства языковых моделей.
Мы разрабатываем новое поколение пользовательской поддержки — это наш смелый стартаперский эксперимент по внедрению LLM в обслуживание клиентов, продажи и коллекшен. Результаты этой работы ощутят миллионы клиентов и десятки тысяч сотрудников. Мы меняем то, как работает большая компания, а возможно, и вся индустрия.
А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.
Все это разработка на передовой технологий, где какие-нибудь все меняющие новости происходят почти каждый месяц.
И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.
👍18🔥11😢5👎1
Оверинжиниринг в архитектурных решениях.
Overengineering — это процесс разработки решения, которое усложнено таким образом, что не представляет ценности или могло бы быть реализовано проще. Если совсем простыми словами, то это когда можно сделать просто, но делается сложно.
Есть очень много причин, почему люди начинают оверинжинирить — это и неправильная формулировка ФТ и НФТ, и неправильные фокусы (например, на платформенность всего и вся), и даже незрелость команды.
Пример задачи, которую легко переоверинжинирить.
Есть функциональность — микросервисы-системы выгружают снапшот каталога продуктов из микросервиса каталога продуктов. В какой-то момент каталог раздувается и снапшот начинает выгружаться уже 5 секунд, нужно реализовать быструю выгрузку изменений из каталога.
Как решить?
Почему оверинжиниринг — это плохо:
— Излишняя стоимость решения. Более сложное решение делается дольше и обходится дороже в разработке без видимых на то причин.
— Излишняя стоимость поддержки. Я не говорю "сложнее поддерживать", потому что "сложнее" — субъективная оценка, но то, что на поддержку и развитие будет уходить больше времени, или потребуется более высокая квалификация инженера — увеличивает бюджет проекта.
Как можно предотвращать появление переуплотненных решений:
У нас в команде есть архитектурное ревью. В какой-то момент мы сформулировали чеклист к изменениям, которые проходят ревью. Я приведу некоторые вопросы из этого чеклиста, которые направлены на то, чтобы избегать оверинжиниринга решений:
— Какую бизнес-проблему мы решаем? Правильно ли, что эту проблему нужно решать именно такими ФТ и НФТ, а не на другом уровне/другой системе? Как еще можно решить эту бизнес-проблему?
— Правда ли, что текущие ФТ и НФТ решают бизнес-задачу? Не могут ли они быть более слабыми/более сильными, что сильно упростило бы решение или снизило стоимость решения?
— Правда ли, что исходя из контекста и ограничений по срокам, выбрано самое оптимальное техническое решение? Какие решения мы не рассмотрели совсем?
— Сколько новых точек отказа появляется в системе? Можно обойтись без них?
— Сколько новых сущностей/абстракций появляется в системе? Можно ли обойтись без них?
— Правда ли, что в компании/соседней команде нет решения, которое можно заиспользовать? Правда ли, что есть весомые аргументы не использовать уже готовые решения?
Если есть что добавить — пишите в комментариях.
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
Overengineering — это процесс разработки решения, которое усложнено таким образом, что не представляет ценности или могло бы быть реализовано проще. Если совсем простыми словами, то это когда можно сделать просто, но делается сложно.
Есть очень много причин, почему люди начинают оверинжинирить — это и неправильная формулировка ФТ и НФТ, и неправильные фокусы (например, на платформенность всего и вся), и даже незрелость команды.
Пример задачи, которую легко переоверинжинирить.
Есть функциональность — микросервисы-системы выгружают снапшот каталога продуктов из микросервиса каталога продуктов. В какой-то момент каталог раздувается и снапшот начинает выгружаться уже 5 секунд, нужно реализовать быструю выгрузку изменений из каталога.
Как решить?
Почему оверинжиниринг — это плохо:
— Излишняя стоимость решения. Более сложное решение делается дольше и обходится дороже в разработке без видимых на то причин.
— Излишняя стоимость поддержки. Я не говорю "сложнее поддерживать", потому что "сложнее" — субъективная оценка, но то, что на поддержку и развитие будет уходить больше времени, или потребуется более высокая квалификация инженера — увеличивает бюджет проекта.
Как можно предотвращать появление переуплотненных решений:
У нас в команде есть архитектурное ревью. В какой-то момент мы сформулировали чеклист к изменениям, которые проходят ревью. Я приведу некоторые вопросы из этого чеклиста, которые направлены на то, чтобы избегать оверинжиниринга решений:
— Какую бизнес-проблему мы решаем? Правильно ли, что эту проблему нужно решать именно такими ФТ и НФТ, а не на другом уровне/другой системе? Как еще можно решить эту бизнес-проблему?
— Правда ли, что текущие ФТ и НФТ решают бизнес-задачу? Не могут ли они быть более слабыми/более сильными, что сильно упростило бы решение или снизило стоимость решения?
— Правда ли, что исходя из контекста и ограничений по срокам, выбрано самое оптимальное техническое решение? Какие решения мы не рассмотрели совсем?
— Сколько новых точек отказа появляется в системе? Можно обойтись без них?
— Сколько новых сущностей/абстракций появляется в системе? Можно ли обойтись без них?
— Правда ли, что в компании/соседней команде нет решения, которое можно заиспользовать? Правда ли, что есть весомые аргументы не использовать уже готовые решения?
Если есть что добавить — пишите в комментариях.
https://www.mindtheproduct.com/overengineering-can-kill-your-product/
Mind the Product
Overengineering can kill your product
In today's post, Simón Muñoz speaks about one of the most prevalent issues when creating products: overengineering them.
👍14🔥1
Топ-10 угроз безопасности приложений, основанных на LLM и генеративном ИИ (OWASP Foundation).
С ростом популярности решений на базе LLM и генеративного ИИ растет и количество потенциальных уязвимостей. Как первые сайты на php упускали из расчета, что пользователь может ввести логин "; DROP TABLE USERS". Так и сейчас — продукты на основе ИИ растут быстрее, чем исследования в области безопасности таких решений.
Некоммерческая организация OWASP Foundation выпускает "OWASP TOP-10" — это отчет, составленный группой экспертов по безопасности со всего мира, об известных проблемах безопасности приложений с акцентом на 10 самых важных. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.
В этом году OWASP выпустили ТОП-10 рисков и уязвимостей при разработке приложений, основанных на генеративном ИИ, и больших языковых моделей на всех этапах жизненого цикла. Ниже этот список.
ТОП-10:
— Prompt Injections: попытка злоумышленников переопределить изначальный Prompt, что может привести к несанкционированным ответам.
— Insecure Output Handling: неправильная очистка или обработка данных, генерируемых ИИ, что приводит к таким уязвимостям, как cross-site noscripting или утечке информации.
— Training Data Poisoning: подразумевает подделку данных, используемых для обучения моделей, что искажает их поведение.
— Denial of Service: атаки, которые перегружают системы с моделями, делая их недоступными для пользователей, например, путем использования ресурсоемких операций.
— Supply Chain Vulnerabilities: жизненный цикл приложения на базе LLM может быть скомпрометирован уязвимыми компонентами или службами.
— Sensitive Data Leakage or Information Disclosure: непреднамеренное раскрытие конфиденциальной информация системами ИИ из-за недостатков в обработке данных или контроле доступов.
— Insecure Plugin Design: плагины LLM могут иметь небезопасные входы и недостаточный контроль доступа.
— Excessive Agency: возникает из-за чрезмерной функциональности, разрешений или автономии, предоставляемых системам на основе LLM, что приводит к непреднамеренным последствиям.
— Overreliance: чрезмерное доверие к результату работы систем ИИ без адекватного контроля, что приводит к распространению ненадлежащего или вредоносного контента.
— Model Theft: подразумевает несанкционированный доступ к моделям под капотом приложения.
https://genai.owasp.org/llm-top-10/
https://education.securiti.ai/certifications/ai-governance/controlling-data-inputs-and-outputs/attacks-against-generative-ai-systems-owasp-top-10-for-llms/
С ростом популярности решений на базе LLM и генеративного ИИ растет и количество потенциальных уязвимостей. Как первые сайты на php упускали из расчета, что пользователь может ввести логин "; DROP TABLE USERS". Так и сейчас — продукты на основе ИИ растут быстрее, чем исследования в области безопасности таких решений.
Некоммерческая организация OWASP Foundation выпускает "OWASP TOP-10" — это отчет, составленный группой экспертов по безопасности со всего мира, об известных проблемах безопасности приложений с акцентом на 10 самых важных. На них ссылаются создатели основных стандартов кибербезопасности и такие организации, как MITRE, PCI DSS и DISA.
В этом году OWASP выпустили ТОП-10 рисков и уязвимостей при разработке приложений, основанных на генеративном ИИ, и больших языковых моделей на всех этапах жизненого цикла. Ниже этот список.
ТОП-10:
— Prompt Injections: попытка злоумышленников переопределить изначальный Prompt, что может привести к несанкционированным ответам.
— Insecure Output Handling: неправильная очистка или обработка данных, генерируемых ИИ, что приводит к таким уязвимостям, как cross-site noscripting или утечке информации.
— Training Data Poisoning: подразумевает подделку данных, используемых для обучения моделей, что искажает их поведение.
— Denial of Service: атаки, которые перегружают системы с моделями, делая их недоступными для пользователей, например, путем использования ресурсоемких операций.
— Supply Chain Vulnerabilities: жизненный цикл приложения на базе LLM может быть скомпрометирован уязвимыми компонентами или службами.
— Sensitive Data Leakage or Information Disclosure: непреднамеренное раскрытие конфиденциальной информация системами ИИ из-за недостатков в обработке данных или контроле доступов.
— Insecure Plugin Design: плагины LLM могут иметь небезопасные входы и недостаточный контроль доступа.
— Excessive Agency: возникает из-за чрезмерной функциональности, разрешений или автономии, предоставляемых системам на основе LLM, что приводит к непреднамеренным последствиям.
— Overreliance: чрезмерное доверие к результату работы систем ИИ без адекватного контроля, что приводит к распространению ненадлежащего или вредоносного контента.
— Model Theft: подразумевает несанкционированный доступ к моделям под капотом приложения.
https://genai.owasp.org/llm-top-10/
https://education.securiti.ai/certifications/ai-governance/controlling-data-inputs-and-outputs/attacks-against-generative-ai-systems-owasp-top-10-for-llms/
👍9
Привет всем!
Давно не писал. Есть несколько причин.
Первое. Немного охладел к классическому системному дизайну, даже взял отпуск от интервью по этой секции. Почти всё, что хотел сказать, уже сказал и чаще использую канал как референс на паттерны (вот тут, кстати, сборник постов, рекомендую). Есть ощущение, что дальше нужно либо уходить в очень глубокие дебри, либо повторять прописные истины.
Второе. В ТБанке я сильно сфокусировался на построении продуктов и платформ на базе AI (буквально моя зона ответственности). Индустрия развивается очень быстро: если ещё вчера все делали Single Prompt Applications, то сегодня модно строить мультиагентные архитектуры, всё больше приближая нас к AGI.
Теперь про канал и его позиционирование. Хочу открыть новую главу. Он по-прежнему будет про технические вещи, но с акцентом на то, что у меня сейчас в фокусе — AI. В ближайшее время я, скорее всего, переименую его. Давайте начнём с первого поста.
А пока и держите трейнспоттинг с моего рабочего места офиса на Белорусской.
Давно не писал. Есть несколько причин.
Первое. Немного охладел к классическому системному дизайну, даже взял отпуск от интервью по этой секции. Почти всё, что хотел сказать, уже сказал и чаще использую канал как референс на паттерны (вот тут, кстати, сборник постов, рекомендую). Есть ощущение, что дальше нужно либо уходить в очень глубокие дебри, либо повторять прописные истины.
Второе. В ТБанке я сильно сфокусировался на построении продуктов и платформ на базе AI (буквально моя зона ответственности). Индустрия развивается очень быстро: если ещё вчера все делали Single Prompt Applications, то сегодня модно строить мультиагентные архитектуры, всё больше приближая нас к AGI.
Теперь про канал и его позиционирование. Хочу открыть новую главу. Он по-прежнему будет про технические вещи, но с акцентом на то, что у меня сейчас в фокусе — AI. В ближайшее время я, скорее всего, переименую его. Давайте начнём с первого поста.
А пока и держите трейнспоттинг с моего рабочего места офиса на Белорусской.
This media is not supported in your browser
VIEW IN TELEGRAM
👍15🔥3
доклад ВШЭ.Вселенная.pdf
7 MB
Когнитивные архитектуры.
В воскресенье выступал в ВШЭ на мероприятии от Центра непрерывного образования ФКН с обзорным докладом о развитии "когнитивных архитектур" и, в частности, о Вселенной ассистентов ТБанка. Рассказал про рынок AI, историю продуктов и эволюцию генеративных архитектур, топ-10 угроз безопасности и то, как под капотом устроена наша система.
Прикрепляю слайды.
В воскресенье выступал в ВШЭ на мероприятии от Центра непрерывного образования ФКН с обзорным докладом о развитии "когнитивных архитектур" и, в частности, о Вселенной ассистентов ТБанка. Рассказал про рынок AI, историю продуктов и эволюцию генеративных архитектур, топ-10 угроз безопасности и то, как под капотом устроена наша система.
Прикрепляю слайды.
🔥29
Forwarded from [30/100] Витя Тарнавский
Собрал для вас табличку сервисов и фреймворков для создания агентских систем по уровню абстракции - от высокого и простого к низкоуровневым инструментам.
Если хотите посмотреть что такое агенты или сделать простую штуку, начинайте сверху. На уровень 4 спускаться примерно никогда не требуется.
Го в комменты где что забыл и у кого какой опыт
Если хотите посмотреть что такое агенты или сделать простую штуку, начинайте сверху. На уровень 4 спускаться примерно никогда не требуется.
Го в комменты где что забыл и у кого какой опыт
🔥13👎2
Think tank with LLM.
Первый раз увидел упоминания этого метода в прекрасном видео AI as Software Architect и с тех пор пользуюсь.
В классическом мире «think tank» — это исследовательский центр, где работают эксперты разных специальностей, которые совместно анализируют проблему, обсуждают разные точки зрения и формируют рекомендации.
В мире LLM можно моделировать нечто подобное за счёт «разделения» одной или нескольких моделей на несколько ролей или «агентов». Каждый «агент» имеет свою задачу (например, «эксперт по статистике», «консультант по маркетингу», «скептик» и т.д.).
Все «агенты» последовательно обмениваются своими мнениями, и в результате формируется сводное решение или ответ.
Я пользуюсь подходом chain-of-thought, вы даёте модели инструкцию вроде «
Позволяет не столько что-то нагенерировать, сколько посмотреть на проблему с разных сторон и увидеть неочевидные вещи в решении.
Держите несколько примеров:
— Линус Торвальдс, Эрик Эванс и Сэм Альтман решают как должен выгдядеть линукс через 10 лет
— Мобильный и бекенд разработчик выбирают между нативом, bdui и вебвью
— Команда придумывает стартап на 1М в велосипедной индустрии
Первый раз увидел упоминания этого метода в прекрасном видео AI as Software Architect и с тех пор пользуюсь.
В классическом мире «think tank» — это исследовательский центр, где работают эксперты разных специальностей, которые совместно анализируют проблему, обсуждают разные точки зрения и формируют рекомендации.
В мире LLM можно моделировать нечто подобное за счёт «разделения» одной или нескольких моделей на несколько ролей или «агентов». Каждый «агент» имеет свою задачу (например, «эксперт по статистике», «консультант по маркетингу», «скептик» и т.д.).
Все «агенты» последовательно обмениваются своими мнениями, и в результате формируется сводное решение или ответ.
Я пользуюсь подходом chain-of-thought, вы даёте модели инструкцию вроде «
Представь, что у нас есть команда экспертов: Эксперт A, Эксперт B и Эксперт C. Каждый по очереди высказывает своё мнение по задаче, основываясь на своей специализации, а потом они приходят к общему выводу».Позволяет не столько что-то нагенерировать, сколько посмотреть на проблему с разных сторон и увидеть неочевидные вещи в решении.
Держите несколько примеров:
— Линус Торвальдс, Эрик Эванс и Сэм Альтман решают как должен выгдядеть линукс через 10 лет
— Мобильный и бекенд разработчик выбирают между нативом, bdui и вебвью
— Команда придумывает стартап на 1М в велосипедной индустрии
👍13
Forwarded from Denis Sexy IT 🤖
Сделал простой гайд какие модели когда использовать в ChatGPT:
GPT-4o mini – лучше не использовать, самая слабая и придумывает ответы; не способна следовать сложным инструкциям
GPT-4o – быстрая модель, для быстрых ответов не требующих проверки фактов, может их придумывать; перевожу ей картинки в текст если нужно быстро. Ее ответы нужно всегда факт-чекать. Зато эта модель имеет доступ к памяти (где все про вас), с ней можно общаться голосом, через нее можно вызывать генерацию картинок Dalle. Не рекомендую обрабатывать большие файлы с ней
GPT-4o with scheduled tasks (beta) – использую только для To Do: модель пишет мне каждое утро и спрашивает приоритеты, показывает текущий список задач и тп
o3-mini – хорошая модель для кодинга и жизни, хорошо ищет в интернете, неплохо следуют инструкциям и при этом очень быстрая; если вам некогда и нужен быстрый ответ, то берите ее. Для анализа картинок и файлов «быстро» хороший кандидат. Не имеет доступа к памяти. Реже ошибается в фактах, но ошибается. В Plus тире – 150 сообщений в день.
✨o3-mini-high – это просто версия o3-mini, которую просят думать подольше перед тем как дать ответ – работает она медленнее, но еще реже ошибается, и еще качественнее решает задачи. Великолепно следует инструкциям. Хорошо работает с файлами. Я бы советовал сначала тратить 50 запросов этой модели, и дальше переходить к o3-mini или o1.
o1 – модель генератор отчетов, эссе и рефератов. Медленная модель. Хорошо следует инструкциям, может ошибиться в фактах. Не может искать в интернете. Хорошо видит картинки и читает файлы, не теряя деталей. У вас всего 50 запросов в неделю. Требует промптинга с описанием отчета которого вы хотите получить.
o1 pro mode – лучшая модель на рынке: почти никогда не ошибается в фактах, решает самые сложные задачи кодинга, дольше всех думает, лучше всех понимает изображения, но не умеет искать в интернете и не умеет работать с файлами напрямую. С точки зрения фактов – модель всегда сама себя перепроверяет, за ~3 месяца использования я только один раз поймал ее на неточности. Требует детального промптинга с описанием отчета который вы хотите. Доступна только в Pro тире, лимитов нет.
Deep research – несмотря на то, что модель выведена в отдельную кнопку, это версия новой o3 для поиска в интернете, как ей лучше пользоваться я напишу отдельно когда дадут доступ всем. Модель ищет в интернете и сама пишет код (который вам не покажет) для анализа найденных данных, чтобы, например включить в отчет графики. Лучшее, что есть на рынке для поиска данных в интернете. Пока доступна только в Pro. Если активируете эту кнопку - выбор модели в выпадашке – игнорируется, UX который мы заслужили
Tldr:
Для повседневных задач ваш лучший выбор – o3-mini-high, потом o3-mini, когда у первой кончились лимиты
GPT-4o mini – лучше не использовать, самая слабая и придумывает ответы; не способна следовать сложным инструкциям
GPT-4o – быстрая модель, для быстрых ответов не требующих проверки фактов, может их придумывать; перевожу ей картинки в текст если нужно быстро. Ее ответы нужно всегда факт-чекать. Зато эта модель имеет доступ к памяти (где все про вас), с ней можно общаться голосом, через нее можно вызывать генерацию картинок Dalle. Не рекомендую обрабатывать большие файлы с ней
GPT-4o with scheduled tasks (beta) – использую только для To Do: модель пишет мне каждое утро и спрашивает приоритеты, показывает текущий список задач и тп
o3-mini – хорошая модель для кодинга и жизни, хорошо ищет в интернете, неплохо следуют инструкциям и при этом очень быстрая; если вам некогда и нужен быстрый ответ, то берите ее. Для анализа картинок и файлов «быстро» хороший кандидат. Не имеет доступа к памяти. Реже ошибается в фактах, но ошибается. В Plus тире – 150 сообщений в день.
✨o3-mini-high – это просто версия o3-mini, которую просят думать подольше перед тем как дать ответ – работает она медленнее, но еще реже ошибается, и еще качественнее решает задачи. Великолепно следует инструкциям. Хорошо работает с файлами. Я бы советовал сначала тратить 50 запросов этой модели, и дальше переходить к o3-mini или o1.
o1 – модель генератор отчетов, эссе и рефератов. Медленная модель. Хорошо следует инструкциям, может ошибиться в фактах. Не может искать в интернете. Хорошо видит картинки и читает файлы, не теряя деталей. У вас всего 50 запросов в неделю. Требует промптинга с описанием отчета которого вы хотите получить.
o1 pro mode – лучшая модель на рынке: почти никогда не ошибается в фактах, решает самые сложные задачи кодинга, дольше всех думает, лучше всех понимает изображения, но не умеет искать в интернете и не умеет работать с файлами напрямую. С точки зрения фактов – модель всегда сама себя перепроверяет, за ~3 месяца использования я только один раз поймал ее на неточности. Требует детального промптинга с описанием отчета который вы хотите. Доступна только в Pro тире, лимитов нет.
Deep research – несмотря на то, что модель выведена в отдельную кнопку, это версия новой o3 для поиска в интернете, как ей лучше пользоваться я напишу отдельно когда дадут доступ всем. Модель ищет в интернете и сама пишет код (который вам не покажет) для анализа найденных данных, чтобы, например включить в отчет графики. Лучшее, что есть на рынке для поиска данных в интернете. Пока доступна только в Pro. Если активируете эту кнопку - выбор модели в выпадашке – игнорируется, UX который мы заслужили
Tldr:
Для повседневных задач ваш лучший выбор – o3-mini-high, потом o3-mini, когда у первой кончились лимиты
👍10🔥2
Паттерны GenAI приложений от Martin Fowler: Emerging Patterns in Building GenAI Products
Мартин Фаулер, эксперт по программной инженерии, известный многим по ряду статей о паттернах микросервисной архитектуры. Автор, чей сайт я неоднократно перечитывал и часто приводил ссылки на этом канале, опубликовал большую работу по паттернам построения GenAI приложений.
Новых концепций Мартин и его соавтор не вводят, но систематизируют и подают информацию о том, как нужно строить GenAI приложения со стороны программистов-практиков.
Не обходят стороной и такие вещи, которые даже Google в своих whitepappers пропускает - Embeddings и Evaluations.
Паттерны:
— Direct Prompting
— Embeddings
— Evals
— Hybrid Retriever
— Query Rewriting
— Reranker
— Retrieval Augmented Generation (RAG)
Мартин Фаулер, эксперт по программной инженерии, известный многим по ряду статей о паттернах микросервисной архитектуры. Автор, чей сайт я неоднократно перечитывал и часто приводил ссылки на этом канале, опубликовал большую работу по паттернам построения GenAI приложений.
Новых концепций Мартин и его соавтор не вводят, но систематизируют и подают информацию о том, как нужно строить GenAI приложения со стороны программистов-практиков.
Не обходят стороной и такие вещи, которые даже Google в своих whitepappers пропускает - Embeddings и Evaluations.
Паттерны:
— Direct Prompting
— Embeddings
— Evals
— Hybrid Retriever
— Query Rewriting
— Reranker
— Retrieval Augmented Generation (RAG)
martinfowler.com
Emerging Patterns in Building GenAI Products
Patterns from our colleagues' work building with Generative AI
👍22
Lecture 10.03.2025.DB.Indexes.pdf
4.2 MB
Сегодня из отпуска читаю лекцию в Академии Бэкенда - интересный экспириенс =). Тема - “индексы в СУБД”.
Если вдруг хочется вспомнить теорию, где они располагаются, сколько весят, что такое BRIN индексы и как частичные индексы могут облегчить жизнь — прикладываю презентацию. Пересылай в своих коллег.
Если вдруг хочется вспомнить теорию, где они располагаются, сколько весят, что такое BRIN индексы и как частичные индексы могут облегчить жизнь — прикладываю презентацию. Пересылай в своих коллег.
👍30
Я тут не так давно купил квартиру, делаю ремонт и ломаю голову как обустроить свое рабочее место.
Но вот на днях chatgpt выпустил убийцу фотошопа — в режиме gpt-4o научился редактировать изображения. Работает очень медленно, но очень помогает представить как это может выглядеть.
Попробовать тут.
Как варианты?)
Но вот на днях chatgpt выпустил убийцу фотошопа — в режиме gpt-4o научился редактировать изображения. Работает очень медленно, но очень помогает представить как это может выглядеть.
Попробовать тут.
Как варианты?)
🔥12👍9😢2🦄2🤷♂1👎1