Research Is Not Engineering at a Slower Speed. https://voiceinthemachine.com/2026/06/10/research-is-not-engineering-at-a-slower-speed/ Я когда-то уже писал пост про то, чем занималась моя R&D команда, а тут вышел довольно интересный write up про различия между ресерчем, R&D и продуктовой разработкой от очень опытного чувака (сам Ян Лекун его рекомендует). Tldr такой, что в ресерче и продуктовой разработке все просто и понятно (с точки зрения ролей, системы оценивания и тд), а в R&D — наоборот. И что компании часто смешивают внутри R&D кучу всякой деятельности. У меня ровно так и было — команда одновременно делала: * и ресерч — копание в статьях, создание новых моделей и архитектур; была наша собственная амбиция догнать и перегнать дипмайнд по части рекомендашек * и довольно большой объем продуктовой разработки — копание в конкретных продуктовых доменах, активное участие в доведении моделей до прода, много внедрений каждое полугодие * и строила инфру — инструменты для работы с данными, обучения и внедрения моделей В статье также много места посвящено тому, где компании часто спотыкаются: 1. Оценивают ресерчеров по инженерным метрикам 2. Называют инженерную деятельность прорывным ресерчем 3. Теряют тот ресерч, который зародился сам по себе и не вписывается в рамки существующих процессов Со всеми пунктами тоже согласен, видел похожее на практике. Чтобы был сильный ресерч, нужны соответствующие люди, с нужными навыками и опытом. Все эти три пункта мешают найму/росту таких людей; скорее их отталкивают. До сих пор довольно много про это думаю в контексте рексистем — как правильно организовать такую команду, как её правильно оценивать, как найти/взрастить нужных людей, органично интегрироваться в структуру большой организации. Мыслей и идей за последний год накопилось много, надеюсь, доведется их как-нибудь реализовать.

Нейросети превратили найм в лотерею 🎰 И дело не в том, что LLM помогают проходить собесы. 🪨 HackerRank выложили в открытый доступ систему для оценки резюме при помощи ИИ. Инструмент стал невероятно популярным среди рекрутеров. Программа парсит файлы и скармливает данные языковой модели для выставления баллов резюме. Учитываются навыки, опыт работы и личные проекты на GitHub. Звучит как отличная автоматизация скучной рутины. 👍 Однако, один разработчик решил проверить систему и прогнал своё резюме несколько раз подряд. Результаты оказались пугающими. Совершенно идентичный файл получал оценки от 74 до 90+ баллов. 🚬 При проходном пороге в 85 баллов кандидат получает отказ просто по воле случая. Модель стабильно распознаёт базовые навыки, но при попытке оценить сложность проектов начинает выдавать случайные числа и каждый раз генерирует абсолютно разные вердикты. Самая большая проблема кроется в оценке профессионального стажа. Запрос для этого раздела состоит всего из пары строк без подробных критериев.😮‍💨 В итоге студент с одной стажировкой и опытный архитектор получают одинаковый максимальный балл. 😐 В чем может быть причина? Поммимо того, что над нормально писать критерии в промптах, есть ряд инженерных факторов о которых вы должны помнить, если делаете такое решение. Если бы мы говорили о classic ML моделях, я бы сказал - бегите глупцы фиксите seed'цы (random states).  Но тк мы работаем с ядром на LMках, придётся следить за параметрами генерации в лице температуры, тк она влияет на креатив. Также нужно следить за тем, что контекст чётко обнуляется, ведь генерация зависит в тч от накопленгого контекста. Те для каждого прогона, каждого резюме нужно "забывать" прошлые прогоны. Однако даже имея Т=0 и фиксу по контексту. Придётся следить и принимать: 1. Non-determinism в LLM - даже при temperature=0, многие современные модели (особенно с speculative decoding, batching, и т.д.) могут давать немного разные результаты. 2. Parsing inconsistency. PDF/DOCX парсинг может давать разные результаты при каждом чтении, особенно если используется OCR или layout analysis. 3. Tool calling / Function calling. Если модель использует function calling для выставления оценок, структура вызова может варьироваться. 4. Batch processing, если резюме обрабатывается батчами с другими, контекст соседних документов может влиять. 5. Floating point non-determinism - на GPU операции могут быть недетерминированными из-за parallel reductions... Да, не легка жизнь AI-dev и AI-engineer, столько нюансов. 📝 P. S. Ещё ссылки на событие. Трек в реддит тут. Блог от HackerRank тут. Читаем, делаем выводы и stay tuned 🦾