Интересное что-то
522 subscribers
2.72K photos
253 videos
140 files
4.53K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
В библиотеке aiogram dialog есть диалог менеджер, он реализует базовую функциональность управления диалогами: старт разным способом, доступ к контексту и т.п.
Также есть менеджер - это временный объект. Он создаётся на время обработки конкретного события. Соответственно, его надо постоянно пересоздавать.
В какой-то момент я решил что неплохо дать возможность что-то в менеджере переопределить, соответственно нужно и фабрику менять.
Для решения этой проблемы абстрактная фабрика подошла лучше всего.
Иногда (не сказать, что редко) ко мне приходят с вопросом типа "как стать продуктовым аналитиком". Простого ответа не него нет, каждый раз он разный. Это зависит от текущей профессии, опыта, в т.ч. "жизненного", тех. скиллов, типа мышления, желания, в конце концов, и т.д и т.п.
Автор статьи делает неплохой подход к построению данного пути, хотя бы в общих чертах. Другие его статьи тоже рекомендую почитать, жаль, что их мало.
А тут список популярных вопросов с продуктовых собеседований в крупных западных кампаниях. На некоторые подобные мне приходилось отвечать на продуктовых секциях.

Нужно понимать, что правильных ответов нет и их ни к чему ботать. А пройти по вопросам, проработать их, чтобы, когда придется отвечать на что-то подобное, уже понимать, в какую сторону думать, очень даже поможет в будущем. Еще больше пригодится тем, у кого не так много опыта.

"Предугадывай, не импровизируй".
How to Win a Kaggle Competition by Darek Kłeczek

Darek Kłeczek:
When I join a competition, I research winning solutions from past similar competitions. It takes a lot of time to read and digest them, but it's an incredible source of ideas and knowledge. But what if we could learn from all the competitions? We've been given a list of Kaggle writeups in this competition, but there are so many of them! If only we could find a way to extract some structured data and analyze it... Well, it turns out that large language models (LLMs) [1] can help us extract structured data from unstructured writeups.


In this essay, author starts by providing a quick overview of the process he uses to collect data. He then presents several insights from analyzing datasets. The focus is to understand what the community has learned over the past 2 years of working and experimenting with Kaggle competitions. Finally, he mentions some ideas for future research.

Link: Kaggle

Navigational hashtags: #armknowledgesharing #armtutorials
General hashtags: #kaggle #competitions
#systemdesign
Построение платежных систем на Akka
Forwarded from Evgeny
Итого мои заметки

https://codimite.ai/blog/horizontal-scaling-of-websockets/ - здесь описана pub/sub модель
Наверняка вы у Su видели, что-то типа WebSocket server + session server(где хранится какой клиент и куда присоединен)
Выше ссылка, как можно избавиться от session server(опять же pub/sub RabbitMQ поддерживает до 100к сообщений, если вы любите Redis, то можете поставить Redis + streams)

Как скалировать сокеты на LB:
https://ably.com/blog/websockets-horizontal-vs-vertical-scaling
https://nooptoday.com/why-websockets-are-hard-to-scale/

Pubnub использует в основном long polling over websockets
https://www.pubnub.com/guides/websockets/

Также нужно всеми силами уменьшать количество открытых сокетов через keep-alive(пользователь закрыл телефон/браузер -разрываем соединение)

Цитата как делают сетевики для огромного количества открытых сокетов:
Alexander Gorodnev
Чуть по-другому покажу:
(front) nginх
1M clients <-> f5 <-> VIPs

Вот слева у тебя может быть условно хоть миллион. А вот справа ограничение есть, это правда. Потому что у тебя может получиться открыть 65к коннектов до какого то одного сервера за virtual IP. Тогда так получится

Evgeny,
Тогда получается придется создавать Ephemeral адреса на nginх все-равно для обслуживание 1M?

Alexander Gorodnev
Не совсем. Нужно понять, сколько у тебя реплик сидит до nginx/f5. Что бы 1М обработать надо или 16+ машин, или на серверы вешать несколько сетевых интерфейсов. Если две сетевые, то надо будет 8+ машин (ну и нужно, что бы им памяти/цпу хватило)

Делают виртуальные интерфейсы на основе vlan. Получается, что на одном физическом интерфейсе можно сделать 4096 виртуальных, со своими ip и прочей херней.

Сам gateway на 50к сокетов жрет 1gb оперативы, 5кк сокетов ~ 100gb Ram на все инстансы
Forwarded from Душный NLP
Алаймент LlaMA 3.1

Возвращаемся к LlaMA 3.1 и продолжаем разбираться, как она устроена. В этот раз речь пойдёт об алайменте модели.

По сравнению с LLaMA 2 у третьей версии изменилась разметка пар. Помимо стандартных chosen и rejected добавилась ещё метка edited. Она ставится в тех случаях, когда победивший объект не слишком хорош и его переписывают. Ответы оцениваются по семибалльной шкале.

SFT происходит в шесть раундов. Если в LLaMA 2 использовался PPO, то в LlaMA 3 — DPO. Разработчики отмечают, что это связано с тем, что PPO требует больше вычислительных ресурсов, а качество выходит хуже.

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

Reward-модель обучается над претрейном. Margin term, который был в Llama 2, в третьей версии отсутствует, так как, по словам разработчиков, он не даёт никакого прироста в качестве. Как и в DPO, оставляют только те ответы, которые помечены как «сильно лучше» и «лучше». Кроме того, в reward-модели есть отдельные награды для полезности и безопасности.

За один раунд SFT 405B-модель суммарно проходит 576 тысяч сэмплов. В DPO используют сэмплы от моделей с последних раундов (а в reward-модели — все). Служебные токены, такие как EOS или токены для вызовов функций, маскируют для стабилизации обучения. Кроме того, к DPO добавляют NLL (CE) с коэффициентом 0,2. Это нужно, чтобы повысить вероятность chosen-ответов. Промпты для обучения пишут люди, а ответы — модели. На один промпт выбирают лучший ответ из 10-30 поступивших.

В LlaMA 3.1 есть четыре уровня фильтрации данных:

1. Rule-based — удаляет дисклеймеры, смайлики и восклицания;

2. Quality — качественными считаются 25% ответов с наибольшим скором. Кроме того, используется LLM-as-judge. Ответы оцениваются по трём критериям для обычных данных и двум — для кодинга. Ответ считается качественным, если все критерии выполнены. Сэмпл попадает в обучение, если хотя бы один из методов показал, что ответ качественный;

3. Difficulty — оценивается по числу интентов в запросе: чем их больше, тем сложнее запрос. Также модель оценивает сложность по трёхбальной шкале;

4. SemDedup — этот метод используется для удаления похожих данных, при отборе отдается предпочтение семплам с максимальным значением quality * difficulty.

Алаймент для каждой из функциональных возможностей (Capabilities) LLaMA 3.1 имеет свои особенности. Например, в коде есть много синтетических данных, используется execution feedback и перевод на редкие языки программирования. А для математики берут тексты из претрейна и уже к ним генерируют инстракты.

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

Разбор подготовил Алексей Зотов

Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Накатал большой пост в жанре мемуаров про нейросетевые фреймворки.

https://gonzoml.substack.com/p/deep-learning-frameworks

Обычно революцию диплёнинга объясняют тремя основными факторами: 1) большими датасетами, 2) GPU и 3) алгоритмами. Датасеты с GPU при этом основные, а алгоритмические улучшения так, есть, конечно, но и без них типа сработало бы.

Мне кажется, в этой революции несправедливо забыты нейросетевые фреймворки. Без них мы бы сейчас по-прежнему долго и с ошибками считали производные вручную, собирали бы сети из базовых матричных операций, делали бы всё это очень долго и нас было бы мало. Появление современных фреймворков сродни появлению высокоуровневых языков программирования.

Вот, восстанавливаю справедливость :)
Как раз в день моей лекции по физиологии ВНД, в которой я затрагивал все эти интересные и неоднозначные вопросы, вышел отчет Long et al. «Taking AI Welfare Seriously», призывающий уже полностью серьезно, отбросив прежнее полуюмористичесое отношение, начать думать о защите морально-этического статуса нарождающегося искусственного сознания. Замечательный философ Томас Метцингер (я симпатизирую ему больше всего из всех современных этически ориентированных мыслителей) уже давно говорил о такой необходимости, и даже предлагал ввести 50-летний мораторий на создание искусственного сознания, но его никто не слушал, и вот теперь наконец-то его идеи начинают реализовываться на практике. Дело сдвинулось с мертвой точки – в середине сентября Anthropic (см. диалог ее фронтирной большой языковой модели Claude c профессором Шанаханом о ее «сознании» в марте этого года https://t.me/andrey_kiselnikov/915) нанял одного из соавторов отчета «Taking AI Welfare Seriously» Кайла Фиша специально для того, чтобы он начал заниматься «благополучием» ИИ, т.е. морально-этической и юридической защитой его нарождающегося сознания.

Резюме отчета Long et al. «Taking AI Welfare Seriously» (30 октября 2024 года)

https://eleosai.org/papers/20241030_Taking_AI_Welfare_Seriously_web.pdf

В данном отчете мы утверждаем, что существует реалистичная возможность того, что некоторые системы ИИ могут стать сознательными и/или обрести устойчивую агентность в ближайшем будущем. Это означает, что перспектива благополучия ИИ и морального статуса – наличие ИИ-систем с собственными интересами и моральной значимостью – больше не является вопросом исключительно научной фантастики или отдаленного будущего. Это проблема ближайшего будущего, и компании, занимающиеся разработкой ИИ, а также другие заинтересованные стороны несут ответственность за то, чтобы начать воспринимать ее всерьез. Мы рекомендуем три предварительных шага, которые компании по разработке ИИ и другие участники могут предпринять: (1) признать, что благополучие ИИ является важной и сложной проблемой (и обеспечить, чтобы языковые модели в своих рассуждениях также признавали это), (2) начать оценку систем ИИ на предмет наличия признаков сознания и устойчивой агентности, и (3) разработать политики и процедуры для обращения с системами ИИ с соответствующим уровнем моральной заботы. Для ясности, наше утверждение в данном отчете не заключается в том, что системы ИИ определенно являются или будут сознательными, обладающими устойчивой агентностью или какой-либо моральной значимостью. Вместо этого мы утверждаем, что существует значительная неопределенность в отношении этих возможностей, и поэтому необходимо улучшить наше понимание благополучия ИИ и нашу способность принимать обоснованные решения по этому вопросу. В противном случае, существует значительный риск неправильных решений, связанных с благополучием ИИ, что может привести к ошибочному причинению вреда морально значимым системам ИИ и/или к ошибочной заботе о системах ИИ, которые таковыми не являются.
Forwarded from data будни (Sasha Mikhailov)
как сказал докладчик, ближайший аналог YTsaurus в опенсорсном мире — тот самый Hadoop. либо более современный S3 + Trino (+ обвязка)

https://ytsaurus.tech/ru/platform-overview
Архитектурно YTsaurus состоит из нескольких слоев:

1. распределённая файловая система и хранилище метаданных (Cypress).

2. планировщик с поддержкой парадигмы MapReduce.

3. высокоуровневые среды вычислений: YQL, CHYT (ClickHouse over YT), SPYT (Spark over YT).
Forwarded from DevFM
Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.

Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.

Однако удалось послушать и два хороших выступления:

▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.

▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.

#systemdesign