Собрали небольшой компанией папку https://t.me/addlist/C_RSYpbW5mIyMjVi тг каналов про ML/DL/AI, которая покрывает сразу большой спектр тем: Илья (автор Сайги) много рассказывает про эксперименты с моделями, алайнмент, своего тг бота; Таня недавно стала менеджером в одной из команд Llama и пишет про интересные связанные темы, например, как поменялись бенчмарки для LLM; Ибрагим занимается сбором огромного кол-ва данных для претрейнов и часто делится обзорами на тему у себя (пост про FineWeb); Богдан шарит много информации про свой стартап Vibe и всякие заметки на тему LifeOps. В общем, думаю, что сможете полистать и отобрать, что приглянулось 🙂

Telegram

Авторский ИИ

Dr. Борис invites you to add the folder “Авторский ИИ”, which includes 30 chats.

В последние месяцы наблюдаю ажиотаж вокруг кодовых агентских бенчмарков по типу SWE-bench. Каждую неделю выходит новая работа, устанавливающая SOTA результаты на лайт версии. Напомню: в SWE-bench агенту дается описание issue, которую нужно починить. Починить означает сгенерировать правильный патч для нужного файла, после применения которого заготовленные тесты будут успешно завершаться (а до этого они падали). Первой работой, где произошел значительный прогресс в этом бенчмарке был SWE-agent на основе gpt4/claude opus. Версия с моделью от openai давала на лайт версии 18% (Последний результат - агент Aide, 43%). Но рассказать хочется не про сота подход, а недавнюю статью AGENTLESS: Demystifying LLM-based Software Engineering Agents. Это лучшее текущее опенсорс решение, осилившее 27% задач. Но интересным выглядит сам подход, тк за его простотой виден сценарий, как можно получить пользу от подобных моделей. Вместо сложных мультиагентных систем или большого числа доступных модели инструментов, здесь каждая задача решается по определенному сценарию из 2 шагов: 1) Найти классы/функции в нужных файлах, которые необходимо исправить 2) Сгенирировать изменение.

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

Генерация изменения (нижний блок). Здесь мы пользуемся вероятностным свойством LM и генерируем множество патчей на каждый блок (все эти патчи будут немного отличаться из-за семплинга токенов) и с помощью простой пост-обработки выбираем главного кандидата.

За счет ограниченного сценария, у модели нет проблем с долгосрочным планированием, ошибками в рефлексии или использованием инструментов. И более того в каждый этап хорошо встраивается подход human-in-the-loop: человек может добавить доп файл для рассмотрения или выбрать лучший патч. Помимо того, что метод дешевле того же swe-agent в 8-10 раз с текущими моделями, возможно с современными моделями подобные подходы более перспективны с точки зрения построения продукта. Остается вопрос, поменяется ли кардинально ситуация с выходом моделей нового поколения, например, gpt-5. Если нужен пост про более подробный обзор swe-bench/swe-agent как основ того, что сейчас активно обсуждают в твиттере, ставьте лайк 🙂

OpenAI за долгое время наконец опубликовали статью: LLM Critics Help Catch LLM Bugs. Идея тянется еще с давних пор: давайте сделаем LLM, которая будет находить слабые места и ошибки при генерации другой LLM. В этом направлении мне очень нравится работа Let’s Verify Step by Step, где авторы учили модель численно оценивать каждый шаг модели-генератора на задачах математики: как только был сделан неправильный переход, LLM-критик давала низкую оценку. Более того, если у нас есть подобная модель, мы можем объединять ее с алгоритмами по типу параллельного поиска или Monte Carlo Tree Search, то есть делать поиск по потенциально полезным состояниям и выбирать наиболее перспективные (как это было сделано в свое время для алгоритмов игры в шахматы и го). Эффективность этого значительно выше, чем у обычной генерации, что понятно: вместо одного продолжения мы генерируем целое множество. Это своего рода дополнительная ручка для размена вычислительных ресурсов на качество.

В этой же работе критик учится давать не численный, а текстовый фидбек для задач написания кода, таким образом генератор получает больше сигнала для последующих действий. Особенно много внимания уделяется совместной работе человека и модели для еще более качественной разметки: в этой связке человек + AI добивается наилучших результатов, но мы ведь все и так это давно знали? 🙃 В статье также много деталей по сбору данных и различным методикам Human Inserted Bugs и Human Detected Bugs – стоит почитать в общем. Еще авторы упоминают, что в RLHF брали PPO; видимо, OpenAI – единственная компания, которая продолжает его использовать, остальные уже съехали на DPO/KTO/you name it.

Из интересных моментов хочется рассказать про способ инференса CriticGPT Force Sampling Beam Search (FSBS). Очевидно, мы хотим, чтобы модель находила как можно больше багов в примерах (назовем это recall). Оптимизируя эту метрику, LLM будет стремиться генерировать все больше и больше замечаний, среди которых будут и галлюцинации (ложные срабатывания), то есть precision будет низким. Если в задаче классификации мы можем двигать пороги алгоритма, выбирая оптимальную для нас точку, то с генерацией текста в данной постановке дела сложнее. FSBS позволяет как-то решать эту проблему: CriticGPT принимает на вход пару (вопрос-ответ) и в каком-то месте может дать фидбек в определенном markdown-формате, начинающемся с трех кавычек. С помощью constrained generation мы можем заставить модель генерировать такой фидбек (highlight) в разных местах. Constrained generation в данном контексте означает, что мы вручную ставим `````, и далее LLM из-за формата обучения думает, что дальше должна последовать критика, и начинает ее генерировать. Причем генерировать мы можем множество различных вариантов параллельно (после такой операции у авторов получалось 28 штук), в итоге имея целый список потенциальных ответов от критика. Наилучший мы выбираем по формуле rm_score + LENGTH_MODIFIER * num_highlights, на этом этапе и происходит контроль precision/recall tradeoff. Подробно этот шаг описан в секции 7.1. Rm_score - оценка Reward модели, LENGTH_MODIFIER - гиперпараметр, контролирующий влияние кол-во хайлайтов.

После длительного отпуска врываемся обратно в плотный график 😊

В LLM происходит сейчас так много вещей, что эксперименты можно встретить в любом направлении. Недавно выходила модель SOLAR, где авторы увеличивали размер обученного трансформера, дублируя некоторые блоки, и модель становилась лучше. Параллельно с этим выпускаются работы в противоположном направлении, где вырезание слоев полностью сохраняет качество и позволяет таким образом прунить модели. В качестве примера - недавняя работа The Unreasonable Ineffectiveness of the Deeper Layers. Авторы смотрят на расстояние между входом и выходом, пройденного через n слоев, и, если оно небольшое, вырезают эти слои. Интуиция здесь такая, что маленькое расстояние означает, что эмбеддинг не сильно изменился за прошедшие преобразования. На практике получается, что слои-кандидаты на прунинг лежат ближе к концу модели, что кажется логичным: сначала модель сильно меняет эмбеддинги и со временем просто корректирует их для финального предсказания.

После вырезания слоев проводится процедура healing — QLoRA тюнинг на датасете C4 (сотни миллионов токенов). Такая корректировка весов позволяет выкидывать еще больше слоев без потери качества. Из замеров — MMLU и BoolQ, в обеих задачах авторы смогли выкинуть ~30% слоев LLaMA 2 70B, сохранив accuracy.

Теперь нужно объединить направления: взять 130B модель, запрунить до 70B и потом расширить опять до исходного размера, получив модель лучше 🧠

Какое-то время назад активно ходили слухи про проект Q от OpenAI. На сегодняшний момент известно мало, но высок шанс, что фокус в нем идет на reasoning, то есть умение планировать, строить цепочку рассуждений и декомпозировать сложные задачи. Это одна из важнейших проблем для текущих моделей, поэтому многие ее исследуют. На днях попалась статья от авторов из FAIR по их работе в сторону адаптации и улучшения алгоритма A для трансформеров. Для тех, кто не слышал про сам алгоритм:

1. Это модификация алгоритма Дейкстры, которая уходит от равномерного исследования в графа (с поправкой на веса ребер) в сторону проверки наиболее “перспективных” решений.
2. Огромное число задач может быть решено с помощью A*, начиная от классического поиска маршрута между двумя городами, до сборки кубика Рубика.
3. Рекомендую наглядное короткое видео с пояснениями и даже имплементацией для интересующихся. Для понимания можно посмотреть первые 10 минут.

Итак, авторы статьи сначала переводят траектории А для некоторой задачи в определенный формат, чтобы это можно было подать на вход как текстовую последовательность для нашей любимой задачи next token prediction. То есть в некотором смысле это попытка дистиллировать алгоритм в веса модели за счет тюнинга на собранный датасет (описание задачи, план, решение). Далее модель генерирует набор новых траекторий, некоторые из которых могут получиться даже лучше оригинального A, то есть быстрее решать проблему. Та часть, которая не решает задачу, выкидывается, и датасет пополняется полезной синтетикой. Такой прием в виде итеративного улучшения за счет генерации новых данных текущей моделью встречается далеко не в первый раз, вот, например, интересная работа про метод Self-Play. Модели при этом небольшие, до 757М параметров, архитектуры T5, то есть Encoder-Decoder.

В статье довольно насыщенный ablation study, но мне не хватило в табличке сравнения популярных существующих методов по типу MCTS и какой-нибудь GPT-4 с few-shot примерами.

И раз зашла речь про reasoning, на kaggle вчера объявили о новом конкурсе про решение математических олимпиадных задач с помощью LLM, следим 👀

Прокатилась новость про то, как исследователи из Гугл придумали способ выяснить веса последнего слоя и внутренний размер эмбеддингов у моделей, доступных ТОЛЬКО по апи (например, ChatGPT). Стало очень интересно, а как в принципе такое возможно, поэтому сегодня попытаюсь базово объяснить на самом простом примере: как достать размер эмбеддинга h, имея на руках значения логитов для ВСЕХ токенов из словаря. Понятно, на практике мы имеем доступ (и то не всегда) к топ-к логитам, но для простоты и интуиции лучше начать с простого. Для обзора всех методов (даже для случая, когда логитов вообще нет), нужно писать отдельный лонгрид.

Итак, алгоритм действий такой:

1. Создаем матрицу n на l, где l — размер словаря, а n — число, большее h. Мы его не знаем, но можем примерно предположить и вообще хоть взять 100_000. Но чем больше этого число, тем больше запросов нужно будет сделать в апи ⇒ весь процесс выйдет дороже.
2. n раз семплируем рандомный промпт, получаем логиты и заполняем нашу матрицу.
3. С помощью какого-нибудь алгоритма (например, SVD) находим сингулярные числа матрицы λ_i.
4. Размер эмбеддинга определим как argmax_i(λ_i/λ_{i+1}).

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

1. Несмотря на то что каждый вектор логитов состоит из l чисел, все они лежат в пространстве размерности h и затем преобразуются линейной проекцией.
2. Соответсвенно, запрашивая результаты модели достаточное число раз (бОльшее h), мы будем получать новые векторы логитов, линейно зависимые от предыдущих.
3. Теперь можно сказать, что нам достаточно найти ранг матрицы, который мы и возьмем в качестве предсказания размера эмбеддинга. А ранг матрицы — это кол-во ее сингулярных чисел. Но тк значения матрицы не целочисленные, а fp16 или вообще fp8, то такое определение нам не подойдет. Именно поэтому мы находим ту точку, в которой происходит максимальный скачок до очень маленьких значений сингулярных чисел — ненулевыми они получились из-за погрешности измерений.

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

Небольшая заметка об изменении архитектуры трансформера с 2017 года. Читая статьи про LLM, можно увидеть фразы вроде "мы используем стандартную архитектуру трансформера". Но что означает "стандартная", и есть ли изменения с момента выхода оригинальной статьи? Давайте на примере языковой модели (т.е. decoder-only) LLaMa-2 посмотрим на основные крупные архитектурные улучшения для LLM:

— Post LayerNorm → Pre LayerNorm. Это делает сходимость более устойчивой. Теперь процесс идет так, что исходные эмбеддинги просто идут сквозь блоки декодера, и к ним прибавляются “корректировки” из FFN и Attention. Выглядит изящно, на мой взгляд.

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

— Функция активации ReLU → SwiGLU. Gated Linear Units (семейство методов, к которому принадлежит SwiGLU. В нем добавляется операция поэлементного умножения матриц, одна из которых прошла через сигмоиду и таким образом контролирует интенсивность сигнала, проходящего из первой матрицы) немного докидывают к качеству на ряде задач.

— LayerNorm → RMSNorm. RMSNorm вычислительно проще, но работает с тем же качеством.

— Модификации Attention, например, использование одной K-V пары матриц сразу на группу Q матриц. Это улучшение в основном уже влияет на оптимизацию инференса. Но здесь есть и огромное число методов, направленных в сторону снижения квадратичной сложности операции, писал об этом подробнее здесь и здесь.

Дошли наконец руки разобрать давно отложенную статью про агентов: V-IRL: Grounding Virtual Intelligence in Real Life, уж очень мне нравится идея объединения различных модулей (например, LLM + Vision Model + Tools + Memory) ради решения сложных многоэтапных задач. На этот раз авторы предложили некоторый фреймворк для построения агентов, которые передвигаются в сеттинге реального мира. То есть агентам доступны апи по гео данным, гугл карты (включая визуальное передвижение по улицам), всякие апи по отзывам на заведения и так далее, то есть практически все, что есть у нас для навигации по городу. А задачи им даются в виде: “Предложи мне оптимальный маршрут в Нью-Йорке, учитывая мои пожелания A, B и ограничения в X долларов” или “Нанеси информацию о пожарных гидрантах в парке на карту”. Для последнего задания агент дает задание другому роботу-агенту сначала проехать по парку и передать данные об обнаруженных гидрантах. Также агенты могут выполнять свои задачи параллельно и если так оказалось, что один уже знает то, что нужно другому, то он этой информацией может поделиться и помочь.

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

Техническая конфигурация стандартная: гугл карты + всякие разные апи для информации о местанахождении/отзывах/маршрутах и так далее, BLIP-2 (Flan T5 XXL) в качестве Visual Question Answering Model, LLM (GPT-4/Llama2) в качестве главного процессора, то есть обработки любой текстовой информации + ризонинг. Например, LLM посылает запрос в гугл карты, получает изображение с улицы, обращается в BLIP для обнаружения гидранта, обрабатывает результат и сохраняет информацию. Но интересно здесь то, как все сплелось в единую платформу по решению задач из реального мира. А теперь представьте, если прикрутить сюда Sora и сидеть наблюдать за агентами в рамках целого набора видео. Может этим и занимаются сейчас в FigureAI? 🤔

Со мной недавно поделились тредом в Twitter, где парень рассказывает про эксперименты с подходом ColBERT со всякими дополнительными трюками, которые помогли улучшить качество. Стало интересно разобрать основные моменты, так как это в данный момент актуально к моим текущим задачам. Давайте напомню, что такое ColBERT в контексте задачи Retrieval. В обычном сценарии мы прогоняем все наши документы через эмбеддер и строим по ним индекс (получая таким образом отображение document ↔ embedding). Далее для любого запроса мы можем посчитать его эмбеддинг и найти k ближайших соседей как кандидатов на выдачу. ColBERT предлагает здесь уйти от представления “1 вектор на 1 документ”, вместо этого у нас будет n эмбеддингов на документ и k эмбеддингов на запрос. На картинке можно увидеть, как получается итоговый скор для пары запрос-документ. Такое расщепление помогает более детально посмотреть на взаимодействие токенов запроса с токенами документа. В пару предложений тяжело запихнуть описание всего подхода, поэтому посмотрите также оригинальную статью, она написана понятным языком.

Из описанных приемов автора мне понравились следующие:

1. Прунинг индекса. Обрабатывая каждый токен по отдельности, мы получаем а) большой индекс б) много ненужных в нем элементов, которые скорее всего будут бесполезны при поиске. Статья
2. Поиск не по всем токенам из запроса, а только по некоторым из них. Своего рода тот же прунинг, но уже для запросов. Статья
3. Дополнительно использовать PRF (pseudo-relevance feedback), то есть делать ретривал в два этапа: на первом извлекать документы для формирования дополнительных эмбеддингов запроса (что-то по типу query expansion), а на втором уже искать финальные документы для выдачи. Схема изображена на картинке. Статья

Если использовали что-то из этого, расскажите, интересно послушать, что взлетело, а что нет. По моим экспериментам не могу сказать, что ColBERT вообще стат. значимо докидывал по сравнению с хорошо настроенными bi-encoder трансформерами, но это в задаче поиска товаров.

Продолжаем серию #interview_questions. Напомню, под этим тегом я пытаюсь собрать не самые популярные вопросы с собеседований, которые часто вызывают трудности. В этот раз вопрос по теме статистики и проверки гипотез, который встретился на собеседовании в одну большую компанию, занимающуюся объявлениями.
Вопрос: при условии, что H0 верна, какое распределение будет у p_value?

Ответ: Равномерное. Вот хорошее чисто математическое объяснение https://statproofbook.github.io/P/pval-h0.html. Заключается оно в том, при H0 можно показать, что для любого 'a' P(p_val < a) = a (отсюда как раз и вытекает возможность устанавливать ограничения на ошибку первого рода в привычном виде по типу "сравни p_value с 0.05"). Единственный вариант, когда возможно такое равенство — когда p_value имеет равномерное распределение на отрезке [0, 1].

Недавно появилась мысль собрать небольшой список из вопросов подобного рода, например, 100 вопросов по темам ML, NLP, CV, DA в формате вопрос/ответ/доп. ссылки. Было бы такое интересно?