Как Яндекс научил YaGPT пересказывать видео в браузере.

Коллеги по AI цеху выпустили статью на Хабре о том, как они научили YandexGPT пересказывать видео.

Пост интересен не только техническими деталями, но и продуктовыми нюансами, влияющими на user experience.

Что ребята из Яндекса там сделали? На самом деле, у команды уже была модель статейной суммаризации, поэтому взяли то что уже есть, и улучшили. При этом, что интересно, в решении нет никакой мультимодальности, как в LLaVa, напрямую. Для приклада к видео были использованы инструменты перевода звука в текст: ведь в видео есть субтитры, чем не текст? И да, ребята, подумали также.

Для обучения было подготовлено 20 000 хорошо выверенных суммаризаций со спец. форматом: заголовок, тайм-код, краткий пересказ, новый заголовок ,его тайм-код и краткий пересказ и тп. Нужно понимать, что видео бывают разные по длине, но у ребят лучше всего завелось нарезать пересказы частями до 12к символов. Иначе далее появляются глюки.

Помимо этого, важно было исследовать разные подходы к обучению LLM. Авторы остановились на LoRA и SFT с расфризом параметров LLM.

Вот так разработчки и добрались до идеальной формулы: добавляем в видео субтитры, делим их по 12 000 символов и пускаем в модельку. Благо видео вещь более структурная чем текст и тут можно делить субтитры на части без значительных смысловых потерь, деля куски субтитров на независимые друг от друга чанки.

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

#nlp #interview

Каков из тебя Старший Прикладной Ученый в Нвидео
#interview

В журнале “Лиза” сразу после моих любимых рецептов идет секция с опросами. Вот там попался такой, получится ли из тебя Старший Прикладной Ученый. За каждый вопрос можно по баллу. Результат – в конце.

Intro

1. Do you have experience dealing with super-large language models? Do you like do model parallelism at all?
2. Did you work with 70b models or only with 7b and 13b?
3. Do you have production experience with model alignment?
4. Okay, so you're saying you haven't started with DPO and RLHF stuff yet, right? (1 балл – за отриц. ответ)

NLP

5. Can you explain to me how self-attention works?
6. Now the same in mathematical terms
7. Can transformer inference be parallelized?
8. What’s the complexity of the self-attention operation?
9. After the self-attention, what happens in the transformer?
10. How many feed-forward layers are there in the transformer block?
11. What’s the dimension of the feed-forward layer?
12. So internally, it’s super wide. Do you know any reason why people design like that?
13. Do you know this paper where people can edit the transformer memory? Have you heard this?
14. Basically the knowledge is stored in the weights of the transformers, right? So like, for example, the Eiffel Tower is in Paris, right? So this knowledge can be edited. So they find out where the memory located. You know this paper?
15. Have you read about like Hopfield network? (No) Yeah, this is called associative memory. So it's a Hopfield network. It's kind of like an ML, feed-forward network, MLP. Basically, that's where the memory happens. You can store this key value.
16. Have you read the RETRO paper?
17. So have you done anything with RETRO before?
18. Do you know how this RETRO external information is feeding into the language model?
19. Can you explain to me what's the difference between T5 and GPT?
20. How does the encoded information fit into the decoder in T5?
21. So, can you revisit the question about RETRO feeding the retrieved documents into the decoder?

Coding

22. Let me first start with some easy questions. Can you explain to me what's the difference between variables on stack versus variables on heap?
23. It’s about memory allocation. So what's the main difference, how it's stored in memory?
24. So, have you done like programming? Anything apart from Python?
25. In Java memory management, do you know the few generations of the variables in the memory?
26. How does garbage collection work in Java?
27. How does a variable on a stack work?
28. How is it related to the scope of variables, e.g. global and local ones? Where are those allocated in memory?
29. Why does recursion use a stack?

Algorithms

30. (3 балла) Describe a solution to the “8 queens” problem. Describe the pseudocode (no need to write code)
31. (3 балла) What’s the complexity of the algorithm?
32. (3 балла) What’s the classic CS 101 algorithm for this problem?

---

Итого макс 38 баллов.

- Если у тебя 30+ – добро пожаловать в следующий раунд (в котором неизвестно что). Ставь 🤓 к посту, глянем, сколько нас таких
- Если у тебя меньше 30 баллов – ты злобный тупой урод нормис и на Старшего Прикладного Ученого в Нвидео пока не тянешь

пс. К слову, я мог закончить собес сразу после 24-го вопроса.

#llm #prompt

#ml #llm

Коль я уж занимаюсь последнее время LLM, давайте о них и поговорим. Итак, начнем с простых вещей. Много кто пытался вывести "формулу идеального промпта" (ей богу, звучит максимально алхимически, почти "формула философского камня"). В итоге есть множество вариантов, как именно лучше писать промпт. Давайте рассмотрим один из таких вариантов:

1. Задача.
Четкое и детальное описание задачи, которую требуется решить LLM. Самая важная часть, в которой мы описываем, а что же мы хотели от модели. Некорректная постановка задачи приведет к некорректному ответу. 
2. Контекст.
Дополнительный контекст, который может быть важен для задачи. Можно определить, с какой позиции нужно рассматривать вопрос, вносить дополнительные справочные данные или иную важную для получения результата информацию.
Частью контекста может быть т.н. “Персона”, то есть детальное описание, с какой точки зрения смотреть на задачу. 
3. Примеры/Пояснения.
Мы можем привести дополнительные разъяснения о том, как именно мы хотели бы решить задачу. Например, указать, нужно ли нам детальное решение или краткое, должен ли быть тон профессиональным или дружелюбным и т.д.
Отдельно мы можем привести пример (или несколько примеров) того, как должна быть решена задача. Конечно, если такой пример в принципе можно привести.
4. Формат.
В этой части мы можем указать, в какой формате нам нужен ответ. Это должна быть таблица, план решения задачи, работоспособный код на определенном языке? Все это позволяет точнее зафиксировать, как именно модель должна нам ответить.

Некоторые из пунктов дробят на меньшие сущности (например, выделяют "персону/роль" в отдельную сущность). В других материалах дополнительно приводят "важность" каждой составляющей (Задача важнее всего, потом идет контекст, а потом уже примеры/пояснения, описание роли, формат ответа и т.п.). Но в целом все крутится примерно около того же самого.

Получаем, что Промпт = Задача + Контекст + Примеры/Пояснения + Формат итога

Кто такой Engineering Manager (EM) в FAANG?

В предыдущих постах я разобрал, кто такие SWE и PM. В этом после я продолжаю эту серию и рассказываю, кто такой EM.

Многие привыкли, что "менеджер" и "руководитель" -- это синонимы. Руководитель говорит команде, что делать. Однако я рассказывал, что уже Middle инженер может самостоятельно решать любые конкретные задачи, Senior инженер достигать бизнес-целей, а Staff инженер задавать успешную стратегию для команды. Что же остается менеджеру? Давайте разбираться.

Engineering Manager в FAANG -- это инженер, компетентный в построении команды. Он не занимается программными системами, и даже продуктами. Он строит команду, которая строит программные системы и продукты.

Если он работает с людьми, то почему же он -- инженер? В сущности, команда -- это такая же система, как и софт, только работающая на углеводах вместо "сырых" электромагнитных полей, на которых работают компьютеры. У команды есть некий рабочий процесс, в ней есть разные "компоненты", предоставляющие разный "функционал" и имеющие разные "проблемы". Задача менеджера -- динамически перестраивать команду, оптимизируя ее эффективность под текущие (и будущие) цели. Отсюда сразу понятно, почему подавляющее большинство EM в FAANG -- бывшие SWE. По большому счету, научиться достигать целей с помощью людей мало чем отличается от умения достигать целей с помощью программных систем. Людей можно воспринимать как еще один фреймворк, который нужно изучить. Очень сложный фреймворк, но так же и очень мощный.

В FAANG команды не создаются под задачи. Как минимум, команды создается под бизнес-цель. По этой причине Engineering Manager роль начинается с Senior позиции. Менеджер должен уметь достигать бизнес целей, именно под конкретные цели он строит команду. Талантливый менеджер может пойти дальше, и построит команду, которая имеет возможности сверх поставленных целей, и сама задает новую стратегию для огранизации. Построение команды, которая не просто достигает поставленных целей, но и успешно задает стратегию, показывает что менеджер удовлетворяет требованиям на Staff позиции, после чего менеджера повышают в уровне. Очень важно не пропустить, что это не сам менеджер должен задать новую стратегию, а именно построенная им команда.

Есть такой феномен как IC Manager. В Google они называются TLM (Technical Lead Manager). Его компетенции оцениваются по правилам где-то между SWE и EM. Лично я ни разу не видел, чтобы эта модель хорошо работала: она банально вызывает конкуренцию между TLM и SWE одного уровня. И Senior TLM и Senior SWE должны задавать успешную стратегию для повышения до Staff позиции, при этом у TLM есть формальная власть над SWE (как минимум TLM представляет SWE на performance review). В результате SWE просто не может задавать свой курс, и не имеет шанса на повышение. Это корректируется дополнительными политиками, вроде того, что если у Senior TLM появился Staff SWE, то и TLM почти наверняка будет повышен. Это частично работает, но все равно часто вызывает напряжение, так как оба не уверены в добросовестности другого. Начиная с сильного Staff SWE я советую всегда искать команды с EM, а не TLM, а для Senior SWE искать команды с как минимум Staff TLM.

Обучаемые векторы для рекомендательных систем.

Есть конечное множество пользователей и айтемов. Хотим рекомендовать пользователям айтемы.

Пусть для каждого объекта задано векторное представление, при этом предпочтения пользователя u определяются через скалярное произведение <u, i> для любого айтема i. Тогда говорят, что векторы пользователей и айтемов находятся в одном семантическом пространстве, а такую модель называют двухбашенной. Эти векторы еще часто называют эмбеддингами, потому что объекты буквально вкладываются (англ. to embed) в векторное пространство.

Почти в любой нейросети возникают векторы объектов. Иногда это целевая задача - получить эмбеддинги, обладающие определенными полезными свойствами (привет, representation learning). В рекомендашках это тоже актуально; и (1) для кандидатогенерации, которую часто делают на основе эмбеддингов (embedding-based retrieval), и (2) для ранжирования, серьезный вклад в которое вносят нейросетевые признаки.

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

Утверждается, что у такой модели максимальная емкость. Что вообще такое емкость модели (англ. model capacity)? Это способность выражать взаимосвязи, аппроксимировать функции. В терминах двухбашенной модели об этом думать проще: представим, что у нас есть некоторая оптимальная структура семантического пространства (если нас волнует только семантическая близость объектов, то с точностью до поворотов, сдвигов и, возможно, масштабов), которую мы хотим получить.

В теории, двухбашенная модель с обучаемыми векторами может выучить любую структуру семантического пространства. Пусть у нас есть какая-то другая модель (e.g. мешок слов, трансформер, графовые нейросети), тогда можно инициализировать обучаемые эмбеддинги векторами из этой модели. В обратную сторону это не работает - имея набор векторов, не всегда можно так настроить "content-based" модель, чтобы она выдавала нужные векторы (привет, дистилляция).

Почему бы тогда не использовать всегда только обучаемые векторы? Несколько причин:
1. Недостаточно данных. Bias-variance tradeoff гласит, что более сложные модели сильнее переобучаются, hence для них нужно больше данных. Double descent в рекомендашках я пока не наблюдал, поэтому будем считать, что это правда :)
2. Тяжелые хвосты (long tail distributions). Если у вас большая часть объектов мало встречается в данных (т.е. хвост тяжелый), то про них сложновато делать выводы без дополнительной информации (e.g. контента), и тем более сложно выучить хорошие векторные представления.
3. Постоянно появляются новые объекты, поэтому нужна индуктивность - умение работать на объектах, не встречавшихся в обучении. У обучаемых векторов она отсутствует, они трансдуктивны.
4. Нестационарность распределений. Интересы пользователей меняются, содержимое айтемов обновляется, тренды (популярности объектов) эволюционируют. Обучаемые векторы это не учитывают.

Последние два пункта частично лечатся инкрементальным дообучением (получили новые данные - дообучились). Но:
* проблема курицы и яйца - чтобы дообучиться, надо накопить фидбек для новых объектов. Чтобы его накопить, нужно их рекомендовать. Если модель на них не дообучалась, то и рекомендовать их не будет.
* у инкрементального дообучения будет определенная задержка, побороть которую можно только невероятными инфраструктурными усилиями. Пока дообучение не произойдет, качество работы на новых и изменившихся объектах будет плохое.

Что же тогда делать? Вносить индуктивное смещение (англ. inductive bias): анализировать содержимое айтемов, делать нейросетевые энкодеры, добавлять регуляризацию, представлять пользователя через историю взаимодействий, etc. Об индуктивном смещении и как оно помогает бороться со всеми этими проблемами поговорим в другой раз :)

Пример мини-исследования

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

Для начала немного контекста:
Представьте, что вы работаете в e-grocery компании с сотнями магазинов. В этих магазинах есть много разных сотрудников: курьеры, сборщики, директора и тд. Сборщики занимаются тем, что собирают продукты в пакет для каждого заказа, который далее курьеры отвозят до клиентов. Допустим, что когда и сколько сборщиков будет работать решает директор магазина.

1. Постановка вопроса
Продакт приходит к нам и просит понять, насколько эффективно директора выводят на работу сборщиков? Стоит ли нам в будущем взять этот процесс на себя?

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

3. Сбор данных
Собираем данные из хранилища в формате:
день - название магазина - длина смен сборщиков - время затраченное на сборку заказов - утилизация %, где
утилизация = время на сборку заказов / время всей смены

4. Проверка данных на качество
Смотрим распределения метрик визуально и проверяем, нет ли у нас подозрительно низких или высоких значений. И находятся ли средние в интуитивно адекватных диапазонах

5. Анализ и подведение итогов
Получаем среднюю утилизацию в 40%, что нам кажется слишком маленьким значением. Считаем, сколько мы тратим денег на зарплаты/часов сборщиков впустую, с прикидкой что «в идеале» утилизация должна быть 50-60%.

6. Обсуждение итогов
Сходимся с продактом, что 40% правда маловато. Договариваемся отдельно обсудить итоги анализа с «бизнесом» (стейкхолдерами). Держим предварительно в приоритете задачу по тому, чтобы начать планировать смены сборщиков самим без участия директоров.

p.s. настоящие цифры, детали и нюансы были опущены по очевидным причинам

#quant #career

Hard skills in HFT (for software execution devs)

- С++ - потому что большинство HFT фирм используют для low latency именно его;
- template metaprogramming - в HFT используется значительно чаще чем вне, потому что из-за желания срезать каждую возможную микросекунду многое (иногда даже слишком) пишется на шаблонах;
- как работает какая нибудь конкретная биржа, какие у неё feed & transaction протоколы - спецификации обычно опубликованы на сайте биржи;
- как подписаться на market feed через multicast udp (и что делать если начнёшь терять пакеты);
- как быстро читать multicast udp с сетевой карточки через user space networking и построить вокруг этого mainloop (см. Solarflare/EfVi) и понимать почему kernel space networking не подойдёт;
- как быстро собирать order book из market feed;
- как максимально упаковать часто используемые данные в L1 cache, а редкоиспользуемые отложить в сторонку;
- как работает процессор и память (см. WEPSKAM и учебный FPGA);
- как спроектировать торговое приложение, какие в нём должны быть компоненты;
- как написать надёжные автотесты;
- как сделать бизнес-логику по-максимуму независимой от специфики конкретной биржи;
- как присоединить приложение к биржевым сессиям и ввести ограничение на транзакции в секунду;
- как добавить ограничение рисков и гарантировать, что они сработают.

@engineer10x

#recommender #graph