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.
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?