Hopscotch analytics

Привет! В прошлом посте я писал о том, что делаю библиотечное решение. После этого мы пообщались с Максом Годзи, фаундером Retentioneering, с которым мы до сих пор дружим, и решили, что для всех будет лучше, если мы затащим это решение под бренд Rete. Вчера мы опубликовали release-candidate версию пакета, так что вы уже можете начать его пробовать. Документация тут. pip install --pre retentioneering В платформенное решение я пока (временно?) перестаю играться. В это новое время LLM, когда код перестаёт быть ценностью, ещё меньше становится понятно как продавать с нуля чисто платформенное решение. А вот к библиотечному наоборот, интерес может быть ещё выше, чем раньше, потому что с теми же LLM а) агенты становятся пользователями библиотеки, б) живые пользователи могут гораздо легче контрибьютить. Кстати да, в retentioneering мы запилили локальный MCP-сервер и скиллы (пока в бета-версии), так что вы теперь можете просить вашего агента анализировать данные с помощью инструментов retentioneering и генерировать отчёты на блюдечке. В общем, пробуйте, оставляйте фидбэк, ну и звёздочек тоже отсыпьте репозиторию, пожалуйста. Будем рады! https://github.com/retentioneering/retentioneering-tools

Я как-то подустал ходить по людям и демонстрировать платформенное решение Hopscotch, так что решил запилить библиотечный вариант решения: питоновскую hopscotch-lib. Пока затащил туда граф переходов и step sankey, дальше поднятну кластеризацию и дата процессоры. Вот как это выглядит в VS Code, например (см. скриншоты). Если интересно потестировать — дайте знать.

Я как-то подустал ходить по людям и демонстрировать платформенное решение Hopscotch, так что решил запилить библиотечный вариант решения: питоновскую hopscotch-lib. Пока затащил туда граф переходов и step sankey, дальше поднятну кластеризацию и дата процессоры. Вот как это выглядит в VS Code, например (см. скриншоты). Если интересно потестировать — дайте знать.

10 дней до DataFest в Белградском университете 😎 Спрос на 24.05 оказался даже выше, чем мы ожидали 🫡 Поэтому 31.05 продолжаем на более крупной площадке 👍 📅 31 мая — ФОН, Белградский университет • 24 доклада · 3 сцены · нетворкинг и афтепати • Trust in AI • Agents & LLMs • Ranking & Banking • Voice & Robotics 🗣 Язык: английский 👉 Регистрация и расписание уже доступны Вход бесплатный · регистрация обязательна //регистрация через гугл/гит сейчас не работает Увидимся на DataFest 😎

Выступаю 31 мая на белградской площадке DataFest. Расскажу про графы переходов в аналитике пользовательского поведения. Приходите! А вообще у меня закончился курс в Constructor University. Отхожу от него. Чуть позже расскажу, как дела.

В документации к Amplitude сказано, что они используют NMF для кластеризации пользователей. Я как-то никогда о таком методе не слышал. Оказалось, что это похоже на SVD: мы аппроксимируем матрицу (пользовательских фичей) произведением не трёх, а двух матриц (но положительных). Типа X ≈ WH, где W — это координаты траекторий в новом сжатом пространстве фичей пользователей, а H — это координаты точек в старом пространстве, задающие поведенческие паттерны. И у такого подхода есть много практических бонусов. • Траектории представляются как линейные комбинации паттернов. Это очень круто, потому что в жизни так не бывает, что пользователь жёстко относится к какому-то поведенческому кластеру. Скорее всего его траектория представляет смесь некоторых базовых паттернов. • В новом пространстве W мы можем провести любую кластеризацию: хоть K-Means, хоть что угодно ещё. И из-за того, что это новое пространство подготовлено, кластеризация в нём, как мне показалось, получается более толковой. • Поведенческие паттерны (матрица H) интерпретируемы, хотя интерпретируемы они примерно в той же степени, как центры кластеров в K-Means. • Можем управлять снижением размерности исходного пространства сильно коррелирующих фичей (если фичи — это счётчики событий, то они часто сильно коррелируют друг с другом). • Можно следить за дрифтом паттернов во времени. Разбиваем траектории на два куска во времени "до" и "после", строим для каждого NMF-расложение, мапим строки матриц H_before и H_after друг в друга, а дальше смотрим через W_before и W_after, в какой степени каждый паттерн представлен в каждом из датасетов. Ещё в этой документации дана ссылка на статью Türkmen - A Review of Nonnegative Matrix Factorization Methods for Clustering, в которой рассказывается про матчасть NMF-разложения, про приложения метода для кластеризации, про сравнение с K-means. Хорошая статья. В общем, мне метод понравился, и я пробую теперь его затащить в Hopscotch. На скриншоте матрица H показывает, что есть три поведенческие компоненты: 1. пользователи, пытающиеся зарегистрироваться, 2. "обычные пользователи", у которых фокус на "базовые" события. 3. случайные прохожие, которые не уходят дальше main. Если интересно потестировать это, дайте знать.

Моя подруга, настоящий учёный Люба Тупикина, пригласила меня почитать с ней спецкурс про анализ пользовательского поведения (большая честь!). Точнее, курс будет про различные практические применения эмбеддингов, а моя часть будет про эмбеддинги пользовательских траекторий. У меня к вам вопрос: может быть у вас есть на примете какие-то классные статьи на эту тему? Меня не забанили в перплексити, и у меня есть свой некоторый шортлист, но может быть вы что-нибудь подскажете интересное? Ну и чтобы два раза не вставать. Я тут понял, что по какой-то непонятной причине я ни разу не рассказывал публично про статью Любы Singh, Tupikina, Lécuyer, Starnini, Santolini - Charting mobility patterns in the scientific knowledge landscape. А статья любопытная. Авторы там изучают траектории учёных в пространстве тегов к научным статьям, смотрят на паттерны поведения (кто вокруг одной и той же темы крутится, кого бросает из стороны в сторону), причём используют для этого в том числе методы из урбанистики, связанные с изучением пассажиропотока. Формализация не совсем обычная: я привык, что одно событие в ивентстриме кодируется "единичным" вектором (все нули, кроме единички на одной позиции), а там у одной точки траектории, одной статьи, может быть много тегов, а значит и много единичек в векторе. Но дальше идеи те же, как и в продуктовой аналитике: имея траектории из точек в этом многомерном пространстве, хочется заэмбедить траектории и провести кластеризацию в этом пространстве. Я был уверен, что мы эту статью разбирали ещё в Retentioneering Journal Club, но сейчас поискал -- нет, не разбирали. Посмотрите, если любопытно.

Всем привет. Мы с @kenaku допилили Hopscotch — платформу для анализа пользовательского поведения — до презентабельного состояния, и теперь очень хотим найти первых пользователей и первые юзкейсы. Мы понимаем, что пока предлагаем удочку вместо рыбы (над UX не успели поработать 😞, всё-таки это MVP), поэтому в первую очередь приглашем людей, знакомых с Retentioneering. Но это необязательное условие: если есть интерес к задаче анализа пользовательского поведения, я могу лично рассказать, как с этим можно управляться. Что сейчас умеет хопскотч: • Загрузить ивентстрим (CSV-файл до 100Мб с колонками вида user_id, event, timestamp + опционально session_id и сегментные колонки); • Подготовить ивентстрим к анализу: отфильтровать траектории по длине, наличию/частоте события, наличию паттерна (A->B->.*->C), нарезать участки траекторий и т.п.; • Построить transition graph, sankey чарт (с интерактивным выбором паттерна траектории); • Сравнивать два сегмента траекторий (чем отличается поведение по платформам, маркетинговым источникам, группам AB-теста, "до" и "после" какой-то даты); • Кластеризовать траектории и анализировать кластеры, сделать из них сегмент и сравнивать графы и санки по кластерам; • Бесшовно переключаться между пользователями и сессиями. • Bonus track: можно построить граф переходов состояний пользователей по growth-модели Duolingo. В общем, как Retentioneering, только no-code, существенно быстрее (от 10 до 100 раз), с удобными UI-фишками и поддержкой дифф-режима. И да, AI там тоже будет, если удастся сделать его не просто модной свистелкой. Напишите мне в личку @wowone, пожалуйста, если вы хотите попробовать. Очень ждём!

Всем привет. Мы с @kenaku допилили Hopscotch — платформу для анализа пользовательского поведения — до презентабельного состояния, и теперь очень хотим найти первых пользователей и первые юзкейсы. Мы понимаем, что пока предлагаем удочку вместо рыбы (над UX не успели поработать 😞, всё-таки это MVP), поэтому в первую очередь приглашем людей, знакомых с Retentioneering. Но это необязательное условие: если есть интерес к задаче анализа пользовательского поведения, я могу лично рассказать, как с этим можно управляться. Что сейчас умеет хопскотч: • Загрузить ивентстрим (CSV-файл до 100Мб с колонками вида user_id, event, timestamp + опционально session_id и сегментные колонки); • Подготовить ивентстрим к анализу: отфильтровать траектории по длине, наличию/частоте события, наличию паттерна (A->B->.*->C), нарезать участки траекторий и т.п.; • Построить transition graph, sankey чарт (с интерактивным выбором паттерна траектории); • Сравнивать два сегмента траекторий (чем отличается поведение по платформам, маркетинговым источникам, группам AB-теста, "до" и "после" какой-то даты); • Кластеризовать траектории и анализировать кластеры, сделать из них сегмент и сравнивать графы и санки по кластерам; • Бесшовно переключаться между пользователями и сессиями. • Bonus track: можно построить граф переходов состояний пользователей по growth-модели Duolingo. В общем, как Retentioneering, только no-code, существенно быстрее (от 10 до 100 раз), с удобными UI-фишками и поддержкой дифф-режима. И да, AI там тоже будет, если удастся сделать его не просто модной свистелкой. Напишите мне в личку @wowone, пожалуйста, если вы хотите попробовать. Очень ждём!

Вес МакКинни, основатель Pandas, тут провёл мини-исследование про то, как плохо LLM умеют суммировать числа из CSV-данных. В исследовании он буквально просил сделать SELECT group, SUM(value) FROM data GROUP BY group, но без использования кода, и наблюдал, как результаты разваливаются по мере роста объёма данных. https://wesmckinney.com/blog/llms-arithmetic/ Со своей стороны могу добавить, что на моей практике LLM демонстрировали бестолковую работу с CSV-данными в принципе. Они даже с трудом обращались к ячейкам таблицы по заданным координатам (X, Y). В моём случае мне помогла трансформация данных к JSON-формату типа [{"row": "X", "column": "Y", "value": Z}, ...]. После этого они хотя бы переставали промахиваться ячейками. С другой стороны, не понятно, почему в этом исследовании автор запрещал использование кода. Наверняка LLM-ка сгенерировала бы корректный SQL и дала бы правильный ответ. Но даже если и смогла бы, скармливать сырые данные LLM кажется как минимум пустой тратой токенов.

Неплохая статья про исследование пользовательского поведения в геймдеве: Interactive Player Journeys: Co-designing a Process Visualization System to Video Game Analytics. Используют граф переходов как главную визуализацию. Отмечают его следующие достоинства: - Интуитивно понятен. - Позволяет расположить ноды в порядке, соответствующем флоу пользователя. - Позволяет сравнивать группы пользователей (те, кто дошёл до таргетного действия против тех, кто не дошёл). - Чтобы уменьшить кардинальность событий, можно, конечно, их фильтровать, а лучше выделять устойчивые подпоследовательности и склеивать их в отдельные события. - Из любопытного: вместо названий событий используют соответствующие этим событиям иконки из игры, это существенно снижает зашумлённость визуализации (я хз правда, как они эти иконки различают, но заказчики, говорят, были довольны; на картинке к посту как раз этот граф). Часть из этого уже реализована в графе переходов в retentioneering. А пока я пилю ещё более продвинутый граф для Hopscotch.

Начал читать книжку Behavioral Data Analysis with R and Python. Заголовок заманчивый. Но в первой же главе автор начинает набрасывать: A potential solution to the problem of confounders would be to add to the regression all the variables we can. This mindset of “everything and the kitchen sink” still has proponents among statisticians. и там становится понятно, что эта книжка скорее про causal inference. Ок, я вполне уважаю эту предметную область, но как-то её адепты, по крайней мере у меня в linkedin, довольно агрессивно её насаждают: мол, эта ваша предиктивная аналитика бесполезна, когда речь заходит о поиске причинно-следственных связей. И вот, значит, в этой первой главе автор приводит пример на синтетических данных, когда добавление фичей искажает выводы (позволю себе не описывать здесь этот пример, он довольно элементарный). Но делает это на примере линейной регрессии. Я вообще не знаю, в индустриальном дата саенсе кто-нибудь использует линейную регрессию всерьёз? Действительно, модель там тупит и даёт неверные выводы. Но если брать нормальный GBDT, то проблем с causal inference там нет никаких. Да, я из этих самых "proponents among statisticians", которые наваливают фичей, чтоб борта датафреймов трещали (на первой итерации), и потом дальше с этим разбираются (include them all, God will recognize His own). Действительно, там могут случаться всякие наводки, когда фичи начинают фонить друг об друга. Они неплохо описаны тут у Лундберга, автора библиотеки shap. Но в этом и заключается часть задачи дата саентиста: устранить эти наводки (в частности, с помощью методов casual inference), а слепо доверять feature importance модели или shap values никто и не собирается. Более того, на практике ложные влияния часто становятся понятны на глаз (у меня был прикольный пример, когда сообщения пользователей в чатбот якобы влияли на отток, а потом оказалось, что в этих случаях сообщения были вида "помоги мне отписаться"). А вот если мы скормим мало фичей, то есть риск потерять скрытые факторы, влияющие на таргет, и тут уже ничего не попишешь. Так вот, у меня к вам вопрос. Как вы подходите к causal inference? Например, вам надо определить, какие продуктовые фичи влияют на отток. Вы строите какую-то предиктивную модель и дальше детально разбираетесь с feature importance? Используете какие-то методы causal inference? Ну и если есть кто-то, кто эту книгу уже читал, поделитесь впечатлениями. Стоит читать?

А пока я ищу работу (говорят, это нынче может много времени отнимать), мы с Максом Годзи из Retentioneering решили снова заколабиться и попробовать вернуться к консалтингу/аутсорсу. Если вам нужны советы по анализу пользовательского поведения или продвинутая аналитика под ключ, то дайте знать. У нас есть опыт проведения таких проектов в е-коме, геймдеве, приложениях о путешествиях, здоровье/фитнесе, трейдинге и банкинге. Темы, в которые мы умеем: - Предсказать таргетное действие (отток, покупка) и определить, какие продуктовые фичи или действия пользователя на него влияют. - Определить корневую причину падения/роста метрик. - Почему A/B эксперимент не прокрасился или прокрасился в красный? - Кластеризовать пользователей по их поведению и степени влияния на таргет. - Аналитика диалогов. Что спрашивают? Как протекает диалог? Что можно улучшить в ответах? - Оптимизация онбординговых воронок. Про Hopscotch тоже будут новости, но чуть позже.

Новость. Я больше не работаю в Perplexity. Не скрою: меня уволили. Однако не известно, сколько бы ещё я сам там вывез: это самое жёсткое место из всех, где я работал. Амбициозная компания, хочет двигаться очень быстро, давление высокое.

Не люблю хайп вокруг LLM, но тут мне рассказали две любопытных истории, хочу ими с вами поделиться. Первая от моего друга, аналитика в одной из крупных финансовых структур в России. Попробовал он тут на днях браузер Comet от Perplexity со встроенным AI-агентом. Оказалось, что он отлично подходит для их рутинных задач chart2text: прокликать 100500 дашбордов, просмотреть их и написать отчёт о том, что там происходит. Теперь собираются раскатывать на всех аналитиков. Другая -- от Елены Буниной, которая сделала ШАД и была руководителем HR в Яндексе. Я тут на прошлой неделе познакомился с ней лично, хотя впервые мы с ней общались 20 лет назад -- я сдавал ей экзамен по алгебре на мехмате. Так вот, она же математик, доктор наук, все дела. Попросила она тут GPT-5 причесать текст в одной из её статей. LLM поправила и в конце добавляет: а вообще у тебя там одна лемма неаккуратно доказана. А она возьми да и предложи: так докажи нормально. И оно взяло и доказало!

И это приводит к следующему эффекту. Для того, чтобы собрать оценки, теперь достаточно написать промпт, ну и немного его потюнить. Это существенно сокращает расходы и позволяет двигаться очень быстро. Особенно LLM хороши как наколеночные классификаторы, которые часто требуются в аналитических замерах. Ты ей просто говоришь: разметь данные так-то и так-то, и она размечает! Ну и в написании кода они, конечно, хороши. Я довольно долго выбирал удобный для себя инструмент для написания аналитического кода. А кода я пишу много, поэтому выбирал я придирчиво. В итоге остановился на Cursor, стилизовал его под PyCharm (темы, шрифты), а вот от самого PyCharm пришлось отказаться. Несмотря на все косяки Cursor, он оказался лучше очень красивого, но тяжеловесного PyCharm, который особенно стал жать в контексте авто-комплита: глуповатый и нерасторопный. Ну и отдельная тема -- это создание всяких вспомогательных интерактивных UI-тулов с помощью AI-ассистентов. Теперь можно на коленке клепать буквально одноразовые тулы, подходящие чисто для твоей задачи! Какой-нибудь кастомный side-by-side интерфейс, например, запилить. При этом глазами всё равно приходится просматривать много документов для оценки качества, дебага алгоритмов ранжирования. Но и здесь есть LLM-помощники. С нашим новым браузером Comet можно спросить, что там происходит на странице, хорошо ли она отвечает на запрос. Да и просто в Perplexity можно спросить, что пользователь имел в виду таким-то запросом. А мозголомных запросов здесь существенно больше по сравнению с тем, что было в Яндексе -- пользователи понимают возможности LLM и не стесняются их использовать. В общем, прогресс не остановить (c). А так работы много, работа интересная, скорость движения ошеломительная, конкуренция жёсткая. Надеюсь, это только начало и впереди ещё куча всего интересного.

А дальше наша служба воплотилась в самостоятельный продукт -- известный теперь под именем Toloka. И тут бы появиться той самой продуктовой аналитике. Но тогда мы не были бизнесом в прямом смысле этого слова, и это накладывало отпечаток на все процессы. Яндекс был и оставался единственным крупным заказчиком, мы были 100% дотационным проектом, рыночных механизмов не было. Нет, на какие-то продуктовые метрики типа ретеншена мы конечно смотрели, но как я сейчас понимаю, это было довольно наивно. Для сравнения, когда я перешёл после Яндекса в Ultimate Guitar, мы каждое утро начинали с просмотра основных метрик, каждый новый пользователь, каждый ушедший пользователь был наперечёт -- это были деньги. Собственно, я и решил уйти из Яндекса как раз потому что чувствовал, что мы делаем что-то не то, а как делать то -- я не знал. Да даже во всём Яндексе аналитика была, на мой взгляд, несколько специфичной: была тенденция заниматься тяжеловесными исследованиями, интересными для аналитиков, но не очень полезными для бизнеса, а сами аналитики были довольно хардкорными ребятами, хорошо разбирающимися коде и статистике, но не особо понимающими суть бизнеса и продукта. Хотя что-то крутое, безусловно, было и в этом. Например, та самая линеаризация в AB-тестах, была придумана в Яндексе как раз в это время. Вот в таком состоянии в 2019 году я ушёл из Яндекса в первый раз. Часть 2 При поиске работы оказалось, что снаружи толком никто не понимает, чем же я занимался в Яндексе. Поэтому многие пункты про исследования, которые я считал классными, пришлось убрать. При этом не могу сказать, что поиски шли плохо: на собесах говорили, мол, мы ничего не поняли про твой опыт, но кажется, что ты умный и наверно справишься и с нашими задачами. Итак, я за короткое время сменил несколько компаний, работая на них ± по году. С одной стороны, я быстро набирал тот самый продуктовый опыт, которого мне не хватало в Яндексе, наблюдая за разными компаниями изнутри. А с другой -- оказалось, что я всё-таки по духу тот самый хардкорный аналитик, и с бизнесом мы не всегда общались на одном языке. Эстетика экселя, бесконечное колчиество дашбордов, борьба с неправильной интерпретацией/методологией в AB-тестах -- вот это прям то что мне не нравилось. Однажды в каком-то паблике я увидел пост Максима Годзи про то, что они ищут как раз хардкорного аналитика. Так я познакомился с ним и с его библиотекой Retentioneering. Но к его команде я присоединился только спустя пару лет. И оказалось, что в продуктовой аналитике всё же есть место для интересных и нетривиальных задач -- анализ пользовательского поведения как раз из таких задач. В Retentioneering я определённо был на своём месте. Будучи сильно подверженным влиянию синдрома самозванца, я впервые в жизни ощутил, как могут быть мощны мои лапищи. И journal club там тоже был ^_^ К продукту я прикипел настолько, что даже после потери инвестора и роспуска команды, я продолжал тащить проект по мере сил, уже имея новую постоянную работу. Однако закончилась и эта история, после которой я решил делать Hopscotch. Часть 3 И вот примерно в это время меня настигает оффер от Perplexity. Забавно, что когда готовил для них резюме, то заново включил в него все те вышеупомянутые пункты про работу в Яндексе, которые исключал ранее. Так вот. Perplexity. Команда ранжирования. Оценка качества поиска. В принципе, всё довольно похоже на мой опыт из Яндекса. Поисковые запросы и ответы. Надо понять, где мы продалбываемся, сформулировать и приоритезировать набор проблем и отнести их в разработку, мол, чините. Но есть одно очень большое отличие. LLM. Даже в середине 2010х было уже понятно, что ML близок к тому, чтобы сравняться с качеством с асессорами. Тогда наш антифрод накрывал нескольких читеров с автоматическими классификаторами, которые палились высокой скоростью, но не сказать, что выбивались по качеству. А теперь в эпоху LLM качество таких классификаторов ещё больше усилилось. Да, они бывает галлюцинируют, но в то же время они, сюрприз, умеют читать тексты существенно внимательнее людей.

Привет. Давайте расскажу, чем я занимаюсь сейчас в Perplexity. Для этого ретроспектива необходима, поэтому длиннопост будет в трёх частях. Часть 1 Я уже упоминал здесь, о том, что в каком-то смысле вернулся к корням. Так вот, начинал я свой аналитический путь с аналитики поиска в Яндексе. Сначала это вообще была примитивнейшая работа асессором. Это когда тебе нужно оценить, насколько хорошо ответил поиск с точки зрения некоторого аспекта. А аспектов этих очень много. Самый просто релевантность -- насколько хорошо отдельный документ отвечает на данный запрос. А можно оценивать не документы, а картинки или сниппеты (короткий текст-выжимка рядом со ссылкой в результатах поиска). А можно оценивать документы попарно (side-by-side), отвечая на вопрос, какой из двух документов лучше. В общем, тысячи их. На основе таких оценок можно считать разные метрики качества поиска. А можно эти оценки подавать в ML и настраивать разные классификаторы/ранкеры. Как и в известном сравнении, что любой человек может сделать гамбургер, но не любой человек может сделать McDonalds, так и в нашем случае, когда нужно производить такие оценки в промышленных масштабах, всплывает миллион разных проблем. Организацией этого всего наша служба и занималась в Яндексе. Изначально (а это был 2010 год) работа асессором служила мне исключительно подработкой. Так-то я в аспирантуре учился, а здесь предлагали удалённую работу -- просто мечта. Довольно быстро меня пригласили в штат менеджить асессоров. Этим я позанимался пару лет. Стало понятно, что в Яндексе с его модным ML прикольно, поэтому я ушёл из аспирантуры, не защитившись, поступил в Computer Science Center (это такой питерский ШАД), и перевёлся на аналитика. Это был 2013 год. Тогда конечно аналитика ещё не была такой, какой мы знаем её сейчас. Питон ещё не был однозначным лидером среди скриптовых языков, поэтому я даже на Perl успел пописать. R был, и я довольно много на нём писал, но потом ожидаемо перешёл на питон (в больших компаниях так всегда происходит). А по запросу "t-test" гуглились в основном медицинские методички. Любопытно, что заниматься мне приходилось в основном не метриками, не AB-тестами, а довольно хардкорными исследованиями. Ну например, практическая задача: вот у нас пять асессоров оценили один и тот же документ; двое сказали, что он хороший, один сказал, что нормальный, а двое сказали, что плохой. Как выбрать наиболее приближенную к действительности оценку? Или вот ещё: очевидно, что для контроля качества асессоров нужно проверять их оценки, но как бы сделать так, чтобы проверять приходилось поменьше, а гарантии качества какие-то сохранялись? Оказалось, что подобные исследования вполне себе ведутся в академической среде, есть много статей на эту тему, и так появился первый мой journal club (мы его называли Бабелевскими чтениями), прочитали в общей сложности больше 200 статей, ЕМНИП. А в 2015 даже написали статью на эту тему и выступили с ней на топовой конференции по проблемам поиска SIGIR в Сантьяго 😎. То исследование вообще достойно отдельного рассказа. Было эпично! Так вот, в те годы я хорошо поездил по разным конференциям. Жаль только, что я тогда только нащупывал свой путь, понимал суть происходящего не очень хорошо и не выжимал пользу из конференций по максимуму. Потом ещё была одна статья на KDD-2020.