Привет, Хабр! Пол года назад на AnalystDays #18 я рассказывал про API-контракты, и доклад вызвал большой интерес у аудитории. Пока видео не опубликовали, решил адаптировать материал в формат статьи.

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

Привет, Хабр!

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

Если возникает вопрос об описании архитектуры системы, то есть несколько основных решений где и как это сделать. Среди популярных нотаций для визуализации схемы архитектуры можно выбрать C4, разработанную Саймоном Брауном.

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

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

В мире интеграций REST API на сегодняшний день занимает по праву свое почетное, королевское место. Сегодня мало какой проект или продукт обходится без стандартных HTTP-методов и документации к ним.

Но если для REST API уже всемирную славу приобрел Open API со своей Swagger-документацией, которая внедряется практически повсеместно и является по праву, так сказать, золотым стандартом, то для брокеров сообщений и, в целом для асинхронного взаимодействия, в большинстве случаев дела обстоят далеко не так однозначно.

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

На некоторых порталах, в том числе и здесь, уже косвенно поднималась тема AsyncAPI и вызывала у авторов, как правило, смешанные чувства. Описывали преимущества и недостатки, приводили некоторые примеры. Справедливо отметить, что AsyncAPI, конечно же, не идеален.

Но если посмотреть на это с другой стороны: удобно ли будет разработчику читать ТЗ и другую документацию касаемо разработки интеграции по асинхрону, слепленную из кусков текста, таблиц, рисунков, непонятных ссылок и т.д.? Одно дело, если разработчик находится на проекте с самого начала и знает все тонкости и может сам что-то додумать. Но если человек придет на проект уже через один, два или более лет после начала проекта и увидит тонны макулатуры, которую как-то нужно читать и анализировать, то вот тут начинаются трудные времена.

Системы дополненной генерации (RAG) были разработаны для улучшения качества ответа крупной языковой модели (LLM). Когда пользователь отправляет запрос, система RAG извлекает релевантную информацию из векторной базы данных и передает ее в LLM в качестве контекста. Затем LLM использует этот контекст для генерации ответа для пользователя. Этот процесс значительно улучшает качество ответов LLM с меньшим количеством «галлюцинаций».

С момента написания моей прошлой статьи прошло не так много времени, но прогресс не стоит на месте и произошло несколько важных изменений. Раньше про RAG можно было услышать из холодильника, теперь же ситуация изменилась. Каким образом - читайте дальше.

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

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

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

Я разделяю вашу боль, давайте разберемся, о чем они говорят.

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

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

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

От теории из оригинальной академической статьи до ее реализации на Python с OpenAI, Weaviate и LangChain

Меня зовут Грибанов Никита, я Data Scientist в отделе R`n`D&ML компании Raft Digital Solutions, и сегодня я расскажу о больших языковых моделях. На данный момент в мире их существует уже более 39 тысяч! Далее буду называть их хайповым названием LLM (Large Language Model).

В этой статье вы сначала узнаете новые или освежите в памяти уже известные вам основы общения с языковыми моделями. Затем разберёте пару реальных примеров настройки запросов и увидите математические возможности Llama 3.2 3B в сравнении с Llama 3.1 8B.

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

Два наиболее интересных похода в создании AI‑систем в 2024 — это агенты (agents, agentic AI systems) и мультиагентность (multi‑agent systems)

Ключевая черта, отличающая агентов от других AI‑систем — это автономность

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

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

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

Привет, Хабр! Меня зовут Матвей Мочалов, я — компьютерный инженер и один из авторов корпоративного блога cdnnow! Как-то мы уже обсуждали особенности Docker на разных системах, а сегодня я хочу копнуть глубже — поговорить о том, как наша индустрия поймала саму себя в ловушку Джокера и умудрилась запутать всех, выдавая контейнеризацию за виртуализацию.

Продолжим об этом ниже в посте.

Привет! Меня зовут Женя, я бэкенд-разработчик, и в этом посте хотела бы кратко обсудить плюсы и минусы разных вариантов идентификаторов в базе данных.

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

В контексте разговоров о больших языковых моделях (LLM) все чаще возникает аббревиатура RAG – Retrieval-Augmented Generation, или если переводить на русский язык, то «поисковая дополненная генерация». В этом тексте попробуем в общих чертах разобраться, как работает RAG, и где он может быть применим на практических задачах.

Краткое и понятное описание подхода RAG (Retrieval Augmented Generation) при работе с большими языковыми моделями.