TF1.x -> Przegląd migracji TF2

TensorFlow 2 zasadniczo różni się od TF1.x pod kilkoma względami. Nadal możesz uruchamiać niezmodyfikowany kod TF1.x ( z wyjątkiem contrib ) w przypadku instalacji binarnych TF2 w następujący sposób:

import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()

Nie jest to jednak działanie polegające na uruchamianiu zachowań i interfejsów API TF2 i może nie działać zgodnie z oczekiwaniami z kodem napisanym dla TF2. Jeśli nie używasz aktywnych zachowań TF2, w rzeczywistości uruchamiasz TF1.x na instalacji TF2. Przeczytaj przewodnik dotyczący zachowań TF1 i TF2, aby uzyskać więcej szczegółów na temat tego, czym TF2 różni się od TF1.x.

Ten przewodnik zawiera przegląd procesu migracji kodu TF1.x do TF2. Dzięki temu możesz korzystać z nowych i przyszłych ulepszeń funkcji, a także sprawić, że Twój kod będzie prostszy, wydajniejszy i łatwiejszy w utrzymaniu.

Jeśli używasz wysokiego poziomu API tf.keras i trenujesz wyłącznie z model.fit , Twój kod powinien być mniej więcej w pełni kompatybilny z TF2, z wyjątkiem następujących zastrzeżeń:

Proces migracji TF2

Przed migracją poznaj różnice w zachowaniu i interfejsach API pomiędzy TF1.x i TF2, czytając przewodnik .

  1. Uruchom automatyczny skrypt, aby przekonwertować część użycia interfejsu API TF1.x na tf.compat.v1 .
  2. Usuń stare symbole tf.contrib (sprawdź TF Addons i TF-Slim ).
  3. Spraw, aby Twoje przebiegi do przodu modelu TF1.x działały w TF2 z włączoną opcją szybkiego wykonywania.
  4. Zaktualizuj swój kod TF1.x do pętli szkoleniowych i zapisywania/ładowania modeli do odpowiedników TF2.
  5. (Opcjonalnie) Przeprowadź migrację interfejsów API tf.compat.v1 zgodnych z TF2 do idiomatycznych interfejsów API TF2.

Poniższe sekcje stanowią rozwinięcie kroków opisanych powyżej.

Uruchom skrypt konwersji symboli

Wykonuje to początkowy przebieg podczas przepisywania symboli kodu, aby działały z plikami binarnymi TF 2.x, ale nie sprawi, że Twój kod będzie idiomatyczny z TF 2.x, ani nie sprawi, że Twój kod będzie automatycznie kompatybilny z zachowaniami TF2.

Twój kod najprawdopodobniej nadal będzie korzystał z punktów końcowych tf.compat.v1 w celu uzyskania dostępu do symboli zastępczych, sesji, kolekcji i innych funkcji w stylu TF1.x.

Przeczytaj przewodnik , aby dowiedzieć się więcej o najlepszych praktykach korzystania ze skryptu konwersji symboli.

Usuń użycie tf.contrib

Moduł tf.contrib został wycofany, a kilka jego podmodułów zostało zintegrowanych z rdzeniem API TF2. Pozostałe podmoduły zostały teraz wydzielone do innych projektów, takich jak TF IO i TF Addons .

Duża część starszego kodu TF1.x korzysta z biblioteki Slim , która została spakowana z TF1.x jako tf.contrib.layers . Podczas migracji kodu Slim do TF2 zmień użycie API Slim tak, aby wskazywało pakiet pip tf-slim . Następnie przeczytaj przewodnik mapowania modeli, aby dowiedzieć się, jak przekonwertować kod Slim.

Alternatywnie, jeśli używasz wstępnie wytrenowanych modeli Slim, możesz rozważyć wypróbowanie wstępnie przeszkolonych modeli Keras z tf.keras.applications lub TF Hub TF Hub TF2 SavedModel wyeksportowanych z oryginalnego kodu Slim.

Spraw, aby przebiegi do przodu modelu TF1.x były uruchamiane z włączonymi zachowaniami TF2

Śledź zmienne i straty

TF2 nie obsługuje kolekcji globalnych.

Wykonanie Eager w TF2 nie obsługuje interfejsów API opartych na kolekcji tf.Graph . Ma to wpływ na sposób konstruowania i śledzenia zmiennych.

W przypadku nowego kodu TF2 należy użyć tf.Variable zamiast v1.get_variable i użyć obiektów Pythona do zbierania i śledzenia zmiennych zamiast tf.compat.v1.variable_scope . Zwykle będzie to jeden z:

Agreguj listy zmiennych (np. tf.Graph.get_collection(tf.GraphKeys.VARIABLES) ) z atrybutami .variables i .trainable_variables obiektów Layer , Module lub Model .

Klasy Layer i Model implementują kilka innych właściwości, które eliminują potrzebę kolekcji globalnych. Ich właściwość .losses może zastąpić użycie kolekcji tf.GraphKeys.LOSSES .

Przeczytaj przewodnik mapowania modeli , aby dowiedzieć się więcej na temat używania podkładek modelujących kod TF2 do osadzania istniejącego kodu opartego na get_variable i variable_scope wewnątrz Layers , Models i Modules . Umożliwi to wykonywanie przejść do przodu z włączoną opcją szybkiego wykonywania bez większych przeróbek.

Dostosowanie się do innych zmian w zachowaniu

Jeśli sam przewodnik mapowania modelu jest niewystarczający, aby umożliwić przekazanie modelu do przodu z innymi zmianami zachowania, które mogą być bardziej szczegółowe, zobacz przewodnik dotyczący zachowań TF1.x i TF2 , aby dowiedzieć się o innych zmianach zachowania i sposobach dostosowania się do nich . Aby uzyskać szczegółowe informacje, sprawdź także tworzenie nowych warstw i modeli za pośrednictwem przewodnika po podklasach .

Walidacja wyników

Zobacz przewodnik po sprawdzaniu poprawności modelu , aby uzyskać proste narzędzia i wskazówki dotyczące sposobu (numerycznego) sprawdzenia, czy model zachowuje się poprawnie, gdy włączone jest szybkie wykonywanie. Może się to okazać szczególnie przydatne w połączeniu z przewodnikiem mapowania modelu .

Uaktualnij szkolenie, ocenę i kod importu/eksportu

Pętle szkoleniowe TF1.x zbudowane w stylu v1.Session tf.estimator.Estimator s i inne podejścia oparte na kolekcjach nie są kompatybilne z nowymi zachowaniami TF2. Ważne jest, aby przeprowadzić migrację całego kodu szkoleniowego TF1.x, ponieważ połączenie go z kodem TF2 może spowodować nieoczekiwane zachowania.

Aby to zrobić, możesz wybrać jedną z kilku strategii.

Podejście najwyższego poziomu polega na użyciu tf.keras . Funkcje wysokiego poziomu w Keras zarządzają wieloma szczegółami niskiego poziomu, które można łatwo przeoczyć, jeśli napiszesz własną pętlę treningową. Na przykład automatycznie zbierają straty regularyzacyjne i ustawiają argument training=True podczas wywoływania modelu.

Zapoznaj się z przewodnikiem dotyczącym migracji narzędzia Estimator , aby dowiedzieć się, jak przeprowadzić migrację kodu programu tf.estimator.Estimator w celu korzystania z standardowych i niestandardowych pętli szkoleniowych tf.keras .

Niestandardowe pętle treningowe zapewniają lepszą kontrolę nad modelem, na przykład śledzenie ciężarów poszczególnych warstw. Przeczytaj przewodnik dotyczący budowania pętli treningowych od podstaw , aby dowiedzieć się, jak używać tf.GradientTape do pobierania wag modeli i używania ich do aktualizacji modelu.

Konwertuj optymalizatory TF1.x na optymalizatory Keras

Optymalizatory w tf.compat.v1.train , takie jak optymalizator Adama i optymalizator gradientu , mają swoje odpowiedniki w tf.keras.optimizers .

Poniższa tabela podsumowuje sposób konwersji starszych optymalizatorów na ich odpowiedniki w Keras. Możesz bezpośrednio zastąpić wersję TF1.x wersją TF2, chyba że wymagane są dodatkowe kroki (takie jak aktualizacja domyślnej szybkości uczenia ).

Pamiętaj, że konwersja optymalizatorów może spowodować, że stare punkty kontrolne będą niekompatybilne .

TF1.x TF2 Dodatkowe kroki
`tf.v1.train.GradientDescentOptimizer` tf.keras.optimizers.SGD Nic
`tf.v1.train.MomentumOptimizer` tf.keras.optimizers.SGD Dołącz argument „pędu”.
`tf.v1.train.AdamOptimizer` tf.keras.optimizers.Adam Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`
`tf.v1.train.RMSPropOptimizer` tf.keras.optimizers.RMSprop Zmień nazwę argumentu „rozpad” na „rho”.
`tf.v1.train.AdadeltaOptimizer` tf.keras.optimizers.Adadelta Nic
`tf.v1.train.AdagradOptimizer` tf.keras.optimizers.Adagrad Nic
`tf.v1.train.FtrlOptimizer` tf.keras.optimizers.Ftrl Usuń argumenty „nazwa_akumulatora” i „nazwa_liniowa”.
`tf.contrib.AdamaxOptimizer` tf.keras.optimizers.Adamax Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`
`tf.contrib.Nadam` tf.keras.optimizers.Nadam Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`

Uaktualnij potoki wprowadzania danych

Istnieje wiele sposobów dostarczania danych do modelu tf.keras . Jako dane wejściowe przyjmą generatory Pythona i tablice Numpy.

Zalecanym sposobem dostarczania danych do modelu jest użycie pakietu tf.data , który zawiera zbiór klas o wysokiej wydajności do manipulowania danymi. dataset należące do tf.data są wydajne, wyraziste i dobrze integrują się z TF2.

Można je przekazać bezpośrednio do metody tf.keras.Model.fit .

model.fit(dataset, epochs=5)

Można je iterować bezpośrednio w standardowym Pythonie:

for example_batch, label_batch in dataset:
    break

Jeśli nadal używasz tf.queue , są one teraz obsługiwane tylko jako struktury danych, a nie jako potoki wejściowe.

Powinieneś także przeprowadzić migrację całego kodu przetwarzania wstępnego funkcji, który używa tf.feature_columns . Więcej szczegółów znajdziesz w przewodniku po migracji .

Zapisywanie i ładowanie modeli

TF2 wykorzystuje punkty kontrolne oparte na obiektach. Przeczytaj przewodnik dotyczący migracji punktów kontrolnych , aby dowiedzieć się więcej na temat migracji poza punktami kontrolnymi TF1.x opartymi na nazwach. Przeczytaj także przewodnik po punktach kontrolnych w podstawowej dokumentacji TensorFlow.

Nie ma znaczących problemów ze zgodnością zapisanych modeli. Przeczytaj przewodnik SavedModel , aby uzyskać więcej informacji na temat migracji SavedModel s z TF1.x do TF2. Ogólnie,

  • TF1.x zapisane_modele działają w TF2.
  • Zapisane modele TF2 działają w TF1.x, jeśli wszystkie operacje są obsługiwane.

Więcej informacji na temat pracy z obiektami Graph.pb i Graph.pbtxt można znaleźć w sekcji GraphDef w przewodniku migracji SavedModel .

(Opcjonalnie) Przeprowadź migrację poza symbolami tf.compat.v1

Moduł tf.compat.v1 zawiera kompletne API TF1.x z jego oryginalną semantyką.

Nawet po wykonaniu powyższych kroków i uzyskaniu kodu w pełni kompatybilnego ze wszystkimi zachowaniami TF2, prawdopodobnie będzie wiele wzmianek o api compat.v1 , które tak się składa, że ​​są kompatybilne z TF2. Powinieneś unikać używania starszych interfejsów API compat.v1 do każdego nowego kodu, który piszesz, chociaż będą one nadal działać z już napisanym kodem.

Możesz jednak zdecydować się na migrację istniejących zastosowań do innych niż starsze interfejsów API TF2. Dokumentacja poszczególnych symboli compat.v1 często wyjaśnia, jak przeprowadzić ich migrację do innych niż starsze interfejsów API TF2. Dodatkowo może w tym pomóc sekcja przewodnika mapowania modeli dotycząca przyrostowej migracji do idiomatycznych interfejsów API TF2 .

Zasoby i dalsza lektura

Jak wspomniano wcześniej, dobrą praktyką jest migracja całego kodu TF1.x do TF2. Przeczytaj przewodniki w sekcji Migracja do TF2 przewodnika TensorFlow, aby dowiedzieć się więcej.

,

TensorFlow 2 zasadniczo różni się od TF1.x pod kilkoma względami. Nadal możesz uruchamiać niezmodyfikowany kod TF1.x ( z wyjątkiem contrib ) w przypadku instalacji binarnych TF2 w następujący sposób:

import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()

Nie jest to jednak działanie polegające na uruchamianiu zachowań i interfejsów API TF2 i może nie działać zgodnie z oczekiwaniami z kodem napisanym dla TF2. Jeśli nie używasz aktywnych zachowań TF2, w rzeczywistości uruchamiasz TF1.x na instalacji TF2. Przeczytaj przewodnik dotyczący zachowań TF1 i TF2, aby uzyskać więcej szczegółów na temat tego, czym TF2 różni się od TF1.x.

Ten przewodnik zawiera przegląd procesu migracji kodu TF1.x do TF2. Dzięki temu możesz korzystać z nowych i przyszłych ulepszeń funkcji, a także sprawić, że Twój kod będzie prostszy, wydajniejszy i łatwiejszy w utrzymaniu.

Jeśli używasz wysokiego poziomu API tf.keras i trenujesz wyłącznie z model.fit , Twój kod powinien być mniej więcej w pełni kompatybilny z TF2, z wyjątkiem następujących zastrzeżeń:

Proces migracji TF2

Przed migracją poznaj różnice w zachowaniu i interfejsach API pomiędzy TF1.x i TF2, czytając przewodnik .

  1. Uruchom automatyczny skrypt, aby przekonwertować część użycia interfejsu API TF1.x na tf.compat.v1 .
  2. Usuń stare symbole tf.contrib (sprawdź TF Addons i TF-Slim ).
  3. Spraw, aby Twoje przebiegi do przodu modelu TF1.x działały w TF2 z włączoną opcją szybkiego wykonywania.
  4. Zaktualizuj swój kod TF1.x do pętli szkoleniowych i zapisywania/ładowania modeli do odpowiedników TF2.
  5. (Opcjonalnie) Przeprowadź migrację interfejsów API tf.compat.v1 zgodnych z TF2 do idiomatycznych interfejsów API TF2.

Poniższe sekcje stanowią rozwinięcie kroków opisanych powyżej.

Uruchom skrypt konwersji symboli

Wykonuje to początkowy przebieg podczas przepisywania symboli kodu, aby działały z plikami binarnymi TF 2.x, ale nie sprawi, że Twój kod będzie idiomatyczny z TF 2.x, ani nie sprawi, że Twój kod będzie automatycznie kompatybilny z zachowaniami TF2.

Twój kod najprawdopodobniej nadal będzie korzystał z punktów końcowych tf.compat.v1 w celu uzyskania dostępu do symboli zastępczych, sesji, kolekcji i innych funkcji w stylu TF1.x.

Przeczytaj przewodnik , aby dowiedzieć się więcej o najlepszych praktykach korzystania ze skryptu konwersji symboli.

Usuń użycie tf.contrib

Moduł tf.contrib został wycofany, a kilka jego podmodułów zostało zintegrowanych z rdzeniem API TF2. Pozostałe podmoduły zostały teraz wydzielone do innych projektów, takich jak TF IO i TF Addons .

Duża część starszego kodu TF1.x korzysta z biblioteki Slim , która została spakowana z TF1.x jako tf.contrib.layers . Podczas migracji kodu Slim do TF2 zmień użycie API Slim tak, aby wskazywało pakiet pip tf-slim . Następnie przeczytaj przewodnik mapowania modeli, aby dowiedzieć się, jak przekonwertować kod Slim.

Alternatywnie, jeśli używasz wstępnie wytrenowanych modeli Slim, możesz rozważyć wypróbowanie wstępnie przeszkolonych modeli Keras z tf.keras.applications lub TF Hub TF Hub TF2 SavedModel wyeksportowanych z oryginalnego kodu Slim.

Spraw, aby przebiegi do przodu modelu TF1.x były uruchamiane z włączonymi zachowaniami TF2

Śledź zmienne i straty

TF2 nie obsługuje kolekcji globalnych.

Wykonanie Eager w TF2 nie obsługuje interfejsów API opartych na kolekcji tf.Graph . Ma to wpływ na sposób konstruowania i śledzenia zmiennych.

W przypadku nowego kodu TF2 należy użyć tf.Variable zamiast v1.get_variable i użyć obiektów Pythona do zbierania i śledzenia zmiennych zamiast tf.compat.v1.variable_scope . Zazwyczaj będzie to jeden z:

Agreguj listy zmiennych (np. tf.Graph.get_collection(tf.GraphKeys.VARIABLES) ) z atrybutami .variables i .trainable_variables obiektów Layer , Module lub Model .

Klasy Layer i Model implementują kilka innych właściwości, które eliminują potrzebę kolekcji globalnych. Ich właściwość .losses może zastąpić użycie kolekcji tf.GraphKeys.LOSSES .

Przeczytaj przewodnik mapowania modeli , aby dowiedzieć się więcej na temat używania podkładek modelujących kod TF2 do osadzania istniejącego kodu opartego na get_variable i variable_scope wewnątrz Layers , Models i Modules . Umożliwi to wykonywanie przejść do przodu z włączoną funkcją szybkiego wykonywania bez większych przeróbek.

Dostosowanie się do innych zmian w zachowaniu

Jeśli sam przewodnik mapowania modelu jest niewystarczający, aby umożliwić przekazanie modelu do przodu z innymi zmianami zachowania, które mogą być bardziej szczegółowe, zobacz przewodnik dotyczący zachowań TF1.x i TF2 , aby dowiedzieć się o innych zmianach zachowania i sposobach dostosowania się do nich . Aby uzyskać szczegółowe informacje, sprawdź także tworzenie nowych warstw i modeli za pośrednictwem przewodnika po podklasach .

Walidacja wyników

Zobacz przewodnik po sprawdzaniu poprawności modelu , aby uzyskać proste narzędzia i wskazówki dotyczące sposobu (numerycznego) sprawdzenia, czy model zachowuje się poprawnie, gdy włączone jest szybkie wykonywanie. Może się to okazać szczególnie przydatne w połączeniu z przewodnikiem mapowania modelu .

Uaktualnij szkolenie, ocenę i kod importu/eksportu

Pętle szkoleniowe TF1.x zbudowane w stylu v1.Session tf.estimator.Estimator s i inne podejścia oparte na kolekcjach nie są kompatybilne z nowymi zachowaniami TF2. Ważne jest, aby przeprowadzić migrację całego kodu szkoleniowego TF1.x, ponieważ połączenie go z kodem TF2 może spowodować nieoczekiwane zachowania.

Aby to zrobić, możesz wybrać jedną z kilku strategii.

Podejście najwyższego poziomu polega na użyciu tf.keras . Funkcje wysokiego poziomu w Keras zarządzają wieloma szczegółami niskiego poziomu, które można łatwo przeoczyć, jeśli napiszesz własną pętlę treningową. Na przykład automatycznie zbierają straty regularyzacyjne i ustawiają argument training=True podczas wywoływania modelu.

Zapoznaj się z przewodnikiem dotyczącym migracji narzędzia Estimator , aby dowiedzieć się, jak przeprowadzić migrację kodu programu tf.estimator.Estimator w celu korzystania z standardowych i niestandardowych pętli szkoleniowych tf.keras .

Niestandardowe pętle treningowe zapewniają lepszą kontrolę nad modelem, na przykład śledzenie ciężarów poszczególnych warstw. Przeczytaj przewodnik dotyczący budowania pętli treningowych od podstaw , aby dowiedzieć się, jak używać tf.GradientTape do pobierania wag modeli i używania ich do aktualizacji modelu.

Konwertuj optymalizatory TF1.x na optymalizatory Keras

Optymalizatory w tf.compat.v1.train , takie jak optymalizator Adama i optymalizator gradientu , mają swoje odpowiedniki w tf.keras.optimizers .

Poniższa tabela podsumowuje sposób konwersji starszych optymalizatorów na ich odpowiedniki w Keras. Możesz bezpośrednio zastąpić wersję TF1.x wersją TF2, chyba że wymagane są dodatkowe kroki (takie jak aktualizacja domyślnej szybkości uczenia ).

Pamiętaj, że konwersja optymalizatorów może spowodować, że stare punkty kontrolne będą niekompatybilne .

TF1.x TF2 Dodatkowe kroki
`tf.v1.train.GradientDescentOptimizer` tf.keras.optimizers.SGD Nic
`tf.v1.train.MomentumOptimizer` tf.keras.optimizers.SGD Dołącz argument „pędu”.
`tf.v1.train.AdamOptimizer` tf.keras.optimizers.Adam Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`
`tf.v1.train.RMSPropOptimizer` tf.keras.optimizers.RMSprop Zmień nazwę argumentu „rozpad” na „rho”.
`tf.v1.train.AdadeltaOptimizer` tf.keras.optimizers.Adadelta Nic
`tf.v1.train.AdagradOptimizer` tf.keras.optimizers.Adagrad Nic
`tf.v1.train.FtrlOptimizer` tf.keras.optimizers.Ftrl Usuń argumenty „nazwa_akumulatora” i „nazwa_liniowa”.
`tf.contrib.AdamaxOptimizer` tf.keras.optimizers.Adamax Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`
`tf.contrib.Nadam` tf.keras.optimizers.Nadam Zmień nazwę argumentów `beta1` i `beta2` na `beta_1` i `beta_2`

Uaktualnij potoki wprowadzania danych

Istnieje wiele sposobów dostarczania danych do modelu tf.keras . Jako dane wejściowe przyjmą generatory Pythona i tablice Numpy.

Zalecanym sposobem dostarczania danych do modelu jest użycie pakietu tf.data , który zawiera zbiór klas o wysokiej wydajności do manipulowania danymi. dataset należące do tf.data są wydajne, wyraziste i dobrze integrują się z TF2.

Można je przekazać bezpośrednio do metody tf.keras.Model.fit .

model.fit(dataset, epochs=5)

Można je iterować bezpośrednio w standardowym Pythonie:

for example_batch, label_batch in dataset:
    break

Jeśli nadal używasz tf.queue , są one teraz obsługiwane tylko jako struktury danych, a nie jako potoki wejściowe.

Powinieneś także przeprowadzić migrację całego kodu przetwarzania wstępnego funkcji, który używa tf.feature_columns . Więcej szczegółów znajdziesz w przewodniku po migracji .

Zapisywanie i ładowanie modeli

TF2 wykorzystuje punkty kontrolne oparte na obiektach. Przeczytaj przewodnik dotyczący migracji punktów kontrolnych , aby dowiedzieć się więcej na temat migracji poza punktami kontrolnymi TF1.x opartymi na nazwach. Przeczytaj także przewodnik po punktach kontrolnych w podstawowej dokumentacji TensorFlow.

Nie ma znaczących problemów ze zgodnością zapisanych modeli. Przeczytaj przewodnik SavedModel , aby uzyskać więcej informacji na temat migracji SavedModel s z TF1.x do TF2. Ogólnie,

  • TF1.x zapisane_modele działają w TF2.
  • Zapisane modele TF2 działają w TF1.x, jeśli wszystkie operacje są obsługiwane.

Więcej informacji na temat pracy z obiektami Graph.pb i Graph.pbtxt można znaleźć w sekcji GraphDef w przewodniku migracji SavedModel .

(Opcjonalnie) Przeprowadź migrację poza symbolami tf.compat.v1

Moduł tf.compat.v1 zawiera kompletne API TF1.x z jego oryginalną semantyką.

Nawet po wykonaniu powyższych kroków i uzyskaniu kodu w pełni kompatybilnego ze wszystkimi zachowaniami TF2, prawdopodobnie będzie wiele wzmianek o api compat.v1 , które tak się składa, że ​​są kompatybilne z TF2. Powinieneś unikać używania starszych interfejsów API compat.v1 do każdego nowego kodu, który piszesz, chociaż będą one nadal działać z już napisanym kodem.

Możesz jednak zdecydować się na migrację istniejących zastosowań do innych niż starsze interfejsów API TF2. Dokumentacja poszczególnych symboli compat.v1 często wyjaśnia, jak przeprowadzić ich migrację do innych niż starsze interfejsów API TF2. Dodatkowo może w tym pomóc sekcja przewodnika mapowania modeli dotycząca przyrostowej migracji do idiomatycznych interfejsów API TF2 .

Zasoby i dalsza lektura

Jak wspomniano wcześniej, dobrą praktyką jest migracja całego kodu TF1.x do TF2. Przeczytaj przewodniki w sekcji Migracja do TF2 przewodnika TensorFlow, aby dowiedzieć się więcej.