Интересное что-то
522 subscribers
2.72K photos
253 videos
140 files
4.53K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Forwarded from rizzearch
Memory Mosaics

хоть недавно и вышла альтернатива трансформеру от саканы, она все равно использует аттеншн как основной механизм и не выглядит как вывод из bitter lesson

здесь же хочется написать про айклировские 2025 мозаики памяти, которые базируются на ассоциативной памяти (да, она мне нравится и я про нее уже писал здесь и здесь + китай тоже что-то пытается с ней делать, разбавляя текст цитатами из goodreads)

вместо селф аттеншна идет же база на основе Надарая-Ватсона [1], [2]
- где моделируют необходимые ключи k и значения v для ассоциаций
- при том ключи вычисляются по токенам вплоть до данного таймстепа, а значения же на один шаг вперед (хотя можно в теории сделать и на большее количество шагов + нам еще так не придется вставлять позиционное кодирование), а на инференсе получается путем интерполяции
- и итоговый аутпут вычисляется через Надарая-Ватсона (который в теории должен сходиться к истинному какому-то там условному мат ожиданию значений v от ключей k)
- и поскольку теоретически один такой модуль сходится, то и интерпретация его (по словам авторов) лучше, чем один модуль селф аттеншна, да и даже эффективнее. так они эмпирически показывают, что inductive bias может появиться уже с одним таким блоком памяти, в то время как аттеншну нужно минимум 2 слоя
- для того, чтобы хендлить длинные последовательности и больше укрепить вопрос о позиционности токенов в архитектуре, авторы добавили нормализацию и leaky average, которую можно реализовать через свертку
- если же наслаивать эти модули друг на друга, каждый в отдельности будет отвечать за свой кусок меморизации, нужный для цельной картины - отсюда и название мозаик памяти (а и еще это наводит на мысли о связи мета-лернинга и градиентного обучения, про которое мы и тут упоминали)

что по экспам?
- супер-пупер маленький скейл (сравнивают с маленькой гпт2)
- игрушечные датасеты (3 луны) + языковое моделирование как BabiStories + in-context learning on RegBench
- обгоняет по перплексии, обгоняет в ин-контекст лернинг сетапе + нужно меньше слоев (в том числе в сравнении и с рнн и ссм)
- добавляют еще аналог FFN в виде Persistent Associative Memory (где количество kv фиксировано и они побольше подходят с теории кернел регрессии)
- но масштабируемо ли?

seems like not. иначе их predictive disentanglement (свойство мозаики) сравнивался с бОльшим скейлом моделек + были бы аблации на чувствительность к гиперам

но материал хорош для повторения всей этой теории и нового взгляда на аттеншн

👀 paper, code
Обещанный аналитический ноутбук от бигтеха!

Доброе воскресеннее утро!
Здесь приложил ссылку на google colab с реальным кейсом на собес Миддла!

Как с ним работать?
1. Первое и самое главное - нажимаем на "файл" - "сохранить копию на диске"
2. Выполняем задачи, по возможности засекайте время выполнения таких вещей как: распарсить данные, выполнение 1, 2 и тд задач
3. Если необходимо закидываем общую инфу из датасета в чат GPT и просим придумать еще задания.


* Если же вы еще маленький или сомневаетесь в себе, но очень интересно - там внизу есть мое решение с комментариями того как я мыслю


Вот вам отличная возможность поработать с датасетом с собеса + ответить на типовые вопросы на скорость решения (причем такие, которые часто самому надо сделать).

Че думаете по поводу сложности кейса?

По традиции ставим прогрессивного жаба 📈, если ждете больше крутых и удобных материалов, заинтересованного жаба 📃 если было интересно глянуть решение и просто лайк ❤️, чтобы я увидел ваш фидбек
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Интерактивный учебник искусству вайб-кодинга от Рика Рубина 🌊

Год назад и представить не могла бы, что такой коллаб возможен. Бесплатная онлайн книжка, в большей степени про искусство создания. В похожем стиле, что и "The Creative Act" -- чтобы остановиться, подумать и вдохновиться. Не бояться критики, не утопать в попытке создать идеальное и конечно же попробовать создать каждую из этих визуализаций в Claude.
Forwarded from Refat Talks: Tech & AI
Media is too big
VIEW IN TELEGRAM
🔥 Наконец-то рабочий Telegram MCP!

Из нескольких GitHub-репозиториев только mcp-telegram от dryeab оказался реально рабочим. И работает он просто огонь! Сделал обзорчик специально для вас.

Зацените, на видео показываю уже настроенную версию: поиск по сообщениям, анализ канала (угадайте чей?), суммаризация контента. Все то, что может делать обычный пользователь Telegram - не бот, а именно юзер-аккаунт. Работает неожиданно быстро и стабильно.

Что можно делать через этот MCP:
- Отправлять, редактировать и удалять сообщения
- Искать по истории чатов с фильтрами
- Скачивать медиа из сообщений
- Управлять черновиками
- Получать сообщения по прямым ссылкам
- Искать пользователей, группы и каналы

И все это прямо из Claude, Cursor и т.д.

Важный дисклеймер: я проанализировал репозиторий, проверил зависимости - ничего подозрительного. Но все равно поставил на тестовый тг аккаунт. Вам тоже советую использовать тестовый, безопасность - прежде всего. Плюс нужно соблюдать ToS Telegram и не злоупотреблять.

Настройка не самая очевидная, но для mtproto стандартная: получаете API ID, ключ, hash и тд с my.telegram.org, аутентифицируетесь через CLI, добавляете конфиг в Claude Desktop.

Side note: вся эта возня с JSON-конфигами и CLI-командами поднимает порог входа в MCP для нетехнических людей, надо что-то с этим делать)

Но если вы умеете в терминал - очень рекомендую поиграиться. Это реально расширяет возможности Claude и открывает кучу интересных use case'ов.

Репозиторий: https://github.com/dryeab/mcp-telegram

И это, если этот пост не заслуживает на 🔥и репост, то даже не знаю какой заслуживает! :)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Apps Design (Artemiy Kozyr)
🆕 Полностью БЕССЕРВЕРНЫЕ Аналитические Приложения на dlt, DuckDB, dbt, Observable (Streamlit)

Или как собрать аналитическое приложение за $2 в месяц.

Изучая стек dlt + DuckDB + dbt + Observable (Streamlit), я наткнулся на интересную архитектуру. Оказывается, можно создать функциональное, но в то же время легковесное аналитическое приложение, которое работает почти без серверов.


🟡 Конкретная схема:

GitHub Actions (CI) → dlt загружает данные →
dbt трансформирует → DuckDB файл → S3/Object storage →
Observable/Streamlit читает DuckDB-WASM в браузере



🔵 Реальные цифры:

— Object storage / S3: $0.015 за GB хранения
— GitHub Actions: 2000 минут бесплатно
— Observable: бесплатно
— Итого: ~$2/месяц для приложения с 10GB данных


🟢 Что получается:

Дашборд грузится за 200ms (всё в браузере)
Работает офлайн после первой загрузки
Выдерживает любые нагрузки (статика!)
Автообновление через GitHub Actions


🔴 Ограничения (честно):

Размер данных ограничен памятью браузера (~2-4GB), но вряд ли нам вообще понадобится больше (ведь хранить мы будем агрегированные витрины)
Сложные real-time обновления проблематичны
Нет серверной логики для сложной авторизации
Ограниченная интерактивность и self-service (для этого нужны BI типа Superset)



🟤 Где это работает лучше всего:

— B2B SaaS аналитика для клиентов / Сквозная аналитика / Sales, Markeplace metrics, etc.
— Встраиваемая (Embedded) в web / mobile apps аналитика
— Демонстрационные стенды (showcasing)
— Публичная аналитика (типа COVID дашбордов)
— Дашборды для внутреннего контура компании (до 1000 сотрудников)
— Персональные и pet-проекты с историческими данными

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



Конкретный пример использования:

— Собираем данные Я.Метрика, Я.Директ, AmoCRM (Bitrix) с помощью dlt в DuckDB
— Варим эти данные, чистим, нормализуем, объединяем, считаем витрины (dbt + DuckDB)
— Создаем интерактивное приложение на основе Observable с DuckDB-WASM под капотом (т.е. бразуер = сервер, который процессит витрину в DuckDB)
— В приложении видим динамику ключевых метрик Marketing, Sales разрезах: даты, каналы, георгафия, воронки, sales-менеджеры
— Приложение = статический вебсайт, который размещается на любом хостинге (Object storage / S3) и не требует сервера


💬 У кого какие мнения на этот счет?
Где еще можно (нужно) применить такой подход?
Кто пробовал похожие решения?

🌐 @data_apps | Навигация по каналу
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from BeOps
System Design github repo 🕌

Проходил сис дизайн интервью в прошлый понедельник, а сегодня наткнулся на такой репозиторий: https://github.com/ByteByteGoHq/system-design-101?tab=readme-ov-file. Это просто библия для прохождения сис дизайна. По мне так отличное чтиво в мире сложных архитектурных решений. Здесь есть всё: от сравнений REST API и GraphQL до объяснений, почему Nginx называют reverse proxy. А если хочешь узнать, как работает Google Authenticator или почему Redis такой быстрый, то тут вообще велком.

Что здесь есть? (спойлер: ВСЁ) 🌍
- Архитектурные паттерны: Хочешь понять, что такое MVC, MVP, MVVM или даже VIPER? Легко.
- CI/CD: Хочешь почувствовать себя инженером Netflix? Добро пожаловать.
- Кэширование: Почему Redis так быстр? Как кэшировать данные правильно? Ответы здесь.
- Базы данных: Визуализация SQL-запросов, CAP-теорема и даже "8 структур данных, которые управляют вашими базами".
- Микросервисы: Лучшие практики, Kafka, и типичная архитектура микросервисов.
- Реальные кейсы: Хочешь понять, как Discord хранит триллионы сообщений или как YouTube справляется с потоковым видео? Этот репозиторий расскажет.


Документация понятным языком 😌
Здесь всё объясняется простыми словами, а визуализации помогут понять даже самые сложные концепции. Например, диаграммы HTTP-протоколов или сравнение Webhook и polling — это просто шедевры.
Что мне еще понравилось,это то что многие репозитории и статьи сосредотачиваются на одной теме — типа БД, DevOps или микросервисы. Но "System Design 101" — это будто шведский стол для инженеров: тут есть всё и сразу, причём подано так, что хочется взять добавки. Конечно, есть и другие хорошие источники (например, книги Фаулера или блоги Google), но этот репозиторий выигрывает своей компактностью и доступностью.

Добавляй в закладки и начни своё путешествие к званию мастера системного дизайна. Кароче, с таким багажом получаешь +10 к харизме на собеседованиях и +20 к навыкам архитектуры. Проверить это можно только одним способом — скачал, отсобесился, забрал офер на 500к.
Forwarded from Анализ, коты, цветы и Катя (Катерина)
🐰 Самый простой способ понять работу RabbitMQ 🐰

В сообществе аналитиков довольно известен этот визуализатор работы Kafka. Я узнала о нём из блога Системный сдвиг, а затем оценила классную рекомендацию по работе с ним от Yet Another Analyst.

Но поскольку я провожу уроки именно по RabbitMQ, стало интересно: А есть ли похожая визуализация RabbitMQ для тех, хочет быстро просто “увидеть”, как оно работает?

Оказывается, есть! И даже несколько:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer

Я советую первый. Как с ним работать? Часть 1.


🚦 0. Добавьте producer и queue. Попробуйте соединить их напрямую. Добавьте exchange, соедините всё по схеме: producer → exchange → queue. Что то должно начинать получаться, потому что еxchange — обязательный этап маршрута в RabbitMQ. У связи exchange и queue появился binding — ключевой элемент понимания маршрутизации. Добавьте consumer. Попробуйте соединить consumer с exchange. Что-то снова будет не хватать. Но правильный порядок близок: producer → exchange → queue → consumer.

💥 1. Выберите для exchange тип fanout. Создайте еще 2 очереди и 2 потребителя и привяжите их к exchange. Отправьте сообщение без routing key. Куда оно ушло? Установите разные binding key и отправьте сообщения со случайными с routing key. Что происходит? Удалите один binding. Получает ли эта очередь сообщение? Здесь можно еще поэкспериментировать с ключами, Но основную особенность обменника типа fanout вы уже должны нащупать.

Это первые важные шаги для знакомства с базовой схемой кролика и типом обменника Fanout. Сохраняйте, пробуйте.

В следующем посте расскажу про упражнения для схем с Direct и Topic exchange — не пропустите!

#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst
Forwarded from Анализ, коты, цветы и Катя (Катерина)
🐰 Самый простой способ понять работу RabbitMQ — Часть 2 🐰
🧵 Первая часть

В первой части я поделилась двумя визуализаторами для RabbitMQ:
🔗 TryRabbitMQ
🔗 RabbitMQ Visualizer
И простыми упражнениями, чтобы разобраться с типом обменника fanout.

Теперь давайте посмотрим на обменники типа Direct и Topic.

1) Очистим поле и снова создадим схему: producer → exchange → 3 очереди → 3 consumer'а. Тип обменника — direct. Для binding key укажем key1, key2, key3. Теперь отправим сообщение с routing key = key. Куда попало сообщение? Затем поочерёдно отправим сообщения с ключами key1, key2, key3. Попробуйте также: key1_1, key1.*, key1.#. Если всё сделали правильно — должны появиться мысли про "полное соответствие".

2) Меняем тип обменника на topic. Для binding key задаём: *.low.* , #.spb , *.high.#
Сразу подсказка: . — разделяет ключи, * — заменяет ровно одно слово, # — заменяет 0 и более слов. Пробуем отправлять: key1.low.smr, key1.middle.spb, key2.high.krd, low.smr, key, high и другие. Для полноты картины можно поэкспериментировать с регистром и пробелами.

3) RabbitMQ для практиков: создаём схему с несколькими exchange'ами, соединяем их как на картинке. Пробуем задавать разные типы для обменников, подбирать ключи и очереди, отправлять сообщения с разными routing key. И просто наблюдать, как идёт сообщение. На этом этапе особенно важен подход "А что если?.." и ваша фантазия.

💡 Еще в TryRabbitMQ можно поэкспериментировать с периодичностью отправки и анонимными очередями. Но, на мой взгляд, в визуализаторе эти функции реализованы довольно скучно и не слишком информативно.

📌 В последней части (на следующей неделе) расскажу, что нельзя увидеть в визуализаторе, куда копать тем, кто хочет больше.

#RabbitMQ #ОчередиСообщений #MessageBroker #SystemAnalyst
Forwarded from Refat Talks: Tech & AI
Media is too big
VIEW IN TELEGRAM
🤌 Anthropic выпустила курс AI Fluency - он супер и по контенту, и по оформлению

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

Главный инсайт курса - 79% пользователей застряли на уровне "automation" (тупо просят AI что-то сделать), а 21% успешных работают на уровне "augmentation" - относятся к AI как к умному коллеге.

Вот например (вроде база, но как хорошо систематизировано): 6-слойный промптинг:
- Контекст: кто ты, зачем спрашиваешь, как будешь использовать ответ
- Примеры: покажи что именно хочешь получить
- Ограничения: формат, длина, стиль ответа
- Шаги: разбей сложную задачу на этапы
- Thinking space: "подумай сначала, потом отвечай"
- Роль: "ты senior разработчик" или "ты UX-эксперт"

И то, что я использую часто - мета-обучение. Курс учит просить AI улучшать твои же промпты. "Claude, как бы ты переписал мой промпт чтобы получить лучший результат?" - и промпт эволюционирует от новичкового до экспертного за 2-3 итерации.

Практический пример с данными:
Было: "Claude, проанализируй эти данные"
Стало: "Ты data scientist с 10 летним опытом. Проанализируй данные как будто готовишь инсайты для CEO. Выдели 3 самых неожиданных паттерна с уровнем уверенности для каждого."

Разница в качестве - небо и земля.

Курс бесплатный, дают фреймворк который останется актуальным даже когда выйдет GPT-10. И да, учат составлять Personal AI Policy - набор правил как и когда использовать AI в работе.

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

Сделал саммари на русском, там же есть mindmap: https://pebble-athlete-3cb.notion.site/Anthropic-Academy-AI-Fluency-204eb5d3f3cb80c28d7ddd0591d55cfe

Но сам курс это не заменит, лучше пройдите (или пройдитесь по тому, что кажется новой информацией) самостоятельно, если интересна эта тема.
Forwarded from DataДжунгли🌳
#SQLWednesday

Сегодня обсудим классический вопрос с собеседования для #DataEngineer. 🪄
Вопрос звучит так:
"Перед тобой #csv файл 20ГБ, как откроешь?"
Конечно никакой pd.read_csv() тут не поможет это просто уложит ваше ядро в #JupyterNotebook.
-- Или поможет ? Дочитай до конца и узнаешь.
Такой вопрос могут задать на самом деле и Junior и Middle да и выше. Потому что не всегда очевидно как это сделать красиво и эффективно.

Самый эффективный способ работать с такого размера файлом это естесвенно загрузить его в базу.
#Postgres уже имеет нативный инструмент для работы с csv файлами и вот как это выглядит.


COPY raw.sales
FROM '/var/lib/postgresql/big_sales.csv' -- путь до файла на сервере или локальный путь(если постгре локальная).
WITH (
FORMAT csv, -- CSV-парсер
HEADER true, -- пропускаем строку заголовков
DELIMITER ',', -- если вдруг не запятая
QUOTE '"', -- кавычки по умолчанию
ENCODING 'UTF8' -- кодировка можно изменить если будет "криво"
);

Легко и просто. Но мы не всегда имеем доступ к серверной файловой системе, так вот как это сделать прям из JupyterNotebook не ломая ядро?

1. Для нашего эксперимента я сгенерировал файл гигант вес которого 13.4GB
2. У меня уже есть развернутый постгрес на удаленном сервере(вы можете локально установить)
3. Будем пользоваться любимым пандас с chunksize


import pandas as pd
import sqlalchemy as sa

DB = dict(
user="",
password="",
host="",
port=5432,
dbname="",
)
engine = sa.create_engine(
f"postgresql+psycopg2://{DB['user']}:{DB['password']}@{DB['host']}:{DB['port']}/{DB['dbname']}",
)

# параметры CSV
csv_path = "big_file.csv"
chunk_rows = 100_000 # будем грузить по 100K строк
table_name = "example_csv"
schema = "raw"

# создаём таблицу один раз с нужными колонками
with engine.begin() as conn:
conn.exec_driver_sql(f"""
CREATE SCHEMA IF NOT EXISTS {schema};
DROP TABLE IF EXISTS {schema}.{table_name};
CREATE TABLE {schema}.{table_name} (
col_0 text, col_1 text, col_2 text, col_3 text, col_4 text,
col_5 text, col_6 text, col_7 text, col_8 text, col_9 text
);
""")

# грузим чанками
reader = pd.read_csv(
csv_path,
chunksize=chunk_rows,
iterator=True,
header=0,
)

for i, chunk in enumerate(reader, 1):
chunk.to_sql(
name=table_name,
con=engine,
schema=schema,
if_exists="append",
index=False,
method="multi",
)
print(f"Чанк {i}: {len(chunk)} строк залито")

print("Готово!")


Пересылайте коллегам, чтобы не терялись на собеседованиях и знали что ответить 💡

Чтобы поиграть дома в DE тетрадку с кодом прилагаю 🧠

#DataJungle #Postgres #ETL
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инжиниринг Данных (Dmitry)
Все знакомы с понятием Ad-hoc запросов. Обычно мы воспринимаем их негативно, так как они отвлекают, время-то и так мало.

На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).

Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.

Вот пример фреймфорка:

1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.

2. Быстрое фильтрование (2 минуты):

- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.

3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.

📌 Чтобы не сгореть:

- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды

Эскалации - через менеджера, не через «договорился в курилке».