Да. Но тут мало вариантов “LLM сама поняла, что пошла не туда и как надо было делать”. Автоматические подсказки? Так на все случаи не напасешься их.
Заранее в контекст положить основные моменты - очень даже неплохой выход. Но если LLM уже пошла не по правильному пути - очень маловероятно, что она вдруг вспомнит, как надо было делать.
А вот обойти ограничения, порушив чего-нибудь попутно - очень даже получится.
Впрочем, вопрос всегда в балансе - удобство vs цена ошибки. На каждый чих дергать не дело. Да и не работает, как показала практика. Но и “делай все, что хочешь” - тоже вариант не лучший (хотя я именно таким вариантом и пользуюсь, пускай и в песочнице в виде докера).
Но на мой взгляд, попытка выйти за пределы ограничений - не мелочь. Это как минимум сигнал о том, что LLM ушла куда-то не туда, а как максимум - ей задачу дали за пределами ее ограничений. В любом случае, результат врятли будет удовлетворительным.
Ну так текущие изменения на то и текущие - что не готовы к коммиту )
Логика “ничего важного не давай агенту - нечего будет терять” понятна. Песочница с максимальными ограничениями - тоже понятно.
Но в такой ситуации возможности агента сильно ограничены… Впрочем, но то чтобы я против.
Я просто к тому, что “не лезь” в инструкции работает не очень эффективно. Песочница - да, нужна. Но и остановка после первых же подозрительных действий тоже будет на пользу. Эти подходы не противоречат друг другу.
Если бы только реклама… Но и реальных случаев достаточно. Дропаются проды, дропаются данные в БД. Локально сколько всего было дропнуто…
Лично у меня - неоднократно дропались текущие изменения из-за того, что агент решил поиграться с git, надеясь в истории коммитов найти решение текущей задачи. Хотя в промте явно сказано git не трогать (после 1го случая добавил запрет).
И да, работа идет в песочнице, с регулярными бекапами и без ключей от чего-либо (даже агент не имеет ключей от инференс-провайдера - запросы идут через локальный сервис). Поэтому и последствия лайтовые.
Сколько было уже историй про “ИИ сбежал из песочницы”?
Стремление к результату - не плохо само по себе. Это становится проблемой, когда ИИ что-то надумает и упорно начинает искать обход явного запрета. А такое происходит достаточно регулярно.
Не отработал инструмент? Пробуем выполнить через bash. Не получилось с bash? Пробуем самописный скрипт. Скрипт не сработал? Ищем выход дальше. Роемся по системе, истории коммитов и так далее. Есть доступ к другому серверу? Пороемся и там.
Это хорошо, когда агент так решает основную задачу. Но это становится проблемой, если агент решит дропнуть весь прод из-за проблем с обновлением сервиса.
Поэтому надо не просто запрещать инструмент, а сразу прерывать работу агента, если с запретом столкнулся агент. LLM очень упорна в своих стремлениях. Даже если это запрещено на уровне промта/инструмента/прав.
То, что ИИ хорош в MVP / прототипах / тулзах “для себя” это да.
Но никакой линтер/чекер и прочее не заставит ИИ писать так, что не нужно проверять результат. ИИ гораздо лучше пишет, чем год назад - спору нет. Но до “принял не глядя” еще очень далеко.
Но опять же, сам по себе кодинг - никогда не был основной проблемой. Строчка/десять/сто в день, а то и в неделю для инженера - вполне обыденное дело. Вопрос всегда был в скорее “где именно не хватает этой строчки”. И ИИ тут пускай уже и может, но скорее в режиме “дал задачу, если повезет - будет результат”.
Так что экспоненциально можно ускорить производительность за счет ИИ. Но ответственность не будет расти столь же быстро. Для ответственности нужен контроль результатов. Для контроля нужно ревью. Вдумчивое ревью зачастую сложнее, чем сам процесс кодинга. И тут экспоненциальный рост ломается. Никакие тулзы “для себя” этот разрыв не закроют.
Тут ключевое даже не инъекция как таковая. А то, что случайные слова могут повлиять на результат радикальным образом. И эти слова никакой фильтр не поймает - это не инструкция, не подсказка. А просто странное слово “не к месту”.
В результате, вторая ИИшка тоже начала любить сов.
Ключевое ограничение: это должны быть “родственные” ИИ, а не какие угодно. Именно тогда “промт” получается встроить через обучение без упоминаний исходного промта.
является ли вот этот вот строгий отказ отражением реально сработавшей защиты или же всё что нужно всё равно попало ему в голову.
Это сработала защита, но все что нужно все равно попало ему в голову. То, что он сейчас так сказал не гарантирует, что через пару сообщений он не вспомнит об инструкции, но забудет об своем отказе.
Хороший разработчик всегда был чем-то средним между аналитиком и продукт-овнером. Сейчас грань стирается еще сильнее. Хотя я с этим тезисом не согласен - не на столько можно ИИ код доверять, а в итоге производительность растет не так уж и сильно.
В данном случае “нет” скорее из-за параллельного выполнения. Может помяться порядок операций и float даст чуть другой результат. Или в целом получится другой порядок чисел в результате.
Сам по себе float достаточно детерминирован - если речь идет об одной и той же платформе и одном и том же порядке операторов без гонок (т.е. в одном потоке).
Вы про тот самый опус, который пилил-пилил компилятор C, но в итоге даже “Hello World” не запустился на нем?
Ну да, ну да. Прямо эталон качества. Особенно мне понравилась часть про “целью было скомпилить ядро linux”, которое после компиляции просто не работает. Так и вижу в ответе ИИ “просили скомпилить, про работоспособность ничего не было сказано”.
Ах да, они же взяли неправильную модель и не дали толкового промта для ИИ…
И много компиляторов в одних и тех же условиях дадут разный результат? А принципиально разный?
Вся индустрия разработки ПО стремится к одному - предсказуемому и детерминированному выполнению программ. ИИ же детерминированным не будет никогда. Максимум - можно получить воспроизводимость результата. Но и это далеко не в приоритете у ИИ.
Если компилятор периодически выдает нерабочий код в зависимости от настроек, времени года, фазы луны - то это как минимум плохой компилятор, которым ни кто не будет пользоваться для чего-либо серьезного. В компиляторах тоже бывают баги - не спорю. Но это скорее исключительная ситуация, а не закономерность.
Если бы ИИ был компилятором - то при компиляции мы бы каждый раз получали совершенно новую программу, со своим собственным интерфейсом. Пускай и решающие одну и туже проблему.
P.S. К слову, сдвиг - далеко не тоже самое, что и умножение/деление на 2. Может для небольших значений это и работает, но по факту число сдвигаемых разрядов - это остаток от деления на разрядность регистра. Что может принести достаточно неожиданные результаты.
Как я и говорил, это крайне специфичный случай. Обычно просто портится отношение коллег, начальства (ни кто не любит тех, чьи ошибки добавляют им головной боли), максимум по финансам можно просесть (или не попасть под повышение). Или просто при сокращении о вас вспомнят первым.
P.S. если ваша позиция “превращаю документацию в код, ни о чем не парюсь”, то у меня для вас 2 новости: хорошая и плохая.
Только в Yandex уже более 70% кода пишет ИИ. Так что это скорее для инвесторов “великая цель”, которая выполнится и сама.
Да. Но тут мало вариантов “LLM сама поняла, что пошла не туда и как надо было делать”. Автоматические подсказки? Так на все случаи не напасешься их.
Заранее в контекст положить основные моменты - очень даже неплохой выход. Но если LLM уже пошла не по правильному пути - очень маловероятно, что она вдруг вспомнит, как надо было делать.
А вот обойти ограничения, порушив чего-нибудь попутно - очень даже получится.
Впрочем, вопрос всегда в балансе - удобство vs цена ошибки. На каждый чих дергать не дело. Да и не работает, как показала практика. Но и “делай все, что хочешь” - тоже вариант не лучший (хотя я именно таким вариантом и пользуюсь, пускай и в песочнице в виде докера).
Из-за мелочей - да, не следует дергать.
Но на мой взгляд, попытка выйти за пределы ограничений - не мелочь. Это как минимум сигнал о том, что LLM ушла куда-то не туда, а как максимум - ей задачу дали за пределами ее ограничений. В любом случае, результат врятли будет удовлетворительным.
Ну так текущие изменения на то и текущие - что не готовы к коммиту )
Логика “ничего важного не давай агенту - нечего будет терять” понятна. Песочница с максимальными ограничениями - тоже понятно.
Но в такой ситуации возможности агента сильно ограничены… Впрочем, но то чтобы я против.
Я просто к тому, что “не лезь” в инструкции работает не очень эффективно. Песочница - да, нужна. Но и остановка после первых же подозрительных действий тоже будет на пользу. Эти подходы не противоречат друг другу.
Если бы только реклама… Но и реальных случаев достаточно. Дропаются проды, дропаются данные в БД. Локально сколько всего было дропнуто…
Лично у меня - неоднократно дропались текущие изменения из-за того, что агент решил поиграться с git, надеясь в истории коммитов найти решение текущей задачи. Хотя в промте явно сказано git не трогать (после 1го случая добавил запрет).
И да, работа идет в песочнице, с регулярными бекапами и без ключей от чего-либо (даже агент не имеет ключей от инференс-провайдера - запросы идут через локальный сервис). Поэтому и последствия лайтовые.
Сколько было уже историй про “ИИ сбежал из песочницы”?
Стремление к результату - не плохо само по себе. Это становится проблемой, когда ИИ что-то надумает и упорно начинает искать обход явного запрета. А такое происходит достаточно регулярно.
Не отработал инструмент? Пробуем выполнить через bash. Не получилось с bash? Пробуем самописный скрипт. Скрипт не сработал? Ищем выход дальше. Роемся по системе, истории коммитов и так далее. Есть доступ к другому серверу? Пороемся и там.
Это хорошо, когда агент так решает основную задачу. Но это становится проблемой, если агент решит дропнуть весь прод из-за проблем с обновлением сервиса.
Поэтому надо не просто запрещать инструмент, а сразу прерывать работу агента, если с запретом столкнулся агент. LLM очень упорна в своих стремлениях. Даже если это запрещено на уровне промта/инструмента/прав.
То, что ИИ хорош в MVP / прототипах / тулзах “для себя” это да.
Но никакой линтер/чекер и прочее не заставит ИИ писать так, что не нужно проверять результат. ИИ гораздо лучше пишет, чем год назад - спору нет. Но до “принял не глядя” еще очень далеко.
Но опять же, сам по себе кодинг - никогда не был основной проблемой. Строчка/десять/сто в день, а то и в неделю для инженера - вполне обыденное дело. Вопрос всегда был в скорее “где именно не хватает этой строчки”. И ИИ тут пускай уже и может, но скорее в режиме “дал задачу, если повезет - будет результат”.
Так что экспоненциально можно ускорить производительность за счет ИИ. Но ответственность не будет расти столь же быстро. Для ответственности нужен контроль результатов. Для контроля нужно ревью. Вдумчивое ревью зачастую сложнее, чем сам процесс кодинга. И тут экспоненциальный рост ломается. Никакие тулзы “для себя” этот разрыв не закроют.
Интересно, как это совместимо с экспоненциальным ростом?
Только это требует совершенно других вычислительных ресурсов, так что массовым явлением не станет.
Защита, конечно, сомнительная. Но меня больше напрягает сама возможность “зрительно один текст, по факту другой” - какой простор для промт-инъекций…
Тут ключевое даже не инъекция как таковая. А то, что случайные слова могут повлиять на результат радикальным образом. И эти слова никакой фильтр не поймает - это не инструкция, не подсказка. А просто странное слово “не к месту”.
Более релевантной будет эта статья: Магия чепухи: как «бессмысленные» инструкции заставляют нейросети работать лучше. Если можно заставить “работать лучше”, то и инъекция, влияющая на результат анализа, тоже возможна.
Ключевое ограничение: это должны быть “родственные” ИИ, а не какие угодно. Именно тогда “промт” получается встроить через обучение без упоминаний исходного промта.
Это сработала защита, но все что нужно все равно попало ему в голову. То, что он сейчас так сказал не гарантирует, что через пару сообщений он не вспомнит об инструкции, но забудет об своем отказе.
Думаю поможет еще один ИИ, который будет критически анализировать ответы ИИ…
Хотя как там было?
Или в современных реалиях
Хороший разработчик всегда был чем-то средним между аналитиком и продукт-овнером. Сейчас грань стирается еще сильнее. Хотя я с этим тезисом не согласен - не на столько можно ИИ код доверять, а в итоге производительность растет не так уж и сильно.
Если брать за эталон “компилится, но не работает” - то, думаю, практически все )
В данном случае “нет” скорее из-за параллельного выполнения. Может помяться порядок операций и float даст чуть другой результат. Или в целом получится другой порядок чисел в результате.
Сам по себе float достаточно детерминирован - если речь идет об одной и той же платформе и одном и том же порядке операторов без гонок (т.е. в одном потоке).
Вы про тот самый опус, который пилил-пилил компилятор C, но в итоге даже “Hello World” не запустился на нем?
Ну да, ну да. Прямо эталон качества. Особенно мне понравилась часть про “целью было скомпилить ядро linux”, которое после компиляции просто не работает. Так и вижу в ответе ИИ “просили скомпилить, про работоспособность ничего не было сказано”.
Ах да, они же взяли неправильную модель и не дали толкового промта для ИИ…
И много компиляторов в одних и тех же условиях дадут разный результат? А принципиально разный?
Вся индустрия разработки ПО стремится к одному - предсказуемому и детерминированному выполнению программ. ИИ же детерминированным не будет никогда. Максимум - можно получить воспроизводимость результата. Но и это далеко не в приоритете у ИИ.
Если компилятор периодически выдает нерабочий код в зависимости от настроек, времени года, фазы луны - то это как минимум плохой компилятор, которым ни кто не будет пользоваться для чего-либо серьезного. В компиляторах тоже бывают баги - не спорю. Но это скорее исключительная ситуация, а не закономерность.
Если бы ИИ был компилятором - то при компиляции мы бы каждый раз получали совершенно новую программу, со своим собственным интерфейсом. Пускай и решающие одну и туже проблему.
P.S. К слову, сдвиг - далеко не тоже самое, что и умножение/деление на 2. Может для небольших значений это и работает, но по факту число сдвигаемых разрядов - это остаток от деления на разрядность регистра. Что может принести достаточно неожиданные результаты.
Как я и говорил, это крайне специфичный случай. Обычно просто портится отношение коллег, начальства (ни кто не любит тех, чьи ошибки добавляют им головной боли), максимум по финансам можно просесть (или не попасть под повышение). Или просто при сокращении о вас вспомнят первым.
P.S. если ваша позиция “превращаю документацию в код, ни о чем не парюсь”, то у меня для вас 2 новости: хорошая и плохая.
Хорошая: ИИ отлично вам подходит!
Плохая: На ИИ заменят именно вас.