#llm #math

В той же статье есть хорошая ссылочка с AI ресурсами для математики

https://docs.google.com/document/d/1kD7H4E28656ua8jOGZ934nbH2HcBLyxcRgFDduH5iQ0/

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 и хранить ещё меньше байт для них.

Если кто-то знает литературу о упаковках и локальности в таких системах, напишите, я не нашёл.

#systemdesign #books

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги 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
Про вторую я тоже уже слышал, но не читал.

#llm #agents

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. Неограниченный агент побил всех ещё больше, но во многих случаях за счёт перехода на более мощную модель 🙂

На полный эволюционный процесс по четырём бенчмаркам с 30 рекурсивными самоулучшениями ушло $15 (и в основном всё из-за растущей памяти с историей). Конкурирующий Meta Agent Search требовал $300.

Отдельно исследуется кейс с Game of 24. Там гёделевский агент после шести неуспешных попыток оптимизации переключился с метода на основе LLM на метод на основе поиска, переписав эту часть кода, и достиг 100% точности. В других запусках он продолжал использовать LLM, но сделал по ходу множество улучшений типа добавления верификации и прогона задачи на дополнительных данных. А ещё добавил библиотеку для лучшей трассировки ошибок, улучшил логи, убрал лишний код.

Также попробовали разные начальные полиси, не только CoT. Из интересного, более сильная полиси ведёт к лучшей сходимости, а также то, что агент c CoT после всех улучшений не превзошёл ToT. То есть типа инновации он не так хорошо придумывает.

У авторов большие планы на улучшение по различным фронтам (см. Раздел 6.1), включая множественных агентов.

Любопытная тема, наэволюционировать и рекурсивно наулучшать можно всякого…

#ml #dl #cv

Итоги года в медицинском ML

#dl #papers

Спасибо!

Я очень люблю старенькую (2017 год) 1 pixel attack на системы распознавания образов

https://arxiv.org/abs/1710.08864

#xgboost #hyperparameters

Приятное описание гиперпараметров xgbost-а, с картинками.

https://towardsdatascience.com/visualizing-xgboost-parameters-a-data-scientists-guide-to-better-models-38757486b813