Expected Behavior

Introducing FucntionCallBackResolver would enable more flexibility and control over how to add FunctionCallbacks to a request.

public interface FunctionCallBackResolver {

    public FunctionCallback getFunctionCallback(@NonNull String beanName, @Nullable String defaultDescription);
}

public class ApplicationContextFunctionCallbackResolver implements FunctionCallBackResolver, ApplicationContextAware {

    //the current implementation of FunctionCallbackContext 

}

Current Behavior

There are 2 options now how to add FunctionCallbacks to a Request

Context

What are you trying to accomplish?

  • Custom logic for dynamic function resolution

What other alternatives have you considered? Are you aware of any workarounds? - Making some less elegant logic around prompt options building.

Comment From: tzolov

Hi @konczdev,

Usually the FunctionCallbackContext instance is created in the auto-configuration for each Chat Model using the @ConditionalOnMissingBean annotation. For example this is the OpenAI Auto-Config FunctionCallbackContext.

So I presume that you can extend the FunctionCallbackContext with your own version that overrides the resolver method and expose it as a Bean in your spring configuration? Wouldn't this work?

Comment From: markpollack

@konczdev can you provide an example of how such an alternative implementation such as "Custom logic for dynamic function resolution" would be implemented? The PR has created a new interface, just with providing a name to method resolve

Comment From: konczdev

Sorry, I had to stop experimenting with the project due to a serious health issue (and totally forget I reported this issue too ). However, I looked at the PR now and this is exactly what I had in my mind.