Meridian Line's charter-desk assistant is a LangChain-style chain wrapped and logged as an MLflow pyfunc model without an explicit signature; MLflow inferred one from a quick local call. In staging, the Model Serving endpoint rejects real requests with a schema-validation error the notebook never showed. What is the most likely cause and correct fix?
Select an answer to reveal the explanation.
Short Explanation
The signature MLflow guesses is only as good as the example you gave it. If your local test call looked nothing like what the endpoint receives in production, log it again with a real example and let MLflow infer the correct shape from that.
Full Explanation
MLflow infers a signature from whatever input_example (or the first observed call) it is given at logging time. A quick local smoke test rarely matches the actual request shape Model Serving forwards — for a chat-style chain that is typically a messages list or a specific dict schema, not the ad-hoc string used in a notebook cell. The fix is to re-log with an input_example (or explicit ModelSignature) built from a realistic request, so the stored signature matches production traffic and validation passes. Disabling schema enforcement is not an available lever for this failure and, even where similar controls exist, papering over the mismatch invites silent bad requests rather than fixing the contract. There is no '@udf' mechanism that exempts a logged model from having a signature — Model Serving validates against whatever signature is stored, decorator or not, so this option is fabricated. Retraining the LLM addresses the wrong layer entirely: the mismatch is between the logged interface and the caller's payload shape, not the model's language output. Exam framing: a correct signature and a representative input_example are part of what 'log and register with MLflow correctly' means — this is graded separately from whether the chain itself works in a notebook.