Forwarded from Всеволод Викулин | AI разбор
AI-агент рекрутер. Кейс компании LinkedIn
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Рекрутер создает описание вакансии, агент уточняет детали, запускает поиск по базе из миллионов кандидатов, показывает только самых подходящих. Это не автоматизация, это другой подход к поиску кандидатов. Кому, как не LinkedIn, пришло в голову воплотить эту идею. Мы разберем устройство этого агента и найдем причины успеха продукта. Может, они не из-за AI-агента? Но давайте по порядку.
Архитектура
Агент построен на классической архитектуре Plan-And-Execute. Это простой, наглядный и итеративный процесс.
1) Главный субагент получает задачу от рекрутера. Смотрит на историю сообщений. Пытается понять, что рекрутер хочет сделать, насколько он явно выразил мысль, достаточно ли информации. Все рассуждения преобразует в план.
2) План превращается в список конкретных задач для будущих исполнителей. На этом этапе важно дать исполнителю ровно ту информацию, которая ему нужна для решения задачи, но не больше. Все как с людьми: важно все объяснить, но не перегрузить лишними деталями. Это называется изоляция контекста — основной паттерн проектирования агентских систем сейчас.
3) Задачи отправляются субагентам-исполнителям. Их великое множество. Ровно столько, сколько есть разных задач в рекрутменте:
— один собирает у рекрутера дополнительную информацию;
— второй формулирует множество запросов в поиск;
— третий оценивает, насколько кандидат подходит.
...
У каждого субагента есть только свой список тулов, которыми он может пользоваться. Это тоже изоляция, не надо давать кому угодно пользоваться чем угодно. Сломает или потеряет.
4) После того как все субагенты отработали, главный проверяет их результаты. Если цель не выполнена, переформулирует план, отправляет новые задачи. Может спросить совета у рекрутера, если есть вопросы (паттерн human-in-the-loop).
Что здесь на самом деле сложно
Вот такую архитектуру мы с вами можем собрать за 3 часа на n8n и ему подобных. HR-тех мы так не перевернем. Главный актив, над которым команда инженеров LinkedIn работала 99,9% времени — структурированные знания, которыми агент может пользоваться.
Это описания кандидатов, вакансий и успешных историй поиска, где нашли и наняли сотрудника. Это огромный массив данных, который где-то хранится, быстро обновляется и по которому могут быстро искать агенты и люди.
Хранить его просто в текстовом индексе крайне неэффективно. Сейчас все важнее становятся графовые базы данных, вроде neo4j, которые позволяют хранить разные зависимости между объектами. Например, в каких компаниях и в каких вузах учились наши лучшие сотрудники.
У самого LinkedIn есть известная база Economic Graph, в которой лежат структурированные данные по рынку труда, и он может ее легко применять в своих агентах.
Резюме
Да, вам нужно выучить паттерны создания надежных AI-продуктов (читая мой канал, конечно же). Иначе все точно развалится. Но правильная архитектура одного агента не сделает чуда.
Вам нужно оцифровать данные на пути, на котором создается ценность для пользователя. Потом сделать инструменты, чтобы агент мог этими данными пользоваться. Тогда агент сможет сам создавать ценность. Автономно, спрашивая вас только тогда, когда что-то непонятно. Тогда агенты действительно будут полезны бизнесу.
Без этого обычно все заканчивается презентацией прототипа. С очень хорошей архитектурой Plan-And-Execute. Но прототипа.
Linkedin
How we engineered LinkedIn’s Hiring Assistant
Forwarded from Всеволод Викулин | AI разбор
Испечь AI-агента и не сжечь продакшн. Разбор ингредиентов
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
При масштабировании агентов не стоит придумывать с нуля архитектуру для каждой новой задачи. Разработка агентов — новейшая область, у вас огромный риск, что эксперимент провалится. Процесс должен быть похож на выпечку торта по бабушкиному рецепту: мука, яйца, шоколад, а лучше побольше шоколада...
Сегодня мы разберем эти ингредиенты и способы их замеса в шикарный, предсказуемый агентский торт (весь пост удачно проиллюстрирован картинкой).
Из каких компонентов состоят агенты
5 кубиков агентской системы:
1) Оркестратор. Сердце (душа?) агента
Это runtime-движок, который управляет бесконечным циклом работы агента. Оркестратор запускает все компоненты с нужными аргументами, обрабатывает их выходные данные и ошибки, если они случились. Он работает по определенному шаблону, вроде ReAct (подумай, потом сделай), Plan-Execute (составь план и иди строго по нему) и т. д. Физически это Python-код, реализованный, например, на базе LangGraph/LangChain. Но можно написать это и с нуля.
2) LLM. Мозг агента
Оркестратор собирает промпт и отправляет его в LLM, чтобы «мозг» решил, что делать дальше. Можно использовать разные модели под разные задачи: дорогие — для редких и сложных, модели попроще — для массовых операций. Физически это либо API к облачному провайдеру, либо API к LLM на ваших серверах.
3) Инструменты. Руки агента
Любые программы, которые агент может вызывать для решения задачи. Удобно использовать какой-то протокол, например, MCP. Инструментом может быть и другой агент, тогда получится мультиагентная система.
4) Контекстное окно. Память агента
Управление контекстным окном — одна из сложнейших задач. Нужно, чтобы в каждый момент запуска LLM в контексте была ровно та информация, которая необходима для решения текущей проблемы. Чем больше мусора в контексте, тем выше шанс, что «мозг» сломается. Физически это реализуется через различные методы работы с памятью: сжатие, вытеснение старых данных во внешнюю память и т. д.
5) Внешняя информация. Знания агента
Здесь лежат данные, которые не нужны в контексте прямо сейчас, но могут потребоваться позже. Физически это базы знаний или файлы. Доступ к ним происходит через RAG или инструменты поиска (вроде командной строки grep).
Как компоненты взаимодействуют
Всё взаимодействие идет через оркестратор. Но чтобы агент был прозрачным и безопасным, мы делаем это не напрямую, а через специальные прокси-сервисы — Gateways (шлюзы). У них две цели:
- Аналитика. Нужно логировать всё, что запустил оркестратор, чтобы потом собирать метрики и строить дашборды. Подробнее мы обсуждали это в прошлом посте про observability.
- Безопасность. Каждое действие оркестратора должно проходить проверку. Это контроль доступов к файлам, анализ контекста на prompt injection, проверка безопасности инструментов, шифрование персональных данных и т. д.
Заключение
Следуя этому рецепту, вы сможете не просто выпекать более надежных агентов, но и делать это каждый раз все качественнее и быстрее.
Улучшение любого компонента автоматически улучшает всех агентов компании. А каждый новый инструмент может быть переиспользован в будущих проектах.
Это та самая рецептура масштабного внедрения AI в компании, которую я каждому желаю освоить. Не все же нам дошираки заваривать?
Forwarded from Всеволод Викулин | AI разбор
Оркестратор AI-агента. 5 типов и инструкция по их применению.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.
В прошлом посте мы разобрали, из каких ингредиентов состоят агенты. Сегодня поговорим про оркестратор, который управляет процессом решения задачи и связывает все компоненты воедино.
От выбора оркестратора зависит, будет ли агент вашим надежным другом или галлюцинирующим кошмаром. Мы разберем 5 базовых типов (см. 5 картинок), которые нужно применять к разным задачам.
1. LLM-Workflow (Детерминированное исполнение)
Самый надежный и распространенный вариант в продакшене. Порядок действий жестко задан разработчиком в коде. LLM здесь используется как функция внутри жесткого графа: например, суммаризует ответ, извлекает сущности или классифицирует тексты.
Плюсы: надежно, предсказуемо, дешево.
Минусы: нужно этот граф написать руками. Для творческих процессов не подходит совсем.
Когда использовать: для процессов с высокими рисками и понятным регламентом. Например, умный документооборот, ответы на вопросы клиентов.
2. ReAct (Рассуждение и выбор действия)
Базовый вариант автономного агента. Процесс заранее не зафиксирован. Модель работает в цикле: "Подумал → Выбрал инструмент → Получил результат". Здесь уже сама LLM решает, какой инструмент вызвать и когда остановиться.
Плюсы: гибкость. Может выбирать разные действия под ситуацию.
Минусы: часто ломается в долгих задачах (застревает в цикле или забывает цель).
Когда использовать: для простых коротких задач с небольшим числом инструментов (например, «найди курс валюты и отправь в Slack»).
3. Reflexion (Рефлексия)
Умная надстройка над ReAct. В цикл добавляется этап "Рефлексии". Агент получает результат от инструмента, но не бежит дальше, а оценивает: "А то ли я сделал?". Если нет — пересматривает ответ. И так может делать несколько раз для одного действия. Мой любимый паттерн, я тоже мнительный :)
Плюсы: критически поднимает качество в задачах, где результат можно валидировать (код, математика).
Минусы: мнительность ест много токенов и замедляет работу.
Когда использовать: когда фидбек инструмента максимально полезен. Например, программирование, где фидбек — ошибка выполнения программы.
4. Plan-and-Execute (Планирование и исполнение)
Сначала LLM составляет план, затем шаг за шагом другой оркестратор (например, Reflexion) этот план исполняет. Всё работает в едином контекстном окне. Как только план выполнен, LLM проверяет: задача решена или нужно составить новый план?
Плюсы: рабочий вариант решения долгих задач без LLM-Workflow.
Минусы: страдает от "распухания" контекста. В истории накапливается столько мусора, что модель ломается.
Когда использовать: для длинных цепочек действий, где шаги жестко зависят друг от друга (любая последовательная аналитика).
5. Plan-and-Execute + Мультиагентность
План создается как в прошлом пункте, но каждую задачу изолированно решает отдельный оркестратор (субагент). У каждого субагента — своя узкая задача и только необходимая для неё информация, они не делятся контекстом.
Плюсы: мощь планирования + надежность исполнения
Минусы: можно использовать только для узкого класса задач
Когда использовать: всегда, когда задачу можно разбить на независимые блоки. Например, написание большого отчета (мы разбирали DeepResearch).
Резюме
Это 5 базовых паттернов. На практике мы их комбинируем. Ваш «агент мечты» может выглядеть как надежный LLM-Workflow, в узлах которого вызываются более автономные агенты для сложных задач.
Главное правило выбора: берите самую простую архитектуру, способную решить вашу задачу. Если вы можете написать детерминированный Workflow — напишите и забудьте. За каждую каплю автономности вы платите надежностью и рисками.
Forwarded from Math for Impact
Последовательная проверка SRM
TL;DR
Позволяет во время эксперимента проверять корректность долей выборок. Эффективен при длинных тестах.
Почему обсуждается?
Мы хотим останавливать эксперимент как можно раньше, если в нём есть ошибки. Один из простых индикаторов таких проблем — Sample Ratio Mismatch (SRM). Это сильное расхождение между планируемыми и фактическими долями участников в группах. SRM позволяет выявить сбои в рандомизации, ошибки в фильтрации и сетевые эффекты.
Проблема
Нужно принимать решение о наличии SRM без ожидания конца эксперимента и накопления всей выборки.
Предположения
1. Распределение пользователей по группам случайное, сетевые эффекты отсутствуют.
Решение
Фиксируем:
– вероятность ошибки α,
– ожидаемые доли групп p(1), …, p(k),
– параметры априорного распределения b(1), …, b(k).
Часто b(i) = 1 или B·p(i), где B > 0. Эти параметры влияют на баланс между мощностью и скоростью принятия решения.
Во время теста:
1. Добавляем наблюдение — номер группы, в которую попал новый пользователь.
2. Обновляем наблюдаемые доли групп q = (q(1), …, q(k)).
3. Считаем байесовское отношение правдоподобий O(q).
4. Если O(q) > 1 / α → считаем, что SRM присутствует; иначе — продолжаем.
Достоинства
– Быстрее останавливает тест в случае SRM.
– Статистика критерия и граница считаются по простым формулам.
– Для запуска достаточно зафиксировать всего один параметр — уровень значимости. Параметры априорного распределения можно задать равными единице.
Ограничения
– Обладает меньшей мощностью в сравнении с применением критерия хи-квадрат в конце эксперимента.
– Критерий консервативен: фактическая вероятность ошибки обычно ниже заданного α, из-за чего немного снижается мощность.
– Если данные поступают раз в день, их нужно случайно упорядочить перед подачей в критерий.
– Выбор параметров априорного распределения не всегда очевиден — требует экспертной настройки или моделирования.
Библиография
Основная статья:
Lindon M., Malek A. Anytime-valid inference for multinomial count data //Advances in Neural Information Processing Systems. – 2022. – Т. 35. – С. 2817-2831.
Популярное изложение:
A Better Way to Test for Sample Ratio Mismatches (SRMs) and Validate Experiment Implementations
На русском:
Как оценить валидность A/B-тестов. SRM и другие критерии
TL;DR
Позволяет во время эксперимента проверять корректность долей выборок. Эффективен при длинных тестах.
Почему обсуждается?
Мы хотим останавливать эксперимент как можно раньше, если в нём есть ошибки. Один из простых индикаторов таких проблем — Sample Ratio Mismatch (SRM). Это сильное расхождение между планируемыми и фактическими долями участников в группах. SRM позволяет выявить сбои в рандомизации, ошибки в фильтрации и сетевые эффекты.
Проблема
Нужно принимать решение о наличии SRM без ожидания конца эксперимента и накопления всей выборки.
Предположения
1. Распределение пользователей по группам случайное, сетевые эффекты отсутствуют.
Решение
Фиксируем:
– вероятность ошибки α,
– ожидаемые доли групп p(1), …, p(k),
– параметры априорного распределения b(1), …, b(k).
Часто b(i) = 1 или B·p(i), где B > 0. Эти параметры влияют на баланс между мощностью и скоростью принятия решения.
Во время теста:
1. Добавляем наблюдение — номер группы, в которую попал новый пользователь.
2. Обновляем наблюдаемые доли групп q = (q(1), …, q(k)).
3. Считаем байесовское отношение правдоподобий O(q).
4. Если O(q) > 1 / α → считаем, что SRM присутствует; иначе — продолжаем.
Достоинства
– Быстрее останавливает тест в случае SRM.
– Статистика критерия и граница считаются по простым формулам.
– Для запуска достаточно зафиксировать всего один параметр — уровень значимости. Параметры априорного распределения можно задать равными единице.
Ограничения
– Обладает меньшей мощностью в сравнении с применением критерия хи-квадрат в конце эксперимента.
– Критерий консервативен: фактическая вероятность ошибки обычно ниже заданного α, из-за чего немного снижается мощность.
– Если данные поступают раз в день, их нужно случайно упорядочить перед подачей в критерий.
– Выбор параметров априорного распределения не всегда очевиден — требует экспертной настройки или моделирования.
Библиография
Основная статья:
Lindon M., Malek A. Anytime-valid inference for multinomial count data //Advances in Neural Information Processing Systems. – 2022. – Т. 35. – С. 2817-2831.
Популярное изложение:
A Better Way to Test for Sample Ratio Mismatches (SRMs) and Validate Experiment Implementations
На русском:
Как оценить валидность A/B-тестов. SRM и другие критерии
Medium
A Better Way to Test for Sample Ratio Mismatches (SRMs) and Validate Experiment Implementations
…or why I don’t use a Chi-squared test.
Forwarded from Artificial stupidity
#libraries
Еще одна интересная библиотека. В этот раз со всякими интерпретируемыми ML моделями.
imodels - sklearn-style библиотека с целым зоопарком методов интерпетируемого ML (авторы обещают там SoTA методы). Набор методов выглядит внушительно (но надо бы поковыряться).
Выглядит полезным тем, кто хочет поизвлекать правила из моделек или попробовать что-то более или менее современное из интерпретируемого ML.
Пример кода для одного из методов (а на картинке визуализация метода)
Еще одна интересная библиотека. В этот раз со всякими интерпретируемыми ML моделями.
imodels - sklearn-style библиотека с целым зоопарком методов интерпетируемого ML (авторы обещают там SoTA методы). Набор методов выглядит внушительно (но надо бы поковыряться).
Выглядит полезным тем, кто хочет поизвлекать правила из моделек или попробовать что-то более или менее современное из интерпретируемого ML.
Пример кода для одного из методов (а на картинке визуализация метода)
from sklearn.model_selection import train_test_split
from imodels import get_clean_dataset, HSTreeClassifierCV # import any imodels model here
# prepare data (a sample clinical dataset)
X, y, feature_names = get_clean_dataset('csi_pecarn_pred')
X_train, X_test, y_train, y_test = train_test_split(
X, y, random_state=42)
# fit the model
model = HSTreeClassifierCV(max_leaf_nodes=4) # initialize a tree model and specify only 4 leaf nodes
model.fit(X_train, y_train, feature_names=feature_names) # fit model
preds = model.predict(X_test) # discrete predictions: shape is (n_test, 1)
preds_proba = model.predict_proba(X_test) # predicted probabilities: shape is (n_test, n_classes)
print(model) # print the model
Forwarded from Artificial stupidity
#paper
По запросам трудящихся (@tech_priestess), поковырялся в не очень старой, но и такой уж молодой (февраль 2022) статье от авторов из весьма уважаемого университета UC Berkley: "Hierarchical Shrinkage: improving the accuracy and interpretability of tree-based methods".
Текста получилось много, потому будет заметка будет в telegraph.
P.S. Разбирал быстро, так что если видите косяки - пишите, я буду докидывать апдейты к посту.
По запросам трудящихся (@tech_priestess), поковырялся в не очень старой, но и такой уж молодой (февраль 2022) статье от авторов из весьма уважаемого университета UC Berkley: "Hierarchical Shrinkage: improving the accuracy and interpretability of tree-based methods".
Текста получилось много, потому будет заметка будет в telegraph.
P.S. Разбирал быстро, так что если видите косяки - пишите, я буду докидывать апдейты к посту.
Forwarded from Artem Ryblov’s Data Science Weekly
Elements of Programming Interviews in Python: The Insiders' Guide by Adnan Aziz, Tsung-Hsien Lee and Amit Prakash
EPI is your comprehensive guide to interviewing for software development roles.
The core of EPI is a collection of over 250 problems with detailed solutions. The problems are representative of interview questions asked at leading software companies. The problems are illustrated with 200 figures, 300 tested programs, and 150 additional variants.
The book begins with a summary of the nontechnical aspects of interviewing, such as strategies for a great interview, common mistakes, perspectives from the other side of the table, tips on negotiating the best offer, and a guide to the best ways to use EPI. We also provide a summary of data structures, algorithms, and problem solving patterns.
Coding problems are presented through a series of chapters on basic and advanced data structures, searching, sorting, algorithm design principles, and concurrency. Each chapter stars with a brief introduction, a case study, top tips, and a review of the most important library methods. This is followed by a broad and thought-provoking set of problems.
Links:
• Amazon
• Free Sample
Navigational hashtags: #armknowledgesharing #armbooks
General hashtags: #programming #python #algorithms #datastructures #interviewpreparation #interviewprep #interview
@data_science_weekly
EPI is your comprehensive guide to interviewing for software development roles.
The core of EPI is a collection of over 250 problems with detailed solutions. The problems are representative of interview questions asked at leading software companies. The problems are illustrated with 200 figures, 300 tested programs, and 150 additional variants.
The book begins with a summary of the nontechnical aspects of interviewing, such as strategies for a great interview, common mistakes, perspectives from the other side of the table, tips on negotiating the best offer, and a guide to the best ways to use EPI. We also provide a summary of data structures, algorithms, and problem solving patterns.
Coding problems are presented through a series of chapters on basic and advanced data structures, searching, sorting, algorithm design principles, and concurrency. Each chapter stars with a brief introduction, a case study, top tips, and a review of the most important library methods. This is followed by a broad and thought-provoking set of problems.
Links:
• Amazon
• Free Sample
Navigational hashtags: #armknowledgesharing #armbooks
General hashtags: #programming #python #algorithms #datastructures #interviewpreparation #interviewprep #interview
@data_science_weekly
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Протокол TLS | Компьютерные сети - 43
Лекция по протоколу Transport Layer Security.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online
Сайт для…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online
Сайт для…
Протокол TLS
В новом видео по компьютерным сетям разбираемся как работает протокол TLS. Он описывает, как совместно использовать шифрование, MAC и сертификаты для обеспечения безопасной передачи данных по небезопасным сетям.
TLS находится на транспортном уровне стека TCP/IP. Для передачи данных TLS использует протокол TCP.
TLS устроен достаточно сложно и включает несколько протоколов, разбитых на два уровня. В основе протокол записей (record protocol). Именно на уровне протокола записей производится шифрование и обеспечение целостности.
Поверх протокола записей в TLS работают несколько протоколов: протокол установки соединения (handshake protocol), оповещений (alert protocol), передачи данных (application data) и смены шифра (change cipher). В лекции подробно рассматриваем, как они устроены.
В следующем видео будем расшифровывать пакеты TLS в WireShark.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
В новом видео по компьютерным сетям разбираемся как работает протокол TLS. Он описывает, как совместно использовать шифрование, MAC и сертификаты для обеспечения безопасной передачи данных по небезопасным сетям.
TLS находится на транспортном уровне стека TCP/IP. Для передачи данных TLS использует протокол TCP.
TLS устроен достаточно сложно и включает несколько протоколов, разбитых на два уровня. В основе протокол записей (record protocol). Именно на уровне протокола записей производится шифрование и обеспечение целостности.
Поверх протокола записей в TLS работают несколько протоколов: протокол установки соединения (handshake protocol), оповещений (alert protocol), передачи данных (application data) и смены шифра (change cipher). В лекции подробно рассматриваем, как они устроены.
В следующем видео будем расшифровывать пакеты TLS в WireShark.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Как расшифровывать протокол TLS в Wireshark | Компьютерные сети - 44
Практика по разбору пакетов TLS. Просматриваем и расшифровываем TLS в Wireshark.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.…
В новом видео по компьютерным сетям на практике с помощью Wireshark анализируем протокол TLS.
Начинаем с просмотра зашифрованных пакетов TLS. В таком виде доступно всего три поля заголовка Record Layer: тип протокола TLS следующего уровня, версия TLS и длина данных. Все остальное зашифровано, посмотреть это нельзя.
Чтобы расшифровать данные, которые передаются по TLS, нужно получить ключи шифрования. Для этого можно установить переменную окружения SSLKEYLOGFILE, в которую прописать путь к файлу. В этот файл будут записываться ключи шифрования TLS. Так работают популярные библиотеки TLS: NSS, OpenSSL и boringssl. Именно эти библиотеки используют большинство браузеров. В видео я использую браузер Chrome. Полная инструкция по настройке расшифровки пакетов TLS есть на сайте Wireshark.
После настройки Wireshark начинает показывать расшифрованные пакеты TLS. Мы можем видеть не только заголовки Record Layer, но и данные, которые ранее были зашифрованы. В видео это запросы HTTP к сайту для практических занятий курса.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Начинаем с просмотра зашифрованных пакетов TLS. В таком виде доступно всего три поля заголовка Record Layer: тип протокола TLS следующего уровня, версия TLS и длина данных. Все остальное зашифровано, посмотреть это нельзя.
Чтобы расшифровать данные, которые передаются по TLS, нужно получить ключи шифрования. Для этого можно установить переменную окружения SSLKEYLOGFILE, в которую прописать путь к файлу. В этот файл будут записываться ключи шифрования TLS. Так работают популярные библиотеки TLS: NSS, OpenSSL и boringssl. Именно эти библиотеки используют большинство браузеров. В видео я использую браузер Chrome. Полная инструкция по настройке расшифровки пакетов TLS есть на сайте Wireshark.
После настройки Wireshark начинает показывать расшифрованные пакеты TLS. Мы можем видеть не только заголовки Record Layer, но и данные, которые ранее были зашифрованы. В видео это запросы HTTP к сайту для практических занятий курса.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.