-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat(spring-ai-bedrock-converse): Introduce BedrockProxyChatOptions #1760
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
base: main
Are you sure you want to change the base?
feat(spring-ai-bedrock-converse): Introduce BedrockProxyChatOptions #1760
Conversation
…or more flexible chat configuration - Add new BedrockProxyChatOptions class to replace FunctionCallingOptions - Create BedrockProxyChatOptionsBuilder for fluent configuration - Update BedrockProxyChatModel and related classes to use new options - Add support for additional model-specific parameters via 'additional' map - Improve options merging and handling of chat configuration
* @author Christian Tzolov | ||
* @since 1.0.0 | ||
*/ | ||
public class BedrockProxyChatOptions implements FunctionCallingOptions { |
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.
Any reason why BedrockProxyChatOptions
can not implement ChatOptions
here as I think we got all of the ChatOptions as well?
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.
FunctionCallingOptions implements ChatOptions already
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.
Got it. I got deceived by the explicit declaration of ChatOptions in some of the model option classes. I just pushed a minor PR to fix this: #1762
* @author Christian Tzolov | ||
* @since 1.0.0 | ||
*/ | ||
public class BedrockProxyChatOptions implements FunctionCallingOptions { |
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.
Not specific to this PR, but, do you think it would be good to have a DefaultFunctionCallingOptions
as the default implementation for FunctionCallingOptions
so that all the Model Chat options can extend? or, any reason why we didn't have the default implementation at the first place?
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.
We already have something like this called PortableFunctionCallingOptions
, but it needs some cleaning regarding the Builder/Object relation ship there.
I started by extending it but then for the sake of the flexibility for the draft I've copied its content.
IMO Before merging this PR we would likely revert to the PortableFunctionCallingOptions parent, unless there are some constrains.
@tzolov still relevant? |
Yes it is. But perhaps we can move it for after the GA |
Related to #1758