Интересное что-то
517 subscribers
2.72K photos
253 videos
138 files
4.51K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Forwarded from Сиолошная
Inference-Time Scaling for Diffusion Models beyond Scaling Denoising Steps (сайт проекта)

Последнее время активно исследуется тема масштабирования вычислений во время инференса (применения модели). В LLM ярким событием стал анонс o1 от OpenAI, где модель могла исписать 50 страниц рассуждений вместо 5, что привело к улучшению качества в нешироком наборе задач. Авторы из DeepMind решили попробовать масштабировать вычисления на инференсе для диффузионных моделей генерации картинок по текстовому запросу.

Диффузионные модели, если упрощать, работают так:
1) Сначала создается случайный шум — просто хаотичная картинка, никак не связанная с запросом (может выглядеть так, ткните картинку чтобы понять о чем речь) и моделью

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

3) берут семпл из этого распределения (то есть случайным образом выбирают какое-то одно значение с учётом предсказанных выше параметров; более просто: случайный выбор значения из предсказанного моделью диапазона)

4) из текущего зашумленного изображения (на первой итерации это то, что получилось в пункте 1) вычитают то, что получилось в пункте (3); модель как бы предсказала, какой шум нужно вычесть, чтобы «очистить» изображение (поэтому называется denoising, убирание шума). Это делает картинку чуть более четкой, но пока она всё ещё далека от финального результата. На этом этапе могут применяться специальные алгоритмы, связанные с дифференциальными уравнениями, но об этом как нибудь в другой раз.

5) Обновленное изображение снова пропускают через модель, повторяя процесс. Постепенно шум убирается шаг за шагом, и через множество итераций модель выдает готовую картинку.

Прочитав это, легко сходу придумать, как именно масштабировать вычисления во время предсказания: нужно просто увеличить количество шагов! К сожалению, эта мера не так эффективна, и после относительно небольшого увеличения прирост качества генераций прекращается. Условно между 20 и 50 шагами (итерациями) вы увидите разницу, а между 100 и 200 почти наверняка нет (в некоторых случаях это и вовсе портит картинку). То есть этот метод масштабирования очень ограничен.

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

Значит, какие-то исходные шумы более удачны, какие-то менее. Это и будет первый метод поиска для масштабирования вычислений: давайте сгенерируем N картинок из N разных шумов, затем пропустим их через отдельную модель, которая даёт оценки, и выберем лучшую. «Отдельная модель» будет называться verifier (верификатор?), она принимает на вход картинку и, опционально, текстовый запрос и выдаёт какую-то цифру, по которой и судим.

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

Второй подход: а давайте ещё поисследуем локальную окрестность лучшего кандидата?
1) сгенерировали N случайных и независимимых шумов
2) сгенерировали N картинок
3) каждую оценили верификатором
4) теперь берём одну или две лучших, вспоминаем какой шум для них генерировали в начале, и берем его же, но чуть-чуть отклоняясь в сторону (K раз). Гипотеза такая, что это какой-то просто более удачный регион, в который попала генерация из первого цикла, но ведь мы наверняка выбрали не самый удачный шум из этого региона с первой попытки?
5) для новых шумов генерируем картинки
6) оценили верификатором
7) повторяем шаги 4-6 сколько хотим

Третий подход гораздо более технический, и не хочется его расписывать детально, поэтому вот TLDR: прерывают процесс генерации на какой-то итерации (скажем, после 20% шагов), и оттуда генерируют несколько продолжений, оценивают их, выбирают лучшие, отбирают их и продолжают генерцию, повторяя прерывания

Все три метода на картинке

Ешё есть четвертный метод, суть которого сводится к тому, что если верификатор — это локальная модель, то мы можем посчитать градиент аналитически, то есть прям в точности понять, как нам нужно изменить шум на входе, чтобы повысить оценку. Он тоже работает и с ним всё хорошо.
Forwarded from Карьера в FAANG
В прошлом посте я начал говорить об ожидаемом содержании performance review документа и поговорил о необходимости подтверждающих заявления артефактов. Сегодня же я хочу поговорить о том, как правильно делать эти заявления.

Инструмент 4: ladder description

В бигтех компаниях уровни (#level) более или менее точно описаны. Где-то есть официальный ladder документ на всю компанию, где-то с локальной спецификой организации, где-то он вообще может передаваться устно. Но независимо от формы, содержание описания уровней существует и понятно старожилам. Такие документы могут быть написаны непонятным корпоративным языком, но это не значит, что они бесполезны. Просто их нужно уметь читать, с чем я помогаю в этом канале. Понимание этого документа -- самый главный ассет сотрудника, желающего расти в бигтехе.

К каждому заявлению в perf документе возникает вопрос: "чем докажешь?", на который отвечают ссылки на артефакты. После него возникает второй вопрос: "и что?". Кандидат снизил latency сервиса вчетверо? И что? Увеличил прибыль на $XXX/год? И что? Запустил сложное изменение? И что? Каждому сотруднику за его работу платят зарплату. Почему вся вышеперечисленная работа должна быть вознаграждена дополнительно? На этот вопрос отвечают ссылки на ladder документ. Сложное изменение требовало leadership, чтобы организовать и синхронизировать работу нескольких команд? В ladder документе написано, что такой организацией занимается Senior. Значительно снизить latency безуспешно пыталось много квалифицированных людей в течении долгого времени? В ladder написано, что Staff решает проблемы, которые не может решить большинство коллег. $XXX -- число, заметное на уровне VP? В ладдере написано, что Senior Staff приносит масштабный импакт.

Отсюда вытекает самое важное правило при написании perf пакета: пишите perf цитатами из ladder документа (или цитатами руководителей об уровнях, если документ отсутствует).

При чтении этих цитат, ни мнение кандидата о работе, ни его же мнение об его уровне / оценке, не оставляют сомнений. Если вы пишите о себе цитатами из Senior уровня, очевидно, вы намекаете на повышение до Senior. Ревьюеры могут не соглашаться с вашей оценкой работы, но по крайней мере они совершенно точно поймут эту вашу оценку и не запутаются в том, что происходит в вашем пакете. Было бы обидно описать крутой проект, только чтобы ревьюеры прочитали ваше описание, похлопали вам, и сказали, какой же классный вы инженер на вашем уровне, вместо того, чтобы увидеть сигналы на следующий уровень, не правда ли? Помимо всего прочего, старшие коллеги, которые занимаются ревью perf пакетов, затерли ladder документ до дыр, и вы сделаете оценку вашего пакета на порядок проще и быстрее, если не будете придумывать свои формулировки, а вставите стандартные и уже знакомые ревьюерам.

#perf
Forwarded from Andrey Volikov
Лайк поставил! Не все компании открывают свои ladder документы, но некоторые открывают, тут собрано несколько примеров на непонятном корпоративном языке: https://progression.fyi/ , лично мне больше всех из открытых понравился док от Monzo.
Forwarded from epsilon correct
Новый день, новый пост про калибровку предсказаний. В прошлом году я писал про классическую работу Фостера и Вохры про то, что идеальной калиброванных предсказаний можно добиться не обладая знаниями о распределении предсказываемой величины. 🤔

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

В таком сеттинге авторы показывают схожесть между калибровкой и сожалением (regret) и доказывают, что случайные исходы по отношению к прогнозам эквивалентны хорошим прогнозам по отношению к исходам. Интуитивно, если исходы случайны по отношению к прогнозам, у "ставочника" нет возможности получить прибыль ставя против прогноза, а если пргнозы хороши по отношению к исходам, вся неопределённость в ошибках предсказателя объясняется случайностью природы.

Осталось только это всё интернализировать. 😰
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from epsilon correct
В Notices Of The American Mathematical Society вышла коротенькая обзорная статья Терри Тао про то, как математики могут пользоваться компьютерами для доказательств. Интересный разбор с примерами из разных областей, включая, например, не особо известную статью по геометрической топологии. Из грустного, Gemini не упоминается. 😭
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Experimental chill
S3 locality

Тут я хотел рассказать о каких-то челленджах в построении storage систем по типу S3. Обычно в таком духе я спрашиваю людей на собеседованиях, поэтому тут мысли вслух, любые совпадения случайны.

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

Диски хоть и дешёвые, но на масштабах S3 любая экономия байт уходит за миллионы/сотни миллионов долларов. S3 сжимает данные с помощью ZSTD https://news.ycombinator.com/item?id=32529412 и внутри скорее всего есть какой-нибудь Erasure Coding, чтобы не хранить дорогие копии.

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

* Есть свобода хранить чанки как угодно

* Чтобы избежать фрагментации, хочется их как-нибудь паковать в большие шарды (сотни мегабайт, гигабайты?)

* Упаковка также помогает процессам вида FSCK и garbage collection работать лучше и использовать меньше дисков, например, проверять на консистентность и удалять больше данных вместе, что снимает нагрузку

А дальше интересный вопрос, на который я и сам не знаю ответов: как лучше всего сделать упаковку? С одной стороны не хочется паковать блоки, которые должны быть скоро удалены с теми, кто никогда не должен удаляться, потому что иногда в упаковке шардов образуются дырки, с другой сделать что-то совсем простое не так тривиально. Без дырок не обойтись, но хотелось бы их поменьше. Я придумал только несколько небольших эвристик

* Хранить данные с похожим TTL в +-1 день вместе. Тем самым не образовывая много дырок

* Скорее всего некоторые пользователи или форматы файлов удаляются без TTL какими-нибудь человеческими усилиями. На них нужно писать предикторы с простыми линейными моделями

* Делать холодные данные холоднее, горячие горячее, например, выделить бюджет дисков, чтобы увеличивать размерность Erasure Coding и хранить ещё меньше байт для них.

Если кто-то знает литературу о упаковках и локальности в таких системах, напишите, я не нашёл.
Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

При этом как ни удивительно, книга интересна и актуальна до сих пор и для разработчиков и для архитекторов и для системных аналитиков.

Можно сказать, что книга прошла почти незамеченной в широкой профессиональной среде, в частности, никогда не переводилась на русский язык.

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам
#rl #llm
Получается, больше смещаем фокус в сторону агентов
Немножко про агента и инструменты, которые я писал последние пару дней.

Поиск по ArXiv. Есть публичное API, есть готовая библиотка. Подводные камни:
- Есть значительный кусок функциональности, который не поддерживается во всех популярных реализациях: фильтр по датам. Более того, в официальном руководстве к API он... неправильно описан! Если вы выполните запрос из руководства, то увидите, что фильтр там тупо не работает! В реальности это должен быть не отдельный GET параметр, это должна быть часть запроса, что я выяснил только из группы с обсуждением.
- Я до сих пор не до конца понимаю, как работает поиск без явного указания полей. Это как будто бы нигде нормально не описано.

Скачивание и парсинг PDF. И если со скачиванием вопросов нет, то с парсингом всё до сих пор очень-очень больно. Есть pypdf, который с извлечением текста из архивовских pdfок кое-как справляется, но получается просто текст без структуры. И есть marker, который справляется очень даже элитно и выдаёт нормальный Markdown + картинки, но который по-хорошему требует отдельного GPU сервака. На CPU ждать по минуте не очень хочется, да и зависимости там сейчас конфликтуют с smolagents. Чего-то посередине я пока не нашёл.

Эмуляция bash. Я взял спеку Anthropic, запихнул её в Соннет и сказал, чтобы он написал код с исполнением через Docker. Пока что работает безотказно, вообще никаких проблем не было. Более того, иногда агент полнейшую дичь умудряется вытворять с этим инструментом.

Сам агент. Сначала я тестировал всё с Соннетом. Когда за 3 дня насчиталось 30$, я понял, что так продолжать нельзя. Сейчас всё пытаюсь делать с gpt-4o-mini, и это реально больно. Зато если уж с ней всё работает, то с нормальными моделями получаются вообще чудеса. Тестирую на простом запросе про свою же статью.

Меня не очень интересуют хардкодные реализациии типа storm и AgentLaboratory. Хочется всё сделать в рамках базового CodeAct, запихивая всю сложность в инструменты и подчинённых агентов.

Сейчас я пишу str_replace_editor из той же спеки, что и bash.
#interesting

Вдогонку😹
На скриншоте один из тестовых вопросов, которые я использую.
Вопрос, очевидно, не совсем серьёзный, но хотя бы заставляет агента попотеть, даже на базе Соннета.
Я всё ещё борюсь за получение нормального лога/отчёта (mind.txt), в комменты скину только final.txt с одного из прогонов.

Что интересно, есть две статьи, которые регулярно всплывали за пару десятков итераций:

Gödel Agent: A Self-Referential Agent Framework for Recursive Self-Improvement
https://arxiv.org/abs/2410.04444

OS-Copilot: Towards Generalist Computer Agents with Self-Improvement
https://arxiv.org/abs/2402.07456

Разбор первой можно найти тут: https://t.me/gonzo_ML/2964
Про вторую я тоже уже слышал, но не читал.
Gödel Agent: A Self-Referential Agent Framework for Recursive Self-Improvement
Xunjian Yin, Xinyi Wang, Liangming Pan, Xiaojun Wan, William Yang Wang
Статья: https://arxiv.org/abs/2410.04444
Репа: https://github.com/Arvid-pku/Godel_Agent

Why did the Gödel Agent take so long to plan its road trip in its Gödel Machine?

Because its navigation system kept recursively self-improving, proving it could find a better route, but never actually getting to the destination!



Любопытная работа про эволюционирующих агентов, вдохновлённых Шмидхуберовской Машиной Гёделя (https://arxiv.org/abs/cs/0309048) 2003 года. Машина пыталась сначала формально доказать, что изменение ведёт к улучшению (что могло требовать примерно вечность), агент вместо формальных доказательств использует эмпирический фидбек из среды и просит LLM улучшить код на базе этого фидбека. По ощущению похоже на что-то типа AutoGPT, который ещё и код свой переписывает.

Идея в том, что агенты бывают разной породы. Первые, Hand-Designed Agents с самой низкой степенью свободы, следуют одной и той же полиси всё время, вне зависимости от фидбека из среды. Другие, известные как Meta-Learning Optimized Agents, имеют фиксированный алгоритм meta-learning, обновляющий их полиси по фидбеку из среды. И есть self-referential Gödel Agent, который может улучшать себя без ограничений. Технически это значит, что он обновляет и полиси, и алгоритм мета-обучения.

Для такого агента нужно задать начальные полиси и алгоритм мета-обучения. В качестве начальной полиси взята LLM с Chain-of-Thought промптом. А в качестве второго взят алгоритм, который рекурсивно запрашивает LLM для переписывания всей своей кодовой базы с учётом фидбека из среды (успешность решения задачи). При этом он может переписать и код, отвечающий за переписывание кода, поэтому он self-referential.

Агент -- это экземпляр конкретного питоновского класса (Agent), он имеет доступ к содержимому памяти питоновской среды (локальные и глобальные переменные, функции и модули) и может динамически там всё менять, включая свой код (monkey patching). Так он и эволюционирует, насколько я понял.

Для улучшения сходимости оптимизационного процесса агенту даны дополнительные тулы: 1) thinking before acting (кажется, похоже на ReAct), 2) error handling (добавлен механизм восстановления после ошибок, ибо LLM может всякого в код навставлять), 3) code running (Python и bash), 4) LLM calling (через API). Первые два дальше покажут наибольшую пользу.

Где-то в обзорах в сети проскакивало, что агент сначала проверяет, что новые изменения ведут к улучшению, и включает новый код только если они ведут, или что он делает backtrack назад к предыдущему хорошему решению в случае, когда результат оказался хуже. Но по статье этого не видно, более того, там явно есть примеры, когда результат сначала ухудшался, а потом агент таки навёрстывал. Код я посмотрел только поверхностно, и мне кажется, что ничего упомянутого тут нет и агент ориентируется только по истории. Но могу и ошибаться, так что если кто погрузится глубже и найдёт что-то интересное, расскажите. Вообще есть чувство, что всё больше обзоров начинают генериться NotebookLM или просто GPT, и оно не всегда соответствует реальности.

Потестили на бенчмарках DROP, MGSM, MMLU, GPQA. Бейзлайны из группы Hand-Designed Agents (CoT, CoT-SC, Self-Refine, LLM Debate, Step-back-Abs, Quality-Diversity, Role Assignment) и Meta-Learning Optimized Agents (Meta Agent Search).

Дефолтный гёделевский агент ограничен, ему запрещено менять модель (gpt-3.5-turbo) и у него нет доступа к интернету. Как я понял, для самоулучшения используется gpt-4o, а gpt-3.5-turbo -- для оценки уже оптимизированной полиси. Есть неограниченный вариант, которому можно фсё.

Ограниченный гёделевский агент побил всех. Где-то сильно (DROP, MGSM), а где-то лишь слегка (GPQA). В приложении есть код для найденных полиси, можно изучить, насколько далеко он ушёл от начального CoT. Неограниченный агент побил всех ещё больше, но во многих случаях за счёт перехода на более мощную модель 🙂