На подходе прекрасные трустори о переходе от миддла к сеньору💅

Как я готовился к собеседованию на позицию Senior ML Engineer

Как понять, что твой мидл готов стать сеньором? Гайд для тимлида (и не только)

В чем разница между мидлом и сеньором

Карьерный рост в Data Analytics: какие скиллы нужны для перехода на следующий грейд

@zadachi_ds

#dl #interview

#dl #nlp #interview

#ml #interview

#llm #papers

#llm #ml #systemdesign #petproject

🤩 Как новенький LangExtract от Google может помочь в AI работе с доками, RAG и не только

Неделю назад Google тихо выпустил библиотеку, которая решает боль production LLM систем: как гарантировать, что извлеченные данные действительно есть в источнике, а не выдуманы моделью. Ты задаешь примеры что хочешь извлечь из текста (например, даты и суммы из контракта), LangExtract находит все такие элементы и показывает где именно каждый находится в документе, гарантируя что ничего не выдумано. Мне как раз надо было что-то подобное, я полез изучать, потом залез в исходники и залип.

Ключевая инновация - Source Grounding
Каждое извлечение привязано к точным координатам в тексте. Парсите контракт на 50 страниц? Система не просто скажет "срок оплаты 30 дней", но и покажет exact char positions где это написано. Под капотом - умный fuzzy matching алгоритм, который находит источник даже если LLM слегка перефразировал. То есть да, это как NER только без обучения, и как structured outputs, но с точным и надежным определением координат цитаты.

А еще на основе моих тестов эта штука поразительно хорошо и быстро работает с длинными документами.

Ботанский кусок (разверните кому интересно):

Покопался в исходниках, рассказываю суть.

По сути LangExtract = Few-shot Information Extraction + Structured Outputs + Automatic Source Grounding.

В отличие от простого использования structured outputs, автоматически находит точное местоположение типа {"startpos": 41, "endpos": 57}.

Общий принцип:

Документ → [Chunking] → [LLM + Schema] → [alignment phase] → Результат с позициями

Трехуровневый alignment (exact → case-insensitive → fuzzy) покрывает все основные кейсы, результаты потом валидируются.

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

На входе использует example-driven подход - вместо написания промптов вы предоставляете несколько примеров того, что хотите извлечь. Из этих примеров автоматически генерируется JSON schema для structured output и создается few-shot промпт. Поддержка разных LLM провайдеров (Gemini, OpenAI, Ollama) с оптимизациями под каждый.

А с длинными доками хорошо работает за счет трех элегантных решений:
- Intelligent chunking с сохранением границ предложений (не тупое разбиение по токенам)
- Multi-pass extraction - несколько независимых проходов, каждый может найти что-то новое, результаты консолидируются
- Массивная параллелизация - десятки чанков обрабатываются одновременно

Есть встроенная HTML-визуализация с подсветкой найденных элементов прямо в исходном тексте (показана на видео).

Некоторые альтернативы: Instructor/Marvin/Outlines.

Use кейсы для вдохновления:
- Контракты на 100+ страниц - находит все суммы и сроки с точной ссылкой на цитату, можно легко интегрировать в UI "подсветку" фактов
- Медкарты с записями - извлекаем дозировки лекарств с гарантией и визуальным указанием источника
- Data Science стал еще доступнее: на вход тысячи не структурированный документов, на выход - CSV с нужными колонками и точными координатами откуда взял
- Извлекаете из корпоративной wiki, email, Slack: люди, проекты, технологии, их связи. Строим графы знаний - Profit!

Главное: LangExtract не просто надежно извлекает, но еще и доказывает откуда взял каждый факт.
Двигаемся еще ближе от "LLM как магический черный ящик" к "LLM как надежный production инструмент".

Блогпост | Репа

🔥➕🔁

#python #code

Спустя долгое время отсутствия приношу пост 👀

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

Так вот это довольно легко сделать (по крайней мере на Linux) с помощью дебагера gdb

Делается так:
0. Сохраняем локально файл libpython.py. Это нужно, чтобы в gdb стек и код вокруг отображался "по-питонячему" (иначе это будет малопонятный C++).
- Для этого открываем CPython на гитхабе
- Переключаемся с main ветки на tag с версией питона, которым запущен зависший код
- Скачиваем файл libpython.py (например `wget https://raw.githubusercontent.com/python/cpython/refs/tags/v3.13.5/Tools/gdb/libpython.py`)
1. Подключаемся к зависшему питонячему процессу
sudo gdb -p 68653
2. Подключаем файл
source libpython.py
3. Выбираем нужный поток, если их несколько
info threads - показать все
thread 1 - выбрать первый
4. Смотрим стек
py-bt
5. Смотрим код вокруг
py-list
6. Смотрим переменные
py-locals
7. Двигаемся по стеку выше/ниже
py-up
py-down

Все команды можно посмотреть как раз в файле libpython.py, который мы скачивали на шаге 0

Один-два раз это упражнение делаешь - код болеть не будет! 💪

Sampled Softmax for Large-Scale Retrieval.

В рекомендашках на стадии генерации кандидатов часто используются двухбашенные модели, в которых пользователи и айтемы отдельно кодируются в векторы нейросетевыми «башнями», и затем с помощью скалярного произведения определяется, насколько пользователю релевантен тот или иной айтем. Мы умеем быстро находить для пользователя примерный топ айтемов с максимальным скалярным произведением (например, с помощью HNSW), даже для очень больших каталогов с миллионами айтемов.

У таких моделей должна быть способность глобального сравнения — возможность для пользователя сравнивать между собой «скоры» всевозможных айтемов из каталога. Ранжирующие лоссы, на которые учатся верхние стадии, для обучения нам не подходят — при таком обучении у модели нет цели научиться ранжировать для пользователя все айтемы, ей важно научиться ранжировать только то, что обычно попадает к нему в выдачу. Если YouTube обычно показывает испанцам видео на испанском, а итальянцам на итальянском, то модели не нужно уметь сравнивать видео на испанском с видео на итальянском, и она может «наложить» (англ. folding) векторы айтемов из этих двух групп друг на друга в векторном пространстве.

А вот что нам подходит — это softmax-лосс. Можно сформулировать задачу рекомендации в виде экстремальной классификации, в которой каждому айтему соответствует свой класс (экстремальной — потому что много классов). Если пользователь лайкнул трек, то что это был за трек? Считаем для каждого трека некоторый скор (читай «логит»), затем превращаем скоры в вероятностное распределение, применив softmax. Учим модель максимизировать правдоподобие правильного класса — минимизируем кросс-энтропийную функцию потерь. При таком обучении в саму модель заложено, что мы должны уметь делать глобальное ранжирование между всеми айтемами в каталоге.

У такого лосса есть одна «большая» проблема — чем больше каталог, тем сложнее посчитать сам softmax. В знаменателе есть сумма экспонент от логитов по всему каталогу. Нам в целом не нужно считать сам лосс, важен только градиент, но в градиенте эта сумма тоже присутствует. Чтобы это побороть, можно использовать сэмплирование негативов — вместо суммы скоров по всему каталогу считать её по небольшому сэмплированному подмножеству. Популярные стратегии сэмплирования — равномерное (выбираем айтемы из каталога абсолютно случайно) и униграммное (пропорционально популярности айтема). Частный случай униграммного — in-batch сэмплирование: при обучении нейросетей мы набираем «батчи» из положительных пар (пользователь, айтем), и можно для каждого пользователя из батча использовать в качестве негативов чужие позитивы из этого же батча.

Почему же всё-таки недостаточно простого равномерного сэмплирования? Здесь поможет следующая интуиция: «полный» softmax-лосс неявно занимается майнингом негативов — у айтемов из каталога, которым модель даёт высокий скор, большой вклад в градиент. Это отличительное свойство softmax-а — например, у BPR-лосса, если модель сильно ошибается в каком-то айтеме, его вклад в градиент всё равно сильно ограничен. Поэтому, если мы хотим аппроксимировать softmax-лосс, нам важно сэмплировать как можно больше «сложных, информативных» негативов, в которых модель ошибается и у которых был бы большой вклад в градиент. А равномерное сэмплирование, особенно при больших каталогах, будет давать простые негативы. Добиться хорошего качества с равномерными негативами всё равно можно, но понадобится гораздо большее количество негативов, чем при использовании альтернативных, более «сложных» источников негативов.

А вот при униграммном сэмплировании мы получаем популярные айтемы, которые чуть ли не по определению имеют высокий средний скор у пользователей и поэтому представляют из себя более «сложные» негативы. Но и здесь не без проблем :) Что же идёт не так — я расскажу в следующем посте.

P.S.: это я вас так готовлю к посту про статью, которую у нас приняли на RecSys :) А ещё это небольшое переосмысление прошлого поста на ту же тему. Что-то похожее я рассказываю в рамках лекции про нейросетевой кандген в ШАД.

#recommender #papers

Correcting the LogQ Correction: Revisiting Sampled Softmax for Large-Scale Retrieval.

А вот и наша статья, принятая на RecSys 2025, добралась до arxiv’а! Что мы сделали: улучшили logQ-коррекцию.

Почему это важно: logQ-коррекция активно используется в индустрии для обучения нейросетевых двухбашенных retrieval моделей. Я за свою жизнь в Яндексе неоднократно участвовал в больших и успешных внедрениях нейросетевых кандидатогенераторов, которые не случились бы без logQ-коррекции.

Улучшение связано с тем, как в формуле logQ-коррекции используется положительный айтем (далее именуемый “позитив”). Он появляется в двух местах — и в числителе, и в знаменателе софтмакса. К числителю вопросов нет. А вот в знаменателе есть странности. Например, в исходной статье от Google к позитиву в знаменателе применяется logQ-поправка; а в следующей статье от тех же авторов — уже нет. То есть для сэмплированных негативов в знаменателе logQ-поправка есть, для позитива — нет. А вывод такой формулы нигде не приводится / не обосновывается.

Более того, само использование позитива в знаменателе выглядит сомнительно. Оригинальный вывод формулы, который Bengio проделал в начале нулевых для доисторических языковых моделей, гласит: для оценки знаменателя софтмакса можно насэмплировать айтемы из произвольного распределения Q (обычного называемого proposal distribution) и добавить к ним ту самую “logQ-поправку”. Распределение Q — это как раз и есть то распределение, из которого мы сэмплируем негативы; которое чаще всего является in-batch распределением.

И когда мы рассматриваем конкретный обучающий пример, то есть конкретную пару (user, positive item), и для нее считаем сэмплированный softmax-лосс с logQ-коррекцией, мы не сэмплируем позитив из распределения Q — он приходит к нам детерминированно, с вероятностью 1. А в формуле он используется для Монте-Карло оценки в предположении, что мы сэмплируем его из Q.

Долгое время мы, как и все, просто плыли по течению и использовали logQ-коррекцию в том виде, в каком все ее применяют. Но потом я взялся сделать ту самую лекцию про нейросетевую генерацию кандидатов для ШАДа, в которой в том числе хотел осветить logQ-коррекцию — строго, с математическим выводом. Хотелось также обосновать формулы, использующие позитив в знаменателе, с logQ-поправкой и без.

Когда я в рамках математических выкладок отделил позитив от Монте-Карло сэмплирования, получилась совершенно другая формула! В которой позитива не было в знаменателе софтмакса вообще, но при этом появилось взвешивание сэмплов. Чем меньше модель ошибается на сэмпле (то есть предсказывает большую вероятность позитива), тем меньше вес этого сэмпла.

Мы поставили эксперименты — сначала на своих внутренних больших датасетах, а затем на небольших академических. И подтвердили, что наша формула хорошо работает, причем работает лучше стандартной! На полноценный long paper на RecSys времени не хватило (когда появилось время на написание статьи, до дедлайна было меньше двух недель), поэтому подались на short paper. Статья получила хорошие отзывы и была принята на RecSys, чему мы несказанно рады :)

Ещё хочется немного подсветить остальную ценность статьи. До этого я не видел в академической литературе замеры на публичных датасетах для logQ-коррекции. Мы эти замеры сделали и показали, что популярная в индустрии logQ-коррекция хорошо работает и в академическом сетапе. Кроме того, мы, возможно, первыми на этих датасетах показали пользу от mixed negative sampling (таких замеров я тоже раньше не встречал, но здесь уже меньше уверен).

И последнее — мы сделали две валидации. Было понимание, что без leave-one-out схемы, как бы я ее ни недолюбливал, есть большая вероятность не пройти ревью :) Но делать только leave-one-out валидацию тоже не хотелось. Поэтому сделали также temporal split валидацию. Получилось, что ранжирование моделей c точки зрения качества в этих двух сетапах заметно различается.

Остальные подробности — читайте в статье!