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

Мне очень нравятся собеседования
1. Это способ раздвинуть шоры, очередной раз вспомнить, что не у всех так, как у вас. Очень здорово, когда человек способен интересно рассказать про свой опыт. Ты вспоминаешь, что стек может быть другой, инфраструктура другая, что подходы к решению точно такой же задачи, как у вас, могут отличаться на 180 градусов.
2. Это способ привести свои знания в порядок. Что-то спрашивать можно только если ты сам отлично в этом разбираешься. Даже самые базовые вещи со временем начинают забываться. Период собеседований - это отличный повод вернуть все основы на место.
3. Это способ познакомиться с абсолютно разными людьми. Услышать как они мыслят, какие у них речевые обороты, на чем они делают акцент в своих целях, интересах, методах решения проблем.

Пара правил хорошего (по моему мнению) собеседующего:
1. Понимай, зачем ты задаешь вопрос. Необходимо осознавать, что именно в данный момент ты проверяешь, знания какого аспекта. Говорить люди могут много, особенно по-верхам. И не редка ситуация, что вопрос вроде пройден, а образ собеседуемого не дополнился.
2. Не давай почувствовать собеседнику, что он "не тянет". Если человек на что-то не может ответить - это не повод сказать "ты даже это не знаешь?" или "ну слууушай, это уже совсем база". Вы должны вместе идти по этому пути, даже если человек по итогу вам не подойдет, я считаю своей задачей успеть дать ему дополнительных знаний, подзакрыть его пробелы, чтобы он ушел сильнее, а не убедил себя в своей несостоятельности.
3. Это не экзамен для одного - это встреча, в которой участвуют двое. Если мы требуем от кандидата, чтобы он подготовился, был бодр и включен, значит мы обязаны требовать то же самое и от собеседующего.
4. Хорошо иметь побольше вопросов с открытым ответом. Круты те вопросы, где есть много правильных решений, именно здесь можно увидеть как человек размышляет. Безусловно, есть теория с единственным верным ответом, которая необходима, но нужно помнить, что, при желании, любой стажер способен "вызубрить" архитектуры, метрики и прочее. Я сталкивался множество раз с тем, что я ожидаю ответ один, а кандидат говорит совершенно иное, то, о чем я до этого даже не думал, и если это разумно, то обязательно нужно такое поощрять, а не говорить "нет, думай дальше".
5. Будь пластичнее. Важно иметь план собеседования, список вопросов, но профессионализм ведения интервью заключается в способности сымпровизировать, углубиться в неожиданном месте, подстроиться под собеседника. Ну и конечно не задавайте вопросы списком, здорово, когда они нативно вытекают один из другого, словно вы просто болтаете.

И я не обманываю, сейчас правда идет найм. Если вам было бы интересно присоединиться к нашей ML команде - сейчас открыты две вакансии:
NLP Engineer и CV Engineer.
Пишите мне в личку, буду рад пообщаться!

@lechim_ai

#gpu #cuda

Скучали? А мы-таки собрали пост про неэффективное использование вычислительных ресурсов ⬇️

Если вы хотите выжать максимум из своей GPU, нужно знать, как устроена видеокарта. Если совсем на пальцах, у неё есть:

📌 DRAM — большая, но медленная память. Расположена на отдельном чипе или чипах. В современных GPU объём может достигать 80 ГБ и больше.
📌 Streaming Multiprocessors (SM) — непосредственно вычислительные модули с CUDA и Tensor-ядрами. Позволяют запускать операции параллельно, распределяя пайплайны вычислений между собой.
📌 SRAM — быстрая, но маленькая память (обычно сотни Кб). Находится внутри вычислительных блоков.

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

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

Например, стандартная цепочка PyTorch-вызовов (без TorchDynamo) всегда будет работать так, что будет происходить перегонка байтиков туда-сюда: DRAM-SRAM-DRAM-SRAM-... .

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

📝 Для более тонкого контроля над памятью можно писать кастомные GPU-ядра: с нуля, используя библиотеки CUDA или с помощью Triton.

Что такое Triton? 🛠

Это программный интерфейс, который позволяет писать кастомные GPU-ядра без прямого использования CUDA.

Чем он хорош:

📍Код пишется на некотором сабсете Python, следовательно порог входа не такой высокий, а работает это дело через JIT-компиляцию.
📍Обеспечивает гибкий контроль над памятью и параллелизмом — мы сами решаем, когда ходить в DRAM, а когда не ходить, и имеем больше контроля над тем, как мы будем параллелить вычисления.

Возвращаясь к примеру выше, Triton позволяет реализовать выполнение некоторой последовательности операций без копирования промежуточных результатов в/из DRAM.

Как написать кернел?

Кернел — это функция с декоратором triton.jit. Их главная особенность — маленькие программки, которые могут быть запущены параллельно. Каждая запущенная копия будет иметь свой pid-идентификатор. Можно сделать так, чтобы каждый идентификатор обрабатывал не все данные, а отдельный фрагмент (вспоминаем, что SRAM-то маленький, а ещё нужно как-то уметь в параллелизм между блоками).

Пример кернела из официальной документации.

В кернеле мы используем:

👾 Указатели на входные и выходные данные.
👾 Размер вектора.
👾 Размер блока (Block Size) — количество элементов, которые обрабатываются одним PID-ом.
👾 PID — идентификатор запущенной программки.

Также в примере используют бинарную маску при чтении и записи в DRAM, чтобы не выйти за пределы нужной нам памяти — например, когда размер вектора не кратен параметру block size.

А также, нужно реализовать небольшой враппер для того, чтобы запускать наш кернел — ниже оставлю пример кода 👇

Здесь всё стандартно. Выделяем в DRAM место для выходного тензора, запускаем наш кернел в стольких копиях, сколько нужно для обработки вектора длины N, если каждая копия обработает длину BLOCK_SIZE.

💜 Этот пост написал Макс Афанасьев, лидер DL-команд Точки, инженер-исследователь

Всем привет! А мне сегодня аж 33 года! Из них уже 10 лет в МЛ, а варю его в этом канале уже 3.5 года. Очень рад, что вы остаётесь со мной, и особенно приятно встречать подписчиков на конфах)

В качестве контента сегодня ссылка на прикольный гайд по борьбе с СДВГ. На самом деле мне он кажется подходящим для многих людей, даже без диагноза, особенно раздел Tactics. Вообще там многое напоминает книжки Дорофеева, так что техники проверены мной годами.

Я вот записываю вообще всё, даже если планирую это сделать через 3 секунды. Поверьте, за это время вас могут успеть отвлечь два раза)

Всем хорошего дня и лета! А кто будет в Питере 25 июня, приходите на прикольную дискуссию, поразгоняем про хаос

#Жека

#gan #papers

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

Читать тут: https://t.me/gonzo_ML_podcasts/303

#llm #code #ml #systemdesign

Интересно про то, как построен Курсор

https://newsletter.pragmaticengineer.com/p/cursor

Paywall, но довольно большая часть доступна

#papers #code

alphaxiv.org

сайт - копия архив, но без кожаных умников
находим статью и вместе с роботами читаем/разбираем/пишем отсутствующий код

Пожалуй лучший способ почувствовать себя умнее

Слава роботам!

Недавно увидел хорошие термины про тип работы - deep work vs shallow work.

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

Shallow work, напротив, - это работа урывками, когда часто меняется контекст между задачами и проектами.

Даже хорошо спланированную работу в формате deep work можно легко превратить в shallow work. Достаточно начать реагировать на сообщения в мессенджере от коллег, менеджеров, друзей. Или участвовать в частых митингах.

Вот и получается: вроде день прошёл, а результата ноль.

Мне лично помогает несложное кольцо действий:
1. составить список 2–3 важных дел на день
2. не переключаться на новое дело, пока не закончу первое
3. блоки deep work в календаре, которые отменяют все встречи - они у меня стоят на год вперёд

Так же можно запланировать дела на неделю, добавив в них личные дела. Свой календарь я не разделяю на личный и рабочий.

Лично для вас будет эффективнее и приятнее выполнить от начала до конца одно важное дело, чем ответить всем подряд в мессенджерах, сходить на несколько митингов и при этом задержаться на работе на несколько часов - всё равно без результатов.

#rag #database

HelixDB - это высокопроизводительная графо-векторная база данных с открытым исходным кодом, написанная на Rust, разработанная для приложений RAG и ИИ. Она объединяет хранение графовых и векторных данных, используя LMDB для обеспечения персистентности данных и соответствия ACID.

Код на GitHub

#llm #code

Вышла свежая лекция Andrej Karpathy про Software in the Era of AI

Там много всего интересного - за 40 минут он понятно и образно описывает текущее состояние AI, систем для кодинга и того, куда все это катится. Очень рекомендую к просмотру.

(Это его выступление для той самой школы AI стартапов в Сан-Франциско)

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

"когда я вайб-кожу, то все пучком. Но вот если мне нужно что-то сделать на самом деле..."

("If I'm vibe-coding, it is all nice and great, but if I'm actually trying to get the work done, it's no so great to have an overractive agent doing all this kind of stuff").

В общем, как мы уже обсуждали раньше, вайб-кодинг - вещь прикольная для прототипчиков. Но если нам не играться надо, а работу делать и серьезные проекты пилить, то AI+Coding агентов уже нужно держать на коротком поводке. А для этого - работаем с планами, выдаем им системы для верификации, даем инструкции для использования всего этого.

Cоветую посмотреть: https://www.youtube.com/watch?v=LCEmiRjPEtQ

Ваш, @llm_under_hood 🤗

#llm #ml #systemdesign

Продолжаем серию публикаций по LLM System Design. Сегодня говорим про важность внешних инструментов.

Паттерн 3. Дайте LLM правильные инструменты

Самый частый паттерн применения LLM — модель переводит запросы с человеческого языка в вызов нужных инструментов. Вы просите узнать баланс на карте, LLM отправляет запрос в нужный сервис, указывая идентификатор карты в параметрах. Вы говорите, что хотите найти в данных, LLM пишет SQL-запрос к правильной таблице.

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

В дизайне системы очень удобно считать tool-ом любой другой элемент: внешний код, база данных (RAG), другие LLM и т.д. Вызов инструментов требует правильного заполнения всех аргументов, поэтому крайне удачно, что мы прошли Structured Output в Втором паттерне. Не забывайте его использовать.

Код — ваш лучший инструмент

Код это самый мощный tool, который вы только можете дать LLM (но риски кратно возрастают). LLM может персонально под задачу генерировать программу.

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

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

На этой идеи построена библиотека smalagents от HuggingFace. Технические подробности в статье CodeAct.

Как научить LLM использовать инструменты

От самого простого к самому сложному:

1) Подключиться к MCP-серверу, если такой есть, и взять оттуда этот tool.

2) Самим сделать tool на базе каких-то API (не забываем про разницу MCP и API), напихать все в промпт

3) Самим сделать tool, зафайнтюнить LLM правильно этот tool использовать. Про это есть классическая статья.


Обязательная литература

- Объяснение, почему важно разделять LLM и tools

- Аналогичное правило, но для ИИ агентов

- Пост, чем дизайн tool для LLM отличается от просто API

- Статья, как важно Structured Output для tools

Любые вопросы обязательно пишите в комментарии.

Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.

#llm_system_design