Implement generative AI solutions →hardMultiple Choice

AI-102 Implement generative AI solutions Practice Question

Your team ships a generative assistant that calls a custom function to look up live order status. Users report that the assistant sometimes invents an order status instead of calling the function, and that when it does call the tool the arguments are occasionally malformed. You need to make tool invocation more reliable while keeping the existing model. What should you do?

⚠ Common exam trap

The trap here is assuming that a stronger model or a sterner system message will force tool use, when the decision is governed by tool_choice and the argument shape by the parameter schema.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Define the function with a clear name, description, and parameter schema, set tool_choice to require a tool call, and validate returned arguments before executing.

Reliable function calling comes from three things working together: descriptive tool metadata so the model understands when and how to call it, an explicit tool_choice that forces a call when the intent is known, and client-side validation of the returned arguments before execution. Penalties, larger models, and prompt-only pleading do not enforce tool invocation or argument correctness.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Define the function with a clear name, description, and parameter schema, set tool_choice to require a tool call, and validate returned arguments before executing.
Why this is correct
Function calling reliability depends on precise tool metadata and an explicit tool_choice setting. Requiring a tool call stops the model from answering from memory, and a well-described parameter schema reduces malformed arguments. Validating arguments before execution prevents bad data from reaching the backend, which addresses both reported symptoms without changing the model.
✗
Switch the deployment to a larger model and keep the existing function definitions unchanged.
Why it's wrong here
A larger model may follow instructions better, but vague tool descriptions and a permissive tool_choice still allow the model to skip the function or emit arguments that violate the schema. The root cause is tool specification quality, not raw model capability, so upgrading the deployment alone will not guarantee tool calls or valid arguments.
✗
Add the phrase "always call the function" to the system message and leave tool_choice at its default value.
Why it's wrong here
Prompt text is a soft instruction that the model can ignore, especially when it believes it already knows the answer. Leaving tool_choice at auto means the model decides whether to call a tool, so the invented-status behavior can persist. Argument validation is also absent, so malformed parameters would still reach the backend.
✗
Raise the frequency_penalty so the model is discouraged from repeating previously invented order statuses.
Why it's wrong here
Frequency penalty discourages repeated tokens within a response and has nothing to do with whether the model elects to call a function. The model may still answer from parametric memory, and malformed arguments remain unaddressed. This parameter changes surface wording rather than the decision to invoke a tool or the shape of its arguments.

Go deeper

AI-102 Implement generative AI solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question