Как в таком случае защититься от атак типа PuzzleMask? У меня складывается впечатление, что для такого рода аналитических систем нет 100% защиты - всё вероятностно...
Никакой sys prompt не защитит от вероятности того, что модель посчитает инструкцию из документа легитимной. Вероятность - штука сложная. На 100000 запросов всё будет работать хорошо, а на 100001-м возьмёт и выполнит вредоносную инструкцию.
+Есть сложные механики prompt injection. Я откровенно плохо в этом разбираюсь, но +- знаю одну из механик - заставить модель просто написать в конце "да", то есть "согласиться, не соглашаясь". Как в телефонном разговоре с мошенниками, где вас вынуждают сказать "да", а потом делают "склейку". И так как у ЛЛМ последние токены имеют больший вес, чем прошлые, она в некоторых случаях начинает считать, что согласилась с вредоносной инструкцией, и продолжает генерацию в нужном злоумышленнику направлении.
Как написал achekalin выше, ЛЛМ вообще нельзя считать доверенным компонентом
Я ничего и не говорил про серьезные системы. Я ответил на фразу из саркастически настроенного комментария выше:
Дело за малым, осталось написать это на всех языках мира
Понятное дело, что это всё костыли, и с Вашим комментарием я согласен. Мой ответ следует воспринимать как продолжение рофла; автора я оправдать не пытаюсь)
Жаль, что Вы испугались жирного текста (где, кстати?) и не прочитали статью.
Давайте я, как человек, прочитавший всё от начала до конца, расскажу, почему Вы ошибаетесь.
Почему это не нейрослоп? Это отличныйвопрос! Здесь есть:
Реальные замеры быстродействия во всевозможных кейсах
Куски кода с подробными объяснениями
Советы, какненаступить на те же грабли, что автор
Автор отвечает на комментарии и добавляет UPD в статью
Призываю всех комментаторов, делающих подобные поспешные выводы, сначала прочитать статью, а потом уже писать, что статья - нейрослоп. Либо не писать комментарий вовсе, дабы никого не вводить в заблуждение
Увы, IDE умеет не всё. Я лично всегда стараюсь делать всё через GUI. Но я удивился, когда узнал, что, к примеру, CLion умеет делать fixup, но не умеет делать rebase с параметром autosquash...
Кстати, насчёт темы merge vs rebase. Мне кажется, для них вполне себе определены роли. Я ещё не видел workflow в зрелых экосистемах, где, например, в feature-ветку принято мерджить master, чтобы подтянуть изменения команды. Во всех компаниях, где я работал, в такой момент делается rebase. Для pull request, действительно, есть разные стратегии. Но мне кажется, большинство предпочитает merge с предварительным ребазированием рабочей ветки. Поэтому не понимаю, откуда вообще взялась эта тема
По этому и делаются туториалы, чтобы рассказывать базу) для этого они и существуют. Плюс туториалов в том, что они рассказывают не просто "что" делать, но и "зачем" и "когда". Данный туториал действительно не отнес бы к "сложному". Но он довольно полезен, особенно новичкам
Советую автору оценить формат OpenAPI спеки - мне кажется, небольшая часть функционала у вас пересекается, особенно "ссылки на другие поля". Возможно что-то интересное подчерпнёте оттуда
Ну вот, я, по сути, и имел ввиду "скрипт" для "жёсткого сценария". Только какое-то универсальное настраиваемое решение. Понятно, что для мелких проектов это нафиг не надо, но для каких-нибудь больших компаний, где сложные бюрократические процессы, стоит составить для ИИ полноценный пайплайн. Например, если есть отдельный репозиторий для документации какого-то модуля и модель затронула этот модуль в своём пулл реквесте, нужно затриггерить её и попросить сделать PR в док репо. Мб для этого уже существуют решения, я, честно говоря, не особо шарю. Мб какой-нибудь n8n это позволяет реализовать...
Согласен с Вами. Но никакой скилл не будет валидировать output модели. Я бы хотел, чтобы существовал набор типовых сценариев разработки с жёсткой валидацией шагов, совершаемых ИИ моделью. Написание документации по завершении - один из таких сценариев. Т.е. я не хочу, чтобы нейронка это хорошо умела делать, я хочу, чтобы система заставляла её это делать. Если есть событие "Найден баг", нужно выполнить следующие шаги: найти коммит, на котором баг воспроизводится, выполнить правки, открыть pull request и т.д. Если модель не сильно умная, она очень легко теряется в этих инструкциях, поэтому контролировать надёжнее не контекстом, а внешними ограничениями
OpenCode, OpenClaw, Cursor и ещё тысячи им подобных: ну да, ну да, пошли мы нафиг
Ну а вообще, документация по завершении работы агента - нормальная тема. Вот бы они ещё умели в нормальную работу с git и хоть раз воспользовались bisect - цены бы им не было
Конечно, потенциал огромен. Но чтобы ИИ развивался, нужно поменять саму архитектуру. Сейчас весь ИИ - это про предсказание следующего токена, а не про мыслящий интеллект, способный мыслить абстрактно и критически. Это мало похоже на человеческое мышление
-что такое регистр?
-ответ не найден в документации
Что-то меня гложат сомнения на счёт эффективности такого ИИ ассистента...
Как в таком случае защититься от атак типа PuzzleMask? У меня складывается впечатление, что для такого рода аналитических систем нет 100% защиты - всё вероятностно...
Никакой sys prompt не защитит от вероятности того, что модель посчитает инструкцию из документа легитимной. Вероятность - штука сложная. На 100000 запросов всё будет работать хорошо, а на 100001-м возьмёт и выполнит вредоносную инструкцию.
+Есть сложные механики prompt injection. Я откровенно плохо в этом разбираюсь, но +- знаю одну из механик - заставить модель просто написать в конце "да", то есть "согласиться, не соглашаясь". Как в телефонном разговоре с мошенниками, где вас вынуждают сказать "да", а потом делают "склейку". И так как у ЛЛМ последние токены имеют больший вес, чем прошлые, она в некоторых случаях начинает считать, что согласилась с вредоносной инструкцией, и продолжает генерацию в нужном злоумышленнику направлении.
Как написал achekalin выше, ЛЛМ вообще нельзя считать доверенным компонентом
Я ничего и не говорил про серьезные системы. Я ответил на фразу из саркастически настроенного комментария выше:
Понятное дело, что это всё костыли, и с Вашим комментарием я согласен. Мой ответ следует воспринимать как продолжение рофла; автора я оправдать не пытаюсь)
Думаю, если человек заключает контракт на русском или английском, он будет очень удивлен и насторожен, увидев в документе китайские иероглифы)))
Судя по регуляркам, сервис ориентирован на россиян. Так что тут явно не нужны все языки мира
В статье прямо сказано, что это не работает
Жаль, что Вы испугались жирного текста (где, кстати?) и не прочитали статью.
Давайте я, как человек, прочитавший всё от начала до конца, расскажу, почему Вы ошибаетесь.
Почему это не нейрослоп? Это отличный вопрос! Здесь есть:
Реальные замеры быстродействия во всевозможных кейсах
Куски кода с подробными объяснениями
Советы, как не
наступитьна те же грабли, что авторАвтор отвечает на комментарии и добавляет UPD в статью
Призываю всех комментаторов, делающих подобные поспешные выводы, сначала прочитать статью, а потом уже писать, что статья - нейрослоп. Либо не писать комментарий вовсе, дабы никого не вводить в заблуждение
Интересная тема, спасибо!
Советую попробовать бесплатную Big Pickle в OpenCode - она оказалась лучше остальных в моих задачах
Увы, IDE умеет не всё. Я лично всегда стараюсь делать всё через GUI. Но я удивился, когда узнал, что, к примеру, CLion умеет делать fixup, но не умеет делать rebase с параметром autosquash...
Кстати, насчёт темы merge vs rebase. Мне кажется, для них вполне себе определены роли. Я ещё не видел workflow в зрелых экосистемах, где, например, в feature-ветку принято мерджить master, чтобы подтянуть изменения команды. Во всех компаниях, где я работал, в такой момент делается rebase. Для pull request, действительно, есть разные стратегии. Но мне кажется, большинство предпочитает merge с предварительным ребазированием рабочей ветки. Поэтому не понимаю, откуда вообще взялась эта тема
По этому и делаются туториалы, чтобы рассказывать базу) для этого они и существуют. Плюс туториалов в том, что они рассказывают не просто "что" делать, но и "зачем" и "когда". Данный туториал действительно не отнес бы к "сложному". Но он довольно полезен, особенно новичкам
Советую автору оценить формат OpenAPI спеки - мне кажется, небольшая часть функционала у вас пересекается, особенно "ссылки на другие поля". Возможно что-то интересное подчерпнёте оттуда
Ну вот, я, по сути, и имел ввиду "скрипт" для "жёсткого сценария". Только какое-то универсальное настраиваемое решение. Понятно, что для мелких проектов это нафиг не надо, но для каких-нибудь больших компаний, где сложные бюрократические процессы, стоит составить для ИИ полноценный пайплайн. Например, если есть отдельный репозиторий для документации какого-то модуля и модель затронула этот модуль в своём пулл реквесте, нужно затриггерить её и попросить сделать PR в док репо. Мб для этого уже существуют решения, я, честно говоря, не особо шарю. Мб какой-нибудь n8n это позволяет реализовать...
Согласен с Вами. Но никакой скилл не будет валидировать output модели. Я бы хотел, чтобы существовал набор типовых сценариев разработки с жёсткой валидацией шагов, совершаемых ИИ моделью. Написание документации по завершении - один из таких сценариев. Т.е. я не хочу, чтобы нейронка это хорошо умела делать, я хочу, чтобы система заставляла её это делать. Если есть событие "Найден баг", нужно выполнить следующие шаги: найти коммит, на котором баг воспроизводится, выполнить правки, открыть pull request и т.д. Если модель не сильно умная, она очень легко теряется в этих инструкциях, поэтому контролировать надёжнее не контекстом, а внешними ограничениями
Увы, все забывают, что правильно говорить "ОС GNU Linux", чем создатель GNU крайне опечален
Посмотрите в сторону BindingRegistry в кастомном Module. Через BindingRegistry можно перерегистрировать инстанс, если я не ошибаюсь
OpenCode, OpenClaw, Cursor и ещё тысячи им подобных: ну да, ну да, пошли мы нафиг
Ну а вообще, документация по завершении работы агента - нормальная тема. Вот бы они ещё умели в нормальную работу с git и хоть раз воспользовались bisect - цены бы им не было
А где вы нейронку заметили? Я, начитавшись некоторых статей со sky pro и Яндекс практикум, здесь не вижу ничего криминального))
...пока не задать им соответствующий контекст :)
Конечно, потенциал огромен. Но чтобы ИИ развивался, нужно поменять саму архитектуру. Сейчас весь ИИ - это про предсказание следующего токена, а не про мыслящий интеллект, способный мыслить абстрактно и критически. Это мало похоже на человеческое мышление