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