В статье уже упомянут параметр температуры, который, по факту, являясь параметром в softmax, вносит некий разброс в вероятности следующего токена. Грубо говоря, при нулевой температуре, вероятность самого, хм, вероятного токена будет 1, а остальных - 0. При более высокой - вероятность остальных токенов повышается. Следующий токен выбирается с помощью ГСЧ, для которого есть seed разумеется. Это наглядно объясняет 3Blue1Brown в https://www.youtube.com/watch?v=wjZofJX0v4M
Так что в теории, при нулевой температуре, ответы в разных чатах будут одинаковыми. Но это в теории, в математической абстракции. На практике, как всегда, бывают нюансы, в основном от того, что всё заоптимизировано вусмерть.
Из того, с чем сталкивался сам:
В зависимости от того, в одиночку обрабатывается запрос, или в батче с другими, да даже в зависимости от размера батча, могут быть использованы разные алгоритмы для перемножения матриц и прочего (для разных размерностей матриц некоторые алгоритмы существенно быстрее). С небольшими отличиями в числовой точности.
Также из-за распределения вычислений по разным GPU, порядок их объединения в том же all-reduce может зависить от таймингов, а из-за представления чисел с плавающей точкой, от перемены мест слагаемых может поменяться результат: если сложить два очень маленьких числа, а потом прибавить большое, или наоборот, взять сначала большое и по очереди прибавлять к нему маленькие, результат может немного отличаться.
Вот тут описано как сделать, чтобы появилось. Путано немного, но смысл в том, чтобы сделать REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\BD3B718A-0680-4D9D-8AB2-E1D2B4AC806D /v Attributes /t REG_DWORD /d 2 /f
Думаю, подразумевается, что он должен быть одинаковый для одинаковых элементов. Или оба скруглённые, или оба квадратные. А там вперемешку на неправильном варианте.
Всё равно не очень понятно. Ведь чтобы узнать адрес перехода, нужно декодировать инструкцию целиком.
Классический бранч предиктор, насколько я знаю, держал для каждой ячейки таблицы (адрес бранча поксореный на что-то там) два бита для машины состояний — strong/weak taken/not taken и предсказывал именно, произойдёт условный переход, или нет, чтобы начать out of order execution именно правильной ветки.
Тут, видимо, про другой механизм, который для каждого бранча кеширует именно адрес назначения.
Выигрыш от такого, конечно будет даже для безусловных, а для условных ещё больше, но вот места будет занимать больше, и при коллизиях и миспредикшенах будет возможно больнее.
Непонятно, это дополнительный механизм, или старый заменили на такой вот новый когда-то.
Простите, но ведь эта фраза демонстрирует только, что не на каждый вопрос можно ответить строго «да», либо «нет». Если у вас появляется возможность отвечать развёрнуто (как раз наш случай тут), то есть, к примеру, сказать «А я и не начинал», то абсурдность вопроса исчезает. Ну, кроме, разве что, непонимания, а зачем кого-то вообще это должно волновать :)
ManyCam умеет так делать. Не без недостатков, правда. Бесплатная версия лепит вотермарку свою, а сама эта фишка очень чувствительна к освещению. Стало чуть меньше света из окна — всё, поплыл фон.
В повседневной жизни, со всеми кабельными подключениями, или 4G этими вашими, как правило, не так заметно, поэтому и сходит с рук.
У меня в роуминге скорость мобильного интернета ограничена 256 кб/с или около того. Казалось бы, когда-то о такой могли только мечтать, хватало на всё на свете. А вот заходишь на сайт любого кафе посмотреть меню, а он грузится. И грузится. И через пару минут загружается… крутилка. И крутится еще минут 5. Всё это чтобы показать статическую, по сути своей, страничку на несколько десятков строчек, зачастую даже без картинок. Зато фреймворки, это да.
После научной победы показали пафосный мультик. Полагаю, что и для других такие же припасены. Ну и таблица рекордов и графики развития на месте. Вот только не было (ну или я совсем слепой) таймлапса карты, который я так любил в прошлой части.
Насчет пиксель-арта 9х — меня всегда удивляло, почему на иконке панели управления кошка? Нет, если приглядеться, все становится ясно. Но стоит на секунду отвернуться, и вот опять — ну кошка же!
Я этого и не утверждаю. Как раз наоборот, я думаю, что изначально взять за предпосылку то, что задача проще, чем кажется и отбросить часть условия было бы не очень хорошей идеей. Оно да, кажется интуитивно правильным, и в данном конкретном случае таким и оказалось. Но, как я уже писал, популярный статьи о теории вероятностей полны примеров того, как интуиция подводит.
В общем виде это можно доказать с помощью того же Байеса.
Пусть в левой руке x синих и w красных, а в правой — y синих и z красных.
Тогда:
p(right) = (y+z)/(x+y+w+z)
p(red)=(w+z)/(x+y+w+z)
p(red|right)=z/(y+z)
И в итоге P(right|red)=P(red|right)*P(right)/P(red) = z/(y+z) * (y+z)/(x+y+w+z) * (x+y+w+z)/(w+z) = z/(w+z)
То есть как раз доля красных в правой руке из общего количества красных.
Преимущество такого подхода в том, что при пространных размышнениях о вероятности, наподобие «факт того, что у нас в руке уже лежит красная таблетка, просто отбрасывает все случаи, когда мы выбирали синюю», легко упустить что-то из виду, о чем нам и говорит множество статей о неинтуитивности теории вероятностей (да, тут у автора все сошлось, но он и рассуждал уже имея результат, а не наоборот).
А так все строго, по учебнику :)
В статье уже упомянут параметр температуры, который, по факту, являясь параметром в softmax, вносит некий разброс в вероятности следующего токена. Грубо говоря, при нулевой температуре, вероятность самого, хм, вероятного токена будет 1, а остальных - 0.
При более высокой - вероятность остальных токенов повышается. Следующий токен выбирается с помощью ГСЧ, для которого есть seed разумеется. Это наглядно объясняет 3Blue1Brown в https://www.youtube.com/watch?v=wjZofJX0v4M
Так что в теории, при нулевой температуре, ответы в разных чатах будут одинаковыми. Но это в теории, в математической абстракции. На практике, как всегда, бывают нюансы, в основном от того, что всё заоптимизировано вусмерть.
Из того, с чем сталкивался сам:
В зависимости от того, в одиночку обрабатывается запрос, или в батче с другими, да даже в зависимости от размера батча, могут быть использованы разные алгоритмы для перемножения матриц и прочего (для разных размерностей матриц некоторые алгоритмы существенно быстрее). С небольшими отличиями в числовой точности.
Также из-за распределения вычислений по разным GPU, порядок их объединения в том же all-reduce может зависить от таймингов, а из-за представления чисел с плавающей точкой, от перемены мест слагаемых может поменяться результат: если сложить два очень маленьких числа, а потом прибавить большое, или наоборот, взять сначала большое и по очереди прибавлять к нему маленькие, результат может немного отличаться.
Немножко из моей коллекции
Про логические компоненты:
The Signal State
Silicon Zeroes
Про низкоуровневое программирование:
Comet 64
Alan's Automation Workshop - тут буквально создавать машины Тьюринга
Про высокоуровневое программирование:
Robo Instructus
The Farmer was Replaced
Ну и вообще всё от Зактроникс, включая его последний сборник Last Call BBS, в котором просто всего навалено
...играешь в танки
Это из другого
анекдотасериалаREG ADD HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20\BD3B718A-0680-4D9D-8AB2-E1D2B4AC806D /v Attributes /t REG_DWORD /d 2 /fКлассический бранч предиктор, насколько я знаю, держал для каждой ячейки таблицы (адрес бранча поксореный на что-то там) два бита для машины состояний — strong/weak taken/not taken и предсказывал именно, произойдёт условный переход, или нет, чтобы начать out of order execution именно правильной ветки.
Тут, видимо, про другой механизм, который для каждого бранча кеширует именно адрес назначения.
Выигрыш от такого, конечно будет даже для безусловных, а для условных ещё больше, но вот места будет занимать больше, и при коллизиях и миспредикшенах будет возможно больнее.
Непонятно, это дополнительный механизм, или старый заменили на такой вот новый когда-то.
У меня в роуминге скорость мобильного интернета ограничена 256 кб/с или около того. Казалось бы, когда-то о такой могли только мечтать, хватало на всё на свете. А вот заходишь на сайт любого кафе посмотреть меню, а он грузится. И грузится. И через пару минут загружается… крутилка. И крутится еще минут 5. Всё это чтобы показать статическую, по сути своей, страничку на несколько десятков строчек, зачастую даже без картинок. Зато фреймворки, это да.
и стали искать объяснение.
Пусть в левой руке x синих и w красных, а в правой — y синих и z красных.
Тогда:
p(right) = (y+z)/(x+y+w+z)
p(red)=(w+z)/(x+y+w+z)
p(red|right)=z/(y+z)
И в итоге P(right|red)=P(red|right)*P(right)/P(red) = z/(y+z) * (y+z)/(x+y+w+z) * (x+y+w+z)/(w+z) = z/(w+z)
То есть как раз доля красных в правой руке из общего количества красных.
Преимущество такого подхода в том, что при пространных размышнениях о вероятности, наподобие «факт того, что у нас в руке уже лежит красная таблетка, просто отбрасывает все случаи, когда мы выбирали синюю», легко упустить что-то из виду, о чем нам и говорит множество статей о неинтуитивности теории вероятностей (да, тут у автора все сошлось, но он и рассуждал уже имея результат, а не наоборот).
А так все строго, по учебнику :)