Тут вы абсолютно правы. ИИ ускоряет, но абсолютно точно, что не заменяет.
Профессию целиком ИИ на текущем этапе не может заменить. Об этом говорят даже исследования именитых компаний и их RnD отделов. В игре есть широкое описание требований, которое периодически обновляется обвязкой, чтобы поспевало за игрой (я написал об этом в статье). Но этого недостаточно для качественного решения. На этапе постановки задачи есть одна из ролей: Product Owner (думаю, близко по формулировке к Game Designer) - она улучшила процесс, но не настолько значительно.
Это же касается и самой разработки - неполностью сформулированные требования или ожидания к задаче не гарантируют качественного исполнения даже с этапом уточнения требований. Надо уметь формулировать, программист в процессе реализации способен сам что-то додумать в контексте, модели (по крайней мере OSS) не ходят внутрь кода чтобы его понять в процессе реализации.
Вчера по замечаниям я добавил более активное использование скриншотов на стадии подготовки требований игры. Это позволило улучшить интерфейс - посмотрю дальше где еще отстрелит.
Спасибо. Это действительно один из самых сложных элементов эксперимента. Об обвязке я расскажу по завершении эксперимента и подведении итогов. Сейчас как раз изучаю опыт Devin, QA Wolf и Cosine как лидеров автоматизированного пайплайна в разработке, которые иногда выступают с докладами.
Я поизучаю почему так вышло: может действительно ИИ не справляется с адаптивом, может пользователи не просили доработать его, а может что-то в обвязке мешает ей делать скриншоты или скриншоты ограничены только из десктопом.
Относительно другой части - она больше похожа на поток возмущения о наболевшем. Но эксперимент как раз об этом и есть - на сколько важна постановка задачи, какой дрейф кодовой базы и результата, куда смещается внимание разработчика.
Попробуйте сами поставить задачу на исправление - возможно это даст больше фундамента вашему возмущению, а мне больше пищи по улучшению.
Не совсем. Задача не является алгоритмом, зачастую это просто формулировка результата или формулировка проблемы. Алгоритм это уже способ достижения результата. В этом эксперименте много мест роста прикладной ценности человека.
Но надо изучить - где именно максимальный позитивный эффект, а где - деградация при видимом эффекте.
1. Да, из-за премодерации я действительно являюсь бутылочным горлышком. Но это осознанный выбор, необходимость валидировать злонамеренный prompt injection. Суть задачи и запрос на изменение я не валидирую. 2. Исходники оставил осознанно закрытыми - суть не в развитии опенсорс проекта и рассмотрении issues, PR/MR. После эксперимента, если будет запрос, я открою исходники с историей вносимых изменений.
Ссылку посмотрю. Я взял другой проект для обвязки, сделанный поверх opencode. Про обвязку pipeline напишу чуть позже статью. Почитаю документацию проекта - может будут интересные идеи для переиспользования.
Это ключевая защита от prompt injection - есть механики обхода даже жестко вшитых системных инструкций.
Но может после этого эксперимента соберу полный AI конвейер - как статистику соберу. Была идея собрать симуляцию - как быстро система из песочницы сбежит. Кстати, интересный эксперимент на будущее. Записал себе - теперь обдумаю всерьез ))
Как по мне — неплохая задумка. То, что у Вас реализовано называется pattern recognition стратегии (если я ничего не упустил). Были очень популярны в конце нулевых, даже давали хороший осязаемый результат на внутридневной торговле. Сейчас я о них мало и редко слышу. Есть довольно топорная, но полнофункциональная реализация opensource на C# на сайте o-s-a.net — посмотрите на неё, может получите ещё немного вдохновения для улучшения и обогащения своего продукта.
Если захотите идти дальше по пути автоматической торговли — полистайте интернет на предмет генетических алгоритмов принятия решений (1С для них не очень приспособлена, но базовые функции обучения сети довольно просты и легки в реализации). Пример простенькой реализации можете посмотреть в библиотеке neatapticjs, в частности класс Neat. Суть алгоритма обучения примерно такая — получается геном, прогоняется на тестовом периоде, тот, который дал наибольший профит — идёт на следующий шаг эволюции и мутаций и так по кругу до получения удовлетворяющего результата, при этом не требуются размеченные данные с правильными и неправильными данными, только оценка конечного результата(фактически — конечной стоимости портфеля). Но для этого потребуется «песочница» и бэктесты.
У 1С огромный профит в отношении других инструментов разработки — куча простых в использовании аналитических инструментов за счёт системы компоновки данных. В правильном русле результат будет действительно хорош.
Или как вариант — обогатите систему данными с ресурсов вроде investing.com (коэффициенты, отчетность, прогнозы дивидендов, оборота, доходов и прочего). Тогда это приложение станет отличным инструментом для принятия инвестиционных решений, вместо спекулятивного трейдинга.
В обоих направлениях есть жизнь, фундамент довольно неплох.
1 убыточная против 2-х прибыльных это — полный фейл, к сожалению. Так как в цепочке 3 убыточных, а потом 6 прибыльных (1 к 2 сделки) с единым процентом дохода и убытка дадут гарантированный убыток. В случае если этот «единый процент» равен 1%, это будет убыток в 0.03%. В данном случае метод монтекарло с увеличение ставки при каждом убытке имеет больше шансов заработать, чем алгоритм.
Я 7 лет на бирже и 5 из них торгую роботами, которых сам себе и пишу (правда в основном это индексный арбитраж и риски в нем минимальны сами по себе). И стратегия торговли это не только условия покупки, продажи и stoploss с takeprofit. Все на бэктестах и имитации сделок забывают, что вы управляете двумя параметрами: условия сделок и на какую долю от портфеля вы будете входить (первичный уровень риска фактически). Если Ваша стратегия даёт успех меньше 80-85% на сделках, монтекарло и случайный осциллятор будут прямым конкурентом Вашим стратегиям, к сожалению. Так как в монтекарло хотябы первичный риск управляем и прозрачен. Копайте в эту сторону. Если у вас есть 70% правильного угадывания, сделайте стратегию доходной докручивая параметры управления портфелем. Это та переменная, о которой многие ньюбы забывают, торгуя и тестируя «на всю котлету», и отваливаются на этапе тестирования гипотез.
Вот по поводу планирования и сравнения с периодом в год противоречит и принципам скрама самого, и тексту выше про изучение пользовательской истории. В этом и есть преимущество скрама — итеративность. А в случае с годом это просто waterfall с еженедельными планерками.
Пока команда разрабатывает и закрывает историю спринта — готовятся будущие истории, но никак не на год вперёд.
Это не Акции в любом случае, Акции — законодательно регулируются. А дыры в контрактах помогут закрыть в опенсорс внимательные люди. Поэтому и нужна внешняя экспертиза.
Я не считаю, что должен быть опенсорс, но внешнюю экспертизу и поддержку, которую даёт опенсорс сообщество считаю лучшим индикатором доверия продукту. То, что компания не имеет внешней экспертизы, при этом является условно закрытой, привлекая средства с рынка по модели, которую сама и принижает, говорит мне (у иных может быть иное мнение) о том, что у собственников нет четкого понимания ни средств извлечения прибыли, ни рыночных рисков. Так как их риски не в том, что появится дубль их продукта, а — в отсутствии доверия к их платформе/контрактам/прочим продуктам и, как следствие, низком спросе.
По P.S. — я считаю, что бизнес сам должен выбрать механику, по которой намерен привлечь средства. А потенциальный инвестор — должен понимать риски от каждой модели и дополнительную нагрузку на него, как инвестора. Другими словами — компания, создавая контракт, указывает модель привлечения средств, расходования средств, доступные роли инвесторов. А инвестор, когда выбирает проект — видит все эти параметры и видит риски и сложности, связанные с ними.
По P.P.S. Да, последние 7 дет я торгую на бирже и чуть больше года инвестирую в ICO небольшими суммами и торгую на криптобиржах. В самих ICO проектах как сотрудник участия не принимал, но сейчас я совладелец молодого SaaS сервиса Торгового терминала для торговли криптовалютами, 3 года проработал консультантом инвест компании и небольшого венчурного фонда по ИТ проектам, работал около 2-х лет ведущим разработчиком в брокере из ТОП-10 РФ по капиталу. И мы делаем фронт нашего терминала опенсорсным в ближайшие месяц-два, как будем готовы. Но не для создания доверия, а скорее — чтобы добиться нужной цели: создать продукт таким, каким он нужен потребителю, а не каким его видим мы.
Спасибо за проекты. Посмотрю на них более внимательно.
Что касается удобств: в любом решении и технологии при внедрении или реализации всегда есть допущения, чтобы добиться желаемого. Даже текущая модель привлечения средств через ICO имеет место для жизни: так как меньше обязательств у компании перед инвестором, требуется меньше ресурсов на отчетность и привлечение средств, с другой стороны — это же допущение привлекает толпы мошенников. Повышение контроля влечёт трудности для компании — надо отчитываться, что-то показывать, давать обратную связь; также сложности для инвестора — с чем-то надо знакомиться, больше функций — сложнее интерфейс, надо принимать участие в голосованиях и прочее; но также — усложняет доступ к средствам мошенникам, что является для инвесторов плюсом (хотя могут быть те, кто пойдёт по простому пути и хочет занять выжидательную позицию: пусть решают и голосуют без меня, я за большинство).
Про descrow посмотрел — не нашёл обсуждения, буду признателен за ссылку. Но мне претит сам их подход — они полностью разносят текущую модель привлечения средств, говоря, что контракт на их платформе полностью решит эти проблемы (как идеальная пилюля), при этом сами используют эту модель для привлечения средств. Да и по-хорошему, сложно доверять молодой компании, которая не даёт возможности на внешнюю экспертизу — вполне хватило бы раскрыть исходный код самого контракта, сделав качественный интерфейс по доступу к его функционалу. Опенсорс бы создал доверие, а интерфейс — аудиторию. А они замахнулись на монополию с тремя директорами и одним программистом в команде.
Но если у Вас есть идеи по созданию такого рода контракта или возражения — давайте их обсудим и учтём. Сейчас прописываю механику в draw.io, я готов пошарить документ, чтобы в итоге получить описание для разработки в виде блок-схем, необходимое для реализации контракта, описанного мной. Мое желание — сделать этот контракт с открытым исходным кодом, чтобы люди и компании могли самостоятельно построить вокруг него экосистему в виде интерфейсов, аудитории и спроса, а сообщество open source дало бы необходимую экспертизу и правки, которые его бы улучшили и развили.
В данной ситуации защищать компанию надо от троллей, которые создают избыточную активность: инициируют ненужные возвраты средств, лишние голосования и строят прочие препоны, мешающие освоению средств добросовестным заемщикам. А также — кто-то недобросовестный от лица компании может инициировать токенизацию, которую сама компания не собирала.
А каким образом можно вернуть средства? Если они не пущены в оборот, а подвешены смарт-контрактом в каком-то промежуточном состоянии, то компания ещё не может их употребить на нужды своего проекта, и собственно, смысла в подобном финансировании и нет. Если они пущены в оборот, то их уже нет, и возвращать там нечего.
В ICO есть такое понятие SoftCap — момент, когда компания собрала нужное количество средств для старта своего проекта (подобные этапы есть и в краудфандинге, и в краудинвестинге). Дальше уже включается механизм «освоения средств» — в зависимости от этапности расходов (если это — не один этап) компания частями может эти средства осваивать и получает на свои счета. Вот пример:
При создании токена есть возможность указать этапность расходования средств получателем, после его отчета по предыдущему этапу и голосованию пользователей об успешности — пользователи голосуют о продолжении инвестирования или возврате средств.
До момента достижения SoftCap, средства остаются на контракте и контракт фактически является держателем до тех пор, пока не будет инициирован вывод средств: на счет компании(если наступил момент SoftCap или HardCap или просто прошло положительное голосование по очередному этапу расходования средств) или возврат инвесторам (в случае инициации и успешного голосования по возврату или недостижение SoftCap к определенной дате окончания сбора средств).
Тут вы абсолютно правы. ИИ ускоряет, но абсолютно точно, что не заменяет.
Профессию целиком ИИ на текущем этапе не может заменить. Об этом говорят даже исследования именитых компаний и их RnD отделов. В игре есть широкое описание требований, которое периодически обновляется обвязкой, чтобы поспевало за игрой (я написал об этом в статье). Но этого недостаточно для качественного решения. На этапе постановки задачи есть одна из ролей: Product Owner (думаю, близко по формулировке к Game Designer) - она улучшила процесс, но не настолько значительно.
Это же касается и самой разработки - неполностью сформулированные требования или ожидания к задаче не гарантируют качественного исполнения даже с этапом уточнения требований. Надо уметь формулировать, программист в процессе реализации способен сам что-то додумать в контексте, модели (по крайней мере OSS) не ходят внутрь кода чтобы его понять в процессе реализации.
Вчера по замечаниям я добавил более активное использование скриншотов на стадии подготовки требований игры. Это позволило улучшить интерфейс - посмотрю дальше где еще отстрелит.
Спасибо. Это действительно один из самых сложных элементов эксперимента. Об обвязке я расскажу по завершении эксперимента и подведении итогов. Сейчас как раз изучаю опыт Devin, QA Wolf и Cosine как лидеров автоматизированного пайплайна в разработке, которые иногда выступают с докладами.
Спасибо за замечание, оно важно для эксперимента.
Я поизучаю почему так вышло: может действительно ИИ не справляется с адаптивом, может пользователи не просили доработать его, а может что-то в обвязке мешает ей делать скриншоты или скриншоты ограничены только из десктопом.
Относительно другой части - она больше похожа на поток возмущения о наболевшем. Но эксперимент как раз об этом и есть - на сколько важна постановка задачи, какой дрейф кодовой базы и результата, куда смещается внимание разработчика.
Попробуйте сами поставить задачу на исправление - возможно это даст больше фундамента вашему возмущению, а мне больше пищи по улучшению.
😅 Да, truncation делает иногда неожиданные сокращения. Уберу его, пока еще лимиты в Changelog не упираются.
Не совсем. Задача не является алгоритмом, зачастую это просто формулировка результата или формулировка проблемы. Алгоритм это уже способ достижения результата. В этом эксперименте много мест роста прикладной ценности человека.
Но надо изучить - где именно максимальный позитивный эффект, а где - деградация при видимом эффекте.
Спасибо.
1. Да, из-за премодерации я действительно являюсь бутылочным горлышком. Но это осознанный выбор, необходимость валидировать злонамеренный prompt injection. Суть задачи и запрос на изменение я не валидирую.
2. Исходники оставил осознанно закрытыми - суть не в развитии опенсорс проекта и рассмотрении issues, PR/MR. После эксперимента, если будет запрос, я открою исходники с историей вносимых изменений.
Ссылку посмотрю. Я взял другой проект для обвязки, сделанный поверх opencode. Про обвязку pipeline напишу чуть позже статью. Почитаю документацию проекта - может будут интересные идеи для переиспользования.
Спасибо за оценку.
Это ключевая защита от prompt injection - есть механики обхода даже жестко вшитых системных инструкций.
Но может после этого эксперимента соберу полный AI конвейер - как статистику соберу. Была идея собрать симуляцию - как быстро система из песочницы сбежит. Кстати, интересный эксперимент на будущее. Записал себе - теперь обдумаю всерьез ))
Как по мне — неплохая задумка. То, что у Вас реализовано называется pattern recognition стратегии (если я ничего не упустил). Были очень популярны в конце нулевых, даже давали хороший осязаемый результат на внутридневной торговле. Сейчас я о них мало и редко слышу. Есть довольно топорная, но полнофункциональная реализация opensource на C# на сайте o-s-a.net — посмотрите на неё, может получите ещё немного вдохновения для улучшения и обогащения своего продукта.
Если захотите идти дальше по пути автоматической торговли — полистайте интернет на предмет генетических алгоритмов принятия решений (1С для них не очень приспособлена, но базовые функции обучения сети довольно просты и легки в реализации). Пример простенькой реализации можете посмотреть в библиотеке neatapticjs, в частности класс Neat. Суть алгоритма обучения примерно такая — получается геном, прогоняется на тестовом периоде, тот, который дал наибольший профит — идёт на следующий шаг эволюции и мутаций и так по кругу до получения удовлетворяющего результата, при этом не требуются размеченные данные с правильными и неправильными данными, только оценка конечного результата(фактически — конечной стоимости портфеля). Но для этого потребуется «песочница» и бэктесты.
У 1С огромный профит в отношении других инструментов разработки — куча простых в использовании аналитических инструментов за счёт системы компоновки данных. В правильном русле результат будет действительно хорош.
Или как вариант — обогатите систему данными с ресурсов вроде investing.com (коэффициенты, отчетность, прогнозы дивидендов, оборота, доходов и прочего). Тогда это приложение станет отличным инструментом для принятия инвестиционных решений, вместо спекулятивного трейдинга.
В обоих направлениях есть жизнь, фундамент довольно неплох.
О! Спасибо. Это действительно моя ошибка.
1 убыточная против 2-х прибыльных это — полный фейл, к сожалению. Так как в цепочке 3 убыточных, а потом 6 прибыльных (1 к 2 сделки) с единым процентом дохода и убытка дадут гарантированный убыток. В случае если этот «единый процент» равен 1%, это будет убыток в 0.03%. В данном случае метод монтекарло с увеличение ставки при каждом убытке имеет больше шансов заработать, чем алгоритм.
Я 7 лет на бирже и 5 из них торгую роботами, которых сам себе и пишу (правда в основном это индексный арбитраж и риски в нем минимальны сами по себе). И стратегия торговли это не только условия покупки, продажи и stoploss с takeprofit. Все на бэктестах и имитации сделок забывают, что вы управляете двумя параметрами: условия сделок и на какую долю от портфеля вы будете входить (первичный уровень риска фактически). Если Ваша стратегия даёт успех меньше 80-85% на сделках, монтекарло и случайный осциллятор будут прямым конкурентом Вашим стратегиям, к сожалению. Так как в монтекарло хотябы первичный риск управляем и прозрачен. Копайте в эту сторону. Если у вас есть 70% правильного угадывания, сделайте стратегию доходной докручивая параметры управления портфелем. Это та переменная, о которой многие ньюбы забывают, торгуя и тестируя «на всю котлету», и отваливаются на этапе тестирования гипотез.
Пока команда разрабатывает и закрывает историю спринта — готовятся будущие истории, но никак не на год вперёд.
Спасибо за ссылку.
При таком законе, думаю, этот умный контракт станет отличным инструментом и фундаментом для развития отрасли
Более того — я считаю любой контракт надо разрабатывать с оглядкой, что им будут пользоваться недобросовестные люди. Даже, если таких не будет)
Это не Акции в любом случае, Акции — законодательно регулируются. А дыры в контрактах помогут закрыть в опенсорс внимательные люди. Поэтому и нужна внешняя экспертиза.
Я не считаю, что должен быть опенсорс, но внешнюю экспертизу и поддержку, которую даёт опенсорс сообщество считаю лучшим индикатором доверия продукту. То, что компания не имеет внешней экспертизы, при этом является условно закрытой, привлекая средства с рынка по модели, которую сама и принижает, говорит мне (у иных может быть иное мнение) о том, что у собственников нет четкого понимания ни средств извлечения прибыли, ни рыночных рисков. Так как их риски не в том, что появится дубль их продукта, а — в отсутствии доверия к их платформе/контрактам/прочим продуктам и, как следствие, низком спросе.
По P.S. — я считаю, что бизнес сам должен выбрать механику, по которой намерен привлечь средства. А потенциальный инвестор — должен понимать риски от каждой модели и дополнительную нагрузку на него, как инвестора. Другими словами — компания, создавая контракт, указывает модель привлечения средств, расходования средств, доступные роли инвесторов. А инвестор, когда выбирает проект — видит все эти параметры и видит риски и сложности, связанные с ними.
По P.P.S. Да, последние 7 дет я торгую на бирже и чуть больше года инвестирую в ICO небольшими суммами и торгую на криптобиржах. В самих ICO проектах как сотрудник участия не принимал, но сейчас я совладелец молодого SaaS сервиса Торгового терминала для торговли криптовалютами, 3 года проработал консультантом инвест компании и небольшого венчурного фонда по ИТ проектам, работал около 2-х лет ведущим разработчиком в брокере из ТОП-10 РФ по капиталу. И мы делаем фронт нашего терминала опенсорсным в ближайшие месяц-два, как будем готовы. Но не для создания доверия, а скорее — чтобы добиться нужной цели: создать продукт таким, каким он нужен потребителю, а не каким его видим мы.
Спасибо за проекты. Посмотрю на них более внимательно.
Что касается удобств: в любом решении и технологии при внедрении или реализации всегда есть допущения, чтобы добиться желаемого. Даже текущая модель привлечения средств через ICO имеет место для жизни: так как меньше обязательств у компании перед инвестором, требуется меньше ресурсов на отчетность и привлечение средств, с другой стороны — это же допущение привлекает толпы мошенников. Повышение контроля влечёт трудности для компании — надо отчитываться, что-то показывать, давать обратную связь; также сложности для инвестора — с чем-то надо знакомиться, больше функций — сложнее интерфейс, надо принимать участие в голосованиях и прочее; но также — усложняет доступ к средствам мошенникам, что является для инвесторов плюсом (хотя могут быть те, кто пойдёт по простому пути и хочет занять выжидательную позицию: пусть решают и голосуют без меня, я за большинство).
Про descrow посмотрел — не нашёл обсуждения, буду признателен за ссылку. Но мне претит сам их подход — они полностью разносят текущую модель привлечения средств, говоря, что контракт на их платформе полностью решит эти проблемы (как идеальная пилюля), при этом сами используют эту модель для привлечения средств. Да и по-хорошему, сложно доверять молодой компании, которая не даёт возможности на внешнюю экспертизу — вполне хватило бы раскрыть исходный код самого контракта, сделав качественный интерфейс по доступу к его функционалу. Опенсорс бы создал доверие, а интерфейс — аудиторию. А они замахнулись на монополию с тремя директорами и одним программистом в команде.
Но если у Вас есть идеи по созданию такого рода контракта или возражения — давайте их обсудим и учтём. Сейчас прописываю механику в draw.io, я готов пошарить документ, чтобы в итоге получить описание для разработки в виде блок-схем, необходимое для реализации контракта, описанного мной. Мое желание — сделать этот контракт с открытым исходным кодом, чтобы люди и компании могли самостоятельно построить вокруг него экосистему в виде интерфейсов, аудитории и спроса, а сообщество open source дало бы необходимую экспертизу и правки, которые его бы улучшили и развили.
В данной ситуации защищать компанию надо от троллей, которые создают избыточную активность: инициируют ненужные возвраты средств, лишние голосования и строят прочие препоны, мешающие освоению средств добросовестным заемщикам. А также — кто-то недобросовестный от лица компании может инициировать токенизацию, которую сама компания не собирала.
В ICO есть такое понятие SoftCap — момент, когда компания собрала нужное количество средств для старта своего проекта (подобные этапы есть и в краудфандинге, и в краудинвестинге). Дальше уже включается механизм «освоения средств» — в зависимости от этапности расходов (если это — не один этап) компания частями может эти средства осваивать и получает на свои счета. Вот пример:
До момента достижения SoftCap, средства остаются на контракте и контракт фактически является держателем до тех пор, пока не будет инициирован вывод средств: на счет компании(если наступил момент SoftCap или HardCap или просто прошло положительное голосование по очередному этапу расходования средств) или возврат инвесторам (в случае инициации и успешного голосования по возврату или недостижение SoftCap к определенной дате окончания сбора средств).