Интересное что-то
517 subscribers
2.71K photos
253 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Forwarded from Tensor Banana
T-one STT (распознавание речи на русском) под виндой (без WSL и докера) на CPU

- размер очень маленький - 71M параметров (whisper large - 1500M), поэтому быстрый.
- по первым ощущениям, уровень ошибок на уровне whisper-large.
- но по метрикам превосходит все существующие модули распознавания речи для русского.
- по умолчанию работает на CPU и довольно быстро. Намного быстрее виспера на cpu
- на ГПУ запускать лень, надо triton-inference-server поднимать. Пишут, что для GPU нужно 8 GB vram
- не ставит знаки препинания (а виспер ставит)
- обычное голосовое сообщение умеренного качества, записанное на улице, длиной 74 секунды он распознал за 12 секунд на CPU. Работает потоково. Первая фраза появилась уже через 1 секунду. Итого: 10 ошибок, в основном, пропуск слов, которые плохо слышно, иногда неверные окончания.


Установка под виндой

(для linux или wsl - используйте официальную инструкцию)

git clone https://github.com/voicekit-team/T-one.git
cd T-one
python -m venv .venv
.venv\Scripts\activate

в файле pyproject.toml удаляем или комментируем (#) строчку 16:
"kenlm (>=0.2.0,<1.0.0)",

git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
bootstrap-vcpkg.sh
vcpkg integrate install
vcpkg install kenlm

cd ..
pip install poetry
poetry lock
poetry install -E demo
pip install kenlm

uvicorn --host 127.0.0.1 --port 8081 tone.demo.website:app --reload

открываем 127.0.0.1:8081 в браузере



По умолчанию демо работает на CPU. Чтобы запустить на GPU нужно ставить TensorRT и triton-inference-server. Там свои сложности, под винду есть только некоторые версии сервера. Официальная инструкция (я не тестил) https://github.com/voicekit-team/T-one/blob/main/docs/triton_inference_server.ru.md



гитхаб: https://github.com/voicekit-team/T-one

HF: https://huggingface.co/t-tech/T-one
Forwarded from Start Career in DS
👩‍💼 Как развить бизнес видение?

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

Небольшой список общих советов:
👉 Ходите на конференции, где разбираются реальные кейсы: матемаркетинг, aha!, датафест
👉 Читайте каналы по интересующей вас тематике, а еще полезно почитать разные каналы с отчетностями компаний, чтобы понять, на чем они зарабатывают и на какие метрики смотрят, например, @businessincognita и @expertosphere
👉 Читайте книги, которые развивают бизнес-видение, например, The Data Detective и How To Measure Anything. Отдельно рекомендуем "Спроси маму" Роба Фитцпатрика, она научит вас правильно задавать вопросы клиенту и понимать, что реально он хочет, а в чем вообще не заинтересован. Саммари есть на хабре, но админы читали целиком и вам советуют

А теперь подборка, если вам нужно все и сразу за короткий срок перед собесом:
🔎 Школа менеджеров Яндекса: возможность заглянуть в закулисье яндекса, построения продукта и принятия решений в нем
🔎 Платформа growth.design, на которой в формате комиксов разбираются различные продуктовые кейсы мировых топ-компаний. Узнали про нее от Макса из Заскуль Питона, оч советуем подробнее про эту крутую платформу прочитать у него.
🔎 Блог GoPractice – много классных бесплатных статей про продуктовый менеджмент, маркетинг и аналитику. А если понравится, то у них есть и платные симуляторы
🔎 Блоги компаний. Например, Авито, Яндекса, Альфа-банка. Выбирайте статьи, относящиеся к бизнес-части и прокачивайте насмотренность по принятию решений, которые влияют на то, что вы видите в своем смартфоне. Отдельно рекомендуем читать блоки компаний, куда вы планируете собеседоваться в ближайшее время. Проверенно повышает успешность прохождения собеседований, тк вы становитесь не просто аналитиком, а аналитиком, знакомым с целями, вызовами и последними решениями компаний

Ставьте лайки 👍, если было полезно, и давайте добьем каналу следующий уровень, осталось совсем немного!
Forwarded from max.sh
Искал статьи / работы рисерчеров, участвовавших в разработке Deep Research и наткнулся на блог одного из ключевых авторов технологии — Джейсона Вэя (Jason Wei). Ссылка на блог. Джейсон является первым автором статьи про Chain of Thought ещё со времён работы в Google Brain (теперь часть Дип Майнда).

В блоге Джейсон интересно пишет свои мысли про рисерч, как его вести, как строить карьерный путь и немного рефлексии на тему своих же научных статей.

Из интересного про RL — Асимметрия верификации. Ссылка

Множество задач требуют значительных усилий для генерации решения, но при этом легко поддаются проверке. Взять судоку или кроссворд. А вот написание эссе на заданную тему — напротив: сгенерировать его для модели несложно, а вот провести факт-чекинг и оценить содержание гораздо труднее. В этом и заключается асимметрия верификации: есть задачи, которые можно быстро и дёшево проверить на корректность (при наличии эталонного ответа), но при этом неясно, как к этому ответу прийти; а есть такие, к которым можно сгенерировать тысячи вариантов, но трудно определить, какие из них действительно правильные.

Тут и начинается самое интересное — поиск способов уменьшения асимметрии. Для большого класса сложных задач это действительно возможно. Например, асимметрию можно значительно снизить для задач по математике и программированию (Картинка к посту). Как? Если для задачи есть эталонное решение или тесты на корректность, то в процессе эволюции, какой бы сложной она ни была, генерация правильного ответа становится задачей RL-оптимизации.

Путём таких рассуждений автор приходит к формулировке условного "закона":
Verifier’s law: The ease of training AI to solve a task is proportional to how verifiable the task is. All tasks that are possible to solve and easy to verify will be solved by AI.


И дальше выделяет пять свойств, которыми должна обладать задача, чтобы быть "легко" решённой LLM:

⚫️Быстрота верификации — можно за секунды определить, правильно ли решена задача
⚫️Скейлинг верификации — можно проверять одновременно множество решений
⚫️Согласованность корректности — все (люди) легко могут придти к консенсусу о том, какое решение хорошее, а какое нет
⚫️Ранжирование качества решений — можно упорядочить варианты по степени качества
⚫️ Устойчивость к шуму — верификация коррелирует с качеством решения и ложно-положительные срабатывания минимальны

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

Отдельно можно заметить, что большинство популярных бенчмарков как раз обладают всеми свойствами задачи для верификаци (MMLU, SWE bench, GSM8K, тот же Humanity's Last Exam). Потому эти бенчмарки и популярны, и потому в тех аспектах, что они проверяют (код, общие знания, математику) LLM-ы развиваются активнее всего.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from эйай ньюз
GLM 4.5 — китайский опенсорс продолжает доминировать

Очередная очень сильная открытая MoE модель от китайцев, с очень хорошими результатами на бенчах. Гибридний ризонер, с упором на тулюз. Доступна по MIT лицензии, 128к контекста, нативный function calling, из коробки работают стриминг и batching, есть FP8‑инференс и совместимость с vLLM/SGLang.

Как и Kimi K2 модельку тренировали с Muon, но в отличие от Kimi авторы использовали QK норму вместо клиппинга — Kimi такой трюк не позволило провернуть использование MLA, из-за чего им пришлось придумывать свою версию оптимайзера. Для спекулятивного декодинга получше модельку тренировали с MTP. Она заметно глубже чем другие открытые китайские MoE — это повышает перформанс, за счёт роста размера KV-кэша. Вместе с этим они используют заметно больше attention heads. Это хоть и не помогает лоссу, но заметно улучшает ризонинг бенчмарки.

Модель идёт в двух размерах — 355B (32B active) и 106B (12B active). Претрейн был на 22 триллионах токенов — 15 триллионов токенов обычных данных, а после них 7 триллионов кода с ризонингом. На мидтрейне в модель запихнули по 500 миллиардов токенов кода и ризонинг данных с контекстом расширенным до 32к, а после этого 100 миллиардов long context и агентных данных при контексте уже в 128к.

Посттрейн двухэтапный — сначала из базовой модели через cold‑start+RL тренируют три эксперта (reasoning модель, agentic модель, и для общих тасков) и сводят их знания в одну модель через self‑distillation. Затем идёт объединённое обучение: общий SFT → Reasoning RL → Agentic RL → General RL.

Для ризонинга применяют одноступенчатый RL на полном 64K‑контексте с curriculum по сложности, динамическими температурами и адаптивным клиппингом. Агентные навыки тренируют на верифицируемых треках — поиск информации и программирование с обратной связью по исполнению. Полученные улучшения помогают и deep search и общему tool‑use. Кстати, их посттрейн фреймворк открытый и лежит на гитхабе.

Веса

Демо
Блогпост
Посттрейн фреймворк

@ai_newz
💫 Spark для аналитика (ч. 1)

Раньше в 💙 я работал немного со Spark, большая часть задач спокойно решалась внутри одной БД или выгрузкой в pandas.

Сейчас для моих задач Spark - это необходимость, чтобы не падал JupyterHub по оперативной памяти: все вычисления выполняются распределённо на кластере с большим объёмом ресурсов. Но это не волшебная таблетка, т.к. важно следить за тем, как используются ресурсы, грамотно настраивать Spark-приложения и оптимизировать запросы. На самом деле подход к работе с ресурсами здесь другой, и есть ряд ограничений, о которых расскажу в следующих постах 🙃

🥳 Как я использую сейчас

1. Собираю данные из разных источников
В реальных задачах часто нужно объединять сразу несколько источников: выгрузки из разных баз, parquet и тд. Пока всё влезает в pandas - норм, но когда данных слишком много, pandas начинает падать. Spark позволяет легко подтянуть все необходимые источники и собрать их в одну большую таблицу, не заботясь об ограничениях памяти.

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

😍 Spark реально может работать дольше, чем pandas, если данных немного. Всё из-за архитектуры: Spark каждый раз поднимает распределённую систему, разбивает задачи на части, отправляет их на кластер и только потом собирает результат. Pandas же считает всё в оперативке и на небольших данных это быстрее почти всегда.

🔽Ниже прикрепляю основные функции для работы в Spark, которые я использую для решения задач аналитики

from pyspark.sql import SparkSession
from pyspark.sql.functions import avg, count

# запускаем Spark-сессию, тут еще можно закопаться в настройки приложения (если будет много 🐳, выложу)

spark = SparkSession.builder.appName("zasql_python").getOrCreate() # название приложения может быть произвольным

# читаем csv и кучу источников

df_csv = spark.read.csv("file.csv", header=True, inferSchema=True)
df_parquet = spark.read.parquet("file.parquet")
df_json = spark.read.json("file.json")

# джойним таблицы между собой

df_joined = df_csv.join(df_parquet, on="user_id", how="inner")

# фильтруем данные

df_filtered = df_joined.filter(df_joined["is_active"] == 1)

# применяем агрегирующие функции, считаем сумму строчек, среднее значение по заказам

df_grouped = (
df_filtered
.groupBy("country")
.agg(
count("*").alias("users_count"),
avg("order_sum").alias("avg_order_sum")
)
)

df_pandas = df_grouped.toPandas()


🐼 Очень похоже на pandas + можно в любой момент пересесть на spark.sql и писать в sql-формате любой запрос.

from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("zasql_python_sql").getOrCreate() # произвольное название приложения, должно быть другим, если запускаем параллельно

df_orders = spark.read.parquet("orders.parquet") # читаем в Spark DataFrame первый источник источник
df_users = spark.read.csv("users.csv", header=True, inferSchema=True) # читаем в Spark DataFrame второй источник

df_orders.createOrReplaceTempView("orders") # создаем темповые таблицы заказов
df_users.createOrReplaceTempView("users") # создаем темповые таблицы юзеров

# теперь читаем тут в sql-формате

query = """
SELECT
u.country,
COUNT(DISTINCT o.user_id) AS active_users,
AVG(o.order_sum) AS avg_order_sum
FROM orders o
JOIN users u ON o.user_id = u.user_id
WHERE o.is_active = 1
GROUP BY u.country
ORDER BY avg_order_sum DESC
"""

result = spark.sql(query) # читаем в spark.sql, результат тот же получаем, но в SQL-формате
result.show() # показать значения, но можно перевести и в pandas, но ресурсов много сожрет


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

Ставьте
🐳, если хотите продолжение истории про Spark 💫
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Б/У ml (Толик Мастрюков)
Ускорение раннего связывания для моделей ранжирования

База
В двухэтапных рекомендательных системах используются кандидатогенерация (кандген) и ранжирование.

На этапе кандгена простые модели (например, DSSM, двухбашенные архитектуры) отбирают наиболее релевантные айтемы для пользователя. Из-за большого количества айтемов применяется позднее связывание (late interaction) — например, через скалярное произведение векторов пользователя и кандидатов.

На этапе ранжирования более сложные модели (например, CatBoost или нейросети) переупорядочивают кандидатов, учитывая дополнительные фичи, такие как счетчики взаимодействий или контекст пользователя.

Контекст
В последние годы крупные компании (Google, Meta, TikTok, Pinterest ❤️ , LinkedIn, Alibaba ) активно внедряют нейросетевые модели ранжирования, которые учитывают глобальный контекст пользователя.

В статье Amortized Inference предложен метод, улучшающий SOTA-результаты для этой задачи.

Авторы берут за основу две модели с ранним связыванием (early interaction):

BST (Behavior Sequence Transformer) — кандидат добавляется в конец истории пользователя.

TransAct — кандидат конкатенируется к каждому айтему в истории.

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

Проблема
Для каждого кандидата модель заново обрабатывает историю пользователя.
Сложность:
O(n^2⋅m⋅d+n⋅m⋅d^2)
где:

n — длина истории,
m — число кандидатов,
d — размерность эмбеддингов.

При больших
n и m (например, 1000+ кандидатов) это приводит к высоким задержкам и делает модель непрактичной для прода.

Решение
Авторы предлагают конкатенировать всех кандидатов к истории и прогонять через трансформер один раз, а затем учить модель предсказывать таргет для каждого кандидата отдельно.

Новая сложность:
O((n+m)⋅d^2+(n+m)^2⋅d)

Это дает значительное ускорение, если
m>2 (что почти всегда верно в рекомендательных системах).

Результаты
+0.18% к качеству (A/B-тесты).

+5% к latency (vs. +56% у BST и +52% у TransAct).

Вывод
Метод упрощает инференс, сохраняя качество. Его можно масштабировать с помощью Flash Attention или приближенных вычислений (например, для 3000 кандидатов, как в Авито).

Статья мне понравилась простотой и практичностью — такой подход легче внедрять в продакшене.
Forwarded from Б/У ml (Толик Мастрюков)
Слева BST , справа идея из статьи. Наглядное сравнение почему 1 метод быстрее другого
Forwarded from max.sh
В продолжение поста выше хочу привести ещё несколько интересных, на мой взгляд, нетехнических мыслей из блога Джейсона. Автор рефлексирует над принципами рисерч: как его стоит вести, какой путь выбирать, какие ожидания на сегодняшний от AI-исследователей.

Короткая сводка наиболее откликающихся мыслей в хронологическом порядке изложения автора:

[Research I enjoy]
Автор критически смотрит на свои ранние публикации и находит их слишком специфичными, «заточенными» под одну задачу. Например, применить модель к конкретному сетапу или выбить прирост в пару процентов на конкретном бенчмарке с помощью сложного не обобщаемого метода. Такие работы обычно не находят отклик в сообществе и не двигают прогресс. Поэтому, если тема слишком узкая, то какой бы крутой ни была реализация, импакт всё равно будет незначительным.
Рисерч, который откликается автору и которым он пытается заниматься:
(1) строится вокруг общих, переиспользуемых идей (новая архитектура, новый метод, новый рецепт предобучения),
(2) направлен на достижение AGI,
(3) нацелен задать вектор влияния на сообщество.

Статья про CoT-Prompting является идеальным примером реализации этой мысли.

[Practicing AI Research]
Умение делать рисерч — это тренируемая способность. Автор выделяет четыре ключевых навыка, из которых состоит рисерч:
⚫️Отбор идей. Вырабатывание собственного «вкуса», проработка концепций и выбор тем, в которые веришь и которые соответствуют твоим принципам. Автор предпочитает обобщённые идеи, без ухода в излишнюю специфику. Как правило, это оказывается «hot topic», над которой и так всё работают, и ты стараешься сделать лучше остальных.

⚫️Дизайн экспериментов и их реализация. У исследования должен быть чёткий набор Research Questions, на которые в ходе работы будут найдены ответы. Хорошая практика — регулярно обсуждать прогресс с коллегами.

⚫️Работа над статьей. Простым языком изложить суть работы, ключевые результаты, объяснить, почему эта работа важна для сообщества и как применить идеи на практике.

⚫️Максимизация импакта. Журналы, конференции, блогпосты, twitter, подкасты — все инструменты хороши, чтобы «прорекламировать» миру свою работу и показать её значимость.

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

[Dopamine cycles in AI research]
AI-исследователи заканчивают свой день (или неделю) либо в хорошем настроении, либо в плохом — всё зависит от того, сработала ли сегодня гипотеза, в которую ты веришь.
Да — супер, допаминовый скачок.
Нет — фрустрация, уходишь в дебаг и допаминовую просадку.
Так или иначе, ресерч создаёт асимметричные по длительности допаминовые циклы, и нужно иметь навыки саморегуляции, чтобы не отлететь.

[AI research is a max-performance domain]
Что значит «max-performance domain»? Для того чтобы быть топ-исследователем, достаточно выдающихся результатов лишь в одном аспекте своей работы. Обучить лучшую модель или создать прорывной алгоритм — и ты уже востребован, в то время как все смежные компетенции (навыки спикера, разработчика, прохождения кодинг-интервью) не имеют значения и прощаются.
И не обязательно делать прорыв каждый год — раз в несколько лет достаточно, потому что метрика исследователя:
лучшие пять работ (не обязательно научных публикаций) за карьеру, а не средний результат.


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

---

Многие из этих мыслей вдохновлены принципами, озвученными Ричардом Хэммингом в 1986 году. You and Your Research, by Richard Hamming. Рекомендую.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from C++95
#notes_from_underground

Пересматривал видос про коробки от хлопьев любимого блогера детства, решил с ChatGPT сделать свою коробку 🍜

Записки из подполья №2 ✍️

1️⃣ Обзор технических блогов по HFT-конторам 💳
Что пишут в своих блогах компании, которые занимаются HFT + бонус
https://telegra.ph/Obzor-tehnicheskih-blogov-po-HFT-kontoram-06-24

2️⃣ "Нижний интернет" нашей сферы 👨‍🔬
Обзор треш-стримеров и анонимных площадок
https://telegra.ph/Nizhnij-internet-nashej-sfery-06-25
Please open Telegram to view this post
VIEW IN TELEGRAM
minimal vscode: открываем окна

https://www.youtube.com/watch?v=frZkPK_1Ui4

Нет, не от духоты, ее в видео как раз не будет 🌚️️️️
Видео короткое, динамичное, практичное.

Перед тем как учиться пользоваться vscode, необходимо:
1. Её поставить
2. Научиться её открывать
3. Располагать её на рабочем пространстве

В видео поговорили про:
- Brewfile и синхронизацию программ / плагинов
- Hotkey managers на примере https://github.com/koekeishiya/skhd
- Тайловые менеджеры окон: https://github.com/rxhanson/Rectangle
- Красивости вроде https://topnotch.app и https://hazeover.com

Все материалы для всех операционных систем тут: https://github.com/sobolevn/the-best-python-course/blob/main/minimal_vscode/links/1-open-vscode.md

Большое спасибо за такой отклик и поддержку 🧡, видео про отключение лишних панелей навигации уже в работе. Скоро будет!

Обсуждение: какие тайловые менеджеры используете вы?

| Поддержать | YouTube | GitHub | Чат |