-
Notifications
You must be signed in to change notification settings - Fork 15.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mistral: read tool calls from AIMessage #20554
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
@@ -216,8 +247,15 @@ def _convert_message_to_mistral_chat_message( | |||
if _id := tc.get("id"): | |||
chunk["id"] = _id | |||
tool_calls.append(chunk) | |||
elif message.tool_calls or message.invalid_tool_calls: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be prioritized over additional_kwargs? The latter should be the source of truth if swapping providers etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to either. I actually implemented it that way first, but it introduces small issues with casting to/from Mistral dicts, since the additional_kwargs contain (1) information on order of tool calls (we lose that with the separation into valid and invalid tool call lists), and (2) JSON formatting, since we parse and then dumps the args. Our unit tests maintain that we can go back/forth so I wasn't sure if we wanted to lose that. These are small issues; if we think there's a compensating benefit to prioritizing .tool_calls then happy to change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yeah if we have a provider that (1) formats tool_calls into additional_kwargs, and (2) does not use OpenAI-style formatting then this will break. updated this. see changes to unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@efriis see above - is it OK to lose the behavior maintained in unit tests, in which applying _convert_message_to_mistral_chat_message
and _convert_mistral_chat_message_to_message
returns the original message identically?
Co-authored-by: Eugene Yurtsev <[email protected]>
No description provided.