Integration of generic LLM API (e.g. Xinference)

[AndiMajore]

Adds generic implementation of the Conversation class to allow for use of non-openai but openai style endpoints.
Includes the addition of customized openai.py > generic_openai.py

• to disable tokenization based on modelname
• to override the modelname based URL use to have static URL endpoint but model_uid in request for model selection

[slobentanzer]

Thanks for the PR, @AndiMajore!

@fengsh27, this is the local LLM application that we briefly talked about, I think it would be helpful for you to see the implementation, and helpful for the PR if you could give your opinion / input on the code.

In particular, I would like to reduce redundancies in the newly established generic OpenAI connectivity and the one that previously existed. It would be great if the existing GPTConversation could inherit from the generic one with some fixed parameters; and if the tests reflected this, equally.

I will be back to being able to code next week, so I'm happy to get practically involved as well. @AndiMajore, could you summarise again what kind of conflicts we have between the OpenAI API and the custom Xinference one?

Ideally, we would end up with a generic OpenAIConversation, that can have Xinference and official OpenAI API (regular and Azure) children (with minimal code duplication). So the hierarchy would be:

Conversation
- OpenAIConversation ( + HuggingFaceConversation etc )
-- XinferenceEndpointOpenAIConversation, OfficialEndpointOpenAIConversation, AzureEndpointOpenAIConversation

Maybe we can come up with more concise names for the classes. ;)

[AndiMajore]

Hey @slobentanzer ,
I just changed the Xinference chatting integration to use the Client class of Xinference and the Xinference embedding integration to use the XinferenceEmbeddings class of langchain.

[slobentanzer]

Thanks!