Build confidence with DSPy's programming model — signatures, predictors, retrievers, and the compile-time optimisation loop.
0 / 5 completed
1 / 5
In a code review, a teammate questions why you used dspy.ChainOfThought instead of dspy.Predict. The key difference is:
dspy.ChainOfThought adds a rationale field before the answer, prompting the LM to reason step-by-step. dspy.Predict maps inputs to outputs directly with no reasoning prefix.
2 / 5
A standup blocker: compile() runs for hours. Your tech lead asks what DSPy's compile() actually does. The correct description is:
DSPy compile() uses an optimizer (teleprompter) to search for better instructions and few-shot demonstrations, optimising the module's prompts without touching model weights.
3 / 5
You're defining a DSPy Signature for a RAG pipeline. A PR comment says the signature fields are wrong. What does a DSPy Signature define?
A DSPy Signature (e.g. "question -> answer" or a class with typed fields) declares the interface — inputs and outputs — of a language model call, driving prompt construction.
4 / 5
During a sprint review, the RAG module is hallucinating. You add dspy.Retrieve to the pipeline. What does Retrieve do in DSPy?
dspy.Retrieve calls the configured retrieval model (e.g. ColBERTv2, Weaviate) and returns top-k passages, which downstream modules use as context.
5 / 5
A colleague proposes wrapping your DSPy modules in a dspy.Module subclass. In a design discussion, you explain that subclassing dspy.Module lets you:
Subclassing dspy.Module and defining forward() lets you compose predictors, retrievers, and other modules into a single compilable program that optimizers treat as one unit.