Get AI summaries of any video or article — Sign up free
Structured Output in LangChain | Generative AI using LangChain | Video 5 | CampusX thumbnail

Structured Output in LangChain | Generative AI using LangChain | Video 5 | CampusX

CampusX·
6 min read

Based on CampusX's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Structured output converts LLM free-form text into schema-based objects that software can parse, store, and validate.

Briefing

Structured output in LangChain is the practical bridge that lets large language models return data in a predictable format—so databases, APIs, and agent tools can consume it reliably. Instead of getting free-form text (“unstructured output”), the model is guided to emit responses in a well-defined schema such as JSON-like structures. That single shift matters because it turns LLM output from something humans must read into something software can parse, validate, and store.

The walkthrough starts by contrasting unstructured text responses with structured responses. A typical LLM answer to a travel-planning prompt might be a paragraph of suggestions. Structured output changes the same task so the response becomes a structured object—e.g., multiple itinerary entries stored as dictionaries with fields like time and activity. LangChain’s structured output feature formalizes this idea: it’s the practice of having language models return responses in a “well-defined data format,” making integration with other systems straightforward.

Three high-impact use cases are highlighted. First is data extraction: sending resumes or documents to an LLM and requesting a JSON-formatted result that can be inserted into a database. The example centers on a job portal (like a Naukri-style workflow), where candidate details such as name, last company, and 10th/12th marks are extracted and stored programmatically.

Second is API building from unstructured reviews. Long product reviews (e.g., from an e-commerce site) can be transformed into structured fields like topic, pros, cons, and overall sentiment. That structured payload can then power an API built with services such as Flask or FastAPI, making the output consumable by clients across the internet.

Third is enabling agents to use tools. Agents often need numeric or tool-specific inputs, but LLMs naturally produce text. Structured output becomes the mechanism for extracting the exact parameters an external tool expects—such as pulling the number “2” from a prompt so a calculator tool can compute the square root. The key point: tools can’t reliably interpret raw text; they need structured arguments.

After establishing the concept, the tutorial moves into implementation details using LangChain’s structured output workflow. For models that support structured output natively, the core function used is with_structured_output. The tutorial then demonstrates three ways to specify the output format: (1) TypedDict, (2) Pydantic models, and (3) JSON Schema.

TypedDict is presented as a lightweight way to define expected keys and types for Python-only projects, mainly improving editor/type-hint guidance. Pydantic is positioned as more robust because it adds validation and parsing: it can reject invalid types (e.g., an integer where a string is required), support optional fields, perform implicit type coercion when reasonable (e.g., converting a numeric string to an int), and validate built-in types like email addresses. It also supports constraints via Field (including ranges and regex-style checks) and can serialize results into dict or JSON.

Finally, JSON Schema is framed as the cross-language option for multi-stack systems where Python backends and JavaScript frontends both need the same contract. The tutorial also distinguishes two modes for structured output: JSON mode (best when the model should return JSON) and function calling (best when the structured output is meant to trigger tool/function execution). A practical warning closes the loop: some open-source models may not support either mode, requiring alternative approaches such as output parsing in later lessons.

Cornell Notes

Structured output in LangChain turns LLM responses from free-form text into predictable, schema-based data that software can parse and store. Instead of returning paragraphs, the model is guided to output objects with specific fields (e.g., summary and sentiment, or itinerary entries with time and activity). This enables reliable integrations for data extraction, API building from reviews, and agent tool usage where external tools require exact argument types. The tutorial demonstrates three schema-specification approaches—TypedDict, Pydantic, and JSON Schema—and explains when to use each. It also contrasts JSON mode vs function calling, noting that some models may not support structured output modes and may require output parsing later.

Why does structured output matter more than “just asking for JSON” from an LLM?

Structured output is about enforcing a contract: the model is constrained to return data in a well-defined format that downstream code can consume. In the tutorial’s examples, this contract enables (1) extracting resume fields into a database-ready object, (2) converting long product reviews into fields like topics/pros/cons/sentiment for an API response, and (3) feeding agents with tool-ready parameters (e.g., extracting the numeric argument needed by a calculator tool). Without structured output, the model’s text is harder to parse and less reliable for programmatic integration.

How do TypedDict, Pydantic, and JSON Schema differ in what they guarantee?

TypedDict mainly provides a schema-like shape for Python and helps with editor/type-hint guidance; it does not inherently stop invalid runtime values. Pydantic adds real validation and parsing: it can throw errors when types don’t match (e.g., rejecting an integer for a field declared as a string), handle optional fields (missing values become None), and perform type coercion when appropriate (e.g., converting a numeric string to an int). JSON Schema is a language-agnostic contract used when multiple languages must share the same structure (e.g., Python backend and JavaScript frontend).

What are the practical benefits of Pydantic features like Field constraints and built-in validators?

Field lets developers attach constraints and metadata to fields—such as requiring a CGPA value to fall within a range (0 to 10) and rejecting out-of-bounds inputs. Pydantic also includes built-in validators such as email validation: an invalid email string triggers an error, while a properly formatted email passes. These checks matter when LLM outputs must be trustworthy enough for APIs and storage.

When should JSON mode be used versus function calling in LangChain structured output?

JSON mode is used when the desired structured result should come back as JSON (common for standard extraction tasks). Function calling is used when the structured output is meant to drive tool/function execution—typical in agent workflows where the agent must call an external tool with precise arguments. The tutorial also notes that model support differs: some models may not support either mode, which can force a fallback to output parsing later.

How does structured output help agents use tools that expect specific input types?

Agents often receive prompts as text, but tools (like calculators) expect typed inputs such as numbers. Structured output extracts the required parameters from the LLM’s text into the exact argument types the tool needs. For example, an agent can parse “find the square root of two” into a numeric input for the calculator, rather than sending raw text that the tool can’t interpret.

What does “optional fields” solve in structured outputs?

Optional fields handle cases where the LLM may not find certain information in the input text. For instance, a review might not mention pros or cons, so those fields should be allowed to be missing. In Pydantic, optional fields can be declared as Optional[...] and will become None when absent, preventing schema failures and making downstream handling more robust.

Review Questions

  1. In what scenarios would TypedDict be sufficient, and when would Pydantic be the safer choice?
  2. Explain how structured output enables agent tool calls, using the idea of extracting tool-ready arguments.
  3. What are the key differences between JSON mode and function calling, and why does model support affect the choice?

Key Points

  1. 1

    Structured output converts LLM free-form text into schema-based objects that software can parse, store, and validate.

  2. 2

    Data extraction, review-to-API transformation, and agent tool parameterization are three core integration use cases.

  3. 3

    TypedDict defines expected keys/types for Python-focused projects, while Pydantic adds runtime validation, optional fields, and type coercion.

  4. 4

    JSON Schema provides a cross-language contract for systems where multiple frontends/backends must agree on the same structure.

  5. 5

    Pydantic Field supports constraints (like numeric ranges) and metadata, and built-in validators (like email) can reject invalid outputs.

  6. 6

    LangChain structured output can run in JSON mode or function-calling mode depending on whether the result is for JSON consumption or tool/function execution.

  7. 7

    Model support varies: some open-source models may not support structured output modes, requiring alternative approaches such as output parsing later.

Highlights

Structured output is the mechanism that lets LLM results become database/API-ready data instead of human-readable text.
Pydantic turns schema definitions into enforceable validation—invalid types can trigger errors, and optional fields can safely become None.
JSON Schema is the universal contract when Python and JavaScript (or other languages) must share the same output structure.
JSON mode fits JSON-return workflows; function calling fits agent/tool execution workflows where structured arguments must be passed to functions.