Let’s talk about AI agents and LangChain…

1 minute read

Let's talk about AI agents and LangChain...With LLMs, you need to "code agile". Just as teams need to adapt quickly to changes, these applications must be able to easily absorb technological developments.

Indeed, models, tools, methods and techniques are progressing daily. What is coded today could become obsolete in a few months. Along the way, you may want to change the LLM, vector store, embedding model, etc.

Of course, modularity is already a good practice, we haven't reinvented the wheel. But with the frantic pace of AI, we probably feel this need even more. The idea is to design the most decoupled blocks possible. For example, you can use abstract classes and implement the technical logic in child classes.

Nevertheless, some couplings may remain, for example prompt templates are closely linked to the chosen LLM models. Some technological choices will be more difficult to change. I'm thinking in particular of orchestrators like Langchain, which are central, which are involved in each of the blocks, and which already provide their share of abstractions.

I'll take this opportunity to provide some feedback on Langchain. For classic cases, it does its job, but if you want to do things that are slightly outside the scope, you quickly end up having to reimplement certain components. In general, very simple things become relatively complex to manage.

I ended up recoding a lot of bricks custom. It's more straightforward and easier to debug. The concept of chains is very interesting on paper, but in practice, there are lots of nebulous things and the documentation doesn't explain all the subtleties. Most of the time, I look directly at the code implementation to understand certain behaviors.

LangChain remains a nice utility brick, I use it in particular for the document loader, chunking and conversational memory management.

I haven't tested alternatives to Langchain yet, I'm looking forward to testing LlamaIndex or Haystack.