TensorFlow Biblioteca de tareas Lite proporciona prediseñadas nativos API / Android / iOS en la parte superior de la misma infraestructura que abstrae TensorFlow. Puede ampliar la infraestructura de la API de tareas para crear API personalizadas si su modelo no es compatible con las bibliotecas de tareas existentes.
Visión general
La infraestructura de la API de tareas tiene una estructura de dos capas: la capa inferior de C ++ que encapsula el tiempo de ejecución nativo de TFLite y la capa superior de Java / ObjC que se comunica con la capa de C ++ a través de JNI o envoltorio nativo.
La implementación de toda la lógica de TensorFlow solo en C ++ minimiza el costo, maximiza el rendimiento de la inferencia y simplifica el flujo de trabajo general en todas las plataformas.
Para crear una clase de tareas, extender los BaseTaskApi para proporcionar lógica de conversión entre la interfaz modelo TFLite y la interfaz API de tareas, a continuación, utilizar los Java / ObjC utilidades para crear APIs correspondientes. Con todos los detalles de TensorFlow ocultos, puede implementar el modelo TFLite en sus aplicaciones sin ningún conocimiento de aprendizaje automático.
TensorFlow Lite proporciona algunas API prediseñados para la mayoría de los populares tareas de visión y PNL . Puede crear sus propias API para otras tareas utilizando la infraestructura de la API de tareas.
Cree su propia API con la API de tareas infra
API de C ++
Todos los detalles de TFLite se implementan en la API nativa. Cree un objeto API utilizando una de las funciones de fábrica y obtenga resultados del modelo llamando a las funciones definidas en la interfaz.
Uso de muestra
Aquí hay un ejemplo usando el C ++ BertQuestionAnswerer
para 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
Construyendo la API
Para construir un objeto de la API, debe proporcionar la siguiente información al extender BaseTaskApi
Determinar la API de E / S - Su API debe exponer de entrada / salida similar a través de diferentes plataformas. por ejemplo
BertQuestionAnswerer
toma dos cadenas(std::string& context, std::string& question)
como entrada y genera un vector de respuesta posible y probabilidades comostd::vector<QaAnswer>
. Esto se realiza mediante la especificación de los tipos correspondientes enBaseTaskApi
's parámetro de plantilla . Con los parámetros de plantilla especificado, elBaseTaskApi::Infer
función tendrá los tipos de entradas / salidas correctas. Esta función se puede llamar directamente por clientes de la API, pero es una práctica buena para envolverlo dentro de una función de modelo específico, en este caso,BertQuestionAnswerer::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(); } }
Proporcionar lógica de conversión entre la API de E / S y tensor de entrada / salida del modelo - Con tipos de entrada y de salida especificados, las subclases también necesitan para implementar las funciones mecanografiadas
BaseTaskApi::Preprocess
yBaseTaskApi::Postprocess
. Las dos funciones proporcionan entradas y salidas de la TFLiteFlatBuffer
. La subclase es responsable de asignar valores de la E / S API a los tensores de E / S. Vea el ejemplo de implementación integralBertQuestionAnswerer
.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; } }
Crear funciones de fábrica de la API - Un archivo de modelo y un
OpResolver
son necesarios para inicializar eltflite::Interpreter
.TaskAPIFactory
ofrece funciones de utilidad para crear instancias BaseTaskApi.También debe proporcionar los archivos asociados con el modelo. por ejemplo,
BertQuestionAnswerer
también puede tener un archivo adicional para el vocabulario de su tokenizer.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 de Android
Cree API de Android definiendo la interfaz Java / Kotlin y delegando la lógica a la capa C ++ a través de JNI. La API de Android requiere que la API nativa se compile primero.
Uso de muestra
Aquí hay un ejemplo usando Java BertQuestionAnswerer
para 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
Construyendo la API
De manera similar a las API nativas, para construir un objeto API, las necesidades de los clientes para proporcionar la siguiente información al extender BaseTaskApi
, que proporciona manejos JNI para todas las tareas APIs Java.
Determinar la API de E / S - esto generalmente espejos las interfaces nativas. por ejemplo
BertQuestionAnswerer
toma(String context, String question)
como entrada y salida aList<QaAnswer>
. La aplicación llama a una función nativa privado con firma similar, excepto que tiene un parámetro adicionallong nativeHandle
, que es el puntero de regresar de 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 ); }
Crear funciones de fábrica de la API - Este también espejos funciones nativas de fábrica, excepto las funciones de fábrica Android también necesitan tomar
Context
de acceso a archivos. La aplicación llama a una de las utilidades enTaskJniUtils
para construir el correspondiente objeto ++ API C y pasar el puntero hasta elBaseTaskApi
constructor.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); }
Implementar el módulo de JNI para las funciones nativas - Todos los métodos nativos de Java se implementan llamando a una función nativa correspondiente desde el módulo de JNI. Las funciones de fábrica crearían un objeto API nativo y devolverían su puntero como un tipo largo a Java. En llamadas posteriores a la API de Java, el puntero de tipo largo se devuelve a JNI y se devuelve al objeto de la API nativa. A continuación, los resultados de la API nativa se vuelven a convertir en resultados de Java.
Por ejemplo, esta es la forma bert_question_answerer_jni se implementa.
// 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 de iOS
Cree API de iOS envolviendo un objeto de API nativo en un objeto de API de ObjC. El objeto API creado se puede utilizar en ObjC o Swift. La API de iOS requiere que la API nativa se compile primero.
Uso de muestra
Aquí hay un ejemplo usando ObjC TFLBertQuestionAnswerer
para MobileBert en 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
Construyendo la API
La API de iOS es un contenedor de ObjC simple sobre la API nativa. Cree la API siguiendo los pasos a continuación:
Definir la envoltura ObjC - Definir una clase ObjC y delegar las implementaciones en el correspondiente objeto API nativa. Tenga en cuenta que las dependencias nativas solo pueden aparecer en un archivo .mm debido a la incapacidad de Swift para interoperar con C ++.
- archivo .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:)); }
- archivo .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]; } }
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2021-11-05 UTC.