Я на Standart Layer в Azure ML сижу. Список отличий слоев можно найти на https://azure.microsoft.com/en-us/pricing/details/machine-learning/. Вроде про функции, о которых вы говорите, речи там не идет, но я не исключаю, что ограничения с которыми вы столкнулиcь, именно из-за типа layer.
Тогда переименуйте пост во что-то, адекватно отражающее его содержимое («Azure digest для { администраторов | всех кроме разработчиков | свой вариант }»)
Вопросов действительно много (легче еще одну статью написать), поэтому ответы будут короткие:
— описание того, как информация и рез-ты транзакции попадают в лог транзакций есть в 3-ей части;
— эксперт (я). Не обязательно, если у клиента не слишком специфический фрод;
— время — год, объем — как можно больше (big data!), дальше время/объем балансируем в зав-ти от точности модели и конечной стоимости ее владения;
— это не проблема для используемых алгоритмов машинного обучения;
— уровень точности предсказания и объем новых данных — основные триггеры для переобучения (т.е. время переобучения недетерминировано).
Все верно: в таблице TransactionsInfo собрана история платежей + результаты по ним (получатель платежа в конце-концов всегда узнает, чем закончился проходящий через него платеж).
(Я не уверен, но думаю, положение дел приблизительно такое) Все зависит от источника данных, который вы используйте: если это Azure Storage, то придется заплатить за хранилище, для внешнего Odata-сервиса — за входящий трафик. Есть и предварительно загруженные в Azure ML датасеты — за них платить не нужно.
Проблем нет, есть законодательные ограничения (нефункциональные требования, описаны во 2-ой части статьи). Проблемы будут, если эти ограничения не соблюдать.
Определение Янга не читал, но за концепцией разделения потоков еще стоит и реализация. В .NET CQRS принято реализовывать с использованием паттернов Repository/Command/введением DDD/Event Sourcing/etс. (тема долгая) В описываемой системе все обстоит немного (сильно) по-другому.
Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).
то касается 1 и 0 (мошенничество или нет) — такой подход не особо гибкий.
Подождите, где прочитали про 1 или 0? Я писал про диапазон числовых значений от 0 до 1 (что представляет собой вероятность того, что транзакция является мошеннической).
Более подробно алгоритм машиного обучения еще будет описан в заключительной чевертой части статьи.
и забываете про fingerprint'ы, proxy, AVS, проверки IP и другие.
Что вы имеете под терминов AVS я не понял. Про остальное не забываю: fingerprintы — это зона ответственности клиента, а не антифрод-сервиса, proxy — не вижу смысла, про списки IP писал в этой статье.
Комментарий ко второй части вашего коментария — где вы видите, чтобы я писал, что в рамках статьи собираюсь обсуждать бизнес план? No money, only IT!)
Я понял. Конечно, я это неудачно выразился: возвращается вероятность того, что платеж окажется мошенническим — число от 0 до 1.
Рекомендации для клиентов сервиса еще будут описаны в 4-ой заключительной части статьи.
Разделение потоков на чтение и на запись — это довольно частый паттерн для высоконагруженных систем (но это только одна единственная концепция, и это точно ни CQRS, ни с Event Sourcing, ни CQRS + Event Sourcing.
Про SLA отдельных компонентов я не очень понял: что Вы подразумеваете под термином 'отдельных компонент'?
(Если упрощенно) Показатели, влияющие на точность работы алгоритма предсказания (предикторы), определяют эксперты в предметной области. Data scientist'ы статистическими методами проверяют верна ли гипотеза экспертов. Если да, то разработчик интегрирует новый показатель в систему и запускается переобучение модели.
Это только на первый взгляд и только по теме Data Platform.
Ссылка в 'Linux в Azure Batch' ведет в какой-то маркетинг, вот ссылка на тот же анонс в MS HPC-блог.
— описание того, как информация и рез-ты транзакции попадают в лог транзакций есть в 3-ей части;
— эксперт (я). Не обязательно, если у клиента не слишком специфический фрод;
— время — год, объем — как можно больше (big data!), дальше время/объем балансируем в зав-ти от точности модели и конечной стоимости ее владения;
— это не проблема для используемых алгоритмов машинного обучения;
— уровень точности предсказания и объем новых данных — основные триггеры для переобучения (т.е. время переобучения недетерминировано).
Спасибо, что поправили.
Внешним клиентам (когда они будут), конечно, открывается только SLA антифрод-сервиса (клиенты могут и не догадываться, что система работает в Azure).
Более подробно алгоритм машиного обучения еще будет описан в заключительной чевертой части статьи.
Комментарий ко второй части вашего коментария — где вы видите, чтобы я писал, что в рамках статьи собираюсь обсуждать бизнес план? No money, only IT!)
И то и другое must have и будет описано в следующих частях статьи.
Рекомендации для клиентов сервиса еще будут описаны в 4-ой заключительной части статьи.
Про SLA отдельных компонентов я не очень понял: что Вы подразумеваете под термином 'отдельных компонент'?