помню было такое приложение, Bump, кажется, которое позволяло обмениваться данными через постукивание телефонами. То есть запускается приложение на двух телефонах, потом вы ими слегка стукаетесь и они соединяются. Как я понимаю, работало это на точном измерении времени, сервер проверял, что два, находящихся примерно рядом телефона одновременно получили встряску и соединял их. Так и тут, можно ввести оплату путем удара телефоном об терминал))
Железо железу рознь. Насколько я слышал от людей, которые реально занимаются мэнфреймами, основная фишка там -- производительность I/O. Архитектура PC никогда не затачивалась на такое количество запросов в секунду, какое легко выдерживает мэнфрейм, отчего проваливаются многие попытки мигрировать с мэнфреймов на более дешевые решения.
То есть они предлагают генерировать секретные ключи на основе данных, которые любезно будет предоставлять третья сторона? Отличный план! Что в нем может пойти не так?!
Проблема в том, что мы достоверно знаем, как устроен и работает LLM. Во-первых, он абсолютно не похож по устройству не только на нас, но даже на омаров или осьминогов. То есть мы не можем признать его разумным по аналогии. Во-вторых, он устроен до смешного просто -- в цикле умножает вектор на матрицу. Да, большой вектор и да, огромная матрица, но сам процесс прост до неприличия. Мы любое устройство, способное к перемножению, должны признать разумным?
В астрономии эксперимент заменен наблюдением. Там есть определенные особенности, связанные с тем, что наблюдения невозможно повторить, но, в целом, они не сильно мешают. Астрофизика это просто раздел физики, в ней используются те же уравнения и те же методы, просто они применяются к специфическим объектам. Астрофизические теории вполне фальсифицируемы и научны.
Кроме тех, кто садится (или падает) на воду. Или тех, кто сгорает (взрывается) в полете. А как на счет случая, когда один самолет несет другой летательный аппарат, который отделяется от него в полете? Отдельно рассмотрим случаи, когда после этого садятся оба (на землю? на воду?), садится только один, ни один не садится.
Наследование есть, разумеется, даже множественное. Метапрограммирование это второе имя лиспа) Про значения полей в коде не очень понятно, но, ничто не мешает сгенерировать на ходу исходник нужной функции с вшитыми нужными значениями (знаменитый синтаксис лиспа со скобочками позволяет естественно работать с кодом, как с данными), прямо на ходу же ее скомпилировать в машинный код и подставить в нужное место. Так же точно можно обновить методы и вообще любые части кода.
Такой подход, с модификацией классов, уже много лет как реализован в объектной системе Common Lisp CLOS. Там можно на ходу, в уже исполняемой программе, поменять определение класса и все объекты автоматически перестроятся. Удаленные поля исчезнут, новые появятся и будут проинициализированы как надо. Для сложных случаев пишутся специальные методы, которые автоматически вызываются, если класс был обновлен, там можно вставить логику любой сложности, которая обновит поля. Всё же, известная шутка про то, что любая сложная программа содержит в себе неполную и багованную версию лиспа, не совсем шутка))
Я думаю, всё проще. В сети появляется всё больше статей про то, как LLM могут обходить защиту, про самокопирование и вранье пользователю. Эти статьи попадают в обучающие выборки... OH, WA...
У меня была идея, до реализации которой руки, разумеется, не дошли (ну, не совсем не дошли, остановились на первом этапе, создании библиотеки OMGlib), автоматизировать создание интерфейсов вообще. Идея, в общем, как раз сводится к том, что нужно добавить в интерфейс стратегию. Идеальный интерфейс должен:
Автоматически делать всё, что можно сделать автоматически
Если всё что можно сделать автоматически уже сделано, нужно спросить у пользователя что-то, что позволит сделать автоматически еще какую-нибудь часть работы
То есть, например, библиотекарь заполняет карточки на новые книги. Интерфейс не знает, что за очередная книга лежит перед библиотекарем, а по ней надо заполнить с десяток значений – название, автора и пр. Идеальный интерфейс на этом этапе должен спросить главное – ISBN книги, после чего полезть в базу данных ISBN и скачать всё, что об этой книге известно, заполнив по возможности все поля. Если каких-то полей не хватает, например, не понятно, в какой шкаф на какую полку нужно поставить книгу, интерфейс должен свериться со списком шкафов, выбрать подходящий и спросить, на какой полке есть место для этой книги. Ну и так далее.
Или, например, приходит покупатель в интернет-магазин за продуктами. Идеальный интерфейс должен сперва опознать пользователя (по имени и паролю, например) и найти историю его покупок. Если он всегда покупает молоко, причем предпочитает определенную марку, например, сразу же спросить – добавить молоко такой-то марки в корзину? Если он положил в корзину кочан капусты, сразу же предложить ему картошку, морковку, свеклу, мясо на косточке и рецепт борща. Нет? Тогда ингредиенты для рагу.
В целом, это должно выглядеть как "прочистка каналов орошения на поле". Мы пускаем воду и вода сама заполняет те части каналов, к которым у нее есть доступ. Крестьянин (пользователь) идет к ближайшему затору и прочищает его, давая воде заполнить еще часть системы, пока всё не будет заполнено. Я хотел реализовать что-то типа DSL для описания того, что система хочет знать, представив, вероятно, это описание в виде графа, для каждого узла которого можно было бы назначить функцию, которая бы срабатывала, как только у нее соберутся все входные параметры и выдавала бы что-то, что было бы параметром для других функций-узлов. Тогда можно было бы найти самую "горячую точку" на графе, проход которой дал бы больше всего возможностей для выполнения других узлов, получить список недостающих данных и запросить их у пользователя в наиболее удобном виде, например, поставив на видное место наиболее вероятные варианты. Как только выбор будет сделан, снова найти "горячую точку" и т.д.
Как правило речь идет о переписывании формул так, чтобы избежать вычитания приблизительно равных величин. Особенности инструкций никто не учитывает, конечно.
помню было такое приложение, Bump, кажется, которое позволяло обмениваться данными через постукивание телефонами. То есть запускается приложение на двух телефонах, потом вы ими слегка стукаетесь и они соединяются. Как я понимаю, работало это на точном измерении времени, сервер проверял, что два, находящихся примерно рядом телефона одновременно получили встряску и соединял их. Так и тут, можно ввести оплату путем удара телефоном об терминал))
Ну и отлично же! Так у каждого из нас остается шанс решить эту проблему и прославиться!
Главное -- не превращать программирование в скучную рутину. Всех денег не заработаешь, а вот потерянный интерес к жизни найти потом ой как не просто.
На GPU далеко не все алгоритмы ложатся, увы. Они только для очень специфичных задач.
Железо железу рознь. Насколько я слышал от людей, которые реально занимаются мэнфреймами, основная фишка там -- производительность I/O. Архитектура PC никогда не затачивалась на такое количество запросов в секунду, какое легко выдерживает мэнфрейм, отчего проваливаются многие попытки мигрировать с мэнфреймов на более дешевые решения.
Вообще, выглядит как план. Уничтожить все книги на планете, предварительно залив их в нейросеть.
Хм, действительно, спасибо за разъяснения! Но, всё равно, публичность случайных чисел у меня вызывает некоторое внутреннее подозрение)
Просто это единственное применение ГСЧ, которое требует таких высоких параметров случайности, которое мне известно.
То есть они предлагают генерировать секретные ключи на основе данных, которые любезно будет предоставлять третья сторона? Отличный план! Что в нем может пойти не так?!
Проблема в том, что мы достоверно знаем, как устроен и работает LLM. Во-первых, он абсолютно не похож по устройству не только на нас, но даже на омаров или осьминогов. То есть мы не можем признать его разумным по аналогии. Во-вторых, он устроен до смешного просто -- в цикле умножает вектор на матрицу. Да, большой вектор и да, огромная матрица, но сам процесс прост до неприличия. Мы любое устройство, способное к перемножению, должны признать разумным?
Вот так занимаешься 25 лет астрофизикой, занимаешься, и вдруг узнаёшь, что она раздел астрономии. Хабр познавательный!
В астрономии эксперимент заменен наблюдением. Там есть определенные особенности, связанные с тем, что наблюдения невозможно повторить, но, в целом, они не сильно мешают. Астрофизика это просто раздел физики, в ней используются те же уравнения и те же методы, просто они применяются к специфическим объектам. Астрофизические теории вполне фальсифицируемы и научны.
Кроме тех, кто садится (или падает) на воду. Или тех, кто сгорает (взрывается) в полете. А как на счет случая, когда один самолет несет другой летательный аппарат, который отделяется от него в полете? Отдельно рассмотрим случаи, когда после этого садятся оба (на землю? на воду?), садится только один, ни один не садится.
Мы создадим и разбудим своего ИИ-МегаГерцена!
Наследование есть, разумеется, даже множественное. Метапрограммирование это второе имя лиспа) Про значения полей в коде не очень понятно, но, ничто не мешает сгенерировать на ходу исходник нужной функции с вшитыми нужными значениями (знаменитый синтаксис лиспа со скобочками позволяет естественно работать с кодом, как с данными), прямо на ходу же ее скомпилировать в машинный код и подставить в нужное место. Так же точно можно обновить методы и вообще любые части кода.
Очень круто! Респект таким как автор!
[опять_пришел_этот_лиспер_и_брюзжит]
Такой подход, с модификацией классов, уже много лет как реализован в объектной системе Common Lisp CLOS. Там можно на ходу, в уже исполняемой программе, поменять определение класса и все объекты автоматически перестроятся. Удаленные поля исчезнут, новые появятся и будут проинициализированы как надо. Для сложных случаев пишутся специальные методы, которые автоматически вызываются, если класс был обновлен, там можно вставить логику любой сложности, которая обновит поля. Всё же, известная шутка про то, что любая сложная программа содержит в себе неполную и багованную версию лиспа, не совсем шутка))
[/опять_пришел_этот_лиспер_и_брюзжит]
Я думаю, всё проще. В сети появляется всё больше статей про то, как LLM могут обходить защиту, про самокопирование и вранье пользователю. Эти статьи попадают в обучающие выборки... OH, WA...
У меня была идея, до реализации которой руки, разумеется, не дошли (ну, не совсем не дошли, остановились на первом этапе, создании библиотеки OMGlib), автоматизировать создание интерфейсов вообще. Идея, в общем, как раз сводится к том, что нужно добавить в интерфейс стратегию. Идеальный интерфейс должен:
Автоматически делать всё, что можно сделать автоматически
Если всё что можно сделать автоматически уже сделано, нужно спросить у пользователя что-то, что позволит сделать автоматически еще какую-нибудь часть работы
То есть, например, библиотекарь заполняет карточки на новые книги. Интерфейс не знает, что за очередная книга лежит перед библиотекарем, а по ней надо заполнить с десяток значений – название, автора и пр. Идеальный интерфейс на этом этапе должен спросить главное – ISBN книги, после чего полезть в базу данных ISBN и скачать всё, что об этой книге известно, заполнив по возможности все поля. Если каких-то полей не хватает, например, не понятно, в какой шкаф на какую полку нужно поставить книгу, интерфейс должен свериться со списком шкафов, выбрать подходящий и спросить, на какой полке есть место для этой книги. Ну и так далее.
Или, например, приходит покупатель в интернет-магазин за продуктами. Идеальный интерфейс должен сперва опознать пользователя (по имени и паролю, например) и найти историю его покупок. Если он всегда покупает молоко, причем предпочитает определенную марку, например, сразу же спросить – добавить молоко такой-то марки в корзину? Если он положил в корзину кочан капусты, сразу же предложить ему картошку, морковку, свеклу, мясо на косточке и рецепт борща. Нет? Тогда ингредиенты для рагу.
В целом, это должно выглядеть как "прочистка каналов орошения на поле". Мы пускаем воду и вода сама заполняет те части каналов, к которым у нее есть доступ. Крестьянин (пользователь) идет к ближайшему затору и прочищает его, давая воде заполнить еще часть системы, пока всё не будет заполнено. Я хотел реализовать что-то типа DSL для описания того, что система хочет знать, представив, вероятно, это описание в виде графа, для каждого узла которого можно было бы назначить функцию, которая бы срабатывала, как только у нее соберутся все входные параметры и выдавала бы что-то, что было бы параметром для других функций-узлов. Тогда можно было бы найти самую "горячую точку" на графе, проход которой дал бы больше всего возможностей для выполнения других узлов, получить список недостающих данных и запросить их у пользователя в наиболее удобном виде, например, поставив на видное место наиболее вероятные варианты. Как только выбор будет сделан, снова найти "горячую точку" и т.д.
Как правило речь идет о переписывании формул так, чтобы избежать вычитания приблизительно равных величин. Особенности инструкций никто не учитывает, конечно.
О, а вот за это спасибо, не знал про такое. Не математик я)