Context
Users often encounter confusion when setting spring.ai.model.chat=none
, as they may not have considered other types of models beyond chat model.
related issues: - https://github.com/spring-projects/spring-ai/issues/3444 - https://github.com/spring-projects/spring-ai/issues/3561
To address this, I propose introducing a spring.ai.model.all
property that allows disabling all models at once.
Current Behavior
Each module needs to be disabled manually.
For example, in the case of the OpenAI module:
spring.ai.model.chat=none
spring.ai.model.audio.speech=none
spring.ai.model.audio.transcription=none
spring.ai.model.image=none
spring.ai.model.embedding=none
spring.ai.model.moderation=none
Expected Behavior
When the property spring.ai.model.all
is set, all model types should be disabled.
spring.ai.model.all=none
Comment From: dev-jonghoonpark
If the project team agree with this feature request, I'd like to implement it.
Comment From: ilayaperumalg
@dev-jonghoonpark Could you elaborate on the use case when you would disable all the models? In this case, why can't you just opt in for a specific auto-configuration you need or not use auto-configuration at all?
Comment From: dev-jonghoonpark
@ilayaperumalg
As far as I know, when using multiple models within a single application or using a single model with multiple configurations, it is commonly handled by disabling autoconfiguration.
For example, let’s assume the user is using the OpenAI module.
After configuring spring.ai.model.chat=none
in the properties file, the user can configure model-specific keys in code rather than in the properties file by creating beans for each model manually.
However, in this case, the autoconfiguration of other type of models interferes with the application startup.
OpenAI API key must be set
As a result, users are forced to set spring.ai.openai.api-key
even if they do not use it - or disable all types of modules.
Of course, users familiar with Spring AI
are likely to quickly realize that they need to disable the other types of models. However, based on the issues mentioned above, it seems that confusion can arise in this area.
Therefore, I suggest implementing this feature.
Even if it seems better not to add the feature, it would be helpful to include a sufficient explanation.