An engineer finishes testing the charter-desk RAG chain in a notebook and wants to log it with MLflow so it can later be registered and served. Which practice ensures the logged model can be deployed reliably to a Model Serving endpoint without manual patching?
Select an answer to reveal the explanation.
Short Explanation
Logging a notebook file is like framing the recipe card instead of packaging the meal — Model Serving can't cook from that. Logging with the right MLflow flavor plus a signature and pinned dependencies is what hands the endpoint something it can actually load and run.
Full Explanation
A model that is going to be deployed to Model Serving must be logged through MLflow using a model flavor that matches how the chain is built (for example, the LangChain flavor, or a custom pyfunc flavor for a hand-assembled chain), with a model signature describing expected inputs and outputs and its Python package dependencies captured so the serving environment can reconstruct an identical runtime. That combination is what lets the endpoint load and invoke the model without hand-editing anything. Logging the notebook file as a generic artifact captures source code for reference but does not produce anything MLflow or Model Serving know how to load and execute as a model — it is documentation, not a deployable artifact. Registering a raw notebook path directly to Unity Catalog skips MLflow's model packaging step entirely; Unity Catalog model registration expects an MLflow-logged model, not an arbitrary file path. Logging only a single run's output text captures one example response, not the model itself, and is useless for redeployment or versioning. For the exam, remember that the deployable unit in this ecosystem is an MLflow-logged model with a flavor, signature, and dependency spec — that is what gets registered to Unity Catalog and then served.