DeepStuff

В чём проблема с добавлением новых данных в GPT-модели?
Возможно, вы заметили, что с каждым обновлением продвигается дата "knowledge cutoff" — момента, до которого модели знают, что происходило в мире.

Какова же проблема? На самом деле, существует два этапа при обучении моделей:

1) Создатели собирают всевозможные данные из интернета, тратя сотни миллионов на обучение модели.
2) Создатели собирают основные новости по разным направлениям и делают дообучение модели.

ChatGPT Knowledge Cutoff — 12/23, Opus — 8/23.

Какие последние версии библиотеки python-telegram-bot знают сети:
GPT-4 — 13.12 (выпущено 2022-05-26), Opus — 20.3 (выпущено 2023-05-07).

Версии библиотек — это самый простой пример, хотя OpenAI и GitHub, находясь в одной компании, могли бы постараться сделать больше! Если вы погрузитесь глубже в любые вещи за пределами новостей, ситуация будет такой же. Статьи, мемы в интернете и т.д.

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

@aihappens

LONG-FORM FACTUALITY IN LARGE LANGUAGE MODELS

Принято считать, что LLM часто галлюцинируют, и вообще у них большие проблемы с фактической информацией. Вот если GPT-4 мне ответит: «...и Эйфелева башня, открытая в 20м веке, обязательны к посещению» — я должен проверять период открытия? Наверное, да — уже не одна сотня людей на подобном погорела (вспомните случай с адвокатом).

Сотрудники DeepMind решили подойти к вопросу более системно и исследовать вопрос: могут ли модели текущего поколения успешно перепроверять сами себя при условии наличия доступа к гуглу? Для тех, кому лень читать, краткие выводы:
1) LLM ЛУЧШЕ ЛЮДЕЙ в перепроверке информации
2) LLM в 20 раз дешевле ручной валидации фактов
3) (конечно же) бОльшие модели лучше (косой взгляд в сторону тех, кто использует GPT-3.5)
4) GPT-4-Turbo значимо лучше остальных моделей
===

Сначала авторы генерируют 2280 относительно длинных ответов модели, запромченной упоминать как можно больше фактов - на этой выборке будут производиться замеры. Для того, чтобы перевалидировать текст, предлагается следующая многоступенчатая схема:
1) разбить текст на отдельные факты
2) сделать каждый факт самодостаточным и атомарным (например, заменив местоимения «она» на «Эйфелева башня»)
3) для каждого факта проверить релевантность оригинальному запросу
4) наконец, запустить агента в интернет с целью проверки каждого атомарного факта. Такой агент сам пишет запросы, сам открывает и читает страницы, сам может найти противоречие между разными источниками и в теории определить, какой более приоритетен
(и для всех пунктов, конечно же, используются LLM - никаких людей)

Такой пайплайн авторы называли SAFE (Search-Augmented Factuality Evaluator). На своём датасете они тоже метрики меряют, но отдельно сравнивают с людьми на датасете, созданном в рамках одной из прошлых работ в 2023м году. Там ~500 промптов, в ответах на которые выделено 16k фактов. Для каждого живой человек искал подтверждение, правда, только в рамках Википедии, а не во всем интернете.

В 72% случаев SAFE выдаёт тот же ответ, что и человек (то есть соглашается, что факт либо правильный, либо неправильный). «Пффф! ошибается в четверти случаев» — скажут одни. «Ща мы тут проверим, кто ошибается» — отвечают авторы. Затем они берут 100 примеров, где ответы модели и людей отличаются, и перепроверяют уже сами, глядя на результат. Оказывается, в 76% случаев они согласны с моделью — просто люди либо ошиблись, либо у них не было всего контекста (вне Википедии).

Код с промптами: тут и тут (разные папки одного репозитория, мб ещё где-то есть)

Опубликован новый пример дизайна ML системы по шаблону Reliable ML
Пополняем базу примеров хороших дизайн-документов

Сегодня добавили новый пример дизайн-документа - проект от Симулятора ML. Даниил Картушов и команда представляют pet project по разработке чат-бота для поиска ответов на разные запросы в телеграм-каналах.

Опубликованный дизайн-док - пример хорошо проработанного и не перегруженного лишней информацией документа. Для более глубокого погружения в потребности пользователей в части про бизнес-требования команда проекта добавила User Story Map и Customer Journey Map. Это, кстати, может стать отличным дополнением к шаблону дизайн-документов.

Огромное спасибо авторам документа за вклад в развитие ML-дизайна.

Шаблон дизайн-документа ML-систем от Reliable ML
Материалы по работе с дизайн-доком
Как написать док вместе с Reliable ML

Stay tuned!

Ваш @Reliable ML

#business #tech #ml_system_design

Чем занимается наша R&D команда.

С годами задачи меняются: сначала был фокус на развитие одной R&D технологии (трансформерной персонализации), затем на ее распространение по Яндексу, а сейчас мы с командой занимаемся R&D для рекомендаций в целом, не ограничивая себя одной конкретной технологией.

На что декомпозируется работа:

1. Поиск новых технологий — постоянное изучение arxiv'а, конференций, воркшопов, инженерных блогов. Об этом я писал чуть подробней в посте Про чтение статей (для R&D). Потребность в R&D, как правило, драйвится с двух сторон: либо мы сами "приносим" новые технологии для улучшения рекомендаций в продуктах; либо продукты приходят к нам со своими проблемами. Для нас первый сценарий реализуется чаще, поэтому поиск новых технологий — очень важная часть работы.

2. Экспериментальная деятельность, прототипирование — выдвигаем и проверяем различные гипотезы, большая часть из которых выглядит как "если сделаем Х, улучшим базовое качество рекомендаций на Y". Довольно неплохое мерило успешности R&D команды, помимо прямого влияния на бизнес-метрики — это количество выдвинутых / проверенных / успешных гипотез, эдакая "пропускная способность" в гипотезах. При этом, чтобы было много успешных гипотез, нужна хорошая ресерчевская 'интуиция'. Чтобы выработать интуицию, нужна хорошая теоретическая база и опыт (как положительный, так и отрицательный) — про это упоминал в посте "Про ML соревнования".

3. Поддержка и развитие R&D инструментов:

* фреймворк для обучения нейросетей (он же трейн луп) - самая важная компонента, больше всего влияющая на количество проверяемых гипотез. Предела совершенству здесь нет: как лучше сделать конфигурирование обучения, как должен выглядеть конструктор модели, какие нужны коллбеки, что нужно логировать. Хорошая утилизация ресурсов тоже очень важна (не упираться в чтение по сети и в cpu, использовать оптимальные реализации слоев).

* работа с данными — зачастую самые профитные гипотезы связаны именно с данными. Подать что-то новое в модель, изменить представление входных данных, модифицировать целевую задачу, придумать новую процедуру предобучения. При этом нам доступны по-настоящему большие данные, триллионы пользовательских событий. Чтобы не состариться при проверке очередной гипотезы, требующей "варки" нового датасета, нужен удобный, гибкий и быстрый фреймворк. Дата инженеров у нас нет — нам важно уметь самим залезать в обработку данных и что-то быстро в ней менять. Да и инструменты для работы с данными в Яндексе настолько хороши (YQL, YT), что даже ресерчеры вполне способны их освоить :)

* инструменты для внедрений — "быстрые применялки" моделей, регулярные процессы дообучения, сервисы для применения моделей, оффлайн насчеты векторов, индексы для кандидатогенерации, etc. Здесь частично мы справляемся сами, частично нам помогают другие команды. Некоторые инструменты мейнтейнят и развивают выделенные команды. Конечная цель у нас — это всегда real-world impact, поэтому с этим всем мы тоже много сталкиваемся.

* командные процессы — совершенствуем их от полугодия к полугодию. На мой biased взгляд, выстраивание процессов для эффективного R&D гораздо сложнее, чем в обычной разработке. Вопросов много: сколько людей должно заниматься одним проектом, как лучше проводить планирования, сколько проектов должно быть у каждого человека, как организовать семинары по чтению статей, на что коммититься, etc.

4. Внедрения — мы постоянно общаемся с продуктовыми командами, рассказываем про новые технологии и наши планы, договариваемся про совместные внедрения, делаем общие для экосистемы Яндекса инструменты. Зачастую от сервисов узнаем много нового, вырабатываем новые интуиции, а потом еще и "кросс-опыляем" сервисы, рассказывая одному сервису про фишки другого :) Ну и, конечно, очень приятно видеть импакт на продукты, которые использует много людей (Музыка, Кинопоиск, Маркет, Алиса, Поиск, etc)

К чему я это все: у меня есть вакансия; если прочитали и чувствуете, что душа к нам лежит — приходите в личку (@kkhrylchenko) :)

P.S: приступаю к созданию видео про Pinterest 🙂

So, how they solved it? 𝗧𝗵𝗲𝘆 𝗳𝗶𝗿𝘀𝘁 𝘁𝗿𝗶𝗲𝗱 𝘁𝗼 𝘂𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱 𝗵𝗼𝘄 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝘀. They tracked what Elixir processes were doing, if they were stuck waiting on something, etc. They recorded the event types, how many of each kind of message they received, and their processing times. In addition, they tried to understand how much memory they use, the performances of garbage collectors, etc.

After the analysis, they 𝗰𝗿𝗲𝗮𝘁𝗲𝗱 𝘁𝗵𝗲 𝗳𝗼𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝘀𝘁𝗿𝗮𝘁𝗲𝗴𝘆:

𝟭. 𝗣𝗮𝘀𝘀𝗶𝘃𝗲 𝘀𝗲𝘀𝘀𝗶𝗼𝗻𝘀: Discord significantly reduced the amount of data processed and sent by differentiating between active and passive user connections, cutting the fanout work by 90% for large servers.

𝟮. 𝗥𝗲𝗹𝗮𝘆𝘀: Implementing a relay system (read - multithreading) allowed Discord to split the fanout process across multiple machines, enabling a single guild to utilize more resources and support more prominent communities. Relays maintain connections to the sessions instead of the guild and are responsible for doing fanout with permission checks.

𝟯. 𝗪𝗼𝗿𝗸𝗲𝗿 𝗽𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀 𝗮𝗻𝗱 𝗘𝗧𝗦: To maintain server responsiveness, Discord employed worker processes and Erlang Term Storage (ETS) for operations requiring iteration over large sets of members, thus avoiding bottlenecks in the guild process. ETS is an in-memory database that supports the ability of multiple Elixir processes to access it safely. This enables the creation of a new worker process and passes the ETS table so this process can run expensive operations and offload the central guild server.

🔗https://discord.com/blog/maxjourney-pushing-discords-limits-with-a-million-plus-online-users-in-a-single-server