ember-memory-test/episodes/TRAZA_es-loops-s-en-espritu-pero-el-sota-dist_S20260712.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

---

episode_id: "80b23d7b-7966-45df-9bcb-e2406dcb3f1b" puente_flat: "TRAZA_es-loops-s-en-espritu-pero-el-sota-dist_S20260712.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD" session_code: "S20260712.PIPELINE_PG_HYDE_FIX" acto_dialogico: "informar" actor_flujo: "multi_actor" criticidad_aegis: "low" skill_dominante: "NONE" fase_proyecto: "operations" tipo_semantico: "troubleshooting" summary_one_line: "EPISODIO 1 — MNEMO_PRE_DIGEST: ¿Es "loops"? Sí en espíritu — pero el SOTA distingue dos pat" source_type: "claude_code" trust_boundary: "internal" created_at: "2026-07-12T20:41:47.234864+00:00" relectura_tagged: false forgejo_commit_sha: "pending"

Tu pregunta apunta a algo fino, así que déjame afinar la respuesta más allá de lo que ya dejé en el doc — porque la palabra "loop" esconde dos cosas distintas, y solo una es literalmente un loop.

¿Es "loops"? Sí en espíritu — pero el SOTA distingue dos patrones

Lo que te describí ("varios intentos + una prueba objetiva que escoge el bueno") en el estado del arte no se llama principalmente "loop" — se llama Best-of-N sampling con verificador (o rejection sampling / verifier-guided test-time scaling). Y la razón es importante:

Patrón	¿Es un "loop" de verdad?	Qué es	Nuestra medición
Best-of-N + verificador	No — es fan-out + filtro	genera K en paralelo, un test objetivo escoge UNA vez. No hay iteración.	✅ el que funciona
Loop iterativo (self-refine, reflexion, agentic loop, ReAct)	Sí — es el loop clásico	genera → critica → reescribe → repite	⚠️ el más débil (brazo-R: R ≤ D)

Es decir: el patrón que gana no es técnicamente un "loop" — es "tirar K veces en paralelo y quedarte con el que pasa la prueba" (un abanico, no un ciclo). El que sí es un loop iterativo de verdad (el modelo reintentando y corrigiéndose) es un patrón SOTA reconocido pero que nuestra propia medición encontró más flojo. Por eso la distinción no es pedante: si le llamamos "loop" a secas, uno tiende a imaginar el iterativo (auto-corrección) — y ese es justamente el que no carga el peso.

¿Está fundamentado en las mejores prácticas? Sí — verificado, y con nuestros mismos límites

Lo confirmé contra arxiv este turno (HARD_FACT, tratado como DATA, sin red flags):

• arXiv:2503.01422 — "Best-of-N sampling serves as a common sampling-based scaling technique, broadening the search space in parallel" → confirma que es estándar Y que es paralelo, no iterativo.
• arXiv:2507.12399 (ROC-n-reroll) — BoN + rejection sampling "make use of a verifier"; estudia justo la imperfección del verificador → coincide con nuestro hallazgo de que el oráculo insobornable es la mitad que pesa.
• arXiv:2504.13171 — "test-time compute has emerged as a key ingredient".

Y lo más bonito: el SOTA respalda nuestros mismos caveats, que medimos por cuenta propia —

• acotado por el techo del modelo (Yue 2504.13837 "bounded by the base model" + Stroebl 2411.17501) → por eso "cosecha", no "amplificación";
• la calidad del verificador es lo que carga (ROC-n-reroll estudia verifier-imperfection).

Todo esto quedó anclado y committeado en docs/LOOPS_SOTA_FUNDAMENTO_S20260712.md (commit 3112b14e, 3 remotos en paridad).

Trust-boundary honesto: la limitación específica del self-refine la medimos nosotros (brazo-R); la línea "los LLM no se auto-corrigen bien de forma intrínseca" existe en la literatura, pero no pinté la cita exacta este turno (la búsqueda no la devolvió) → no la cito por número para no fabricar. Si quieres, la rastreo en un turno aparte.