Сегодня мы запустили новый сервис Нейро — новый способ поиска ответов на вопросы. Пользователь может задать Нейро любой вопрос, а тот сам подберёт подходящие материалы в Поиске, проанализирует их и соберёт найденную информацию в одном ответе, подкрепив его ссылками на источники. Нейро объединил опыт Яндекса в создании поисковых технологий и больших языковых моделей. 

Меня зовут Андрей Сюткин, и я отвечаю за ML-трек в Нейро. В этой статье покажу, как выглядит архитектура Нейро и как формируются ответы на технологическом уровне. Ну и, конечно же, поговорим о нейросетях, в том числе о YandexGPT 3, без обучения которых новый сервис просто не увидел бы свет.

Ивент шторминг (Event Storming) — это отличный способ разложить продукт по полочкам, понять, как он работает (или должен работать), а также донести это до всех участников команды, чтобы картинка в разных головах была одинаковой (что сильно упростить разработку и поможет избежать ошибок и недопониманий).

На моей практике Event Storming успешно использовался в проектировании игр, именно об этом я расскажу в данной статье.

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.

В этой заметке я хочу разобрать несколько «парадоксов» в данных, о которых полезно знать как начинающему аналитику данных, так и любому человеку, кто не хочет быть введенным в заблуждение некорректными статистическими выводами.

За рассматриваемыми примерами не кроется сложной математики помимо базовых свойств выборки (таких, как среднее арифметическое и дисперсия), зато такие кейсы могут встретиться и на собеседовании, и в жизни.

Всем привет! Меня зовут Максим, я тимлид деливери-менеджеров в Тинькофф Кассе. Расскажу, из чего состоят изменения, а также про одну методологию работы с ними. Будет кейс, как мы применяли ее на практике. Будет немного про провалы изменений, про структурный подход и факторы успеха любого изменения.

Главная мысль, которую я хотел бы до вас донести: системная работа повышает вероятность успеха изменений. Добро пожаловать под кат разговаривать про изменения!

Привет, я работаю в сфере уже около 10 лет, преимущественно по специальности чистой продуктовой аналитики. Иногда я оглядываюсь назад и думаю — с текущим пониманием что и как устроено в работе, как бы я выстраивал свой процесс обучения с нуля?

Эта статья — мои мысли на эту тему. В каком порядке и какие материалы впитывать, чтобы потом комфортно себя чувствовать в любой продуктовой компании.

Из челленджей — все материалы должны быть бесплатными, или достаточно дешёвыми, чтобы была возможность бросить учёбу на пол пути (ну не зашло, бывает) и не жалеть о потраченных деньгах на мега-курс от %big_tech_name%.

В этой статье я попробую собрать план обучения профессии, как бы я вкатывался сейчас, что бы изучал раньше, что позже, на что бы потратил больше сил и времени и т.д. У некоторых пунктов будут аналоги, можно выбрать на свой вкус без потерь качества.

По итогам всех усвоенных материалов, это будет уровень знаний примерно middle+, но фактически, грейды зависят больше от опыта (особенно в программировании), чем от объёма знаний.

И последнее — я тут не пытаюсь продать курсы, поэтому обещать что будет весело, интересно и быстро, а потом вас наймут на 300к/наносек я не буду. Будет долго, местами сложно, иногда душно, пару раз вы захотите слиться и бросить эту идею. Но… нет, тут не будет но 🙂

Ладно, пожалуй хватит предисловия, поехали.

Кластеризация — это набор методов без учителя для группировки данных по определённым критериям в так называемые кластеры, что позволяет выявлять сходства и различия между объектами, а также упрощать их анализ и визуализацию. Из-за частичного сходства в постановке задач с классификацией кластеризацию ещё называют unsupervised classification.

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

Первая часть была посвящена разбору пары десятков самых различных примеров хороших корпоративных стратегий. Вторая часть посвящена разбору такого подхода, описанию ограничений и нюансов в формировании стратегий и ответам на различные вопросы, которые могли возникнуть в процессе чтения.

Очень много букв.

Что такое хорошая стратегия? Чем она отличается от плохой? И какие примеры хороших стратегий могут наглядно это показать?В этой и следующей публикации я раскрываю примеры хороших стратегий и того, что именно делает их хорошими. В общей сложности в этой и следующей части приведу более 30 разных случаев в максимально сжатом формате.

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

Много букв.

Лид продуктовой аналитики о том, как спасал свою команду от ad-hoc-задач, что получилось, а что нет и как нужно было действовать. История внедрения изменений в команде аналитики.

Извечный вопрос: должен ли тимлид обладать самой крутой технической экспертизой в команде? Споры будут идти ещё много тысячелетий, но где, как не в крупной компании, лучше в этом разобраться?

Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.

Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?

Или потому что требования были неоднозначно сформулированы, и он их неправильно понял. А может наоборот, в них было так много информации, что потерялся фокус и некоторая часть информации пропала из виду во время разработки.

И в этой ситуации разработчик не является вредителем, который специально ошибся. На практике, если предоставить ему простые, понятные и, главное, — короткие требования — то количество ошибок, которые будут находить тестировщики, устремится к нулю.

Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.

Я считаю, что все такие задачи, заведенные после релиза, и являющиеся следствием плохо проработанной спецификации, — тоже баги. Баги, которые характеризуют качество вашего продукта.

Приветствуем всех читателей! Сегодня команда Ad-Hoc аналитики X5 Tech приоткроет дверь в увлекательный мир A/B-тестирования Causal Inference. С момента написания предыдущей статьи прошло уже 4 года. За это время наш подход к оценке инициатив значительно эволюционировал. Мы собирали бизнес-кейсы, изучали научную литературу, экспериментировали с реальными данными и в итоге пришли не только к другой модели для оценки эффекта, но и изменили методологию в целом. 

Привет, Хабр! На связи ведущий аналитик Ульяна. В первой главе я рассказала, что такое Confluence, зачем его используют и как работать с макросами. 

Во второй главе поговорим про шаблоны и метки, которые помогут организовать процессные и проектные рутины, например ведение MN, RFC и другое интересное.

Привет, Хабр! Я Федор Щудло, team lead и fullstack-разработчик. Всего я в разработке 15 лет, из них 11 в роли team lead.

Три года назад я сменил работу и занялся проектом, состояние которого можно описать кратко: ему 25 лет.

За этот долгий срок проект пережил несколько слияний и разделений компании, означающих серьезные потери людей, знаний, и даже исходников от некоторых сервисов по юридическим соображениям.

На проекте были благополучные периоды, когда были созданы очень крутые и амбициозные вещи. Но были также периоды, когда команды еле хватало на выполнение самых срочных задач. И в это время многие сделанные или не доделанные большие штуки изрядно обветшали.

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

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