Ta strona została przetłumaczona przez Cloud Translation API.

Zbuduj własny interfejs API zadań

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ń.

Rysunek 1. Wstępnie zbudowane interfejsy API 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

Rysunek 2. Natywne API zadań

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 jako std::vector<QaAnswer> . Odbywa się to poprzez określenie odpowiednich typów w parametrze szablonu BaseTaskApi . Po określeniu parametrów szablonu funkcja BaseTaskApi::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 przypadku 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();
  }
}
```

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 i BaseTaskApi::Postprocess . Obie funkcje zapewniają wejścia i wyjścia z TFLite FlatBuffer . Podklasa odpowiedzialna jest za przypisywanie wartości z API I/O do tensorów I/O. Zobacz pełny przykład implementacji w BertQuestionAnswerer .

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 i OpResolver . 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

Rysunek 3. API zadań systemu Android

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 wyniki List<QaAnswer> . Implementacja wywołuje prywatną funkcję natywną o podobnym podpisie, z tą różnicą, że ma dodatkowy parametr long 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 w TaskJniUtils w celu zbudowania odpowiedniego obiektu API C++ i przekazania jego wskaźnika do konstruktora BaseTaskApi .

  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

Rysunek 4. API zadań iOS

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];
  }
}