Forwarded from Находки в опенсорсе
`__typing_subst__` – магический метод в Python, про который вы не слышали
В питоне сложилась довольно сложная ситуация с типизацией. В отличии от многих других языков, у нас нет специального "мини-языка типов". Что сильно упрощает работу с типизацией для авторов языка. Ведь им не нужно поддерживать поведение объектов типизации в рантайме.
А у нас есть только старый добрый питон и его объекты. Да, в питоне – действительно всё объект. Даже типизация. Оттого, любой код, который вы пишите в аннотациях – должен корректно работать в рантайме. Ведь у нас есть потребители такого, например:
Скажем, у нас есть TypeAliasType объект с одной типовой переменной. Мы хотим её явно указать:
Тут все довольно просто в рантайме:
Мы видим, что замена
А как физически происходит замена переменной?
Начнем с того, что в Python есть 3 TypeVar-like объекта:
-
-
-
Пример ошибки замены, исходник:
Пытаемся заменить
Но как фактически проверить, что замена корректная? И вот тут входит в дело
Он определен у всех типов TypeVar-like. Мы посмотрим на ParamSpec. Все, конечно же, написано на дикой смеси C и Python. И Cшная реализация
Аналогично:
Подготовка к замене
Но, все еще чуть-чуть сложнее. Потому что перед тем как что-то заменить, нам нужно подготовиться к замене.
Есть второй магический метод, исходники:
Ну или напрямую:
Здесь в первом случае
Вот такая машинерия выполняется каждый раз, когда нам нужен
Обсуждение: задумывались ли вы о работе аннотаций типов в рантайме? Сталкивались ли с проблемами в данной сфере? Тормозило?
| Поддержать | YouTube | GitHub | Чат |
В питоне сложилась довольно сложная ситуация с типизацией. В отличии от многих других языков, у нас нет специального "мини-языка типов". Что сильно упрощает работу с типизацией для авторов языка. Ведь им не нужно поддерживать поведение объектов типизации в рантайме.
А у нас есть только старый добрый питон и его объекты. Да, в питоне – действительно всё объект. Даже типизация. Оттого, любой код, который вы пишите в аннотациях – должен корректно работать в рантайме. Ведь у нас есть потребители такого, например:
pydantic.Скажем, у нас есть TypeAliasType объект с одной типовой переменной. Мы хотим её явно указать:
type StrDict[_V] = dict[str, _V]
numbers: StrDict[int] = {'one': 1}
Тут все довольно просто в рантайме:
StrDict[int] вызовет __getitem__ вот тут. Кстати, там Cшный код, конечно же. И нам просто вернется нужный GenericAlias объект с нужными __args__:
>>> type StrDict[_V] = dict[str, _V]
>>> StrDict[int], type(StrDict[int]), StrDict[int].__args__
(StrDict[int], <class 'types.GenericAlias'>, (<class 'int'>,))
Мы видим, что замена
_V на int работает! Пока что 🌚А как физически происходит замена переменной?
Начнем с того, что в Python есть 3 TypeVar-like объекта:
TypeVar, TypeVarTuple, ParamSpec. У каждого из них есть свои правила, как можно их заменять (в некоторых контекстах):-
TypeVar можно заменять на одно другое типовое значение-
TypeVarTuple можно заменять на любое количество типовых значений-
ParamSpec можно заменять на Concatenate, ... и список типовПример ошибки замены, исходник:
>>> from collections.abc import Callable
>>> from typing import ParamSpec, TypeVar
>>> P = ParamSpec('P')
>>> R = TypeVar('R')
>>> Callable[P, R][0, int]
Traceback (most recent call last):
TypeError: Expected a list of types, an ellipsis, ParamSpec, or Concatenate. Got <class 'int'>
Пытаемся заменить
P на 0, что не является корректной заменой.Но как фактически проверить, что замена корректная? И вот тут входит в дело
__typing_subst__.Он определен у всех типов TypeVar-like. Мы посмотрим на ParamSpec. Все, конечно же, написано на дикой смеси C и Python. И Cшная реализация
ParamSpec.__typing_subst__ вызывает typing._paramspec_subst. Почему так? В 3.12 все переписали на C в спешке. Но некоторые части были слишком сложны, их оставили на питоне.Аналогично:
>>> P.__typing_subst__([])
()
>>> P.__typing_subst__([int, str])
(<class 'int'>, <class 'str'>)
>>> P.__typing_subst__(...)
Ellipsis
>>> P.__typing_subst__(0)
Traceback (most recent call last):
TypeError: Expected a list of types, an ellipsis, ParamSpec, or Concatenate. Got 0
Подготовка к замене
Но, все еще чуть-чуть сложнее. Потому что перед тем как что-то заменить, нам нужно подготовиться к замене.
Есть второй магический метод, исходники:
__typing_prepare_subst__. Он нужен, чтобы собрать аргументы для замены. Потому что у нас, например, могут быть неявные аргументы с default. Проверим на TypeVarTuple:
>>> class Custom[T1, *Ts=(int, int)]: ...
...
>>> Custom[str]
__main__.Custom[str, [int, int]]
>>> Custom[str, str]
__main__.Custom[str, str]
Ну или напрямую:
>>> Custom.__type_params__[1].__typing_prepare_subst__(*Custom.__type_params__[1], ())
([(<class 'int'>, <class 'int'>)],)
>>> Custom.__type_params__[1].__typing_prepare_subst__(*Custom.__type_params__[1], (str,))
((<class 'str'>,),)
Здесь в первом случае
[int, int] нам как раз добавили в __args__ через __typing_prepare_subst__ вот тут.Вот такая машинерия выполняется каждый раз, когда нам нужен
Generic с параметрами. Потому с 3.14 все аннотации будут ленивыми по-умолчанию. А __annotate__ будет выполняться только тогда, когда аннотации будут запрашивать реально для рантайма.Обсуждение: задумывались ли вы о работе аннотаций типов в рантайме? Сталкивались ли с проблемами в данной сфере? Тормозило?
| Поддержать | YouTube | GitHub | Чат |
Python documentation
typing — Support for type hints
Source code: Lib/typing.py This module provides runtime support for type hints. Consider the function below: The function surface_area_of_cube takes an argument expected to be an instance of float,...
Forwarded from Душный NLP
Проблемы LLM-as-a-Judge и их решение
Сегодня разберём статью о проблеме оценки открытых ответов (например, рассказов) моделью так же, как это делают асессоры. Мотивация тут проста: использование LLM дешевле, быстрее и позволяет значительно увеличить корзинку, на которой проводится сравнение. При этом полностью выступать заменой разметчиками модель, конечно, пока не может.
Авторы рассматривают три типа LLM-as-a-Judge:
— Попарное сравнение. Модели предоставляют два ответа и предлагают выбрать из них лучший. Такой вариант дорогой, но даёт хорошую согласованность.
— Оценка одного ответа. Модель ставит оценку по какой-то шкале всего одному ответу.
— Оценка по референсу. Модель получает эталонный ответ и, отталкиваясь от него, оценивает.
Однако у использования LLM есть свои минусы. Первый, существующий и у разметчиков, — position bias, который возникает при попарном сравнении. Большинство моделей, получая два ответа, предпочитают выбирать первый. Что интересно, если попросить LLM не просто сравнить два ответа, а дать оценку каждому, то position bias проявляется чаще.
Чтобы решить эту проблему, авторы заставляют модель дважды сравнивать ответы, каждый раз меняя их местами. При этом победитель оглашается только в конце. Если решение судьи изменилось после смены позиции, то авторы предлагают считать это ничьёй.
Ещё один способ — использование few-shot. Модель получает два ответа с прямым указанием, какой из них лучше. Всего таких «прогонов» три: в одном случае лучше первый ответ, в другом — второй, а в третьем — ничья. Только после этого LLM предлагают уже самостоятельно оценить два решения. Такой способ помог повысить согласованность с 65% до 77,5%. Авторы отмечают, что это дорогой метод, причём нельзя быть уверенным, что в результате его использования не возникли новые проблемы.
Также LLM плохо справляются с оцениваем решения математических задач и задач с рассуждением. Чтобы обойти эту проблему пытались использовать CoT, но он не дал хороших результатов. Зато число ошибок уменьшило руководство по референсу: авторы просили судью решить задачу, затем использовать собственный ответ как эталонный для последующей оценки.
Кроме того, у LLM-as-a-Judge есть ещё две проблемы: verbosity bias (LLM выше оценивает более длинные ответы; такое, к слову, бывает и у разметчиков) и self-enhancement bias (модели-судьи лучше оценивают собственные ответы). Для этих проблем у авторов нет решения.
Разбор подготовила❣ Анастасия Кириллова
Душный NLP
Сегодня разберём статью о проблеме оценки открытых ответов (например, рассказов) моделью так же, как это делают асессоры. Мотивация тут проста: использование LLM дешевле, быстрее и позволяет значительно увеличить корзинку, на которой проводится сравнение. При этом полностью выступать заменой разметчиками модель, конечно, пока не может.
Авторы рассматривают три типа LLM-as-a-Judge:
— Попарное сравнение. Модели предоставляют два ответа и предлагают выбрать из них лучший. Такой вариант дорогой, но даёт хорошую согласованность.
— Оценка одного ответа. Модель ставит оценку по какой-то шкале всего одному ответу.
— Оценка по референсу. Модель получает эталонный ответ и, отталкиваясь от него, оценивает.
Однако у использования LLM есть свои минусы. Первый, существующий и у разметчиков, — position bias, который возникает при попарном сравнении. Большинство моделей, получая два ответа, предпочитают выбирать первый. Что интересно, если попросить LLM не просто сравнить два ответа, а дать оценку каждому, то position bias проявляется чаще.
Чтобы решить эту проблему, авторы заставляют модель дважды сравнивать ответы, каждый раз меняя их местами. При этом победитель оглашается только в конце. Если решение судьи изменилось после смены позиции, то авторы предлагают считать это ничьёй.
Ещё один способ — использование few-shot. Модель получает два ответа с прямым указанием, какой из них лучше. Всего таких «прогонов» три: в одном случае лучше первый ответ, в другом — второй, а в третьем — ничья. Только после этого LLM предлагают уже самостоятельно оценить два решения. Такой способ помог повысить согласованность с 65% до 77,5%. Авторы отмечают, что это дорогой метод, причём нельзя быть уверенным, что в результате его использования не возникли новые проблемы.
Также LLM плохо справляются с оцениваем решения математических задач и задач с рассуждением. Чтобы обойти эту проблему пытались использовать CoT, но он не дал хороших результатов. Зато число ошибок уменьшило руководство по референсу: авторы просили судью решить задачу, затем использовать собственный ответ как эталонный для последующей оценки.
Кроме того, у LLM-as-a-Judge есть ещё две проблемы: verbosity bias (LLM выше оценивает более длинные ответы; такое, к слову, бывает и у разметчиков) и self-enhancement bias (модели-судьи лучше оценивают собственные ответы). Для этих проблем у авторов нет решения.
Разбор подготовила
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Valuable AI / Валентин Малых
почти подряд пришло две новости:
1) Microsoft выпустила сеть для генерации голоса VibeVoice; она позволяет генерировать аудио длиной до 90 минут с 4 участниками; и это моделькой, размером в 1.5B; я попробовал генерировать русский, сильный американский акцент слышно и периодически захлебывается, явно на русский не рассчитано, хотя на странице есть пример с китайским
2) OpenAI буквально сегодня ночью выпустила Realtime API для генерации голоса при общении с ChatGPT, кстати, поддерживает SIP
@valuableai
1) Microsoft выпустила сеть для генерации голоса VibeVoice; она позволяет генерировать аудио длиной до 90 минут с 4 участниками; и это моделькой, размером в 1.5B; я попробовал генерировать русский, сильный американский акцент слышно и периодически захлебывается, явно на русский не рассчитано, хотя на странице есть пример с китайским
2) OpenAI буквально сегодня ночью выпустила Realtime API для генерации голоса при общении с ChatGPT, кстати, поддерживает SIP
@valuableai
Forwarded from Dealer.AI
Alarm мы уперлись в потолок или как жить дальше в GenAI?
Продолжаем старую тему про развитие текущей парадигмы GenAI. Глянем на это через призму "как ChatGPT стал великим",на самом деле не только он :
1. Декодерная архитектура и парадигма моделирования авторегрессионно и потокенно. Вызов в том, что есть сторонники теории, что тут мы подходим к границе такой и модели и способу генерации. Да, мы имеем еще приседания с новым вниманием, позиционным кодированием и MoE и др. Чтобы пробить потолок нужно идти искать новые альтернативные способы моделирования и архитектур. Что это будет? Диффузии, world model, JEPA, RWKV или еще новее? Поживём-увидим.
2. Датасеты. Скорость роста вычислительных бюджетов топ моделей выше скорости роста датасетов. Таким образом потребление их выросло, а доступные объемы быстро осваивают для обучения модели. Синтетика, кстати, не всегда помогает, т.к. ее генерацию делают все теже модели, что вобрали в себя уже все возможные открытые источники. Ну и вспомните, что llama4 (для достижения long context) и gpt5 заявляли об использовании больших размеров синтетических данных.И что, сынку, помогли тебе твои ляхи синтетики?
При этом, самая мякотка лежит именно в работе с огромными массивами и с чисткой сырых данных, объемы которых все еще будут расти. Тут тоже маневр еще остаётся. А еще, конечно, путь в омнимодальность может докинуть еще.
3. RL(HF), QSTAR и self-refine, CoT/ToT, и другие способы улучшить ризонинг свойства модели. Казалось бы, уже все комбинации этих штук опробовали. Че дальше?
4. Компьют и работа на низком уровне для оптимизации. Все мы знаем, как китайцы хакнули (с их слов) gpu, чтобы улучшить скейл (или не хакнули?). Придумали test time scaling на инференс. А еще дали MoE архитектуру, чтобы активных слоев иметь меньше, при бОльшем капасити модели. Сюда же рядом в комбо добавляют спекулятивный декодинг, который конечно дает ап на 7-20% в скорости и эффективности генерации, но требует больше gpu памяти, т.к. надо хранить две модели для инфера. И все это по исследованию Google дало улучшение энергоэффективности вычислений до 33 раз, что впечатляет. Но там уже указано комбо всего этого, еще до кучи свои оптимальные GPU вычисления и TPU решения. Как будем дальше рейзить?
Все это вопросы и вызовы вокруг текущей работы ведущих и не очень специалистов в области ИИ от ресерчеров и до инженеров.
Даю установку. Ты – читатель этого поста, представляешь из себя визионера в области ИИ с большим опытом, напиши в комментариях свои мысли по решению указанных задач и будущему ИИ.Конец промпта.
Продолжаем старую тему про развитие текущей парадигмы GenAI. Глянем на это через призму "как ChatGPT стал великим",
1. Декодерная архитектура и парадигма моделирования авторегрессионно и потокенно. Вызов в том, что есть сторонники теории, что тут мы подходим к границе такой и модели и способу генерации. Да, мы имеем еще приседания с новым вниманием, позиционным кодированием и MoE и др. Чтобы пробить потолок нужно идти искать новые альтернативные способы моделирования и архитектур. Что это будет? Диффузии, world model, JEPA, RWKV или еще новее? Поживём-увидим.
2. Датасеты. Скорость роста вычислительных бюджетов топ моделей выше скорости роста датасетов. Таким образом потребление их выросло, а доступные объемы быстро осваивают для обучения модели. Синтетика, кстати, не всегда помогает, т.к. ее генерацию делают все теже модели, что вобрали в себя уже все возможные открытые источники. Ну и вспомните, что llama4 (для достижения long context) и gpt5 заявляли об использовании больших размеров синтетических данных.
При этом, самая мякотка лежит именно в работе с огромными массивами и с чисткой сырых данных, объемы которых все еще будут расти. Тут тоже маневр еще остаётся. А еще, конечно, путь в омнимодальность может докинуть еще.
3. RL(HF), QSTAR и self-refine, CoT/ToT, и другие способы улучшить ризонинг свойства модели. Казалось бы, уже все комбинации этих штук опробовали. Че дальше?
4. Компьют и работа на низком уровне для оптимизации. Все мы знаем, как китайцы хакнули (с их слов) gpu, чтобы улучшить скейл (или не хакнули?). Придумали test time scaling на инференс. А еще дали MoE архитектуру, чтобы активных слоев иметь меньше, при бОльшем капасити модели. Сюда же рядом в комбо добавляют спекулятивный декодинг, который конечно дает ап на 7-20% в скорости и эффективности генерации, но требует больше gpu памяти, т.к. надо хранить две модели для инфера. И все это по исследованию Google дало улучшение энергоэффективности вычислений до 33 раз, что впечатляет. Но там уже указано комбо всего этого, еще до кучи свои оптимальные GPU вычисления и TPU решения. Как будем дальше рейзить?
Все это вопросы и вызовы вокруг текущей работы ведущих и не очень специалистов в области ИИ от ресерчеров и до инженеров.
Даю установку. Ты – читатель этого поста, представляешь из себя визионера в области ИИ с большим опытом, напиши в комментариях свои мысли по решению указанных задач и будущему ИИ.
Forwarded from Пресидский залив
Какое ключевое применение AI в e-commerce?
3 года назад я бы точно сказала про рекомендации и контекстную рекламу, но сейчас AI двигает рынок глубже, формируя новые подходы и пути пользователя.
Давайте посмотрим 5 разных категорий и что меняется в каждой из них согласно недавней статье a16z:
"Hyper-optimized TikTok and IG algorithms steer purchases."
Алгоритмы становятся умнее и точнее.
Здесь все понятно, AI усиливает динамический контент и персонализированную рекламу
Кстати, нтересный факт, что чаще всего такие покупки происходят ночью и с телефона
"AI agent tracks prices and buys for you when the time is right."
AI постепенно превращается в закупщика: сам следит за ценой и стоком,
делает заказ, когда пора, и сообщает: "твой ежедневный айс американо уже готовят".
Это хорошо ложится на гросери сторы и регулярные покупки как например доставка еды по подписке
“AI researcher finds + suggests SKUs for your needs.”
Это самый хот топик, где мы существуем с Aesty. AI собирает варианты, знает твои вкусы, тип фигуры и
предлагает персональный shortlist не 1000 вариантов, а топ оф зэ топ
Кстати, чем меньше вариантов предлагаем за раз, тем лучше конверсия
“AI consultant meets with you and recommends what + where to buy.”
Здесь AI работает как доменный эксперт: сравнивает бренды, объясняет разницу,
помогает принять решение и выбрать лучшее под твои задачи 🧗
“AI coach helps… and guides you through the decision process.”
Тут конечно же никакой автоматической закупки, по крайней мере пока ты не серийный real estate инвестор.
AI помогает искать, анализировать, сравнивать, но финальное слово остается за человеком.
По мнению a16z 2, 3 и 4 сильнее всего будут меняться благодаря персонализации и более удобному поиску информации
Го 50 🔥 на этот пост и разберу 4 главных технических изменения, которые должны произойти чтобы мы могли полностью делегировать шоппинг агентам
@neural_prosecco
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Google расчехлил исследование про эмбеддеры.
В данном исследовании авторы показывают также как и в моих постах упор в capacity векторов моделей для RAG.
Причем это соотносится с более ранним исследованием. Однако, на нашем опыте нам удавалось иметь пожималку эмба с 1024 до 400 и иметь минимальную просадку на метриках поиска для индекса в 1.1млн документов. Что показывает, что для 512 эмба до 500к можно строить индекс не совсем правда. Нужно еще учитывать не только представимость вектора, но еще и capacity модели. А еще, если мы вспомним matryoshka, когда нарезают эмбед по размерности от M к изначальной длине, при правильном обучении, срез эмба не уменьшает значимо метрики поиска. Иначе бы матрешка просто бы не работала и не была так популярна. Поэтому давайте говорить, не про представимость эмбеда, а еще об эффективности вектора. Видимо, исследование рассматривает весьма неэффективные векторные представления.
Отсюда выводы, просто нужно правильно готовить metric learning и тогда RAG в части поисковой модели будет хорош. На этом все.
Upd. И кстати, у соседей там пишут мол ColBERT работает круто ибо там не один эмб юзают и тип капасити вектора растёт в К векторов это все не так.
ColBERT хорош за счёт того, что совмещает в себе полнотекстовый и полноконтекстный поиск. И задача metric learning стоит как сведение токен эмбов попарно все со всеми у запроса и документов и поэтому это эффективно. Но для поиска всеравно использует mean pooling этих произведений скалярных эмбов. А токены итак связаны между собой и тем более с mean pooling вектором, который и рассматривает статья от гугла.
Т.е. снова мы видим просто хорошую правильную постановку metric learning.
В данном исследовании авторы показывают также как и в моих постах упор в capacity векторов моделей для RAG.
Причем это соотносится с более ранним исследованием. Однако, на нашем опыте нам удавалось иметь пожималку эмба с 1024 до 400 и иметь минимальную просадку на метриках поиска для индекса в 1.1млн документов. Что показывает, что для 512 эмба до 500к можно строить индекс не совсем правда. Нужно еще учитывать не только представимость вектора, но еще и capacity модели. А еще, если мы вспомним matryoshka, когда нарезают эмбед по размерности от M к изначальной длине, при правильном обучении, срез эмба не уменьшает значимо метрики поиска. Иначе бы матрешка просто бы не работала и не была так популярна. Поэтому давайте говорить, не про представимость эмбеда, а еще об эффективности вектора. Видимо, исследование рассматривает весьма неэффективные векторные представления.
Отсюда выводы, просто нужно правильно готовить metric learning и тогда RAG в части поисковой модели будет хорош. На этом все.
Upd. И кстати, у соседей там пишут мол ColBERT работает круто ибо там не один эмб юзают и тип капасити вектора растёт в К векторов это все не так.
ColBERT хорош за счёт того, что совмещает в себе полнотекстовый и полноконтекстный поиск. И задача metric learning стоит как сведение токен эмбов попарно все со всеми у запроса и документов и поэтому это эффективно. Но для поиска всеравно использует mean pooling этих произведений скалярных эмбов. А токены итак связаны между собой и тем более с mean pooling вектором, который и рассматривает статья от гугла.
Т.е. снова мы видим просто хорошую правильную постановку metric learning.
arXiv.org
On the Theoretical Limitations of Embedding-Based Retrieval
Vector embeddings have been tasked with an ever-increasing set of retrieval tasks over the years, with a nascent rise in using them for reasoning, instruction-following, coding, and more. These...
Forwarded from Dealer.AI
Разработчик из Google поделился кукбуком по созданию ангентов.
У нас было 400 страниц, две ветки проекта, семьдесят пять ампул reasoning step, пять пакетиков кристально чистого SGR, солонка, наполовину наполненная function calling, и целое море разноцветных chat template injection, tool execution и прочих примесей. А также литр persistent context, литр clarification prompts, ящик adaptive planning, пинта чистого structured output, и двенадцать пузырьков report completion. Не то, чтобы всё это было категорически необходимо для запуска пайплайна, но если уж начал собирать Google мануал по созданию ангентов, то к делу надо подходить серьёзно.(с)
——————————————
У нас было 400 страниц, две ветки проекта, семьдесят пять ампул reasoning step, пять пакетиков кристально чистого SGR, солонка, наполовину наполненная function calling, и целое море разноцветных chat template injection, tool execution и прочих примесей. А также литр persistent context, литр clarification prompts, ящик adaptive planning, пинта чистого structured output, и двенадцать пузырьков report completion. Не то, чтобы всё это было категорически необходимо для запуска пайплайна, но если уж начал собирать Google мануал по созданию ангентов, то к делу надо подходить серьёзно.(с)
——————————————
Google Docs
Agentic Design Patterns
Agentic Design Patterns 👉 🧠 ✅ I’m excited to share that my new book, "Agentic Design Patterns: A Hands-On Guide to Intelligent AI Agents," is officially out! 👉 🧠 ✅ In a field moving at lightning speed, this book focuses on the durable, fundamental patterns…
Forwarded from Artem Ryblov’s Data Science Weekly
Feature Selection in Machine Learning by Soledad Galli
Feature selection is the process of selecting a subset of features from the total variables in a data set to train machine learning algorithms. Feature selection is an important aspect of data mining and predictive modelling.
Feature selection is key for developing simpler, faster, and highly performant machine learning models and can help to avoid overfitting. The aim of any feature selection algorithm is to create classifiers or regression models that run faster and whose outputs are easier to understand by their users.
In this book, you will find the most widely used feature selection methods to select the best subsets of predictor variables from your data. You will learn about filter, wrapper, and embedded methods for feature selection. Then, you will discover methods designed by computer science professionals or used in data science competitions that are faster or more scalable.
First, we will discuss the use of statistical and univariate algorithms in the context of artificial intelligence. Next, we will cover methods that select features through optimization of the model performance. We will move on to feature selection algorithms that are baked into the machine learning techniques. And finally, we will discuss additional methods designed by data scientists specifically for applied predictive modeling.
In this book, you will find out how to:
- Remove useless and redundant features by examining variability and correlation.
- Choose features based on statistical tests such as ANOVA, chi-square, and mutual information.
- Select features by using Lasso regularization or decision tree based feature importance, which are embedded in the machine learning modeling process.
- Select features by recursive feature elimination, addition, or value permutation.
Each chapter fleshes out various methods for feature selection that share common characteristics. First, you will learn the fundamentals of the feature selection method, and next you will find a Python implementation.
The book comes with an accompanying Github repository with the full source code that you can download, modify, and use in your own data science projects and case studies.
Feature selection methods differ from dimensionality reduction methods in that feature selection techniques do not alter the original representation of the variables, but merely select a reduced number of features from the training data that produce performant machine learning models.
Using the Python libraries Scikit-learn, MLXtend, and Feature-engine, you’ll learn how to select the best numerical and categorical features for regression and classification models in just a few lines of code. You will also learn how to make feature selection part of your machine learning workflow.
Link:
- Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning #featureselection #fs
@data_science_weekly
Feature selection is the process of selecting a subset of features from the total variables in a data set to train machine learning algorithms. Feature selection is an important aspect of data mining and predictive modelling.
Feature selection is key for developing simpler, faster, and highly performant machine learning models and can help to avoid overfitting. The aim of any feature selection algorithm is to create classifiers or regression models that run faster and whose outputs are easier to understand by their users.
In this book, you will find the most widely used feature selection methods to select the best subsets of predictor variables from your data. You will learn about filter, wrapper, and embedded methods for feature selection. Then, you will discover methods designed by computer science professionals or used in data science competitions that are faster or more scalable.
First, we will discuss the use of statistical and univariate algorithms in the context of artificial intelligence. Next, we will cover methods that select features through optimization of the model performance. We will move on to feature selection algorithms that are baked into the machine learning techniques. And finally, we will discuss additional methods designed by data scientists specifically for applied predictive modeling.
In this book, you will find out how to:
- Remove useless and redundant features by examining variability and correlation.
- Choose features based on statistical tests such as ANOVA, chi-square, and mutual information.
- Select features by using Lasso regularization or decision tree based feature importance, which are embedded in the machine learning modeling process.
- Select features by recursive feature elimination, addition, or value permutation.
Each chapter fleshes out various methods for feature selection that share common characteristics. First, you will learn the fundamentals of the feature selection method, and next you will find a Python implementation.
The book comes with an accompanying Github repository with the full source code that you can download, modify, and use in your own data science projects and case studies.
Feature selection methods differ from dimensionality reduction methods in that feature selection techniques do not alter the original representation of the variables, but merely select a reduced number of features from the training data that produce performant machine learning models.
Using the Python libraries Scikit-learn, MLXtend, and Feature-engine, you’ll learn how to select the best numerical and categorical features for regression and classification models in just a few lines of code. You will also learn how to make feature selection part of your machine learning workflow.
Link:
- Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning #featureselection #fs
@data_science_weekly
Forwarded from Refat Talks: Tech & AI
Суть про Observability для AI-систем и ландшафт тулов на сегодня
Итак, обычный код работает предсказуемо - знаешь входные данные, понимаешь результат. С AI все иначе: появляется не детерминированный компонент, в agentic системах все еще сложнее. Поэтому Observability стал не роскошью, а базовой потребностью.
Без трейсов ты не понимаешь, почему агент принял именно это решение, сколько это стоило и где система дала сбой, и какие вообще метрики - конкретные и в среднем.
AI observability наследует ДНК от классических инструментов вроде Grafana и Sentry, но решает специфические задачи:
- Трейсинг вызовов. В агентских системах одна задача может породить цепочку из десятков API-вызовов. Нужно видеть полную последовательность: какие промпты отправлялись, какие тулы, что в ответ, что попало в контекст, как модель рассуждала.
- Мониторинг стоимости. Каждый запрос = токены = деньги. Хороший observability tool покажет стоимость каждого вызова и поможет оптимизировать расходы.
- Continuous evaluation. Интеграция с evaluation-платформами позволяет трекать качество ответов и деградацию модели в реальном времени.
- Фидбэк-лупы. Возможность собирать оценки пользователей (лайки/дизлайки) и связывать их с конкретными трейсами.
При выборе инструмента обращай внимание на:
1. OTEL-совместимость. OpenTelemetry - важный открытый стандарт трейсинга. Если инструмент его поддерживает, легче интегрировать логи других систем.
2. Безопасность. Ты будешь логировать почти все взаимодействия с LLM, хоть и best practice - избегать перс. данных в логах, оперировать ID вместо например имейлов, рассмотри self-hosted решения и смотри на лицензцию.
3. Простоту внедрения. Например, LangFuse (который многие как и я любят) при использовании OpenAI SDK интегрируется буквально заменой импорта:
4. Поддержку твоего стека. Проверь, работает ли с твоим фреймворком из коробки, например Mastra (пост) умеет в эти вот.
5. SKD и фичи, например некоторые тулы лучше подходят для agentic систем, другие круто интегрируются с Cloud инфраструктурой.
И про ландшафт. Я собирал для себя информацию по топ observability инструментов в эту таблицу - от простых логгеров до enterprise-монстров. Пользуйтесь. Кроме замечательного LangFuse там есть много интересного, со своими плюсами в некоторых кейсах.
Итак, обычный код работает предсказуемо - знаешь входные данные, понимаешь результат. С AI все иначе: появляется не детерминированный компонент, в agentic системах все еще сложнее. Поэтому Observability стал не роскошью, а базовой потребностью.
Без трейсов ты не понимаешь, почему агент принял именно это решение, сколько это стоило и где система дала сбой, и какие вообще метрики - конкретные и в среднем.
AI observability наследует ДНК от классических инструментов вроде Grafana и Sentry, но решает специфические задачи:
- Трейсинг вызовов. В агентских системах одна задача может породить цепочку из десятков API-вызовов. Нужно видеть полную последовательность: какие промпты отправлялись, какие тулы, что в ответ, что попало в контекст, как модель рассуждала.
- Мониторинг стоимости. Каждый запрос = токены = деньги. Хороший observability tool покажет стоимость каждого вызова и поможет оптимизировать расходы.
- Continuous evaluation. Интеграция с evaluation-платформами позволяет трекать качество ответов и деградацию модели в реальном времени.
- Фидбэк-лупы. Возможность собирать оценки пользователей (лайки/дизлайки) и связывать их с конкретными трейсами.
При выборе инструмента обращай внимание на:
1. OTEL-совместимость. OpenTelemetry - важный открытый стандарт трейсинга. Если инструмент его поддерживает, легче интегрировать логи других систем.
2. Безопасность. Ты будешь логировать почти все взаимодействия с LLM, хоть и best practice - избегать перс. данных в логах, оперировать ID вместо например имейлов, рассмотри self-hosted решения и смотри на лицензцию.
3. Простоту внедрения. Например, LangFuse (который многие как и я любят) при использовании OpenAI SDK интегрируется буквально заменой импорта:
- import openai
+ from langfuse.openai import openai
4. Поддержку твоего стека. Проверь, работает ли с твоим фреймворком из коробки, например Mastra (пост) умеет в эти вот.
5. SKD и фичи, например некоторые тулы лучше подходят для agentic систем, другие круто интегрируются с Cloud инфраструктурой.
И про ландшафт. Я собирал для себя информацию по топ observability инструментов в эту таблицу - от простых логгеров до enterprise-монстров. Пользуйтесь. Кроме замечательного LangFuse там есть много интересного, со своими плюсами в некоторых кейсах.
Forwarded from Refat Talks: Tech & AI
This media is not supported in your browser
VIEW IN TELEGRAM
GitHub Copilot в веб-версии как умный поиск по всему open source
Относительно недавно открыл для себя фичу, которая экономит часы копания в чужом коде. GitHub Copilot Chat прямо на github.com - по сути - натуральный RAG по всему open source. На видео, кстати, пару моих недавних юз кейсов.
Как это работает
Заходишь на любой репозиторий, открываешь Copilot Chat и задаешь вопросы по этому репо. Но самое крутое - он может искать и анализиовать не только в текущем репо, но и по всему GitHub.
Реальные кейсы
Выбор библиотеки. Вместо того чтобы гуглить "best X library for Y", открывать десятки вкладок и сравнивать звездочки - просто спроси Copilot про активность проекта, количество issues, частоту релизов. Он соберет инфу и выдаст summary.
Разбор имплементации. Нужно понять, как в популярной библиотеке реализован retry с backoff? "In repo X, explain how the HTTP client handles retries and backoff, show the relevant functions and files". Copilot покажет конкретные куски кода и объяснит логику.
Поиск известных проблем. Перед интеграцией библиотеки полезно проверить, какие там баги висят. "List recent security-related issues for repo Y and summarize mitigations or patches" - и сразу видишь, стоит ли вообще связываться.
Понимание архитектуры. Залез в новый проект и не понимаешь, как оно вообще устроено? Copilot может объяснить структуру, основные компоненты и как они взаимодействуют еще до того как ты спулишь этого репо. Особенно круто для больших проектов.
И да, прямо в VS Code есть
Короче, если раньше разбор новой библиотеки занимал полдня прыжков по документации и исходникам, теперь базовое понимание получаешь за 10 минут диалога с Copilot. А потом уже целенаправленно копаешь глубже там, где нужно.
В разработке большая часть кода - open source проекты, которые живут, развиваются и часто плохо документированы, Copilot тут реально экономит время.
Относительно недавно открыл для себя фичу, которая экономит часы копания в чужом коде. GitHub Copilot Chat прямо на github.com - по сути - натуральный RAG по всему open source. На видео, кстати, пару моих недавних юз кейсов.
Как это работает
Заходишь на любой репозиторий, открываешь Copilot Chat и задаешь вопросы по этому репо. Но самое крутое - он может искать и анализиовать не только в текущем репо, но и по всему GitHub.
Реальные кейсы
Выбор библиотеки. Вместо того чтобы гуглить "best X library for Y", открывать десятки вкладок и сравнивать звездочки - просто спроси Copilot про активность проекта, количество issues, частоту релизов. Он соберет инфу и выдаст summary.
Разбор имплементации. Нужно понять, как в популярной библиотеке реализован retry с backoff? "In repo X, explain how the HTTP client handles retries and backoff, show the relevant functions and files". Copilot покажет конкретные куски кода и объяснит логику.
Поиск известных проблем. Перед интеграцией библиотеки полезно проверить, какие там баги висят. "List recent security-related issues for repo Y and summarize mitigations or patches" - и сразу видишь, стоит ли вообще связываться.
Понимание архитектуры. Залез в новый проект и не понимаешь, как оно вообще устроено? Copilot может объяснить структуру, основные компоненты и как они взаимодействуют еще до того как ты спулишь этого репо. Особенно круто для больших проектов.
И да, прямо в VS Code есть
@github agent, а для других агентов есть Github MCP, но на практике это не то, часто удобнее и эффективнее юзать именно веб-версию.Короче, если раньше разбор новой библиотеки занимал полдня прыжков по документации и исходникам, теперь базовое понимание получаешь за 10 минут диалога с Copilot. А потом уже целенаправленно копаешь глубже там, где нужно.
В разработке большая часть кода - open source проекты, которые живут, развиваются и часто плохо документированы, Copilot тут реально экономит время.