Langchain Is Pointless

• EdgeChains

  12 284 9.3 JavaScript

  EdgeChains.js Typescript/Javascript production-friendly Generative AI. Based on Jsonnet. Works anywhere that Webassembly does. Prompts live declaratively & "outside code in config". Kubernetes & edge friendly. Compatible with OpenAI GPT, Gemini, Llama2, Anthropic, Mistral and others

  

this is precisely the problem i encountered and tried to solve with Edgechains. we think Generative AI is a config management problem (like Terraform or Kubernetes).

>None of this stuff is reusable. Langchain is attempting to set up abstractions to reuse everything. But what we end up with a mediocre DAG framework where all the instructions/data passing through is just garbage. The longer the chain, the more garbage you find at the output.

chains X prompts X LLMs == pods X services X nodes in Terraform.

So we model it on top of config management grammar that is proven to work in large production config - jsonnet.

A trivial example is this - https://github.com/arakoodev/EdgeChains/blob/main/Examples/r...

Would love to get an example of complex chains (even if u have an ARxiv paper) that you think we could solve in Edgechains-jsonnet ?

• langstream

  4 379 8.7 Python

  Build robust LLM applications with true composability 🔗

I agree, I really don’t like LangChain abstractions, the chains they say are “composable” are not really, you spend more time trying to figure out langchain than actually building things with it, and it seems it’s not just me after talking to many people

Their code seems all rushed, and seems it worked out for initial popularity, but with their current abstractions I personally don’t think it’s a good long term framework to learn and adopt

That’s why I built my own alternative to it, I call it LiteChain, where the chains are actual composable monads, the code is async streamed by default not ducktaped, it’s very bare bones yet but I’m really putting effort on building a solid foundation first, and having a final simple abstractions for users that don’t get in the way, check it out:

https://github.com/rogeriochaves/litechain

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• hamilton

  20 1,312 9.8 Jupyter Notebook

  Hamilton helps data scientists and engineers define testable, modular, self-documenting dataflows, that encode lineage and metadata. Runs and scales everywhere python does.

  

I had been hearing these pains from Langchain users for quite a while. Suffice to say I think:

1. too many layers of OO abstractions are a liability in production contexts. I'm biased, but a more functional approach is a better way to model what's going on. It's easier to test, wrap a function with concerns, and therefore reason about.

2. as fast as the field is moving, the layers of abstractions actually hurt your ability to customize without really diving into the details of the framework, or requiring you to step outside it -- in which case, why use it?

Otherwise I definitely love the small amount of code you need to write to get an LLM application up with Langchain. However you read code more often than you write it, in which case this brevity is a trade-off. Would you prefer to reduce your time debugging a production outage? or building the application? There's no right answer, other than "it depends".

To that end - we've come up with a post showing how one might use Hamilton (https://github.com/dagWorks-Inc/hamilton) to easily create a workflow to ingest data into a vector database that I think has a great production story. https://open.substack.com/pub/dagworks/p/building-a-maintain...

Note: Hamilton can cover your MLOps as well as LLMOps needs; you'll invariably be connecting LLM applications with traditional data/ML pipelines because LLMs don't solve everything -- but that's a post for another day.

• haystack

  54 13,633 9.9 Python

  :mag: LLM orchestration framework to build customizable, production-ready LLM applications. Connect components (models, vector DBs, file converters) to pipelines or agents that can interact with your data. With advanced retrieval methods, it's best suited for building RAG, question answering, semantic search or conversational agent chatbots.

  

there is an alternative that is production-grade - deepset haystack https://haystack.deepset.ai/

p.s. i am contributor so there could be bias

• duckduckgo-locales

  2,077 94 0.0 Perl

  Translation files for <a href="https://duckduckgo.com"> </a>

  

• aipl

  4 119 9.2 Python

  Array-Inspired Pipeline Language

I agree, and that's why I've been working on AIPL[0]. Our first v0.1 release should be in the next few days. https://github.com/saulpw/aipl

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.

• txtai

  355 6,990 9.3 Python

  💡 All-in-one open-source embeddings database for semantic search, LLM orchestration and language model workflows

  

If you'd like another option built on a foundation of open LLMs, open models and open source, check out txtai (https://github.com/neuml/txtai).

Disclaimer: I am the author of txtai

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• modelfusion

  18 883 9.9 TypeScript

  The TypeScript library for building AI applications.

  

If you’re using JS/TS and want to have a nicer API for LLM calls (and a bit more), check out https://github.com/lgrammel/ai-utils.js

• langchain

  152 56,526 10.0 Python

  Discontinued ⚡ Building applications with LLMs through composability ⚡ [Moved to: https://github.com/langchain-ai/langchain] (by hwchase17)

  

Yeah I never know where memory goes exactly in langchain, it's not exactly clear all the time. But sure, the main insight I remember is this, take a look at their MULTI_PROMPT_ROUTER_TEMPLATE: https://github.com/hwchase17/langchain/blob/560c4dfc98287da1...

It's a lot of instructions for an LLM, they seem to forget an LLM is an auto-completion machine, and which data it is trained on. Using <<>> for sections is not a normal thing, it's not markdown, which probably the thing read way more often on the internet, instead of open json comments, why not type signatures, instead of so many rules, why not give it examples? It is an autocomplete machine!

They are relying too much on the LLM being smart because they probably only test stuff in GPT-4 and 3.5, but with GPT4All models this prompt was not working at all, so I had to rewrite it, for simple routing, we don't even need json, carying the `next_inputs` here is weird if you don't need it.

So this is my version of it: https://gist.github.com/rogeriochaves/b67676977eebb1936b9b5c...

It's so basic it's dumb, yet it is more powerful, as it does not rely on GPT-4 level intelligence, it's just what I needed

• tree-of-thought-llm

  41 4,152 7.2 Python

  [NeurIPS 2023] Tree of Thoughts: Deliberate Problem Solving with Large Language Models

  

Tree of thoughts: https://arxiv.org/abs/2305.10601

Good video on "Tree of thoughts" which also reviews / puts it in the context of other methods: https://www.youtube.com/watch?v=ut5kp56wW_4

Completion vs conversational interface is something you can read about in the OpenAI API documentation.

For the remaining things I don't have single specific pointer at hand.

Suggest a related project