-
Notifications
You must be signed in to change notification settings - Fork 956
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
Support for registering Supplier functions in addition to Function interfaces for LLM function calling #1277
Comments
Assuming the FunctionCallbackWrapper.builder(() -> LocalDate.now()); and: FunctionCallbackWrapper.builder(_ -> LocalDate.now()); // Java 22; use __ for earlier versions Or, you could just use your simple utility method: public static <Void, O> FunctionCallbackWrapper.Builder<Void, O> builder(Supplier<O> function) {
return new FunctionCallbackWrapper.Builder<>(__ -> function.get());
} |
@ullenboom @GetMapping("/sample")
public AssistantMessage sample() {
return chatClient.prompt()
.function("GetCurrentTime", "Use this function to get the current time.", ... some Function code .... )
.system("You are a helpful AI assistant.")
.call()
.chatResponse()
.getResult()
.getOutput(); However, if Supplier were supported directly, the code could be more concise and intuitive: @GetMapping("/sample")
public AssistantMessage sample() {
return chatClient.prompt()
.function("GetCurrentTime", "Use this function to get the current time.", () -> LocalDateTime.now().toString())
.system("You are a helpful AI bot.")
.call()
.chatResponse()
.getResult()
.getOutput();
} Supporting Supplier directly in FunctionCallbackWrapper would make such scenarios simpler and enhance the developer experience. Feel free to share any other thoughts or suggestions; I welcome them! |
This issue is part of the more generic one #1718 |
- Add support for Java Consumer and Supplier functional interfaces in function callbacks - Handle void type inputs and outputs in function callbacks - Add test cases for void responses, Consumer callbacks, and Supplier callbacks - Update ModelOptionsUtils to properly handle void type schemas Resolves spring-projects#1718 and spring-projects#1277
- Add support for Java Consumer and Supplier functional interfaces in function callbacks - Handle void type inputs and outputs in function callbacks - Add test cases for void responses, Consumer callbacks, and Supplier callbacks - Update ModelOptionsUtils to properly handle void type schemas Resolves spring-projects#1718 and spring-projects#1277
- Add support for Java Consumer and Supplier functional interfaces in function callbacks - Handle void type inputs and outputs in function callbacks - Add test cases for void responses, Consumer callbacks, and Supplier callbacks - Update ModelOptionsUtils to properly handle void type schemas Resolves spring-projects#1718 and spring-projects#1277
- Add support for Java Consumer and Supplier functional interfaces in function callbacks - Handle void type inputs and outputs in function callbacks - Add test cases for void responses, Consumer callbacks, and Supplier callbacks - Update ModelOptionsUtils to properly handle void type schemas Resolves spring-projects#1718 and spring-projects#1277
Add support for no-argument Supplier and single-argument Consumer function callbacks in the Spring AI core module. This enhancement allows: - Registration of Supplier<O> callbacks with no input (Void) type - Registration of Consumer<I> callbacks with no output (Void) type - Support for Kotlin Function0 (equivalent to Java Supplier) - Handle empty properties for Void input types in schema generation - Enhance FunctionCallback builder to support Supplier/Consumer patterns Additional changes: - Add test coverage for both Supplier and Consumer callbacks in various scenarios - Enhance TypeResolverHelper to support Consumer input type resolution - Support lambda-style function declarations for improved ergonomics - Add test cases for void input/output handling in OpenAI chat model - Include examples of function calls without return values - Add support for parameterless functions through Supplier interface Resolves spring-projects#1718 , spring-projects#1277 , spring-projects#1118, spring-projects#860
Add support for no-argument Supplier and single-argument Consumer function callbacks in the Spring AI core module. This enhancement allows: - Registration of Supplier<O> callbacks with no input (Void) type - Registration of Consumer<I> callbacks with no output (Void) type - Support for Kotlin Function0 (equivalent to Java Supplier) - Handle empty properties for Void input types in schema generation - Enhance FunctionCallback builder to support Supplier/Consumer patterns Additional changes: - Add test coverage for both Supplier and Consumer callbacks in various scenarios - Enhance TypeResolverHelper to support Consumer input type resolution - Support lambda-style function declarations for improved ergonomics - Add test cases for void input/output handling in OpenAI chat model - Include examples of function calls without return values - Add support for parameterless functions through Supplier interface Resolves spring-projects#1718 , spring-projects#1277 , spring-projects#1118, spring-projects#860
Add support for no-argument Supplier and single-argument Consumer function callbacks in the Spring AI core module. This enhancement allows: - Registration of Supplier<O> callbacks with no input (Void) type - Registration of Consumer<I> callbacks with no output (Void) type - Support for Kotlin Function0 (equivalent to Java Supplier) - Handle empty properties for Void input types in schema generation - Enhance FunctionCallback builder to support Supplier/Consumer patterns Additional changes: - Add test coverage for both Supplier and Consumer callbacks in various scenarios - Enhance TypeResolverHelper to support Consumer input type resolution - Support lambda-style function declarations for improved ergonomics - Add test cases for void input/output handling in OpenAI chat model - Include examples of function calls without return values - Add support for parameterless functions through Supplier interface Add comprehensive documentation for the FunctionCallback API: - Overview of the interface and its key methods - Builder pattern usage with function and method invocation approaches - Examples for different function types (Function, BiFunction, Supplier, Consumer) - Best practices and common pitfalls - Schema generation and customization options Resolves #1718 , #1277 , #1118, #860
This functionality was added in M4, closing. See 432954d commit |
Add support for no-argument Supplier and single-argument Consumer function callbacks in the Spring AI core module. This enhancement allows: - Registration of Supplier<O> callbacks with no input (Void) type - Registration of Consumer<I> callbacks with no output (Void) type - Support for Kotlin Function0 (equivalent to Java Supplier) - Handle empty properties for Void input types in schema generation - Enhance FunctionCallback builder to support Supplier/Consumer patterns Additional changes: - Add test coverage for both Supplier and Consumer callbacks in various scenarios - Enhance TypeResolverHelper to support Consumer input type resolution - Support lambda-style function declarations for improved ergonomics - Add test cases for void input/output handling in OpenAI chat model - Include examples of function calls without return values - Add support for parameterless functions through Supplier interface Add comprehensive documentation for the FunctionCallback API: - Overview of the interface and its key methods - Builder pattern usage with function and method invocation approaches - Examples for different function types (Function, BiFunction, Supplier, Consumer) - Best practices and common pitfalls - Schema generation and customization options Resolves spring-projects#1718 , spring-projects#1277 , spring-projects#1118, spring-projects#860 Signed-off-by: leijendary <jonathanleijendekker@gmail.com>
Add support for no-argument Supplier and single-argument Consumer function callbacks in the Spring AI core module. This enhancement allows: - Registration of Supplier<O> callbacks with no input (Void) type - Registration of Consumer<I> callbacks with no output (Void) type - Support for Kotlin Function0 (equivalent to Java Supplier) - Handle empty properties for Void input types in schema generation - Enhance FunctionCallback builder to support Supplier/Consumer patterns Additional changes: - Add test coverage for both Supplier and Consumer callbacks in various scenarios - Enhance TypeResolverHelper to support Consumer input type resolution - Support lambda-style function declarations for improved ergonomics - Add test cases for void input/output handling in OpenAI chat model - Include examples of function calls without return values - Add support for parameterless functions through Supplier interface Add comprehensive documentation for the FunctionCallback API: - Overview of the interface and its key methods - Builder pattern usage with function and method invocation approaches - Examples for different function types (Function, BiFunction, Supplier, Consumer) - Best practices and common pitfalls - Schema generation and customization options Resolves spring-projects#1718 , spring-projects#1277 , spring-projects#1118, spring-projects#860 Signed-off-by: leijendary <jonathanleijendekker@gmail.com>
Please do a quick search on GitHub issues first, the feature you are about to request might have already been requested.
Expected Behavior
I expect that Spring AI should support registering
java.util.function.Supplier
functions for LLM (Large Language Model) function calling, in addition to the currently supportedjava.util.function.Function
interface. This would allow developers to register functions that do not take any arguments but return a dynamic result, such as a random number generator, the current time, or the server's health status.Here are a few examples where
Supplier
functions would be useful:Random Value Generation:
Time-Related Information:
Server Status Monitoring:
By supporting
Supplier
functions, Spring AI would allow for more dynamic and versatile function calling capabilities in LLM-powered applications. These functions are essential for generating real-time or context-dependent data without requiring any input parameters.Current Behavior
Currently, it appears that Spring AI only supports registering functions that implement the java.util.function.Function interface for LLM function calling. This limits the functionality to only those functions that take an input and return an output. However, there are use cases where functions that take no arguments but return a value (like Supplier) would be more appropriate. This limitation makes it impossible to implement certain types of functionality using the current version.
Context
This issue has affected our ability to fully utilize Spring AI for dynamic content generation, such as generating random numbers or strings within the context of an LLM-powered application. We have considered alternative approaches, such as wrapping a Supplier within a Function, but this feels like a workaround rather than a proper solution. We believe that direct support for Supplier would be a more elegant and useful addition to the framework.
Are there any plans to support this feature, or is there a recommended workaround that we may not be aware of?
The text was updated successfully, but these errors were encountered: