Contrast declarative LLM frameworks (DSPy, BAML) with imperative ones (LangChain, LlamaIndex) on what each optimizes for. Then pick the family you would use for a metric-driven information-extraction pipeline that runs on a labeled trainset, and defend the choice.
Free · 2 AI evals / day
**Imperative frameworks** like LangChain and LlamaIndex are about composition. You write the prompt, you write the chain, you tune it by hand. Every step is visible and inspectable.
**Declarative frameworks** like DSPy and BAML take a different approach. You declare what the function should do (a Signature in DSPy, a function schema in BAML), and an optimizer or compiler turns that declaration into the actual prompt and few-shot examples. You stop writing prompts and start writing specifications and metrics.
For a metric-driven extraction pipeline with a labeled trainset, declarative wins clearly. You already have the two things an optimizer needs: examples (the trainset) and a way to score outputs (the metric, like exact match or F1). DSPy's `BootstrapFewShot` or `MIPROv2` uses both to compile a prompt that scores higher than what you would write by hand. If you used LangChain instead, the labeled data sits unused except for manual prompt tweaking, which wastes the most valuable thing you have.
**Declarative** vs **imperative** is a question about who writes the prompt, not about composition.
Declarative frameworks (DSPy, BAML) treat the prompt as the *output* of an optimization process. You declare a Signature (input fields and output fields with semantic descriptions), wrap it in a Module, and pass a metric plus a trainset to an Optimizer like `BootstrapFewShot` or `MIPROv2`. The compiler searches the prompt and demonstration space and produces a compiled program. You never write the final prompt. The optimizer does. The cost is opacity: harder to read the exact prompt at runtime, harder to attribute a single bad output to a specific edit.
Imperative frameworks (LangChain, LlamaIndex) treat the prompt as the *input* you write. Every Runnable, every ChatPromptTemplate, every output parser is the thing you authored. Debuggability is excellent, observability hooks line up cleanly, but the human is the optimizer.
For a metric-driven extraction pipeline with a labeled trainset, declarative wins decisively. The trainset plus metric is exactly the input shape an optimizer wants. DSPy will compile a better prompt than you would by hand, in less developer time. Using LangChain here wastes the labels.
Quick reference
TL;DR
Declarative frameworks compile prompts against a metric and a trainset, imperative ones execute prompts you wrote, so a labeled extraction job is a near-perfect fit for DSPy or BAML.
Imagine you want to bake bread. The imperative approach is a recipe you write down: do step 1, then 2, then 3. If the bread is bad, you tweak the recipe by hand. The declarative approach is more like telling an apprentice 'here are 200 loaves I judged good or bad, and here is the taste test I care about, go figure out a recipe that scores well.' The apprentice tries variations and reports back the best one. With labeled data and a clear metric, the apprentice wins easily. Without them, the recipe you write yourself is more readable and easier to fix.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
You have no labeled trainset and no agreed metric for the task DSPy's optimizer has nothing to optimize against, you would be hand-writing prompts inside a framework that adds compile-time machinery for no payoff.
The task requires step-level traceability for audit or compliance (every prompt must be reviewable in the trace) Compiled prompts are opaque relative to hand-authored ones, an imperative LangChain or LlamaIndex pipeline is easier to defend in audit.
Your team is TS-first and you want compile-time type checking across services DSPy is Python-centric, BAML or a thin Vercel AI SDK + Zod stack fits better, the right framework depends on the language ecosystem, not just declarative vs imperative.
Quick scan · 2–4 min
Everything important, quickly.
6 to 8 min: what each family optimizes for + DSPy compile loop + BAML codegen + when imperative wins + why labels + metric make declarative the right pick for extraction.
Real-world examples
Real products, models, and research that use this idea.
1DSPy's STORM (Stanford) compiles multi-hop research agents from a metric on draft quality, the prompts are not hand-written.
2BAML at Lyft and Notion generates typed extraction functions across TS and Python from one schema, with parsing built in.
3LangChain LCEL powers many 2026 production RAG stacks where teams value step-level traces in LangSmith over auto-tuning.
4LlamaIndex QueryEngines are imperative composition for data-centric RAG, with explicit retriever / postprocessor / synthesizer layers.
5Outlines and Instructor are imperative siblings to BAML. Explicit structured output, no compile step, no metric loop.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does DSPy's MIPROv2 differ from BootstrapFewShot, and when do you pick each?
Sign in or go Pro to see the approach for this follow-up.
QHow do you serve a DSPy-compiled program in production, and what is the rollback story?
Sign in or go Pro to see the approach for this follow-up.
QCould you bolt DSPy's optimizer onto a LangChain chain?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating DSPy as 'just another chain library.' The whole point is the compile step: signature + module + optimizer + metric, not pipe-operator composition.