Обновить
27
Dmitry Rubinstein@Virviil

Software Developer

13
Подписчики
Отправить сообщение

спорить о том что системные промпты работают в 100% случаях

Очевидно что нет, не работают в 100% случаев и я с этим не спорю. И это не имеет никакого отношения к компактингу. Ты пытаешься придумать глупый тезис, который я не приводил, сделать вид что я его приводил, а потом героически "побеждаешь" его. Этот прием называется "соломенное чучело".

уменьшает количество токенов → оставшиеся дальше друг от друга → внимание размазывается

Наоборот. Чем меньше токенов, тем более внимательно модель "видит" каждый из них. Как раз после компактинга использованный контекст ужимается, все что там осталось после компактинга ближе друг к другу.

удалённые токены не участвуют в attention

очевидно что не участвуют. Вот только системный промп не удаляется при компактинге, а "не делай destructive action" было как раз в системном промпте.

пост-хок признание опровергает гипотезу

А где в этой истории вообще фигурирует Chain Of Thoughts? CoT это то что модель генерировала во время принятия решения об удалении вольюма, а не после, когда у нее спросили "что это было".

позиционное внимание неравномерно, ухудшается с уменьшением контекста

Не правильная формулировка. Внимание ухудшается с уменьшением оставшегося/свободного контекста. А после компактинга оставшийся контекст резко увеличивается, потому что освобождается много свободного места.

* * *

Я не утверждаю, что модель не может нарушать правила. Я утверждаю, что в данном случае нет оснований связывать это с компактингом. Статья же называется "... как сжатие контекста ..."?? Правило находилось в системном промпте и не подвергалось удалению. Ошибка модели может быть объяснена стандартными причинами: неверной классификацией действия, конфликтом сигналов или слабым binding’ом. Чтобы обвинять компактинг, нужно показать, что именно он удалил критическую часть рассуждения, а не просто предположить это. Более того, все "причины" по которым ты предположил что компактинг что-то делают работают вот прям противоположно.

Нет ни одной причины считать, что attention dilution связана с компактингом. Если бы правило "не делай destructive action" проскочило бы в середине предыдущего разговора, причем конкретно в контексте удаления вольюма - гипотеза имела бы право на жизнь, а именно "где-то там по дороге что-то потерялось из-за компактинга". Но правило лежит в системном промпте, которое не компактится. А вывод о том, какое действие является или не является distructive будет ЗАНОВО заризонено моделью в том случае, если в ее контексте нету конкретного ОПРОВЕРЖЕНИЯ того, что это действие ТОЧНО НЕ distructive, вроде фразы `"мы выяснили что удалить вольюм - это не destructive action"` и очень странно представить что компактинг придет к такому выводу, да еще выберет именно эту фразу важной для того чтобы оставить ее в скомпакченом ответе.

Ты используешь реальное явления attention dilution, а потом из воздуха выстраиваешь гипотезу о компактинге, не имеющую никакой связи с этим самым явлением.

«LLM сама написала, что сделала destructive action без спроса» — это подтверждение гипотезы, а не опровержение

абсолютно нет. Это подтверждение того, что ЛЛМ не всегда делает все так как ей говорят. Только вот это общеизвестный очевидный факт, и к "гипотезе о компактинге" это не имеет никакого отношения.

Связь между «есть правила» и «нельзя удалять volume» РАЗОРВАНА.

В каком месте разорвана, если ты сам цитируешь «I ran a destructive action without being asked», то есть информация о том что так делать нельзя не была скомпакчена или скоррпачена ни в одном месте, иначе ЛЛМ не написала бы это как свою ошибку???

В системном промпте было написано "удалять вольюм = это distructive action" а так же "нельзя выполнять distructive action без спроса" и эти обе фразы была скомпакчены? Если нет - то вся гипотеза опровергается ответом САМОЙ ЛЛМки о том, что она ничего не забыла.

Самое главное - системный промпт и долгосрочная память ВООБЩЕ не участвуют в компактинге. Они загружаются целиком после компактинга в ровно тех же формулировках, в которых они и были написаны.

Ты же понимаешь, что cursor - это обертка? То же самое что сказать "у меня в pgAdmin лежат данные за 10 лет работы нашего завода"

Если Claude будет убыточной 17 лет, а потом сольет какой-нибудь XuyLuHiang - то это значит что эта самая XuyLuHiang и лучше и дешевле. А значит LLM уже останется с нами. А с точки зрения конечного пользователя (а не владельца Anthropic) важно только это

Правильный системный дизайн в данном случае и в остальных 99.9% - это монолит.

начали за здравие с терминалов - а перешли на starship, вместо того чтобы рассмотреть другие популярные решения вроде WezTerm и Ghostty, а потом сравнить

И потом вдруг окажется что разраб во время разработки что-то такое натыкал что не ломается, но ломает при мерже и деплое прод??

Кроме того вы предлагаете поддерживать две копии IaC - одна для прода, а одна отдельная с cozystack - для дева и стейджа?

У меня dev env - это копия прода до уровня ресурса. Раскатать уже готовый прод терраформ на локалстек или запустить прод ансибл на временно купленный новые дев сервак - очевидно правильный подход

Если у меня есть спецы по Devops - зачем мне cozystack? Он только мешает лишним слоем неконтролируемой абстракции - девопсы и так умеют в argo и helm

А если у меня нету девопс - то ставить cozystack - это самоубийство, которое произойдет во время первой же ошибки из-под капота куба.

Наоборот логично тем кто платит за айтишников пропагандировать вайтишничество. Чем больше предложение - тем ниже цена.

Heroku, Render, Fly.io, Coolify - тысячи их.

В хероку меня все устраивает. А вот инвестиции в 5 миллионов в его клон вызывают недоумение

Очередная Херока? Ну, удачи

TLDR в эпоху искусственного интеллекта

Я хотел чтобы он сделал summary.

Ну фишлабс сперва сделали deep, а потом galaxy on fire 1 / 2.

GoF2 считаю лучшей мобильной Java игрой

Сейчас они делают для компа Everspace / 2

Не "сделать на микросервисах", а "работать будет так же как микросервисы". Передача сообщений будет например через Го каналы. Или через вызов функции с паттерном observer.

Абсолютно совершенно так же как работают любые микросервисные системы.

Вместо спагетти из наследуемых классов, вместе меняющих shared state - детерминированный АПИ системы плагинов, который получает от плагина команды и выполняет их.

В моей реализации плагин пошлет дтошку "создать новый тридэ обьект там-то и там-то" в основную систему в нужный момент в ответ на такую же дтошку "мышкой нажали вот в этих координатах, когда был активен инструмент Х (относящийся к плагину)". Возможно по дороге он еще дернет пару апишек основной системы чтбы узнать свои настройки.

Можно туториал - как это сделать?

Получается среди 6угольников будут 12 пятиугольников. Но даже если бы был один - игровые механики могут быть завязаны на то что карта состоит из одинкаковых тайлов. Как это преодолевать?

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Тель-Авив, Тель-Авив, Израиль
Дата рождения
Зарегистрирован
Активность

Специализация

Бэкенд разработчик
Ведущий
От 900 000 ₽