Сигнал может проходить только через определенные последовательности нейронов, и прямые связи между группами нейронов в разных областях - физически невозможны.
Там еще есть таламус. Через него, если упрощенно, "всё связано со всем". А "прямые связи" между кортикальными колонками довольно ограничены и больше для технического низкого уровня, чем для коммуникации между нейрональными ансамблями.
Возможно я невнимательно прочитал, но как бот переводит подарки жертвы себе? Какое подтверждение от жертвы нужно? Ведь не может же любой бот, которому я напишу сообщение, просто так переводить себе мои подарки? В какой момент у пользователя запрашивается разрешение на это действие и как такое разрешение выглядит? 🤔
В соответствии с гипотезами о работе сознания Майкла Грациано и Константина Анохина. Спрашивать чатгпт что такое "динамики внимания" и "когнитом", оно все расскажет лучше меня.
Поспорить с этой позицией с точки зрения биологии, биохимии, нейрофизиологии etc., действительно, не получится.
Это если LessWrong не читать 😂 Если читать, то с удивлением видишь, что у канонического эксперимента "приборы показали, что мозг принимает решение нажать на кнопку 10 секунд до того, как человек это решение осознал, гы, лол" есть пара десятков трактовок.
Самое простое и тривиальное звучит так: "Испытуемому предлагают нажать на кнопку в случайный момент времени. Испытуемый запускает в сознании процесс 'выбери мне случайный момент времени примерно в радиусе минуты'. Процесс сразу выбирает время, ждет, после чего рапортует в сознание 'будильник зазвенел'. Человек смотрит на часы и запоминает, во сколько 'он принял решение'. А приборы показывают работу того самого процесса, получая числа от нескольких сотен миллисекунд до несколько секунд (!!!) раньше, чем человек принял 'осознанное' решение".
Высокоуровнево YDB может себе позволить распределенные транзакции по двум причинам:
У нее разделение storage и compute. То есть процесс(ы), которые выполняют запрос, и так читают и пишут данные по сети. При такой архитектуре нет разницы, на одном сервере находятся такие данные или на сотне.
У нее акторная модель. Слой вычисления выполняет легковестные акторы с надежно сохраняемым стейтом и дает им возможность обмениваться сообщениями. Тоже по сети. Для акторов их бессмертие и возможность безнаказанно отправлять друг другу сообщения — тот мир, в котором они существуют. Ну и в рамках такого мира уже несложно организовать оркестрацию любого количества изменений в рамках транзакции 😊
Мануальный навык вождения машины можно приобрести или за годы опыта, или пройдя соответствующие курсы. На курсах, кстати, начнут с того, что привьют водителю элементарную грамотность: как правильно держать руки на руле (многие не умеют!), как правильно рулить и пользоваться педалями. Только освоив эту базу, можно учиться чему-то более полезному.
Интересная аналогия. Действительно, есть сильные гипотезы о том, что мозг способен экстраполировать и заимствовать способы думания об алгоритмах (так называемые в нейрофизиологии "динамики внимания") на нашу ежедневную работу по написанию кода.
Тем не менее, хороших подтверждений такой гипотезы я не встречал. Возвращаясь к аналогии про мануальный навык воздения машины. Говорить о том, что инвестиция нескольких месяцев в решение литкода и формулирование алгоритмов по памяти помогает в работе программистов — это примерно как говорить о том, что умение бегать марафоны сильно помогает водить машину. Координация, физическая подготовка, фокус внимания на дороге и вот это всё.
Причем, если собрать статистику, то, возможно, среди тех, кто бегает марафоны действительно аварий меньше. Но вопрос будет в том, переиспользует ли мозг навыки бега марафонов для вождения машины как "базу", или же и то и другое коррелирует с чем-то другим. Например, собранностью, целеустремленностью, хорошей физической формой или какими-то чертами характера.
Если ты Гугл, то можно при сдаче на права требовать пробежать марафон, 100 раз отжаться, 50 раз подтянуться, поразить мишеть из лука, перевести текст с Японского и ответить устно на вопрос по-английски. Возможно, в таком случае аварий будет меньше. Но это — если ты Гугл. Во всех остальных случаях your mileage may vary 😥.
Из любопытного: в cSpell есть настройка checkLimit, которая указывает сколько килобайт файла спеллчекать. И по умолчанию она установлена в 500. Что на больших .md'шках может легко не хватить и возникает криповая ситуация, когда часть файла спеллчекер проверяет, а часть — нет. И никаких ошибок или варнингов в консоли VSCode. Мне пришлось покопаться в сорцах расширения VSCode и потом cSpell, чтобы обнаружить эту настройку 😳
@andrei777777, я в 2017 году про это рассказывал на Python Junior Meetup. И, если посмотреть на комментарии к видео, то можно увидеть, что гостям и зрителям очень не понравилось 😂 Сейчас дописываю новый учебник, возможно, в виде книжки получится лучше 😳
Однако более поздние исследования, в частности работы Нельсона Коуэна, показали, что реальный объём рабочей памяти ещё меньше – всего 3-4 элемента информации одновременно. Это означает, что при превышении этого лимита новая информация начинает вытеснять старую, что затрудняет принятие решений и выполнение сложных задач.
Приввет, спасибо за статью! Скажи, если реальный объем рабочей памяти всего 3-4 элемента, то как мы способны помнить содержание 30-минутного разговора с друзьями в кафе, 45-минутную лекцию в институте и в целом очень много событий за день к вечеру?
RAG это "подход". Поискать в базе похожие тексты и скормить в промпте вместе с запросом. Эмбеддинги - способ быстрого поиска похожих текстов, деталь технической реализации.
"эмбеддинг" - это числовое представление "выжимки" из текста. "Вектор", как их еще называют. Они используются, потому что, в отличии от текста, их можно сравнивать друг с другом на предмет "похожести". То есть имея вектор текста запроса от пользователя и векторную базу данных, в которой сохранены векторы миллионов фрагментов текста из базы знаний, можно быстро найти все фрагменты, которые "похожи" на запрос пользователя. Иначе сравнение текста с другими текстами займет бесконечно много времени. То есть просто вопрос оптимизации поиска.
Там еще есть таламус. Через него, если упрощенно, "всё связано со всем". А "прямые связи" между кортикальными колонками довольно ограничены и больше для технического низкого уровня, чем для коммуникации между нейрональными ансамблями.
Возможно я невнимательно прочитал, но как бот переводит подарки жертвы себе? Какое подтверждение от жертвы нужно? Ведь не может же любой бот, которому я напишу сообщение, просто так переводить себе мои подарки? В какой момент у пользователя запрашивается разрешение на это действие и как такое разрешение выглядит? 🤔
Пользуясь случаем, я немного рассказал как это работает на прошлом Московском Highload:
В соответствии с гипотезами о работе сознания Майкла Грациано и Константина Анохина. Спрашивать чатгпт что такое "динамики внимания" и "когнитом", оно все расскажет лучше меня.
Это если LessWrong не читать 😂 Если читать, то с удивлением видишь, что у канонического эксперимента "приборы показали, что мозг принимает решение нажать на кнопку 10 секунд до того, как человек это решение осознал, гы, лол" есть пара десятков трактовок.
Самое простое и тривиальное звучит так: "Испытуемому предлагают нажать на кнопку в случайный момент времени. Испытуемый запускает в сознании процесс 'выбери мне случайный момент времени примерно в радиусе минуты'. Процесс сразу выбирает время, ждет, после чего рапортует в сознание 'будильник зазвенел'. Человек смотрит на часы и запоминает, во сколько 'он принял решение'. А приборы показывают работу того самого процесса, получая числа от нескольких сотен миллисекунд до несколько секунд (!!!) раньше, чем человек принял 'осознанное' решение".
Мда. С крокодилом, конечно, справилось лучше 😳 Ниже пример от ChatGPT. Которая перерисовала изображение, но с задачей справилась.
ChatGPT, кстати, в чате справляется. Но картинку, конечно, перерисовывает 😂
Описанное как-то доступно в гигачате? Если просто попробовать фокусы из статьи то текущая версия вообще игнорирует приложенные изображения.
Это не то же самое, что делает Caddy-Docker-Proxy?
Разделение на compute & storage позволяет проще организовать распределение по нодам с сохранением отказоустойчивости. И делает акторы бессмертными 😊
Высокоуровнево YDB может себе позволить распределенные транзакции по двум причинам:
У нее разделение storage и compute. То есть процесс(ы), которые выполняют запрос, и так читают и пишут данные по сети. При такой архитектуре нет разницы, на одном сервере находятся такие данные или на сотне.
У нее акторная модель. Слой вычисления выполняет легковестные акторы с надежно сохраняемым стейтом и дает им возможность обмениваться сообщениями. Тоже по сети. Для акторов их бессмертие и возможность безнаказанно отправлять друг другу сообщения — тот мир, в котором они существуют. Ну и в рамках такого мира уже несложно организовать оркестрацию любого количества изменений в рамках транзакции 😊
А в случае rollback получилась бы катастрофа 😂
Интересная аналогия. Действительно, есть сильные гипотезы о том, что мозг способен экстраполировать и заимствовать способы думания об алгоритмах (так называемые в нейрофизиологии "динамики внимания") на нашу ежедневную работу по написанию кода.
Тем не менее, хороших подтверждений такой гипотезы я не встречал. Возвращаясь к аналогии про мануальный навык воздения машины. Говорить о том, что инвестиция нескольких месяцев в решение литкода и формулирование алгоритмов по памяти помогает в работе программистов — это примерно как говорить о том, что умение бегать марафоны сильно помогает водить машину. Координация, физическая подготовка, фокус внимания на дороге и вот это всё.
Причем, если собрать статистику, то, возможно, среди тех, кто бегает марафоны действительно аварий меньше. Но вопрос будет в том, переиспользует ли мозг навыки бега марафонов для вождения машины как "базу", или же и то и другое коррелирует с чем-то другим. Например, собранностью, целеустремленностью, хорошей физической формой или какими-то чертами характера.
Если ты Гугл, то можно при сдаче на права требовать пробежать марафон, 100 раз отжаться, 50 раз подтянуться, поразить мишеть из лука, перевести текст с Японского и ответить устно на вопрос по-английски. Возможно, в таком случае аварий будет меньше. Но это — если ты Гугл. Во всех остальных случаях your mileage may vary 😥.
Из любопытного: в cSpell есть настройка
checkLimit, которая указывает сколько килобайт файла спеллчекать. И по умолчанию она установлена в 500. Что на больших.md'шках может легко не хватить и возникает криповая ситуация, когда часть файла спеллчекер проверяет, а часть — нет. И никаких ошибок или варнингов в консоли VSCode. Мне пришлось покопаться в сорцах расширения VSCode и потом cSpell, чтобы обнаружить эту настройку 😳О, спасибо, я тоже не знал что
addWordsуже не используется. Респект!@andrei777777, я в 2017 году про это рассказывал на Python Junior Meetup. И, если посмотреть на комментарии к видео, то можно увидеть, что гостям и зрителям очень не понравилось 😂 Сейчас дописываю новый учебник, возможно, в виде книжки получится лучше 😳
Приввет, спасибо за статью! Скажи, если реальный объем рабочей памяти всего 3-4 элемента, то как мы способны помнить содержание 30-минутного разговора с друзьями в кафе, 45-минутную лекцию в институте и в целом очень много событий за день к вечеру?
Все картинки генерируются одним промптом? Или как обеспечивается сохранение визуального стиля?
RAG это "подход". Поискать в базе похожие тексты и скормить в промпте вместе с запросом. Эмбеддинги - способ быстрого поиска похожих текстов, деталь технической реализации.
"эмбеддинг" - это числовое представление "выжимки" из текста. "Вектор", как их еще называют. Они используются, потому что, в отличии от текста, их можно сравнивать друг с другом на предмет "похожести". То есть имея вектор текста запроса от пользователя и векторную базу данных, в которой сохранены векторы миллионов фрагментов текста из базы знаний, можно быстро найти все фрагменты, которые "похожи" на запрос пользователя. Иначе сравнение текста с другими текстами займет бесконечно много времени. То есть просто вопрос оптимизации поиска.