44 docs tagged with "langchain"

A chain has edges you fixed at design time: step A always leads to step B. An agent hands that decision to the model — the next step is chosen at runtime, from the model's own output.

Every Runnable exposes sync and async twins (invoke/ainvoke, batch/abatch, stream/astream, from Runnables and LCEL), plus batch for running many independent inputs efficiently.

Two independent caches matter in a LangChain app, and they solve different problems.

There is no server-side "memory" object that magically remembers a user. Memory is just the message list you re-send on every call. Each turn, you append the new human message, invoke the model, append its reply, and send the whole (possibly trimmed) list back next time.

initchatmodel builds a chat model from a model name and provider string, so switching providers is a one-line change rather than a different import per vendor.

A LangGraph agent that remembers a conversation across turns and processes, with a token budget so it doesn't grow unbounded — thread persistence and trimming applied together rather than explained again here.

Chroma is a local-first, embedded vector database — no server to run, one pip install, data on disk. It's the default recommendation for learning and prototyping in this section.

The @tool decorator turns a typed, documented function into something a model can call:

Every retrieval pipeline starts by turning some external source — a PDF, a web page, a database table — into LangChain's shared unit: the Document.

An embedding model turns text into a fixed-length vector of numbers positioned so that semantically similar text ends up nearby in that vector space. That's the entire mechanism retrieval is built on: instead of matching keywords, you compare vectors.

FAISS is an in-process similarity search library — the index lives in memory inside your Python process, with no server and no persistence unless you save it explicitly.

LangChain 1.x ships as a set of small, independently-versioned packages instead of one monolith. Installing langchain alone gets you the orchestration layer — prompts, chains, agents — but no model provider.

LangChain reads provider credentials from environment variables by default. The standard pattern is a .env file loaded with python-dotenv, never a key typed directly into source.

A chat model's input and output are both lists of typed message objects, not raw strings. Each message type maps to a role.

Tool selection quality degrades as the tool list grows — with a handful of well-named tools the model picks correctly almost every time; past a few dozen, overlapping descriptions start colliding and the wrong tool gets called more often.

An output parser sits at the end of a chain and reshapes a model's raw output into something your code can use.

LangChain's packages form a dependency tree. Understanding the direction of that tree tells you which package to import an abstraction from, and which packages are safe to depend on for the long term.

Real chains are rarely a single straight line. RunnableParallel runs several steps against the same input concurrently, RunnablePassthrough threads the original input through unchanged so a later step can still see it, and RunnableBranch picks one path out of several based on a condition.

pgvector is a Postgres extension that adds a vector column type and nearest-neighbour operators, so embeddings live next to the relational data they describe instead of in a separate system.

Pinecone is a managed, hosted vector database — no infrastructure to run, but the index itself is a billed cloud resource rather than a free local file.

The | operator builds a RunnableSequence, as introduced in Runnables and LCEL. Each step's output becomes the next step's input, and the types have to line up — a prompt template's PromptValue output must be something the chat model's invoke accepts, and so on down the chain.

A prompt template turns a dict of variables into a PromptValue the model can consume. ChatPromptTemplate is the one you'll use almost everywhere; PromptTemplate produces a plain string instead of a message list.

A citation-aware version of the RAG pipeline: load a folder of PDFs, chunk them while keeping page numbers, embed into Chroma, and answer with a reference back to the source page.

Retrieval-Augmented Generation combines everything in this section into one flow: load documents, split them, embed them into a searchable index, then at query time retrieve the relevant chunks and hand them to a model alongside the question.

createagent builds a ReAct-style agent — reason, act, observe, repeat — from a model and a tool list. The constructor itself lives in LangGraph's prebuilt layer; langchain.agents.createagent is the stable entry point.

A retriever is the interface between a query and a candidate set of relevant chunks. Every vector store exposes one through as_retriever, which returns a VectorStoreRetriever — a Runnable, so it composes with | like anything else in this reference.

Any Runnable can be wrapped with retry and fallback behavior, and any call can carry per-invocation configuration — without changing the chain's shape.

Every composable piece in LangChain — prompts, chat models, parsers, retrievers, custom functions — implements the same interface: Runnable. LCEL (LangChain Expression Language) is just the | operator composing Runnables into a RunnableSequence, as shown in Your First Chain.

An LLM app has trust boundaries that don't exist in a normal backend: text the model reads can also steer the model. Anything that isn't your own code is untrusted input.

An agent that answers questions over a database: it introspects the schema, writes a query, runs it, and reasons over the result — the tool-calling loop applied to SELECT statements.

stream (sync) and astream (async) yield output incrementally instead of waiting for the whole result. For a chat model alone, that means tokens as they're generated:

Turn a pile of unstructured documents into validated records — structured output run in a batch loop, with a place to put the ones that don't validate.

withstructuredoutput wraps a chat model so it returns a validated Pydantic object instead of prose you then have to parse. The provider enforces the schema at generation time (constrained decoding or native tool-calling), which is far more reliable than parsing free-form output after the fact.

Embedding models and context windows both have limits, so a loaded Document almost always needs to be broken into smaller pieces — chunks — before it can be indexed. Splitting is where retrieval quality is won or lost; get it wrong and no amount of prompt tuning fixes it downstream.

"LangChain" is often used loosely to mean four separate projects that compose together: LangChain

The model never executes anything. It only requests a call — your code decides whether to honour it, runs it, and reports the result back.

An unbounded chat history eventually exceeds the model's context window, and even before that, it inflates every call's token cost and latency. Two standard strategies keep it in check.

Common failure modes across this section, and where to go for the full explanation.

| Store | Local / Hosted | Setup effort | Metadata filtering | Scale ceiling | Cost model | Pick it when |

A vector store persists embedded chunks and answers nearest-neighbour queries. Every implementation in this folder — Chroma, FAISS, pgvector, Pinecone — sits behind the same VectorStore interface, so swapping the backend later is mostly a constructor change, not a rewrite.

PyPI

PyPI

A framework earns its keep when it removes real complexity. For the simplest LLM use case — one

A minimal chain: a prompt template feeds a chat model, whose output feeds a parser. The | operator wires them together.