Function Calling - How Does It Modify The Prompt?

I assume you mean that using the enum it’s less likely to hallucinate?

I meant more likely to hallucinate in my example. Because in my example, we’d want the model to not call a function. But if the context for the model to decide whether or not to call a function is nested inside the enum value list for a function parameter, (my guess is that) the model might pay less attention to that than when it was in the system prompt.

NB: This is just my empirically observation with current models’ behavior.

So you’re saying with an Enum[A,B,C] the model may be more likely to hallucinate and still call return_product with a product outside of the enum, versus the system prompt approach?

What about if the description field to the function had the instructions to only allow returns for existing products, and the prompt always listed the products a user had purchased. So basically the same instructions, just ordered differently.

When defining functions, I prefer to limit the description to four key elements:

  1. The function’s purpose
  2. Its functionality
  3. Required params
  4. Expected outputs

This approach:

  • Keeps function descriptions focused and specific
  • Avoids including procedural instructions or inter-function dependencies
  • Maintains clear separation between function definitions and broader system logic

I prefer handling procedural details and dependencies in the system message rather than in individual function descriptions.

… versus the system prompt approach?

Yes, that’s correct.

What about …

In my opinion, “only allow returns for existing products” is more like instruction to the model on when to call this function, as opposed to the description of the function itself. I’d second what @sps said above.


Purpose/functionality make sense, but why would you need to include required params and expected outputs in the description? Wouldn’t the argument schema itself take care of that?

Appreciate the discussion - very helpful.