Интересное что-то
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 Рыба-шарп
История autonomous driving от Антона Слесарева

Современная история autonomous driving началась в 2007-м. Сразу несколько команд сделали решение, автономно ездящее в игрушечном городе несколько часов без серьёзных инцидентов! В историю поверили фаундеры Google и собрали победителей в Google Self-Driving Car Project.

В 2012-м появились первые видео полностью беспилотных проездов!

В 2014-м уже стали катать внешнюю публику. И в 2020-м запустили настоящее такси.

Сейчас такси Waymo можно вызвать в 6–7 городах, и Лондон будет первой локацией за пределами Штатов!

У Waymo было много конкурентов, многих из которых создали выходцы из Google Self-Driving. Но все компании, открытые выходцами, либо закрылись, либо застыли в развитии. Из значимых игроков в США - Zoox (купленный Amazon), Tesla (про которую есть много сомнений, что её подход приведет к запуску), Cruise (куплен, а потом закрыт GM) ну и мой Avride(кстати последний независимый игрок на рынке!) В Китае есть несколько заметных игроков, но мне сложно судить об их зрелости.


Интересно, что CEO Waymo Дмитрий Долгов участвовал в DARPA Challenge, всё это время работал в компании в роли CTO, а недавно стал CEO. Ещё интересно, что он выпускник Физтеха, как и я - и мы одно время шутили, что во всех успешных self-driving компаниях CTO - с Физтеха.

Autonomous driving оказался сложнее любых самых пессимистичных прогнозов - например, с момента первых хороших демо до запуска прошло аж 6 лет. И даже сейчас полностью беспилотно в США ездят только полторы компании. И лидер рынка Waymo работает только в ограниченных зонах! С другой стороны, даже эта технология позволила завоевать заметную долю рынка. Лично я всегда выбираю такси без постороннего человека и уверен, что вот оно - будущее!

Если хотите подробнее почитать про историю - есть отличная книга Driven https://www.goodreads.com/book/show/52767920-driven

Сейчас происходит бум робототехники. Ожидать ли прорывов или ждать ещё 10 лет? Об этом я готов написать еще один гостевой пост у Феди, но только если этот наберёт 100 лайков!

#гостевойпост

Подписаться на канал https://t.iss.one/rybasharp
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