DSPy Compiling Declarative Language Model Calls (Khattab et al., 2023)

URL: https://arxiv.org/abs/2310.03714

The paper proposes DSPy, a programming model that replaces hand-coded prompt templates with systematic optimizable language-model pipelines. The framework treats LM pipelines as "text transformation graphs, i.e., imperative computational graphs where LMs are invoked through declarative modules." Modules are parameterized; a compiler optimizes any DSPy pipeline to maximize specified metrics. The empirical claim is over 25 percent and 65 percent improvement over standard few-shot prompting across multiple benchmarks.

Adopted

DSPy is the foundational framework that the RLM research direction extends. The "writing programs that compile down to prompts" framing is conceptually downstream of the primitives-vs-glue diagnostic this graph names: programs need a runtime layer to compile into; pipelines need a runtime to run on. Khattab's own subsequent work (RLM, Agent Skills) elaborates on the framework's runtime-layer dependencies, naming the variable-vs-token-space distinction this graph's harness-as-tool inversion ([[Agent Harnesses Drive the Runtime, Not the Reverse]]) makes load-bearing. eOS Continuum is the runtime-LAYER answer to the runtime question DSPy raises and works around in user-space.

Not adopted (yet)

DSPy operates as a Python-runtime compilation framework; the runtime layer underneath is whatever Python provides, which is the wrong runtime layer for the workload (no orthogonal persistence, no capability separation, no atomic operations as primitives). The compilation framework itself is downstream of runtime-layer concerns; eOS Continuum does not adopt DSPy's compilation model -- it adopts the framework's diagnosis that LM-pipelines-as-programs need a runtime, and provides the runtime.

Sources

Relations