DSPy

Admin → DSPy configures the pipeline that turns a plain-English metric request into SQL. It runs on the DSPy-default provider, independently of the Chat default.

Note

Tuning is optional. SEMANTIX generates metric SQL without it. DSPy matters when you generate a lot of metrics and want the SQL to stop needing correction.

Configuration

• DSPy default provider — which LLM the pipeline uses.
• Temperature — higher explores more; lower converges faster.
• Max iterations — how many refinement passes are allowed.

Training examples

The examples are the tuning material. Each pairs a question with the SQL that should answer it:

Question	SQL
“Monthly recurring revenue by plan”	the query you would accept

Real questions you were asked and the queries you actually approved are the best material available. Hypothetical ones produce plausible tuning and worse SQL.

Programs

The pipeline is made of programs — a module per step, with a compiled version and its current performance. Viewing a program shows the signature, the compiled artefact, and the metrics from its most recent evaluation.

Status

Status	Meaning
idle	Not run yet
building dataset	Collecting examples
compiling	Optimising against the dataset
running	Compiled and in use
error	Failed — the message says where

Caution

A failed compile leaves the previous compiled version in place. Metrics keep generating, on the older program. The status is the only signal that a change did not take effect.

When to bother

Not on day one. Compiling against examples collected from real questions produces noticeably better SQL; compiling against six invented questions produces a pipeline that has been optimised for your assumptions. Collect examples first.