Databricks Certified Generative AI Engineer Associate 問題集

正解: A

正解の理由
Model Serving に独自の Python コードを置く頁と、MLflow のモデルの頁は、どちらもデプロイの前の注記で、モデルがサービングできるかを確かめておくとよいと書き、その方法として mlflow.models.predict を挙げている。pyfunc は前処理・推論・後処理を任意の Python で書けるぶん、コードの誤りや依存の抜けが、エンドポイントを作るまで表に出にくい。エンドポイントはモデルからコンテナを組んでから動き出すので、そこで失敗すると、直して作り直すまでの待ちが大きい。記録したモデルを先にこの関数で呼び、サービングできる形かを確かめるのが案内の意図である。

違う選択肢
「mlflow.evaluate に評価データを渡し、指標が出るかを確かめる」… mlflow.evaluate は、評価データに対する答えの質を指標で測るためのものである。文書がデプロイ前のサービングの確認として挙げているものではなく、指標が出ても、エンドポイントのコンテナで動くかは別の問題として残る。
「mlflow.pyfunc.get_model_dependencies で依存を取り出して確かめる」… この関数は、記録したモデルの依存のファイルを取り出してその場所を返すもので、%pip install でノートブックの環境をモデルに合わせるときに使う。環境をそろえる助けにはなるが、サービングできるかの検証として案内されているのは mlflow.models.predict である。
「mlflow.pyfunc.spark_udf で UDF にし、表にかけて確かめる」… spark_udf は、モデルを Spark の UDF にして、表全体のバッチ推論やストリーミングの推論に使う形である。Spark の上で表にかけて動くことと、REST のエンドポイントとして置けることは別で、文書がデプロイの前の検証として挙げているものではない。

押さえどころ
記録のあとの流れは、記録する、mlflow.models.predict で確かめる、Unity Catalog に登録する、Model Serving のエンドポイントに置く、の順になる。置いたあとに失敗したときは、起動の段階はコンテナのビルドログ、推論の段階はモデルサーバーのログで調べる（どちらもエンドポイントの画面の Logs タブから見られる）。