Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we no longer use LangChain for building our AI agents

octomind.dev

Post reply on HN
Print view View original

241–250 of 307 posts

Re: Why we no longer use LangChain for building our AI agents

#241

Post by hwchase17 »

chatmasta wrote: post #239
hwchase17 wrote: post #223

Earlier quoted context omitted.

sorry to hear that, totally understand feeling burnt ooc - do you think theres anything we could do to change that? that is one of the biggest things we are wrestling with. (aside from completely distancing from langchain project)

My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part. That’s the real reason people use something other than the native SDK of an LLM provider - they want to be able to swap out LLMs. That’s a well-defined problem that you can solve with a straight forward library. There’s still a lot of hidden work because you need to nail the “least common denominator” of the interfaces while…

> My advice is to focus less on the “chaining” aspect and more on the “provider agnostic” part

a lot of our effort recently has been going into standardizing model wrappers, including for tool calling, images etc. this will continue to be a huge focus

> My other advice would be to build a lot of these small libraries… take advantage of your resources to iterate quickly on different ideas and see which sticks. Then go deep on those. What you’re doing now is doubling down on your first success, even though it might not be the best solution to the problem (or that it might be a solution looking for a problem).

I would actually argue we have done this (to some extent). we've invested a lot in LangSmith (about half our team), making it usable with or without langchain. Likewise, we're investing more and more in langgraph, also usable with or without langchain (that is in the orchestration space, which youre separately not bullish on, but for us that was a separate bet than LangChain orchestration)

Re: Why we no longer use LangChain for building our AI agents

#242

Post by me_vinayakakv »

Treesrule14 wrote: post #20

Has anyone else found a good way to swap out models between companies, Langchain has made it very easy for us to swap between openai/anthropic etc

Vercel AI SDK[1] shines in this aspect in JS ecosystem.

They have the concept of providers [2] and switching between them is easy as changing parameters of a function[3]

[1]:https://sdk.vercel.ai/docs/introduction

[2]: https://sdk.vercel.ai/docs/foundations/providers-and-models

[3]: https://sdk.vercel.ai/docs/ai-sdk-core/overview#ai-sdk-core

Re: Why we no longer use LangChain for building our AI agents

#244

Post by verdverm »

paraph1n wrote: post #199
sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Could someone point me towards a good resource for learning how to build a RAG app without llangchain or llamaindex? It's hard to find good information.

My strategy has been to implement in / follow along with llamaindex, dig into the details, and then implement that in a less abstracted, easily understandable codebase / workflow.

Was driven to do so because it was not as easy as I'd like to override a prompt. You can see how they construct various prompts for the agents, it's pretty basic text/template kind of stuff

Re: Why we no longer use LangChain for building our AI agents

#245

Post by jfjeschke »

hwchase17 wrote: post #237
jfjeschke wrote: post #232

Earlier quoted context omitted.

Thanks Harrison. LangGraph (eg graph theory + Networkx) is the correct implementation of multi-agent frameworks, though it is looking further into, and anticipating a future, then where most GPT/agent deployments are at. And while structured output and tool calling are good, from client feedback, I'm seeing more of a need for different types of composable agents other then the default ReAct, which has distinct limita…

> Different agents for different situations... totally agree. we've opted for keeping langgraph very low level and not adding these higher level abstractions. we do have examples for them in the notebooks, but havent moved them into the core library. maybe at some point (if things stabilize) we will. I would argue the react architecture is the only stable one at the moment. planning and reflection are GREAT technique…

Agreed. I've got a few of them ready to open source. It's almost like there needs to be a reference library of best practices for agent types

Re: Why we no longer use LangChain for building our AI agents

#246

Post by drdaeman »

elbear wrote: post #84

It would have been great if the article provided a more realistic example. The example they use is indeed more complex than the openai equivalent, but LangChain allows you to use several models from several providers. Also, it's true that the override of the pipe character is unexpected. But it should make sense, if you're familiar with Linux/Unix. And I find it shows more clearly that you are constructing a pipeline…

Yeah, I was kind of surprised. The premise of the article started as "LangChain abstractions are off" and then the complaint was about... just a very simple pipeline?

I honestly don't care about the syntax (as long as it's sane enough), and `|` operator overloading isn't the worst one. Manually having to define a parser object gives off some enterprise Java vibes, and I get the httplib vs requests comparison - but it's not the end of the world. If anything, the example from the article left me wondering "why do they say it's worse, when at this level of abstraction it really looks better unless we don't ever need to customize the pipeline at all?" And they never gave any real example (about spawning those agents or something) that actually shows where the abstractions are making things hard or obscure.

Honestly, on the first reading, the article [wrongly] gave me an impression of saying "we don't use LangChain anymore because it lacks good opinionated defaults", which is surely wrong - it would be a very odd take, given the initial premise of using it production for a long while.

(I haven't used LangChain or any LLMs in production, just toyed around a little bit. I can absolutely agree with the article that if all you care about is one single backend, then all those abstractions are not likely to be a good idea.)

Re: Why we no longer use LangChain for building our AI agents

#247

Post by sabrina_ramonov »

You used langchain for a simple replacement of OpenAI API calls — of course it will increase complexity for no benefit.

The benefits of langchain are: (1) unified abstraction across multiple different models and (2) being able to plug this coherently into one architecture.

If you’re just calling some OpenAI endpoints, then why use it in the first place?

Re: Why we no longer use LangChain for building our AI agents

#248

Post by ianschmitz »

sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Way to follow your instinct.

I ran into similar limitations for relatively simple tasks. For example I wanted access to the token usage metadata in the response. This seems like such an obvious use case. This wasn’t possible at the time, or it wasn’t well documented anyway.

Re: Why we no longer use LangChain for building our AI agents

#249

Post by turnsout »

paraph1n wrote: post #199
sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Could someone point me towards a good resource for learning how to build a RAG app without llangchain or llamaindex? It's hard to find good information.

At a fundamental level, all you need to know is:

- Read in the user's input

- Use that to retrieve data that could be useful to an LLM (typically by doing a pretty basic vector search)

- Stuff that data into the prompt (literally insert it at the beginning of the prompt)

- Add a few lines to the prompt that state "hey, there's some data above. Use it if you can."

Re: Why we no longer use LangChain for building our AI agents

#250

Post by krawczstef »

paraph1n wrote: post #199
sc077y wrote: post #186

Damn I built a RAG agent during the past 3 months and a half for my internship. And literally everyone in my company was asking me why I wasn't using llangchain or llamaindex like I was a lunatic. Everyone else that built a rag in my company used llangchain, one even went into prod. I kept telling them that it works well if you have a standard usage case but the second you need to something a little original you have…

Could someone point me towards a good resource for learning how to build a RAG app without llangchain or llamaindex? It's hard to find good information.

Here's a blog post that I just pushed that doesn't use them at all - https://blog.dagworks.io/p/building-a-conversational-graphdb (we have more on our blog - search for RAG).

[disclaimer I created Hamilton & Burr - both whitebox frameworks] See https://www.reddit.com/r/LocalLLaMA/comments/1d4p1t6/comment... for comment about Burr.

Post reply on HN