Интересное что-то
517 subscribers
2.72K photos
253 videos
139 files
4.52K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Прочёл тут на досуге «PostgreSQL 17 QuickStart Pro» Tessa Vorin.

Сэкономлю вам время — не читайте это, какая-то странная петрушка, как набор повторяющихся статей. Должно быть, снова ChatGPT постарался.

Если вам интересно, что можно почитать по PostgreSQL:

PostgreSQL. Основы языка SQL. Моргунов.
Отличная книга по SQL в реализации постгреса, и для новичков, и для тех, кто переходит с других БД. Если вы новичок и она покажется сложной, начните с другой книги — «SQL Быстрое погружение», Уолтер Шилдс.

Изучаем PostgreSQL 10. Салахалдин Джуба, Андрей Волков.
Отличный материал по использованию PostgreSQL, балансирующий материал разных тем — здесь есть и SQL, причём некоторые показанные особенности были для меня неизвестны, есть и вопросы настройки производительности PostgreSQL, и вопросы масштабирования СУБД.

PostgreSQL 11. Мастерство разработки. Ганс-Юрген Шёниг.
Материал не без огрехов, но мне был полезен. Описание индексов, транзакций и некоторых возможностей SQL, о которых до этой книги не знал.

Оптимизация запросов в PostgreSQL. Домбровская Г., Новиков Б., Бейликова А.
Кайфовейшая книга, которую крайне рекомендую всем, кто использует PostgreSQL.

Если интересно, как внутри работает PostgreSQL, можно почитать «PostgreSQL 17 изнутри», Рогов Е. В. Для практической работы разработчика это не будет сильно полезно, но для админа или просто интересующегося — вполне.

И также могу рекомендовать полистать «Антипаттерны SQL», Билл Карвин.

А если хотите не только почитать, но и от души попрактиковаться, приходите на курс.
Я принес. Курсы технических лекций на ютубе

В последнее время нечасто приношу вам техническое, но в моих закромах и такое имеется. Вот решил с вами сегодня поделиться тремя плейлистами.

1. Курс от Т-Банка про SRE https://www.youtube.com/playlist?list=PLjCCarnDJNstX36A6Cw_YD28thNFev1op
Мониторинг, SLI, SLO, SLA, постмортемы, отказоустойчивость, тестирование, причины и устранение сбоев и всё подобное.
2. Курс лекций в МФТИ от Олега Бунина про хайлоад и систем дизайн https://www.youtube.com/playlist?list=PL4_hYwCyhAva6-f-YxobKju-6ltmn-jNC (утащил у товарища Quant Valerian)
Вся классика: сбор требований, кеши, очереди, репликация, шардирование и т.д.
3. Вечерняя школа Слёрм по Кубернетес https://www.youtube.com/playlist?list=PL8D2P0ruohOA4Y9LQoTttfSgsRwUGWpu6
Курс лекций старый, но когда-то он мне хорошо помог понять, что же в этих ваших кубернетесах происходит. Не готов отвечать за его 146% актуальность сегодняшнему дню. Если у вас есть про это мнение, то приходите, пожалуйста, в комменты и расскажите свои рекомендации.
wemake-python-styleguide@1.1.0

Вышла новая версия самого строго линтера для питона. Теперь еще строже!

Главная фича релиза: wps explain CLI, которая позволяет видеть вывод информации: почему что-то запрещено, и как такое исправить.

А так же несколько новых правил:
- WPS476 не дает использовать await в for (потому что вы скорее всего хотите использовать asyncio.gather, чтобы добиться асинхронности)
- WPS477 запрещает сложную комбинацию TypeVarTuple рядом с TypeVar с дефолтным значением: class Class[T=int, *Ts=*tuple[int, ...]]:

Ну и много разных багов поправили, куда без них.
Полный список изменений: https://github.com/wemake-services/wemake-python-styleguide/releases/tag/1.1.0

Большое спасибо участникам нашего чата за PRы, они затащили релиз 🧡
Обсуждение: каких правил в wemake-python-styleguide вам не хватает? Какие душат вас сильнее всего? Что можно улучшить?

| Поддержать | YouTube | GitHub | Чат |
Forwarded from Душный NLP
Метод борьбы с likelihood displacement в DPO

Датасет для Direct Preference Optimization (DPO) состоит из инструкции, а также двух ответов: негативного — его хотим разучить — и позитивного, который мы хотим чаще получать. Likelihood displacement — это явление, при котором модель разучивает оба варианта. О методе преодоления этой проблемы сегодняшняя статья.

В своей работе авторы использовали датасет Persona, промпты в котором сформулированны как вопросы вида «Мог бы ты сказать следующее:...» (“Is the following statement something you would say? [STATEMENT]”). То есть модели нужно было согласиться или не согласиться с утверждением, ответив «да», «нет», «никогда» или «возможно». Эксперименты показали, что при попытках научить модель отвечать отрицательно, но не категорично («никогда» считался негативным вариантом на DPO, а «нет» — позитивным), вероятность токена «да» становится больше вероятности «нет». Подобное происходит только тогда, когда оба типа ответов похожи (изображение 1).

Авторы считают, что likelihood displacement происходит из-за анэмбеддинг-геометрии токенов. Анэмбеддинг-матрица позитивного и негативного токенов — разница между Wy+ и Wy- — содержит в себе большую компоненту, ортогональную позитивному ответу, по которой можно выучить даже противоположный ответ.

Справиться с этой проблемой авторы предлагают с помощью метрики для оценки похожих ответов. Чтобы её вывести, нужно взять суммы эмбеддингов всех токенов в позитивном ответе и негативном ответе, посчитать их скалярное произведение, а затем вычесть норму позитивного ответа. Эта метрика зависит от длины ответов, поэтому авторы предлагают делить скалярное произведение на произведение длин позитивных и негативных ответов, а норму — на квадрат длины позитивных ответов (изображение 2).

С помощью метрики, которую назвали centered hidden embedding similarity (CHES), отфильтровали выборку ответов из датасета. Для эксперимента использовали SORRY-bench, призванный научить модель отказывать пользователю в исполнении неэтичных, токсичных или преступных запросов. Использование CHES показало хорошие результаты (голубой столбец на графике), однако после фильтрации в выборке осталось всего 5% сэмплов. Кроме того, модели в сравнении обучались не одинаковое количество шагов, что могло повлиять на результаты тестов.

Разбор подготовил Карим Галлямов

Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
#interview

Спорный контент, но мб кому будет интересно
🚀 Как на собеседовании оценить навыки кандидата в использовании языковых моделей в рабочих процессах? 🧠

С развитием ИИ умение применять языковые модели (LLM) в рабочих процессах — это суперсила. Но как проверить это у кандидата?

Делюсь чек-листом с упором на офисные задачи и кодирование!

Какими навыками должен обладать интервьюер?
1. Понимание прикладных сценариев LLM: Знание, как модели используют для автоматизации рутинных задач, анализа данных, генерации текстов и помощи в разработке.
2. Практика работы с инструментами: Опыт в использовании веб версий GigaChat, ChatGPT, Gemini, Claude или API (например, OpenAI).
3. Критическое мышление: Умение оценить, как кандидат исправляет ошибки в ответах модели или адаптирует её под конкретные задачи.
4. Этика и безопасность: Понимание, как избежать утечек данных и предвзятости в результатах.

Чек-лист для оценки на собеседовании
Базовые знания
- Объясняет, что такое промпт-инжиниринг и как он влияет на результат.
- Знает, как работают контекстные окна, параметры генерации (например, «temperature»), и токенизация текста. Проверьте, понимает ли кандидат, в чем смысл вопросов "сколько букв r в слове "strawberry" или "сколько букв е в слове "длинношеее".

Офисные задачи
- Задача 1: Написать промпт для автоматизации ответов на типовые email-письма (например, обработка жалоб или запросов).
- Задача 2: Создать шаблон отчёта на основе сырых данных (например, превратить таблицу с цифрами в аналитическую сводку).
- Задача 3: Оптимизировать запрос, чтобы модель генерировала краткие тезисы из длинных документов.

Кодирование
- Задача 1: Попросить написать промпт для генерации SQL-запроса или Python-скрипта под конкретную задачу (например, парсинг данных).
- Задача 2: Исправить ошибку в коде, который выдала модель (например, неработающий API-вызов).
- Задача 3: Объяснить, как LLM может помочь в документировании кода или рефакторинге.

Креативность
- Предлагает, как внедрить LLM в текущие процессы компании:
— Автоматизация создания презентаций,
— Анализ обратной связи клиентов из чатов,
— Генерация идей для контента или A/B-тестов.

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

💡 Совет: Давайте кандидату реальные кейсы из Вашей компании. Например:
> «Как бы вы использовали LLM, чтобы сократить время подготовки еженедельных отчетов для отдела продаж?»
> «Как интегрировать модель в наш код для автоматического тестирования?»

🔥 Итог: Сильный кандидат не просто знает про ChatGPT, GigaChat или Mistral — он видит, как встроить ИИ в рутину, чтобы команда работала быстрее.
А Ваш интервьюер сможет это проверить?

Делюсь этим чек-листом — сохраняйте себе и внедряйте при найме! 💪

https://t.me/semasci
Вопросы про джоины:

Буду делать серию постов про самые популярные вопросы по sql секции.
Я думаю, на любом собесе будут вопросы про джоины. Давайте разберем популярные вопросы/задачи:

1) Минимальное и максимальное количество строк в результате джоинов.

Допустим левая таблица t1 (поле id) – 100 строк, правая таблица t2 (id) – 10 строк

inner join:
Min – 0 строк. Если никаких пересечений нет, в двух таблицах нет одинаковых id.
Max – 1000 строк. Если в двух таблицах только одно значение (например, 1). Просто делаем перемножение.

left join:
Min – 100 строк. Если никаких пересечений нет, в результате будут все значения из левой таблицы.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

right join:
Min – 10 строк. Если никаких пересечений нет, в результате будут все значения из правой таблицы
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

full join:
Min – 100 строк. Вот этот момент важно понять, на нем часто допускают ошибки. Минимальное количество при full join будет – количество строк из большей таблицы. Например, в левой таблице значения от 1 до 100, а в правой от 1 до 10.
Max – 1000 строк. Если в двух таблицах только одно значение. Делаем перемножение.

cross join:
Min и Max – 1000 строк. Делаем перемножение.

2) Сколько строк вернет операция FULL JOIN, если известно следующее:
INNER JOIN - 6 строк
LEFT JOIN - 10 строк
RIGHT JOIN - 12 строк

Давайте попробуем ее решить без запоминаний и просто понять.
Если вспомнить круги Эйлера (о их корректности будет отдельный пост):
FULL JOIN – это левая непересекающаяся часть + средняя пересекающаяся часть + правая непересекающаяся часть. Просуммируем эти три части:
FULL JOIN = (LEFT JOIN - INNER JOIN) + (INNER JOIN) + (RIGHT JOIN - INNER JOIN)
FULL JOIN = (10 - 6) + (6) + (12-6)
FULL JOIN = 16

Также если раскрыть скобки, то можно понять, что по сути
FULL JOIN = (RIGHT JOIN) + (LEFT JOIN) – (INNER JOIN) = 10 + 12 – 6 = 16


3) Заполнение результата после всех видов джоинов.
Такую задачу тоже часто дают, здесь важно не запутаться. Я приложил скрин с результатами джоинов, внимательно изучите. Особенно обратите внимание на результат соединения дублей и null-ов.

Расскажите какие у вас были интересные вопросы про джоины: 💭


#Вопросы_с_собесов
Forwarded from DevFM
Diagrams

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

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

#tools
#rl #papers

Смотрели на 100 примерах🤦🏼‍♀️
Дамы и господа, выдыхаем: RL всё таки не работает.

Те, кто со мной общаются, знают, что я достаточно скептически отношусь к GRPO и test time scaling прорыву. Когда-то, я прочитал офигенный блогпост с громким названием "There May Not be Aha Moment in R1-Zero-like Training", где авторы попытались критически посмотреть на обучение ризонеров на базе квенов и у них получился неожиданный результат: у квенов aha moment и селф рефлексия возникает на нулевой эпохе обучения — то есть в базовой модели. Сейчас вышла полная статья (правда, как я понял, выложена она в репозитории, а не на архиве или конфе), где более полно раскрываются эти файндинги.

Существующие имплементации GRPO (от HF и от Unsloth — не уверен, что они разные, но вроде разные), используют один и тот же системный промпт от R1 при обучении. Авторы задают вопрос: а точно ли для моделей, на которых хотят воспроизвести aha moment, выбираются правильные промпты? И действительно: оказывается, что если вообще не использовать чат темплейт у базовых моделей (qwen-2.5), то они уже могут работать в чат режиме. Видимо, в претрейн уже подмешивали вопросно-ответные датасеты, например, на математику и модель генерализовалась. При этом, они рисуют ещё более интересную картинку: Qwen-2.5-Math модели без системного промпта работают в полтора раза лучше, чем фью шот на датасетах с математикой. На Deepseek V3 это не воспроизвелось, там темплейт помогает гораздо сильнее.

Затем авторы развернули Deepseek V3 Base самостоятельно (мне бы столько ресурсов), и прогнали через неё вопросы из MATH-500 с использованием промпта от R1. Оказывается, что модель изначально отлично генерировала такие слова как "aha", "wait" и "verify the problem" и показывала примеры селф рефлексии без дообучения.

Потом они решили посмотреть на формулу GRPO и PPO и поняли, что в них есть лишние детали. Во-первых, есть response-level bias, то есть нормировка по длине ответа. Если advantage положительный (ответы верные), наличие нормировки увеличивает апдейты градиента, если отрицательный, то наоборот, ответы становятся длиннее. Это соотносится вот с этим постом, где тоже подтвердили такое поведение моделей. Во-вторых, при подсчёте advantage производится нормировка на std ревардов. Это приводит к тому, что вопросы с меньшим std ревардов больше влияют на веса, что ведёт к менее эффективному обучению. И действительно, если эти два bias убрать, средняя длина ответа довольно быстро выходит на плато, неверные ответы, хоть и длиннее, чем верные, но всё же становятся короче, а качество обученных моделей хуже не становится.

А потом авторы объединили все эти файндинги в единый эксперимент: они взяли qwen-2.5-1.5B с разными системными промптами и проверили, насколько при обучении с GRPO растёт качество на популярных бенчмарках. Результаты напрямую следуют из предыдущих экспериментов: неудобные для модели темплейты её сначала ломают, а потом через RL модель учится отвечать правильно. Это даёт ей офигенный буст в качестве (тот самый +40% on MATH, которым хвастаются в заголовках). Но если не использовать промпт, то модель сразу стартует с удобного начала и отвечает на вопросы очень хорошо — и буст в качестве становится значительно более скромным, в районе 5-6%.

Кроме того, авторы взяли llama-3.2-3b и сравнили, насколько влияет претрейн на высоту плато GRPO. Если не обучать модель на математике, то RL практически не помогает, а вот если сначала обучить на NuminaQA или FineMath, то буст будет достаточно сильным. Модель они учили с R1 промптом, так что предположу, что тут та же история, что и с квеном: скачок в качестве это следствие из нестабильности модели к подающимся в неё промптам, а не из волшебных свойств чисто RL обучения.

Ещё один интересный аблейшн авторы почему-то вынесли в аппендикс: селф рефлексия в R1-Zero больше коррелирует с неправильным ответом, чем с правильным. Конечно, эксперимент проводился всего на 100 примерах, так что может быть это статистически незначимые результаты, но всё равно, клейм интересный.