Опенсорсное расширение для движков 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

Модель, которая шарит в безопасности : VulnLLM-R-7B

VulnLLM-R-7B это первая специализированная ИИ-модель, которая находит уязвимости, рассуждая как секьюрити-эксперт. Она обучена вылавливать уязвимости до того, как их начнут эксплуатировать

На ключевых бенчмарках обгоняет коммерческие модели (типа Claude-3.7-Sonnet, o3-mini) и стандартные инструменты индустрии (CodeQL, AFL++). Даёт SOTA при всего 7B параметров, то есть примерно в 30 раз меньше и заметно быстрее, чем универсальные reasoning-модели.

Обучена и протестирована на C, C++, Python и Java (zero-shot обобщение).

100% open source.

👉 @DataSciencegx

Если ты когда-нибудь задумывался, как работают большие языковые модели типа ChatGPT, этот курс для тебя.

Там разбирают подготовку данных, обучение модели и fine-tuning, которые нужны до того, как LLM вообще станет пригодной к использованию.

Пройдешь весь пайплайн обучения: от токенизации сырого текста до дообучения рабочего чатбота.

Начать смотреть

👉 @DataSciencegx

Векторный поиск не всегда ответ.

Алгоритм из 90-х, без обучения, без эмбеддингов и без fine-tuning, до сих пор лежит в основе Elasticsearch, OpenSearch и большинства продовых поисковых систем.

Называется он BM25, и стоит понять, почему он никак не вымирает.

Допустим, ты ищешь "transformer attention mechanism" в библиотеке ML-статей.

BM25 считает релевантность документов на трёх базовых идеях:

1. Редкие слова важнее частых

В каждой статье есть "the" и "is", так что такие слова почти ничего не значат.

А вот "transformer" специфичное и информативное, поэтому BM25 даёт ему заметно больший вес. В формуле это отражается через IDF(qᵢ).

2. Повторы помогают, но с убывающей отдачей

Если "attention" встречается в статье 10 раз, это сильный сигнал релевантности. Но рост с 10 до 100 упоминаний почти не меняет итоговый скор.

BM25 использует насыщение (saturation), управляемое f(qᵢ, D) и параметром k₁, чтобы keyword stuffing не мог “накрутить” ранжирование.

3. Длина документа нормализуется

Статья на 50 страницах по природе будет иметь больше вхождений ключевых слов, чем статья на 5 страниц.

BM25 учитывает это через |D|/avgdl, под контролем параметра b, чтобы длинные документы не доминировали в выдаче просто потому, что текста больше.

Три идеи. Ноль нейросетей. Ноль датасетов. Просто аккуратная математика, которая пережила десятилетия.

Вот что многие упускают: BM25 отлично тащит точное совпадение по ключевым словам, а с этим у эмбеддингов реально бывают проблемы.

Когда пользователь ищет "error code 5012", векторный поиск может вернуть семантически похожие коды ошибок. BM25 почти всегда поднимет точное совпадение наверх.

Именно поэтому hybrid search стал дефолтом в топовых RAG-системах.

Комбинация BM25 + векторный поиск даёт и семантику, и точный keyword match в одном пайплайне.

Так что прежде чем кидать GPU в любую задачу поиска, подумай: возможно, BM25 уже решает её. А если нет, то почти наверняка сделает твой семантический поиск заметно лучше в связке.

Этот hybrid search-стек, о котором я говорил выше, на самом деле уже реализован в open-source слое контекстного ретривала для агентов.

GitHub repo: https://github.com/airweave-ai/airweave

👉 @DataSciencegx