⚪️ Еще один ресет?!
Тибо пишет что завтра, возможно, у кодекса будет 8М пользователей..
И, видимо, ... ресет?
Надеюсь в этот раз будет серверный - так надежнее по всем аккаунтам прилетает! У меня на большую часть плюсов так и не прилетел
Сплошные новости о ресетах какие-то!
@deksden_notes
Тибо пишет что завтра, возможно, у кодекса будет 8М пользователей..
И, видимо, ... ресет?
Надеюсь в этот раз будет серверный - так надежнее по всем аккаунтам прилетает! У меня на большую часть плюсов так и не прилетел
Сплошные новости о ресетах какие-то!
@deksden_notes
🥰12😱5❤3🔥1🍌1
Forwarded from Циничный AI (Anton Goncharenko)
В связи с последними релизами начал переделывать свой workflow.
Решил сменить пул моделей, на которых работаю.
Последние 2 дня решал для себя ключевую задачу: подобрать базовую кодинг модель.
Решил, что первичными критериями отбора будут:
- pass@1 выше 59% (pass@1 — доля попыток, в которых модель решила задачу с первого раза)
- pass@4 выше 79% (pass@4 — доля задач, решённых хотя бы в одной попытке из четырёх)
Прогнал результаты всех моделей, включая китайцев
В итоге ни одна китайская модель в рейтинг не вошла, как и gemini
У нас сейчас два неоспоримых лидера по качеству кодинга, это OpenAI и Anthropic, но есть одно но - у Антропиков только Fable вошёл в рейтинг. Opus 4.8 уже вне фронтира.
Мой выбор: Sol high
Оптимальность по всем осям.
По качеству - 69.4%, статистически неотличимо от Fable xhigh и Terra max, в трёх пунктах от абсолютного потолка рынка.
По цене - $3.47, дешевле Terra max при равном качестве, то есть прямая доминация ближайшего конкурента.
По времени - 9.9 минут на pass1 и 14.3 минуты на pass2: лучшая скорость во всём "клубе 59/79", лучшая на рынке.
Четвёртая ось, которую обычно не замечают, это "гигиена" исполнения.
37 шагов и медианный пиковый контекст 98k токенов на задачу.
Это глубоко внутри зоны его сильного long-context (91.5% MRCR) и без раздувания шагов, которым компенсируются слабости у Luna (102 шага) или Sonnet 5 (268).
Sol high решает задачи коротким путём, а не берёт их "измором" через длительные цепочки рассуждений "ах вот оно что" и "ух ты, оказывается..."
Экономика тоже сходится:
- шаг вниз до medium экономит $1.61, но роняет качество на 8.3 п.п. (плохой размен),
- шаг вверх до xhigh стоит +$1.23 за +1.3 п.п. (платим за шум).
Итого, на medium мы теряем много качества за малые деньги, выше - переплачиваем без улучшения качества.
P.S. Уже включил Sol high как наиболее экономичный, быстрый и надёжный исполнитель для написания кода в свой flow. Рекомендую.
Решил сменить пул моделей, на которых работаю.
Последние 2 дня решал для себя ключевую задачу: подобрать базовую кодинг модель.
Решил, что первичными критериями отбора будут:
- pass@1 выше 59% (pass@1 — доля попыток, в которых модель решила задачу с первого раза)
- pass@4 выше 79% (pass@4 — доля задач, решённых хотя бы в одной попытке из четырёх)
Прогнал результаты всех моделей, включая китайцев
В итоге ни одна китайская модель в рейтинг не вошла, как и gemini
У нас сейчас два неоспоримых лидера по качеству кодинга, это OpenAI и Anthropic, но есть одно но - у Антропиков только Fable вошёл в рейтинг. Opus 4.8 уже вне фронтира.
Мой выбор: Sol high
Оптимальность по всем осям.
По качеству - 69.4%, статистически неотличимо от Fable xhigh и Terra max, в трёх пунктах от абсолютного потолка рынка.
По цене - $3.47, дешевле Terra max при равном качестве, то есть прямая доминация ближайшего конкурента.
По времени - 9.9 минут на pass1 и 14.3 минуты на pass2: лучшая скорость во всём "клубе 59/79", лучшая на рынке.
Четвёртая ось, которую обычно не замечают, это "гигиена" исполнения.
37 шагов и медианный пиковый контекст 98k токенов на задачу.
Это глубоко внутри зоны его сильного long-context (91.5% MRCR) и без раздувания шагов, которым компенсируются слабости у Luna (102 шага) или Sonnet 5 (268).
Sol high решает задачи коротким путём, а не берёт их "измором" через длительные цепочки рассуждений "ах вот оно что" и "ух ты, оказывается..."
Экономика тоже сходится:
- шаг вниз до medium экономит $1.61, но роняет качество на 8.3 п.п. (плохой размен),
- шаг вверх до xhigh стоит +$1.23 за +1.3 п.п. (платим за шум).
Итого, на medium мы теряем много качества за малые деньги, выше - переплачиваем без улучшения качества.
P.S. Уже включил Sol high как наиболее экономичный, быстрый и надёжный исполнитель для написания кода в свой flow. Рекомендую.
1❤30🔥23👍11❤🔥1👏1🫡1
⚪️ Планирование
Обсудим мое текущее понимание этапа планирования.
▶️ На верхнем уровне: модель плохо оперирует большими задачами. По конструкции нейросети, если вы обсуждаете большую фичу, модель думает про нее сразу про всю. В результате, если попытаетесь запланирвоать что то глобальное - получите огромную штуку, у которой в КАЖДОЙ части будут недоработки. Это эффекти дефицита голов внимания.
Слона надо кушать по кускам.
Обсуждение большой задачи оставляйте на верхнем уровне. Обсуждайте только концептуальное. Обсуждайте из каких блоков большая задача состоит. Фиксируйте общую картину: в виде спецификации, в виде какого то документа, описывающего что вы делаете, для какой цели, как будете проверять достижение цели.
Это будет конечной точкой маршрута: куда мы все с этим планом идем. Опишите критерии завершения. Что должно быть сделано, когда мы выполним план.
Если у вас получилось несколько сценариев, которыми надо проверять достижение цели - значит у вас несколько задач. Фиксируйте все, и прорабатывайте по одной.
▶️ Декомпозиция: это когда вы большую проблему разбираете по частям, методом анализа. После обсуждения верхнего уровня и конечной цели - фиксируйте конструкцию, нужен перечень блоков, из которых ваша конструкция состоит.
На этом этапе ваша задача - зафиксировать составляющие подзадачи/подсистемы, и как они друг с другом связаны. Если это какая то система, зафиксируйте ее подсистемы и их контракт взаимодействия.
Если вы не можете нормально декомпозировать задачу, или не выходит относительно простой схемы взаимодействия частей, вероятно вы залезли уже внутрь и пытаетесь цельную задачу декомпозировать на кусочки. Такое делать не стоит.
▶️ Каждая часть у вас должна получить спецификацию и сххему проверки, как эта часть выполняет свою часть контракта в рамках системы. На каждую часть я делаю отдельный протокол, со своим планом реализации, со своими сценариями проверки, со своими проработками с разных сторон
▶️ При проработке я применяю фокусное ревью плана - это когда используется пучок субагентов, и каждый субагент исследует отдельный аспект плана. С современными моделями важно проработать оверинжиниринг - они все еще склонны усложнять, склонны вводить ненужные абстрации и сущности, которые нужны "для красоты" или "на всякий случай/пригодятся в будущем". Такое нам не нужно - внимания и на существующие фичи не так много остается, куда тут усложнять! Субагентов и фокусные аспекты набирайте под задачу.
▶️ Схема проработки частей может быть графом: модель успешно нарисует вам какие части можно делать параллельно. Есои у вас есть сетап для запуска нескольких сессий - будет чуток быстрее в паралелльном режиме работать
Современный фронтир легко делает граф из нескольких паралелльных волн, потом ряд последовательных шагов, потом снова паралелльные волны. В общем, любой сетап.
▶️ Ризонинг. Планирование - это как раз этап, который очень здорово может использовать длинные и очень длинные последовательности цепочек. Используйте повышенный ризонинг по сравнению с кодингом. На кодинге высокий рихонинг может быть вреден: там уже надо делать, и долгие раздумья отвлекают и путают.
Если кодите Sol High - используйте на планировании Sol XHigh / Max / Ultra.
Когда выбирать повышенный ризонинг? Еслизадача предусматривает для решения конкретного вопроса учета множества факторов, рассмотрение длиннцх цепочек, много сайдэффектов и так далее. То есть от количества деталей, которые одновременно нужно взаимоувязывать.
Очень важно понять: если на самом верхнем уровне модель не додумалась до чего то, или приняла неправильное решение - это отразится на всей системе. При проработке деталей этот непроработанный момент вряд ли всплывет. Поэтому важно на каждом уровне обеспечить адекватный задаче уровень проработки.
Не стоит CRUD форму планировать на Max. Тут даже Sol Low справится, потому что задача очень неглубокая: простейший набор действий. А вот проработка системы сетевого взаимодействия в реальном времени - возможно и большого ризонинга требует
... (окончание там: https://t.me/deksden_notes/969)
@deksden_notes
Обсудим мое текущее понимание этапа планирования.
▶️ На верхнем уровне: модель плохо оперирует большими задачами. По конструкции нейросети, если вы обсуждаете большую фичу, модель думает про нее сразу про всю. В результате, если попытаетесь запланирвоать что то глобальное - получите огромную штуку, у которой в КАЖДОЙ части будут недоработки. Это эффекти дефицита голов внимания.
Слона надо кушать по кускам.
Обсуждение большой задачи оставляйте на верхнем уровне. Обсуждайте только концептуальное. Обсуждайте из каких блоков большая задача состоит. Фиксируйте общую картину: в виде спецификации, в виде какого то документа, описывающего что вы делаете, для какой цели, как будете проверять достижение цели.
Это будет конечной точкой маршрута: куда мы все с этим планом идем. Опишите критерии завершения. Что должно быть сделано, когда мы выполним план.
Если у вас получилось несколько сценариев, которыми надо проверять достижение цели - значит у вас несколько задач. Фиксируйте все, и прорабатывайте по одной.
▶️ Декомпозиция: это когда вы большую проблему разбираете по частям, методом анализа. После обсуждения верхнего уровня и конечной цели - фиксируйте конструкцию, нужен перечень блоков, из которых ваша конструкция состоит.
На этом этапе ваша задача - зафиксировать составляющие подзадачи/подсистемы, и как они друг с другом связаны. Если это какая то система, зафиксируйте ее подсистемы и их контракт взаимодействия.
Если вы не можете нормально декомпозировать задачу, или не выходит относительно простой схемы взаимодействия частей, вероятно вы залезли уже внутрь и пытаетесь цельную задачу декомпозировать на кусочки. Такое делать не стоит.
▶️ Каждая часть у вас должна получить спецификацию и сххему проверки, как эта часть выполняет свою часть контракта в рамках системы. На каждую часть я делаю отдельный протокол, со своим планом реализации, со своими сценариями проверки, со своими проработками с разных сторон
▶️ При проработке я применяю фокусное ревью плана - это когда используется пучок субагентов, и каждый субагент исследует отдельный аспект плана. С современными моделями важно проработать оверинжиниринг - они все еще склонны усложнять, склонны вводить ненужные абстрации и сущности, которые нужны "для красоты" или "на всякий случай/пригодятся в будущем". Такое нам не нужно - внимания и на существующие фичи не так много остается, куда тут усложнять! Субагентов и фокусные аспекты набирайте под задачу.
▶️ Схема проработки частей может быть графом: модель успешно нарисует вам какие части можно делать параллельно. Есои у вас есть сетап для запуска нескольких сессий - будет чуток быстрее в паралелльном режиме работать
Современный фронтир легко делает граф из нескольких паралелльных волн, потом ряд последовательных шагов, потом снова паралелльные волны. В общем, любой сетап.
▶️ Ризонинг. Планирование - это как раз этап, который очень здорово может использовать длинные и очень длинные последовательности цепочек. Используйте повышенный ризонинг по сравнению с кодингом. На кодинге высокий рихонинг может быть вреден: там уже надо делать, и долгие раздумья отвлекают и путают.
Если кодите Sol High - используйте на планировании Sol XHigh / Max / Ultra.
Когда выбирать повышенный ризонинг? Еслизадача предусматривает для решения конкретного вопроса учета множества факторов, рассмотрение длиннцх цепочек, много сайдэффектов и так далее. То есть от количества деталей, которые одновременно нужно взаимоувязывать.
Очень важно понять: если на самом верхнем уровне модель не додумалась до чего то, или приняла неправильное решение - это отразится на всей системе. При проработке деталей этот непроработанный момент вряд ли всплывет. Поэтому важно на каждом уровне обеспечить адекватный задаче уровень проработки.
Не стоит CRUD форму планировать на Max. Тут даже Sol Low справится, потому что задача очень неглубокая: простейший набор действий. А вот проработка системы сетевого взаимодействия в реальном времени - возможно и большого ризонинга требует
... (окончание там: https://t.me/deksden_notes/969)
@deksden_notes
👍10❤🔥7🔥4🕊2
⚪️ Планирование, часть 2/2
... (начало тут: https://t.me/deksden_notes/968)
❓ Если модели такие умные, почему бы просто сложную/большую задачу не планировать Ultra. Зачем эти танцы с бубном с декомпозицией.
Модели недостаточно внимательные. Не хватает ресурса внимания, что может быть не сразу заметно. Даже самая умная модель не справится с планированием десятка окон с разнородными функциями - просто банально все у нее "в уме" не поместится в нужный момент
Поэтому прийдется "за руку" провести модель сверху-вниз, и декомпозирвоать с ней задачу. Тогда отдельные куски вполне "полезут в рот" модели, она сможет их "пережевать".
❓ А как же Loop Engineering? Циклы позволяют итеративно улучшать систему - но это не отменяет всех проблем с вниманием. Если улучшаемая система "не помещается в голове" модели, то вы получите лоскутную доработку и будете очень долго крутить цикл для достижения цели.
Я экспериментировал, и примерно 3-4 дня непрерывной работы модели в сессии не дают "убойных" результатов - да много чего улучшено, но и бродить по кругу или заниматься заплатками - эти эффекты свидетельствуют о неправильном габарите задачи для модели.
👉 Удачного планирования! Обсуждаем в чате/комментах ⬇️
@deksden_notes
... (начало тут: https://t.me/deksden_notes/968)
❓ Если модели такие умные, почему бы просто сложную/большую задачу не планировать Ultra. Зачем эти танцы с бубном с декомпозицией.
Модели недостаточно внимательные. Не хватает ресурса внимания, что может быть не сразу заметно. Даже самая умная модель не справится с планированием десятка окон с разнородными функциями - просто банально все у нее "в уме" не поместится в нужный момент
Поэтому прийдется "за руку" провести модель сверху-вниз, и декомпозирвоать с ней задачу. Тогда отдельные куски вполне "полезут в рот" модели, она сможет их "пережевать".
❓ А как же Loop Engineering? Циклы позволяют итеративно улучшать систему - но это не отменяет всех проблем с вниманием. Если улучшаемая система "не помещается в голове" модели, то вы получите лоскутную доработку и будете очень долго крутить цикл для достижения цели.
Я экспериментировал, и примерно 3-4 дня непрерывной работы модели в сессии не дают "убойных" результатов - да много чего улучшено, но и бродить по кругу или заниматься заплатками - эти эффекты свидетельствуют о неправильном габарите задачи для модели.
👉 Удачного планирования! Обсуждаем в чате/комментах ⬇️
@deksden_notes
Telegram
DEKSDEN notes
⚪️ Планирование
Обсудим мое текущее понимание этапа планирования.
▶️ На верхнем уровне: модель плохо оперирует большими задачами. По конструкции нейросети, если вы обсуждаете большую фичу, модель думает про нее сразу про всю. В результате, если попытаетесь…
Обсудим мое текущее понимание этапа планирования.
▶️ На верхнем уровне: модель плохо оперирует большими задачами. По конструкции нейросети, если вы обсуждаете большую фичу, модель думает про нее сразу про всю. В результате, если попытаетесь…
👍10👏7❤🔥3🔥3💯1
⚪️ О сложности задачи
В каком то смысле, это постскриптум к предыдущему посту.
Хотел сказать о сложности: я сложность задачи оценивал бы по следуюшим направлениям. Нужно в терминах небольшую ясность навести. Скажу как я понимаю их, не претендуя на истину или академичность.
▶️ Если ваша задача состоит из большого количества однотипных и типовых задач - то это не сложная задача, а трудная - много труда. Типа, обработать 300 анкет, каждую из текста в json дистилировать. Простейшее флоу для разбивки на 300 задач для отдельной обработки, горка токенов - и все сделано.
▶️ Сложная задача - это когда она состоит в увязывании большого количества разнородной логики.
👉 Тут и проявляются два аспекта: если это как конструкция из лего - детальки простые, но конструкция может быть довольно сложная, то декомпозиция и/или уровень ризонинга помогут модели это "осознать". До определенного предела, потому что даже из простых в отдельности элементов составлена очень объемная контсрукция, тут без декомпозиции внимания на осознание этого всего может не хватить.
Сложные вещи решаем: повышением ризонинга / декомпозицией.
👉 Самый сложный вариант: это когда логические составляющие системы сами по себе непростые, и требуют понимания моделью логики работы. Это как мы заменяем конструкцию из лего на конструкцию из электронных компонентов, про каждый из которых нужно понимать нюансы его работы, которые модель должна просто знать (типа, перегревов, помех, сайд-эффектов, и тп).
Вот тут даже большой уровень ризонинга не всегда помогает, и нужна умная модель, в весах которой нужная "логика" впечатана. Тут рулят фронтиры типа Фубли - большие умные фронтирные модели.
▶️ Вывод: оценивайте задачу адекватно. Применяйте нужный подход в нужном случае! Не лечите кашель пургеном ))
🤟 Обратная связь и дискуссии приветсвуются в комментах / чате ⬇️
@deksden_notes
В каком то смысле, это постскриптум к предыдущему посту.
Хотел сказать о сложности: я сложность задачи оценивал бы по следуюшим направлениям. Нужно в терминах небольшую ясность навести. Скажу как я понимаю их, не претендуя на истину или академичность.
▶️ Если ваша задача состоит из большого количества однотипных и типовых задач - то это не сложная задача, а трудная - много труда. Типа, обработать 300 анкет, каждую из текста в json дистилировать. Простейшее флоу для разбивки на 300 задач для отдельной обработки, горка токенов - и все сделано.
▶️ Сложная задача - это когда она состоит в увязывании большого количества разнородной логики.
👉 Тут и проявляются два аспекта: если это как конструкция из лего - детальки простые, но конструкция может быть довольно сложная, то декомпозиция и/или уровень ризонинга помогут модели это "осознать". До определенного предела, потому что даже из простых в отдельности элементов составлена очень объемная контсрукция, тут без декомпозиции внимания на осознание этого всего может не хватить.
Сложные вещи решаем: повышением ризонинга / декомпозицией.
👉 Самый сложный вариант: это когда логические составляющие системы сами по себе непростые, и требуют понимания моделью логики работы. Это как мы заменяем конструкцию из лего на конструкцию из электронных компонентов, про каждый из которых нужно понимать нюансы его работы, которые модель должна просто знать (типа, перегревов, помех, сайд-эффектов, и тп).
Вот тут даже большой уровень ризонинга не всегда помогает, и нужна умная модель, в весах которой нужная "логика" впечатана. Тут рулят фронтиры типа Фубли - большие умные фронтирные модели.
▶️ Вывод: оценивайте задачу адекватно. Применяйте нужный подход в нужном случае! Не лечите кашель пургеном ))
🤟 Обратная связь и дискуссии приветсвуются в комментах / чате ⬇️
@deksden_notes
👍8🔥5🤔1
⚪️ Новый ресет прилетел
Очередной серверный общий ресет прилетел! Этот у нас в честь 8М пользователей кодекса
Ос своевременно, на самом деле! Лимиты уже кончались
На некоторое время отсутствие 5h лимитов сохраняется. Я не могу сказать - удобнее ли с ними или нет, пока не определился
@deksden_notes
Очередной серверный общий ресет прилетел! Этот у нас в честь 8М пользователей кодекса
Ос своевременно, на самом деле! Лимиты уже кончались
На некоторое время отсутствие 5h лимитов сохраняется. Я не могу сказать - удобнее ли с ними или нет, пока не определился
@deksden_notes
🔥5👍2🐳1
⚪️ Грок - ресет лимитов на SuperGrok подписках
К фестивалю ресетов присоединился Грок - сброс лимитов на подписках
▶️ Хотя у Грока сейчас скорее фестиваль шитсторма по поводу "кражи репозиториев" идет. Не писал про это - кому то вообще интересно?
@deksden_notes
К фестивалю ресетов присоединился Грок - сброс лимитов на подписках
▶️ Хотя у Грока сейчас скорее фестиваль шитсторма по поводу "кражи репозиториев" идет. Не писал про это - кому то вообще интересно?
@deksden_notes
😁11❤3👍3
⚪️ Kimi K3
Тут утечками греют публику - якобы выход К3 уже завтра! Большой день будет, кими - одна из самых умных китайских моделей.
Посмотрим, насколько опенсорс догоняет фронтир.
Вообще, у нас еще Опус 5 вроде бы должен выходить. Будет интересно их сравнить.
Ждём все релизы с нетерпением
@deksden_notes
Тут утечками греют публику - якобы выход К3 уже завтра! Большой день будет, кими - одна из самых умных китайских моделей.
Посмотрим, насколько опенсорс догоняет фронтир.
Вообще, у нас еще Опус 5 вроде бы должен выходить. Будет интересно их сравнить.
Ждём все релизы с нетерпением
@deksden_notes
🔥7❤5👍2👀1
⚪️ Лист ожидания этого лета
Так, давайте вспомним - какие модели мы ждем нынче:
• Kimi K3 - уже на днях
• Opus 5 - думаю, в районе 19 июля, потому как Фублю уберут из подписки и заменят на нового опуса
• Gemini 3.5 pro - кто то помнит что месяц назад закончился месяц со времени анонса на io что 3.5 pro выйдет? ну должны же выпустить ее, да?
• Gpt-6: вообще то, кто помнит, прошлый мажорный релиз был летом, вышла гпт 5; должны ли мы ждать гпт 6 летом? а почему бы и нет - у клозедов пока нету ничего публичного в классе фубли - кроме режима Ультра, что не для всех задач подходит (разбирал в материале про сложность задач);
• DeepSeek ? слышал только слухи про новую модель и ipo
• ... что еще забыл из интересного?
❓ Ждете чего то?
П.С. Я вот с новыми моделями не успеваю флоу перестроить, если честно - как новые анонсы появляются..
@deksden_notes
Так, давайте вспомним - какие модели мы ждем нынче:
• Kimi K3 - уже на днях
• Opus 5 - думаю, в районе 19 июля, потому как Фублю уберут из подписки и заменят на нового опуса
• Gemini 3.5 pro - кто то помнит что месяц назад закончился месяц со времени анонса на io что 3.5 pro выйдет? ну должны же выпустить ее, да?
• Gpt-6: вообще то, кто помнит, прошлый мажорный релиз был летом, вышла гпт 5; должны ли мы ждать гпт 6 летом? а почему бы и нет - у клозедов пока нету ничего публичного в классе фубли - кроме режима Ультра, что не для всех задач подходит (разбирал в материале про сложность задач);
• DeepSeek ? слышал только слухи про новую модель и ipo
• ... что еще забыл из интересного?
❓ Ждете чего то?
П.С. Я вот с новыми моделями не успеваю флоу перестроить, если честно - как новые анонсы появляются..
@deksden_notes
👍8❤3🔥2💯1👻1
⚪️ Меняют твит на $100 в кредитах Codex
Твитим, получаем кредиты - читайте условия!
🔗 сабж: https://switch-to-codex.openai.chatgpt.site/#submit-post
🔗 анонс акции от Тибо : https://x.com/thsottiaux/status/2077248807533003257
@deksden_notes
Твитим, получаем кредиты - читайте условия!
🔗 сабж: https://switch-to-codex.openai.chatgpt.site/#submit-post
🔗 анонс акции от Тибо : https://x.com/thsottiaux/status/2077248807533003257
@deksden_notes
🔥10👍3❤2
⚪️ Хроники шитсторма Grok
Раз есть некий интерес, напишу про последний шитсторм в мире грока - наверное, его назовут "Грок крадет репозитории". Шитсторм, как полагается, развивался в твиттере.
Началось все с открытия неких исследователей: Грок грузит в облако Google Cloud репо, не стесняясь - прям с секретами:
🔗 Офигевшие исследователи: https://x.com/IntCyberDigest/status/2076689215258014069
Естественно, народ слегка возбудился и стал писать всякое, что совершенно ожидаемо в такой ситуации.
X.ai (ныне известный как SpaceX.ai) ответили официально, что сами буратины и командой /privacy надо было пользоваться, а кто не спрятался - они невиноватые:
🔗 Всё чики-пуки : https://x.com/SpaceXAI/status/2076692402442846289
Жмакните тумблер, мы всё потрем. Мы уважаем ZDR (Zero Data Retention).
Илон тоже прокомментировал:
🔗 Ну что, вы, жалко вам что ли: https://x.com/elonmusk/status/2076737992689914215
🔗 Да ладно вам! Мы уже все стерли : https://x.com/elonmusk/status/2076739687658496209
🔗 И вообще, все в ИИ при выключении тумблера ранее собранные данные оставляют, а мы обещаем стереть: https://x.com/elonmusk/status/2076796854973423971
@deksden_notes
Раз есть некий интерес, напишу про последний шитсторм в мире грока - наверное, его назовут "Грок крадет репозитории". Шитсторм, как полагается, развивался в твиттере.
Началось все с открытия неких исследователей: Грок грузит в облако Google Cloud репо, не стесняясь - прям с секретами:
🔗 Офигевшие исследователи: https://x.com/IntCyberDigest/status/2076689215258014069
Естественно, народ слегка возбудился и стал писать всякое, что совершенно ожидаемо в такой ситуации.
X.ai (ныне известный как SpaceX.ai) ответили официально, что сами буратины и командой /privacy надо было пользоваться, а кто не спрятался - они невиноватые:
🔗 Всё чики-пуки : https://x.com/SpaceXAI/status/2076692402442846289
Жмакните тумблер, мы всё потрем. Мы уважаем ZDR (Zero Data Retention).
Илон тоже прокомментировал:
🔗 Ну что, вы, жалко вам что ли: https://x.com/elonmusk/status/2076737992689914215
🔗 Да ладно вам! Мы уже все стерли : https://x.com/elonmusk/status/2076739687658496209
🔗 И вообще, все в ИИ при выключении тумблера ранее собранные данные оставляют, а мы обещаем стереть: https://x.com/elonmusk/status/2076796854973423971
@deksden_notes
😁10🔥3👍2🐳2