Hacker News Reader

Comment by ggnore7452 | Hacker News Reader

The place where I work was an early adopter of LLM, having started working on it a year ago.

When I build stuff with GPT-3, especially in the earlier days, I get the strong impression that it's like we are doing machine learning without Numpy and Pandas.

with LangChain, many of the systems I have built can be done in just one or two lines, making life much easier for rest of us. I also believe that LangChain's Agent framework is underappreciated as it was pretty ahead of its time until the official ChatGPT plugins were released. (contributed to LangChain a bit too.)

Unfortunately, the documentation is lacking indeed. While I understand the need to move quickly, it is not good that some crucial concepts like Customized LLM have inadequate documentation. (Perhaps having some LLM builds on top of the repo would be more effective than documentation at this point.)

View on HN

The docs are lacking but the underlying code is so simple that it's just a few clicks/rg searches away from figuring out what you need. It's all mostly ways to do string templating. IMO the ergonomics of LangChain need an overhaul; there's too many ways to do the same thing and there's too much type erasure that makes it hard to use strengths in a particular LLM. For example, it's still a pain to distinguish between using a Chat oriented LLM vs a regular completion one.

There also seems to be really poor observability in the code and performance seems to be an afterthought. I tell friends who ask about LangChain that it's great to experiment with but not something I'd put into production. Hopefully this funding helps them shore things up.

I was about to rant about the documentation, but I just checked and it seems to have improved a lot.

I wonder is it already possible for an AI to write documentation from scratch based of code base?

Are you saying you'd use something else in production?

> For example, it's still a pain to distinguish between using a Chat oriented LLM vs a regular completion one.

Totally agree. After using it for a few weeks, this is one of the most visible weaknesses in the design.

> Are you saying you'd use something else in production?

Absolutely. The Langchain interface is quite easy to build atop any old LLM, and if you're just using OpenAI then OpenAI already distirbutes clients in a bunch of languages that you can just use. Even then, you're calling a few HTTP endpoints and stuffing some data in a payload. It's really basic stuff. I'd prototype in Langchain, grab the prompts and agents I ended up using, and reimplement them in $MY_PL on $MY_PLATFORM. That's what I find so fun about these LLMs, they're just trivial to use for anyone that can ship text off to an endpoint (whether networked or local) and receive a text response.

This is what blows my mind. They raised a 10M seed on what is (no disrespect intended) a wafer thin abstraction that an experienced dev really could implement the core of in a few days. Obviously the raise was about the momentum and mindshare Langchain holds, but still. Wow.

I agree that their current implementation is what you said, something an experienced dev can do in a couple days. But they have the potential to really make a robust library here. The thing is, there's a lot of small things with stop sequences, token estimation, API call backoff, and generic structures that are just a pain to make yourself.

But you're right that their moat will probably be razor then. A few senior devs can get together and probably hackathon a library that's just like Langchain but much more robust. Thanks for an idea on what I'm gonna do this weekend lol.

> But you're right that their moat will probably be razor then. A few senior devs can get together and probably hackathon a library that's just like Langchain but much more robust. Thanks for an idea on what I'm gonna do this weekend lol.

Did you do it? I'm doing something similar but in Rust, for my product. It'll be open source soon enough.

Agreed. The text parsing for feeding prompts into an LLM and parsing a response is about as simple and straightforward as it gets in programming. It is nice to have some control over that process and know what your code is doing every step along the way. It doesn’t need to do much anyway, the LLM is doing the hard work mostly. It makes no sense to me and I’m trying to understand it, but I just can’t see the value in a black box library to interface with an LLM when it’s so easy to DIY.

I agree that the agents are underappreciated.

To make them more accessible I rewrote them in ~200 lines of code, so you can easily understand how it works.

They have access to a python console, Google search and hacker news search:

https://github.com/mpaepper/llm_agents

In case anyone misses it buried in the readme, your accompanying blog post looks like the solid introduction to the subject that I've been looking for: https://www.paepper.com/blog/posts/intelligent-agents-guided...

I was looking through Langchain's docs and code last weekend. I'm surprised how well it is documented, actually. I thought it was fairly feature rich vis-a-vis potential chaining opportunities, but with obvious room to grow. Quite impressive, all things considered.

Excited to see what happens going forward.

I think LangChain is already outdated and it (and its copycats) are going to cripple the entire field.

Why? What do you think the better model is?

Could you expand on what you think is the state of the art and direction we should be heading in?

Well, had the community tried analyzing what could be done better? And iterating on the design?

No, the design from an old academic paper was used with a much newer model. And now everyone is just copying that.

It works, because new models are impressive. But the design is far from being elegant or particularly efficient. And now, because tons of data like that is going to be generated, we’ll be stuck with it.

I mean, it's based on a paper[0] from November, no? Or is that called "old" in the AI world?

[0]: https://ai.googleblog.com/2022/11/react-synergizing-reasonin...

Yes, relatively old. The issue is, this approach is designed to work with the “classical” language model, trained using “The Pile” methods. This particular one was Palm 540b.

So essentially you have an approach, designed to work on these models that are not really instruction following models and that truly are stochastic parrots.

The models had changed substantially since. But the approach of chaining them in this particular way stuck. And is getting copied everywhere, without much thought.

Your answer doesn't make any sense regarding langchain to be honest.

Sure. I’m just expressing my opinion that the design is suboptimal and that the level of design is literally “You are GPT-3 and you suck at math” [quote from the LangChain code base].

I don’t want to see further expansion of this. I’m not offering higher level design, because I’m not sure about safety of all of this.

But having a poor and potentially unstable design like LangChain also doesn’t contribute to it :-/

Sorry to bring up an older thread, but I was looking into LangChain recently, and I was thinking of making something similar but in other languages. Do you have any insight into what direction is better to move in for LangChain-like alternatives?

Could you expand on what you think is the state of the art and direction we should be heading in?

It seems pretty rare that communities get "stuck with" a framework. Frameworks are pretty fluid. Eg, Python didn't get "stuck on Django," and they didn't get "stuck on flask," and they're not "stuck on FastAPI" now - the ecosystem continued to evolve, and none of these projects even had to die for a different vision of how a framework should be organized to capture the zeitgeist. They've each got dedicated communities which are continuing to improve them.

Similarly, I expect creative hackers to pursue new approaches in the space of LLM frameworks and for some of those to catch on, and that they don't need to uproot langchain to do so.

The difference is, lots of data is being generated. And, open models in particular, are trained on it. So there is a certain level of stickiness.

An analogy of a file format is a close one. Imagine someone invents something nasty and bulky, like a twisted form of XML or something. And, simply because it is early, it catches on. It could be buggy and unstable and ugly, but it still wins, because it is early.

The call here is to try to examine LangChain design a bit closer. And maybe consider that a start from scratch is a good idea.

It is, but it'll still get copious funding and let a few sly engineers escape the Matrix - so what's the harm?

There are two Javascript alternatives, but how robust the development is remains to be seen:

https://github.com/hwchase17/langchainjs

https://github.com/cfortuner/promptable

Where do you see Langchain fitting into the ecosystem once Open AI rolls out plugins more widely?

Then we will connect plugins visually as Unreal's Blueprint Visual Scripting allows.

Is this supposition, or actually the direction Langchain is headed?

it still works well with other LLM (like llama and more).

various small, open sourced, and verticle LLMs vs one large GPT models would be quite interesting.

It's unfortunate that prettymuch all shiny AI things have horrible documentation. I see a lot of misinformation in non-researcher AI circles and I feel like it stems from that sometimes.

it is ironic that documentation is lacking when it can be generated with an LLM, using LangChain itself

Reply on news.ycombinator.com