41–50 of 192 posts
Since last year, before I heard about langchain, I've been building my own stack of tooling for my own LLM projects that probably now covers about 10-20% of Langchain's functionality. I heard about Langchain earlier this year and groaned, thinking that I did a lot of work for nothing.. ..Then I actually used langchain. I was shocked at how poorly performant the code is. Some operations took 10x longer than how I did…
I don't trust them, because they never talk about their "tradeoffs". Every software has its tradeoff.
K8s and react are wildly popular, huge tradeoffs, but mention none of them.
I had the same thought about Langchain, and it's essentially my same criticism of most wrapper libraries and SDKs. What are they actually doing that can't be just as easily done with straight up string manipulation and HTTP requests? Usually very little. ORMs might be one of the few exceptions in some cases. Even so, ORMs sell a similar false promise to Langchain, which is that you can "easily" swap out the underlyin…
But Langchain is far, far, _far_ away from being truly helpful with that. It's glorious that we're 5 months into GPT-4 and most people either got bored or are building on rickety rushed structures in Python to rush out a proof of concept web app.
It seems to mostly be (bad) abstractions around things you could easily do without langchain.
Take one of the most important llm things: prompt templates. What does langchain add over a simple function and an f string? Maybe I'm missing the point, but I can't find anything.
Anyway, it seems people like it so who am I to judge, but I don't like making our codebase dependent on a huge new library with unnecessary abstractions and little or no value add.
It’s maybe useful as a repository of prompting techniques, but I found myself constantly monitoring the actual prompt text being generated rather than reading the code that produces it…
Earlier quoted context omitted.
We also do platform & customer work there (cool pipelines to feed louie.ai or real-time headless versions), and agreed those pipelines have simple uses of LLM where langchain is mostly useful just for a vendor neutrality. Think BYO LLM as it is now a zoo. Basically apache nifi or spark streaming with simple LLM & vector DB call outs. Our harder work here is more at the data engineering level. But....a lot of our loui…
I agree that it's a little silly, but I mostly use it to abstract over BYO LLMs and extract information from documents. It's nice to be able to quickly prototype something and swap out the underlying language model than set up a whole pipeline with Apache Tika, ETL, etc. Once the idea is feasible, then sure. That said, langchain is really inefficient and I often find I can re-implement the pieces I need much faster t…
Earlier quoted context omitted.
You should probably not mention it by name on a resume anyway, but emphasize your actual skills, experience, and familiarity with the lower level technologies and APIs that underly it. This hype train isn't going to last forever, and it's probably better to advertise sustainable, evergreen skills rather than being an expert in the flavor of the week. With that much experience, you shouldn't have to feel tied to any o…
It was a joke, langchain was released last year.
Remember, this is the project that raised ~$30m from Benchmark and Sequoia. There was a controversial "quality doesn't matter for software products" post and discussion[0] here on HN a few days ago and this is a beautiful example. Product may matter eventually, but you can sure surf the hype for a long time before the reckoning comes (and if you're lucky, you may even be able to get someone else to hold the bag then)…