но по прежнему совершают многочисленные фактические и логические ошибки, которые не допустил бы даже человек с интеллектом ниже среднего
А может и допустил бы. Либо сделал бы другие. Утверждение, что текущие топовые модели (например Claude 3 Opus) глупее среднего человека — весьма спорное.
Ну-ка, расскажите, как вы выведете латентность из пропусконой способности, если вам нужно прочитать один единственный блок (в котором лежит индекс БД, например)?
Группе дронов достаточно лететь быстрее, чем их сбивают. На многих подобных видео на "сбитие" уходит 10-30 секунд. На самом деле это довольно много.
соответственно перезаряжаться после выстрела ей не надо
Скорее всего надо. С большой вероятностью будет требоваться время на накопление заряда и на охлаждение. Сильно зависит от того, как решена проблема с питанием.
Более того, ещё до того как про этот Grok появилась публичная информация — Маск призывал OpenAI, Google и других заморозить разработку, чтобы, дескать, сперва выработать общие правила и ограничения на ИИ.
Более того — проблема решается банальнейшим образом через p2p (торренты, IPFS etc). Да и в общем-то куча файлообменников уже давно позволяет раздавать файлы по несколько гигов размером.
Тут ещё стоит добавить, что сами вектора могут позволять делать операции над ними. Соответственно вы можете сделать какие-то преобразования над "смыслами" и потом в базе искать что-то близкое к цели.
Условный пример (работает для некоторых видов эмбеддингов): если из вектора для слова "король" вычесть вектор для слова "мужчина" и прибавить вектор для слова "женщина", то вы получите вектор, близкий к вектору для слова "королева".
Я бы ещё добавил, что легко может оказаться так, что системы на базе LLM (ChatGPT и прочие) заберут ту нишу, которую сейчас занимают условные джуны и слабые миддлы. И даже те, кто недавно успешно прошёл курсы и трудоустроился - через год-два-три останутся без работы.
Только вот процесс не симметричный. Время-то бесполезно потеряно. Нужно, чтобы был какой-то симметричный набор тестов для работодателя, чтобы он показал, что он не "чудак", как в примере выше.
если у меня нет веба, нет томката — то нет и никакой проблемы вообще, потому что никакое выражение на SpEL никто снаружи засунуть в код не сможет?
Если вы совсем-совсем никаких данных никаким образом "снаружи" не получаете, то ваше приложение, действительно, не уязвимо к этой атаке (и к 99% любых атак в принципе).
На практике вы так или иначе получаете в приложение данные внешних источников. Если в процесс парсинга данных и биндинга их на POJO/DTO будет вовлечён Spring - вы всё ещё можете быть под угрозой. Сказать наверняка - трудно, так как подробностей всё ещё опубликовано мало.
Вот тут есть некоторая информация помимо той, что опубликована в Spring Blog:
Во-первых, на момент начальной публикации подробностей было намного меньше. Я бы даже сказал, почти не было.
Во-вторых, сама концептуальная проблема находится в Spring Core. А вот конкретный практически осуществимый вариант её использования для RCE — требует деплой через WAR на Tomcat.
Доказательства? Аргументы? Пока нет никаких предпосылок к тому, чтобы утверждать, что LLM не подходят для получения AGI.
А может и допустил бы. Либо сделал бы другие. Утверждение, что текущие топовые модели (например Claude 3 Opus) глупее среднего человека — весьма спорное.
Ну-ка, расскажите, как вы выведете латентность из пропусконой способности, если вам нужно прочитать один единственный блок (в котором лежит индекс БД, например)?
Россия не участвовала в финансировании ЦЕРН. Всё, что РФия поставляла — было оплачено в рамках контрактов.
Список стран участников есть тут: https://ru.wikipedia.org/wiki/ЦЕРН
Автор статьи забыл упоянуть, что РФ в ЦЕРН имела статус наблюдателя и в этом статусе не участвовала в финансировании ЦЕРН.
Группе дронов достаточно лететь быстрее, чем их сбивают. На многих подобных видео на "сбитие" уходит 10-30 секунд. На самом деле это довольно много.
Скорее всего надо. С большой вероятностью будет требоваться время на накопление заряда и на охлаждение. Сильно зависит от того, как решена проблема с питанием.
Зачем платить за отдельный девайс прибитый к стене, который занимает место и явно быстро устареет, если можно предоставить приложение на телефон?
Более того, ещё до того как про этот Grok появилась публичная информация — Маск призывал OpenAI, Google и других заморозить разработку, чтобы, дескать, сперва выработать общие правила и ограничения на ИИ.
Более того — проблема решается банальнейшим образом через p2p (торренты, IPFS etc). Да и в общем-то куча файлообменников уже давно позволяет раздавать файлы по несколько гигов размером.
Тут ещё стоит добавить, что сами вектора могут позволять делать операции над ними. Соответственно вы можете сделать какие-то преобразования над "смыслами" и потом в базе искать что-то близкое к цели.
Условный пример (работает для некоторых видов эмбеддингов): если из вектора для слова "король" вычесть вектор для слова "мужчина" и прибавить вектор для слова "женщина", то вы получите вектор, близкий к вектору для слова "королева".
Зачем спекуляции и предположения в плане количества токенов, если можно запустить токенайзер от самого OpenAI?
https://github.com/openai/tiktoken
Из заголовка можно подумать, что производительность системы как-то однозначно и очевидно коррелирует с числом разработчиков (нет).
Я бы ещё добавил, что легко может оказаться так, что системы на базе LLM (ChatGPT и прочие) заберут ту нишу, которую сейчас занимают условные джуны и слабые миддлы. И даже те, кто недавно успешно прошёл курсы и трудоустроился - через год-два-три останутся без работы.
Только вот процесс не симметричный. Время-то бесполезно потеряно. Нужно, чтобы был какой-то симметричный набор тестов для работодателя, чтобы он показал, что он не "чудак", как в примере выше.
Пока что ChatGPT не очень трудно убедить, что "дважды два - пять".
А не важно, какие конкретно. Важно, что использовал (включил в модель).
Если вы совсем-совсем никаких данных никаким образом "снаружи" не получаете, то ваше приложение, действительно, не уязвимо к этой атаке (и к 99% любых атак в принципе).
На практике вы так или иначе получаете в приложение данные внешних источников. Если в процесс парсинга данных и биндинга их на POJO/DTO будет вовлечён Spring - вы всё ещё можете быть под угрозой. Сказать наверняка - трудно, так как подробностей всё ещё опубликовано мало.
Вот тут есть некоторая информация помимо той, что опубликована в Spring Blog:
https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
Во-первых, на момент начальной публикации подробностей было намного меньше. Я бы даже сказал, почти не было.
Во-вторых, сама концептуальная проблема находится в Spring Core. А вот конкретный практически осуществимый вариант её использования для RCE — требует деплой через WAR на Tomcat.
Актуальная информация из Spring Blog:
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
А разве уже где-то разработана технология выращивания нового органа с нуля в другом организме?