#fun #openings #retro #covers #friday

https://youtu.be/CzdO8Hd_Wxc

Красивый кавер и заставка. А сам мини-сериал 1899 я рекомендую лишь тем, кто хочет сломать себе мозг )

One pill makes you larger,
And one pill makes you small.
And the ones that mother gives you
Don’t do anything at all.

Feed your head
When logic and proportion
Have fallen sloppy dead,
And the White Knight is talking backwards
And the Red Queen’s off with her head.

#news #law #dataleaks

А ведь в своё время топам фэйсбука сотрудничество с Cambridge Analytica наверняка казалось отличной идеей.

https://3dnews.ru/1079328/meta-soglasilas-uregulirovat-isk-po-intsidentu-s-cambridge-analytica-za-725-millionov

"Внесудебное урегулирование завершит тяжбу, начало которой было положено в 2018 году, когда стало известно об открытии Facebook данных 87 млн пользователей платформы британской компании Cambridge Analytica, специализировавшейся на политическом консалтинге. Адвокаты истцов назвали сумму в $725 млн крупнейшей в истории урегулирования коллективных исков по конфиденциальности данных в США и максимальной выплатой со стороны Meta в адрес коллективного истца. При этом компания не признала факта правонарушений и заявила, что согласилась на урегулирование иска «в интересах сообщества и акционеров».
В 2019 году компания выплатила $5 млрд за урегулирование расследования Федеральной торговой комиссии (FTC) в отношении её политики конфиденциальности и $100 млн за урегулирование претензий Комиссии по ценным бумагам и биржам (SEC) за введение инвесторов в заблуждение в отношении неправомерного применения персональных данных пользователей."

#knowledgemanagement

https://www.youtube.com/watch?v=L9SLlxaEEXY&ab_channel=morganeua

Пример работы по методу Zettelkasten: добавление книги, написание заметки, линковка с другой заметкой.

Давай-давай, пиши документацию

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

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

Считаем, что в докстрингах должно быть описано назначение функций с пояснением каких-то особо хитрых моментов, описаны принимаемые и возвращаемые параметры. Мы используем гугл нотацию. Также в комплекте с докстрингами неразрывно идет аннотация типов. Это особенно важно, когда на входе какие-то сложные структуры данных. Целью является облегчение чтения кода.

Теперь о ридми. У нас на проектах ридми состоит из следующих блоков:
— Вводная часть, где тезисно указываем общее назначение сервиса. Если у сервиса чётко выраженное назначение, то описываем общий алгоритм работы.

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

И, конечно, мы всё запускаем в докере. О важности докера у нас есть отдельный пост.

В этом же разделе также важно описать, как запускать тесты. Очень важно.

— Переменные окружения и опции. Сложный проект требует настройки, поэтому обязательно указываем набор переменных окружения, которые нужны в проекте, с описанием их назначения и дефолтными значениями.

— В разделе "другое" пишем о каких-то специфичных для проекта моментах. К таким особенностям может относится, например, накатывание миграций.

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

Резюмируя, чем больше вы дадите информации о том, как запускать, как управлять проектом, какие у него есть особенности, тем лучше. Это облегчит вход любому разработчику. С увеличением числа проектов качественная документация становится критически важной. Во время разработки кажется: да всё понятно, как запускать эту штуку. А через пол года написанный вами проект будет выглядеть чужим и непонятным.

И ещё мысль по поводу документации:
Считаем вредным советом или требованием писать документацию в каких-то сторонних системах, таких как конфлюенс (да, порой и такое требуют). Практика показала, что поддержание документации в актуальном виде в стороннем сервисе, мягко говоря, не работает. Очень сложно убедить и даже заставить разработчика поддерживать доку где-то в сторонней приблуде. С ридми проще — можно писать, не отходя от кассы. И контролировать легче, проверяя изменение доки в merge request.
#devfm #procode

#futurology #AI #singularity #Kurzweil #evolution #metaverse #brainsandthumbs #neurallink #backwardsthinking #digitalafterlife #itweetthereforeiam #intothestars #nanobots #alienlife #immortality

https://www.youtube.com/watch?v=ykY69lSpDdo&t=947s&ab_channel=LexFridman

Интервью с Рэем Курцвейлом, футурологом, предсказавшим в 1999-м, что машина начнёт проходить тест Тьюринга к 2029-му. Он всё ещё настаивает на этой дате, считает, что именно большие языковые модели станут основой прорыва в ИИ, более того, этот прорыв уже начался и будет продолжаться постепенно – многие уже и не могут по ответам отличить подобную модель от человека. Замечу, что видео записано до выхода ЧатГПТ, и названный Рэем срок кажется весьма правдоподобным. Обсуждается то, что способность проходить тест Тьюринга ещё не означает наличия сознания, да и сознание на "небиологическом" носителе будет отличаться от человеческого – его можно будет остановить, "отмотать во времени", и т.д. Далее остаётся подключение ИИ к неокортексу с целью усиления мыслительных способностей человека. К 2045, по Рэю, они усилятся в миллионы раз, и наступит "сингулярность" – время непредставимых пока возможностей и целей для человечества.

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

https://www.youtube.com/watch?v=zprg2WbmgzQ

#chess #gm #naro

Познавательно! Гроссмейстер Народицкий чётко объясняет ход своих рассуждений при оценке позиции. А какое красивое название дебюта )

InstructGPT — модель, на основе которой работает ChatGPT от OpenAI

Мы все знаем GPT-3: огромная языковая модель, которая отлично умеет в генерацию правдоподобного, и даже имеющего нужный (почти всегда) смысл текста. Но в роли диалоговой системы (чат-бота) стандартный GPT-3 не слишком хорош: часто случается так, что он генерирует текст, совсем не соответствующий запросу юзера. Это неудивительно, ведь GPT-3 обучался на текстах из интернета, а не парах “запрос-ответ”, и во время обучения цель модели была генерировать правдоподобный текст (предсказывать следующий токен на основе предыдущих), а не “выдать текст, соответствующий запросу юзера”.

В OpenAI решили затюнить GPT-3 специально на задачу взаимодействия с пользователем, и получили InstructGPT. Вот как это сделали:
1. Сгенерировали несколько текстов запросов и наняли 40 людей, которые вручную составили к этим запросам ответы. Получили пары (запрос-ответ), на которых в обычном supervised режиме затюнили GPT-3;
2. Взяли затюненную с первого шага модель и попросили ее выдать несколько вариантов ответов на разные запросы. Попросили людей отранжировать ответы на каждый запрос: от самого релевантного, полного и правильного до самого плохого. На этих размеченных данных натренировали reward model (RM), которая по паре (запрос-ответ) дает оценку, насколько хорош этот ответ на запрос.
3. Используя RM, дообучили GPT-3 с шага 1 в reinforcement learning парадигме.

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

Конечно, InstructGPT (и ChatGPT в частности) — далеко не AGI. У него все еще есть серьезные недостатки. Например:
- ChatGPT может врать. Например, на запрос “расскажи об эпохе возрождения” выдать правдоподобный бред. Это, опять же, неудивительно: при обучении ни GPT-3, ни InstsructGPT корректность ответов никак не регулировалась;
- Небольшое изменение текста запроса может сильно поменять ответ модели. Например, в одном случае она может выдать. “я не знаю”, а во втором — сгенерить вполне хороший ответ (проверено в соседнем чатике, это действительно так);
- В идеале авторы хотели бы, чтобы ChatGPT спрашивала уточняющие вопросы, если запрос пользователя не очень понятный. Но вместо этого модель чаще всего начинает сразу писать ответ, как бы “угадывая”, что именно хотел пользователь;
- Ну и наша любимая тема: bias, hate speech и все такое. ChatGPT все же может выдавать плохие шутки и подобное, как бы авторы ни старались это нивелировать ¯\_(ツ)_/¯

Статья InstructGPT

A Generalist Neural Algorithmic Learner

А еще на основе своего датасета CLRS-30 DeepMind обучили графовую нейросеть решать все эти 30 алгоритмических задач.

Модель устроена по тому же принципу, что и большинство моделей для решения сразу большого набора задач. Она состоит из трех частей (см картинку):
- Нескольких отдельных голов-энкодеров, каждая из которых кодирует вход для одной из тридцати задач. Каждый энкодер принимает на вход граф и кодирует информацию в его вершинах и ребрах в общее пространство эмбеддингов. Получается набор (x_i, e_ij, g), где x_i — эмбеддинги вершин графа, e_ij — эмбеддинги ребер графа и g — эмбеддинг графа в целом.
- Одной центральной части-процессора P, который обрабатывает вход из голов. P — это графовая нейросеть, она принимает и выдает на выход информацию в виде набора эмбеддингов вершин, ребер и графа (x_i, e_ij, g)
- Нескольких отдельных голов-декодеров, каждая из которых декодирует выход процессора P из общего пространства эмбеддингов в вид графа;

Работает это вес довольно неплохо, намного лучше других ранее придуманных алгоритмов (DeepMind протестили несколько из них на CLRS-30 и сравнили метрики). По F1-micro в среднем получается 74%, что, кажется, довольно неплохо. У лучшего конкурента F1-micro около 50%

Подробнее о модели читайте в статье

#dating #ml

Кто пробовал Тиндер, Баду? Да, там хотя бы есть люди, в отличие от других сайтов знакомств.
Но… Меня одного раздражает необходимость ручного отсеивания сотен кандидатов? Ну можно же по моим свайпам быстро понять, на что я смотрю (в, скажем, фото или анкете), и кого мне надо показывать, а кого нет? Или это специально НЕ делается, чтобы юзеры проводили в приложении месяцы, покупая подписку? Но почему эта опция не продается за бОльшие деньги тогда? Я точно видел, что в тиндере в штате дата сайентисты есть...
Поправочка. У Тиндера всё же есть что-то подобное, Top Picks, но как же примитивно это сделано...

https://www.youtube.com/watch?v=4ixKONimf1g&ab_channel=TextGod

Семейство GPT прекрасно!

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

#postgres #storage #optimization #dba
Возникла в процессе работы над моделью соцсети проблема: гигантский размер таблицы фолловеров. При количестве юзеров порядка 130K количество связей между ними уже превышает 80M. Юзер имеет от нуля до 800K подписчиков (медиана 25, среднее 468) и сам подписан на от нуля до 160К инфлюенсеров (медиана 28, среднее 186).
Табличка вида
create table users_followers(
target_user_id text ,
following_user_id text,
link_prev_from bigint,
link_next_from bigint,
position smallint,
added_at timestamp default (now() at time zone 'utc'),
primary key (target_user_id,following_user_id)
);
занимает уже 6 Гб, а первичный ключ - 4Гб. link_prev_from/ link_prev_to/position это, по сути, оценки времени, когда юзеры подружились; added_at это момент времени, когда связь была установлена внешним наблюдателем.
Хранится всё в ванильном Постгре 15 на Ubuntu 20.04 LTS, FS=ext4. После недавнего инцидента никаких дисков кроме ssd для баз я использовать не хочу, следовательно, пространство дорого (скажем, на 1 машинке есть 3.5TB SSD storage). С учётом того, что данные после записи не модифицируются и не удаляются, а только читаются и вставляются, и всего ожидается около 100M юзеров, как бы Вы подошли к оптимизации хранения таких связей? Запросы сводятся к
1) случайной выборке флолловеров (и последующей проверке их id по другой табличке) SELECT following_user_id FROM users_followers TABLESAMPLE SYSTEM_ROWS(1000)
2) получению всех записей/всех полей по target_user_id в пакетном режиме.
Итоговым решением поделюсь позже, а пока буду рад советам ) Вдруг подобную задачу подписчики уже решали.
Пример строки target_user_id,following_user_id,link_prev_from,link_next_from,position,added_at:
"10000187a48d";"fc632fb4596f";1657686648645;1657686624495;23; "2023-01-11 13:02:11.064876"
Размеры заполненных полей в байтах: 13,13,8,8,2,8.