Я пытаюсь реализовать расчет потерь журнала (двоичная классификация) для больших наборов данных в кластере Hadoop.
Итак, у меня есть два источника - файл с истинной целью с идентификатором и истинным целевым значением в строке:
id,true_target
, где истинная цель - 0 или 1.
и файл с прогнозируемыми вероятностями:
id,pred_proba
где pred_proba - действительное число в диапазоне [0, 1].
Мой подход состоит в том, чтобы объединить два входа в фазе карты, например, используя -mapper cat
, затем позволить фазе случайного выбора отсортировать ее, а затем использовать уменьшениефаза для расчета метрики.
Так что это хорошо работает, например, на MAE. Вот довольно стандартный код потокового редуктора Hadoop:
prev_key = None
values = []
for line in sys.stdin:
key, value = line.strip().split("\t")
if key != prev_key and prev_key is not None:
score += math.fabs(values[0] - values[1])
n_records += 1
values = []
values.append(float(value))
prev_key = key
if prev_key is not None:
score += math.fabs(values[0] - values[1])
n_records += 1
score /= n_records
print(score)
Теперь я не уверен в реализации потери журнала.
Я вижу, что если я слепо применяю формулу
score += values[0] * math.log(values[1]) + (1 - values[0]) * math.log(1 - values[1])
не является численно устойчивым, поскольку не обрабатывает регистр log (0).
Но что более важно, симметрична ли эта формула относительно истинного, pred interchange? Поскольку я объединяю и сортирую файлы true и pred, я не могу гарантировать, что значения [0] всегда будут истинными целями.
Поэтому возникает вопрос: можно ли рассчитать потерю журнала в таком сценарии потоковой передачи Hadoop и дакакой подход к численно устойчивому расчету?