*Какое-то большое число*

💥 Google DeepMind выкатил LEGO для AI-агентов!

Open-source библиотека GenAI Processors — это фреймворк, который предлагает новый взгляд на то, как можно организовывать AI-агентов.

Суть такая:

1. Всё — это ProcessorPart. Неважно, что прилетело: кусок аудио, кадр видео, текстовая транскрипция или JSON-чик с данными. Всё это теперь унифицированный "кубик" со своим типом, ролью и метаданными. Никакого зоопарка из форматов.
2. "Моторы" и "переключатели" для кубиков. Вместо того, чтобы лепить гигантские функции, ты собираешь свой AI из маленьких, переиспользуемых "процессоров". Они могут работать как последовательный конвейер (Processor), так и обрабатывать каждый кубик параллельно (PartProcessor), выжимая максимум из асинхронности Python'а. Хочешь, чтобы данные обрабатывались разными способами одновременно? Пожалуйста: процессор1 // процессор2. Хочешь последовательно? процессорА + процессорБ.

GenAI Processors умеет сам жонглировать потоками, минимизировать задержки и обеспечивать хорошую отзывчивость (Time-To-First-Token).

Что с этим можно делать?

* Собирать real-time AI-агентов (слышит, видит, говорит) всего в несколько строк кода.
* Строить исследовательских агентов, которые сами ищут инфу в Google и синтезируют ответы.
* Делать умных планировщиков, которые, пока ты ждешь, уже в фоне накидывают тебе маршрут путешествия.

🧐 Разбор поподробнее с примерами кода читаем здесь.

Осваиваем query() и eval() в Pandas для лаконичной фильтрации и вычислений

Если вы работаете с данными, то наверняка знаете этот "скобочный ад" в pandas. Когда простое, на первый взгляд, условие фильтрации превращается в нечитаемое чудовище: df[(df['col1'] > X) & ((df['col2'] == Y) | (df['col3'] < Z))] 🤢

Но есть более читаемый путь. Речь, конечно, о методах query() и eval(). Они позволяют писать условия фильтрации и вычисления в виде простой строки, как будто вы описываете логику на естественном языке. Код становится чище, короче и понятнее с первого взгляда.

Все подробности, наглядные примеры разобрали в статье. Читаем 🚀

Алгоритмическая задачка 🐍

Представьте, что вы нашли сокровищницу! 🐉💰 В ней — россыпь золотых слитков разного веса. Ваша задача как самого умного в команде — определить, можно ли поделить всю добычу по-честному на k равных долей для каждого участника.

📋 Условие

Напишите функцию can_partition(nums: list[int], k: int) -> bool, которая принимает список весов слитков nums и количество участников k. Функция должна возвращать True, если все слитки можно разбить ровно на k непустых групп с одинаковой суммой весов, и False в противном случае.

Формат ввода:
- nums: список целых положительных чисел.
- k: целое положительное число.

Формат вывода:
- bool: True или False.

Примеры: 🤔

1️⃣ Вход:
nums = [4, 3, 2, 3, 5, 2, 1]
k = 4

Вывод: True ✅
Объяснение: Общая сумма 20. На каждого из 4-х участников приходится по 5. Возможный делёж: [5], [1, 4], [2, 3], [2, 3].

2️⃣ Вход:
nums = [1, 2, 3, 4]
k = 3

Вывод: False ❌
Объяснение: Общая сумма 10, которая не делится на 3 без остатка. Делёж невозможен.

Жду ваши элегантные и эффективные решения в комментариях! 👇

🔮 Прогнозирование временных рядов в Python: от хаоса в данных к работающей модели SARIMA

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

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

Что внутри:
1️⃣ Загружаем и смотрим на данные. Учимся видеть тренд и сезонность.
2️⃣ Узнаём, почему «нестационарный» ряд — это плохо, и как его исправить с помощью логарифмов и дифференцирования.
3️⃣ Разбираемся, как подбирать параметры в SARIMA при помощи ACF/PACF графиков.
4️⃣ Строим и проверяем полученную модель.

✍️ Решения вчерашней задачи

Задачку никто не решил 🥹 Но она была не из простых. Давайте посмотрим, как можно было.

💡 Оптимальное решение: умный бэктрекинг с умом

Этот метод по своей сути — умный перебор. Мы пытаемся рекурсивно "пристроить" каждый слиток в одну из k корзин, но с важными оптимизациями, которые отсекают заведомо проигрышные пути.

def can_partition(nums: list[int], k: int) -> bool:
    total_sum = sum(nums)
    if total_sum % k != 0:
        return False

    target_sum = total_sum // k
    subsets = [0] * k
    nums.sort(reverse=True)

    def backtrack(index):
        if index == len(nums):
            return True

        for i in range(k):
            if subsets[i] + nums[index] <= target_sum:
                subsets[i] += nums[index]
                if backtrack(index + 1):
                    return True
                subsets[i] -= nums[index]
                
                if subsets[i] == 0:
                    break
        
        return False

    return backtrack(0)

🧠 Как это работает?

1. Первым делом считаем общую сумму total_sum. Если она не делится на k нацело, то поделить слитки на равные по весу группы невозможно. Сразу возвращаем False.

2. Сортируем слитки по убыванию nums.sort(reverse=True). Пытаясь разместить сначала самые тяжелые слитки, мы гораздо быстрее обнаруживаем "тупиковые" ветви комбинаций и отбрасываем их, экономя уйму времени.

3. Рекурсивный поиск (бэктрекинг):
- Функция backtrack пытается разместить каждый слиток, начиная с index = 0.
- Она перебирает все k "корзин" (subsets) и пробует добавить текущий слиток nums[index].
- Если после добавления сумма в корзине не превышает target_sum, мы рекурсивно вызываем backtrack для следующего слитка.
- Если вызов вернул True — ура, решение найдено!
- Если нет — мы "откатываем" изменение (убираем слиток из корзины) и пробуем положить его в следующую.

4. Оптимизация: if subsets[i] == 0: break.
Эта строчка означает: если мы попробовали положить слиток в пустую корзину и эта попытка не привела к итоговому решению, то нет никакого смысла пробовать класть этот же слиток в другие пустые корзины. Они ведь ничем не отличаются! Это простое условие радикально сокращает пространство поиска.

Временная сложность: O(k^N), где N — количество слитков. Задача относится к классу NP-полных, поэтому решения с полиномиальным временем (вроде O(N^2)) не существует. Однако благодаря нашим оптимизациям, на реальных данных алгоритм работает значительно быстрее, чем его худшая оценка.
А пространственная сложность: O(N + k). В основном определяется глубиной рекурсии (O(N)) и хранением "корзин" (O(k)).

Наверное, одна из самых сложных задачек, которые тут были 😏

Нейронка-исследователь от Стэнфорда 🧑🏻‍🔬

Наткнулся тут на проект от ребят из Стэнфорда — STORM. Это LLM-система, которая по заданной теме сама лезет в интернет, проводит ресёрч и на выходе генерирует подробную статью в стиле Википедии, сразу со ссылками на источники.

Самое интересное, конечно, как оно под капотом работает. Вместо того чтобы тупо просить LLM задавать вопросы, они сделали хитрее:
1️⃣ Сначала система находит похожие статьи, чтобы понять, с каких разных точек зрения (перспектив) можно посмотреть на тему.
2️⃣ А потом симулирует диалог между автором и экспертом, который «заземлён» на найденные интернет-источники. Это позволяет задавать более глубокие и осмысленные вопросы.

Сами авторы, конечно, честно признаются, что на выходе получается не готовая к публикации статья, а скорее очень хороший черновик для дальнейшей работы. Так что заявления в стиле «ИИ пишет научные статьи как PhD» — это, как обычно, заигрывания с мечтами людей 🌚

Что ещё крутого:
▫️ Есть фича Co-STORM, где человек может влезть в процесс и направить дискуссию LLM-агентов в нужное русло.
▫️ Всё это дело опенсорсное и ставится через pip install knowledge-storm.
▫️ Можно под капотом менять и LLM (через litellm), и поисковые движки.

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

👉🏻 GitHub проекта
👉🏻 Попробовать онлайн