DSP Framework Core Knowledge¶
Document Type: Knowledge Base
Created: 2025-10-20
Last Updated: 2025-10-20
Confidence Level: High
Source: Original DSP paper (arXiv:2212.14024) and framework analysis
Overview¶
The Demonstrate-Search-Predict (DSP) framework is a sophisticated approach for composing Language Models (LM) and Retrieval Models (RM) that goes beyond simple retrieve-then-read pipelines.
Core Architecture Principles¶
Three Fundamental Operations¶
1. Demonstrate¶
- Purpose: Bootstrap pipeline-aware demonstrations that guide language models
- Function: Create examples for smaller pipeline steps, not just final answers
- Implementation: Part of program's explicit execution logic in original DSP
2. Search¶
- Purpose: Find relevant information to ground LM reasoning and predictions
- Function: Strategic placement within program flow, often after Predict calls
- Implementation: Enables multi-step knowledge retrieval during reasoning
3. Predict¶
- Purpose: Generate grounded predictions and text transformations
- Function: Used for intermediate steps (decomposing questions, formulating queries) and final output
- Implementation: Context and retrieved information based processing
Compositional Strategy¶
DSP's core concept is systematic breakdown of knowledge-intensive problems into smaller, manageable transformations that LM and RM can handle reliably.
Key Characteristics: - Natural language texts passed between LM and RM in multiple steps - Developer acts as pipeline architect - High-level programs enable sophisticated multi-hop reasoning - Explicit control over pipeline design and composition
Performance Context¶
Documented Improvements: - 37-120% relative gains over vanilla GPT-3.5 in open-domain QA - 8-39% improvements over standard retrieve-then-read in multi-hop reasoning - 80-290% gains vs contemporaneous self-ask pipeline in conversational QA
Problem Solved¶
DSP addressed structural limitations of the then-dominant "retrieve-then-read" pipeline (December 2022): - Simple model was too simplistic for powerful LM-RM combinations - Need for complex, effective multi-stage pipelines - Required sophisticated composition beyond basic retrieval
Implementation Implications for AirsDSP¶
Core Requirements¶
- Compositional Architecture: Support for combining three operations in complex patterns
- Natural Language Interfaces: Text-based communication between components
- Pipeline Awareness: Context-sensitive processing understanding full pipeline
- Frozen Model Support: Work with existing models without fine-tuning
Architectural Considerations¶
- Systematic problem decomposition mechanisms
- Explicit pipeline control and design
- Modular composition using standard control flow
- Performance-focused implementation in Rust
Research Foundation Quality¶
Credibility: High - Based on Stanford NLP research team foundational paper Technical Depth: Comprehensive - Covers all three operations and interactions Implementation Relevance: High - Direct application to AirsDSP architecture Performance Evidence: Strong - Documented significant improvements across tasks