# SWE-Prime: Fewer Trajectories, Better Performance > SWE-Prime's two-stage trajectory and segment selection enables training on just 10% of resolved trajectories to outperform full-dataset SFT by up to 24.2%. - **Source:** [arXiv](https://arxiv.org/abs/2608.27449) - **Published:** 2026-10-12 - **Permalink:** https://picx.dev/p/5snn36 - **Whiteboard:** https://picx.dev/p/5snn36/image ## Summary # SWE-Prime: Fewer Trajectories, Better Performance ## Summary (Overview) - **Core contribution**: SWE-Prime is a multi-granularity, two-stage supervised fine-tuning (SFT) data selection method for coding agents that progressively filters training data at both the trajectory level and the semantic segment level. - **Key finding**: Training on only **10%** of the resolved trajectories selected by SWE-Prime outperforms training on the **full resolved dataset**, yielding relative performance gains of up to **12.2%** on SWE-Bench Pro and **24.2%** on SWE-Bench Verified. - **Methodological innovation**: SWE-Prime introduces *semantic segments* (groups of consecutive steps sharing a common intent) as behaviorally coherent units for fine-grained supervision-quality assessment, rather than evaluating isolated steps. - **Multi-dimensional quality assessment**: The method evaluates trajectories on process quality (workflow pattern, tool success rate, redundancy, git-hacking prevention), result quality (patch scope), and data representativeness (cluster-based selection), then filters segments by contribution, learnability, and behavioral risk. - **Validation breadth**: Experiments across three base models (Qwen3-30B-A3B-Instruct-2507, GLM-4.7-Flash, Qwen3-Coder-30B-A3B-Instruct) and two benchmarks demonstrate consistent improvements, including across Python, JavaScript, TypeScript, and Go subsets. ## Introduction and Theoretical Foundation ### Background Software issue resolution in real-world repositories is a long-horizon task requiring coding agents to understand repository context, iteratively locate relevant code, implement changes, and validate patches. Recent work has constructed large-scale software engineering datasets for SFT, such as: - **SWE-Gym**: Derives executable tasks from real-world GitHub issues - **SWE-smith and R2E-Gym**: Use synthetic data generation to scale task and trajectory collection - **SWE-Factory**: Automates environment construction and task verification across multiple programming languages These approaches perform SFT on *successful trajectories* identified through execution-based verification. ### Key Insight: Success ≠ Quality The authors identify that **task success alone does not guarantee high-quality supervision**. Successful trajectories may contain ineffective, redundant, or risky behaviors. The paper analyzes this problem from three perspectives: **Outcome View**: Existing work adopts an outcome-based view, retaining all successful trajectories. **Trajectory View**: A successful trajectory may still be unsuitable for SFT due to: 1. **Problem-solving pattern**: Poor workflows (e.g., modifying code without prior exploration vs. observe-edit-verify patterns) 2. **Tool call success rate**: Frequent tool failures introduce unreliable tool-use patterns 3. **Continuous redundancy**: Repeated actions without new information 4. **Git hacking**: Leakage-based shortcuts using future repair information from version history 5. **Result quality**: Overly broad patches modifying unnecessary files increase regression risks **Segment View**: Even high-quality trajectories may contain segments of limited value (e.g., steps that execute successfully but don't contribute to the final fix). ### Theoretical Foundation The work draws on prior findings that: - Task success alone is insufficient for identifying high-quality supervision (Uesato et al., 2022; Lightman et al., 2023) - High-quality SFT data should be **compact and low-noise**, providing demonstrations models can reliably learn from - Standard problem-solving processes help models learn systematic behaviors (Chen, Ma, and Jiang, 2026) - Frequent tool failures introduce unreliable patterns (Yang et al., 2025a) - Long-context repetition introduces undesirable supervision (Xiao et al., 2025) - Leakage-based shortcuts introduce cheating behaviors (Song et al., 2026; Tao et al., 2026) ## Methodology ### Overview of SWE-Prime SWE-Prime is a two-stage method: - **Stage 1**: Trajectory-level selection based on process quality, result quality, and data representativeness - **Stage 2**: Segment-level selection identifying high-value semantic segments within retained trajectories During SFT, complete trajectories are retained as context, but **only selected segments contribute to the loss**. ### Stage 1: Trajectory-Level Selection #### Process Quality Assessment Four complementary signals: **1. Observe-Edit-Verify Problem-solving Pattern**: Sets $S_{\mathrm{workflow}} = 1$ if a trajectory inspects the repository before its first edit AND validates the patch through a test or check after its final edit; otherwise 0. **2. Tool Call Success Rate**: The tool reliability score $S_{\mathrm{tool}}$ is the percentile rank of the trajectory's tool-call success rate within the trajectory pool. **3. Continuous Redundancy Control**: $S_{\mathrm{redundancy}} = 0$ if any adjacent pair of tool calls has matching tool names AND arguments; otherwise 1. **4. Git Hacking Prevention**: $S_{\mathrm{git}} = 0$ when Git-history operations reveal reference-patch content before code modification; otherwise 1. #### Result Quality Evaluation Using reference patch to estimate appropriate modification scope: $$S_{\mathrm{file}} = \min\left(\frac{F_{\mathrm{gold}}}{F_{\mathrm{model}}}, 1\right), \qquad S_{\mathrm{line}} = \min\left(\frac{L_{\mathrm{gold}}}{L_{\mathrm{model}}}, 1\right)$$ where $F_{\mathrm{model}}$ and $F_{\mathrm{gold}}$ are the numbers of files modified by the generated and reference patches, and $L_{\mathrm{model}}$ and $L_{\mathrm{gold}}$ are their changed line counts. $$S_{\mathrm{result}} = S_{\mathrm{file}} \times S_{\mathrm{line}}$$ Multiplication ensures a high score only when both file and line scopes are focused. #### Combined Trajectory Score $$S_{\mathrm{traj}} = \frac{1}{5}\left(S_{\mathrm{workflow}} + S_{\mathrm{tool}} + S_{\mathrm{redundancy}} + S_{\mathrm{git}} + S_{\mathrm{result}}\right)$$ #### Data Representativeness Assessment - Issue descriptions are encoded using **Qwen3-Embedding-8B** - **HDBSCAN** clusters semantically similar issues - Trajectories are ranked by $S_{\mathrm{traj}}$ within each cluster - Highest-ranked candidates are selected under the target budget (10%) ### Stage 2: Segment-Level Selection #### Segment Chunking Individual steps are too narrow for behavior-level assessment. SWE-Prime groups consecutive steps sharing a common intent into **semantic segments**. **Boundary-aware chunking**: Fixed-size sliding windows may split ongoing behaviors. SWE-Prime: - Finalizes all segments except the last in each window - Carries the potentially incomplete last segment into the next window - Provides the LLM with a compact summary of task objective, established facts, and identified risks from preceding windows #### Segment Scoring Each segment $s_{i,j}$ receives a quality score $q_{i,j} \in [0, 10]$ based on three criteria: 1. **Contribution to the Final Fix**: Advances issue localization, context gathering, modification, verification, or error recovery 2. **Local Learnability**: Provides a clear evidence–action–feedback pattern based on available information 3. **Behavioral Risk**: Captures undesirable behaviors (irrelevant exploration, uninformative failures, unsafe operations, hardcoded solutions) #### Segment Filtering and Selective SFT Objective Binary selection mask: $m_{i,j} = 1$ if $q_{i,j} \geq \delta$ (threshold = 7), else 0. The selective SFT objective: $$\mathcal{L}_{\mathrm{SFT}} = -\frac{1}{N_{\mathrm{sel}}} \sum_{i} \sum_{j} m_{i,j} \sum_{t \in \mathcal{A}(s_{i,j})} \log p_{\theta}(y_{i,t} | y_{i,