-
Notifications
You must be signed in to change notification settings - Fork 898
Support Tool Calling with Llama 3.3 on Bedrock #1649
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
Comments
@tamir-alltrue-ai It seems like the tool is being registered to the model, and the model is trying to call it, but as it shows in the second screenshot and JSON snippet, the model is doing so through a regular text message containing JSON, rather than a special (The issue where I recommended overriding the schema generation mentioned “All other fields are disallowed and result in a hard API error.“, which is not the case here.) To debug this further, I'd like to see the complete HTTP response to the request where the model is supposed to explicitly pass tool calls, but is passing regular text instead. It's possible there's another property to indicate that PydanticAI should be interpreting the message as a tool call. Can you please add the following to the top of your code? import logfire
logfire.configure()
logfire.instrument_httpx(capture_all=True) Then, from the traces, I'd like to see the response JSON of the httpx trace that will be under |
Thanks for your response @DouweM Turns out that There is no instrumentation for from logfire.integrations.logging import LogfireLoggingHandler
logfire_handler = LogfireLoggingHandler()
logfire.configure(send_to_logfire="if-token-present", scrubbing=False, metrics=False)
basicConfig(handlers=[logfire_handler], level=DEBUG) I found this log for the response body to the POST request to made by botocore:
Or, parsed: {
"metrics": {
"latencyMs": 426
},
"output": {
"message": {
"content": [
{
"text": "{\"type\": \"function\", \"name\": \"roll_die\", \"parameters\": {}}"
}
],
"role": "assistant"
}
},
"stopReason": "end_turn",
"usage": {
"inputTokens": 242,
"outputTokens": 19,
"totalTokens": 261
}
} Again you can see that the output is serialized JSON for the function call. |
@DouweM I've looked into this a bit further, and I'm starting to think it's a limitation with bedrock. According to this:
As a result, I tried to use Mistral instead of Llama. I get this error from the bedrock API
It looks as if the tool is being invoked correctly, but then when the results are passed back into the model they are done so in a format bedrock doesn't expect. According to the Bedrock documentation, The tool result should be fed back to the model after it's invoked with the following format: {
"role": "user",
"content": [
{
"toolResult": {
"toolUseId": "tooluse_kZJMlvQmRJ6eAyJE5GIl7Q",
"content": [
{
"json": {
"song": "Elemental Hotel",
"artist": "8 Storey Hike"
}
}
]
}
}
]
} Is this something that I can fix by overriding the default |
@tamir-alltrue-ai We build the toolResult block here: pydantic-ai/pydantic_ai_slim/pydantic_ai/models/bedrock.py Lines 384 to 395 in dd22595
As you can see, the difference with your example is that we pass Can you try changing that bit from The tricky thing we're seeing here is that Bedrock runs many different models, and we only have one Bedrock model class that aims to work with all of them. So while this change may work for one model, it may break others. We may need to start implementing some feature flags inside the Bedrock model so we can switch behaviors based on the specific model used. |
Thanks @DouweM , Yeah I agree the challenge is that different models give different response types. The change you propose is definitely a breaking one - the tests start failing (
But the function is not called |
If supporting different models differently in bedrock becomes a new undertaking, I would strongly express my interest in this. Our company is trying hard to adopt PydanticAI but due to data-sharing concerns we need to stay within the AWS environment, and this is a big blocker for us from adoption pydantic-ai. My intuition is that treating bedrock as its own model (like OpenAI, Anthropic, etc) is not quite the right model. Rather, it's just a place where you can host models, like Anthropic and others. So I would kind of expect that using Anthropic on Bedrock would use the In any case - if there's some other hack I can try here in the meantime, or something I can do to help bring attention to this issue that it's put in your roadmap promptly, I'd love to do so! THanks for your help @DouweM |
my team and i were experimenting a bit, and this setup ended up working for us: response = client.converse(
modelId="us.meta.llama3-3-70b-instruct-v1:0",
messages=messages,
system=[{"text": system_prompt}],
inferenceConfig={
'maxTokens': 4096,
'temperature': 0,
'topP': 1,
},
toolConfig={
"tools": tools,
"toolChoice": {
"auto": {}
}
},
) @tamir-alltrue-ai feel free to give it a shot — let me know how it goes! |
Uh oh!
There was an error while loading. Please reload this page.
Question
Description
I'm using the BedrockConverseModel to use models hosted on Bedrock. When working with Llama-3.3-70B, tool calls do not work.
This seems to be a similar issue to #1623, and following @DouweM advice I've attempted to create a custom
GenerateToolJsonSchema
to match Llama 3.3's schema (which is the same as llama 3.1) but found it confusing. I'm hoping someone with more knowledge on the what's going on under the hood can help me out here. Considering that Llama3 is one of the top 5 most popular Llms, I hope others would find this useful too.Code snippet
Below is an example showing that tools work fine when working with Anthropic on Bedrock, but not Llama. This is how I convinced myself it's not a problem with bedrock specifically or my prompt, but rather a difference in the underlying model
Any advice, code snippets or help on resolving this would be super appreciated. thanks.
Logfire output
When calling anthropic, you can see that the tool is registered and called
Full conversation json
But when we call with Llama, the tool does not seem to be correctly registered and it is not invoked:
Full conversation history
Configuration
Relevant libraries
Python version
3.11.6
Additional Context
No response
The text was updated successfully, but these errors were encountered: