AI-хайп. Что такое AI-агенты и как работает RAG?

RAG (Retrieval Augmented Generation) — это метод работы с большими языковыми моделями, когда пользователь пишет свой вопросы, а вы программно к этому вопросу «подмешиваете» дополнительную информацию из каких‑то внешних источников и подаете все целиком на вход языковой модели. Другими словами вы добавляете в контекст запроса к языковой модели дополнительную информацию, на основе которой языковая модель может дать пользователю более полный и точный ответ.
О том, что же такое RAG более подробно можно почитать тут.

Как работает RAG.
Рассмотрим схему на рисунке.
1⃣ Предположим у нас есть UI (интерфейс). Сначала мы загрузим документы в нашу базу знаний (в любом формате: pdf, doc, да хоть в json) через сервис DocumentLoader.

2⃣ Сервис DocumentLoader перед тем, как поместить документы в хранилище, преобразует их в векторный вид с помощью Embedding Model - например из английского слова «cat» вы получите нечто похожее на [0.2, -0.4, 0.7]

3⃣ Получив в ответе от Embedding Model векторное представление документа сервис DocumentLoader сохраняет его в векторную БД Vector Database.

4⃣ После того, как мы загрузили в БД документы нашей базы знаний в векторном формате, мы можем начать работу с RAG и LLM.
Вопрос пользователя попадает в сервис Mediator, который направляет запрос в сервис RAG для поиска релевантной вопросу информации в хранилище.

5⃣ Сервис RAG преобразует вопрос пользователя в векторный вид с помощью Embedding Model и ищет совпадения в векторном хранилище, которые возвращает в качестве ответа.

6⃣ Сервис Mediator использует полученную в ответе от сервиса RAG информацию для обогащения контекста запроса в LLM.

7⃣ Ответ от LLM, при формировании которого был учтен контекст из базы знаний, возвращается пользователю на UI.

Как работают AI-агенты
Сервис Mediator в связке с LLM также может реализовывать функции AI-агента.

Если в процессе обработки запроса пользователя необходимо выполнить какие то действия, в том числе, основываясь на результатах обработки языковой моделью (LLM) вашего запроса, то здесь на помощь вам могут прийти AI-агенты.
Один из самых популярных подходов к реализации агентов называется ReAct - парадигма, объединяющая рассуждение и выполнение действий. Более подробно об устрйостве можно почитать по ссылке.

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

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

Mediator сходит в векторное хранилище за релевантной информацией, затем вызовет LLM, которая, обработав запрос, может принять решение, что ей недостаточно данных для того, чтобы фактологически точно дать ответ на вопрос и вызовет ту часть (Tools - см. статью по ссылке выше) сервиса Mediator, которая имеет подключение к внешним API (например API поиска Google), для того, чтобы она нашла в интернете релевантную информацию с новостями о нефтедобыче, дообогатила ей контекст запроса и снова вызвала LLM, а затем вернула ответ пользователю.

P.S. Не претендую на фактологическую точность материала, рассказываю то, как я это понимаю сам и с чем сталкивался в работе. Если среди подписчиков есть специалисты в ds/ml/ai, буду рад комментариям/исправлениям/дополнениям 🐈

Всем, привет!
У меня две новости:

1⃣ Я выздоровел, а это значит, что у меня хорошее настроение, поэтому объявляется минута юмора 🤣
Лучше смотреть со звуком.

2⃣ Осталось 1 свободное место для записи на обучение до оффера, стартуем в субботу 22 марта. Записаться - ко мне в личные сообщения

Всем хорошего дня! ⭐

🕊🌿👆🌸🔹🌺💎🔹

👨‍💻 Открыта запись на новый поток обучения системных аналитиков с нуля до Middle+ на ближайшие 1,5 месяца.
Старт занятий - 22 марта.

Ознакомиться с содержанием и стоимостью вы можете здесь.

Что ждет вас на обучении?

• 8 онлайн-занятий с изучением теории и отработкой практики. Никаких записанных видео и кучи ссылок. Только живое общение со мной 👨‍💻

• Акцент на техническую составляющую самых распространенных типов интеграций (REST, gRPC, Kafka, RabbitMQ) и архитектуру систем 👨‍💻

• Резюме Middle аналитика с ориентиром на 200+ 💰

Записаться - ко мне в личные сообщения @oldschoolsysdes

⚠️UPD: старт переносится на неделю вперёд, на 22 марта, так как я заболел гриппом :(

Друзья, привет!
Сегодня пост посвящен самой хайповой теме - AI 😅

В работе системного аналитика AI ускоряет и автоматизирует довольно много рутинных операций.

На своем курсе я показываю обучающимся, как можно использовать LLM для:
🔘формирования Use Case’ов
🔘построения по ним Sequence-диаграмм в PlantUML
🔘формирования ER-диаграмм при проектировании БД
🔘проектирования спецификаций REST API в формате OpenAPI, проектирования protobuf-файлов для gRPC, описания json-схем.

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

А вчера мои коллеги поделились ссылкой на вот такой продукт калифорнийского стартапа https://www.cursor.com

Это форк среды разработки VSCode, к которому прикручен AI-copilot, умеющий бесплатно из коробки формировать структуру репозитория прямо в IDE, устанавливать зависимости, писать код, дебажить, запускать скрипты и сам проект на твоей машине 🤯

Под капотом бесплатный gpt-4o-mini и даже он творит нечто нереальное - можно собрать MVP проекта на любом языке меньше чем за час в пару десятков кликов, что, собственно, мои коллеги и сделали 🤑

Интересно было бы узнать ваше мнение и опыт использования AI в повседневной работе в комментариях 😊

Друзья, привет!
Сегодня немного теории 🤓

Если вам в работе придётся сталкиваться с необходимостью гарантировано доставлять сообщения до какого-либо сервиса, то вам необходимо будет реализовать архитектурный паттерн Transactional Outbox (или просто Outbox), гарантирующий модель доставки at least once (хотя бы один раз).

Как работает паттерн?
Предположим, что есть два микросервиса: Сервис А и Сервис В.
Задача состоит в том, чтобы после получения сообщения в Сервис А, гарантировано передать данные из него в Сервис В.

Без использования какого-либо механизма обеспечения надежности этот процесс мог бы выглядеть следующим образом:
1. Сервис А обрабатывает запрос клиента.
2. После успешной обработки сообщения Сервис А отправляет сообщение в Сервис В через брокер (например, Kafka).

Но тут возникает проблема: если при передаче сообщения произойдет сбой (сеть упадет, очередь окажется перегруженной), мы можем потерять данные.
Сообщение будет обработано сервисом А, но до сервиса В не дойдет.

Чтобы избежать этой проблемы, используется паттерн Transactional Outbox.

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

Примерный порядок действий выглядит так:

1⃣ Сервис А получает запрос.

2⃣ Затем внутри транзакции:
🔘Сохраняется информация о запросе
🔘Создается запись в таблице Outbox с информацией о сообщении, которое должно быть доставлено
🔘Транзакция фиксируется

3⃣ Асинхронная задача (например шедулер в сервисе А) берет записи из таблицы Outbox и пытается отправить их в сервис В:
🔘Если доставка прошла успешно, то в БД данной записи проставляется атрибут (например status), свидетельствующий об ее успешной отправке в сервис В, или запись удаляется из таблицы Outbox
🔘Если происходит ошибка при доставке, асинхронная задача продолжает попытки до тех пор, пока доставка не завершится удачно

4⃣ Сервис В читает сообщения из брокера.

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

👨‍💻 Небольшая подборка полезных материалов для недавно присоединившихся к сообществу

1⃣ Самостоятельное обучение
🔘Системный аналитик. Часть 1.
🔘Системный аналитик. Часть 2.
🔘Системный аналитик. Часть 3.
🔘Системный аналитик. Часть 4.
🔘Системный аналитик. Часть 5.

2⃣ Архитектура
🔘Как устроены современные приложения
🔘Микросервисы
🔘Масштабирование систем
🔘CQRS+Event Sourcing
🔘Saga

3⃣ Интеграции
��REST
��gRPC
🔘Kafka
🔘RabbitMQ

👨‍💻 Спешу сообщить, что один из самых популярных видов спорта этой зимой - спортивное вкатывание в айти

16 февраля стартует последний в уходящей зиме трек моего менторства для системных аналитиков.
🤓 Подробная информация про обучение - по ссылке.

🛞Осталось 3 свободных места.
Записаться - ко мне в личку @oldschoolsysdes

🤷‍♂️ Зачем аналитику необходимо уметь читать код?

По результатам опроса в канале и под статьей на Хабре образовалась интересная статистика, которая превзошла мои ожидания.

🟨 В обоих случаях целые 44% опрошенных (почти половина) проголосовали за вариант «мне приходилось погружаться в код и читать его».

А если учесть, что и в канале и на Хабре треть опрошенных (35% и 40% соответственно) проголосовала за вариант «посмотреть результаты», то получим около 70% аналитиков, сталкивавшихся с необходимостью погружаться в код своих коллег и это колоссальные цифры! 🤯

О чем же они говорят?

😳 1. Плохая документация
На это могло повлиять множество факторов. Как основные: или отсутствие аналитиков, или сложный запутанный домен, или команда работала в режиме «стартап», когда главное было пилить как можно быстрее новый функционал для бизнеса. Или все вместе взятое 👨‍💻

☹️2. Плохие процессы
Возможно, что в команде не были должным образом выстроены процессы проектирования, разработки и тестирования:
отсутствовали соглашения по проектированию и описанию требований, отсутствовала культура тестирования (напомню, что хорошо описанные требования на разработку являются основой для формирования тест-кейсов, и хорошие QA будут требовать документацию от аналитиков).

Что делать?

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

1⃣ Получить доступ к тестовому стенду и попробовать понять, какой функционал есть в системе.

2⃣ Определить круг стейкхолдеров продукта и подготовить вопросы для интервью о его функциональности.

3⃣ Изучить таск‑трекер (условная Jira) на предмет следов разработки (можно узнать о том какие сервисы и фичи были сделаны ранее)

4⃣ Пройтись по всем разработчикам и узнать, какие сервисы они разрабатывают/разрабатывали на проекте и вообще что они о нем знают.

5⃣ Изучить систему контроля версий (например GitLab или BitBucket) — позволит найти сервисы и их код.

5⃣🧡 Изучить конфигурацию сервисов. В ней могут быть скрыты URL-адреса интеграций и иных взаимодействий (БД, брокеры итд).

5⃣🌿 Изучить API, если есть описание. Если нет, то придется погружаться в чтение кода.
На всем этом этапе очень полезным станет отрисовка схемы микросервисов и определение структуры моделей данных в БД.
На схему микросервисов будет необходимо нанести сервисы, стрелочками изобразить взаимодействие между ними, и желательно написать имя используемого метода и его URL.
БД можно описывать в табличном виде или в виде ER-диаграмм.

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