Does it really make sense to officially support both pandasai LLMs and langchain's ?

[mspronesti]

Hi @gventuri , this is a sort of philosophical thread for discussion (hence not really an issue).

I've just noticed we are now supporting any langchain client llm in PandasAI and the first thing that comes to mind was "what do we need our llms for then ?".
Matter of fact, langchain supports more clients and those in common have often more features than ours. Then why don't we simply drop the support to ours and live with langchain's ?
My original thought process was that having ours was better for the following 2 reasons:

• we only support the LLMs that we know can do the job (which is why we don't support any huggingface llm available via inference api but only openassistant, starcoder and falcon). For instance, in the early days of pandasai I tried LLamaCpp and GPT4All and none of them produced meaningful code (or code at all)
• we are not dependent on langchain, which might change its classes, methods and/or signatures in future releases.

A direct consequence of not respecting the first bullet is that we are implicitly saying that any client available in langchain works with pandasai, which is not the case.

To sum up, the point of this discussion is to raise a "coherency" issue and proposes 2 alternatives:

• drop pandasai llms and stick with langchain's
• drop langchain and maybe explain in the docs how one can easily use it at their own risk as we don't guarantee the expected behavior. To do this, one does not really to do this detection inside the PandasAI object. One only needs to make sure that type is implemented and that's pretty much it.

What do you think ? :)

[gventuri]

@mspronesti thanks a lot for the great point! I totally agree.

Just a quick explanation of why we have currently implemented it like this.

We have out own models wrappers because:

• we support the LLMs that we know can do the job to only encourage the usage of those
• we are not dependent on langchain, which might change its classes, methods and/or signatures in future releases
  BUT ALSO:
• we have more control about how we implement our models wrappers
• we don't necessarily need to install langchain and all the related (and most of the time unnecessary) dependencies

On the other hand, we also support langchain models (as a non-default option) because:

• in this way people can try models that we haven't still implemented (and maybe langchain already has). Something like that happened, for example, when we weren't supporting VertexAI models yet. But it could also be the case for all the people willing to use local models (which we don't want to push atm as the quality is quite low and the inference can take minutes)
• it could be easier for people to integrate PandasAI with LangChain without having to instantiate too many instances of the same LLM (imagine someone willing to create a PandasAI agent for LangChain, for instance)

This is the reason why atm we have both the options:

• PandasAI llm wrappers are the recommended, built-in way to go
• Langchain llm wrappers are a supported (yet not recommended unless necessary) way to go in some of the edge cases explained above

What do you think?