Provide JLama categorization support

[lordofthejars]

If I am not wrong currently we are providing JLama support by using the LangChain4J integration through ChatModel. The problem is that JLama also supports classification feature, not just generating content. I have been using JLama in several examples, specially in GuardRails and the code most of the time looks like:

 @ConfigProperty(name = "jailbreak.model", defaultValue = "lordofthejars/jailbreak-classifier")
    String jailbreakModel;
    static String workingDirectory = System.getProperty("user.home") + "/jlamamodels";

    File localJailbreakModelPath;

    @Startup
    public void init() throws IOException {
        this.localJailbreakModelPath = new Downloader(workingDirectory, jailbreakModel).huggingFaceModel();
    }

    @Produces
    @Named("jailbreak")
    AbstractModel createJailbreakModel() {
        return ModelSupport.loadClassifierModel(localJailbreakModelPath, DType.F32, DType.I8);
    }

And this is repeated for every classification model. So would it be possible to provide some integration where I set as quarkus property something like:

quarkus.langchain4j.jlama.jailbreak.model=lordofthejars/jailbreak-classifier
quarkus.langchain4j.jlama.download=true
quarkus.langchain4j.jlama.outputdir=....

Of course other properties could be download yes/no, download directory, .... optional with some defaults.

So then from my code the only thing I need to do is:

@Named("jailbreak")
AbstractModel m;

So basically I help users to not have to repeat this code for every project and every model.

Maybe we could even provide some interface returning a Map and annotated with @RegisterAiService, or any other annotation but I think this would be more complicated.

[geoand]

This is interesting for sure.

Can you please link to a sample application that uses this idea?

[geoand]

I am saying that if can come up with something that makes sense (the way ChatLanguageModel does), we can configure it. What we don't want to do is configure something totally generic.

[lordofthejars]

Ok, but then automatic creation of AbstractModel you are up to incorporate it?

[geoand]

No, that's what I am saying. There is going to be no automatic producing of AbstractModel - that's up to user code to do.

[lordofthejars]

Yes but then the code becomes really cumberstone as it is repeated everywhere. I think it is a good addition for improving dev experience on this, as we avoid user having to define all the Producer code every time with the configuration parameters and so on.

But it is ok, no worries. It was an idea after all

[geoand]

Yes but then the code becomes really cumberstone as it is repeated everywhere.

That might be the case for these examples, but I see plenty of things that would have to be configurable to make this useful as something general, and this it doesn't seem to me at this point to be something that the extension should provide.