Skip to main contentü¶úÔ∏èüîó LangChainDocsUse casesIntegrationsAPICommunityChat our docsLangSmithJS/TS DocsSearchCTRLKGet startedIntroductionInstallationQuickstartLangChain Expression LanguageInterfaceHow toCookbookLangChain Expression Language (LCEL)Why use LCEL?ModulesModel I/‚ÄãORetrievalChainsMemoryAgentsCallbacksModulesSecurityGuidesMoreLangChain Expression LanguageWhy use LCEL?Why use LCEL?The LangChain Expression Language was designed from day 1 to support putting prototypes in production, with no code changes, from the simplest ‚Äúprompt + LLM‚Äù chain to the most complex chains (we‚Äôve seen folks successfully running in production LCEL chains with 100s of steps). To highlight a few of the reasons you might want to use LCEL:first-class support for streaming: when you build your chains with LCEL you get the best possible time-to-first-token (time elapsed until the first chunk of output comes out). For some chains this means eg. we stream tokens straight from an LLM to a streaming output parser, and you get back parsed, incremental chunks of output at the same rate as the LLM provider outputs the raw tokens. We‚Äôre constantly improving streaming support, recently we added a streaming JSON parser, and more is in the works.first-class async support: any chain built with LCEL can be called both with the synchronous API (eg. in your Jupyter notebook while prototyping) as well as with the asynchronous API (eg. in a LangServe server). This enables using the same code for prototypes and in production, with great performance, and the ability to handle many concurrent requests in the same server.optimised parallel execution: whenever your LCEL chains have steps that can be executed in parallel (eg if you fetch documents from multiple retrievers) we automatically do it, both in the sync and the async interfaces, for the smallest possible latency.support for retries and fallbacks: more recently we‚Äôve added support for configuring retries and fallbacks for any
The LangChain Expression Language was designed from day 1 to support putting prototypes in production, with no code changes, from the simplest ‚Äúprompt + LLM‚Äù chain to the most complex chains (we‚Äôve seen folks successfully running in production LCEL chains with 100s of steps). To highlight a few of the reasons you might want to use LCEL:
The LangChain Expression Language was designed from day 1 to support putting prototypes in production, with no code changes, from the simplest ‚Äúprompt + LLM‚Äù chain to the most complex chains (we‚Äôve seen folks successfully running in production LCEL chains with 100s of steps). To highlight a few of the reasons you might want to use LCEL: ->: Skip to main contentü¶úÔ∏èüîó LangChainDocsUse casesIntegrationsAPICommunityChat our docsLangSmithJS/TS DocsSearchCTRLKGet startedIntroductionInstallationQuickstartLangChain Expression LanguageInterfaceHow toCookbookLangChain Expression Language (LCEL)Why use LCEL?ModulesModel I/‚ÄãORetrievalChainsMemoryAgentsCallbacksModulesSecurityGuidesMoreLangChain Expression LanguageWhy use LCEL?Why use LCEL?The LangChain Expression Language was designed from day 1 to support putting prototypes in production, with no code changes, from the simplest ‚Äúprompt + LLM‚Äù chain to the most complex chains (we‚Äôve seen folks successfully running in production LCEL chains with 100s of steps). To highlight a few of the reasons you might want to use LCEL:first-class support for streaming: when you build your chains with LCEL you get the best possible time-to-first-token (time elapsed until the first chunk of output comes out). For some chains this means eg. we stream tokens straight from an LLM to a streaming output parser, and you get back parsed, incremental chunks of output at the same rate as the LLM provider outputs the raw tokens. We‚Äôre constantly improving streaming support, recently we added a streaming JSON parser, and more is in the works.first-class async support: any chain built with LCEL can be called both with the synchronous API (eg. in your Jupyter notebook while prototyping) as well as with the asynchronous API (eg. in a LangServe server). This enables using the same code for prototypes and in production, with great performance, and the ability to handle many concurrent requests in the same server.optimised parallel execution: whenever your LCEL chains have steps that can be executed in parallel (eg if you fetch documents from multiple retrievers) we automatically do it, both in the sync and the async interfaces, for the smallest possible latency.support for retries and fallbacks: more recently we‚Äôve added support for configuring retries and fallbacks for any