DSPy Framework Vocabulary: English for Declarative LLM Programming

DSPy reimagines how engineers build LLM-powered systems by replacing hand-crafted prompts with a programming model that can optimise itself. Instead of manually writing and tweaking prompt strings, you define the behaviour you want — and DSPy finds the prompts and few-shot examples that achieve it.

If you are learning DSPy or joining a team that uses it, the vocabulary can be unfamiliar at first. This guide explains the key terms so you can read the documentation, participate in code reviews, and discuss DSPy architecture confidently.

Key Vocabulary

Signature

A signature in DSPy is a declarative specification of what an LLM call should do: its input fields, output fields, and a natural-language description of the task. Rather than writing a raw prompt, you define a signature like "question -> answer" and DSPy handles the prompt construction.

“Instead of maintaining a fragile prompt string, we defined a DSPy signature — if the underlying model changes, we just recompile rather than rewrite all our prompts.”

Module

A module is the building block of a DSPy programme. Each module wraps a call to a language model (or a composition of calls) and exposes a clean Python interface. Modules can be composed together, just like layers in a neural network, to build complex pipelines.

“Our pipeline has three modules in sequence: a retrieval module, a reasoning module, and a formatting module. Each one can be optimised independently.”

Optimizer (Teleprompter)

An optimizer (historically called a teleprompter in early DSPy versions) is an algorithm that automatically improves a DSPy programme. It searches over possible prompts, instructions, and few-shot demonstrations to maximise a metric you define. Examples include BootstrapFewShot, MIPRO, and BayesianSignatureOptimizer.

“We ran the BootstrapFewShot optimizer overnight and it found a set of demonstrations that improved our answer accuracy from 61% to 74% — without us writing a single example by hand.”

Compiled Program

A compiled program is a DSPy programme after it has been through the optimizer. The optimizer has filled in the concrete prompts, instructions, and demonstrations that the programme will use at inference time. Compilation is analogous to training in machine learning — you run it once and then deploy the compiled artefact.

“We store the compiled programme as a JSON file and load it at startup — recompilation only happens when the metric drops or we change the pipeline architecture.”

Few-Shot Compilation

Few-shot compilation is the process by which DSPy’s optimizer selects and bootstraps demonstration examples (few-shot examples) to include in the prompts of each module. Rather than manually curating examples, the optimizer generates candidate demonstrations using the pipeline itself and evaluates which ones improve the metric.

“The optimizer bootstrapped 50 candidate demonstrations from our training set and selected the 8 that most improved validation accuracy — that’s few-shot compilation in action.”

Chain of Thought

Chain of Thought (CoT) is a reasoning strategy where the LLM is prompted to write out intermediate reasoning steps before giving its final answer. In DSPy, ChainOfThought is a built-in module that adds a rationale output field to any signature, automatically prompting the model to reason step by step.

“Switching from Predict to ChainOfThought for our multi-step reasoning module improved accuracy by 12 percentage points — the model errors were happening because it was jumping to conclusions.”

Bootstrapping

Bootstrapping in DSPy refers to the process of generating labelled training examples automatically by running the pipeline on unlabelled inputs and keeping the outputs that satisfy the metric. It allows you to build a training set without manually annotating examples.

“We only had 20 manually labelled examples, but after bootstrapping we had 400 high-quality demonstrations for the optimizer to work with.”

Metric

A metric in DSPy is a function that scores a programme’s output — it takes the input, the expected output, and the actual output, and returns a score. The optimizer uses the metric to judge which prompts and demonstrations are best. Defining a good metric is one of the most important engineering decisions when using DSPy.

“Our metric checks three things: factual accuracy, citation presence, and response length. We spent more time designing the metric than building the pipeline itself.”

Useful Phrases

• “The signature tells DSPy what the module needs to do — the optimizer figures out how to prompt the model to do it.”
• “We haven’t touched a raw prompt string in months — everything goes through DSPy signatures and the optimizer handles the rest.”
• “Recompilation took about two hours on our validation set, but now the programme adapts automatically when we swap the underlying model.”
• “The ChainOfThought module improved performance significantly, but it roughly doubles token usage — we’re evaluating whether the quality gain is worth the cost.”
• “Our metric is the most critical piece of the whole system — if the metric is wrong, the optimizer will confidently produce the wrong programme.”

Common Mistakes

Confusing “compiling” with traditional code compilation

When engineers first hear that DSPy “compiles” a programme, they sometimes think this means transpiling Python code or generating binary artefacts. In DSPy, compilation is an optimisation process that finds good prompts and demonstrations — not a traditional compile step. The output is a set of prompt strings and examples, not compiled code. Say “we compiled the DSPy programme against our validation set”, not “we built the DSPy binary”.

Using “teleprompter” in current documentation

Early DSPy versions used the term teleprompter for what is now called an optimizer. If you read older tutorials or papers, you will encounter this term. In current DSPy (v2.x), the correct term is optimizer. Using “teleprompter” in a modern code review or documentation may cause confusion for readers who only know the newer terminology.

Treating the metric as an afterthought

A common mistake is to build the pipeline first and define a rough metric quickly at the end. In DSPy, the metric is the specification — it determines what “better” means. A vague or poorly calibrated metric produces a compiled programme that scores highly on the metric but fails in practice. Teams that struggle with DSPy often have a metric problem, not a pipeline problem.

DSPy represents a significant shift in how LLM applications are engineered — from prompt artistry to software engineering. The vocabulary above captures the most important concepts in this model: you declare what you want (signatures), compose it into a pipeline (modules), define what “good” means (metrics), and let the optimizer find how to achieve it (compilation). Once these concepts click, the DSPy documentation becomes much easier to navigate.

Related Posts

• AI and Machine Learning Vocabulary: LLM, RAG, Embeddings Explained
• AI Agents Vocabulary: Agent Loop, ReAct, Tool Calling, and Agentic Systems Explained
• Hallucination Explained in English

Bridging the Gap: Addressing Specific Challenges for Non-Native Speakers

DSPy’s core philosophy – declarative programming for Large Language Models – is already a shift for many developers. Adding precision to your communication around it, particularly when dealing with technical discussions and collaborating on code, can be significantly harder for those whose first language isn’t English. We often focus on the what of DSPy functionality, but less so on the nuanced ways these concepts are discussed in professional settings. It’s not just about knowing “optimizer” translates to “optimization,” it’s about understanding the context, the expected tone, and the phrasing used when describing a particular problem or solution. For example, a colleague might say, “The teleprompter is pulling too much context from the initial prompt – we need to reduce its scope.” A non-native speaker could interpret this literally as needing to physically use a teleprompter, leading to confusion. Similarly, discussions around “few-shot compilation” can quickly become dense with terminology if not carefully explained. The key is recognizing that professional English isn’t just about individual words; it’s about conveying meaning efficiently and accurately within established conventions. This section aims to provide targeted vocabulary and phrasing designed to smooth these transitions for developers from diverse linguistic backgrounds. We’ll focus on situations you might actually encounter, like code reviews or team communication, offering concrete examples of how to articulate your ideas effectively. It’s about building confidence and reducing ambiguity in a collaborative environment.

A common hurdle is understanding the difference between “signature” and “module.” While technically related – both describe components within the DSPy framework – their usage often differs subtly. A code review comment might read: “This module’s signature needs to be more granular; it’s currently exposing too many internal parameters.” This isn’t simply saying the module is poorly designed, but rather pointing out a specific issue with its interface. The “signature” refers to the inputs and outputs of the module – what data it accepts and what results it produces. Conversely, a “module” represents the logical unit itself, encapsulating the code that implements a particular function within the LLM pipeline. Another frequent area for misunderstanding is the concept of “Chain of Thought” prompting. When submitting a Pull Request describing a change, you might write: “Implemented Chain of Thought to improve reasoning accuracy by explicitly guiding the model through intermediate steps.” This emphasizes not just that Chain of Thought was used, but why – that it’s intended to enhance the model’s ability to reason. Focusing on these details helps clarify intent and avoid misinterpretations.

Let’s illustrate this with a practical example. Suppose you are debugging an issue where the LLM is consistently generating incorrect answers when processing complex prompts. You could use the following command in the DSPy CLI to inspect the module’s execution flow:

dspy trace --module my_complex_module --depth 3

This command would initiate a tracing session, allowing you to examine the steps taken within my_complex_module during prompt processing. The output – which might contain lines like “Teleprompter invoked with context size 128” or “Optimizer applied heuristic delta-one” – could then be used as the basis for further discussion. You’d explain, “The trace shows that the teleprompter is pulling in a significant amount of contextual information, potentially overwhelming the module’s core processing capabilities.” This phrasing is more precise and actionable than simply saying “the teleprompter is broken.” It directly relates to observed behavior and suggests a potential area for optimization. Remember, clear and specific communication minimizes ambiguity and fosters effective collaboration within your team.

Finally, don’t hesitate to ask clarifying questions – it’s always better to seek understanding than to make assumptions. Using phrases like “Could you elaborate on what you mean by ‘granular signature’ in this context?” demonstrates a willingness to learn and prevents misunderstandings. Building vocabulary around DSPy isn’t just about learning new terms; it’s about developing the communication skills needed to thrive in a complex, rapidly evolving field.