节点 n26

I'll analyze the results from rounds 0 and 1 to decide what to try next.

**Round 0 (K_BLOCK=25):** Score dropped slightly (-0.092). neighborhood_mmd got *worse* (0.05848 → 0.05935), and expression_change/cell_state dropped. Larger blocks hurt.

**Round 1 (DO_ALIGN=0):** Score dropped more (-0.535). shape_scale dropped (52.67 → 51.24), local_spatial dropped. Alignment helps, keep it.

Both changes made things worse. Let me think about what else to try. Looking at the score breakdown:

- `neighborhood_mmd` is the biggest single metric (25 points max, currently 15.54). The raw value is 0.05848. Lower is better.
- `shape_scale` is the weakest group (52.67). Within it, `d2_shape` skill is only 0.523 and `scale_log_ratio` skill is 0.512 — both near the floor of 0.5.
- `occupancy_dice` skill is 0.545, also weak.

The `scale_log_ratio` raw value is 0.4669 with skill 0.512. This measures whether the overall scale of the output matches the target. The current approach does `scale_to_rms(coords, target_rms)` at the end. But `target_rms` is computed as `log_interp(rms_A, rms_B, t)`. 

One issue: when `DO_ALIGN=1`, each side is scaled to `target_rms` individually, then the concatenated cloud is scaled to `target_rms` again. The second scaling is a no-op only if the concatenated cloud already has RMS = target_rms, which it won't if the two sides have different means. This double-scaling could distort things.

Actually wait — let me re-read the code. When DO_ALIGN=1:
- `coords_a = scale_to_rms(ca, target_rms)` 
- `coords_b = scale_to_rms(cb, target_rms)`
- Then at the end: `coords = scale_to_rms(coords, target_rms)`

The final `scale_to_rms` recenters and rescales. If the two aligned clouds have different centroids, concatenating them increases the RMS beyond target_rms, and the final rescale shrinks everything. This could compress the spatial structure.

What if I try removing the per-side scaling and only do the final global scaling? Or alternatively, what if I try a different `target_rms` computation?

Actually, let me think about `T_SHIFT`. The METHOD.md says `s=t·shift` with `shift∈{0.625,1,1.5}` was scanned and `s=t` (shift=1.0) was optimal. So that's already tuned.

Let me think about `K_BLOCK` in the other direction — trying K_BLOCK=10 instead of 15. Smaller blocks might preserve finer local structure and reduce the "blockiness" that could hurt shape metrics. The block sampling with k=15 means each block has 16 cells (seed + 15 neighbors). With k=10, blocks would be 11 cells, giving more spatial diversity in the sample while still preserving local pairing.

Actually, looking more carefully at the metrics:
- `d2_shape` (skill 0.523) and `occupancy_dice` (skill 0.545) are the weakest. These relate to the spatial distribution/shape of the output.
- `scale_log_ratio` (skill 0.512) is the weakest of all. This is about the ratio of the output scale to the target scale.

The `scale_log_ratio` being near the floor suggests the output scale is systematically off. The current `target_rms = log_interp(rms_A, rms_B, t)`. Maybe a linear interpolation would be better? Or maybe the double-scaling is causing issues.

Let me try: remove the per-side scaling when DO_ALIGN=1, and only do the final global `scale_to_rms`. This way, the aligned coordinates maintain their relative scale, and only the final concatenated cloud is scaled to target_rms. This should give a more natural scale.

Wait, but if I remove per-side scaling, the two sides might have very different scales, and the final scaling would be dominated by the larger side. Let me think differently.

Actually, let me try a simpler change: K_BLOCK=10. The rationale is that smaller blocks give finer spatial sampling, which might help with shape metrics (occupancy_dice, d2_shape) by producing a more representative spatial distribution. The METHOD.md suggested trying 25-30, but that made things worse. Going the other direction might help.

（只摘前 40 行）