Forwarded from Refat Talks: Tech & AI
Продолжаю про file-first подход к агентам для работы с базами знаний. В прошлом посте рассказал про общий концепт и rclone. В этом посте как и обещал расскажу про поиск по бинарным (не-текстовым) файлам.
Напомню что общая идея - использовать всю мощь передовых кодинг-агентов (в данном случае Claude Code) для задачи работы с базами знаний.
Итак, синхронизация настроена, имеем на быстром диске файлы, но большинство из них в формате Word, PDF, Excel, PowerPoint. По дефолту Claude Code (а точнее в его обертке под названием Agent SDK) доступны все инструменты для поиска по текстовым файлам (grep, ripgrep и тд), но эти файлы не текстовые.
Первая мысль была: ок, давай конвертнем все в plain text (есть же docling, markitdown и тд). Но хотелось чего-то проще, не хотелось строить пайплайн индексации: это и время, и дублирование источника истины, и проблема инвалидации - файлы-то постоянно обновляются. Хотелось найти решение которое работает напрямую с Office файлами.
Эксперименты
Создал тестовое окружение: 150 документов в разных форматах и сравнивал такой шортлист, который мне подкинул deep research:
- ripgrep c расширенными настройками (на самом деле их было больше) - почти сразу отпал
- pdfgrep - прекрасно ищет по PDF файлам
- ugrep - хоть и ищет по всем файлам, но по-началу давал средние результаты, например был хуже pdfgrep для pdf и плохо искал по презентациям, но потом я открыл его суперсилу - фильтры!
Фильтры ugrep - вот где магия
ugrep умеет на лету конвертить файлы через внешние тулы перед поиском. Для этого используется флаг
Пример:
Или еще проще:
Самое крутое - ugrep уже идет с набором преднастроенных фильтров для популярных форматов. В итоге pdfgrep и другие специализированные тулы оказались не нужны -
ugrep еще умеет искать в архивах (zip, tar, gz) без распаковки, поддерживает fuzzy-поиск и regex с Unicode, может выдавать контекст вокруг найденного текста с подсветкой и все это можно конфигурировать через .ugrep конфиг-файл. Короче, швейцарский нож для поиска.
По скорости. На деле с быстрым диском поиск по тысячам документам занимает доли секунды и не является узким местом в агентных сценариях. Но если база огромная и нужна реальная скорость - у ugrep есть встроенная система индексирования через
Далее, чтобы это эффективно работало было несколько раундов работы с промптом агента. Одна из лучших идей оказалась - инструктировать агента сначала запускать команду
Почему file-first - это кайф
Мне нравится работать в file-first экосистеме. Linux - это filesystem-first операционка и в этом мире много сильных инженеров и очень развитый опенсорс. Поражаешься как много эффективных и производительных тулов доступны, они просто работают. Плюс это же все текстовые интерфейсы - CLI + stdin/stdout - кодинговые агенты (считай LLM) с ними на ты. Никаких API оберток, никаких дополнительных слоев абстракции. Просто композиция мощных Unix-тулов.
В будущих постах по этой теме планирую покрыть:
- Другие челленджи: чтение и понимание содержимого нетекстовых файлов
- Когда все-таки нужны индексы или "шпаргалки" (или навигаторы) для таких агентов
- Опыт с Remote MCP и вопросы авторизации
- Подходы к разграничению прав доступа
- Вопросы изоляции (безопасность)
🔥 ➕ 🔁поддержите если хотите больше на эту тему
Напомню что общая идея - использовать всю мощь передовых кодинг-агентов (в данном случае Claude Code) для задачи работы с базами знаний.
Итак, синхронизация настроена, имеем на быстром диске файлы, но большинство из них в формате Word, PDF, Excel, PowerPoint. По дефолту Claude Code (а точнее в его обертке под названием Agent SDK) доступны все инструменты для поиска по текстовым файлам (grep, ripgrep и тд), но эти файлы не текстовые.
Первая мысль была: ок, давай конвертнем все в plain text (есть же docling, markitdown и тд). Но хотелось чего-то проще, не хотелось строить пайплайн индексации: это и время, и дублирование источника истины, и проблема инвалидации - файлы-то постоянно обновляются. Хотелось найти решение которое работает напрямую с Office файлами.
Эксперименты
Создал тестовое окружение: 150 документов в разных форматах и сравнивал такой шортлист, который мне подкинул deep research:
- ripgrep c расширенными настройками (на самом деле их было больше) - почти сразу отпал
- pdfgrep - прекрасно ищет по PDF файлам
- ugrep - хоть и ищет по всем файлам, но по-началу давал средние результаты, например был хуже pdfgrep для pdf и плохо искал по презентациям, но потом я открыл его суперсилу - фильтры!
Фильтры ugrep - вот где магия
ugrep умеет на лету конвертить файлы через внешние тулы перед поиском. Для этого используется флаг
--filter или его алиас `ug+`. Работает просто: ты говоришь "для файлов .docx юзай pandoc, для .pdf юзай pdftotext" и все.Пример:
ugrep --filter="docx:pandoc %f -t plain" --filter="pdf:pdftotext % -" "искомая фраза"
Или еще проще:
ug+ "искомая фраза"
Самое крутое - ugrep уже идет с набором преднастроенных фильтров для популярных форматов. В итоге pdfgrep и другие специализированные тулы оказались не нужны -
ugrep is all you need.ugrep еще умеет искать в архивах (zip, tar, gz) без распаковки, поддерживает fuzzy-поиск и regex с Unicode, может выдавать контекст вокруг найденного текста с подсветкой и все это можно конфигурировать через .ugrep конфиг-файл. Короче, швейцарский нож для поиска.
По скорости. На деле с быстрым диском поиск по тысячам документам занимает доли секунды и не является узким местом в агентных сценариях. Но если база огромная и нужна реальная скорость - у ugrep есть встроенная система индексирования через
ugrep-indexer, которая может дать ускорение в разы.Далее, чтобы это эффективно работало было несколько раундов работы с промптом агента. Одна из лучших идей оказалась - инструктировать агента сначала запускать команду
tree чтобы понять структуру директорий, а потом уже делать таргетированные запросы. Это хорошо фокусирует поиск и помогает агенту лучше ориентироваться в контексте.Почему file-first - это кайф
Мне нравится работать в file-first экосистеме. Linux - это filesystem-first операционка и в этом мире много сильных инженеров и очень развитый опенсорс. Поражаешься как много эффективных и производительных тулов доступны, они просто работают. Плюс это же все текстовые интерфейсы - CLI + stdin/stdout - кодинговые агенты (считай LLM) с ними на ты. Никаких API оберток, никаких дополнительных слоев абстракции. Просто композиция мощных Unix-тулов.
В будущих постах по этой теме планирую покрыть:
- Другие челленджи: чтение и понимание содержимого нетекстовых файлов
- Когда все-таки нужны индексы или "шпаргалки" (или навигаторы) для таких агентов
- Опыт с Remote MCP и вопросы авторизации
- Подходы к разграничению прав доступа
- Вопросы изоляции (безопасность)
🔥 ➕ 🔁
Forwarded from whargarbl
Никак не мог понять почему SDXS так плохо генерит короткие промпты
Те если описание длинное то все более менее хорошо, но если дать короткое - например dog или собака - все разваливалось
Сперва думал дело в датасете - нужно чтобы были равномерно представлены разные типы описаний, как короткие так и длинные
Добавил больше коротких - стало хуже. Дело в том, что например было длинное описание черно-белая иллюстрация небоскреба, вид снизу бла-бла-бла
При сокращении ЛЛМ-кой описание она превращается во что то типа "вид снизу на небоскреб устремленный в небеса - и прочие галлюцинации символизирующие что то там"
В итоге у меня самурай стал черно белым, тк ллм считает часть про черно белую иллюстрацию менее существенной, чем описание того, что собственно на картинке
Как оказалось дело было в паддингах. При добивании до одинакового батч сайз - например 150 (выравнивание нужно для обучения) пустой текст заменяется на служебные пад токены. Выравниваться может как слева так и справа, типа
пад пад .. собака
или
собака пад пад..
Казалось бы ну и хрен с ним. Но у падов есть значения типа 0.1 0.2 Токен_собаки
Те пад добавляет мусорные числа в вектор - которые не только замедляют обучение - "запутывая" диффузию но и мешают выучить токен
Поэтому длинные описания учили лучше и работали лучше (ну я так думаю)
Для решения этой проблемы можно взять маску внимания 1, 0, 0 - где 0 - соотвествует позиции пад токена
И умножив на нее - получить чистый скрытый слой в котором не будет мусора пад токенов
Хорошо что я это понял. Плохо что опять переучивать придется
такой день
Те если описание длинное то все более менее хорошо, но если дать короткое - например dog или собака - все разваливалось
Сперва думал дело в датасете - нужно чтобы были равномерно представлены разные типы описаний, как короткие так и длинные
Добавил больше коротких - стало хуже. Дело в том, что например было длинное описание черно-белая иллюстрация небоскреба, вид снизу бла-бла-бла
При сокращении ЛЛМ-кой описание она превращается во что то типа "вид снизу на небоскреб устремленный в небеса - и прочие галлюцинации символизирующие что то там"
В итоге у меня самурай стал черно белым, тк ллм считает часть про черно белую иллюстрацию менее существенной, чем описание того, что собственно на картинке
Как оказалось дело было в паддингах. При добивании до одинакового батч сайз - например 150 (выравнивание нужно для обучения) пустой текст заменяется на служебные пад токены. Выравниваться может как слева так и справа, типа
пад пад .. собака
или
собака пад пад..
Казалось бы ну и хрен с ним. Но у падов есть значения типа 0.1 0.2 Токен_собаки
Те пад добавляет мусорные числа в вектор - которые не только замедляют обучение - "запутывая" диффузию но и мешают выучить токен
Поэтому длинные описания учили лучше и работали лучше (ну я так думаю)
Для решения этой проблемы можно взять маску внимания 1, 0, 0 - где 0 - соотвествует позиции пад токена
И умножив на нее - получить чистый скрытый слой в котором не будет мусора пад токенов
Хорошо что я это понял. Плохо что опять переучивать придется
такой день
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
Современная история 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
Goodreads
Driven: The Race to Create the Autonomous Car
Wired editor Alex Davies tells the dramatic, colorful s…
Forwarded from Daniilak — Канал
This media is not supported in your browser
VIEW IN TELEGRAM
JS-библиотека для визуализации данных в реальном времени. Делает интерактивные дашборды, легко тянет большие наборы данных, лайв-обновления и сложную аналитику
#сервисы@daniilak
#сервисы@daniilak
Forwarded from New Yorko Times (Yury Kashnitsky)
#google #genai
Ну что, Gemini 3 Pro Image – первая text2image модель, которая реально полезна, скажем, в блоггинге или преподавании для создания иллюстраций. К примеру, те же деревья решений
На всякий случай прогнал через Gemini, чтоб улучшить промпт (в Vertex есть фича "Help me write" для этого) – и вот на выходе.
Мое почтение.
На русском языке еще видны артефакты, но это пофиксят
Ну что, 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
Современные мультимодальные модели умеют работать с визуальными данными и текстом. Следующий шаг их развития — взаимодействие с физическим миром. Для управления роботами создаются Vision-Language-Action (VLA) модели, которые переводят визуальные данные и текстовые инструкции прямо в моторные команды робота. О том, как устроены такие модели, рассказываем в новой статье. 🤖
Из неё вы узнаете:
• как устроены VLA-модели — от визуального энкодера до генератора действий
• какие архитектуры используются для предсказания движений — от дискретных токенов до диффузий и Flow Matching'а
• какие существуют подходы к дообучению систем — от полного fine-tuning'а до PEFT-методов, таких как LoRA
• с какими проблемами сталкиваются VLA в реальном мире: задержки, накопление ошибок и безопасность
Читайте новую статью по ссылке! 🚀
Please open Telegram to view this post
VIEW IN TELEGRAM
DeepSchool
Vision-Language-Action (VLA) Models: от токенов к действиям - DeepSchool
Рассказываем, как устроены VLA-модели — от визуального энкодера до генератора действий.
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
#Протоколы_в_агентах
Второй по важности протокол в агентах - 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 в тишине. Но что же нужно для того, чтобы эти взаимодействия работали:
A2A и MCP
По сути, MCP — это то, как агенты вызывают инструменты, A2A — то, как агенты вызывают друг друга . Один подход похож на вызов функции или использование приложения; другой — на разговор с коллегой. Оба подхода часто работают рука об руку : агент может использовать MCP для получения данных, а затем использовать A2A, чтобы попросить другого агента проанализировать эти данные, и всё это в рамках одного сложного рабочего процесса.
Причем тут ACP
После поста про MCP я писал, что хочу расписать все про ACP, но так вышло, что фактически A2A его поглотил. Причина очень проста: ACP и A2A решают почти одну и ту же задачу — протокол “агент ↔ агент”, поэтому сейчас про этот протокол особо не вспоминают.
Фух, надеюсь стало понятнее. Пробовали ли вы протокол A2A, и если да, то в каких проектах?) Буду рад ваших историях
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
Интерактивная карта всей экосистемы Kafka.
В этой карте собрано все, что вам может понадобиться при работе с Kafka.
Это:
- Книги
- Блоги
- Учебные материалы
- Инструменты
и многое другое.
Карту составил Gunnar Morling - разаработчик в Confluent, один из разработчиков Debezium и автор kcctl (open-source CLI тулза для работы с Kafka)
@five_minutes_of_data