8 самых показательных VLA (Vision-Language-Action) моделей:

▪️Gemini Robotics
▪️π0
▪️SmolVLA
▪️Helix
▪️ChatVLA-2 (архитектура MoE)
▪️ACoT-VLA (Action Chain-of-Thought, цепочка рассуждений для действий)
▪️VLA-0
▪️Rho-alpha (ρα) новый VLA+ модель от Microsoft

👉 @DataSciencegx

Vector Index vs Vector Database, простым языком

Разрабы часто используют эти термины как синонимы.

Но если не понимать разницу, потом это вылезает в проблемы на проде.

Как думать об этом:

Vector index это по сути алгоритм поиска.

Ты кормишь его векторами, он организует их в структуру, по которой можно быстро искать похожие (например, HNSW), и находит nearest neighbors. FAISS это тоже пример.

Но нюанс в том, что это и все.

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

Vector DB это обертка вокруг индекса, плюс все, что реально нужно в проде.

Туда входят распределенное хранилище, persistence, фильтрация по метаданным, конкурентный доступ и прочее. Хороший опенсорсный пример: Milvus.

Из этого видно: одно это компонент, другое это система.

Почему это важно:

Однажды компания с автопилотами строила поиск по дорожным видео, и масштабы были огромные.

Каждая поездка генерила кадры, каждый кадр превращался в embedding.

Инженерам нужно было спрашивать что-то вроде “ночные перекрестки с пешеходами” по данным за месяцы.

Сначала FAISS выглядел идеально: быстрый, легкий, легко поднять.

Но по мере роста данных embeddings каждого дня стали отдельным index-файлом.

Через пару месяцев у них было сотни тысяч разрозненных файлов.

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

Сложные запросы потребовали самописных DB, query planner’ов и фильтрации, построенных вокруг FAISS.

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

Вот где и нужны vector DB. Компания мигрировала на Milvus, и разница стала очевидной:

↳ один запрос: similarity + фильтры по метаданным
↳ данные в коллекциях и партициях, а не раскиданы по файлам
↳ десятки миллиардов векторов, год в проде, без крупных инцидентов
↳ минус 30% к инфраструктурным затратам
↳ 10x запас по масштабированию

И это не уникальная история.

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

Vector DB существует ровно для этого момента.

Milvus выделяется тем, что хорошо держит масштаб и разные типы данных.

Можно хранить миллиарды векторов, горизонтально масштабироваться и делать специализированные индексы, например для геоданных свой оптимизированный индекс, а не “один общий на все”.

Он полностью open-source (41k+ звезд), можно self-host, можно взять их cloud.

👉 @DataSciencegx

Пожизненная память для агентов LLM: SimpleMem

👉 @DataSciencegx

Векторные базы, возможно, не то решение, которое нужно для памяти ИИ

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

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

Память хранится в простых Markdown-файлах, а не в непрозрачных индексах.

→ Двухрежимное извлечение (LLM + поиск)
→ Нативная мультимодальность (изображения, аудио)
→ Полностью настраиваемые промпты

100% open source.

👉 @DataSciencegx

Я разогнал производительность своего AI-агента на 184%

...используя полностью опенсорсную технику.

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

То есть ручной prompt engineering вообще не нужен

Идея простая:

1. Берешь стартовый промпт и eval-датасет
2. Дальше оптимизатор итеративно улучшает промпт
3. В итоге получаешь оптимальный промпт автоматически

И все это буквально в несколько строк кода.

Почему именно Opik?

Opik это на 100% опенсорсная платформа для оценки (evaluation) LLM.

Она помогает оптимизировать LLM-системы так, чтобы они работали лучше, быстрее и дешевле: от RAG-чатботов до ассистентов для кода. В Opik есть трейсинг, оценки (evaluations) и дашборды.

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

GitHub-репозиторий

👉 @DataSciencegx

OpenAI представили Prism — умный LaTeX-редактор для научных работ

OpenAI выкатили Prism – полноценный LaTeX-редактор с ИИ внутри. По сути, это новый стандарт для работы с научными текстами, формулами и графиками.

Что умеет Prism:

- Верстает статьи и пейперы в LaTeX с помощью GPT-5.2
- Превращает рисунки и черновики в графики, диаграммы и формулы
- Находит ошибки, неточности и проблемы в логике текста
- Помогает с источниками и цитированием
- Поддерживает голосовой ввод
- Совместная работа над одним проектом в реальном времени

Инструмент изначально ориентирован на учёных и исследователей, но по факту это – лучший ИИ-инструмент для рефератов, курсовых и дипломов, особенно для технических и естественно-научных специальностей

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

Попробовать можно уже сейчас:
https://prism.openai.com/

👉 @DataSciencegx

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

На GitHub есть Plexe, опенсорсный проект, который сильно снижает порог: ты описываешь задачу обычным языком, а он автоматически собирает машинное обучение под это.

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

Поддерживает разных провайдеров LLM: OpenAI, Anthropic, Ollama и другие. Плюс умеет автоматически выводить структуру данных или даже генерировать синтетический датасет.

Еще внутри есть распределенное обучение на Ray: можно параллельно прогонять несколько вариантов моделей и сильно ускоряться.

👉 @DataSciencegx

Marching Squares это классический алгоритм для построения контурных линий (изолиний) по 2D скалярному полю.

Его используют для визуализаций вроде топографических карт.

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

У него есть 3D-аналог Marching Cubes, который делает то же самое, но для 3D.

Если тебе нравятся такие визуализации, может зайдет свежая статья про ML-концепт Rectified Flows.

Там много поясняющих интерактивных визуализаций.

Код для всего этого тоже можно посмотреть здесь.

👉 @DataSciencegx

От OCR к agentic-доставанию данных из документов

LandingAI выпустили бесплатный курс по Document AI. Там учат собирать пайплайны обработки документов, которые вытаскивают текст, таблицы, графики и формы, не теряя контекст разметки.

Проблема классического OCR в том, что оно “достаёт буквы”, но ломает смысл:

- у таблиц пропадает структура (включая merged cells)
- связи “график ⬅️➡️ подпись” разваливаются
- порядок чтения в multi-column становится кашей

В курсе показывают, как строить agentic-воркфлоу, которые читают документы ближе к тому, как это делает человек, через Agentic Document Extraction (ADE).

Что внутри:

- почему обычный OCR валится на сложных документах
- как детект layout + правильный reading order сохраняют структуру
- как парсить PDF в Markdown/JSON и не потерять layout
- как собирать RAG с ADE и векторными БД
- как деплоить event-driven документные пайплайны на AWS

3 часа, 6 практических примеров кода. Полностью бесплатно.

👉 @DataSciencegx

Microsoft только что закрыл проблему "agent loop"

Они выложили в open-source Agent Lightning, фреймворк, который позволяет агентам учиться на собственных ошибках.

Он использует reinforcement learning, чтобы автоматически оптимизировать промпты и веса.

→ Твой агент пробует выполнить задачу → Фейлится → Agent Lightning анализирует трейс → Обновляет промпт на следующий раз

На 100% open source.

👉 @DataSciencegx

Unsloth AI смогли обучить LLM вообще без участия человека, используя Claude Code.

Они сделали гайд, как повторить это с локальными LLM через Claude Code и OpenAI Codex.

Подключай GLM-4.7-Flash к своему серверу и запускай agentic coding локально: гайд

👉 @DataSciencegx

DevOps vs. MLOps vs. LLMOps:

Многие команды пытаются натянуть DevOps-практики на LLM-приложения.

Но DevOps, MLOps и LLMOps решают принципиально разные задачи.

Почему это важно: 88% ML-инициатив с трудом доходили до прода, если пытаться запускать их через традиционные DevOps-подходы.

А LLM добавляют проблемы, под которые даже MLOps изначально не проектировали.

Разберём по полочкам:

→ DevOps ориентирован на софт.

Ты пишешь код, тестируешь и деплоишь. Фидбек-луп простой: код работает или нет?

Главный артефакт это код. Тестирование детерминированное. Инструментарий зрелый после 15+ лет развития.

→ MLOps ориентирован на (модель + данные).

Тут у тебя data drift, деградация модели и постоянное переобучение.

Код может быть идеальным, но качество модели со временем падает, потому что мир меняется.

Модель для антифрода может отлично работать на старте, а через пару недель начать валиться, потому что мошенники адаптировались.

Главный артефакт расширяется до code + data + models. Версионировать нужно всё три. Поэтому MLflow, DVC и feature store стали обязательными штуками.

→ LLMOps ориентирован на foundation models.

Обычно ты не тренируешь модели с нуля. Вместо этого выбираешь базовую модель и оптимизируешь её по трём параллельным направлениям:

* Prompt Engineering
* Настройка контекста / RAG
* Fine-tuning

В отличие от DevOps и MLOps, эти направления идут параллельно, а не последовательно.

Но главное отличие LLMOps это мониторинг: он вообще другой.

В MLOps ты следишь за data drift, деградацией модели и метриками точности.

В LLMOps ты отслеживаешь:

* детект галлюцинаций
* bias и токсичность
* расход токенов и стоимость
* human feedback loops

Потому что выход LLM недетерминированный. Нельзя просто проверить, “правильно” ли оно ответило. Нужно убедиться, что ответ безопасный, grounded и не прожигает бюджет.

63% production AI-систем ловят опасные галлюцинации в первые 90 дней.

Ещё переворачивается модель затрат.

В MLOps основные расходы это обучение (GPU-часы на этапе разработки).

В LLMOps основные расходы это инференс (каждый запрос жрёт токены).

Поэтому в LLMOps так важны эффективность промптов, кэширование и routing между моделями.

Цикл оценки в LLMOps возвращается сразу во все три направления оптимизации. Проваленный eval может значить, что нужны лучше промпты, богаче контекст, ИЛИ fine-tuning.

То есть это уже не линейный пайплайн.

И ещё: версионирование промптов и RAG-пайплайны в LLMOps теперь first-class штуки, так же как версионирование данных стало обязательным в MLOps.

И ops-слой, который ты выбираешь, должен соответствовать системе, которую ты строишь.

👉 @DataSciencegx

В этом фри курсе ты изучишь основы RAG, а также ключевые концепции Model Context Protocol (MCP). Курс построен на Python SDK и разбирает стратегии чанкинга, работу с AI-агентами и многое другое.

👉 @DataSciencegx

Опенсорсное расширение для движков LLM-сервинга: LMCache

Это как слой кэширования для крупномасштабного продакшн-инференса LLM.

LMCache реализует умное управление KV-кэшем, переиспользуя key-value состояния уже встречавшегося текста между GPU, CPU и локальным диском.

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

Это дает:

▪️4–10x сокращение затрат в RAG при моделях, которыми владеет пользователь
▪️Меньше Time-To-First-Token (TTFT)
▪️Выше throughput под нагрузкой
▪️Более эффективную работу с long-context сценариями

Показательный пример применения: NVIDIA интегрировала LMCache в свой инференс-проект Dynamo.
LMCache позволяет Dynamo выгружать KV-кэш во внешние слои хранения и при этом эффективно переиспользовать его между запросами. Это снижает стоимость prefill и освобождает GPU-память под активные вычисления.

👉 @DataSciencegx

RAG против CAG, понятное объяснение

👉 @DataSciencegx

Слияние RAG и CAG . Как это можно использовать AI-инженеру?

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

Примерные шаги для архитектуры CAG + RAG:

Подготовка данных

1. Для CAG берем только источники, которые меняются редко. Помимо “редко меняется”, важно понять, какие из этих источников чаще всего нужны по релевантным запросам. Только после этого выбранные данные заранее “прогреваем” в KV cache модели, кэшируем в памяти. Это делается один раз, дальше остальные шаги можно гонять много раз без пересчета начального кэша.

2. Для RAG, если нужно, заранее считаем и сохраняем векторные эмбеддинги в совместимую базу, чтобы потом искать их на шаге 4. Иногда для RAG хватает и более простых типов данных, тогда подойдет обычная БД.

Query path

Теперь можно использовать подготовленные данные.

3. Собираем промпт: запрос пользователя + system prompt с инструкциями, как модели использовать кэшированный контекст и внешний (retrieved) контекст.

4. Строим эмбеддинг запроса пользователя для семантического поиска через vector DB и дергаем хранилище контекста, чтобы достать релевантные данные. Если семантика не нужна, можно ходить в другие источники, например в realtime БД или в веб.

5. Обогащаем финальный промпт внешним контекстом, который достали на шаге 4.

6. Возвращаем пользователю финальный ответ.

Пара важных моментов

▪️Контекстное окно не бесконечное. Даже если у модели огромный контекст, проблема “иголки в стоге сена” никуда не делась. Используй контекст экономно и кэшируй только то, что реально нужно.

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

▪️Хотя в open-source CAG хайпанул относительно недавно, на практике это уже давно можно делать через prompt caching в API OpenAI и Anthropic. Там легко быстро собрать прототип.

▪️Всегда разделяй hot и cold источники. В кэш кладем только cold (редко меняющиеся), иначе данные протухнут, и приложение начнет жить “мимо реальности”.

Риски и ограничения

▪️Очень аккуратно с тем, что кэшируешь, потому что эти данные становятся доступными для запросов всех пользователей.

▪️RBAC для кэша обеспечить тяжело, если у тебя не отдельная модель со своим кэшем на каждую роль.

Ты уже пробовал такой комбо-подход?

👉 @DataSciencegx

Можно собрать LLM с нуля.

Есть репозиторий, который раскладывает сложную математику Transformer-ов в понятный, чистый Python. Покрывает весь жизненный цикл LLM.

→ пошаговая реализация
→ простые, “хакабельные” примеры

100% open source.

👉 @DataSciencegx