Интересное что-то
517 subscribers
2.71K photos
253 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.iss.one/asisakov_channel
Чат: https://t.iss.one/youknowds_chat
Download Telegram
Forwarded from Daniilak — Канал
This media is not supported in your browser
VIEW IN TELEGRAM
JS-библиотека для визуализации данных в реальном времени. Делает интерактивные дашборды, легко тянет большие наборы данных, лайв-обновления и сложную аналитику

#сервисы@daniilak
Forwarded from New Yorko Times (Yury Kashnitsky)
#google #genai

Ну что, Gemini 3 Pro Image – первая text2image модель, которая реально полезна, скажем, в блоггинге или преподавании для создания иллюстраций. К примеру, те же деревья решений

проиллюстрируй в виде инфографики энтропийный принцип поиска признака для разбиения в дереве решений https://habr.com/ru/companies/ods/articles/322534/


На всякий случай прогнал через Gemini, чтоб улучшить промпт (в Vertex есть фича "Help me write" для этого) – и вот на выходе.

Мое почтение.

На русском языке еще видны артефакты, но это пофиксят
Forwarded from DeepSchool
Vision-Language-Action (VLA) Models: от токенов к действиям

Современные мультимодальные модели умеют работать с визуальными данными и текстом. Следующий шаг их развития — взаимодействие с физическим миром. Для управления роботами создаются Vision-Language-Action (VLA) модели, которые переводят визуальные данные и текстовые инструкции прямо в моторные команды робота. О том, как устроены такие модели, рассказываем в новой статье. 🤖

Из неё вы узнаете:
• как устроены VLA-модели — от визуального энкодера до генератора действий
• какие архитектуры используются для предсказания движений — от дискретных токенов до диффузий и Flow Matching'а
• какие существуют подходы к дообучению систем — от полного fine-tuning'а до PEFT-методов, таких как LoRA
• с какими проблемами сталкиваются VLA в реальном мире: задержки, накопление ошибок и безопасность

Читайте новую статью по ссылке! 🚀

🪔 DeepSchool
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
Зачем нам A2A и причем тут ACP
#Протоколы_в_агентах

Второй по важности протокол в агентах - A2A. Он решает важную проблему взаимодействия агентов между собой. Давай разберемся, что к чему?

Что такое A2A🤨
По своей сути A2A - это протокол связи для агентов. Сегодня существуют куча фреймворков для создания агентов - LangGraph, CrewAI, Google ADK, Microsoft Autogen, что угодно. Без A2A, если бы вы попытались заставить агента LangGraph напрямую общаться с агентом CrewAI, вас бы ждал мир головной боли от пользовательской интеграции. 

Как работает A2A изнутри🤔
Давайтезаглянем под капот. Протокол A2A построен на знакомых веб-технологиях: он использует JSON-RPC 2.0 по HTTP(S) в качестве основного метода коммуникации. На неинженерном языке это означает, что агенты отправляют друг другу сообщения в формате JSON посредством стандартных веб-вызовов. Он также поддерживает полезные дополнения, такие как Server-Sent Events (SSE) для потоковых обновлений и асинхронных обратных вызовов для уведомлений. Так, если агент A задаёт агенту B вопрос, который займёт некоторое время (например, B должен обработать данные за 2 минуты), B может передать частичные результаты или обновления статуса A, вместо того чтобы оставлять A в тишине. Но что же нужно для того, чтобы эти взаимодействия работали:
1️⃣ Карточка агента (обнаружение возможностей): каждый агент, использующий A2A, представляет карточку агента - по сути, JSON, описывающую его сущность и возможности. В карточке указано имя агента, его описание, версия и, что немаловажно, список доступных навыков.
2️⃣ Навыки агента: это индивидуальные возможности агента, перечисленные в его карточке агента.
3️⃣ Задачи и артефакты (управление задачами): когда агент A хочет, чтобы агент B что-то сделал, он отправляет запрос на задачу . Задача - это структурированный JSON-объект (определяемый протоколом A2A), описывающий задачу, которую необходимо выполнить.
4️⃣ Сообщения (совместная работа агентов): фактическая информация, которой обмениваются агенты - контекст, вопросы, частичные результаты и т. д. - отправляется в виде сообщений . По сути, это разговор, происходящий для выполнения задачи. Протокол позволяет агентам отправлять в сообщениях различные типы контента, а не только простой текст.

A2A и MCP🤑
По сути, MCP — это то, как агенты вызывают инструменты, A2A — то, как агенты вызывают друг друга . Один подход похож на вызов функции или использование приложения; другой — на разговор с коллегой. Оба подхода часто работают рука об руку : агент может использовать MCP для получения данных, а затем использовать A2A, чтобы попросить другого агента проанализировать эти данные, и всё это в рамках одного сложного рабочего процесса.

Причем тут ACP🔨
После поста про MCP я писал, что хочу расписать все про ACP, но так вышло, что фактически A2A его поглотил. Причина очень проста: ACP и A2A решают почти одну и ту же задачу — протокол “агент агент”, поэтому сейчас про этот протокол особо не вспоминают.

Фух, надеюсь стало понятнее. Пробовали ли вы протокол A2A, и если да, то в каких проектах?) Буду рад ваших историях😎

💗 - настройка сервера A2A+MCP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 5 minutes of data
A Great Day Out With... Apache Kafka

Интерактивная карта всей экосистемы Kafka.

В этой карте собрано все, что вам может понадобиться при работе с Kafka.

Это:
- Книги
- Блоги
- Учебные материалы
- Инструменты
и многое другое.

Карту составил Gunnar Morling - разаработчик в Confluent, один из разработчиков Debezium и автор kcctl (open-source CLI тулза для работы с Kafka)

@five_minutes_of_data
Forwarded from РИСЕРЧОШНАЯ
4️⃣5️⃣6️⃣

Главный bottleneck в рекомендациях — embedding-таблицы

Давно хотел рассказать про такую интересную штуку как unified embeddings, и кажется, что этот подход реально БАЗОЙ в генеративных рекомендациях.

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

В отличие от LLM где вокабуляр составляет 40-50 тысяч токенов, мы оперируем миллионами товаров и пользователей. Поэтому мы ограничены как в расчете full CE, так и в том что-бы хранить все пространство.


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

Один из таких подходов предложили исследователи Google под названием Feature Multiplexing: вместо независимых таблиц для каждого признака модель использует единое пространство эмбеддингов.

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

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

Безусловно за все хорошее надо платить — теперь у вас открывается пассивный навык в виде 1-5% коллизий.

Кроме Google unified матрицы используют Pinterest, Netflix, Yandex, WB, определенно стоит присмотреться!

➡️ Unified Embedding

В предыдущем посте кстати угадали альтернативную версию — semantic id. Одну из проблем мы решили, но вот вам следующий кейс: FullCE вы считать не можете у вас слишком много классов, а что тогда?
Please open Telegram to view this post
VIEW IN TELEGRAM
➡️Как сделать ИИ-чатбота менее болтливым. Совет от OpenAI

Ребята из OpenAI в мануале по ЖПТ-5.1 рекомендуют добавлять следующий текст к промпту:

Вы цените ясность, динамику и уважение, измеряемое полезностью, а не любезностями. Ваш инстинкт по умолчанию — поддерживать беседы четкими и целенаправленными, отсекая все, что не продвигает работу вперед. Вы не холодны — вы просто экономны в языке и достаточно доверяете пользователям, чтобы не оборачивать каждое сообщение в "набивку".
- Адаптивная вежливость:
- Когда пользователь тепло относится, детализирует, проявляет внимание или говорит «спасибо», вы предлагаете одно, краткое подтверждение — небольшой кивок в ответ на их тон с помощью токенов подтверждения или получения, таких как «Понял», «Я понимаю», «Пожалуйста» — затем немедленно переключаетесь обратно на продуктивное действие. При этом не будьте приторными или чрезмерно поддерживающими.
- Когда ставки высоки (сроки, вопросы соответствия, срочная логистика), вы отбрасываете даже этот небольшой кивок и сразу переходите к решению или сбору необходимой информации.
- Основная склонность:
- Вы говорите с обоснованной прямотой.
- Вы верите, что самое уважительное, что вы можете предложить, — это эффективность: чистое решение проблемы без лишней болтовни.
- Вежливость проявляется через структуру, точность и оперативность, а не через словесный «пух».
- Отношение к токенам подтверждения и получения:
- Вы относитесь к подтверждению и получению как к необязательной приправе, а не к самому блюду.
- Если пользователь быстр или лаконичен, вы соответствуете этому ритму с почти полным отсутствием подтверждений.
- Вы избегаете стандартных подтверждений, таких как «Понял» или «Спасибо, что обратились», если только тон или темп пользователя естественным образом не приглашают к краткому, пропорциональному ответу.
- Ритм разговора:
- Вы никогда не повторяете подтверждения. Как только вы сигнализировали о понимании, вы полностью переключаетесь на задачу.
- Вы внимательно прислушиваетесь к энергии пользователя и отвечаете в том же темпе: быстро, когда они быстры, более пространно, когда они многословны, всегда оставаясь сфокусированным на действии.
- Основной принцип:
- Ваша философия общения — «уважение через динамику». Вы теплы в намерении, но лаконичны в выражении, фокусируя каждое сообщение на том, чтобы помочь пользователю продвигаться вперед с минимальным трением.


Этож сколько сил требуется на убеждение модели, чтобы с нее как с рога изобилия всякая дичь не лилась??😄
Рекомендую запомнить эту мантру перед началом планерок😄
Please open Telegram to view this post
VIEW IN TELEGRAM