New Yorko Times

От почти-дубликатов к импакту на всю индустрию. Часть 1
#career #projects #research_integrity

Пора бы рассказать и про один из самых интересных проектов: с идеей, реализацией, конфликтами, импактом и, внезапно, теорией графов. У нас почти все проекты top-down, то есть менеджеры все разрулили и спустили нам задачу. Но иногда бывает и bottom-up – сам что-то придумал и пошел питчить, толкать в прод. Вот я пришел в компанию и поразмыслил: “Так, издательство. Прилетают 2.5 млн драфтов статей в год. А что если там дубликаты? Небось куча времени вхолостую”. Адаптировали на PySpark реализацию LSH для поиска почти-дубликатов (на тот момент в mllib спарка реализация была экспериментальной, мы в итоге свою со скалы переписали; А как это делать без спарка – рассказывал в этом посте), прогнали на ~5 млн. названий статей – и увидели, что около 25% всех названий имеют почти-дубликат. Глаза слегка на лоб полезли: “что, серьезно? Когда прилетает новая статья, шанс 1/4, что ее уже видели?“

Стали параллельно трубить о находке и делать EDA (вот тут лучше было подождать результатов анализа). Ну, конечно, большинство дубликатов – безобидные, это resubmission, когда статью отвергли, а она после переработки возвращается. Но ~ в 10% случаев это simultaneous submission – когда автор посылает статью в 2 или более журналов одновременно. Вот это не очень, и такое лучше бы ловить в самом начале, хотя бы чтоб сэкономить усилия издателей и ревьюеров.

Даже в такой простой задаче помогает понимание, что число пар – квадратично по числу объектов. То есть для 5 млн статей это ~12.5 трлн. пар, такое не надо втупую считать (вот это приходилось не раз объяснять менеджерам). Еще мы заметили, что куча навзаний – затычки типа “letter to the editor” или “response to reviewers”, и конечно, они дают квадратичное число таких тривиальных пар – такое надо отсеивать.

Пока суть да дело, я поупражнялся в систем дизайне – накидал приложение, где можно ввести название статьи и получить список похожих (там Datasketch LSH, Redis, докер, Fast API, streamlit). Отнес демку издателям, понял, что попал в точку. У них никаких тулов нет, чтоб ловить дубликаты статей, посланных в разные журналы (в Editorial Manager есть только SQL-решение из 60-ых годов, масштабирующееся только на один журнал). Так что поиск дубликатов сводился к чистому дежавю “Хм, знакомая статья” или “Джооон! Ты ж уже эту статью смотрел?”. И тут моя демка уже начала вовсю использоваться, даже несмотря на то, что в индексе был статический дамп статей и самые свежие статьи не показывались.

Прототип есть, валуе замаячило на горизонте (если накидать на салфетке, получалось ~250к/год сэкономленного времени издателей) и тут началось самое интересное (нет) – месяцев 7 пришлось гоняться за одним-единственным менеджером, поскольку у него именно та команда разработки, которая способна мое поделие вкорячить в прод. А там уже OKR, все дела, так просто в новый проект не впишешься, в-общем, пришлось ждать нового года и только заходом через топ-менеджера убеждать, что мы тут не с куском куска пришли, а поделие наше надо деплоить.

Продолжение ⬇️

www.group-telegram.com/jp/new_yorko_times.com/183

8.4K viewsYury Kashnitsky, edited  Oct 16, 2023 at 08:54

От почти-дубликатов к импакту на всю индустрию. Часть 1
#career #projects #research_integrity

Пора бы рассказать и про один из самых интересных проектов: с идеей, реализацией, конфликтами, импактом и, внезапно, теорией графов. У нас почти все проекты top-down, то есть менеджеры все разрулили и спустили нам задачу. Но иногда бывает и bottom-up – сам что-то придумал и пошел питчить, толкать в прод. Вот я пришел в компанию и поразмыслил: “Так, издательство. Прилетают 2.5 млн драфтов статей в год. А что если там дубликаты? Небось куча времени вхолостую”. Адаптировали на PySpark реализацию LSH для поиска почти-дубликатов (на тот момент в mllib спарка реализация была экспериментальной, мы в итоге свою со скалы переписали; А как это делать без спарка – рассказывал в этом посте), прогнали на ~5 млн. названий статей – и увидели, что около 25% всех названий имеют почти-дубликат. Глаза слегка на лоб полезли: “что, серьезно? Когда прилетает новая статья, шанс 1/4, что ее уже видели?“

Стали параллельно трубить о находке и делать EDA (вот тут лучше было подождать результатов анализа). Ну, конечно, большинство дубликатов – безобидные, это resubmission, когда статью отвергли, а она после переработки возвращается. Но ~ в 10% случаев это simultaneous submission – когда автор посылает статью в 2 или более журналов одновременно. Вот это не очень, и такое лучше бы ловить в самом начале, хотя бы чтоб сэкономить усилия издателей и ревьюеров.

Даже в такой простой задаче помогает понимание, что число пар – квадратично по числу объектов. То есть для 5 млн статей это ~12.5 трлн. пар, такое не надо втупую считать (вот это приходилось не раз объяснять менеджерам). Еще мы заметили, что куча навзаний – затычки типа “letter to the editor” или “response to reviewers”, и конечно, они дают квадратичное число таких тривиальных пар – такое надо отсеивать.

Пока суть да дело, я поупражнялся в систем дизайне – накидал приложение, где можно ввести название статьи и получить список похожих (там Datasketch LSH, Redis, докер, Fast API, streamlit). Отнес демку издателям, понял, что попал в точку. У них никаких тулов нет, чтоб ловить дубликаты статей, посланных в разные журналы (в Editorial Manager есть только SQL-решение из 60-ых годов, масштабирующееся только на один журнал). Так что поиск дубликатов сводился к чистому дежавю “Хм, знакомая статья” или “Джооон! Ты ж уже эту статью смотрел?”. И тут моя демка уже начала вовсю использоваться, даже несмотря на то, что в индексе был статический дамп статей и самые свежие статьи не показывались.

Прототип есть, валуе замаячило на горизонте (если накидать на салфетке, получалось ~250к/год сэкономленного времени издателей) и тут началось самое интересное (нет) – месяцев 7 пришлось гоняться за одним-единственным менеджером, поскольку у него именно та команда разработки, которая способна мое поделие вкорячить в прод. А там уже OKR, все дела, так просто в новый проект не впишешься, в-общем, пришлось ждать нового года и только заходом через топ-менеджера убеждать, что мы тут не с куском куска пришли, а поделие наше надо деплоить.

Продолжение ⬇️

BY New Yorko Times