-
Notifications
You must be signed in to change notification settings - Fork 1.6k
configuring defaultOptions can cause defaultToolCallbacks failure #3392
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
It is not clear to me what is failing from the code you provided. Can you please clarify? |
@markpollack If I configure the default options, like this .defaultOptions(ChatOptions.builder()
.model(DeepSeekApi.ChatModel.DEEPSEEK_CHAT.getValue())
.temperature(0.7)
.build()) my tool will not work, If I Delete the default options, tool is work~ @Service
public class ToolService {
@Tool(description = "query weather")
public String queryWeather(@ToolParam(description = "Weather date") String date) {
System.out.println("weather date is: " + date);
return date + " The weather is sunny";
}
}
@Configuration
public class ToolConfig {
@Bean
public ToolCallbackProvider toolServiceMethodToolCallback(ToolService toolService) {
return MethodToolCallbackProvider.builder().toolObjects(toolService).build();
}
} |
Hi, I've encountered the same issue, it might be the same reason, can you confirm? Solution: Use other ChatOptions that support Tool Calling, ToolCallingChatOptions.builder().model(model).build() |
Hi @jimmyqin , this may be a bug. The issue occurs because when the ChatClient tries to generate a ChatClientRequest based on the DefaultChatClientRequestSpec, it overlooks the scenario where "ChatOptions is of type DefaultChatOptions, but the tool call information is also declared in the DefaultChatClientRequestSpec." I've already pushed a PR to fix this: #3417 |
thanks @sunyuhan1998 I looked through the source code and found that the optional configuration used must be of type ToolCallingChatOptions for the tool to work. Final code or wait for the @sunyuhan1998 PR @Bean("chatClient")
public ChatClient chatClient(ChatClient.Builder chatClientBuilder, ToolCallbackProvider[] toolCallbackProviders, DeepSeekChatProperties deepSeekChatProperties) {
MessageWindowChatMemory chatMemory = MessageWindowChatMemory.builder()
.chatMemoryRepository(chatMemoryRepository)
.maxMessages(100)
.build();
DeepSeekChatOptions options = deepSeekChatProperties.getOptions().copy();
options.setModel(DeepSeekApi.ChatModel.DEEPSEEK_CHAT.getValue());
return chatClientBuilder
.defaultOptions(options)
.defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build(), new SimpleLoggerAdvisor())
.defaultSystem(systemResource)
.defaultToolCallbacks(toolCallbackProviders)
.build();
}
@Bean("thinkChatClient")
public ChatClient thinkChatClient(ChatClient.Builder chatClientBuilder, ToolCallbackProvider[] toolCallbackProviders, DeepSeekChatProperties deepSeekChatProperties) {
MessageWindowChatMemory chatMemory = MessageWindowChatMemory.builder()
.chatMemoryRepository(chatMemoryRepository)
.maxMessages(100)
.build();
DeepSeekChatOptions options = deepSeekChatProperties.getOptions().copy();
options.setModel(DeepSeekApi.ChatModel.DEEPSEEK_REASONER.getValue());
return chatClientBuilder
.defaultOptions(options)
.defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build(), new SimpleLoggerAdvisor())
.defaultSystem(systemResource)
.defaultToolCallbacks(toolCallbackProviders)
.build();
} |
Bug description
When building defaultOptions for ChatClient, the defaultToolCallbacks will fail, When calling AI chat, it will not trigger tool calls. Deleting the defaultOptions configuration may trigger tool calls when conversing with AI again
Environment
Spring AI 1.0.0, Springboot 3.5.0, Jdk21
Steps to reproduce
Expected behavior
I want to configure two models and switch between different chatClient by considering whether to switch front-end or not
Minimal Complete Reproducible example
Please provide a failing test or a minimal complete verifiable example that reproduces the issue.
Bug reports that are reproducible will take priority in resolution over reports that are not reproducible.
The text was updated successfully, but these errors were encountered: