Azure Cognitive Services: где отсутствует статистика производительности Custom Vision?

Я запрашиваю учебный API Azure Custom Vision версии 3.0 (см. https://westeurope.dev.cognitive.microsoft.com/docs/services/Custom_Vision_Training_3.0/operations/5c771cdcbf6a2b18a0c3b809), чтобы самостоятельно генерировать ROC для каждого тега с помощью операции GetIterationPerformance, частью вывода которой является:

{u'averagePrecision': 0.92868346,
 u'perTagPerformance': [{u'averagePrecision': 0.4887446,
                         u'id': u'uuid1',
                         u'name': u'tag_name_1',
                         u'precision': 0.0,
                         u'precisionStdDeviation': 0.0,
                         u'recall': 0.0,
                         u'recallStdDeviation': 0.0},
                        {u'averagePrecision': 1.0,
                         u'id': u'uuid2',
                         u'name': u'tag_name_2',
                         u'precision': 0.0,
                         u'precisionStdDeviation': 0.0,
                         u'recall': 0.0,
                         u'recallStdDeviation': 0.0},
                    {u'averagePrecision': 0.9828302,
                     u'id': u'uuid3',
                     u'name': u'tag_name_3',
                     u'precision': 1.0,
                     u'precisionStdDeviation': 0.0,
                     u'recall': 0.5555556,
                     u'recallStdDeviation': 0.0}],

u'точность': 0,9859485, u'precisionStdDeviation': 0,0, ты вспоминаешь: 0.3752228, u'recallStdDeviation': 0,0}

Точность и неопределенность отзыва, precisionStdDeviation и recallStdDeviation соответственно, всегда кажутся равными 0,0. Является ли это ошибкой пользователя, и если нет, есть ли планы активировать эту статистику?

Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
Как установить LAMP Stack 1/2 на Azure Linux VM
Как установить LAMP Stack 1/2 на Azure Linux VM
В дополнение к нашему предыдущему сообщению о намерении Azure прекратить поддержку Azure Database для MySQL в качестве единого сервера после 16...
0
0
150
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Так что в настоящее время precisionStdDeviation и recallStdDeviation не используются, поэтому они всегда будут равны нулю, это не ошибка пользователя. Эти две метрики существуют, потому что ранее мы выполняли перекрестную проверку пользовательского набора данных, и для каждой складки перекрестной проверки у нас есть точность и полнота, а stddev измеряет изменение точности и полноты между сгибами. Теперь вместо перекрестной проверки мы разделяем часть пользовательских данных как набор проверки и сообщаем об IterationPerformance на основе этого, поскольку нет множественных сгибов, stddev всегда будет равен нулю. Мы планируем удалить эти два поля, извините за путаницу, они, скорее всего, будут удалены в следующей основной версии.

Спасибо за быстрый ответ! Не могли бы вы добавить некоторые дополнительные сведения о других показателях полезной нагрузки и планах по ним, а затем я готов к работе? :) В частности: какая разница между precision и averagePrecision и т. д. в этом случае? Спасибо!

jtlz2 31.05.2019 17:03

Рад ответить на это. 1. Планы полезной нагрузки: мы удалим StdDeviations, а остальное останется прежним. 2. Для метрик полезной нагрузки мы рассчитываем точность и полноту по определению: Точность = TP/(TP+FP) Recall = TP/(TP+FN), а TP, FP и FN зависят от выбранного вами порога (т.е. третий параметр в GetIterationPerformance API), скажем, у нас есть изображение яблока, и модель предсказывает, что это яблоко с достоверностью 60%. Теперь, если вы установите порог более 0,6, этот образец будет ложноотрицательным, если ниже 0,6, этот образец будет истинно положительным.

Kuan Lu 31.05.2019 22:31

Однако средняя точность (AP) представляет собой обобщение точности и отзыва при различных пороговых значениях, подробное объяснение можно найти здесь. Таким образом, с помощью AP вы можете получить представление о том, насколько хорошо модель работает в целом. Модель с высокой точностью и отзывом при другом пороге будет иметь более высокий AP. Еще одна вещь, которую вы заметите, если вы измените пороговое значение, заключается в том, что точки доступа всегда будут одинаковыми, поскольку точка доступа связана не с одним порогом, а со всеми порогами в целом.

Kuan Lu 31.05.2019 22:32

Есть ли шанс, что вы или ваш коллега тоже сможете помочь с этим вопросом? stackoverflow.com/questions/56426097/… :)

jtlz2 03.06.2019 13:10

Да, я вижу, что AP не является функцией запрошенного threshold. Также под средним я предполагаю, что вы имеете в виду среднее, а не медиану или моду :) Есть ли какие-либо планы по обогащению доступных показателей? В настоящее время мы отчасти в ваших руках.... Еще раз спасибо!

jtlz2 03.06.2019 14:00

Да, AP работает как средняя точность при другом пороге. Есть ли какие-то дополнительные показатели, которые вам особенно нужны или имеют для вас смысл? мы всегда открыты для обратной связи, поэтому, возможно, мы можем добавить еще что-то.

Kuan Lu 03.06.2019 19:31

конечно, мы посмотрим на этот Q

Kuan Lu 03.06.2019 19:33

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

jtlz2 04.06.2019 10:19

Другие вопросы по теме