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

𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 уже не “последняя мысль” и не бонус к проекту — это ключевые архитектурные паттерны, которые определяют, можно ли безопасно деплоить вашу агентную систему.

Ниже четыре рабочих паттерна, которые мы видели в продакшн-системах:

1️⃣Адаптивные петли обратной связи
Агенты выполняют задачи → Супервизор оценивает → Сервис наград обновляет политики → Руководства корректируются → Агенты улучшаются со временем.
Создаётся непрерывный цикл обучения, где система усиливает эффективное поведение и снижает рискованное. Это обучение через награды, которое улучшается с каждой итерацией.

2️⃣Корректирующее действие
Централизованный Супервизор распределяет задачи, сверяет результаты с гайдлайнами приложения, и при обнаружении ошибок подключает альтернативных агентов. Лучший проверенный результат возвращается пользователю. Это предотвращает попадание плохого результата к конечным пользователям.

3️⃣Человек в петле
Для чувствительных доменов (медицина, юриспруденция, финансы) агенты генерируют предварительные ответы, но человек валидирует их перед выполнением. Поток автоматически ставится на паузу для экспертной проверки и возобновляется только после одобрения.

4️⃣Аварийная остановка
Критично для высокорисковых систем, например трейдинга.
Агент 1 собирает рыночные данные → LLM обрабатывает сигналы → Агент 2 оценивает условия → если обнаружены аномалии или риски, выполнение останавливается мгновенно.
Пример: торговый бот с доступом к API волатильности, показывающий VIX = 42 (крайний рыночный стресс). Даже если бот предлагает агрессивную сделку, оценщик проверяет независимо: «С учётом текущей волатильности это адекватно?» Если нет — действие полностью блокируется.

Философия, лежащая в основе, — формирование поведения: трёхшаговая петля оценка → обратная связь → коррекция. Оценщик не просто фиксирует результат постфактум. Он активно вмешивается: откатывает плохие транзакции, останавливает потоки с некорректными данными, или перенаправляет сложные кейсы на проверку человека.

Особенно важно, когда агенты взаимодействуют с нестабильными внешними состояниями — рыночными условиями, здоровьем API, нагрузкой системы. Оценщик даёт sanity-check, чтобы убедиться, что модель правильно интерпретировала сигналы, а не просто сгенерировала связный текст.

Цель не поймать все ошибки заранее (это невозможно). Цель — строить системы, которые выявляют проблемы на лету, понимают, что пошло не так, и автоматически корректируют курс, пока ущерб не распространился.

👉 @DataSciencegx

Кто-то наконец решил главную проблему тестирования LLM.

Это называется DeepEval — инструмент, который оценивает релевантность ответов, выявляет галлюцинации и считает метрики G-Eval, которые реально работают.

Запускается полностью локально

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

100% Open Source

👉 @DataSciencegx

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

Это не так. Agentic RAG, сделанный по-настоящему:

https://github.com/GiovanniPasq/agentic-rag-for-dummies

→ иерархический поиск (сначала дочерние элементы, родитель — по запросу)
→ память диалога
→ уточнение запросов
→ параллельные агенты

👉 @DataSciencegx

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

На GitHub есть открытый сборник , где системно собраны разные источники и API с реальными потоковыми данными.

Ресурсы разделены на бесплатные и платные, охватывают более десятка сфер: финансы и крипту, транспорт, погоду и землетрясения, IoT‑сенсоры, кибербезопасность и т.д.

Бесплатные источники: Coinbase (рыночные данные), реальное положение поездов Нью‑Йорка, поток редактирования Википедии, NOAA (погодные данные) и многое другое. Доступ через WebSocket или HTTP.

Платные: Bloomberg (финансовые потоки), FlightAware (отслеживание рейсов по всему миру), Reuters (новостные ленты) и другие профессиональные сервисы.

👉 @DataSciencegx

Анимация кластеризации KMeans в стиле 3blue1brown

👉 @DataSciencegx

Hierarchical Navigable Small World (HNSW) — это алгоритм, который делает поиск по векторам быстрым даже на огромных объёмах данных, позволяя искать миллиарды векторов за миллисекунды. Идея его работы довольно элегантная — одно из самых интересных открытий последних лет.

Вот как это устроено:
HNSW строит многоуровневый граф, где каждый верхний слой содержит экспоненциально меньше узлов, чем слой ниже.

▪️Все векторы находятся в нижнем слое (layer 0), который хорошо связан.
▪️В слое 1 появляются только некоторые векторы, ещё меньше — в слое 2 и т.д.
▪️Верхние слои работают как «скоростные трассы», позволяя пропускать большое количество нерелевантных данных.

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

Это объясняет, почему HNSW так экономно расходует память. Он умеет «перепрыгивать» через большие объёмы данных, не оценивая каждый элемент.

Ключевые параметры, влияющие на баланс скорости и качества:

▪️ef — размер кандидатного списка во время поиска
▪️maxConnections — сколько связей может быть у каждого узла
▪️distance — метрика для сравнения векторов (cosine, dot product и др.)

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

Подробно можно почитать здесь ✅

👉 @DataSciencegx

Kimi K2.5 теперь доступна на GPU-ускоренных эндпойнтах для бесплатного прототипирования, так что можно быстро начать работу с мультимодальной моделью frontier-класса, а не просто читать о ней.

Хотите попробовать? Всё готово: пошаговое руководство, готовый к запуску GitHub-ноутбук и первая инференция за минуты, а не часы.

📖 Подробности в техническом блоге → https://nvda.ws/4ad6EMw

👉 @DataSciencegx

Сервер для LLM для обратной разработки приложений: GhidraMCP

👉 @DataSciencegx

Кто-то собрал коллекцию всех production-ready LLM-приложений, которые можно делать в 2026 году.

Называется awesome-llm-apps. Это буквально copy-paste код для RAG, агентов, мультимодальных приложений и AI SaaS-продуктов.

→ Нужен RAG? Копируешь код.
→ Нужны AI-агенты? Копируешь код.
→ Нужны мультимодальные приложения? Копируешь код.

Никаких hello world. Никаких учебных демо для новичков. Только реальные приложения, которые можно деплоить уже сегодня.

100% бесплатно. 100% Open Source.

👉 @DataSciencegx

Graph-based RAG с двухуровневым поиском.

LightRAG — open-source RAG-фреймворк, который строит графы знаний из документов и использует dual-level retrieval, чтобы отвечать и на точечные, и на концептуальные запросы.

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

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

Он использует LLM, чтобы находить в документах сущности (люди, места, события) и их отношения, а затем собирает полноценный knowledge graph, сохраняющий эти связи.

Фреймворк работает с двухуровневым поиском:

Низкоуровневый поиск нацелен на конкретные сущности и детали, например: Что такое Mechazilla?

Высокоуровневый поиск агрегирует информацию сразу по нескольким сущностям для более общих вопросов
например: Как видение Илона Маска способствует устойчивому развитию?

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

Чем он отличается:

• Индексация на основе графа сохраняет связи между концепциями, а не превращает знания в изолированные куски
• Двухуровневый поиск подходит и для точечных, и для концептуальных запросов
• Автоматическое извлечение сущностей без ручной разметки
• Инкрементальные обновления — новые данные добавляются без полной перестройки графа
• Мультимодальная поддержка через RAG-Anything для PDF, офисных документов, изображений, таблиц и формул

Ключевые возможности:

✅Визуализация графа знаний через WebUI
✅Несколько бэкендов хранения (PostgreSQL, Neo4j, MongoDB, Qdrant)
✅Поддержка основных LLM-провайдеров (OpenAI, Anthropic, Ollama, Azure)
✅Поддержка reranker’ов для смешанных запросов
✅Удаление документов с автоматической регенерацией графа знаний

100% open source.

👉 @DataSciencegx