Data Portal | DS & ML

Если ты когда-нибудь задумывался, как работают большие языковые модели типа ChatGPT, этот курс для тебя. Там разбирают подготовку данных, обучение модели и fine-tuning, которые нужны до того, как LLM вообще станет пригодной к использованию. Пройдешь весь пайплайн обучения: от токенизации сырого текста до дообучения рабочего чатбота. Начать смотреть 👉 @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

Нужно найти НОД двух чисел? Просто сложи их друг на друга, пока дальше уже не получится Это работает, потому что НОД(a, b) равен НОД(a, b − a). А “складывание” одной числовой линии на другую это по сути и есть вычисление разницы. Вторая анимация, начинается с 34 и 55. Это два соседних числа Фибоначчи, и процесс спускается по всей последовательности Фибоначчи до 1. Красивое доказательство, что соседние числа Фибоначчи взаимно просты. 👉 @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

Кто-то собрал коллекцию всех production-ready LLM-приложений, которые можно делать в 2026 году. Называется awesome-llm-apps. Это буквально copy-paste код для RAG, агентов, мультимодальных приложений и AI SaaS-продуктов. → Нужен RAG? Копируешь код. → Нужны AI-агенты? Копируешь код. → Нужны мультимодальные приложения? Копируешь код. Никаких hello world. Никаких учебных демо для новичков. Только реальные приложения, которые можно деплоить уже сегодня. 100% бесплатно. 100% Open Source. 👉 @DataSciencegx

Совет на 2026 год — освойте ВАЙБ-КОДИНГ. ИИ уже пишет код, чинит баги, генерит тесты и документацию быстрее и качественнее любой команды айтишников И те, кто научится вайбкодить сейчас, будут зарабатывать в разы больше тех, кто всё ещё делает всё вручную Разобраться в этом с нуля поможет канал Вайб-кодинг. Там простым языком разбирают, какие инструменты действительно стоит использовать, как собирать проекты от идеи до релиза и что сейчас актуально в вайбкодинге Подписывайтесь, нас уже 15 тысяч: @vibecoding_tg

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

Kimi K2.5 теперь доступна на GPU-ускоренных эндпойнтах для бесплатного прототипирования, так что можно быстро начать работу с мультимодальной моделью frontier-класса, а не просто читать о ней. Хотите попробовать? Всё готово: пошаговое руководство, готовый к запуску GitHub-ноутбук и первая инференция за минуты, а не часы. 📖 Подробности в техническом блоге → https://nvda.ws/4ad6EMw 👉 @DataSciencegx

Hierarchical Navigable Small World (HNSW) — это алгоритм, который делает поиск по векторам быстрым даже на огромных объёмах данных, позволяя искать миллиарды векторов за миллисекунды. Идея его работы довольно элегантная — одно из самых интересных открытий последних лет. Вот как это устроено: HNSW строит многоуровневый граф, где каждый верхний слой содержит экспоненциально меньше узлов, чем слой ниже. ▪️Все векторы находятся в нижнем слое (layer 0), который хорошо связан. ▪️В слое 1 появляются только некоторые векторы, ещё меньше — в слое 2 и т.д. ▪️Верхние слои работают как «скоростные трассы», позволяя пропускать большое количество нерелевантных данных. При поиске алгоритм стартует с верхнего слоя, находит ближайший узел, спускается на слой ниже и повторяет процесс. К моменту достижения нижнего слоя вы уже сузили поиск до наиболее релевантного окружения — нет необходимости перебирать всё. Это объясняет, почему HNSW так экономно расходует память. Он умеет «перепрыгивать» через большие объёмы данных, не оценивая каждый элемент. Ключевые параметры, влияющие на баланс скорости и качества: ▪️ef — размер кандидатного списка во время поиска ▪️maxConnections — сколько связей может быть у каждого узла ▪️distance — метрика для сравнения векторов (cosine, dot product и др.) Вставка новых элементов работает похожим образом: сначала ищем оптимальное место через поиск, затем создаём связи. Перестройка графа ресурсоёмкая, но сами запросы выполняются очень быстро. Подробно можно почитать здесь ✅ 👉 @DataSciencegx

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

Чувак полностью реализовал архитектуру GPT-OSS-20B с нуля на PyTorch. Все компоненты написаны с нуля: ▪️RoPE с YaRN + NTK-by-parts для масштабирования контекста ▪️RMSNorm ▪️SwiGLU с клэмпингом и residual connections ▪️Mixture-of-Experts (MoE) ▪️Self-Attention, оптимизированный через Grouped Query Attention (GQA) ▪️Learned sinks ▪️Banded (скользящее окно) attention ▪️Поддержка KV-кэширования Всё это работает на одной A100 SXM (80GB). Он также написал подробную документацию с теорией каждого компонента, а также инструкциями по настройке и инференсу. Репозиторий: https://github.com/HamzaElshafie/gpt-oss-20B 👉 @DataSciencegx

Если обычно вы работаете с историческими статическими данными для анализа или проектов, а нужны потоки реальных данных для тестирования или обучения моделей, то ресурсов не так уж много и они разбросаны. На GitHub есть открытый сборник , где системно собраны разные источники и API с реальными потоковыми данными. Ресурсы разделены на бесплатные и платные, охватывают более десятка сфер: финансы и крипту, транспорт, погоду и землетрясения, IoT‑сенсоры, кибербезопасность и т.д. Бесплатные источники: Coinbase (рыночные данные), реальное положение поездов Нью‑Йорка, поток редактирования Википедии, NOAA (погодные данные) и многое другое. Доступ через WebSocket или HTTP. Платные: Bloomberg (финансовые потоки), FlightAware (отслеживание рейсов по всему миру), Reuters (новостные ленты) и другие профессиональные сервисы. 👉 @DataSciencegx

Каждый второй туториал по RAG либо игрушка, либо исследовательская работа, замаскированная под продукт. Это не так. Agentic RAG, сделанный по-настоящему: https://github.com/GiovanniPasq/agentic-rag-for-dummies → иерархический поиск (сначала дочерние элементы, родитель — по запросу) → память диалога → уточнение запросов → параллельные агенты 👉 @DataSciencegx

Кто-то наконец решил главную проблему тестирования LLM. Это называется DeepEval — инструмент, который оценивает релевантность ответов, выявляет галлюцинации и считает метрики G-Eval, которые реально работают. Запускается полностью локально Позволяет тестировать агентов, RAG-системы и продакшн-ответы с точностью уровня человека. 100% Open Source 👉 @DataSciencegx

𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀 уже не “последняя мысль” и не бонус к проекту — это ключевые архитектурные паттерны, которые определяют, можно ли безопасно деплоить вашу агентную систему. Ниже четыре рабочих паттерна, которые мы видели в продакшн-системах: 1️⃣Адаптивные петли обратной связи Агенты выполняют задачи → Супервизор оценивает → Сервис наград обновляет политики → Руководства корректируются → Агенты улучшаются со временем. Создаётся непрерывный цикл обучения, где система усиливает эффективное поведение и снижает рискованное. Это обучение через награды, которое улучшается с каждой итерацией. 2️⃣Корректирующее действие Централизованный Супервизор распределяет задачи, сверяет результаты с гайдлайнами приложения, и при обнаружении ошибок подключает альтернативных агентов. Лучший проверенный результат возвращается пользователю. Это предотвращает попадание плохого результата к конечным пользователям. 3️⃣Человек в петле Для чувствительных доменов (медицина, юриспруденция, финансы) агенты генерируют предварительные ответы, но человек валидирует их перед выполнением. Поток автоматически ставится на паузу для экспертной проверки и возобновляется только после одобрения. 4️⃣Аварийная остановка Критично для высокорисковых систем, например трейдинга. Агент 1 собирает рыночные данные → LLM обрабатывает сигналы → Агент 2 оценивает условия → если обнаружены аномалии или риски, выполнение останавливается мгновенно. Пример: торговый бот с доступом к API волатильности, показывающий VIX = 42 (крайний рыночный стресс). Даже если бот предлагает агрессивную сделку, оценщик проверяет независимо: «С учётом текущей волатильности это адекватно?» Если нет — действие полностью блокируется. Философия, лежащая в основе, — формирование поведения: трёхшаговая петля оценка → обратная связь → коррекция. Оценщик не просто фиксирует результат постфактум. Он активно вмешивается: откатывает плохие транзакции, останавливает потоки с некорректными данными, или перенаправляет сложные кейсы на проверку человека. Особенно важно, когда агенты взаимодействуют с нестабильными внешними состояниями — рыночными условиями, здоровьем API, нагрузкой системы. Оценщик даёт sanity-check, чтобы убедиться, что модель правильно интерпретировала сигналы, а не просто сгенерировала связный текст. Цель не поймать все ошибки заранее (это невозможно). Цель — строить системы, которые выявляют проблемы на лету, понимают, что пошло не так, и автоматически корректируют курс, пока ущерб не распространился. 👉 @DataSciencegx

Можно собрать LLM с нуля. Есть репозиторий, который раскладывает сложную математику Transformer-ов в понятный, чистый Python. Покрывает весь жизненный цикл LLM. → пошаговая реализация → простые, “хакабельные” примеры 100% open source. 👉 @DataSciencegx

Как мы перестали «угадывать продажи» в FMCG и начали их прогнозировать Последние годы мы часто работаем с планированием и автоматизацией S&OP в FMCG. Видели десятки прогнозов в Excel, «на глаз», по прошлому году, с ручными коэффициентами на промо и вечными спорами между продажами и планированием. И чтобы это исправить мы с командой создали и уже внедрили ML-модель, которая учитывает промо-эффекты и цены, работает с данными отгрузок, учитывает продажи с полки, автоматически очищает историю и многое другое. А результаты ее работы можно увидеть уже через 3 месяца после пилота. Прочитать, как работает ML-модель.

Слияние 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

RAG против CAG, понятное объяснение 👉 @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