Плюсы и минусы запрета компиляции в MetaEditor Mql4/Mql5 кода сгенерированного нейросетями - страница 6

 
Vitaly Muzichenko #:

Окончить тему можно этим: Если при запуске файла ex4/5  алгоритм работает "как задумано", вообще не имеет значения кто, как и когда его написал.

Если алгоритм работает не так как задумано, значит где-то есть ошибка, и кто его писал - не имеет значения, ошибка от этого не перестанет быть ошибкой, и не станет полуошибкой. 

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

Что насчет алгоритма, всё верно.

 
Igor Zakharev #:
Но вообще, блокировка компиляции сгенерированного ИИ кода автоматически нарастит кол-во покупателей на mql5.com во всех категориях

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

По поводу анализа на декомпил, если правильно помню, то эта проблема ещё была в MT4, а в MT5 побеждена уже давно.

Igor Zakharev #:
Многие отвечают что чушь, потому что лично в обратном заинтересованы.

Ради интереса закинул один из своих файлов на проверку этому инструменту проверки кода

Похоже, что менее 15% получить просто нельзя. Для MQL5 ещё не приходилось обращаться за помощью к ИИ, так что тут должен быть честный 0%. Поэтому мой интерес тут может быть только в том, чтобы когда нажимаю кнопку компиляции, не приходилось ждать больше минимально необходимого и не видеть радостного сообщения, что в его написании на 15%, оказывается, ещё и какой-то ИИ поучаствовал ).

Ну из области лёгкой паранойи: не хотелось бы думать о том, что весь исходный код при каждой компиляции отправляется неизвестно куда. Ладно, если это и так публичный проект. А если это заказ на фрилансе, в котором заказчик хотел даже хотел подписать дополнительный NDA на физической бумаге?

 

Несмотря на всю инертность публики относительно ИИ - всё равно нужно что-то предпринимать в целях адаптации. 

Суть в количестве юзеров которые заказывают услуги, это общий интерес.

Что-то не заметил в ответах на промпты по MQL5/MQL4 рекомендаций/ссылок на Маркет, Фриланс, VPS и другие сервисы и услуги mql5.com


 
Yuriy Bykov #:

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

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

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

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

Не совсем понятно, кому таким образом можно причинить добро?

Покупателям продуктов на Маркете? Так не каждая компиляция советника отправляется прямиком на первую страницу продаж. Да и остановят ли алерты таких покупателей, если продавец в описании продукта, например, прямо напишет: "Высокое качество советника подтверждается ещё и тем, что система защиты оценила идеальность исходного кода советника на 95% по похожести на идеальный код ИИ".

Может, заказчикам на Фрилансе? Представим ситуацию: контракт заключён, советник написан, отправлен на проверку заказчику и заказчик видит алерт: "Код на 45% похож на сгенерированный ИИ". И что ему с этим делать? Не начинать тестировать и обращаться в Арбитраж? Или всё-таки начинать терять своё время на тестирование? Вдруг советник делает ровно то, что ожидал заказчик? Вполне возможно, что разработчики на Фрилансе тоже смогут на этапе переговоров пояснять, что "они пишут код так хорошо, что даже встроенной системой он опознается как написанный умным ИИ. Поэтому все алерты, если будут, можно смело игнорировать". Но проще, наверное, будет просто лишать код похожести на написанный ИИ, как это сейчас делают со сгенерированными текстами.

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

Igor Zakharev #:

К сожалению сейчас пока нет свободного времени, как время найдется, то ответы по существу напишу.

Если вкратце: то задумка не тяжело осуществима, у неё средний уровень сложности. Суть в том, что конечно совсем идеально она работать не будет, но основные проблемы снимет даже при точности процентов в 80%. Есть масса контраргументов, но что бы их привести нужно ссылки нагуглить, я на днях найду время и напишу ответ.

Код коммерческих продуктов и фриланс работ для финансовых рынков должен писать человек на 100%, а вот проверять тот код на корректность и правильность можно в ИИ - тут как бы вопроса нет.

P. S. Кстати, декомпилы тоже не надо давать компилировать(ещё один повод валидатор кода ввести), они также по признакам легко идентифицируются, как ИИ код по логической структуре и т.д. Над декомпилом нужно попотеть прежде чем он валидный вид примет. И ещё кстати один повод Метаквотс через европейскую ИИ комиссию затребовать запрет на обработку силами ИИ декомпированных исходников и их преображение в якобы авторские. Если вы в курсе, то начало регулированию ИИ уже положено: https://ec.europa.eu/commission/presscorner/detail/en/ip_25_1787

Так что предварительно, на многое ответ - повод для введения валидатора кода и запрета компиляции ИИ кода в защите авторского права, в т.ч. для следования ИИ кодексу ЕС. Это веская причина, она многое перетягивает. И уже содержится в Кодексе Европейского Союза по искусственному интеллекту. 

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


Раз я топикстартер + сейчас выходные, продолжу тему. Обещанный ответ.

Использовал свежий ActiveFense отчет - GenAI Regulations Enterprise Compliance Guide (Руководство по соблюдению корпоративных требований GenAI Regulations)

Что уже актуально (использовал ИИ для анализа статей и материалов - но это не бездумный копипаст по итогу промптов, пометил важное восклицательными знаками):


На основе анализа отчета можно обосновать запрет компиляции в MetaEditor ИИ-сгенерированного кода через следующие регуляторные аргументы и практические риски:


1. Юридическая ответственность за выходные данные ИИ
«Businesses deploying GenAI are not just responsible for what goes into their systems. They are now accountable for what comes out.»
Это фундаментальный принцип EU AI Act и других регуляторных рамок. Если ИИ сгенерирует код с уязвимостью, нарушением лицензии или вредоносной логикой — ответственность несёт компания, а не модель(!). Запрет компиляции до верификации — превентивная мера снижения юридического риска.


2. Требования EU AI Act для high-risk систем

Если ИИ-код используется в критических системах (финансы(!), здравоохранение, инфраструктура), применяются строгие обязательства:

Вывод: Без выполнения этих требований компиляция ИИ-кода может нарушать EU AI Act (!). 


3. NIST AI RMF: Генеративный ИИ-профиль

Хотя профиль NIST добровольный, он становится де-факто стандартом в США. Ключевые элементы, обосновывающие запрет:
  • Guardrails and Safety Controls: Требуются механизмы фильтрации ввода/вывода в реальном времени. Для кода это означает статический/динамический анализ перед компиляцией.
  • Bias Mitigation: ИИ может генерировать код с дискриминационной логикой или уязвимостями, обусловленными смещениями в обучающих данных.
  • Rigorous Adversarial Testing: Red teaming должен включать проверку кода на инъекции, backdoor'ы, уязвимости памяти.
  • Monitoring and Incident Response: Без возможности отслеживания поведения скомпилированного ИИ-кода в production компиляция создаёт неконтролируемый риск.


4. Red Teaming как обязательный этап

Отчет подчеркивает: adversarial testing — единственный практико-ориентированный элемент, согласованный во всех юрисдикциях.
Для ИИ-кода это означает:
  • Проверка на уязвимости (OWASP Top 10, CWE)
  • Анализ на соответствие внутренним стандартам кодирования
  • Тестирование на наличие скрытой функциональности
  • Верификация лицензионной чистоты (риск копирования защищённого кода)

Если red teaming не может быть выполнен автоматически и масштабируемо — запрет компиляции сгенерированного кода в MetaEditor является разумной мерой предосторожности.



P. S. Есть еще статья на Хабре относительно регуляции ИИ, там тоже тот отчет используется: https://habr.com/ru/companies/raft/articles/959630/


Оценка риска в последовательности сделок с одним активом
Оценка риска в последовательности сделок с одним активом
  • 2017.08.28
  • www.mql5.com
В статье описано использование методов теории вероятностей и математической статистики при анализе торговых систем.