From 5e0b6b3e757d717db5b13d15180d1e943c9a7e66 Mon Sep 17 00:00:00 2001 From: Vadym Barda Date: Mon, 29 Apr 2024 09:06:10 -0400 Subject: [PATCH] docs: update langserve link in LCEL docs (#20992) --- docs/docs/expression_language/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/expression_language/index.mdx b/docs/docs/expression_language/index.mdx index e204d29ce0225..9b970fda6db96 100644 --- a/docs/docs/expression_language/index.mdx +++ b/docs/docs/expression_language/index.mdx @@ -11,7 +11,7 @@ LCEL was designed from day 1 to **support putting prototypes in production, with 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. [**Async support**](/docs/expression_language/interface) -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](/docs/langsmith) 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. +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](/docs/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. [**Optimized parallel execution**](/docs/expression_language/primitives/parallel) 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.