Ogólny
Czy EvalSavedModel jest nadal wymagany?
Wcześniej TFMA wymagało przechowywania wszystkich metryk na wykresie tensorflow przy użyciu specjalnego EvalSavedModel
. Teraz metryki można obliczyć poza wykresem TF za pomocą implementacji beam.CombineFn
.
Niektóre z głównych różnic to:
-
EvalSavedModel
wymaga specjalnego eksportu od trenera, podczas gdy model obsługujący może być używany bez żadnych zmian wymaganych w kodzie szkoleniowym. - Gdy używany jest
EvalSavedModel
, wszelkie metryki dodane w czasie szkolenia są automatycznie dostępne w czasie oceny. BezEvalSavedModel
te metryki muszą zostać ponownie dodane.- Wyjątkiem od tej reguły jest to, że jeśli używany jest model Keras, metryki mogą być również dodawane automatycznie, ponieważ Keras zapisuje informacje o metryce obok zapisanego modelu.
Czy TFMA może współpracować zarówno z metrykami w wykresie, jak i metrykami zewnętrznymi?
TFMA pozwala na zastosowanie podejścia hybrydowego, w którym niektóre metryki można obliczyć na wykresie, podczas gdy inne można obliczyć na zewnątrz. Jeśli obecnie masz EvalSavedModel
, możesz nadal go używać.
Istnieją dwa przypadki:
- Użyj TFMA
EvalSavedModel
zarówno do ekstrakcji cech, jak i obliczeń metryk, ale także dodaj dodatkowe metryki oparte na łączeniu. W takim przypadku uzyskasz wszystkie metryki na wykresie zEvalSavedModel
wraz z wszelkimi dodatkowymi metrykami z opartego na połączeniu, które mogły nie być wcześniej obsługiwane. - Używaj TFMA
EvalSavedModel
do wyodrębniania cech/prognoz, ale używaj metryk opartych na łączeniu dla wszystkich obliczeń metryk. Ten tryb jest przydatny, jeśli wEvalSavedModel
istnieją przekształcenia funkcji, których chcesz użyć do wycinania, ale wolisz wykonywać wszystkie obliczenia metryk poza wykresem.
Organizować coś
Jakie typy modeli są obsługiwane?
TFMA obsługuje modele Keras, modele oparte na ogólnych API sygnatur TF2, a także modele oparte na estymatorze TF (chociaż w zależności od przypadku użycia modele oparte na estymatorze mogą wymagać EvalSavedModel
).
Zobacz przewodnik get_started , aby zapoznać się z pełną listą obsługiwanych typów modeli i wszelkich ograniczeń.
Jak skonfigurować TFMA do pracy z natywnym modelem Keras?
Poniżej znajduje się przykładowa konfiguracja modelu Keras oparta na następujących założeniach:
- Zapisany model służy do udostępniania i używa nazwy sygnatury
serving_default
(można to zmienić za pomocąmodel_specs[0].signature_name
). - Wbudowane metryki z
model.compile(...)
powinny zostać ocenione (można to wyłączyć za pomocąoptions.include_default_metric
w tfma.EvalConfig ).
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
label_key: "<label-key>"
example_weight_key: "<example-weight-key>"
}
metrics_specs {
# Add metrics here. For example:
# metrics { class_name: "ConfusionMatrixPlot" }
# metrics { class_name: "CalibrationPlot" }
}
slicing_specs {}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o innych typach metryk, które można skonfigurować.
Jak skonfigurować TFMA do pracy z ogólnym modelem opartym na sygnaturach TF2?
Poniżej znajduje się przykładowa konfiguracja ogólnego modelu TF2. Poniżej nazwa_sygnatury to nazwa konkretnego signature_name
, który powinien być użyty do oceny.
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
signature_name: "<signature-name>"
label_key: "<label-key>"
example_weight_key: "<example-weight-key>"
}
metrics_specs {
# Add metrics here. For example:
# metrics { class_name: "BinaryCrossentropy" }
# metrics { class_name: "ConfusionMatrixPlot" }
# metrics { class_name: "CalibrationPlot" }
}
slicing_specs {}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o innych typach metryk, które można skonfigurować.
Jak skonfigurować TFMA do pracy z modelem opartym na estymatorze?
W tym przypadku są trzy możliwości.
Opcja 1: użyj modelu serwowania
Jeśli ta opcja zostanie użyta, wszelkie metryki dodane podczas szkolenia NIE będą uwzględniane w ocenie.
Poniżej znajduje się przykładowa konfiguracja, w której założenie serving_default
to użyta nazwa sygnatury:
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
label_key: "<label-key>"
example_weight_key: "<example-weight-key>"
}
metrics_specs {
# Add metrics here.
}
slicing_specs {}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o innych typach metryk, które można skonfigurować.
Opcja 2: Użyj EvalSavedModel wraz z dodatkowymi metrykami opartymi na łączeniach
W takim przypadku użyj EvalSavedModel
do wyodrębniania i oceny funkcji/predykcji, a także dodaj dodatkowe metryki oparte na łączeniu.
Oto przykładowa konfiguracja:
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
signature_name: "eval"
}
metrics_specs {
# Add metrics here.
}
slicing_specs {}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o innych typach metryk, które można skonfigurować, i EvalSavedModel , aby uzyskać więcej informacji na temat konfigurowania EvalSavedModel.
Opcja 3: Użyj modelu EvalSavedModel tylko do wyodrębniania cech/prognoz
Podobny do opcji (2), ale używaj tylko EvalSavedModel
do wyodrębniania cech/predykcji. Ta opcja jest przydatna, jeśli wymagane są tylko metryki zewnętrzne, ale istnieją przekształcenia funkcji, które chcesz podzielić. Podobnie jak w przypadku opcji (1), wszelkie metryki dodane podczas szkolenia NIE będą uwzględniane w ocenie.
W tym przypadku konfiguracja jest taka sama jak powyżej, tylko include_default_metrics
jest wyłączona.
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
signature_name: "eval"
}
metrics_specs {
# Add metrics here.
}
slicing_specs {}
options {
include_default_metrics { value: false }
}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o innych typach metryk, które można skonfigurować, i EvalSavedModel , aby uzyskać więcej informacji na temat konfigurowania EvalSavedModel.
Jak skonfigurować TFMA do pracy z modelem Keras opartym na modelu estymatora?
Konfiguracja model_to_estimator
jest podobna do konfiguracji estymatora. Istnieje jednak kilka różnic dotyczących sposobu działania modelu z estymatorem. W szczególności, model-esimtator zwraca swoje dane wyjściowe w postaci dict gdzie klucz dict jest nazwą ostatniej warstwy danych wyjściowych w powiązanym modelu Keras (jeśli nie podano nazwy, Keras wybierze nazwę domyślną na przykład dense_1
lub output_1
). Z perspektywy TFMA to zachowanie jest podobne do tego, co zostałoby wyprowadzone dla modelu z wieloma wyjściami, mimo że model do estymatora może dotyczyć tylko jednego modelu. Aby uwzględnić tę różnicę, wymagany jest dodatkowy krok w celu ustawienia nazwy danych wyjściowych. Jednak te same trzy opcje mają zastosowanie jako estymator.
Poniżej znajduje się przykład zmian wymaganych w konfiguracji opartej na estymatorze:
from google.protobuf import text_format
config = text_format.Parse("""
... as for estimator ...
metrics_specs {
output_names: ["<keras-output-layer>"]
# Add metrics here.
}
... as for estimator ...
""", tfma.EvalConfig())
Jak skonfigurować TFMA do pracy ze wstępnie obliczonymi (tj. niezależnymi od modelu) prognozami? ( TFRecord
i tf.Example
)
Aby skonfigurować TFMA do pracy ze wstępnie obliczonymi prognozami, domyślny tfma.PredictExtractor
musi być wyłączony, a tfma.InputExtractor
musi być skonfigurowany do analizowania prognoz wraz z innymi funkcjami wejściowymi. Jest to osiągane przez skonfigurowanie tfma.ModelSpec
z nazwą klucza funkcji używanego do prognoz wraz z etykietami i wagami.
Oto przykładowa konfiguracja:
from google.protobuf import text_format
config = text_format.Parse("""
model_specs {
prediction_key: "<prediction-key>"
label_key: "<label-key>"
example_weight_key: "<example-weight-key>"
}
metrics_specs {
# Add metrics here.
}
slicing_specs {}
""", tfma.EvalConfig())
Zobacz metryki , aby uzyskać więcej informacji o metrykach, które można skonfigurować.
Zauważ, że tfma.ModelSpec
jest konfigurowany, model nie jest w rzeczywistości używany (tj. nie ma tfma.EvalSharedModel
). Wezwanie do uruchomienia analizy modelu może wyglądać następująco:
eval_result = tfma.run_model_analysis(
eval_config=eval_config,
# This assumes your data is a TFRecords file containing records in the
# tf.train.Example format.
data_location="/path/to/file/containing/tfrecords",
output_path="/path/for/metrics_for_slice_proto")
Jak skonfigurować TFMA do pracy ze wstępnie obliczonymi (tj. niezależnymi od modelu) prognozami? ( pd.DataFrame
)
W przypadku małych zestawów danych, które mogą zmieścić się w pamięci, alternatywą dla TFRecord
jest pandas.DataFrame
s. TFMA może działać na pandas.DataFrame
przy użyciu API tfma.analyze_raw_data
. Aby uzyskać wyjaśnienie dotyczące tfma.MetricsSpec
i tfma.SlicingSpec
, zobacz przewodnik instalacji . Zobacz metryki , aby uzyskać więcej informacji o metrykach, które można skonfigurować.
Oto przykładowa konfiguracja:
# Run in a Jupyter Notebook.
df_data = ... # your pd.DataFrame
eval_config = text_format.Parse("""
model_specs {
label_key: 'label'
prediction_key: 'prediction'
}
metrics_specs {
metrics { class_name: "AUC" }
metrics { class_name: "ConfusionMatrixPlot" }
}
slicing_specs {}
slicing_specs {
feature_keys: 'language'
}
""", config.EvalConfig())
eval_result = tfma.analyze_raw_data(df_data, eval_config)
tfma.view.render_slicing_metrics(eval_result)
Metryka
Jakie typy metryk są obsługiwane?
TFMA obsługuje szeroką gamę wskaźników, w tym:
- metryki regresji
- metryki klasyfikacji binarnej
- metryki klasyfikacji wieloklasowej/wieloetykietowej
- metryki mikrośrednie / makrośrednie
- metryki oparte na zapytaniach / rankingach
Czy obsługiwane są metryki z modeli wielowyjściowych?
TAk. Więcej informacji znajdziesz w przewodniku po metrykach .
Czy obsługiwane są metryki z wielu modeli?
TAk. Więcej informacji znajdziesz w przewodniku po metrykach .
Czy można dostosować ustawienia metryki (nazwę itp.)?
TAk. Ustawienia metryk można dostosować (np. ustawiając określone progi itp.), dodając ustawienia config
do konfiguracji metryk. Więcej informacji znajdziesz w przewodniku po metrykach .
Czy obsługiwane są niestandardowe metryki?
TAk. Albo pisząc niestandardową implementację tf.keras.metrics.Metric
, albo pisząc niestandardową implementację beam.CombineFn
. Przewodnik po metrykach zawiera więcej szczegółów.
Jakie rodzaje metryk nie są obsługiwane?
Dopóki metrykę można obliczyć za pomocą beam.CombineFn
, nie ma ograniczeń dotyczących rodzajów metryk, które można obliczyć na podstawie tfma.metrics.Metric
. W przypadku pracy z metryką pochodzącą z tf.keras.metrics.Metric
należy spełnić następujące kryteria:
- Powinna istnieć możliwość niezależnego obliczenia wystarczających statystyk dla metryki w każdym przykładzie, a następnie połączenia tych wystarczających statystyk przez dodanie ich we wszystkich przykładach i określenia wartości metryki wyłącznie na podstawie tych wystarczających statystyk.
- Na przykład, dla dokładności wystarczające statystyki to „całkowita poprawność” i „całkowita liczba przykładów”. Możliwe jest obliczenie tych dwóch liczb dla poszczególnych przykładów i dodanie ich do grupy przykładów, aby uzyskać właściwe wartości dla tych przykładów. Ostateczną dokładność można obliczyć za pomocą „całkowicie poprawne/całkowite przykłady”.
Dodatki
Czy mogę użyć TFMA do oceny uczciwości lub stronniczości w moim modelu?
TFMA zawiera dodatek FairnessIndicators , który zapewnia metryki poeksportowe do oceny skutków niezamierzonego odchylenia w modelach klasyfikacji.
Dostosowywanie
A jeśli potrzebuję większej personalizacji?
TFMA jest bardzo elastyczny i pozwala na dostosowanie prawie wszystkich części potoku za pomocą niestandardowych Extractors
, Evaluators
i/lub Writers
. Te abstrakcje są omówione bardziej szczegółowo w dokumencie architektonicznym .
Rozwiązywanie problemów, debugowanie i uzyskiwanie pomocy
Dlaczego metryki MultiClassConfusionMatrix nie pasują do zbinaryzowanych metryk ConfusionMatrix
To są właściwie różne obliczenia. Binaryzacja wykonuje porównanie dla każdego identyfikatora klasy niezależnie (tj. prognoza dla każdej klasy jest porównywana oddzielnie z podanymi progami). W tym przypadku możliwe jest, aby dwie lub więcej klas wszystkie wskazywały, że pasowały do prognozy, ponieważ ich przewidywana wartość była większa niż próg (będzie to jeszcze bardziej widoczne przy niższych progach). W przypadku wieloklasowej macierzy pomyłek nadal istnieje tylko jedna prawdziwa przewidywana wartość, która albo pasuje do rzeczywistej wartości, albo nie. Próg jest używany tylko do wymuszenia, aby prognoza nie pasowała do żadnej klasy, jeśli jest mniejsza niż próg. Im wyższy próg, tym trudniej dopasować prognozę zbinaryzowanej klasy. Podobnie im niższy próg, tym łatwiej jest dopasować prognozy zbinaryzowanej klasy. Oznacza to, że przy progach > 0,5 wartości zbinaryzowane i wieloklasowe wartości macierzy będą bliższe, a przy progach < 0,5 będą bardziej od siebie oddalone.
Na przykład, powiedzmy, że mamy 10 klas, w których przewidziano klasę 2 z prawdopodobieństwem 0,8, ale rzeczywista klasa to klasa 1, która miała prawdopodobieństwo 0,15. Jeśli zbinaryzujesz klasę 1 i użyjesz progu 0,1, wtedy klasa 1 zostanie uznana za poprawną (0,15 > 0,1), więc będzie liczona jako TP. Jednak w przypadku wieloklasowym klasa 2 zostanie uznana za poprawną (0,8 > 0.1), a ponieważ klasa 1 była rzeczywista, będzie to liczone jako FN. Ponieważ przy niższych progach więcej wartości będzie uważanych za dodatnie, na ogół będą wyższe zliczenia TP i FP dla zbinaryzowanej macierzy pomyłek niż dla wieloklasowej macierzy pomyłek i podobnie niższe TN i FN.
Poniżej znajduje się przykład zaobserwowanych różnic między MultiClassConfusionMatrixAtThresholds a odpowiednimi licznikami z binaryzacji jednej z klas.
Dlaczego moje metryki precyzja@1 i przypomnieć@1 mają tę samą wartość?
Przy najwyższej wartości k równej 1 precyzji i przywołanie to to samo. Precyzja jest równa TP / (TP + FP)
, a przywołanie jest równe TP / (TP + FN)
. Najlepsza prognoza jest zawsze pozytywna i albo pasuje do etykiety, albo nie. Innymi słowy, z N
przykładami, TP + FP = N
. Jeśli jednak etykieta nie jest zgodna z najwyższą prognozą, oznacza to również, że dopasowana została prognoza nienajwyższa k, a przy najwyższej k ustawionej na 1, wszystkie prognozy nienajwyższe będą wynosić 0. Oznacza to, że FN musi być (N - TP)
lub N = TP + FN
. Końcowym wynikiem jest precision@1 = TP / N = recall@1
. Należy pamiętać, że dotyczy to tylko sytuacji, w której na przykład jest jedna etykieta, a nie wielu etykiet.
Dlaczego moje dane mean_label i mean_prediction zawsze wynoszą 0,5?
Jest to najprawdopodobniej spowodowane tym, że metryki są skonfigurowane pod kątem problemu z klasyfikacją binarną, ale model wyświetla prawdopodobieństwa dla obu klas zamiast tylko jednej. Jest to powszechne, gdy używany jest interfejs API klasyfikacji tensorflow . Rozwiązaniem jest wybranie klasy, na której chcesz oprzeć prognozy, a następnie zbinaryzacja na tej klasie. Na przykład:
eval_config = text_format.Parse("""
...
metrics_specs {
binarize { class_ids: { values: [0] } }
metrics { class_name: "MeanLabel" }
metrics { class_name: "MeanPrediction" }
...
}
...
""", config.EvalConfig())
Jak interpretować MultiLabelConfusionMatrixPlot?
Biorąc pod uwagę konkretną etykietę, MultiLabelConfusionMatrixPlot
(i skojarzoną MultiLabelConfusionMatrix
) można użyć do porównania wyników innych etykiet i ich przewidywań, gdy wybrana etykieta jest rzeczywiście prawdziwa. Załóżmy na przykład, że mamy trzy klasy bird
, plane
i superman
i klasyfikujemy obrazy, aby wskazać, czy zawierają jedną lub więcej z tych klas. MultiLabelConfusionMatrix
obliczy iloczyn kartezjański każdej rzeczywistej klasy względem każdej innej klasy (nazywanej klasą przewidywaną). Należy zauważyć, że chociaż parowanie jest (actual, predicted)
, predicted
klasa niekoniecznie oznacza pozytywną prognozę, reprezentuje jedynie przewidywaną kolumnę w macierzy rzeczywistej i przewidywanej. Załóżmy na przykład, że obliczyliśmy następujące macierze:
(bird, bird) -> { tp: 6, fp: 0, fn: 2, tn: 0}
(bird, plane) -> { tp: 2, fp: 2, fn: 2, tn: 2}
(bird, superman) -> { tp: 1, fp: 1, fn: 4, tn: 2}
(plane, bird) -> { tp: 3, fp: 1, fn: 1, tn: 3}
(plane, plane) -> { tp: 4, fp: 0, fn: 4, tn: 0}
(plane, superman) -> { tp: 1, fp: 3, fn: 3, tn: 1}
(superman, bird) -> { tp: 3, fp: 2, fn: 2, tn: 2}
(superman, plane) -> { tp: 2, fp: 3, fn: 2, tn: 2}
(superman, superman) -> { tp: 4, fp: 0, fn: 5, tn: 0}
num_examples: 20
MultiLabelConfusionMatrixPlot
ma trzy sposoby wyświetlania tych danych. We wszystkich przypadkach sposób odczytywania tabeli jest wiersz po wierszu z perspektywy aktualnej klasy.
1) Całkowita liczba prognoz
W tym przypadku dla danego wiersza (tj. aktualnej klasy) jakie były TP + FP
dla pozostałych klas. Dla powyższych zliczeń nasz wyświetlacz wyglądałby następująco:
Przewidywany ptak | Przewidywany samolot | Przewidywany superman | |
---|---|---|---|
Rzeczywisty ptak | 6 | 4 | 2 |
Rzeczywisty samolot | 4 | 4 | 4 |
Rzeczywisty superman | 5 | 5 | 4 |
Kiedy obrazki rzeczywiście zawierały bird
, prawidłowo przewidzieliśmy 6 z nich. Jednocześnie przewidzieliśmy plane
(albo słusznie albo nie) 4 razy i superman
(albo słusznie albo nie) 2 razy.
2) Nieprawidłowa liczba prognoz
W tym przypadku dla danego wiersza (tj. aktualnej klasy) jakie były liczby FP
dla pozostałych klas. Dla powyższych zliczeń nasz wyświetlacz wyglądałby następująco:
Przewidywany ptak | Przewidywany samolot | Przewidywany superman | |
---|---|---|---|
Rzeczywisty ptak | 0 | 2 | 1 |
Rzeczywisty samolot | 1 | 0 | 3 |
Rzeczywisty superman | 2 | 3 | 0 |
Kiedy zdjęcia rzeczywiście zawierały bird
, 2 razy błędnie przewidywaliśmy plane
, a 1 raz superman
.
3) Fałszywa liczba ujemna
W tym przypadku dla danego wiersza (tj. aktualnej klasy) jakie były liczby FN
dla innych klas. Dla powyższych zliczeń nasz wyświetlacz wyglądałby następująco:
Przewidywany ptak | Przewidywany samolot | Przewidywany superman | |
---|---|---|---|
Rzeczywisty ptak | 2 | 2 | 4 |
Rzeczywisty samolot | 1 | 4 | 3 |
Rzeczywisty superman | 2 | 2 | 5 |
Kiedy zdjęcia rzeczywiście zawierały bird
, nie udało nam się go przewidzieć 2 razy. Jednocześnie 2 razy nie udało nam się przewidzieć plane
i 4 razy superman
.
Dlaczego otrzymuję komunikat o błędzie informującym, że nie znaleziono klucza prognozy?
Niektóre modele wyświetlają swoje przewidywania w formie słownika. Na przykład estymator TF dla problemu klasyfikacji binarnej wyprowadza słownik zawierający probabilities
, class_ids
itp. W większości przypadków TFMA ma domyślne ustawienia wyszukiwania powszechnie używanych nazw kluczy, takich jak predictions
, probabilities
itp. Jeśli jednak Twój model jest bardzo dostosowany, może to klucze wyjściowe pod nazwami nieznanymi przez TFMA. W takich przypadkach do prediciton_key
należy dodać ustawienie tfma.ModelSpec
, aby zidentyfikować nazwę klucza, pod którym przechowywane są dane wyjściowe.