Migrating from v0.0 chains: ConversationChain vs ConversationalRetrievalChain

[supreetkt]

Checked other resources

• I added a very descriptive title to this question.
• I searched the LangChain documentation with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.

Commit to Help

• I commit to help with one of those options 👆

Example Code

qa_chain = create_stuff_documents_chain(llm, qa_prompt)
convo_qa_chain = create_retrieval_chain(history_aware_retriever, qa_chain)
convo_qa_chain.invoke(
    {
        "input": "What are autonomous agents?",
        "chat_history": [],
    }
)

Description

The migrating v0.0 chains guide suggests using LCEL as a replacement for ConversationChain and certain different chains as a replacement for ConversationalRetrievalChain, namely history_aware_retriever, create_stuff_documents_chain and create_retrieval_chain.

Why does this differentiation exist? Why not use pipe operator like sequences for both of them? The LCEL documentation had seemed to suggest that this was the way to go, so it seems conflicting that the migration guide suggests something else but the LCEL documentation suggests something else.

System Info

Does not affect versions.

[dosubot[bot]]

The migrating v0.0 chains guide suggests using LCEL as a replacement for ConversationChain and different chains like history_aware_retriever, create_stuff_documents_chain, and create_retrieval_chain for ConversationalRetrievalChain instead of using pipe operator sequences for both because:

1. Clearer Internals: The ConversationalRetrievalChain hides an entire question rephrasing step which dereferences the initial query against the chat history. This means the class contains two sets of configurable prompts, LLMs, etc., making it less transparent.
2. Easier Return of Source Documents: The LCEL implementation allows for more straightforward retrieval and return of source documents.
3. Support for Runnable Methods: LCEL supports methods like streaming and async operations, which are not as easily managed with the legacy ConversationalRetrievalChain.
4. Unified Interface: LCEL provides a unified interface where every object implements the Runnable interface, defining a common set of invocation methods (invoke, batch, stream, ainvoke, etc.). This ensures consistent support for useful operations like streaming of intermediate steps and batching.
5. Composition Primitives: LCEL offers primitives that make it easy to compose chains, parallelize components, add fallbacks, and dynamically configure chain internals.
6. Extensibility and Customization: The parameters of the chain are typically surfaced for easier customization (e.g., prompts) over previous versions, which tended to be subclasses with opaque parameters and internals.

Supporting evidence and code from the document:

# Migrating from ConversationalRetrievalChain

The [`ConversationalRetrievalChain`](https://python.langchain.com/v0.2/api_reference/langchain/chains/langchain.chains.conversational_retrieval.base.ConversationalRetrievalChain.html) was an all-in one way that combined retrieval-augmented generation with chat history, allowing you to "chat with" your documents.

Advantages of switching to the LCEL implementation are similar to the [`RetrievalQA` migration guide](./retrieval_qa.ipynb):

- Clearer internals. The `ConversationalRetrievalChain` chain hides an entire question rephrasing step which dereferences the initial query against the chat history.
  - This means the class contains two sets of configurable prompts, LLMs, etc.
- More easily return source documents.
- Support for runnable methods like streaming and async operations.
- Unified interface with `Runnable` methods.
- Composition primitives for easy chain configuration.
- Extensibility and customization of chain parameters.

Additionally, the create_stuff_documents_chain is recommended over StuffDocumentsChain because it functions the same but with better support for streaming and batch functionality. It is also easier to extend and incorporate into other LangChain applications due to its use of LCEL primitives.

The LCEL implementation exposes the internals of what's happening around retrieving, formatting documents, and passing them through a prompt to the LLM, but it is more verbose. You can customize and wrap this composition logic in a helper function, or use the higher-level create_retrieval_chain and create_stuff_documents_chain helper methods ^[1][2][3][4].

To continue talking to Dosu, mention @dosu.

[supreetkt]

I see. I saw the internals of create_retrieval_chain etc. and they use LCEL. Ok thanks.