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.
Why we no longer use LangChain for building our AI agents
271–280 of 307 posts
Re: Why we no longer use LangChain for building our AI agents
#272Earlier quoted context omitted.
The main reason ChatGPT took off was: 1) Response time of the API of that quality was 10x quicker than the Davinci-instruct-3 model that was released in summer 2022, making interaction more feasible with lower wait times and with concurrency 2) OpenAI strictly banned chat applications on the GPT API; even summarising with more than 150 tokens required your to submit a use case for review; I built an app around this i…
"Instruct tuning was far more impactful than conversational model tuning because instruct enabled so many synthesizing use cases beyond the training data." I saw many model providers nowadays provide instruct model in name as chat model. What difference between instruct tuning and conversational model tuning specifically?
Afaik there's no difference, instruct and chat are used interchangeably. Mistral calls their tunes "modelname-Instruct", Meta calles them "modelname-chat".
Strictly speaking instruct tuning would mean having one instruction and one answer, but the models are typically smart enough to still get it if you chain them together and most tuning datasets do contain examples of some back and forth discussion. That might be more what could be considered a chat tune, but in practice it's not a hard distinction.
Re: Why we no longer use LangChain for building our AI agents
#273Earlier quoted context omitted.
Maybe. Developers love to invent new definitions for existing terms all the time, so Java is OOP under one or more of those definitions, but Java is not OOP in the original sense. So, it depends on the definition of OOP arbitrarily chosen today.
The "original sense" argument is frankly nonsense. Simula 67 was the original OOP language, predating Smalltalk, and it already had "classes" and "objects". It also looked a great deal like Java and the OOP parts of C++.
Simula 67 long predates OOP. Which, when you think about it, means that when OOP was coined it referred to a "message passing" paradigm, not "classes" or "objects". "Oriented", not "object", was the operative word. Having objects does not make a language object-oriented, at least not as it was originally conceived.
Simula 67, like Java, may fit into some newer OOP definitions that have come about over the years, but it was not considered OOP at the time of its arrival. The term OOP hadn't even been invented yet. And when OOP finally did get used for the first time, it most definitely did not refer to Simula 67. Where on earth did you get the idea that it did? Whatever gave you that idea was, frankly, nonsense.
Re: Why we no longer use LangChain for building our AI agents
#274This echoes our experience with LangChain, although we have abandoned it before putting it into production. We found out that for simple use cases it's too complex (as mentioned in the blog), and for complex use cases it's too difficult to adapt. We were not able to identify what is the sweet spot when it is worth it to use it. We felt like we can easily code ourselves most of its functionality very quickly and in a…
i've never seen a HN thread where everybody just unanimously agrees and wow I definitely will not be recommending Langchain or using it personally after reading through all the horror stories.
seems like another case of creating busysoftware. doesn't add value, rather takes away value through needless pedantry, but has enough github stars for people to take a look anyways
Re: Why we no longer use LangChain for building our AI agents
#275Genuine question: can someone point me to a use case where langchain makes the problem easier to solve than using the openai/anthropic/ollama SDKs directly? I've gotten a lot of advice to use langchain, but the docs haven't really shown me how it simplifies the task, or at least not more than using an SDK directly. I really want to at least understand when to use this as a tool but so far I've been failing to figure…
It makes it simple (and uniform) to switch providers.
theres already solutions for this but even this i feel like is a wasted effort unless you have the token volume to justify high availability
Re: Why we no longer use LangChain for building our AI agents
#276Is there a lighter weight solution that abstracts the interfaces so I can swap GPT4 with Claude, including function calling?
Re: Why we no longer use LangChain for building our AI agents
#277Earlier quoted context omitted.
using LangGraph for a month, every single "graph" was the same single solution. The idea is cool, but it isn't solving the right problem.... (and the problem statement shouldn't be generating buzz on twitter. sorry to be harsh). You could borrow some ideas from DSPy (which borrows from pytorch) their Module: def forward: and chain LM objects this way. LangGraph sounds cool, but is a very fancy and limited version of…
ooc, what was the "same single solution"
The graph code, when all done and said, is identical for all scenarios.
Re: Why we no longer use LangChain for building our AI agents
#278LLM frameworks like LangChain are causing a java-fication or Python . Do you want a banana? You should first create the universe and the jungle and use dependency injection to provide every tree one at a time, then create the monkey that will grab and eat the banana.
I’ll use this to explain why typescript is bad
Wait how does this relate to TypeScript?
Re: Why we no longer use LangChain for building our AI agents
#279Re: Why we no longer use LangChain for building our AI agents
#280I don't like langchain that much either. It's not as bad as LLAmaIndex and Haystack in regards to extreme overengineering and overabstracting but it still is bad. The reason I still use Langchain is that often times I need to be able to swap out LLM service providers, embedding models and so on for clients. Thats really the only part about langchain that really works well. Btw. you don't have to actually chain langch…
I don’t think that’s fair to Llama-Index. LI is much more focused, better documented and frankly way easier to use than LangChain, with much lower - or negligible - cognitive overhead. Plus, it plays nice with most everything else.
Even if you’re mostly working just with a provider SDK and other lightweight, low-dependency convenience wrappers for stuff you know you’ll almost always need (e.g. Instructor for structured output and retry), you can easily sprinkle LI in where you need it as a wrapper over common context retrieval patterns.
Unlike LangChain, which is a nightmare to pull out once you’ve started working with it - LI can be cleanly excised if you change your mind.