Там вроде зенкер был в оригинале. Ибо по советским гайдам отверстие сначала сверлилось, потом зенкеровалось, а потом, если нужно - разворачивалось. Только вот оказывается, что если делать нормальные сверла - то зенкер не нужен. Достаточно сверла и развертки.
А нигде. Фокус как раз в том что оно само определяет статистически важные характеристики. Автор сего кода (и статьи) предположил что сеть разделит токены на гласные/согласные потому что это статистически важно. Но это нигде не зафиксировано в любом случае. Нельзя даже получить эту информацию из весов модели.
Так Value как раз является узлом графа и хранит в себе локальный градиент. Как без него обойтись? Нужно же от конечного результата (значения функции потерь) пройтись назад по всем вычислениям в самое-самое начало, чтобы там подправить коэффициенты.
Марковская цепь 16-го порядка сожрет экспоненциально больше памяти. Но при этом будет "точнее". А для реальных LLM - это вообще не имеет смысла. Если мы хотим контекст хотя бы в тысячу токенов, нам нужна цепь тысячного порядка. Столько памяти в принципе не найдется.
Но функционально - да, этот тот же бредогенератор. Тем забавнее наблюдать как с ним все носятся.
Я практически уверен что они есть в исходном наборе. Собственно, это как раз хорошо показывает принцип работы LLM: она всегда галлюцинирует. Иногда эти галлюцинации совпадают с реальностью и мы получаем реально существующее имя (или "правильный" ответ от большой LLM), иногда оно просто выдает что-то, что никак не связано с реальностью.
Проблема во всем. Начиная с около "76.3%". Это ж какая у них была выборка и какие крутые статистические методы, что для них три значащих цифры - это "около"?
Во вторых, я не уверен что 76.3% процента россия имеет смартфон вообще. Включая детей, пенсионеров, нищих, заключенных и т.д.
Ну и в третьих, вы точно уверены что у 3 из 4 человек в общественном транспорте будут айфоны?
Такое ощущение что мы с вами читали две разных статьи. Подметание пола - это просто фон. Знаете как в начале книги автор устанавливает контекст: "события разворачиваются на космической станции в 2075 году". Хотя, большинство историй можно рассказать используя другие декорации. Типа, если сменить старушку-процентщицу на крипто-барыгу, а Петербург - на Лондон, то в принципе ничего в "Преступлении и наказании" не изменится.
Так вот, статья не про полы. И даже не про оптимизацию движения на двухмерной карте. Это - всего лишь иллюстрации к главной, но довольно таки банальной мысли - "надо правильно выбирать критерий оптимизации". Точно такую же статью можно было написать про KPI, например. Как неправильно выбранный KPI все делает только хуже. Но обсуждение KPI уже всех задолбало, а тут - что-то новенькое.
Интересно, а какой смысл в HMB если ОС и так использует всю свободную память как файловый кеш? Или в HMB накопитель сбрасывает содержимое блоков которые он собирается обновлять частично?
А какая разница - почему? То же самое можно сказать про большинство картин известных поп-культуре: "Крик", "Звездное небо", "Искушения святого Антония" и т.д.
Ну что-нибудь уровня черного квадрата, например. Что-то новое и неожиданное. Чтобы люди потом об этом еще 100 лет говорили.
Кстати, я вот попросил нарисовать тот же черный квадрат на белом фоне. Он только с пятого раза справился, все норовил добавить тени, даже если я просил без теней.
Иногда занимаюсь литьем силикона и полиуретана. Понял что дегазировать нужно в меру. Если перестараться - то действительно может начать пениться там где не надо. Но и если не дегазировать, то пузырьки будут. Главное - дегазировать перед заливкой. Если пытаться дегазировать состав который уже залит в форму - выйдет полная шляпа.
Вторая, неочевидная проблема с дегазацией состоит в том, что некоторые вещества в составе эпоксидки - довольно таке летучие и если перестараться с дегазацией, то можно оставить смесь без нужного ингредиента, ибо он тупо улетучится.
Так оно ж даже не компилируется. При том что CI там настроен, но последних 4 дня все проверки фейлятся. Даже при том, что последний (на данный момент) называется "resolve browser binary compilation errors", оно нифига не компилируется.
Там вроде зенкер был в оригинале. Ибо по советским гайдам отверстие сначала сверлилось, потом зенкеровалось, а потом, если нужно - разворачивалось. Только вот оказывается, что если делать нормальные сверла - то зенкер не нужен. Достаточно сверла и развертки.
Да, согласен. Тут автор налажал с формулировкой.
А нигде. Фокус как раз в том что оно само определяет статистически важные характеристики. Автор сего кода (и статьи) предположил что сеть разделит токены на гласные/согласные потому что это статистически важно. Но это нигде не зафиксировано в любом случае. Нельзя даже получить эту информацию из весов модели.
Так
Valueкак раз является узлом графа и хранит в себе локальный градиент. Как без него обойтись? Нужно же от конечного результата (значения функции потерь) пройтись назад по всем вычислениям в самое-самое начало, чтобы там подправить коэффициенты.Марковская цепь 16-го порядка сожрет экспоненциально больше памяти. Но при этом будет "точнее". А для реальных LLM - это вообще не имеет смысла. Если мы хотим контекст хотя бы в тысячу токенов, нам нужна цепь тысячного порядка. Столько памяти в принципе не найдется.
Но функционально - да, этот тот же бредогенератор. Тем забавнее наблюдать как с ним все носятся.
А как вы предлагаете это оптимизировать?
Насколько я понимаю, то смысл как раз в том, чтобы все влияло на все. Поэтому и n^2.
Я практически уверен что они есть в исходном наборе. Собственно, это как раз хорошо показывает принцип работы LLM: она всегда галлюцинирует. Иногда эти галлюцинации совпадают с реальностью и мы получаем реально существующее имя (или "правильный" ответ от большой LLM), иногда оно просто выдает что-то, что никак не связано с реальностью.
В конце статьи есть FAQ. Буквально первый же вопрос - это именно то о чем вы спрашивали.
Если люди неспособны осмыслить текст перед ними, то чего вы ожидаете от машины?
Проблема во всем. Начиная с около "76.3%". Это ж какая у них была выборка и какие крутые статистические методы, что для них три значащих цифры - это "около"?
Во вторых, я не уверен что 76.3% процента россия имеет смартфон вообще. Включая детей, пенсионеров, нищих, заключенных и т.д.
Ну и в третьих, вы точно уверены что у 3 из 4 человек в общественном транспорте будут айфоны?
Это вы про Абрамсы с турбинной установкой? Там, конечно, да...
Такое ощущение что мы с вами читали две разных статьи. Подметание пола - это просто фон. Знаете как в начале книги автор устанавливает контекст: "события разворачиваются на космической станции в 2075 году". Хотя, большинство историй можно рассказать используя другие декорации. Типа, если сменить старушку-процентщицу на крипто-барыгу, а Петербург - на Лондон, то в принципе ничего в "Преступлении и наказании" не изменится.
Так вот, статья не про полы. И даже не про оптимизацию движения на двухмерной карте. Это - всего лишь иллюстрации к главной, но довольно таки банальной мысли - "надо правильно выбирать критерий оптимизации". Точно такую же статью можно было написать про KPI, например. Как неправильно выбранный KPI все делает только хуже. Но обсуждение KPI уже всех задолбало, а тут - что-то новенькое.
Вслед за Microsoft, гугл пытается запихнуть ИИ в каждую щель. "Ну пожалуйста, ну пользуйтесь нашим ИИ"
Интересно, а какой смысл в HMB если ОС и так использует всю свободную память как файловый кеш? Или в HMB накопитель сбрасывает содержимое блоков которые он собирается обновлять частично?
На Марсе можно будет устроить такой технофашизм, который тут на Земле и не снился.
А какая разница - почему? То же самое можно сказать про большинство картин известных поп-культуре: "Крик", "Звездное небо", "Искушения святого Антония" и т.д.
Ну что-нибудь уровня черного квадрата, например. Что-то новое и неожиданное. Чтобы люди потом об этом еще 100 лет говорили.
Кстати, я вот попросил нарисовать тот же черный квадрат на белом фоне. Он только с пятого раза справился, все норовил добавить тени, даже если я просил без теней.
А то что робот пишет код? Сядете в самолет, авионику которому писал робот?
А, действительно. Ведь космонавт - в первую очередь коммунист, а потом уже - мужчина или женщина.
Иногда занимаюсь литьем силикона и полиуретана. Понял что дегазировать нужно в меру. Если перестараться - то действительно может начать пениться там где не надо. Но и если не дегазировать, то пузырьки будут. Главное - дегазировать перед заливкой. Если пытаться дегазировать состав который уже залит в форму - выйдет полная шляпа.
Вторая, неочевидная проблема с дегазацией состоит в том, что некоторые вещества в составе эпоксидки - довольно таке летучие и если перестараться с дегазацией, то можно оставить смесь без нужного ингредиента, ибо он тупо улетучится.
Так оно ж даже не компилируется. При том что CI там настроен, но последних 4 дня все проверки фейлятся. Даже при том, что последний (на данный момент) называется "resolve browser binary compilation errors", оно нифига не компилируется.