I don't know enough to agree that it's pointless, but I'd agree that when I looked at it I saw a lot of abstraction of already simple stuff (like the examples the post gives) and decided that for what I was doing it would be faster and easier to understand to just write my own python script. Though I can picture for very inexperienced developers the abstractions may be helpful short term?
I had a similar experience; looked into using it for something, and felt that it would be easier to recreate the things I would use langchain for in Jinja2, than it would be to reshape my code to the interface that langchain wanted.
This guy's analysis is terrible. I literally built a retrieval augmented generation with memory in langchain last night (comments claim you can't do this)
Sure, langchain has poor documentation and useless helper functions. That doesn't mean that it's pointless.
Just fyi, if you use a standard knn library like faiss and pretty much any embedding + language model raw from huggingface or an API, it will require ~15 lines of code to do what you describe. I’m not sure how much shorter langchain made your implementation but I can’t imagine it saving too much.
The point is in 99% of use cases no one will ever swap OpenAI or vector storage db for anything else. All Langchain does in these cases is introduces useless abstraction that takes longer to implement and makes things less transparent.
And when you need some customization instead of taking you 10 minutes it takes an hour to work around this abstraction.
I've definitely got heartache here, and they merit criticism, but it is real
We need a lot of pluggability to support diff vendor LLMs and BYO LLMs in Louie.ai, so having langchain has been nice for helping code to interfaces vs vendor lockin. It definitely has growing pains - ex: sync & multithreading is important for us so we are generally coding around langchain while that smooths out. Likewise, we ended up building much of our conversational and multitool capabilities as custom libraries vs using theirs for similar quality reasons. We can't use any of the codegen capabilities because they are massive security holes so doing our own work there too.
If anyone is into that kind of work (backend, AI & web infra, ...), definitely hiring for core platform & cool customer projects here: louie.ai / Graphistry.com/careers
Also, the thread title is unintentionally funny: I'd like the interface to be more functional so we can write truly 'point-free' pipelines, especially around areas like memory. Ex: When dealing with multithreading, that makes it a lot safer. There are projects exploring that, but langchain is winning as a pluggable interface for many new LLM providers.
I have done a bit of research trying to figure out why anyone would use langchain. The main two reasons I’ve found are these:
1. Newbies that want to play with LLMs don’t know where to start or what the major building blocks even are. Despite the complaints here about documentation their getting started docs will walk you through the concepts. Going from total ignorance and confusion to now having a rough understanding of loading a prompt with chat history, using an embeddings database, calling a completions endpoint, etc. will make people feel accomplished. And then lang chain has earned some loyalty just because they were there for you first.
2. In the case that you don’t know which embedding db, AI host, or model you want to use you can quickly swap those in and out and measure the results. That means there’s little reason to complicate your back end code with lang chain (I’ve always just written my own abstraction layer to make this possible with very few lines of code). But for a python notebook it can make sense.
I tried using langchain.js after a bit of hype and overwhelming dev support and incremental releases, but it became added complexity for no reason for our case.
OpenAI's NPM is much easier to use. A lot of what langchain promised out of the box didn't work like caching. Anyways it's still beta i believe
Perfect.. I've seen so many demos showing people feeding data to LLMs so they can "ask questions about their data" but still not seen any real business use cases. Is anyone using these tools in production for a real problem?
The enterprise search domain has evolved quite a bit, utilizing & integrating retrieval-rerank architectures for a few years now. That includes embedding/vector storage, as well as LLM usage (eg using Google T5 for query understanding and model rerank)… there’s some generative modeling but not really like GPT… more like structuring an abstract tree from a complex Boolean query, and sending that tree into an custom retrieval approach over ANN & rerank ensemble.
If you’re doing that type of work in a serious manner you don’t use libraries like langchain or lamaindex. They are a bit late/irrelevant to the engineering that exists in that type of environment.
It abstracts some work only to introduce introduce it's own API (which is ultimately more complicated, less documented, introduces limits and constraints, and comes with its own bugs and dev politics)...
It is pointless - LlamaIndex and LangChain are re-inventing ETL - why use them when you have robust technology already?
1. You ETL your documents into a vector database - you run this pipeline everyday to keep it up to date. You can run scalable, robust pipelines on Spark for this.
2. You have a streaming inference pipeline that has components that make API calls (agents) and between them transform data. This is Spark streaming.
Prophecy is working with large enterprises to implement generative AI use cases, but they don’t talk so much on HN.
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 louie.ai work happens for less trivial scenarios where it isn't just the ETL NLP 2.0 tier . That logic is much more complicated, so structured programming abstractions matter a LOT more for AI-style business logic. Think talk to your data and generate on-the-fly analytics pushdown with an interactive data viz UI. That's.. a lot of code.
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 than dealing with langchain's bugs and performance issues.
That’s assuming you’re not using low-code. There are inbuilt connectors to read data, transform data, read/write to pinecone, make api calls to LLMs. It is much faster to prototype with Prophecy.io
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 one company's software.
No no, that is the right tense! I thought initially it was like light sarcasm targeting the conceit of the reddit post, i.e., "how could it be pointless if I have amassed all this experience." Beyond that.. not sure (I'm not that smart).
Perhaps its just something like: "the scandal that this library is bullshit amounts to not a lot considering it's still pretty new thing." But the, erm, strong showing of downvotes of my original post makes me think its a better bit than that!
Indulge me with the joke if you'd like, but don't worry about me! I'm doing pretty good, despite my slow mind.
The context for the joke is that some job listings have inflated requirements, like N years of experience from framework/language X that realistically nobody has (or in this case, can have)
You'll still need to re-tune your prompt and the hyperparameters when switching models. So the actual effort of switching models is not improved much if at all.
This. I'll still use langchain for token/cost counting and some nice abstractions on top of the LLM, and the document loader system is semi-useful, but all of the retriever/chain stuff abstracts away the most important part - the prompt.
I found that you need to dig into the actual code and debug it while it is running to see what is going on to actually use the library (both with Langchain and LlamaIndex). That's unfortunate, but it does show a path to get you to where you want to go and is probably faster in the long run than writing your own code because you can swap components (e.g., which LLM or which vector DB) in and out.
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 underlying thing; a migration that is rare in practice and almost always not that simple.
It's a really interesting question: the converse of this is its _really_ tricky nailing all this down, much harder than you'd think -- see the GPT4 GA thread earlier this week for people who swear up and down the OpenAI API acts in bizarre ways, you'll note that it almost seems fantastical that it could be that bizarre: it is fantastical. If you're truly used to it, it reads like "hey I have auto retries enabled in my HTTP client framework. p.s. whats 'context size'?"
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.
For me the biggest benefit is just following the project and seeing what the community is doing with llms (It’s also not bad for quick proofs of concept).
That said especially in python it’s not that hard to reimplement things yourself in a cleaner way. Output parsing for agents was nice but with the function update from OpenAI it’s not really necessary (if you’re just using their API)
Every system I’ve seen for managing this kind of system has flaws, including the ones that I have written.
For instance scikit-learn implements excellent algorithms for model selection that would apply, in principle, to a model based on huggingface transformers that might take 2 hours to train. skl is a fast machine if memory fits in RAM on a single computer, but it is not up to task for multiple computers or anything mortal to a single process such as the computer bring turned off.
HF has model selection algorithms too, but not as nice. They don’t take the same kind of datasets as all so it would be a hassle to import my ski models into HF.
I have to be able to compare models generated with any kind of tools so I think I will build a universal model selection framework (builds and test models) but then you run into the problems langchain did where there is a lot of structure imposed and all sorts of quirks and performance losses because of that structure.
For instance my current skl selector wastes a lot of resources computing stuff from scratch over and over again and if the code were properly organized it could get the job done 3 times faster but the same trick wouldn’t work for every other experiment I might want to do.
So we are all running into hurdles and finding ways to jump over them, making a lot of mistakes because we are in a rush and don’t know better yet.
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 it, and all the while producing worse results. As tempting as it is to just roll with langchain from day one, I'd highly advise against it. Think deeply about what you're actually trying to accomplish and instead of just injecting langchain in the middle of everything as this messy, amorphous glue code thing.
I had this exact same experience. I was happy to move to something good, but I couldn’t find a lot of benefit. Maybe I’m missing something, but the added complexity is not worth it to me for what it provides.
Yeah I've got a few thousand lines of langchain code now for a data cleaning pipeline... I've been fighting it every step of the way. Trying to replace sections of the pipeline to use a local LLM instead of OpenAI has had me have to replace the templates entirely, the chat based templates won't allow me to assign the proper user/assistant names, so the performance for the local LLM is terrible (stupid). They have zero actual composibility when you look at it slightly differently than they expect.
It's a useless abstraction for every single purpose I've actually tried it for.
Will be extricating it from my code base as soon as I find something else that works any better.
I have an attempt in the same domain, would love feedback
We think - Generative AI is config management. We model it on top of config management grammar that is proven to work at K8s/Terraform scale - jsonnet.
Prompts live outside the code. We didnt invent a new markup - we used jsonnet which is used in large scale kubernetes and has a grammar that has been well tested for config mgmt.
We thought the same thing with https://neum.ai - config management/infra as code for your LLM app, using plain JSON, though we are abstracting even more what LangChain does. Not suitable for the audience here given the level of customizations some folks want.
I like that analogy. I have one of those slicers and every time I use it I have two thoughts. First, this slices so quick and evenly. Second, there's a whole lot more I have to clean up compared to the knife.
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).
I’m curious - who gets screwed over the most here? Is it investors who got tricked into over valuing? Or langchain who now can’t meet their expected revenue targets and will be forced to pivot?
Speaking in hypothetical terms of course. I’m assuming the langchain folks are probably paying themselves pretty well and not working super hard (at least not on engineering stuff)?
Usually the investors - the funding amount means that the founders and early employees can get paid a living wage at least (as a former VC-backed founder I can say that they probably don't get paid exorbitantly). But investors will get rinsed if the company can't either reach IPO or raise a subsequent round at a higher valuation. This becomes very difficult when the company is already worth $200M on paper, and need to get the revenue to a point where that valuation is justified.
Sequoia never figured out their edge in the enterprise world. They likely won't fall from grace since they're still investing in the space, but their filter is certainly poorer than their other areas of investment.
Thanks for this post, I hadn't seen the linked conversation when it happened. Here's my reading. The conversation blog post you linked begrudgingly points out that companies aren't sunk by bugs, technical debt, or inefficient development practices. If you have a good sales team and a product that people want, need, or will be forced to use, you can succeed even if you have to burn money on dev, ops, customer support.
However I think what this langchain conversation is about is overeager VCs and a product that maybe doesn't do anything we need. It's not that langchain is slow or hard to use; it's that we can just do this stuff with Python or whatever. I don't have enough langchain experience to substantiate these claims but I think that's what I'm reading here.
I have looked for the value and never really found it.
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.
Honestly, it's hard to even tell if people really like it or if the LangChain team have just done a really good job of evangelizing for it. I saw that they did some kind of interview with Andrew Ng the other day. I feel like that sort of thing doesn't just happen by accident, but because someone actively reached out to him, especially considering that LangChain has only been on the scene for a couple of months.
True, you gotta respect the marketing, they definitely got that covered and actually created some real value there, a $10M seed round to be precise.
I think they got the timing right and the idea is kinda alluring as well: have everything standardized, pluggable and swappable sounds neat. Just doesn't really work.
They are also doing a great job at maintaining the mirage of adding value. Templates for example will work totally fine, as they are just f strings. It seems there are plenty of people who don't really think twice about it, and they have captured that audience very well.
There is also a low barrier to contribute as everything is kinda basic, that must help a lot as well.
I actually found a lot of value when I left the LangChain ecosystem and started using jinja templates. The syntax from home assistant moved over and I can just pass dictionaries to render a prompt now.
With peace and love, why would I not just write some code?
LLM pipelines are not very complex: it's string manipulation, api calls, and storage, there is not much more too it. All are quite easy to do, often needing nothing else but the standard library.
For more complex cases or bigger scale you have a plethora of battle tested solutions to manage things like queues, back off and retries, concurrency, etc.
Maybe it's me missing the point (again), but I wonder what the added value is of learning a new language to do things that are super easy to do in Python/JS/whatever my language of choice is? Or maybe I'm just not be your target audience, very possible.
I get this feeling too "maybe I'm not the target audience"
This feeling is followed closely by "Who is the target audience?". Some abstract concept of an audience doing complex LLM work to accomplish... something?
The value in statistics analysis for LLMs is clear, the value in chaining responses is very unclear.
> 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.
Seconding.
Ever since learning about it, then seeing a co-worker use it for some simple embedding job (and being impressed in how few lines of code it took, but that's actually not thanks to LangChain), then reading its docs end-to-end, about once a week, I find myself going through the following sequence of thoughts:
1. Alright, let's set up LangChain and implement my ${most recent harebrained idea};
2. Oh, but it's in Python. I don't like Python, I don't know Python, I hate dealing with its dependency issues even more than with NPM ones. Could I do things I need from it directly in ${my preferred environment, which half the time is just Emacs}?
3. Wait a minute. Chaining "DAGs" the way it does is basically equivalent to a sequence of function calls in a while loop, occasionally mixed with some if/else or goto. Generating prompts is... string interpolation that can be wrapped in a helper function. LMAO.
4. No, really. Why bother? The only useful thing here seems to be discoverability - i.e. a list of toolkits it supports, and said support working as intro 101 tutorial. Given the surface areas of those plugins are so small, I can literally wrap what I need in a bunch of functions, and then do the "chain" part as... plain old sequential code.
So yeah, right now, I think about the only value this project has is in being a convenient list of AI tools with examples of using their APIs. Everything else seems better done either by coding it directly, or (for certain needs) by building up a more complex dataflow framework.
Fair assessment. Maybe you have found the value: it’s a library of code snippets. There is truly something to say for that, but maybe it had worked better as a documentation site (kinda ironic as their docs are not super great).
> plain old sequential code
This!! Besides the templates this is the most confusing thing, it is indeed the same as running lines of code sequentially.
P.S. for python dependencies, check out Poetry, not perfect but a lot more sane than the other options.
I tried to improve the type coverage of the JS package and I came to a lot of the same conclusions. It feels like a lot of unnecessary and poorly conceived indirection and abstraction. There’s basically just a lot more to learn especially if you’re just getting started.
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…
Completely agree. I had this exact thought last week. It's been helpful to go through their repo to see how they've done certain things, but it's a textbook leaky abstraction.
189 comments
[ 3.0 ms ] story [ 296 ms ] threadSure, langchain has poor documentation and useless helper functions. That doesn't mean that it's pointless.
And when you need some customization instead of taking you 10 minutes it takes an hour to work around this abstraction.
We need a lot of pluggability to support diff vendor LLMs and BYO LLMs in Louie.ai, so having langchain has been nice for helping code to interfaces vs vendor lockin. It definitely has growing pains - ex: sync & multithreading is important for us so we are generally coding around langchain while that smooths out. Likewise, we ended up building much of our conversational and multitool capabilities as custom libraries vs using theirs for similar quality reasons. We can't use any of the codegen capabilities because they are massive security holes so doing our own work there too.
If anyone is into that kind of work (backend, AI & web infra, ...), definitely hiring for core platform & cool customer projects here: louie.ai / Graphistry.com/careers
Edit: link - https://en.wikipedia.org/wiki/Tacit_programming
1. Newbies that want to play with LLMs don’t know where to start or what the major building blocks even are. Despite the complaints here about documentation their getting started docs will walk you through the concepts. Going from total ignorance and confusion to now having a rough understanding of loading a prompt with chat history, using an embeddings database, calling a completions endpoint, etc. will make people feel accomplished. And then lang chain has earned some loyalty just because they were there for you first.
2. In the case that you don’t know which embedding db, AI host, or model you want to use you can quickly swap those in and out and measure the results. That means there’s little reason to complicate your back end code with lang chain (I’ve always just written my own abstraction layer to make this possible with very few lines of code). But for a python notebook it can make sense.
OpenAI's NPM is much easier to use. A lot of what langchain promised out of the box didn't work like caching. Anyways it's still beta i believe
If you’re doing that type of work in a serious manner you don’t use libraries like langchain or lamaindex. They are a bit late/irrelevant to the engineering that exists in that type of environment.
It abstracts some work only to introduce introduce it's own API (which is ultimately more complicated, less documented, introduces limits and constraints, and comes with its own bugs and dev politics)...
But nobody asked me, keep using it
(though it does exist already) https://www.urbandictionary.com/define.php?term=fauxcade
1. You ETL your documents into a vector database - you run this pipeline everyday to keep it up to date. You can run scalable, robust pipelines on Spark for this.
2. You have a streaming inference pipeline that has components that make API calls (agents) and between them transform data. This is Spark streaming.
Prophecy is working with large enterprises to implement generative AI use cases, but they don’t talk so much on HN.
Here’s our talk from Data+AI Summit: Build a Generative AI App on Enterprise Data in 13 Minutes https://www.youtube.com/watch?v=1exLfT-b-GM
Here’s a blog/demo https://www.prophecy.io/blog/prophecy-generative-ai-platform...
But....a lot of our louie.ai work happens for less trivial scenarios where it isn't just the ETL NLP 2.0 tier . That logic is much more complicated, so structured programming abstractions matter a LOT more for AI-style business logic. Think talk to your data and generate on-the-fly analytics pushdown with an interactive data viz UI. That's.. a lot of code.
That said, langchain is really inefficient and I often find I can re-implement the pieces I need much faster than dealing with langchain's bugs and performance issues.
K8s and react are wildly popular, huge tradeoffs, but mention none of them.
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 one company's software.
If you don't get it now, I'm worried about you:)
Perhaps its just something like: "the scandal that this library is bullshit amounts to not a lot considering it's still pretty new thing." But the, erm, strong showing of downvotes of my original post makes me think its a better bit than that!
Indulge me with the joke if you'd like, but don't worry about me! I'm doing pretty good, despite my slow mind.
Does it introduce features that you don't need to implement yourself? Yes
Does it make it easy to drop OpenAI? Yes
What's the problem?
Even so, ORMs sell a similar false promise to Langchain, which is that you can "easily" swap out the underlying thing; a migration that is rare in practice and almost always not that simple.
You might not need Langchain.
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.
That said especially in python it’s not that hard to reimplement things yourself in a cleaner way. Output parsing for agents was nice but with the function update from OpenAI it’s not really necessary (if you’re just using their API)
For instance scikit-learn implements excellent algorithms for model selection that would apply, in principle, to a model based on huggingface transformers that might take 2 hours to train. skl is a fast machine if memory fits in RAM on a single computer, but it is not up to task for multiple computers or anything mortal to a single process such as the computer bring turned off.
HF has model selection algorithms too, but not as nice. They don’t take the same kind of datasets as all so it would be a hassle to import my ski models into HF.
I have to be able to compare models generated with any kind of tools so I think I will build a universal model selection framework (builds and test models) but then you run into the problems langchain did where there is a lot of structure imposed and all sorts of quirks and performance losses because of that structure.
For instance my current skl selector wastes a lot of resources computing stuff from scratch over and over again and if the code were properly organized it could get the job done 3 times faster but the same trick wouldn’t work for every other experiment I might want to do.
So we are all running into hurdles and finding ways to jump over them, making a lot of mistakes because we are in a rush and don’t know better yet.
..Then I actually used langchain. I was shocked at how poorly performant the code is. Some operations took 10x longer than how I did it, and all the while producing worse results. As tempting as it is to just roll with langchain from day one, I'd highly advise against it. Think deeply about what you're actually trying to accomplish and instead of just injecting langchain in the middle of everything as this messy, amorphous glue code thing.
It's a useless abstraction for every single purpose I've actually tried it for.
Will be extricating it from my code base as soon as I find something else that works any better.
We think - Generative AI is config management. We model it on top of config management grammar that is proven to work at K8s/Terraform scale - jsonnet.
https://github.com/arakoodev/EdgeChains/blob/main/Examples/r...
Prompts live outside the code. We didnt invent a new markup - we used jsonnet which is used in large scale kubernetes and has a grammar that has been well tested for config mgmt.
p.s. i am contributor so there could be bias
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).
0: https://news.ycombinator.com/item?id=36615286
Speaking in hypothetical terms of course. I’m assuming the langchain folks are probably paying themselves pretty well and not working super hard (at least not on engineering stuff)?
Is that what we are starting to see for Sequoia?
Like KP, I doubt they’ll fold, but it would be interesting to live in a world where sequoia is just top half instead of top 1.
Today I learnt.
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.
I think they got the timing right and the idea is kinda alluring as well: have everything standardized, pluggable and swappable sounds neat. Just doesn't really work.
They are also doing a great job at maintaining the mirage of adding value. Templates for example will work totally fine, as they are just f strings. It seems there are plenty of people who don't really think twice about it, and they have captured that audience very well.
There is also a low barrier to contribute as everything is kinda basic, that must help a lot as well.
It's basically just a simple scripting language with array semantics and inline prompt construction, and you can drop into Python any time you like.
LLM pipelines are not very complex: it's string manipulation, api calls, and storage, there is not much more too it. All are quite easy to do, often needing nothing else but the standard library.
For more complex cases or bigger scale you have a plethora of battle tested solutions to manage things like queues, back off and retries, concurrency, etc.
Maybe it's me missing the point (again), but I wonder what the added value is of learning a new language to do things that are super easy to do in Python/JS/whatever my language of choice is? Or maybe I'm just not be your target audience, very possible.
The value in statistics analysis for LLMs is clear, the value in chaining responses is very unclear.
Seconding.
Ever since learning about it, then seeing a co-worker use it for some simple embedding job (and being impressed in how few lines of code it took, but that's actually not thanks to LangChain), then reading its docs end-to-end, about once a week, I find myself going through the following sequence of thoughts:
1. Alright, let's set up LangChain and implement my ${most recent harebrained idea};
2. Oh, but it's in Python. I don't like Python, I don't know Python, I hate dealing with its dependency issues even more than with NPM ones. Could I do things I need from it directly in ${my preferred environment, which half the time is just Emacs}?
3. Wait a minute. Chaining "DAGs" the way it does is basically equivalent to a sequence of function calls in a while loop, occasionally mixed with some if/else or goto. Generating prompts is... string interpolation that can be wrapped in a helper function. LMAO.
4. No, really. Why bother? The only useful thing here seems to be discoverability - i.e. a list of toolkits it supports, and said support working as intro 101 tutorial. Given the surface areas of those plugins are so small, I can literally wrap what I need in a bunch of functions, and then do the "chain" part as... plain old sequential code.
So yeah, right now, I think about the only value this project has is in being a convenient list of AI tools with examples of using their APIs. Everything else seems better done either by coding it directly, or (for certain needs) by building up a more complex dataflow framework.
> plain old sequential code
This!! Besides the templates this is the most confusing thing, it is indeed the same as running lines of code sequentially.
P.S. for python dependencies, check out Poetry, not perfect but a lot more sane than the other options.
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…