节点 n17

Looking at the Round 0 results, my changes (gamma 1.0→1.5, clip 4.0→6.0, delta_min 0.005→0.01) all hurt performance. The X3 score dropped from 55.35 to 52.68, confirming that gamma=1.0 with clip [0.25, 4.0] was already near-optimal, and the stronger extrapolation was counterproductive.

The current program is back to the parent's original code (delta_min=0.005, gamma=1.0, clip [0.25, 4.0]).

Let me think about what could actually help:

1. **Lower clip bound 0.25→0.1**: More aggressively downweight shrinking populations. The METHOD.md notes "消失型也压到 0.25" gave 53.63 vs 55.27, so that was worse. So don't lower it.

2. **Tighten upper clip 4.0→3.0**: Since gamma=1.5 was too aggressive, maybe the upper clip of 4.0 is already too generous. Reducing to 3.0 might prevent over-amplification of rare expanding types.

3. **n_neighbors 15→20 or 15→10**: The kNN graph affects both pseudotime quality and transition probabilities. More neighbors could smooth the graph.

4. **graph_n 4000→6000**: More cells in the graph could improve pseudotime estimation and transition quality.

5. **For proxy10**: The single-stage path is neutral. Maybe reducing moved_fraction (higher delta_min) would help slightly, but Round 0 showed delta_min=0.01 hurt proxy10 only slightly (52.32 vs 52.04 - actually proxy10 improved slightly!). Wait, proxy10 actually went UP from 52.04 to 52.32 with delta_min=0.01. The problem was X3 dropping.

So the key insight: delta_min=0.01 helped proxy10 slightly. The X3 drop was entirely from gamma=1.5 and clip=6.0. 

Strategy for Round 1: Keep gamma=1.0 and clip [0.25, 4.0] unchanged. Try:
- **n_neighbors 15→20**: More neighbors could improve pseudotime and transition matrix quality for X3
- **delta_min 0.005→0.008**: Slightly more conservative (less than 0.01 which helped proxy10)

Actually, let me reconsider. The proxy10 improvement with delta_min=0.01 was small (+0.27). Let me focus on what could move X3 up since it has weight 2.

Looking at X3 metrics: de_score skill 0.546, de_direction 0.528, mmd_u 0.595, variogram 0.532. The variogram is weakest. The variogram measures spatial/temporal smoothness. 

What if I try **n_neighbors 15→25**? More neighbors in the kNN graph would make the transition matrix smoother, potentially helping variogram. It also affects pseudotime quality.

Or try **num_waypoints 400→600** for better pseudotime resolution.

Let me go with a conservative approach:
1. **n_neighbors: 15→20** — smoother graph, better pseudotime, potentially helps both views
2. **Keep everything else at parent values**

This is a single, clean change that could improve graph quality without the risk of over-extrapolation.

CHANGE: n_neighbors 15→20 (smoother kNN graph for better pseudotime estimation and transition probabilities, targeting variogram and mmd_u improvement on X3)

<<<<<<< SEARCH
    p.add_argument("--n-neighbors", type=int, default=15)

（只摘前 40 行）