Forwarded from Valuable AI / Валентин Малых
китайские товарищи предложили еще одну новую идею: не считать всю огромную матрицу внимания, а выбрать из нее только важные блоки; это и до них пытались делать, вспомнить хотя бы BigBird, но тут коллеги предложили делать выбор по принципу смеси экспертов, то есть ввести специальный роутер, который будет отправлять запрос в нужный блок (фактически - на сравнение с нужной фразой); на картинке слева показана принципиальная схема работы самого модифицированного внимания, а справа - в контексте всего трансформера; в заключение хочу отметить вкус коллег в плане названия - MoBA (ждем YoBA)
P.S. стоит отметить, что Moonshot сразу выложили код, за что им отдельный лайк от меня
P.S. стоит отметить, что Moonshot сразу выложили код, за что им отдельный лайк от меня
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
Я раcскажу вам о классном
Если у вас в компании есть проблемы с соблюдением стандартов форматирования SQL-кода, и вас бесит
Данный форматер устанавливается очень просто, с помощью команды:
pip install shandy-sqlfmt[jinjafmt]
А чтобы отформатировать код необходимо выполнить ну просто "нереальную
sqlfmt <путь к sql файлу>
Прелести данной фичи:
Мои коллеги накатили данную приблуду на репозиторий во время миграции, ибо когда мы дошли до задачи переписывания кода формирования витрин на DBT, ужаснулись в том плане, что читать этот код, невозможно, пока его не отформатируешь. И чтобы в дальнейшем такого не было, накатили данную приблуду на репу, где данный код хранился.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 5 minutes of data
🚀 PGAI-Vectorizer + SQLAlchemy + LiteLLM: Векторный поиск в PostgreSQL стал простым как никогда
Если вы хотите внедрить векторный поиск в свои проекты, но не готовы разворачивать отдельные сервисы вроде Elasticsearch или Qdrant, то вот хорошая новость. Команда Timescale объединила три мощных инструмента, чтобы вы могли работать с векторными эмбеддингами прямо внутри PostgreSQL. Давайте разберемся, как это работает!
Что в связке?
1. PGAI-Vectorizer
— Расширение для PostgreSQL, которое превращает текст в векторные эмбеддинги напрямую в БД.
— Поддерживает модели из Hugging Face, OpenAI, Anthropic и другие.
— Автоматическое обновление эмбеддингов при изменении данных.
2. SQLAlchemy
— Знакомый ORM для работы с PostgreSQL.
— Позволяет описывать таблицы и векторы как Python-объекты.
3. LiteLLM
— Универсальный интерфейс для 100+ языковых моделей (LLM).
— Единый API для OpenAI, Claude, Cohere и даже локальных моделей (например, Llama 3).
🔧 Как это работает?
1. Генерация эмбеддингов
— Через SQL-запросы или Python-код PGAI-Vectorizer преобразует текст в векторы.
Пример SQL:
2. Интеграция с SQLAlchemy
— Векторы хранятся как специальные типы данных в таблицах.
— Поиск похожих записей через оператор <=> (косинусное сходство).
3. Гибкость моделей через LiteLLM
— Можно легко переключаться между LLM без изменения кода.
— Пример на Python:
🛠 Пример использования: поиск статей по смыслу
1. Создаете таблицу с колонкой для векторов:
2. Генерируете эмбеддинги при добавлении данных:
3. Ищете похожие статьи одним запросом:
💡 Плюсы подхода
✅ Не нужно обслуживать отдельные сервисы (всё в PostgreSQL).
✅ Меньше boilerplate-кода — эмбеддинги генерируются автоматически.
✅ Масштабируемость — TimescaleDB отлично работает с большими объемами данных.
✅ Снижение затрат — можно использовать бесплатные модели из Hugging Face.
🚨 Когда это не подойдет?
— Для high-load проектов с миллиардами векторов (смотрите в сторону специализированных векторных БД).
— Если нужны сложные метрики поиска (например, HNSW-индексы).
@data_whisperer
Если вы хотите внедрить векторный поиск в свои проекты, но не готовы разворачивать отдельные сервисы вроде Elasticsearch или Qdrant, то вот хорошая новость. Команда Timescale объединила три мощных инструмента, чтобы вы могли работать с векторными эмбеддингами прямо внутри PostgreSQL. Давайте разберемся, как это работает!
Что в связке?
1. PGAI-Vectorizer
— Расширение для PostgreSQL, которое превращает текст в векторные эмбеддинги напрямую в БД.
— Поддерживает модели из Hugging Face, OpenAI, Anthropic и другие.
— Автоматическое обновление эмбеддингов при изменении данных.
2. SQLAlchemy
— Знакомый ORM для работы с PostgreSQL.
— Позволяет описывать таблицы и векторы как Python-объекты.
3. LiteLLM
— Универсальный интерфейс для 100+ языковых моделей (LLM).
— Единый API для OpenAI, Claude, Cohere и даже локальных моделей (например, Llama 3).
🔧 Как это работает?
1. Генерация эмбеддингов
— Через SQL-запросы или Python-код PGAI-Vectorizer преобразует текст в векторы.
Пример SQL:
SELECT pgai.embed(
transformer => 'huggingface',
model => 'sentence-transformers/all-MiniLM-L6-v2',
text => 'Ваш текст здесь'
);
2. Интеграция с SQLAlchemy
— Векторы хранятся как специальные типы данных в таблицах.
— Поиск похожих записей через оператор <=> (косинусное сходство).
3. Гибкость моделей через LiteLLM
— Можно легко переключаться между LLM без изменения кода.
— Пример на Python:
from litellm import completion
response = completion(
model="claude-3",
messages=[{"content": "Ваш запрос", "role": "user"}]
)
🛠 Пример использования: поиск статей по смыслу
1. Создаете таблицу с колонкой для векторов:
class Article(Base):
__tablename__ = "articles"
id = Column(Integer, primary_key=True)
content = Column(Vector(384)) # Размерность вектора
2. Генерируете эмбеддинги при добавлении данных:
article = Article(content=pgai.embed("...ваш текст..."))
session.add(article)
3. Ищете похожие статьи одним запросом:
SELECT * FROM articles
ORDER BY content <=> pgai.embed('Искать это')
LIMIT 5;
💡 Плюсы подхода
✅ Не нужно обслуживать отдельные сервисы (всё в PostgreSQL).
✅ Меньше boilerplate-кода — эмбеддинги генерируются автоматически.
✅ Масштабируемость — TimescaleDB отлично работает с большими объемами данных.
✅ Снижение затрат — можно использовать бесплатные модели из Hugging Face.
🚨 Когда это не подойдет?
— Для high-load проектов с миллиардами векторов (смотрите в сторону специализированных векторных БД).
— Если нужны сложные метрики поиска (например, HNSW-индексы).
@data_whisperer
GitHub
GitHub - timescale/pgai: A suite of tools to develop RAG, semantic search, and other AI applications more easily with PostgreSQL
A suite of tools to develop RAG, semantic search, and other AI applications more easily with PostgreSQL - timescale/pgai
Forwarded from Техножрица 👩💻👩🏫👩🔧
Доброе утро, дорогие девочки 💋 и фембойчики 💅. Спешу поделиться радостной новостью: вчера я выложила на архив новый препринт (short paper), в написании которого принимала участие - Quantifying Logical Consistency in Transformers via Query-Key Alignment: https://arxiv.org/abs/2502.17017 .
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Статья посвящена анализу того, как разные головы внимания LLMок реагируют на логические задачки. Главный прием, который в ней используется, изображен на рис. 1 и аналогичен приему из нашей с коллегами статьи про использование Query-Key Alignment для MCQA (часть 1, часть 2). Мы подаем на вход модели текст логической задачки вместе с вариантом ответа "true" и считаем скалярное произведение токена "true" из Query на выбранной голове внимания, на последний токен перед словом "Answer:" из Key на той же голове внимания. Получается одно число. Далее то же самое повторяется для варианта ответа "false". Получается второе число. Если первое число больше второго, то мы считаем, что голова выбрала вариант "true", а если наоборот, то "false" (в некоторых задачах более уместно вместо "true" и "false" использовать "yes" и "no", но принцип остается таким же). Таким образом можно проэкзаменовать каждую голову внимания и посмотреть, насколько хорошо из её query и key извлекаются правильные ответы (условно говоря, насколько хорошо голова "решает" логические задачки).
Задачки различались по степени сложности: во-первых, по количеству логических шагов, которые нужно предпринять для нахождения ответа ("steps" на рис. 2), а во-вторых, по количеству нерелевантных, шумных элементов в условии ("distractors" на рис. 2).
В статье было проанализировано много разных моделей (от 1.5B до 70B), и везде нашлись головы, которые "решают" сложные (5 шагов/5 дистракторов) задачки лучше, чем сама модель (если ответ модели оценивать по логитам, аналогично тому, как это делается в MCQA задачах). Более того, часть таких "хороших" голов, отобранных на валидационной выборке одного датасета, сохраняет высокое качество и на других датасетах, являясь более-менее универсальными. Мы выдвигаем гипотезу, что именно эти головы могут отвечать за логические рассуждения в модели.
Этот феномен аналогичен тому, что происходит в MCQA задачах (см. ссылки на разбор статьи выше): модель находит правильный ответ на задачу/вопрос где-то на промежуточных слоях, но этот ответ, по каким-то причинам, не всегда доходит до финального слоя. При чем, что интересно, чем сложнее задача, тем чаще правильный ответ не доходит до выхода. А это значит, что все рассмотренные модели не полностью раскрывают свой потенциал и имеют пространство для улучшения.
#объяснения_статей
Forwarded from Fley's flow
Давно я ничего не писал – всё не видел достойных поводов для постов, однако сейчас такой появился.
Я сделаю небольшую серию публикаций на тему глобальной оптимизации:
Пример
Представьте, что у вас есть какая-то бизнес- или математическая задача. Например — купить мясо и напитки к столу на фиксированный бюджет. Цель — потратить минимум времени. Зададим переменные и ограничим их диапазон, чтобы совсем с ума не сходить:
x1: Сколько людей мы отправим: от 1 до 4
x2: Каких именно людей мы отправим: пускай будет выборка из 6 человек.
x3: День недели: пятница или суббота
x4: В какое время суток отправлять: с 8 до 16 часов
x5: На какой рынок отправиться: пускай будет 3 варианта наиболее удачных рынков в городе.
Давайте попробуем решить эту задачу, опираясь на жизненный опыт. Я опишу свои мысли, а вы можете прикинуть сами и потом читать дальше.
х2 — кого отправим: здесь нужны люди пунктуальные и желательно с большим опытом в организации таких мероприятий.
х3 — день недели: лучше в пятницу, чем в субботу, очевидно.
х4 — время суток: я бы выбрал 10 утра, потому что в это время уже все, кому надо, на работе, и отправленные на рынок люди уже проснулись и бодрствуют, тормозить не будут.
х5 — рынок: здесь не буду предполагать, но можно учесть местоположение людей, которых отправляем, и взять тот рынок, который по среднему расстоянию будет ближе всего.
Разумеется, это достаточно простая жизненная задача, однако к 20-25 годам у нас уже есть набор знаний и опыта, который позволяет оценить поведение этой функции в зависимости от переменных, и выбрать некоторую субоптимальную комбинацию параметров. Но как, очутившись в мире, где есть только люди, рынки и мясо для шашлыка, такой опыт можно получить и каким образом достичь цели быстрее всего? Перепробовать все комбинации — точно сработает, но долго. Попробовать случайные 5-6 — а достаточно ли это хороший подход?
Задача
Теперь с опорой на пример сформулируем общую задачу: есть функция многих переменных, f(x1, x2, ..., x_n), для которой мы предполагаем существование глобального минимума или максимума — нужно его найти.
Оптимизация гиперпараметров
С помощью примера выше мы показали, что в жизни таких задач очень много — практически каждый процесс можно сформулировать как задачу оптимизации, в том числе и эволюционный (это важное замечание). И раз уж я не владелец кафе а-ля Шашлычный Мир, а CV/ML-инженер, расскажу про реальную задачу, где нам нужна глобальная оптимизация.
Обучаем мы нейросеть, задаем различные гиперпараметры, начиная с оптимизатора, learning rate и batch size, заканчивая аугментациями и регуляризациями и смотрим на точность после обучения. Важно отметить, что в силу невозможности продифференцировать такую функцию, мы имеем более общую задачу и медленную сходимость. Как будем подбирать самую хорошую комбинацию? Жизненный опыт — это хорошо, но его долго получать, нет гарантий, что он верный и сработает как нам надо, а также его не так легко обосновать.
Люди, которые касались этой задачи, сразу же вспомнят про GridSearch – поиск по сетке, где мы задаем для каждого параметра набор значений, которые нужно перебрать каждый с каждым. Однако есть высокая вероятность не попасть даже в хороший локальный максимум. Ну и вспомним RandomSearch – поиск по случайным наборам параметров. Любопытно, что у него даже теоретически доказанная сходимость заметно лучше, чем у поиска по сетке, но он тоже не вызывает чувство спокойствия по поводу обоснованности сделанного выбора.
Как раз о таких методах, которые помогут спать спокойно, в следующих постах и пойдет речь.
#learn #hard #cases
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Knowledge Accumulator
A Conceptual Explanation of Bayesian Hyperparameter Optimization for Machine Learning [2018]
Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:
1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам
Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:
3) Функцию качества очень долго и дорого считать
В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.
Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:
1) Мы пытаемся аппроксимировать распределение
2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции
Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.
Один из вариантов, используемых на практике, выглядит так:
- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание"
- Для оценки
- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.
При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params)
Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.
Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.
@knowledge_accumulator
Неделю назад я писал пост про Evolution Strategies. Напомню его область применения:
1) Есть не очень большое пространство параметров
2) Есть функция качества этих параметров, но нет доступа к каким-либо градиентам
Эта область применения не так уж и редко встречается в реальной жизни, и чаще всего это происходит в контексте оптимизации гиперпараметров. В этом случае появляется ещё одно обстоятельство:
3) Функцию качества очень долго и дорого считать
В данной ситуации мы хотим максимально эффективно использовать этот ресурс, извлекать и переиспользовать максимальное количество информации из её замеров. Стандартный Evolution Strategies в этом плане достаточно туп - каждая итерация алгоритма происходит "с чистого листа", а точки для замера выбираются с помощью добавления шума.
Именно здесь на сцену выходит Bayesian model-based optimization. Это целое семейство методов, но все они работают по примерно одному и тому же принципу:
1) Мы пытаемся аппроксимировать распределение
P(objective | params)2) Мы используем каждое наше измерение для обучения этой аппроксимации
3) Выбор следующих кандидатов происходит по-умному, балансируя между неисследованными областями в пространстве параметров и проверкой тех областей, в которых мы ожидаем получить хорошее значение функции
Исследуя всё больше и больше точек, мы получаем всё более точную аппроксимацию функции, как показано на картинке. Остаётся выбрать, каким образом моделировать распределение и выбирать кандидатов.
Один из вариантов, используемых на практике, выглядит так:
- При выборе следующих кандидатов мы максимизируем нечто похожее на "мат. ожидание"
P(objective | params), но интеграл берётся только по "хорошим" значениям objective - это называется Expected Improvement- Для оценки
P(objective | params) мы формулу Байеса и переходим к моделированию P(params | objective), которое в свою очередь является композицией из двух распределений P(params) - для "хороших" значений objective и для "плохих" - эти распределения называется`L(params) и `G(params).- В пунктах выше я упоминал "хорошие" и "плохие" значения. Порог, который их разделяет, выбирается как квантиль уже собранного нами множества значений objective.
При применении капельки математики получается, что Expected Improvement максимизируется в тех точках, в которых максимизируется` L(params) / G(params)
. Эти точки мы пытаемся найти, сэмплируя много раз из `L(params) и пересчитывая это соотношение. Вся эта схема называется Tree-structured Parzen Estimator.Описанная процедура гораздо хитрее и тяжелее, чем Evolution Strategies, но всё это несопоставимо дешевле и быстрее, чем каждый подсчёт значения Objective(params). Таким образом, метод хорошо подходит для таких ситуаций, как оптимизация гиперпараметров обучения, и используется в качестве одного из основных в библиотеке Hyperopt.
Метод, конечно, не идеален - он не учитывает зависимости параметров между собой. Это может ограничивать область применения и мешать методу работать для оптимизации более запутанных схем. Бесплатные обеды, как обычно, не завезли.
@knowledge_accumulator
Forwarded from Data, Stories and Languages
Ужасы поиска работы от Mimansa Jaiswal
Сегодня в твиттере я увидел весьма интересный тред об опыте поиска работы прошлой осенью от Mimansa Jaiswal. У неё есть PhD в Computer Science, опыт работы стажёром в Facebook AI, Allen и год опыта работы в ещё одной компании. Плюс 10+ опубликованных статей (часть во времена BERT, часто в настоящее время).
И вот она рассказывает, как осенью 2024 искала работу - подавалась в 200 компаний, было ~100 собеседований. Текст очень интересный - про подходы к поиску работы, про различия между стартапами и BigTech и многое другое.
Вот некоторые интересные моменты:
Общее:
• Искала работу связанную с ресерчем - общие применения LLM или работа над SOTA. Чисто инженерные позиции или разработка продуктов типа чат-ботов её не интересовали. Хотелось work-life balance и работа в Seattle или сравнимой локации.
• Основные способы поиска работы: подаваться через сайты компаний напрямую, писать рекрутёрам и hiring manager в LinkedIn, добывать рефералы
• Полно мини хоррор-историй о том, какие бывают общения с компаниями
Стартапы:
• Процессы собеседований сильно разнятся между компаниями. Из необычного: некоторые хотели проводить собеседования при личной стрече (не по созвону), некоторые хотели, чтобы кандидат несколько дней проработал у них (за оплату, конечно) как мини-триал вместо собеседований.
• Даже в таких молодых стартапах обычно было 5-6 раундов собеседований.
• Как можно ожидать, многие стартапы сразу озвучивали ожидания работать 6/7 дней в неделю или 12 часов в день.
• Нередко название позиции намекает на ресерч, а по факту оказывается, что нужна инженерная работа.
• Часто компании прекращают общение между этапами собеседований и перестают отвечать
• Стартапы обычно предлагают 150-250k$ gross в год и 0.2%–0.5% equity.
Unicorns (Anthropic, OpenAI, Scale):
• Дикое количество раундов у Anthropic - 10
• Не было раундов leetcode, часто можно было использовать дополнительные материалы (но без чат-ботов)
BigTech:
• Обычно процесс собеседований идёт 1.5-2.5 месяцев
• В Apple было... 12 раундов, у остальных компаний обычно около 6 +/- 2
• Процессы собесов были прозрачные, интервьюверы были профессиональными
• Некоторые компании всё-таки пропадали посередине общения
• В среднем компании предлагают 350-430k$ gross в год с учётом всех бонусов
Материалы для подготовки
#datascience
Сегодня в твиттере я увидел весьма интересный тред об опыте поиска работы прошлой осенью от Mimansa Jaiswal. У неё есть PhD в Computer Science, опыт работы стажёром в Facebook AI, Allen и год опыта работы в ещё одной компании. Плюс 10+ опубликованных статей (часть во времена BERT, часто в настоящее время).
И вот она рассказывает, как осенью 2024 искала работу - подавалась в 200 компаний, было ~100 собеседований. Текст очень интересный - про подходы к поиску работы, про различия между стартапами и BigTech и многое другое.
Вот некоторые интересные моменты:
Общее:
• Искала работу связанную с ресерчем - общие применения LLM или работа над SOTA. Чисто инженерные позиции или разработка продуктов типа чат-ботов её не интересовали. Хотелось work-life balance и работа в Seattle или сравнимой локации.
• Основные способы поиска работы: подаваться через сайты компаний напрямую, писать рекрутёрам и hiring manager в LinkedIn, добывать рефералы
• Полно мини хоррор-историй о том, какие бывают общения с компаниями
Стартапы:
• Процессы собеседований сильно разнятся между компаниями. Из необычного: некоторые хотели проводить собеседования при личной стрече (не по созвону), некоторые хотели, чтобы кандидат несколько дней проработал у них (за оплату, конечно) как мини-триал вместо собеседований.
• Даже в таких молодых стартапах обычно было 5-6 раундов собеседований.
• Как можно ожидать, многие стартапы сразу озвучивали ожидания работать 6/7 дней в неделю или 12 часов в день.
• Нередко название позиции намекает на ресерч, а по факту оказывается, что нужна инженерная работа.
• Часто компании прекращают общение между этапами собеседований и перестают отвечать
• Стартапы обычно предлагают 150-250k$ gross в год и 0.2%–0.5% equity.
Unicorns (Anthropic, OpenAI, Scale):
• Дикое количество раундов у Anthropic - 10
• Не было раундов leetcode, часто можно было использовать дополнительные материалы (но без чат-ботов)
BigTech:
• Обычно процесс собеседований идёт 1.5-2.5 месяцев
• В Apple было... 12 раундов, у остальных компаний обычно около 6 +/- 2
• Процессы собесов были прозрачные, интервьюверы были профессиональными
• Некоторые компании всё-таки пропадали посередине общения
• В среднем компании предлагают 350-430k$ gross в год с учётом всех бонусов
Материалы для подготовки
#datascience
X (formerly Twitter)
Mimansa Jaiswal (@MimansaJ) on X
I interviewed for LLM/ML research scientist/engineering positions last Fall. Over 200 applications, 100 interviews, many rejections & some offers later, I decided to write the process down, along with the resources I used.
Links to the process & resources…
Links to the process & resources…
Forwarded from epsilon correct
Claude Code
Вчера Antropic представили обновлённую модельку Sonnet 3.7 и вместе с ней локального агента Claude Code. Вместе с обновлением, которое значительно подняло метрики по выполнению кода, получилась пушка для как минимум хобби-разработчиков.
Агент работает по API, час работы выходит примерно 10-20$. Агент работает на локальной машине через свой терминал, запуская команды на локальной машине. За полтора часа работы у меня получилось "написать" ~5k строк C++ кода для системы быстрого построения графов при помощи locality-sensitive hashing проекций. Ничего сложного, но время разработки существенно скоратилось, а скаффолдинг можно и поправить.
За весь час я вообще не редактировал код, а давал только общие указания (напиши бенчмарк, напиши тесты). В результате получилась система, которая вроде бы даже работет – агент сам старается всё тестировать и себя проверять. В результате получилось написать то, на что у меня бы ушло недели две работы, да ещё и C++ вышел довольно читаемым.
Будущее, получается, уже совсем рядом – нужно только отстёгивать $20/час за такое удовольствие.
Вчера Antropic представили обновлённую модельку Sonnet 3.7 и вместе с ней локального агента Claude Code. Вместе с обновлением, которое значительно подняло метрики по выполнению кода, получилась пушка для как минимум хобби-разработчиков.
Агент работает по API, час работы выходит примерно 10-20$. Агент работает на локальной машине через свой терминал, запуская команды на локальной машине. За полтора часа работы у меня получилось "написать" ~5k строк C++ кода для системы быстрого построения графов при помощи locality-sensitive hashing проекций. Ничего сложного, но время разработки существенно скоратилось, а скаффолдинг можно и поправить.
За весь час я вообще не редактировал код, а давал только общие указания (напиши бенчмарк, напиши тесты). В результате получилась система, которая вроде бы даже работет – агент сам старается всё тестировать и себя проверять. В результате получилось написать то, на что у меня бы ушло недели две работы, да ещё и C++ вышел довольно читаемым.
Будущее, получается, уже совсем рядом – нужно только отстёгивать $20/час за такое удовольствие.
Forwarded from ML Underhood
YandexGPT 5 уже в опенсорсе и Алисе
Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.
Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.
YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.
На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).
На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.
По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.
Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!
ML Underhood
Сегодня Яндекс показал миру новое поколение больших языковых моделей — YandexGPT 5. Старшая модель YandexGPT 5 Pro доступна в чате с Алисой и Yandex Cloud через API. Ну а претрейн-версия младшей модели YandexGPT 5 Lite Pretrain — уже лежит на Hugging Face.
Все подробности о процессе обучения можно прочитать в статье на Хабре. А в этом посте — главные факты о свежей опенсорсной модели Яндекса.
YandexGPT 5 Lite Pretrain — модель на 8 миллиардов параметров с длиной контекста 32 тысячи токенов. Претрейн проходил в два этапа: сначала модель обучили на 15 триллионах токенов текста на русском и английском языках, а потом использовали 320 миллиардов токенов высококачественных данных, включая образовательный контент.
На первом этапе датасет больше чем на половину состоял из веб-документов, остальное — код, математика и специфичные данные. Под последними подразумеваются синтетика (сгенерированные YandexGPT 4 вопросы на основе проверенных источников) и внутренние наработки компании (например, внутренняя база Яндекса Fact Snippet и новый корпус данных Переводчика).
На втором этапе датасет на четверть состоял из веб-страниц и почти в равных пропорциях содержал математику, код и образовательные данные. Также была небольшая часть аугментаций фактовых документов, другой синтетики и датасетов сервисов.
По сравнению с моделью предыдущего поколения, YandexGPT 4 Lite Pretrain, новая модель показывает ощутимый рост качества в решении математических задач и написании кода. А в сравнении с зарубежными аналогами, такими как LLaMa3.1-8B и Qwen-2.5-7B-base, она лидирует почти во всех типах задач.
Ещё раз приглашаем пощупать модель, почитать статью на Хабре с деталями обучения и не забыть поделиться впечатлениями в комментариях!
ML Underhood
Forwarded from Quant Valerian
Очередная итерация по повышению точности прогнозирования сроков проектов 🤓
В этой работе нами было показано
В какой-то раз, похоже, придется реально статью уже писать 😁
КОРОЧЕ, опять Канеманн меня вдохновил на идею. В главе «Взгляд извне» он рассказывает, что они с коллегами собрались написать учебник. Попланировали, поприкидывали, написали несколько глав.
❗️ВНИМАНИЕ!❗️Планинг покер!❗️ Канеманн попросил каждого участника независимо оценить срок, в который они закончат книгу. В среднем они оценили срок в два года.
А потом они спросили одного из членов группы, специалиста по спецкурсам, как исторически справлялись другие группы?💡
Он ответил, что в среднем книгу такого объема пишут минимум за семь лет, но не больше, чем за десять. Ещё он сказал, что их группа несколько слабее среднего по уровню подготовки и ресурсов.
Услышав это, они погрустнели.
И забили хер на эту информацию! 😁 В итоге, книгу они писали ещё восемь лет с того эпизода.😱
Что с этим делать?
Я уже рассказывал, что мы пользуемся статистикой. Кратко🤡 напомню:
1. Собираем диаграмму Гантта (там нарезано на MOVE a la стори, других задач там нет, даже самое мелкое внесено через MOVE) 😋
2. Оцениваем стори маечно (совсем мелочь / что-то невообразимо большое / всё остальное) 📏
3. Смотрим цикл-тайм (на самом деле lead time ) диаграммы в разрезе этих размеров (медианы и 85%%)👩🔬
4. Выделяем критический путь в Гантте (с учетом ресурсов) ☢️
5. Для критического пути считаем медиану (как сумму медиан задач) и 85%% (как сумму 85%%), вообще говоря, так нельзя делать математически, но нам для примерности сойдет (распределения там логнормальные примерно, я проверял на разных командах из разных частей компании) 🧮
6. Теперь мы знаем, когда закончим с вероятностью 50%, когда с вероятностью 85% — скорее всего где-то между этими значениями и получится 🤞
7*. Не надо закладывать никакие буферы, они учтены в статистике 🤌
Это работает, мы пробовали. Но не так хорошо, как на бумаге. Потому что люди (ну мы) туповаты 🤤 и, например, на старте проекта забывают, не учитывают какой-то кусок работы. Или приходит какой-нибудь аудитор/регулятор/юрист🤵🏼♂️ и наваливает вам 💩 еще обязательного в скоуп.
!!!НОВАЯ ИНФОРМАЦИЯ!!! 🎉
Поэтому предлагается ко взгляду извне (метод выше) добавить ещё субъективщины. И важно, что я говорю не о том, что мы ко всем проектам просто будем докидывать какой-то одинаковый (в абсолютах или процентах) запас. А о том, что у нас есть:
1. Чуйка (aka интуиция aka насмотренность) 🐕
2. Осознанное знание, как шли какие-то похожие проекты 👴🏻
И вот тут уже, имея опору в виде объективной априорной оценки, стоит опросить членов команды, что они думают о сроках. И эти данные использовать, как поправку. Конкретную методику я ещё не пробовал, поэтому мне нечего вам посоветовать. 🌝 Пока!
Из этой истории, btw, можно сделать вывод, что не работают не только стори поинты, но и планинг покер. Хотя для взвешивания быка 🐂 вроде работает. Разница в том, что при планировании работы, мы оцениваем себя, а от веса быка нам ни холодно, ни жарко.
В какой-то раз, похоже, придется реально статью уже писать 😁
КОРОЧЕ, опять Канеманн меня вдохновил на идею. В главе «Взгляд извне» он рассказывает, что они с коллегами собрались написать учебник. Попланировали, поприкидывали, написали несколько глав.
❗️ВНИМАНИЕ!❗️Планинг покер!❗️ Канеманн попросил каждого участника независимо оценить срок, в который они закончат книгу. В среднем они оценили срок в два года.
А потом они спросили одного из членов группы, специалиста по спецкурсам, как исторически справлялись другие группы?💡
Он ответил, что в среднем книгу такого объема пишут минимум за семь лет, но не больше, чем за десять. Ещё он сказал, что их группа несколько слабее среднего по уровню подготовки и ресурсов.
Услышав это, они погрустнели.
И забили хер на эту информацию! 😁 В итоге, книгу они писали ещё восемь лет с того эпизода.😱
Что с этим делать?
Я уже рассказывал, что мы пользуемся статистикой. Кратко
1. Собираем диаграмму Гантта (там нарезано на MOVE a la стори, других задач там нет, даже самое мелкое внесено через MOVE) 😋
2. Оцениваем стори маечно (совсем мелочь / что-то невообразимо большое / всё остальное) 📏
3. Смотрим цикл-тайм (
4. Выделяем критический путь в Гантте (с учетом ресурсов) ☢️
5. Для критического пути считаем медиану (как сумму медиан задач) и 85%% (как сумму 85%%), вообще говоря, так нельзя делать математически, но нам для примерности сойдет (распределения там логнормальные примерно, я проверял на разных командах из разных частей компании) 🧮
6. Теперь мы знаем, когда закончим с вероятностью 50%, когда с вероятностью 85% — скорее всего где-то между этими значениями и получится 🤞
7*. Не надо закладывать никакие буферы, они учтены в статистике 🤌
Это работает, мы пробовали. Но не так хорошо, как на бумаге. Потому что люди (ну мы) туповаты 🤤 и, например, на старте проекта забывают, не учитывают какой-то кусок работы. Или приходит какой-нибудь аудитор/регулятор/юрист🤵🏼♂️ и наваливает вам 💩 еще обязательного в скоуп.
!!!НОВАЯ ИНФОРМАЦИЯ!!! 🎉
Поэтому предлагается ко взгляду извне (метод выше) добавить ещё субъективщины. И важно, что я говорю не о том, что мы ко всем проектам просто будем докидывать какой-то одинаковый (в абсолютах или процентах) запас. А о том, что у нас есть:
1. Чуйка (aka интуиция aka насмотренность) 🐕
2. Осознанное знание, как шли какие-то похожие проекты 👴🏻
И вот тут уже, имея опору в виде объективной априорной оценки, стоит опросить членов команды, что они думают о сроках. И эти данные использовать, как поправку. Конкретную методику я ещё не пробовал, поэтому мне нечего вам посоветовать. 🌝 Пока!
Из этой истории, btw, можно сделать вывод, что не работают не только стори поинты, но и планинг покер. Хотя для взвешивания быка 🐂 вроде работает. Разница в том, что при планировании работы, мы оцениваем себя, а от веса быка нам ни холодно, ни жарко.
tenchat.ru
MOVE как атомарная единица бизнес-ценности — Олег Лыков на TenChat.ru
Целевой пакет/объем работ также является единицей обязательств.
В #Канбан-доске управления портфелем проектов буфер ограничения в потоке работ представлен колонкой "Принято".
Обязательства, которые попадают в колонку "Принято", являются именно такими: они…
В #Канбан-доске управления портфелем проектов буфер ограничения в потоке работ представлен колонкой "Принято".
Обязательства, которые попадают в колонку "Принято", являются именно такими: они…