Feature Request: using kears-like api to build custom work flow instead of LCEL

[forestneo]

Checked

• I searched existing ideas and did not find a similar one
• I added a very descriptive title
• I've clearly described the feature request and motivation for it

Feature request

I propose to add a feature in langchain that allows the creation of custom workflows by building graphs through code. Currently, in langchain, LCEL can be used to connect different components to build users' custom processes. However, for those who are not familiar with coding, there is still a learning barrier. Therefore, I suggest constructing workflows in a block-based manner. Similar to LCEL, each block is executable. The code writer can assemble these blocks to build the workflow. Even in the near future, users could drag and customize workflows through interactive interfaces.

Motivation

The Keras API provides a clean way to assemble different models, as demonstrated by the following code snippet:

x = layers.Rescaling(1.0 / 255)(inputs)
x = layers.Conv2D(128, 3, strides=2, padding="same")(x)
x = layers.BatchNormalization()(x)
x = layers.Activation("relu")(x)

This serially chains four steps, similar to the LCEL representation Rescaling | Conv2D | BatchNormalization | Activation, making the code highly readable. Additionally, the plot_model function can visually represent this flow in a clear and concise manner:

I wish to introduce this feature into langchain. To illustrate the difference between LCEL and what we'll temporarily call "kears-chain," I've designed an example. Suppose a user writes a RAG process where the reranking is implemented through a function rather than as a component within the retriever. When insufficient content is recalled, the user wants to return a default answer, such as "No relevant content found in the database, please provide more information." Here is the flowchart:

The corresponding LCEL code for this flowchart is:

retriever = ...
rerank = ...
prompt_template = ...
llm = ...

chain = RunnableParallel(
    q=itemgetter('q'),
    docs=itemgetter('q') | retriever
) | RunnableBranch(
    (lambda x: len(x['docs']) < 1, RunnableLambda(lambda x: 'hello')),
    RunnableParallel(
        context=RunnableLambda(lambda x: rerank.compress_documents(documents=x['docs'], query=x['q'])),
        query=itemgetter('q')
    ) |
    RunnableParallel(
        context=RunnableLambda(lambda x: ','.join([_.page_content for _ in x['context']])),
        query=itemgetter('query')
    )  | prompt_template
)

r = chain.invoke({"q": "hello_query"})
print(r)

In contrast, our future "kears-chain" style code would assemble in blocks, with the following example code:

# The block component supports three types:
# 1. vearch components such as retriever, chat_models
# 2. python functions
# 3. define input and output

# define block，using naive langchain component or redesigning a new one called Block.
input_block = Block(name='input', type='input', keys=['q'])
retriever_block = Block(name='retriever', type='langchain', value=retriever)
rerank_block = Block(name='rerank', type='function', value=rerank.compress_documents)
prompt_block = Block(name='qa_prompt', type='function', value=prompt)
output_block = Block(name='output', type='output', value='docs is empty')

# construct flow
docs = retriever_block(input_block)
rerank_docs = rerank_block(docs, input_block)
prompt = prompt_block(rerank_docs, input_block)
llm_response = llm(prompt)

r = Branch(
    conditions=(len(docs) == 0),
    flows=(output_block),
    default_flow=llm_response
)

Proposal (If applicable)

We aim to achieve this by extending the LCEL approach or by building new components (Blocks) based on the Langchain component. From the user's perspective, there are two ways to construct workflows: the SDK approach and the interactive user interface approach. In the SDK, users simply need to define each block and the relationships between blocks. In the interactive interface, users can drag and drop components to connect them (similar to Langflow, but Langflow does not support user-defined workflows).

The example code above demonstrates how to build a custom user workflow through the SDK. During execution, each block will be parsed into LCEL (the specific parsing method is still in the design phase, but it is certain that this is feasible).