Как вы знаете, я сейчас руковожу разработкой в AI-Центр Т-Банка. Мы делаем очень крутые AI first продукты и платформы. Мне часто говорят, что тут одни ML-задачи, это совсем не так. Немного расскажу.

Технологически все выглядит примерно так — у нас микросервисы. Мы пишем на Python и Golang. Используем как стандартные PG, Redis и прочее, так и специфические вещи вроде векторных БД (см. Milvus). Решаем крутые инженерные задачки вроде как гонять огромные потоки аудио через микросервисы с минимальной задержкой. Или что такое LLM-платформа и как ее построить таким образом, чтобы можно было на базе этого создавать продукты с минимальным TTM.

Мы создаем Вселенную AI-ассистентов — это финансовый, инвестиционный, шоппинг и другие ассистенты. Мы строим для этого целую LLM-платформу на базе нашего семейства языковых моделей.

Мы разрабатываем новое поколение пользовательской поддержки — это наш смелый стартаперский эксперимент по внедрению LLM в обслуживание клиентов, продажи и коллекшен. Результаты этой работы ощутят миллионы клиентов и десятки тысяч сотрудников. Мы меняем то, как работает большая компания, а возможно, и вся индустрия.

А еще куча всего: голосовые технологии, компьютерное зрение, рекомендательные платформы.

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

И если что, помимо ML-инженеров, мы в поиске как сильных backend и mobile инженеров, так и руководителей разработки. Если чувствуете в себе силы или есть вопросы — заходите ко мне в личку @skogorev.

Как работает 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

Как Netflix обеспечивает высокую доступность stateful системам.

Вышла очень интересная статья Нетфликса о доступности в распределенных 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…

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://t.me/startup_architecture/88

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://t.me/startup_architecture/96
https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead

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/

ArchGPT — Архитектура с помощью GPT.

Давно думал, как подступиться к этому вопросу — как заставить GPT дизайнить архитектуру? Чтобы получше, чем качество уровня рандомного человека с улицы.
Пока не наткнулся на интересную статью https://www.accidental-architect.com/archgpt

Идея в следующем — если мы можем представлять нашу архитектуру как “код” (в статье приводится пример с моделью С4 — способ записи архитектуры системы в виде “контекст-контейнер-компонент-код”), то GPT может отлично понимать такой формат.

Тогда задача системного дизайна сводится к задаче “кодогенерации”, которую GPT умеет решать. В статье, например, приводится пример с тем, что GPT спросили, как перейти с json на protobuf. Модель подсказала, какие изменения в каких системах это повлечет, и как изменится сам документ архитектуры.

В дополнение получаем новый тип интерактивной документации.

Если подумать, как правильно прикрутить RAG, можно делать совсем интересные вещи.

Accidental-Architect

ArchGPT | The Accidental Architect

A crazy looking robot software architect, standing in front of a whiteboard of crazy designs

Подход Change Data Capture как способ реактивного взаимодействия сервисов.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/

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

Для решения подобных задач на помощь приходит подход Change Data Capture (CDC) или “Захват изменения данных”.

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

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

С применением этого подхода можно реализовать несколько популярных паттернов, таких как CQRS (чтобы развязать потоки чтения и модификации данных) или Strangler (чтобы распилить монолит на микросервисы).

Какую функциональность можно реализовать с помощью этого подхода:
— Репликация (Другая БД? DWH?)
— Обновление и инвалидация кэшей
— Экспорт данных в поисковые движки (Elastic?)
— Аудит изменений в БД
— Передача состояния другим сервисам

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/754802/
https://en.wikipedia.org/wiki/Change_data_capture

Хабр

Change Data Capture (CDC) в Yandex Data Transfer: гид по технологии с примерами

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

GPT как оркестратор микросервисной архитектуры?
Мы знаем, что GPT-модели могут писать SQL-запросы или код. Новая парадигма — А что если GPT будет формировать пользовательский флоу в архитектуре нашего сервиса?

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

Что если мы опишем базовые функции нашего сервиса и дадим GPT возможность самому конструировать пользовательские сценарии?

Я решил сделать сервис заказа еды. У меня есть несколько функций системы, про которые я рассказываю ассистенту:
\- make_order([{item, count}]) \- cancel_order…
Дальше я прошу ассистента обслужить пользователя — GPT может самостоятельно составить цепочку вызовов, которые нужно совершить для того, чтобы понять, что хочет пользователь, и сходить в нужные сервисы.
GPT выступает как замена части бизнес-логики приложения, отвечающей за формирование пользовательского пути по вашей архитектуре.
Просто посмотрите пример.

Такое становится доступным благодаря подходу RAG (Retrieval-Augmented Generation), когда обученной на большой базе знаний модели (GPT) на вход подсовывают динамический контекст (описание сервиса заказа еды). Если хочется начать углубляться — можно начать отсюда: https://habr.com/ru/articles/779526/

Как вы используете GPT-ассистентов? Спрашиваете советы или строите поверх системы и продукты?