Требовать маркировку тем и плагинов, сгенерированных LLM

Внести вклад Обратная связь по сайту
41

Это довольно большой скачок в вашем рассуждении.

  • Если бы вы наняли стажёра или сами потратили 10 ночей, вы тоже могли бы добавить FLAC-плеер в ваше воображаемое приложение. Принятие плохих продуктовых решений не является присущим использованию LLM, и вопрос о том, является ли добавление бесполезной функции потерей усилий на разработку, всегда был предметом обсуждения.

  • Дополнительные функции не обязательно делают ваше приложение медленнее и тяжелее по потреблению RAM, эта проблема была решена концепцией динамической загрузки — 40 лет назад.

Именно так. Подчёркивание моё :slight_smile:

4 лайка
42

Нет, это различие не следует обозначать.

  • Обеспечена ли безопасность программного обеспечения?
  • Решает ли оно мою проблему?

Возвращаюсь к своей первоначальной мысли.

Если у нас есть проблемы с безопасностью в темах, давайте обсудим систему их проверки.

Если у нас есть проблемы с качеством в темах, давайте обсудим системы их проверки.

Но нет, я не буду вводить в темах наклейки вроде «разработано на Mac», «разработано на красной клавиатуре» или «разработано с использованием 93,2% ИИ» — этого не будет.

Сколько я использую ИИ? С удовольствием поделюсь своими рабочими процессами в отдельной теме, но я больше не пишу код вручную в vim.

8 лайков
43

Отвергать все плагины, созданные с помощью ИИ, исключительно по причине их происхождения, было бы генетической ошибкой. То, что контент создан ИИ, раньше могло быть неплохим эвристическим критерием для определения низкокачественного мусора, но по мере улучшения моделей становится всё труднее отличить результат работы человека от результата работы ИИ. Если вас беспокоят качество или безопасность, я считаю, что безопаснее исходить из предположения, что любой код небезопасен, пока он не будет проверен в рамках какой-либо системы рецензирования сообществом.

44

Я думаю, что многим было бы интересно узнать, как команды используют ИИ сегодня — от дизайнеров и разработчиков до юристов, маркетологов и специалистов в других областях.

Знать немного об ИИ, как и я, не значит понимать и осознавать, как компания на самом деле работает с ИИ в повседневной деятельности.

6 лайков
45

Я внимательно изучил всё, что здесь написано, и вижу обе стороны медали. С одной стороны, хорошо, что люди могут просто создавать плагины здесь и публиковать их, но с другой — это плохо, если они содержат «потенциальные» уязвимости безопасности, которые могут поставить под угрозу установку Discourse.

Чуть в сторону.

Существует другой провайдер форумного ПО (WoltLab), у которого, например, есть магазин плагинов. Перед каждым релизом плагины и темы проходят проверку командой. Возможно, стоит подумать о внедрении чего-то подобного и здесь. Однако всегда возникает вопрос о том, кто будет проводить эту проверку, и я предполагаю, что это потребует значительных затрат времени и персонала.

2 лайка
46

Я могу с уверенностью в 100% сказать, что это абсолютно нежизнеспособная идея — проверять каждый плагин и тему сторонних разработчиков. (Хотя бы не вручную, силами человека)

47

А что насчёт специально подобранного набора инструментов для тестирования плагинов или TC, сгенерированных LLM, под наблюдением, поддержкой и обновлением со стороны команды?

Я понимаю, что каждый может запускать тесты самостоятельно, но, честно говоря, не все знают, как это делать.

Простой и надёжный метод для этого, на мой взгляд, — это лучшее из двух миров.

48

В этом и заключается главная цель данной темы:

Было интересно наблюдать, как каждый высказывает своё мнение о том, почему эта прозрачность может быть важна, как с моральной, так и с точки зрения безопасности. Лично мне безразлично, создано ли что-то инженером-программистом с 30-летним стажем, пишущим на Ruby с самого начала, или маленьким Тимми, не имеющим никакого опыта в программировании. Если это на 100% «сгенерированный мусор»[1], я не буду этим пользоваться, и в противном случае я буду лицемером. Я понимаю, почему это популярно, но я просто не собираюсь поддерживать этот подход. Если бы эти модели обучались этичным путём и не вызывали дефицит компонентов, а также эпидемию медиа, сгенерированных ИИ, моё отношение к ним могло бы быть менее негативным, но таков не мир, в котором мы живём.

Беспокойство о безопасности плагинов в целом также обосновано и не ограничивается лишь тем, что «это создано ИИ». Это сложная проблема, которая выходит за рамки данной темы; здесь лишь предлагается ввести требование об обязательных тегах для активов, полностью сгенерированных LLM.

  1. «vibe-coding» или «agentic development» — термины, которые я отказываюсь использовать ↩︎

2 лайка
49

Я по-прежнему не понимаю, какую проблему решает этот подход. Может, кто-нибудь приведёт пример плагина, написанного «на интуиции» (vibe-coded), который оказался мусором, небезопасным или чрезмерно нагружал систему? Такой, который вообще не следовало рекламировать здесь, потому что он был полным хламом и тратой времени всех?

И если такие примеры действительно есть, то достаточно ли их, чтобы считать это проблемой?

1 лайк
50

Мне кажется, было бы полезно ввести某种 самопроверяемый чек-лист для тем: сколько тестирования вы провели, готовы ли вы получать отчеты о качестве и безопасности, будете ли вы оперативно реагировать на обратную связь.

Или, например, опишите ваш процесс разработки не более чем в трех предложениях.

Истинность ответов не будет иметь большого значения, но разница между теми темами, которые прошли самопроверку, и теми, которые этого не делали, может стать ценным сигналом для того, кто рассматривает возможность установки.

4 лайка
51

Лично я никогда не использую «vibe-coding» ни в одном приложении, проекте или программном обеспечении, которое создаю. Я использую чаты с ИИ для генерации идей или уточнения деталей, но никогда не отдаю ИИ весь проект целиком. Это, безусловно, более ручной процесс, но хотя бы я знаю, что делаю, и не слепо доверяю всё это другой сущности.

Но я наблюдал, как за последние несколько месяцев сильно выросло качество кода, созданного с помощью ИИ. Возможно, изначально он писался плохо или был усеян уязвимостями, но я бы сказал, что с тех пор он улучшился на порядок. Дизайн, созданный в стиле «vibe-coding», всё ещё довольно узнаваем (градиенты, рамки, эмодзи и т. д.), даже в некоторых плагинах, которые я видел на Meta. Но важно то, что автор поделился этим из личных интересов и интересов сообщества. Не для того, чтобы кто-то затоптал это и назвал «мусором», а потому что он добился реального успеха с этим плагином и хочет поделиться им с другими форумами, которые ищут аналогичный функционал.

Я понимаю ваши опасения по поводу этики использования ИИ, но они, кажется, направлены на ИИ в целом: компании, которые «разрезают» книги, массовое потребление воды и электроэнергии и т. д. Вы упомянули:

Но как это соотносится с использованием плагинов или TC, созданных с помощью ИИ? Если вам не нравится ИИ, ладно, не используйте его. Но ландшафт программирования радикально изменился с появлением ИИ, и такие вещи, как плагины и TC, тоже изменятся. Перестанете ли вы полностью использовать Discourse, зная, что часть кода была написана с помощью ИИ? Я бы не стал, потому что знаю, что за этим всё ещё стоят люди.

Так стоит ли всё ещё называть это «мусорным кодом» и бойкотировать использование термина «vibe-coding» (лично я не вижу в этом последнем выражении ничего плохого)? Возможно, нет. Это слишком резко? Да. Насколько бы вам это ни не нравилось, иногда нам приходится адаптироваться. Означает ли это, что теперь я буду создавать TC с помощью ИИ и делиться ими? Для меня — нет. Но означает ли это, что я буду рассматривать это как альтернативу, которую не следует отвергать или презирать? Да. И я стараюсь именно так и поступать. Надеюсь, вы тоже сможете.

5 лайков
52

Просто делюсь отобранной статьёй, связанной с этой темой:

Trail of Bits утверждает, что ИИ-агенты наиболее полезны в аудите для создания специализированных инструментов, а не только для поиска уязвимостей. При аудите zkVM Miden они использовали Claude и Codex для создания LSP-сервера, дизассемблера, статического анализатора и модели Lean, что позволило выявить уязвимость высокой критичности, связанную с подделкой подписи, и 95 доказательств на языке Lean, обнаруживших две тонкие проблемы.

Поскольку агенты делают амбициозные побочные проекты дешевле, экономика аудита сместилась в сторону инструментально-ориентированных проверок, способных обеспечить защиту сложных систем гораздо более тщательно, чем прежде.

53

я использую ии, чтобы помогать мне в разработке моих плагинов и компонентов. используйте их на свой страх и риск, но я не буду помечать их какими-либо предупреждениями или тегами, точно так же, как это делает ядро discourse. я управляю агентами, проверяю код (иногда с помощью другого агента или набора «глаз» llm) и тестирую их. вы свободны не использовать их, но я чаще видел плохо написанный код, созданный полностью человеком, чем ии.

7 лайков
54

Действительно, я думаю, что традиционный подход к оценке качества чего-либо — это проверка репутации сущности, которая это создала. Личная репутация хорошо работает, когда человек активен в open source. Как правило, если кто-то ранее делал хорошую работу и был отзывчив, он будет продолжать в том же духе.

2 лайка
55

Вам всё равно придётся приложить усилия. Даже при использовании LLM для создания детерминированных инструментов необходимо проверять, действительно ли они выполняют нужные действия, а не просто делают то, что статистически часто оказывается верным. Использование LLM для создания детерминированных инструментов лучше, чем просто промптинг LLM с markdown-файлами в надежде, что результат будет таким же (это по-прежнему проблематично с юридической и этической точек зрения). Однако, если такой детерминированный инструмент будет слепо поддерживаться с помощью LLM, новые версии рискуют со временем потерять своё детерминированное поведение.

Как показало Snyk в своём отчёте VulnBench, аудит с помощью LLM не является действительно надёжным:

1 лайк
56

Использование ИИ-агентов для создания тем для Discourse кажется мне вполне уместным.

Это было бы здорово. Также, возможно, стоит разобраться, какой идеальный подход подойдёт для тех, у кого нет сильного бэкграунда в программировании. Полагаю, это будет что-то вроде ИИ-агента с доступом к тестовой инстанции Discourse и хорошим файлом навыков. Плюс какой-то автоматизированный аудит безопасности.

2 лайка
58

Конечно, Сэм и команда являются несомненным авторитетом и могут поправить меня, если я ошибаюсь, но после долгих экспериментов с моей стороны и с радостью отдавая что-то взамен, я узнал за последние несколько месяцев, что Discourse Vibe и грамотное использование тестового окружения — это то, что рекомендуется, и, безусловно, идеальная ситуация для начала.

Также возможно работать с определенными тестами на GitHub или даже использовать Discourse Container, но возможности для разработки ограничены, особенно для тех, кто менее опытен, как в моем случае.

Можно «вайб-кодить» для Discourse с помощью ИИ, и нужно лишь проверить или делегировать финальную проверку перед представлением выполненной работы или использованием в продакшене.

Что касается меня, я не имею технической квалификации для ревью кода, но достаточно компетентен, чтобы определять функциональность, как и где её адаптировать, а также задавать вопросы о том, что именно генерировать или доводить до ума. Я предполагаю, что кто-то придёт и открыто внесёт свой вклад в безопасность и надёжность (человеческое ревью всегда) кода, чтобы его можно было использовать всем сообществом. Не только в Meta, но и в Discourse в целом. Это всегда была моя цель, начиная с моего первого промпта.

Вчера я прочитал эту тему и был удивлён тем, как всё изменилось: How hard would it be for non programmers to be able to use the Discourse AI - AI bot to help them create plugins and/or themes

Несколько лет назад я думал, что не смог бы даже направить ИИ, чтобы тот написал код за меня. А сегодня, с оговорками и законной дискуссией, которая существует вокруг этого, это стало реальностью.

4 лайка
59

Да, за последний год многое изменилось. Мне нравится кодировать с помощью ИИ-агентов, так что, возможно, я предвзят.

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

5 лайков
60

Времена меняются: модели с открытыми весами быстро сокращают разрыв. То, что раньше составляло 12-месячную разницу между передовыми (frontier) и открытыми моделями, сейчас укладывается в 3–6 месяцев.

Я ожидаю, что в ближайшие годы ИИ будет распространяться гораздо более равномерно. Локальный ИИ сегодня — это аутсайдер, но он станет более распространённым. Всё больше компаний будут самостоятельно размещать интеллектуальные системы на своих серверах, как это делаем мы в Discourse.

8 лайков