Biblioteka zadań TensorFlow Lite zapewnia wstępnie zbudowane interfejsy API natywne/Android/iOS na tej samej infrastrukturze, która abstrakcyjnie TensorFlow. Możesz rozszerzyć infrastrukturę interfejsu API zadań, aby tworzyć niestandardowe interfejsy API, jeśli Twój model nie jest obsługiwany przez istniejące biblioteki zadań.
Przegląd
Infrastruktura Task API ma strukturę dwuwarstwową: dolna warstwa C++ zawierająca natywne środowisko wykonawcze TFLite i górna warstwa Java/ObjC, która komunikuje się z warstwą C++ poprzez JNI lub natywne opakowanie.
Implementacja całej logiki TensorFlow tylko w C++ minimalizuje koszty, maksymalizuje wydajność wnioskowania i upraszcza ogólny przepływ pracy na różnych platformach.
Aby utworzyć klasę Task, rozszerz BaseTaskApi, aby zapewnić logikę konwersji pomiędzy interfejsem modelu TFLite a interfejsem Task API, a następnie użyj narzędzi Java/ObjC do utworzenia odpowiednich interfejsów API. Po ukryciu wszystkich szczegółów TensorFlow możesz wdrożyć model TFLite w swoich aplikacjach bez wiedzy o uczeniu maszynowym.
TensorFlow Lite zapewnia kilka gotowych interfejsów API dla najpopularniejszych zadań związanych z wizją i NLP . Korzystając z infrastruktury Task API, możesz tworzyć własne interfejsy API do innych zadań.
Zbuduj swój własny interfejs API za pomocą infrastruktury Task API
API C++
Wszystkie szczegóły TFLite są zaimplementowane w natywnym API. Utwórz obiekt API korzystając z jednej z funkcji fabrycznych i uzyskaj wyniki modelu wywołując funkcje zdefiniowane w interfejsie.
Przykładowe użycie
Oto przykład użycia C++ BertQuestionAnswerer
dla MobileBert .
char kBertModelPath[] = "path/to/model.tflite";
// Create the API from a model file
std::unique_ptr<BertQuestionAnswerer> question_answerer =
BertQuestionAnswerer::CreateFromFile(kBertModelPath);
char kContext[] = ...; // context of a question to be answered
char kQuestion[] = ...; // question to be answered
// ask a question
std::vector<QaAnswer> answers = question_answerer.Answer(kContext, kQuestion);
// answers[0].text is the best answer
Budowanie API
Aby zbudować obiekt API, należy podać następujące informacje, rozszerzając BaseTaskApi
Określ wejście/wyjście interfejsu API — Twój interfejs API powinien udostępniać podobne dane wejściowe/wyjściowe na różnych platformach. np.
BertQuestionAnswerer
przyjmuje dwa ciągi znaków(std::string& context, std::string& question)
jako dane wejściowe i wyprowadza wektor możliwych odpowiedzi i prawdopodobieństw jakostd::vector<QaAnswer>
. Odbywa się to poprzez określenie odpowiednich typów w parametrze szablonuBaseTaskApi
. Po określeniu parametrów szablonu funkcjaBaseTaskApi::Infer
będzie miała prawidłowe typy wejść/wyjść. Ta funkcja może być wywoływana bezpośrednio przez klientów API, ale dobrą praktyką jest zawinięcie jej w funkcję specyficzną dla modelu, w tym przypadkuBertQuestionAnswerer::Answer
.class BertQuestionAnswerer : public BaseTaskApi< std::vector<QaAnswer>, // OutputType const std::string&, const std::string& // InputTypes > { // Model specific function delegating calls to BaseTaskApi::Infer std::vector<QaAnswer> Answer(const std::string& context, const std::string& question) { return Infer(context, question).value(); } }
Zapewnij logikę konwersji między interfejsem API we/wy a tensorem wejścia/wyjścia modelu — po określeniu typów danych wejściowych i wyjściowych podklasy muszą również implementować funkcje typu
BaseTaskApi::Preprocess
iBaseTaskApi::Postprocess
. Obie funkcje zapewniają wejścia i wyjścia z TFLiteFlatBuffer
. Podklasa odpowiedzialna jest za przypisywanie wartości z API I/O do tensorów I/O. Zobacz pełny przykład implementacji wBertQuestionAnswerer
.class BertQuestionAnswerer : public BaseTaskApi< std::vector<QaAnswer>, // OutputType const std::string&, const std::string& // InputTypes > { // Convert API input into tensors absl::Status BertQuestionAnswerer::Preprocess( const std::vector<TfLiteTensor*>& input_tensors, // input tensors of the model const std::string& context, const std::string& query // InputType of the API ) { // Perform tokenization on input strings ... // Populate IDs, Masks and SegmentIDs to corresponding input tensors PopulateTensor(input_ids, input_tensors[0]); PopulateTensor(input_mask, input_tensors[1]); PopulateTensor(segment_ids, input_tensors[2]); return absl::OkStatus(); } // Convert output tensors into API output StatusOr<std::vector<QaAnswer>> // OutputType BertQuestionAnswerer::Postprocess( const std::vector<const TfLiteTensor*>& output_tensors, // output tensors of the model ) { // Get start/end logits of prediction result from output tensors std::vector<float> end_logits; std::vector<float> start_logits; // output_tensors[0]: end_logits FLOAT[1, 384] PopulateVector(output_tensors[0], &end_logits); // output_tensors[1]: start_logits FLOAT[1, 384] PopulateVector(output_tensors[1], &start_logits); ... std::vector<QaAnswer::Pos> orig_results; // Look up the indices from vocabulary file and build results ... return orig_results; } }
Utwórz fabryczne funkcje API — do zainicjowania
tflite::Interpreter
potrzebny jest plik modelu iOpResolver
.TaskAPIFactory
udostępnia funkcje narzędziowe do tworzenia instancji BaseTaskApi.Należy także dostarczyć wszelkie pliki powiązane z modelem. np.
BertQuestionAnswerer
może również mieć dodatkowy plik ze słownictwem swojego tokenizera.class BertQuestionAnswerer : public BaseTaskApi< std::vector<QaAnswer>, // OutputType const std::string&, const std::string& // InputTypes > { // Factory function to create the API instance StatusOr<std::unique_ptr<QuestionAnswerer>> BertQuestionAnswerer::CreateBertQuestionAnswerer( const std::string& path_to_model, // model to passed to TaskApiFactory const std::string& path_to_vocab // additional model specific files ) { // Creates an API object by calling one of the utils from TaskAPIFactory std::unique_ptr<BertQuestionAnswerer> api_to_init; ASSIGN_OR_RETURN( api_to_init, core::TaskAPIFactory::CreateFromFile<BertQuestionAnswerer>( path_to_model, absl::make_unique<tflite::ops::builtin::BuiltinOpResolver>(), kNumLiteThreads)); // Perform additional model specific initializations // In this case building a vocabulary vector from the vocab file. api_to_init->InitializeVocab(path_to_vocab); return api_to_init; } }
API Androida
Twórz interfejsy API systemu Android, definiując interfejs Java/Kotlin i delegując logikę do warstwy C++ za pośrednictwem JNI. Interfejs API systemu Android wymaga najpierw zbudowania natywnego interfejsu API.
Przykładowe użycie
Oto przykład użycia Java BertQuestionAnswerer
dla MobileBert .
String BERT_MODEL_FILE = "path/to/model.tflite";
String VOCAB_FILE = "path/to/vocab.txt";
// Create the API from a model file and vocabulary file
BertQuestionAnswerer bertQuestionAnswerer =
BertQuestionAnswerer.createBertQuestionAnswerer(
ApplicationProvider.getApplicationContext(), BERT_MODEL_FILE, VOCAB_FILE);
String CONTEXT = ...; // context of a question to be answered
String QUESTION = ...; // question to be answered
// ask a question
List<QaAnswer> answers = bertQuestionAnswerer.answer(CONTEXT, QUESTION);
// answers.get(0).text is the best answer
Budowanie API
Podobnie jak w przypadku natywnych interfejsów API, aby zbudować obiekt API, klient musi podać następujące informacje, rozszerzając BaseTaskApi
, który zapewnia obsługę JNI dla wszystkich interfejsów API zadań Java.
Określ wejście/wyjście API — zwykle odzwierciedla to interfejsy natywne. np.
BertQuestionAnswerer
przyjmuje(String context, String question)
jako dane wejściowe i wynikiList<QaAnswer>
. Implementacja wywołuje prywatną funkcję natywną o podobnym podpisie, z tą różnicą, że ma dodatkowy parametrlong nativeHandle
, który jest wskaźnikiem zwróconym z C++.class BertQuestionAnswerer extends BaseTaskApi { public List<QaAnswer> answer(String context, String question) { return answerNative(getNativeHandle(), context, question); } private static native List<QaAnswer> answerNative( long nativeHandle, // C++ pointer String context, String question // API I/O ); }
Utwórz funkcje fabryczne interfejsu API — odzwierciedla to również natywne funkcje fabryczne, z tą różnicą, że funkcje fabryczne systemu Android również muszą pobierać
Context
w celu uzyskania dostępu do plików. Implementacja wywołuje jedno z narzędzi wTaskJniUtils
w celu zbudowania odpowiedniego obiektu API C++ i przekazania jego wskaźnika do konstruktoraBaseTaskApi
.class BertQuestionAnswerer extends BaseTaskApi { private static final String BERT_QUESTION_ANSWERER_NATIVE_LIBNAME = "bert_question_answerer_jni"; // Extending super constructor by providing the // native handle(pointer of corresponding C++ API object) private BertQuestionAnswerer(long nativeHandle) { super(nativeHandle); } public static BertQuestionAnswerer createBertQuestionAnswerer( Context context, // Accessing Android files String pathToModel, String pathToVocab) { return new BertQuestionAnswerer( // The util first try loads the JNI module with name // BERT_QUESTION_ANSWERER_NATIVE_LIBNAME, then opens two files, // converts them into ByteBuffer, finally ::initJniWithBertByteBuffers // is called with the buffer for a C++ API object pointer TaskJniUtils.createHandleWithMultipleAssetFilesFromLibrary( context, BertQuestionAnswerer::initJniWithBertByteBuffers, BERT_QUESTION_ANSWERER_NATIVE_LIBNAME, pathToModel, pathToVocab)); } // modelBuffers[0] is tflite model file buffer, and modelBuffers[1] is vocab file buffer. // returns C++ API object pointer casted to long private static native long initJniWithBertByteBuffers(ByteBuffer... modelBuffers); }
Zaimplementuj moduł JNI dla funkcji natywnych — wszystkie natywne metody Java są implementowane poprzez wywołanie odpowiedniej funkcji natywnej z modułu JNI. Funkcje fabryczne utworzą natywny obiekt API i zwrócą jego wskaźnik jako typ długi do Java. W późniejszych wywołaniach API języka Java wskaźnik typu długiego jest przekazywany z powrotem do JNI i rzutowany z powrotem na natywny obiekt API. Wyniki natywnego interfejsu API są następnie konwertowane z powrotem na wyniki Java.
Na przykład w ten sposób zaimplementowano bert_question_answerer_jni .
// Implements BertQuestionAnswerer::initJniWithBertByteBuffers extern "C" JNIEXPORT jlong JNICALL Java_org_tensorflow_lite_task_text_qa_BertQuestionAnswerer_initJniWithBertByteBuffers( JNIEnv* env, jclass thiz, jobjectArray model_buffers) { // Convert Java ByteBuffer object into a buffer that can be read by native factory functions absl::string_view model = GetMappedFileBuffer(env, env->GetObjectArrayElement(model_buffers, 0)); // Creates the native API object absl::StatusOr<std::unique_ptr<QuestionAnswerer>> status = BertQuestionAnswerer::CreateFromBuffer( model.data(), model.size()); if (status.ok()) { // converts the object pointer to jlong and return to Java. return reinterpret_cast<jlong>(status->release()); } else { return kInvalidPointer; } } // Implements BertQuestionAnswerer::answerNative extern "C" JNIEXPORT jobject JNICALL Java_org_tensorflow_lite_task_text_qa_BertQuestionAnswerer_answerNative( JNIEnv* env, jclass thiz, jlong native_handle, jstring context, jstring question) { // Convert long to native API object pointer QuestionAnswerer* question_answerer = reinterpret_cast<QuestionAnswerer*>(native_handle); // Calls the native API std::vector<QaAnswer> results = question_answerer->Answer(JStringToString(env, context), JStringToString(env, question)); // Converts native result(std::vector<QaAnswer>) to Java result(List<QaAnswerer>) jclass qa_answer_class = env->FindClass("org/tensorflow/lite/task/text/qa/QaAnswer"); jmethodID qa_answer_ctor = env->GetMethodID(qa_answer_class, "<init>", "(Ljava/lang/String;IIF)V"); return ConvertVectorToArrayList<QaAnswer>( env, results, [env, qa_answer_class, qa_answer_ctor](const QaAnswer& ans) { jstring text = env->NewStringUTF(ans.text.data()); jobject qa_answer = env->NewObject(qa_answer_class, qa_answer_ctor, text, ans.pos.start, ans.pos.end, ans.pos.logit); env->DeleteLocalRef(text); return qa_answer; }); } // Implements BaseTaskApi::deinitJni by delete the native object extern "C" JNIEXPORT void JNICALL Java_task_core_BaseTaskApi_deinitJni( JNIEnv* env, jobject thiz, jlong native_handle) { delete reinterpret_cast<QuestionAnswerer*>(native_handle); }
API iOS
Twórz interfejsy API systemu iOS, zawijając natywny obiekt API w obiekt API ObjC. Utworzonego obiektu API można używać w ObjC lub Swift. Interfejs API systemu iOS wymaga najpierw zbudowania natywnego interfejsu API.
Przykładowe użycie
Oto przykład użycia ObjC TFLBertQuestionAnswerer
dla MobileBert w Swift.
static let mobileBertModelPath = "path/to/model.tflite";
// Create the API from a model file and vocabulary file
let mobileBertAnswerer = TFLBertQuestionAnswerer.mobilebertQuestionAnswerer(
modelPath: mobileBertModelPath)
static let context = ...; // context of a question to be answered
static let question = ...; // question to be answered
// ask a question
let answers = mobileBertAnswerer.answer(
context: TFLBertQuestionAnswererTest.context, question: TFLBertQuestionAnswererTest.question)
// answers.[0].text is the best answer
Budowanie API
iOS API to proste opakowanie ObjC na bazie natywnego API. Zbuduj interfejs API, wykonując poniższe kroki:
Zdefiniuj opakowanie ObjC — zdefiniuj klasę ObjC i deleguj implementacje do odpowiedniego natywnego obiektu API. Należy pamiętać, że natywne zależności mogą pojawić się tylko w pliku .mm ze względu na niemożność współpracy Swifta z C++.
- plik .h
@interface TFLBertQuestionAnswerer : NSObject // Delegate calls to the native BertQuestionAnswerer::CreateBertQuestionAnswerer + (instancetype)mobilebertQuestionAnswererWithModelPath:(NSString*)modelPath vocabPath:(NSString*)vocabPath NS_SWIFT_NAME(mobilebertQuestionAnswerer(modelPath:vocabPath:)); // Delegate calls to the native BertQuestionAnswerer::Answer - (NSArray<TFLQAAnswer*>*)answerWithContext:(NSString*)context question:(NSString*)question NS_SWIFT_NAME(answer(context:question:)); }
- plik .mm
using BertQuestionAnswererCPP = ::tflite::task::text::BertQuestionAnswerer; @implementation TFLBertQuestionAnswerer { // define an iVar for the native API object std::unique_ptr<QuestionAnswererCPP> _bertQuestionAnswerwer; } // Initialize the native API object + (instancetype)mobilebertQuestionAnswererWithModelPath:(NSString *)modelPath vocabPath:(NSString *)vocabPath { absl::StatusOr<std::unique_ptr<QuestionAnswererCPP>> cQuestionAnswerer = BertQuestionAnswererCPP::CreateBertQuestionAnswerer(MakeString(modelPath), MakeString(vocabPath)); _GTMDevAssert(cQuestionAnswerer.ok(), @"Failed to create BertQuestionAnswerer"); return [[TFLBertQuestionAnswerer alloc] initWithQuestionAnswerer:std::move(cQuestionAnswerer.value())]; } // Calls the native API and converts C++ results into ObjC results - (NSArray<TFLQAAnswer *> *)answerWithContext:(NSString *)context question:(NSString *)question { std::vector<QaAnswerCPP> results = _bertQuestionAnswerwer->Answer(MakeString(context), MakeString(question)); return [self arrayFromVector:results]; } }
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2024-06-28 UTC.