|
|
|
|
|
by killthebuddha
1188 days ago
|
|
Related: I've been seeing a ton of news/references to LangChain recently. My own team is working closely with LLMs, and my non-technical cofounder is pushing hard for us to adopt LangChain as one of our core tools. So I spent a couple days diving into the LangChain codebase and I just don't understand why I would use LangChain. It feels to me like almost all of the LangChain codebase is dedicated to solving non-complex problems or interfacing with dozens on dozens of third-party APIs. All that said, the LangChain team looks solid, they've definitely been shipping code fast, tons of people have committed to the ecosystem, they raised a bunch of money, and I'm a huge believer in just going with standards. Has anyone here worked through this same dilemma, or a similar one, and could maybe help me with how I should be thinking about it? |
|
- learning the framework is a one-time cost that pays dividends over multiple projects. Subsequent products can be built by only implementing the domain-specific stuff above the framework.
- presumably the stuff solved by the framework is non-trivial. It might be “obvious” (in hindsight) but chances are the framework designer has thought about it much more than we want to.
- (theoretical) the framework will outlive any single generation of LLM. This is a fast-moving space and learning a new API or model every few months isn’t going to be fun. Hopefully the framework will adapt and adopters can transition to new models using one framework they already know.
Only the third really applies to an existing project adopting the framework. Is that applicable in your case?