Forwarded from Канал Доброго Вани | Data Science и Продуктики
Продолжаем рубрику с разбором вопросов на собесах
МЛ
❓ Что будет, если убрать первое дерево у случайного леса? Аналогичный вопрос для бустинга
Ответ для случайного леса:практически ничего, потому что в случайном лесе все деревья голосуют за ответ и исчезновение одного дерева не повлияет решение большинства (при большом N).
Ответ для градиентного бустинга: первое дерево в бустинге вносит самое большое влияние в ответ модели, а все последующие модели лишь улучшают оценку предыдущих деревьев. Поэтому его исчезновение приведет к тому, что смысл всех остальных деревьев будет утерян
МЛ
❓ Я построил линейную регрессионную модель, показывающую 95% доверительный интервал. Означает ли это, что существует 95% вероятность, что коэффициенты моей модели верно оценивают функцию, которую я хочу аппроксимировать?
Ответ:
Доверительный интервал — это результат процедуры, свойства которой определяются при многократном повторении эксперимента.
Корректная интерпретация:
"Если бы мы многократно (бесконечное число раз) повторяли эксперимент, собирали новые данные и каждый раз строили 95% доверительный интервал для коэффициента, то в 95% случаев эти интервалы содержали бы истинное значение параметра."
Big Data
❓ Что такое parquet? В чем отличие csv?
Ответ:
• Колоночный формат: Данные хранятся по столбцам, а не по строкам (как в CSV, JSON).
• Минимизация I/O-операций: При запросе к определенным столбцам читаются только нужные данные, а не вся строка.
• Predicate Pushdown: Фильтрация данных на этапе чтения (например, WHERE age > 20). Parquet хранит метаданные (мин/макс значения для блоков), что позволяет пропускать ненужные блоки данных.
МЛ
Ответ для случайного леса:
МЛ
Ответ:
Корректная интерпретация:
"Если бы мы многократно (бесконечное число раз) повторяли эксперимент, собирали новые данные и каждый раз строили 95% доверительный интервал для коэффициента, то в 95% случаев эти интервалы содержали бы истинное значение параметра."
Big Data
Ответ:
• Минимизация I/O-операций: При запросе к определенным столбцам читаются только нужные данные, а не вся строка.
• Predicate Pushdown: Фильтрация данных на этапе чтения (например, WHERE age > 20). Parquet хранит метаданные (мин/макс значения для блоков), что позволяет пропускать ненужные блоки данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from .ml
Асессорская разметка: как оценивать согласованность?
Обычно разметка проходит строго по этапам: сбор данных → создание гайда → запуск разметки обычно с перекрытием → агрегация меток → обучение модели → оценка качества.
В такой ситуации можно посчитать коэффициент согласованности — agreement. Он показывает долю совпадающих меток между асессорами.
В нашем случае средний попарный agreement — 83,9%, что достаточно неплохо. Но есть подвох: этот коэффициент, так же как и accuracy в случае бинарной классификации, может вводить в заблуждение при дисбалансе классов. В нашем датасете больше 70% меток приходятся на два класса — «Нейтральный» и «Замешательство». Давайте воспользуемся другими статистическими коэффициентами, чтобы удостовериться в высокой согласованности:
📌 Cohen‘s Kappa (Каппа Коэна) — попарный коэффициент. Оценивает нормализованное согласие между двумя асессорами.
Как интерпретировать результаты:
📌 Fleiss’s Kappa (Каппа Фляйна) — подходит для оценки согласованности между несколькими (более двух) асессорами.
В нашем случае Каппа Коэна варьируется от 0,7 до 0,84, что указывает на высокую согласованность. Для дополнительной проверки мы взяли несколько сотен случайных примеров из датасета и вручную расставили метки. Оказалось, что в 44% наши и асессорские метки расходились — то есть, асессоры в среднем согласованно ставят неправильные метки. Вот поэтому даже высокие показатели согласованности не гарантируют качественной разметки данных.
Что делать в такой ситуации — расскажем в следующем посте.
Обычно разметка проходит строго по этапам: сбор данных → создание гайда → запуск разметки обычно с перекрытием → агрегация меток → обучение модели → оценка качества.
Допустим, мы хотим получить разметку данных для классификатора сентимента обращений в поддержку. Мы получили метки от трех асессоров для некоторого количества реальных диалогов. Как же понять, насколько качественный результат разметки?
В такой ситуации можно посчитать коэффициент согласованности — agreement. Он показывает долю совпадающих меток между асессорами.
В нашем случае средний попарный agreement — 83,9%, что достаточно неплохо. Но есть подвох: этот коэффициент, так же как и accuracy в случае бинарной классификации, может вводить в заблуждение при дисбалансе классов. В нашем датасете больше 70% меток приходятся на два класса — «Нейтральный» и «Замешательство». Давайте воспользуемся другими статистическими коэффициентами, чтобы удостовериться в высокой согласованности:
📌 Cohen‘s Kappa (Каппа Коэна) — попарный коэффициент. Оценивает нормализованное согласие между двумя асессорами.
Как интерпретировать результаты:
<0,6 — плохая согласованность.
0,6…0,8 — хорошая согласованность, можно использовать в прикладных задачах.
>0,8 — очень высокая согласованность.
📌 Fleiss’s Kappa (Каппа Фляйна) — подходит для оценки согласованности между несколькими (более двух) асессорами.
В нашем случае Каппа Коэна варьируется от 0,7 до 0,84, что указывает на высокую согласованность. Для дополнительной проверки мы взяли несколько сотен случайных примеров из датасета и вручную расставили метки. Оказалось, что в 44% наши и асессорские метки расходились — то есть, асессоры в среднем согласованно ставят неправильные метки. Вот поэтому даже высокие показатели согласованности не гарантируют качественной разметки данных.
Что делать в такой ситуации — расскажем в следующем посте.
Forwarded from .ml
Что делать, если асессорская разметка не совпала с экспертной?
В прошлом посте мы выяснили, что коэффициенты согласованности не всегда отражают финальное качество разметки и модели. В нашем случае почти половина примеров размечена неверно — асессоры согласны между собой, но не с экспертами. Как можно улучшить разметку:
📝 Проверить формулировку задачи и прописать подробный гайд с корнер-кейсами. Можно взять выборку, разметить её по гайду и посмотреть, где возникают споры — эти места нужно уточнить.
📝 Собрать тестовый датасет с золотой разметкой с помощью эксперта. После этого можно отобрать асессоров с высокими показателями на тестовом наборе или провести брифинг-встречу со всеми асессорами, чтобы обсудить ошибки.
📝 Разбить работу на чанки и добавить в каждый golden set для валидации. Это позволит оценивать качество разметки итеративно и следить, насколько асессоры попадают в золотой набор.
После внедрения этих шагов в нашей модели эмоций взвешенный F1 вырос с 0,61 до 0,7, а расхождение экспертной и асессорской разметки упало с 44% до 18%. Также хорошо подтянулись небольшие проблемные классы:
Важно:низкая согласованность не всегда означает плохую работу асессоров . Причинами могут быть:
📎 Неоднозначность задачи: она может подразумевать некоторую неопределенность. Например, такое часто встречается при подготовке диалоговых данных для LLM.
📎 Разный бэкграунд асессоров: внутренние AI-тренеры и внешние подрядчики могут понимать задачу по-разному. Это приводит к значительным различиям в оценках.
Поэтому ML-инженерам и датасаентистам важно самим вчитываться в данные и понимать, как они размечены.
Что делать с ошибочными разметками — расскажем в следующем посте.
В прошлом посте мы выяснили, что коэффициенты согласованности не всегда отражают финальное качество разметки и модели. В нашем случае почти половина примеров размечена неверно — асессоры согласны между собой, но не с экспертами. Как можно улучшить разметку:
📝 Проверить формулировку задачи и прописать подробный гайд с корнер-кейсами. Можно взять выборку, разметить её по гайду и посмотреть, где возникают споры — эти места нужно уточнить.
📝 Собрать тестовый датасет с золотой разметкой с помощью эксперта. После этого можно отобрать асессоров с высокими показателями на тестовом наборе или провести брифинг-встречу со всеми асессорами, чтобы обсудить ошибки.
📝 Разбить работу на чанки и добавить в каждый golden set для валидации. Это позволит оценивать качество разметки итеративно и следить, насколько асессоры попадают в золотой набор.
После внедрения этих шагов в нашей модели эмоций взвешенный F1 вырос с 0,61 до 0,7, а расхождение экспертной и асессорской разметки упало с 44% до 18%. Также хорошо подтянулись небольшие проблемные классы:
Благодарность — 0,8 → 0,76
Нейтральный — 0,7 → 0,75
Удовлетворительно — 0,68 → 0,74
Нетерпение — 0,57 → 0,53
Разочарование — 0,57 → 0,55
Замешательство — 0,46 → 0,7
Важно:
📎 Неоднозначность задачи: она может подразумевать некоторую неопределенность. Например, такое часто встречается при подготовке диалоговых данных для LLM.
📎 Разный бэкграунд асессоров: внутренние AI-тренеры и внешние подрядчики могут понимать задачу по-разному. Это приводит к значительным различиям в оценках.
Поэтому ML-инженерам и датасаентистам важно самим вчитываться в данные и понимать, как они размечены.
Что делать с ошибочными разметками — расскажем в следующем посте.
Forwarded from Жизнь и датка (Alexander Guschin)
В процессе работы над ВсОШ я узнал, как образовательный "рынок" адаптируется под появление новой олимпиады.
Например, оказывается (я правда не знал!) что существуют сборные регионов и городов - например, в Питере и Москве ребят на ВсОШ будут целенаправленно готовить.
В некоторых школах появились доп. занятия по ML (например, 2107 или Л2Ш), а в некоторых уже были кружки (Летово, СУНЦ НГУ), а где-то ML учат даже на уровне школьной программы (Лицей №22 "Надежда Сибири).
Стали появляться также разные кружки подготовки: например, кружок от яндекса https://ai.algocode.ru/ (надо было вовремя узнать и пройти отбор) и, конечно, всякие платные кружки.
Это все помогает готовиться, но в основном, если тебе повезло: ты учишься в Москве или Питере, в школе, где учат ML, а также если ты уже шаришь и тогда имеешь шансы отобраться в какой-нибудь онлайн кружок. При этом многие ребята, которые участвовали в отборе на IOAI, были вообще из какой-нибудь noname школы. Кто-то даже шутил, что он единственный млщик в своем городе (не удивлюсь, если среди школьников это и правда так). А Вова Архипов, который проводил муницип в Ростовской области, рассказал мне, что у него его несложный муницип на почти что фулл решило всего два человека. Как вы, возможно, помните, я сам из маленького города, где олимпиадного ML, кмк, нет до сих пор. Поэтому мне очень хотелось чтобы появился открытый и бесплатный курс по подготовке к ВсОШ ИИ, который будет доступен всем и сможет помочь ребятам, с которыми не занимаются учителя или тренеры.
И вот появился и такой) https://cu.ru/olympiad/events/ai-course
Как и ВсОШ по ИИ, курс состоит из трех частей: математика, прога и ML. Части по математике и проге были сделаны специально под ВсОШ, а ML частично взят с нашего курса для подготовки к межнару + частично дозаписан, чтобы закрыть недостающие темы. В создании курса поучаствовали классные ребята, которые проанализировали все доступные по ВсОШ материалы и тестовые контесты, чтобы составить программу и подобрать задачи для домашек. Все они шарят за свой предмет, так что я думаю, что всем, кто готовится, это прям будет полезно)
Например, оказывается (я правда не знал!) что существуют сборные регионов и городов - например, в Питере и Москве ребят на ВсОШ будут целенаправленно готовить.
В некоторых школах появились доп. занятия по ML (например, 2107 или Л2Ш), а в некоторых уже были кружки (Летово, СУНЦ НГУ), а где-то ML учат даже на уровне школьной программы (Лицей №22 "Надежда Сибири).
Стали появляться также разные кружки подготовки: например, кружок от яндекса https://ai.algocode.ru/ (надо было вовремя узнать и пройти отбор) и, конечно, всякие платные кружки.
Это все помогает готовиться, но в основном, если тебе повезло: ты учишься в Москве или Питере, в школе, где учат ML, а также если ты уже шаришь и тогда имеешь шансы отобраться в какой-нибудь онлайн кружок. При этом многие ребята, которые участвовали в отборе на IOAI, были вообще из какой-нибудь noname школы. Кто-то даже шутил, что он единственный млщик в своем городе (не удивлюсь, если среди школьников это и правда так). А Вова Архипов, который проводил муницип в Ростовской области, рассказал мне, что у него его несложный муницип на почти что фулл решило всего два человека. Как вы, возможно, помните, я сам из маленького города, где олимпиадного ML, кмк, нет до сих пор. Поэтому мне очень хотелось чтобы появился открытый и бесплатный курс по подготовке к ВсОШ ИИ, который будет доступен всем и сможет помочь ребятам, с которыми не занимаются учителя или тренеры.
И вот появился и такой) https://cu.ru/olympiad/events/ai-course
Как и ВсОШ по ИИ, курс состоит из трех частей: математика, прога и ML. Части по математике и проге были сделаны специально под ВсОШ, а ML частично взят с нашего курса для подготовки к межнару + частично дозаписан, чтобы закрыть недостающие темы. В создании курса поучаствовали классные ребята, которые проанализировали все доступные по ВсОШ материалы и тестовые контесты, чтобы составить программу и подобрать задачи для домашек. Все они шарят за свой предмет, так что я думаю, что всем, кто готовится, это прям будет полезно)
Telegram
avearrr
Все кто писал олимпиады знают, что ВсОШ считается самой крутой. И неожиданно в этом году информатику разделили на 4 направления, один из них ИИ
Так вот я был организатором МЭ в Ростовской области и составлял задачи. Оказывается, разрабатывать задания намного…
Так вот я был организатором МЭ в Ростовской области и составлял задачи. Оказывается, разрабатывать задания намного…
Forwarded from Daniilak — Канал
Переход c Selenium на Playwright
У меня имеется мой парсер для особых сервисов, который имеет в себе классический зоопарк с selenium (xvfb, конкретная версия ChromeDriver), а также постоянные проблемы с таймаутами и нестабильностью. В общем, всё как обычно.... а Xvfb было решением, которое... позволяет компилировать wasm скрипты
Я очень давно хотел его выкинуть. и наконец-то я близко у цели. Один
Playwright действительно быстрее. Не на 10%, а ощутимо. Особенно заметно на больших объемах данных. Код стал чище — вместо
теперь просто
Не нужно гадать, почему браузер упал — Playwright просто говорит, что не так. Docker образ стал легче — я убрал xvfb, кучу системных пакетов и прочую ерунду. Теперь базовый образ python slim + Playwright.
Технически тоже всё упростилось. Браузер теперь инициализируется один раз на воркер и переиспользуется. Конфиги настраиваются через действительно конфиги, а не через аргументы. а их там аж 30 chrome параметров наберется. Скриншоты делаются встроенными методами
Да, можно было написать код на Selenium лучше, делать больше оберток и покупать лучше сервера, но он мне очень сильно надоел...
У меня имеется мой парсер для особых сервисов, который имеет в себе классический зоопарк с selenium (xvfb, конкретная версия ChromeDriver), а также постоянные проблемы с таймаутами и нестабильностью. В общем, всё как обычно.... а Xvfb было решением, которое... позволяет компилировать wasm скрипты
Я очень давно хотел его выкинуть. и наконец-то я близко у цели. Один
playwright install chromium — и всё работает. Нативный async/await вместо костылей с WebDriverWait. Dockerfile сократился. Были улучшены воркеры, взамен самописных скриптовPlaywright действительно быстрее. Не на 10%, а ощутимо. Особенно заметно на больших объемах данных. Код стал чище — вместо
WebDriverWait(driver, 20).until(expected_conditions.presence_of_element_located((By.ID, "element"))) теперь просто
await page.wait_for_selector("#element")Не нужно гадать, почему браузер упал — Playwright просто говорит, что не так. Docker образ стал легче — я убрал xvfb, кучу системных пакетов и прочую ерунду. Теперь базовый образ python slim + Playwright.
Технически тоже всё упростилось. Браузер теперь инициализируется один раз на воркер и переиспользуется. Конфиги настраиваются через действительно конфиги, а не через аргументы. а их там аж 30 chrome параметров наберется. Скриншоты делаются встроенными методами
Да, можно было написать код на Selenium лучше, делать больше оберток и покупать лучше сервера, но он мне очень сильно надоел...
Forwarded from Женя Янченко
Частичные индексы
Представьте ситуацию. В БД PostgreSQL есть таблица с данными водителей:
Внутри одной компании номер телефона водителя должен быть уникален. Для этого заведен индекс уникальности по
Затем добавляется возможность удалять водителей из кабинета компании. Удаление реализуем через soft delete: добавляем в табличку поле
Проходит время, и от пользователей приходит баг: при добавлении нового водителя возникает ошибка.
В логах видно, что БД ругается из-за нарушения уникальности. Оказалось, что запись с таким номером телефона уже существовала и была удалена.
Перед вставкой записи о новом водителе в коде делали проверку, нет ли уже в этой компании водителя с таким телефоном, но проверка была для неудаленных водителей:
Для просмотра списка водителей тоже возвращались только неудаленные записи.
А индекс уникальности по
Разобрались, сделали, чтобы индекс уникальности тоже учитывал только неудаленные записи:
Такой индекс называется частичным.
Частичный индекс — это индекс, который строится не по всем строкам таблицы, а по их подмножеству, определяемому условием WHERE. Это не обязательно должен быть индекс уникальности, может использоваться для индексов поиска.
Когда частичный индекс может пригодиться:
➡️ Как в разобранном выше кейсе, если нужно сделать уникальность по условию.
➡️ Когда в таблице 90% записей "неинтересны" для запросов, можно построить частичный индекс по оставшимся 10%, он будет работать быстрее и занимать в несколько раз меньше места.
Например, у вас есть таблица счетов.
90% счетов имеют статус "Оплачено", а запросы касаются счетов в других статусах.
Если сделать частичный индекс, проиндексировав для поиска оставшиеся 10% неоплаченных счетов, то такой индекс будет занимать значительно меньше места, чем индекс по всем строкам.
Это имеет смысл на больших таблицах, от миллионов строк, когда индекс по всей таблице становится слишком тяжёлым. Плюс запросов к тем 90% непроиндексированным строкам действительно должно быть минимум, ведь они будут обрабатываться без индекса.
⚡️ Ещё кейс из практики.
Когда работала в платформе, тоже столкнулась с ситуацией, в которой пригодились частичные индексы для уникальности.
В рамках одной из задач мне нужно было поддержать уникальность связки полей
Я знала, что c NULL используется не
И если мы хотим разрешить только одну такую запись
1️⃣ Уникальность связки
2️⃣ Уникальность связки
Частичные индексы — нечастая история, но могут пригодиться.
Читала, что в некоторых компаниях отказываются от constraints на уровне БД, таких как foreign keys и индексы уникальности, все необходимые проверки существуют только на уровне кода. Поделитесь, пожалуйста, как у вас?
🔗 — у нас созданы foreign keys и индексы уникальности в БД
💅 — у нас все проверки на уровне кода, индексы только для ускорения поиска
Представьте ситуацию. В БД PostgreSQL есть таблица с данными водителей:
id
company_id
name
phoneВнутри одной компании номер телефона водителя должен быть уникален. Для этого заведен индекс уникальности по
(phone, company_id).Затем добавляется возможность удалять водителей из кабинета компании. Удаление реализуем через soft delete: добавляем в табличку поле
is_deleted. Все работает корректно.Проходит время, и от пользователей приходит баг: при добавлении нового водителя возникает ошибка.
В логах видно, что БД ругается из-за нарушения уникальности. Оказалось, что запись с таким номером телефона уже существовала и была удалена.
Перед вставкой записи о новом водителе в коде делали проверку, нет ли уже в этой компании водителя с таким телефоном, но проверка была для неудаленных водителей:
WHERE is_deleted = false, поэтому она не находила ранее удаленного водителя (и это правильно).Для просмотра списка водителей тоже возвращались только неудаленные записи.
А индекс уникальности по
(phone, company_id) при добавлении поля is_deleted изменить забыли. Поэтому при попытке добавить ранее удаленного водителя с тем же номером телефона возникала ошибка 😢Разобрались, сделали, чтобы индекс уникальности тоже учитывал только неудаленные записи:
create unique index uc_drivers_phone_company_id
on drivers(phone, company_id)
where is_deleted is false;Такой индекс называется частичным.
Частичный индекс — это индекс, который строится не по всем строкам таблицы, а по их подмножеству, определяемому условием WHERE. Это не обязательно должен быть индекс уникальности, может использоваться для индексов поиска.
Обратите внимание, что поле из WHERE не обязано быть индексируемым. В примере мы строим индекс по полям phone, company_id, а в предикате используем поле is_deleted.
Когда частичный индекс может пригодиться:
Например, у вас есть таблица счетов.
90% счетов имеют статус "Оплачено", а запросы касаются счетов в других статусах.
Если сделать частичный индекс, проиндексировав для поиска оставшиеся 10% неоплаченных счетов, то такой индекс будет занимать значительно меньше места, чем индекс по всем строкам.
Это имеет смысл на больших таблицах, от миллионов строк, когда индекс по всей таблице становится слишком тяжёлым. Плюс запросов к тем 90% непроиндексированным строкам действительно должно быть минимум, ведь они будут обрабатываться без индекса.
Когда работала в платформе, тоже столкнулась с ситуацией, в которой пригодились частичные индексы для уникальности.
В рамках одной из задач мне нужно было поддержать уникальность связки полей
(a, b, c). Я добавила индекс и стала писать тесты. Поле c могло быть null, и в процессе тестирования я обнаружила, что несмотря на индекс могу добавить в таблицу две одинаковые записи со значениями:a = 1, b = 2, c = null
a = 1, b = 2, c = nullЯ знала, что c NULL используется не
!=, а IS NULL и IS NOT NULL, так как для PostgreSQL NULL — это не значение, а маркер отсутствия данных. Но оказалось, что с null-значениями еще и уникальный индекс не видит конфликт.И если мы хотим разрешить только одну такую запись
a = 1, b = 2, c = null, то нужно сделать два частичных индекса уникальности:(a, b) where c is null(a, b, c) where c is not nullЧастичные индексы — нечастая история, но могут пригодиться.
Читала, что в некоторых компаниях отказываются от constraints на уровне БД, таких как foreign keys и индексы уникальности, все необходимые проверки существуют только на уровне кода. Поделитесь, пожалуйста, как у вас?
💅 — у нас все проверки на уровне кода, индексы только для ускорения поиска
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
Ребят, в комментариях к предыдущему посту про частичные индексы написали, что проблема с NULL значениями в индексах уникальности решена с PostgreSQL 15.
Моя история ещё из 2021 года 👨🦳
Сейчас можно добавить такую формулировку при создании индекса в конце:
И null values для целей индекса будут считаться одинаковыми, не нужно будет создавать два индекса.
Моя история ещё из 2021 года 👨🦳
Сейчас можно добавить такую формулировку при создании индекса в конце:
NULLS NOT DISTINCTИ null values для целей индекса будут считаться одинаковыми, не нужно будет создавать два индекса.
Forwarded from Pavel Zloi
Частенько друзья, знакомые или коллеги интересуются, какие книги я бы порекомендовал инженеру, который только начинает разбираться с тем, как внедрять ML-системы и вообще, как работает "кухня" разработки интеллектуальных систем, ну и поскольку я не учёный, а скорее инженер-интегратор, я рекомендую пару книг за авторством Алекса Соя (которые мне в своё время тоже очень рекомендовали).
⬜️ System Design. Подготовка к сложному интервью
Она даёт фундамент, поясняет, из каких компонентов собирают те или иные решения, как софт взаимодействует с железом, как выполняется балансировка, в общем очень много чего, от проектирования базовых и тривиальных решений до архитектур сложных высоконагруженных систем.
Помимо непосредственно самого содержания книги в ней мне очень нравится объёмная ссылочная информация на разные источники, в том числе и исходники на гитхабе или научные публикации.
🟨 System Design. Машинное обучение. Подготовка к сложному интервью
После базовой базы описанной в первой книге можно уже спокойно браться за вторую книгу, которая уже непосредственно про ML рассказывает, хотя наверно будет правильнее сказать MLOps, так как в больше степени там говорится про то какие ИИ-решения бывают, как выбрать наиболее подходящее под задачу, как выполнять оценку, какие типовые решения бывают.
И конечно же масса ссылок на дополнительную документацию, которую тоже очень интересно читать.
PS. И пусть вас не пугает то что книги называются подготовка к сложному интервью, информация изложена в них простым и понятным языком, поэтому даже без глубоких познаний в той или иной теме можно относительно быстро разобраться.
⬜️ System Design. Подготовка к сложному интервью
Она даёт фундамент, поясняет, из каких компонентов собирают те или иные решения, как софт взаимодействует с железом, как выполняется балансировка, в общем очень много чего, от проектирования базовых и тривиальных решений до архитектур сложных высоконагруженных систем.
Помимо непосредственно самого содержания книги в ней мне очень нравится объёмная ссылочная информация на разные источники, в том числе и исходники на гитхабе или научные публикации.
🟨 System Design. Машинное обучение. Подготовка к сложному интервью
После базовой базы описанной в первой книге можно уже спокойно браться за вторую книгу, которая уже непосредственно про ML рассказывает, хотя наверно будет правильнее сказать MLOps, так как в больше степени там говорится про то какие ИИ-решения бывают, как выбрать наиболее подходящее под задачу, как выполнять оценку, какие типовые решения бывают.
И конечно же масса ссылок на дополнительную документацию, которую тоже очень интересно читать.
PS. И пусть вас не пугает то что книги называются подготовка к сложному интервью, информация изложена в них простым и понятным языком, поэтому даже без глубоких познаний в той или иной теме можно относительно быстро разобраться.
Forwarded from Neural Kovalskii
Я ставлю крест на RAG: почему поиск по базе — это теперь задача для джуна, а будущее — за Generic Agent
Байт засчитан =)
Капля истории
Мы с вами начали с фундамента AI-инфраструктуры тестировали Llama на кластерах 4090, показывал вам тюн Whisper и считали экономику on-premise решений
Затем углубились в сложный RAG и Vibe Coding: заняли топ с малыми моделями в Enterprise RAG Challenge изучили Circuit Tracing для поиска галлюцинаций и научились собирать MVP за 7 дней
В середине 2025 перешли к автономным системам: запустили open-source SGR Deep Research доказали эффективность на бенчмарках и выпустили фреймворк SGR Agent Core
Честно говоря к концу 2025 года стало очевидно что RAG превратился в стандартную инженерную задачу которую может собрать джун по туториалам
Настоящий вызов сместился к агентам
И вот тут начинается самое интересное потому что большинство того что называют агентами на рынке это просто красивые цепочки в no-code конструкторах Workflow где вы заранее продумали каждый if-else
Это не агенты это детерминированные пайплайны с LLM внутри
Я потратил последние месяцы на то чтобы понять как строить настоящие автономные системы (Запускал демо ERC3, строил решения для демо в agentic comerce)
Результат всей моей работы оказался тут sgr-agent-core фреймворк уже набрал 815 звезд на GitHub и работает в продакшене у реальных клиентов
Но главное не звезды а то понимание физики процесса которое я получил, и это так же ответ зачем было его делать
Generic Agent = Based Prompt + ReAct+PlanAct + Context Engineering + Memory + Tool Search
Это не просто формула это средя для автономности Based Prompt задает законы физики для модели как она должна думать планировать реагировать на ошибки
ReAct это безальтернативный цикл без которого автономности не существует модель должна рассуждать действовать анализировать результат и корректировать план
Context Engineering потому что контекст не резиновый и агент должен уметь управлять своим вниманием сжимать историю отбрасывать неактуальное держать фокус
Memory это не просто кэш это архитектурное решение о том что помнить что забывать когда делать compaction
Tool Search критически важный компонент для энтерпрайза когда у вас 500 плюс API-ручек вы не можете скормить их все в контекст настоящий агент сначала понимает задачу находит нужный инструмент в репозитории и только потом использует
В ближайшие дни у меня будет несколько площадок где я буду давать очень скромный прогноз без хайпа обещаю
Очень хочу показать что курсы по AI-агентам дают вам базу с langchain или n8n и обещают что теперь вы зарабатываете 300к в наносекунду но они не расскажут про управление форматом и структурами внутри tools про constraint и args про то как на самом деле работает structured output (пришлите в коменты если такой курс есть) как управлять ризонингом в агентах и как его вызывать самому (наш тул reasoning+plan)
Must Read от создателей LLM
Перед тем как что-то изобретать и задавать вопросы прочитайте что говорят те кто делает сами модели
OpenAI A Practical Guide to Building Agents
OpenAI Building Agents Track
Anthropic Building Effective Agents
Anthropic Context Engineering
Anthropic Building Agents with Claude Agent SDK
Все они говорят +- одно начинайте с простого не тащите сразу LangGraph на 20 нод сделайте одного агента с одним инструментом заставьте работать потом масштабируйте
Я строю агентов на локальных моделях и как оказалось что бы строить generic agent нужно мощное железо🗿
Это не потому что я против OpenAI это потому что я хочу полный контроль над инференсом над латенси над стоимостью
Когда ты делаешь продакшен на локальных моделях ты понимаешь каждый байт контекста каждый вызов инструмента каждую миллисекунду задержки
Это сделать тебя лучшим инженером над API вызовами
По этому далее будет усиление на контент именно про них, про агентов, и про sgr-agent-core будем выводить фреймворк на 10к звезд!
Если ты со мной ставь🖥 Linux =)
Stay tuned!
Капля истории
Мы с вами начали с фундамента AI-инфраструктуры тестировали Llama на кластерах 4090, показывал вам тюн Whisper и считали экономику on-premise решений
Затем углубились в сложный RAG и Vibe Coding: заняли топ с малыми моделями в Enterprise RAG Challenge изучили Circuit Tracing для поиска галлюцинаций и научились собирать MVP за 7 дней
В середине 2025 перешли к автономным системам: запустили open-source SGR Deep Research доказали эффективность на бенчмарках и выпустили фреймворк SGR Agent Core
Честно говоря к концу 2025 года стало очевидно что RAG превратился в стандартную инженерную задачу которую может собрать джун по туториалам
Настоящий вызов сместился к агентам
И вот тут начинается самое интересное потому что большинство того что называют агентами на рынке это просто красивые цепочки в no-code конструкторах Workflow где вы заранее продумали каждый if-else
Это не агенты это детерминированные пайплайны с LLM внутри
Я потратил последние месяцы на то чтобы понять как строить настоящие автономные системы (Запускал демо ERC3, строил решения для демо в agentic comerce)
Результат всей моей работы оказался тут sgr-agent-core фреймворк уже набрал 815 звезд на GitHub и работает в продакшене у реальных клиентов
Но главное не звезды а то понимание физики процесса которое я получил, и это так же ответ зачем было его делать
Generic Agent = Based Prompt + ReAct+PlanAct + Context Engineering + Memory + Tool Search
Это не просто формула это средя для автономности Based Prompt задает законы физики для модели как она должна думать планировать реагировать на ошибки
ReAct это безальтернативный цикл без которого автономности не существует модель должна рассуждать действовать анализировать результат и корректировать план
Context Engineering потому что контекст не резиновый и агент должен уметь управлять своим вниманием сжимать историю отбрасывать неактуальное держать фокус
Memory это не просто кэш это архитектурное решение о том что помнить что забывать когда делать compaction
Tool Search критически важный компонент для энтерпрайза когда у вас 500 плюс API-ручек вы не можете скормить их все в контекст настоящий агент сначала понимает задачу находит нужный инструмент в репозитории и только потом использует
В ближайшие дни у меня будет несколько площадок где я буду давать очень скромный прогноз без хайпа обещаю
Очень хочу показать что курсы по AI-агентам дают вам базу с langchain или n8n и обещают что теперь вы зарабатываете 300к в наносекунду но они не расскажут про управление форматом и структурами внутри tools про constraint и args про то как на самом деле работает structured output (пришлите в коменты если такой курс есть) как управлять ризонингом в агентах и как его вызывать самому (наш тул reasoning+plan)
Must Read от создателей LLM
Перед тем как что-то изобретать и задавать вопросы прочитайте что говорят те кто делает сами модели
OpenAI A Practical Guide to Building Agents
OpenAI Building Agents Track
Anthropic Building Effective Agents
Anthropic Context Engineering
Anthropic Building Agents with Claude Agent SDK
Все они говорят +- одно начинайте с простого не тащите сразу LangGraph на 20 нод сделайте одного агента с одним инструментом заставьте работать потом масштабируйте
Я строю агентов на локальных моделях и как оказалось что бы строить generic agent нужно мощное железо
Это не потому что я против OpenAI это потому что я хочу полный контроль над инференсом над латенси над стоимостью
Когда ты делаешь продакшен на локальных моделях ты понимаешь каждый байт контекста каждый вызов инструмента каждую миллисекунду задержки
Это сделать тебя лучшим инженером над API вызовами
По этому далее будет усиление на контент именно про них, про агентов, и про sgr-agent-core будем выводить фреймворк на 10к звезд!
Если ты со мной ставь
Stay tuned!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from декомпозиция и отвага
Один вопрос, чтобы понять, подходит ли кандидат под вакансию 🤔
И это вопрос⬇️
Его задают, чтобы понять:
🔴 как были выстроены процессы в компаниях, где кандидат работал?
🔴 имеет ли кандидат опыт работы в режиме повышенной опасности многозадачности?
🔴 работал ли он с нечеткими требованиями?
🔴 насколько самостоятельной единицей был этот аналитик? или всё ОТ и ДО курировал его техлид?
Ответы варьируются от вот такого травоядного варианта🐇 🍃
До такого хищного и зубастого🐯 🥩
И это два параллельных мира👋 👋
А теперь представьте, что на проект типа 2 приходит аналитик с опытом только на проектах типа 1. Как думаете, он готов к такому экстриму? Желает ли он этих острых ощущений?
Не, ну может и желает. Это просто надо было обсудить на собесе. А начать — с вопроса «От кого и в каком виде вы получали задачи?»👌
🙃 🙃 🙃 🙃 🙃 🙃 🙃 🙃 🙃 🙃
❤️ -
⁉️ -
😎
И это вопрос
🔊 От кого и в каком виде вы получали задачи?
Его задают, чтобы понять:
Ответы варьируются от вот такого травоядного варианта
Всего на проекте 3 системных аналитика, 1 бизнес-аналитик и техлид аналитиков. Задачи приходят от техлида в виде jira-тикетов с верхнеуровневым описанием, ссылками на макеты в Figma и с бизнес-требованиями от бизнес-аналитика. Уже готовую документацию СА скидывает на ревью своему техлиду.
До такого хищного и зубастого
На проекте я был единственным аналитиком. Бизнес-аналитика или Product Owner как такового не было, и я общался с заказчиком напрямую. Задачи приходили ко мне в устной форме и были сформулированы довольно кратко. Я задавал уточняющие вопросы, протоколировал встречи и фиксировал бизнес требования в отдельном документе
, который никому кроме меня нахер не сдался.
Помимо этого, задачи поступали от техлида. Как правило, это были задачи, связанные с разбором ошибок на проде или техдолг по документации в базе знаний проекта. Какого-то общего планирования, на котором решался бы приоритет и очередность выполнения задач от бизнеса и от техлида не было, организация времени была только моей зоной ответственности. Практики обязательной проверки моих артефактом техлидом не было, я нес полную индивидуальную ответственность за результат.
И это два параллельных мира
А теперь представьте, что на проект типа 2 приходит аналитик с опытом только на проектах типа 1. Как думаете, он готов к такому экстриму? Желает ли он этих острых ощущений?
Не, ну может и желает. Это просто надо было обсудить на собесе. А начать — с вопроса «От кого и в каком виде вы получали задачи?»
А как у вас?❤️ -
скорее вариант 1, всегда есть четкие требования скорее вариант 2, у меня черный пояс по сбору требований, а вчера вообще звонили и приглашали работать в разведку😎
- в активном поиске хоть какого-то вариантаPlease open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dataism
База про работу с метриками.pdf
1001.5 KB
🌟NSM, пирамида и дерево метрик: три всадника продуктовой аналитики
Собрала вам базу по основным понятиям.
В pdf краткий конспект дляленивых энергосберегающих 🔋 .
Кстати, тут pdf с диагностикой отрицательного роста.
❓Какие бывают метрики:
https://gopractice.ru/product/added_value_metrics/ - метрики продукта, роста, эффективности и добавочной ценности
https://amplitude.com/books/north-star/the-north-star-checklist - North Star Metric чек-лист
➡️ Иерархия метрик:
https://www.youtube.com/watch?v=DgvUq4D0IUQ - лекция ШМЯ
https://www.youtube.com/watch?v=xh0GTIkYhOw - Денис Теплов из Лиги Ставок про фейлы с NSM. Очень классное выступление!
https://www.youtube.com/watch?v=0KColE4-MdY&t - Глеб Кудрявцев онлайнбез регистрации и смс строит дерево метрик
https://library.wannabe.ru/article/kak-postroit-ierarhiyu-metrik-i-ispolzovat-ee-v-rabote
🔼Пирамида метрик:
больше материала найдете в канале Лены Серегиной
https://www.youtube.com/watch?v=7wTO1GonUj4&t=53s - краткое пояснение за разницу между иерархией и пирамидой
https://master-strategy.ru/tpost/nrpt840r71-kak-sdelat-put-razvitiya-kompanii-produk
https://www.agima.ru/blog/analytics/piramida-metrik-pozhaluy-luchshiy-sposob-ponyat-chto-ne-tak-s-vashim-produktom/ - пирамида метрик как способ понять, что не так с продуктом
Собрала вам базу по основным понятиям.
В pdf краткий конспект для
Кстати, тут pdf с диагностикой отрицательного роста.
❓Какие бывают метрики:
https://gopractice.ru/product/added_value_metrics/ - метрики продукта, роста, эффективности и добавочной ценности
https://amplitude.com/books/north-star/the-north-star-checklist - North Star Metric чек-лист
https://www.youtube.com/watch?v=DgvUq4D0IUQ - лекция ШМЯ
https://www.youtube.com/watch?v=xh0GTIkYhOw - Денис Теплов из Лиги Ставок про фейлы с NSM. Очень классное выступление!
https://www.youtube.com/watch?v=0KColE4-MdY&t - Глеб Кудрявцев онлайн
https://library.wannabe.ru/article/kak-postroit-ierarhiyu-metrik-i-ispolzovat-ee-v-rabote
🔼Пирамида метрик:
больше материала найдете в канале Лены Серегиной
https://www.youtube.com/watch?v=7wTO1GonUj4&t=53s - краткое пояснение за разницу между иерархией и пирамидой
https://master-strategy.ru/tpost/nrpt840r71-kak-sdelat-put-razvitiya-kompanii-produk
https://www.agima.ru/blog/analytics/piramida-metrik-pozhaluy-luchshiy-sposob-ponyat-chto-ne-tak-s-vashim-produktom/ - пирамида метрик как способ понять, что не так с продуктом
Please open Telegram to view this post
VIEW IN TELEGRAM