RFC LLM Library Structure

[jeastham1993]

Start Date

No response

Implementation PR

No response

Reference Issues

No response

Summary

An RFC to discuss the structure of the libraries. The proposal is to split the libraries down into a 'LangChain.NET.Core' library containing the core abstractions and the functionality. Each individual LLM would then be split down into individual libraries, allowing users to only take on the dependencies they need.

Basic Example

• LangChain.NET.Core
• LangChain.NET.OpenAI
• LangChain.NET.HuggingFace

Drawbacks

More complicated project structure and deployment.

Unresolved questions

No response

[CrazyBaran]

For sure any third party dependencies should had their own library/package. If we assume that there is multiple LLM providers as right now OpenAI and AzureOpenAI then we should go with separate packages, as it is for ef core with MySql, Oracle etc. So it will not be too heavy in future. For me right now is a question if we should go with that further, I made in my draft PR #3 first look into LangChain.NET.Abstractions layer to introduce some interfaces needed for testing right now. Maybe it would be useful in that case to move abstract things there.

[jeastham1993]

Ok, excellent.

I noticed the abstractions, and I like what you've done with it. I'm just wondering what the benefit there is to having that in a separate package, as apposed to in a 'Core' library alongside everything else. What would the use case be for using the abstractions package and not the rest of the core library?

[CrazyBaran]

I don't had in mind right now any specific feature rather than organizing code in some ".Shared"/".Contracts" pattern from DDD. Potentially it open road for less headache with nuget packages as such Abstractions package don't need to be iterated with new version each time when we change something in core. In terms of separation of packages for each provider for example. But this is some future thing. Also there is some human factor with development of new packages, you would think twice if you really need add .Core dependency into your package or not.

[gisvlasta]

Hi, all. I just arrived here to say that I would really love to see this lib become a success story. Currently, I can not contribute with code because of excessive workloads related to my job. But I will write my thoughts here.

So, as I understand, the .NET port is going to deviate from the Python source code and its structure? I guess this is somewhat inevitable given the fact that .NET and C# have many differences from Python. In such a case, what would be the strategy for the .NET port to resemble the original LangChain lib? Will there be public classes that would be the same as LangChain's, even if they are packaged in a different way? Are you planning to maintain some kind of one-to-one relationship with them, and if such classes are dropped, what happens with those in the .NET Port? Is the plan to maintain some loose coupling and perhaps the project go its own path in the long term, or is the plan to maintain a close relationship with LangChain and keep up with new features added or even removed?

What about building a community? My previous experience with .NET ports is that they tend to fail often because .NET developers usually do not have the time to contribute (as in my case), and then the original aim to maintain and grow the port becomes a development pain. My view is that for the port to be successful, it needs a community that will be able to contribute. However, this can be done only if a development path with targets is laid out by the core contributors. You see, sometimes if someone wants to contribute and has some time to devote, it would be good to know what kind of development tasks to pick based on the time they have. I know it sounds like too much work for the core team, but it may help the community to grow, while if no such plan exists, then features may appear randomly from those who want to contribute without impacting a lot the functionality of the lib.

I am not sure how many .NET developers would be interested in the project; I am definitely interested in using the lib. I still hope we are many around building in .NET, and this is a needed library, but instead of just jumping on developing code, have second thoughts on how to create a community that contributes regularly. This is usually the key to success in such projects.

[jeastham1993]

Thanks for the thoughful repsonse @gisvlasta. In terms of the .NET port structure, we are trying to find the balance between a common way of doing things to Python whilst also keeping some of the idiomatic .NET specific things. I'm completely ok with the .NET implementation forging it's own path, but I think the core features/naming conventions should be consistent between the 2 languages.

Great call out on creating a community, I will have a think about that.

[fbouteruche]

Hi James.

Resuming the conversation. For the library structure, for now, I would stick to KISS and keep everything in the same package with clear namespace until there is a real need to split into multiple package to reduce the overhead to maintain multiple nuget packages.

In the coming weeks, I want to invest some time in your library as I go deeper with my LLMs learning journey.

What are your thoughts on this?

[HavenDV]

@fbouteruche There is no additional complexity in maintaining a large number of NuGet packages. Since the project will require a large number of dependencies, in LangChain I use separate packages for everything, and a meta package that allows to quickly use the most necessary things. .NET has a fairly large ecosystem, and some platforms require the size of dependencies to be as small as possible

[fbouteruche]

Hi Konstantin,

I’ve just discovered your own project. What is the difference between your project and this one? I see you include this project but I’m puzzled.

Regards, François.

From: Konstantin S. @.> Sent: Thursday, October 19, 2023 7:27 AM To: jeastham1993/langchain-dotnet @.> Cc: Bouteruche, Francois @.>; Mention @.> Subject: Re: [jeastham1993/langchain-dotnet] RFC LLM Library Structure (Issue #4)

@fbouteruchehttps://github.com/fbouteruche There is no additional complexity in maintaining a large number of NuGet packages. Since the project will require a large number of dependencies, in LangChainhttps://github.com/tryAGI/LangChain I use separate packages for everything, and a meta package that allows me to quickly use the most necessary things. .NET has a fairly large ecosystem, and some platforms require the size of dependencies to be as small as possible

— Reply to this email directly, view it on GitHubhttps://github.com/jeastham1993/langchain-dotnet/issues/4#issuecomment-1770025104, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACS6KPE7CZHD22H4GMRLXDDYAC2YZAVCNFSM6AAAAAAZ2BUDBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZQGAZDKMJQGQ. You are receiving this because you were mentioned.Message ID: @.**@.>>

Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA SARL, succursale francaise, 31 Place des Corolles, Tour Carpe Diem, F-92400 Courbevoie, SIREN 831 001 334, RCS Nanterre, APE 6311Z, TVA FR30831001334

[HavenDV]

@fbouteruche I started my project a little earlier(and from other things than this repository), and I think we have a lot more things implemented. But I'm trying to keep an eye on the activity in this repository and include these things as well, but things are pretty slow here.

[fbouteruche]

@jeastham1993 should we consider that the main C# LangChain implementation is the one of @HavenDV? If this is the case, I'm glad to switch to @HavenDV's project.

[jeastham1993]

@fbouteruche that's ok with me and I can shut down this project.