Frameworks and Orchestration · Declarative Optimization with DSPy¶

DSPy treats instructions, examples, or trainable model parameters as optimization targets within a program. Signatures and modules first form a runnable program; developers then choose an optimizer, data, metrics, and a budget. This does not eliminate handwritten task instructions, program-structure design, or independent testing.

Chapters¶

How the components fit together¶

flowchart LR
    A["Signature<br/>Declare the input/output contract"] --> B["Module<br/>Predict / ChainOfThought / ReAct"]
    B --> C["Program<br/>Compose modules"]
    C --> D["Choose an optimizer by search target"]
    D -->|"Example / instruction search"| E["Prompts / few-shot examples"]
    D -->|"For example, BootstrapFinetune"| F["Weights of a fine-tunable model"]
    E -.Feed back.-> C
    F -.Deploy and configure.-> C

Reading suggestions¶

Start with Chapter 16 to understand how signatures, modules, and programs separate “what to do” from “how to do it.” Then read Chapter 17 to see how compilation uses that separation to search automatically for better implementations.
To compare with LangChain and LlamaIndex, these chapters discuss how DSPy's evaluation loop differs from LangSmith-style observability. Read LangChain Ecosystem · Production Feedback Loops first, then return to make the comparison.
If your main question is whether DSPy is worth adopting, go directly to Chapter 17, Section 17.4, then compare with Framework Selection and Portable Architecture.
Read alongside the official optimizer guide. Understanding why GEPA needs meaningful feedback, why a validation set cannot serve as the final test set, and whether compilation makes each inference request more expensive matters more than memorizing optimizer names.

Back to AI Frameworks and Orchestration.