Команда Qwen имеет свой официальный agent framework, и в нем есть вообще все.

Не нужно сшивать сторонние библиотеки. Не нужно бороться с абстракциями.

Qwen-Agent дает вам:

→ нативный function calling, встроенный прямо в сам фреймворк
→ безопасную песочницу с code interpreter из коробки
→ поддержку RAG и MCP
→ Chrome-расширение для agent workflow прямо в браузере

Это сделала команда, которая создала саму модель. Поэтому оно просто работает.

На 100% open source и полностью бесплатно.

👉 @DataSciencegx

Простые числа - это причина, по которой данные вашей банковской карты в безопасности.

Когда вы что-то покупаете в интернете, платёжная информация шифруется с помощью системы под названием RSA, и вся её безопасность держится на одном простом математическом факте:

Перемножить два больших простых числа легко. А вот обратить этот процесс назад и выяснить, какие именно два простых числа были перемножены, практически невозможно.

Например, для компьютера не составляет труда посчитать:

12,451 × 18,637 = 232,048,387

Но в обратную сторону всё намного сложнее. Если я дам вам число 232,048,387 и попрошу найти его простые множители, не подсказывая, с чего начинать, это уже становится реально трудной задачей.

А теперь увеличьте эти простые числа до чисел с сотнями цифр, именно такие и используются в RSA, и даже самым быстрым компьютерам на Земле потребовалось бы больше времени, чем возраст Вселенной, чтобы взломать это тупым перебором.

Что делает ситуацию философски странной, так это то, что шифрование RSA построено на задаче, про которую математики до сих пор не доказали, что она действительно сложная.

Мы считаем, что разложение больших чисел на множители фундаментально трудная задача. Но никто так и не доказал, что для неё не существует какого-то короткого пути. Теоретически, как бы маловероятно это ни было, кто-то может уже завтра открыть хитрый алгоритм, который мгновенно ломает всё шифрование, одновременно раскрывая все банковские счета, все личные сообщения и все государственные секреты.

Это одна из величайших нерешённых задач математики, известная как P vs NP. Она ставит вопрос: всегда ли задачи, для которых легко проверить правильность ответа, так же легко и решаются. Если ответ да, то есть если P = NP, современное шифрование полностью рушится.

👉 @DataSciencegx

Одно из самых наглядных доказательств того, что LLM на самом деле не понимают, о чём говорят.

Мы спросили GPT, допустимо ли пытать женщину, чтобы предотвратить ядерный апокалипсис.
Он ответил: да.

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

Хотя пытка очевидно хуже, чем домогательство.

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

И возникает он именно для тех видов вреда, которые находятся в центре споров о гендерном паритете.

Наиболее правдоподобное объяснение такое: во время reinforcement learning with human feedback модель усвоила, что определённые виды вреда считаются особенно тяжёлыми, и затем начала механически сверхобобщать это.

Но рассуждать о самом вреде как таковом она не научилась.

LLM не рассуждают о морали. То, что называют generalization, часто оказывается механическим сверхобобщением, лишённым семантического содержания.

Ссылка на статью

👉 @DataSciencegx

Напоминание:

💕LR это в первую очередь про штраф L1 (lasso) или L2 (ridge)
💕Naive Bayes это alpha
💕decision tree почти никто не использует как отдельный алгоритм, но понимать, как он работает, всё равно нужно
💕random forest это в первую очередь max_depth, число estimators, max_features (нельзя брать все признаки), min_samples_split и min_samples_leaf
💕GBT это обычно про xgboost / catboost / lightgbm, где смотришь на всё то же самое, что выше, плюс learning_rate, alpha / lambda, число leaves, subsample / colsample_bytree и boosting type, если он применим
💕PCA лучше лишний раз не трогать для time series, если только ты не делаешь rolling-вариант или не используешь это в исследовательских целях. А вот PLS вполне норм. Виды PCA и когда их использовать:
-> linear, если предполагаются линейные зависимости между признаками
-> kernel, если зависимости между признаками нелинейные
-> incremental, если у тебя очень много признаков и сэмплов и нужно быстро прогонять PCA
-> robust PCA, если в данных есть выбросы
💕Если уже говорим про PCA, можно упомянуть ICA, когда нужны статистически независимые признаки, а не просто некоррелированные
💕 kNN иногда используют; k-means полезен там, где очевидно, что главное это число кластеров
💕support vector machine это когда уже ничего не сработало и тебе просто интересно, вдруг вот это взлетит. Держится на C и kernel, которые отвечают за линейные или нелинейные зависимости
💕гиперпараметры NN это вообще отдельная история, потому что они зависят от типа сети. Но базово помни связку: NN layer -> normalization layer -> dropout layer. Иногда между normalization и dropout, или даже позже, ставят activation layer. Это уже зависит от того, нужна ли тебе гибкость в выборе места для активации, или ты просто убираешь её как отдельный слой и задаёшь activation прямо в параметрах слоя NN.

👉 @DataSciencegx

Андрей Карпаты упаковал проект autoresearch в новый самодостаточный минималистичный репозиторий, если кто-то хочет поиграться с ним на выходных. По сути, это training core из nanochat для LLM, ужатый до версии на одну GPU и один файл примерно на 630 строк кода, а дальше:

- человек итеративно дорабатывает промпт (.md)
- AI-агент итеративно дорабатывает training-код (.py)

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

На изображении каждая точка — это полный training run LLM, который длится ровно 5 минут. Агент работает в автономном цикле в git feature-ветке и накапливает git-коммиты в training-скрипт по мере того, как находит более удачные настройки, дающие меньший validation loss к концу обучения: архитектуру нейросети, оптимизатор, все гиперпараметры и так далее.

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

Часть код, часть sci-fi, и щепотка психоза :)

👉 @DataSciencegx

Files are all you need!

В этой исследовательской работе говорится, что лучший способ управлять AI-контекстом — это относиться ко всему как к файловой системе, и OpenClaw это уже доказал.

Но большинство agent framework'ов до сих пор этого не поняли.

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

Работа Everything is Context берет 50-летнюю идею из Unix и использует ее, чтобы это исправить.

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

Если открыть директорию OpenClaw,

там прямо лежат SOUL.md, MEMORY.md, AGENTS.md и HEARTBEAT.md — обычные Markdown-файлы.

В статье формализуется то, что делает OpenClaw, в виде трех этапов:

↳ Context Constructor выбирает релевантное и сжимает это так, чтобы оно поместилось в token window
↳ Context Updater обновляет контекст по мере развития диалога
↳ Context Evaluator записывает проверенные знания обратно на диск

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

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

Вот в этом и весь выигрыш.

Когда агент что-то забывает или ошибается, можно просто открыть файл и точно увидеть, что именно он знал. Ничего не исчезает бесследно между сессиями. Файлы решают эту проблему по самому устройству системы.

Если вы строите что-то на агентах, эту статью точно стоит прочитать.

👉 @DataSciencegx

Исследователи внедрили одного вредоносного агента в группу LLM-агентов. Вся сеть не смогла прийти к консенсусу.

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

И теперь это проблема и ваших agent-pipeline.

Даже в полностью «честной» среде, где вообще нет злонамеренных участников, LLM-агенты всё равно часто не могут сойтись на общих значениях. И ситуация становится хуже по мере увеличения числа агентов в группе.

Причём характер сбоя показательный.
Это не скрытая подмена ценностей. Не один агент тихо проталкивает неправильный ответ. Модели просто.. застревают. Тайм-ауты. Круговые обсуждения. Разговор никогда не приходит к общему решению.

Почему это важно: весь хайп вокруг multi-agent AI строится на предположении, что координация работает. Рои автономных агентов, коллективное решение задач, децентрализованные AI-системы. Всё это предполагает, что если посадить несколько LLM в «комнату» и дать им протокол общения, они смогут прийти к общему решению.

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

Пока что ответ — нет. И причина довольно фундаментальная.

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

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

В этом и есть фундаментальное несоответствие: алгоритмы консенсуса предполагают детерминированные state machines, а LLM — их противоположность.

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

Практическое следствие довольно неприятное для тех, кто строит multi-agent системы для задач с высокими рисками. Надёжное согласие не возникает само, если просто посадить умных агентов за один стол. Его нужно явно проектировать, с формальными гарантиями, а не надеяться, что оно появится само.

При этом multi-agent системы уже начинают внедрять в финансы, медицину и автономную инфраструктуру. А проблема консенсуса — самый базовый механизм координации — до сих пор не решена.

👉 @DataSciencegx

Сильные математические идеи почти всегда обгоняют сложные инженерные ухищрения.

Много лет в deep learning правили всё более замысловатые архитектурные фишки: CNN-блоки, attention-слои, channel mixers, residual-связи, стеки нормализации.

Каждые несколько лет появляется «новая революционная архитектура».

Один из самых известных примеров — Kaiming He и Residual Networks (ResNet). В своё время его словно выставляли на красную дорожку AI-сцены: residual connections будто «решили» глубокое обучение.

Но по сути это были инженерные патчи.

Теперь же появилось нечто более интересное.

Новая архитектура CliffordNet возвращается к математике — конкретно к Clifford Algebra, разработанной в XIX веке Уильямом Кингдоном Клиффордом.

Вместо случайной навески модулей модель строится вокруг геометрического произведения:

[
uv = u \cdot v + u \wedge v
]

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

То есть математика уже содержит механизм взаимодействия.

Без attention-блоков.
Без mixer-слоев.
Без архитектурного «спагетти».

Результат:

- 77.82% точности на CIFAR-100 при всего 1.4M параметров
- примерно в 8 раз меньше параметров, чем у ResNet-18

И при строгой сложности O(N).

Авторы даже предполагают, что как только геометрические взаимодействия смоделированы корректно, feed-forward сети становятся практически лишними.

Хорошее напоминание для сообщества AI: инженерные фишки могут править долго, но рано или поздно приходит математика и убирает половину архитектуры.

Геометрия XIX века только что вошла в компьютерное зрение.

https://arxiv.org/pdf/2601.06793

👉 @DataSciencegx

OpenClaw + RL

Агенты OpenClaw адаптируются через файлы памяти и навыки (skills), но базовые веса модели при этом фактически не меняются.

OpenClaw-RL решает эту проблему.

Он оборачивает self-hosted модель в OpenAI-совместимый API, перехватывает живые диалоги из OpenClaw и обучает policy в фоне с использованием RL.

Архитектура полностью асинхронная. Это означает, что обслуживание запросов (serving), оценка награды (reward scoring) и обучение (training) выполняются параллельно.

После завершения веса модели hot-swap’ятся после каждого батча, при этом агент продолжает отвечать без остановки.

Сейчас поддерживаются два режима обучения:

- Binary RL (GRPO): process reward model оценивает каждый ход диалога как хороший, плохой или нейтральный. Это скалярное вознаграждение используется для обновления policy через objective в стиле PPO с клиппингом.

- On-Policy Distillation: когда приходят конкретные исправления вроде «тебе стоило сначала проверить тот файл», эта обратная связь используется как более богатый, направленный обучающий сигнал на уровне токенов.

Когда стоит использовать OpenClaw-RL?

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

Существующая экосистема навыков OpenClaw и созданные сообществом навыки самоулучшения покрывают широкий спектр кейсов без какого-либо изменения весов модели.

Если агент постоянно забывает пользовательские предпочтения — это проблема памяти. А если он не знает, как обработать конкретный workflow — это проблема навыков. Обе задачи решаются на уровне prompt’ов и контекста.

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

Например:

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

Исследования в области agentic RL (например, ARTIST и Agent-R1) показывают, что такие поведенческие паттерны упираются в потолок при использовании только prompt-подходов, особенно в сложных многошаговых задачах, где модель должна восстанавливаться после сбоев инструментов или менять стратегию прямо во время выполнения.

Именно на этот уровень нацелен OpenClaw-RL — и это принципиальное отличие от того, что предлагает OpenClaw.

https://github.com/Gen-Verse/OpenClaw-RL

👉 @DataSciencegx

4 паттерна, которые я вижу, когда GenAI сталкивается с системами Data Engineering:

» LLM не понимают чувствительность данных.
Попросите её «проанализировать данные клиентов», и она спокойно объединит PII, логи, внутренние метрики и тестовые таблицы в одном запросе. У неё нет концепции того, к чему ей нельзя прикасаться. Эта граница должна существовать на уровне архитектуры.

» Экспонирование схемы — это поверхность безопасности.
Чем больше сырых таблиц вы открываете системе GenAI, тем более непредсказуемыми становятся её запросы. Хорошие системы предоставляют курированные семантические слои, а не сам data warehouse.

» Промптинг — это не управление доступом.
Написать в системном промпте «не обращайся к чувствительным данным» — это рекомендация, а не контроль. Управление должно реализовываться через права доступа, замаскированные представления и шлюзы выполнения запросов

» Наблюдаемость важнее при работе с AI, чем с людьми.
Человек выполняет несколько запросов.
Агент может выполнить сотни за считанные минуты.
Если вы не отслеживаете паттерны запросов и скачки стоимости почти в реальном времени, вы не заметите проблему, пока не получите отчёт об инциденте.

Распространённая ошибка: относиться к AI как к умному аналитику. Это не так.
Это высокоскоростной генератор запросов без суждений, которому нужны guardrails и строгий execution layer между ним и любыми критичными системами.

👉 @DataSciencegx

json-render теперь поддерживает YAML как wire-format

JSONL требует, чтобы элемент был получен полностью, прежде чем его можно будет отрендерить.

YAML, напротив, остается валидным на любом префиксе — от уровня элемента до уровня свойства

Кроме того, YAML выглядит для LLM как исходный код, что облегчает работу с ним.

Также используются три знакомых для моделей стандарта:

* JSON Patch
* Merge Patch
* Unified diff

➤ Любой вход + любой выход

➤ Любой стандарт + отсутствие стандарта

➤ Быстро, предсказуемо, функционально, stateful

https://github.com/vercel-labs/json-render

👉 @DataSciencegx

Визуализатор сложности

👉 @DataSciencegx

Кодинг с AI-агентами тихо превращается в новый SDLC.

Разработка ПО переживает самый большой сдвиг со времён появления GUI.

Планирование.
Разработка.
Тестирование.
Деплой.

Агенты начинают брать на себя всё это.

Вот изменение, которое большинство инженеров пока не заметили 👇

Старая модель: SDLC (Software Development Lifecycle)

- последовательные этапы
- выполнение управляется людьми
- тестирование происходит после разработки
- изменения требований ломают сроки

Всё движется шаг → за → шагом.

Новая модель: ADLC (Agent-Driven Lifecycle)

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

Вместо обычного pipeline…

вы получаете живую систему разработки.

6 крупных изменений, которые происходят прямо сейчас

1️⃣Драйвер процесса

Исполнение людьми → автономные агенты

2️⃣Планирование

Фиксированный scope → эволюционирующие цели и PRD

3️⃣Скорость разработки

Последовательные передачи задач → параллельные суб-агенты

4️⃣Тестирование

QA после разработки → непрерывное тестирование

5️⃣Адаптивность

Хаос в середине цикла → перепланирование в реальном времени

6️⃣Обратная связь

Ретроспектива в конце проекта → постоянный live-мониторинг

Первые сигналы уже есть

Согласно отчётам по agentic coding:

- команды в Wiz и CRED удвоили скорость выполнения задач
- крупные репозитории уже модифицируются автономно
- сложные реализации выполняются за часы вместо дней

Как инженерам адаптироваться

1. Начните с одного агента
Автоматизируйте сначала тестирование.

2. Учитесь писать чёткие PRD
Агенты выполняют ровно то, что вы формулируете.

3. Используйте параллельных суб-агентов
Разбивайте большие задачи на несколько потоков работы.

4. Проверяйте результат, а не каждую строку кода

5. Создавайте live-feedback loops
Агенты должны обнаруживать проблемы раньше вас.

Главная мысль: будущее разработки ПО — это не просто более быстрый кодинг.

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

👉 @DataSciencegx

Вам больше не нужен облачный API, чтобы получить качественный OCR

GLM-OCR работает локально, требует всего около ~2 ГБ VRAM, умеет обрабатывать таблицы, математические формулы и достигает скорости примерно ~260 токенов/с на Mac Studio M2 Ultra.

Локальные модели становятся лучше и при этом меньше с невероятной скоростью.
Если у вас есть GPU или Mac, то у вас уже есть всё необходимое, чтобы войти в эпоху ИИ.

👉 @DataSciencegx

K-means — простой алгоритм. Быстрым на GPU его сделать — нет.

Поэтому сделали Flash-KMeans — IO-aware реализацию точного k-means, переосмысленную с учётом узких мест современных GPU.

За счёт работы напрямую с memory bottleneck’ами:

- до 30× быстрее, чем cuML
- до 200× быстрее, чем FAISS
- при этом — тот же самый алгоритм, просто оптимизированный под современное железо

На масштабах в миллионы точек одна итерация k-means выполняется за миллисекунды.

Классический алгоритм — переработанный под современные GPU.

Paper: https://arxiv.org/abs/2603.09229
Code: https://github.com/svg-project/flash-kmeans

👉 @DataSciencegx