El ciclo de reflexión y lo que multiplica

Lo que separa a un sistema que investiga de uno que solo genera es un bucle de autocrítica: escribe, se evalúa, y si no llega al estándar vuelve a buscar con preguntas nuevas. Ese bucle es el diferenciador real — y también la razón por la que el coste de estos sistemas no se estima a ojo: cada vuelta multiplica búsquedas y llamadas al modelo, y el parámetro que la controla parece inofensivo.

01 — El bucle

Escribir, evaluar, volver a buscar

Dentro de cada sección, el flujo no termina al redactar:

write_section → section_grader → pass → fin de la sección
                              └→ fail → follow_up_queries → search_web → write_section

Y hay dos decisiones de diseño ahí que valen para cualquier sistema propio:

Decisión	Por qué
El evaluador usa el modelo planner, no el writer	Quien escribió no es buen juez de lo que escribió. Un modelo distinto —o al menos otra instancia con otro rol— da una perspectiva independiente
El fallo no reintenta: genera queries de seguimiento	Reintentar lo mismo da lo mismo. El evaluador señala qué falta y esa carencia se convierte en las búsquedas siguientes

La segunda es la más importante y la más fácil de hacer mal. Un bucle que reintenta sin cambiar la entrada no es un ciclo de mejora, es un bucle. Lo que convierte esto en reflexión es que el diagnóstico —«a esta sección le falta X»— se traduce en una acción concreta: buscar X.

El criterio del evaluador tampoco es abstracto: compara la sección escrita contra la descripción que el plan le asignó. Es decir, el estándar se fijó en la fase de planificación, antes de escribir nada — y por eso aprobar un plan flojo condena todo lo que viene después.

02 — La aritmética

Qué multiplica cada parámetro

La configuración del sistema tiene cuatro mandos que parecen equivalentes y no lo son: unos suman y otros multiplican.

Parámetro	Qué controla	Efecto en el coste
Número de secciones	Cuántos subgrafos se abren	Multiplica todo lo de abajo
`number_of_queries`	Búsquedas por iteración y sección	Multiplica las llamadas a la API de búsqueda
`max_search_depth`	Cuántas vueltas puede dar el bucle de reflexión	Multiplica búsquedas y llamadas al LLM
Resultados por búsqueda	Cuánto texto entra al contexto	Sube el coste por llamada, no el número de llamadas

El peligroso es el tercero, porque su nombre suena a un ajuste de calidad y es un multiplicador: en el peor caso, cada sección puede repetir su ciclo completo de búsqueda y redacción tantas veces como diga ese número. Con seis secciones y tres vueltas, el sistema puede acabar haciendo del orden de dieciocho ciclos de búsqueda-y-redacción para un solo informe.

// secciones × vueltas × queries: tres factores, no tres sumandos

De ahí la única defensa que no depende de acertar con la configuración: haz la multiplicación antes de lanzar, no después de ver la factura. Son tres números y una calculadora.

03 — La fuente

Elegir dónde busca cambia lo que encuentra

El sistema admite intercambiar la API de búsqueda, y esa elección hace más por la calidad del informe que casi cualquier ajuste del prompt. No son equivalentes:

Tipo de fuente	Qué aporta	Cuándo compensa
Búsqueda semántica	Encuentra por significado y explora subpáginas	Temas amplios, exploración inicial
Búsqueda web con extracto	Devuelve el contenido crudo de la página	Cuando hace falta el texto entero, no un resumen
Repositorios académicos	Papers, con sus límites de frecuencia	Temas técnicos donde la web general es ruido
Fuentes médicas especializadas	Literatura biomédica	Dominio clínico, donde el resto no sirve
Web general sin clave	Cobertura amplia, sin registro	Prototipar sin dar de alta nada

Y hay un mando más discreto que suele rendir más que cambiar de API: restringir los dominios. Limitar las búsquedas a un puñado de sitios de confianza —académicos, del sector, del regulador— sube la calidad de las fuentes citadas más que aumentar la profundidad del bucle, y a diferencia de esta no multiplica nada.

Auditoría Dos cosas que este material presenta como datos. Una: «los analistas dedican el 70 % de su tiempo a buscar y compilar y solo el 30 % a análisis de valor», y «el tiempo promedio por informe es de 6-8 horas». Sin fuente, sin sector, sin muestra — y es el argumento entero a favor de montar el sistema. Dos: «un max_search_depth de 2-3 es óptimo para la mayoría de casos». ¿Óptimo medido cómo, y contra qué? Es el parámetro que más multiplica el coste, así que un «óptimo» sin criterio es justo lo que no se debe copiar. Y una tercera, más sutil: la validación del ejercicio propone contar líneas y encabezados del informe generado —eso comprueba que el pipeline terminó, no que el informe sea bueno—, lo cual es irónico en la unidad cuyo diferenciador es un evaluador de calidad.

Para hacer

La multiplicación, antes de lanzar

Con los parámetros que pienses usar, calcula tres números en una servilleta: secciones × profundidad máxima × queries por iteración. Eso te da el peor caso de búsquedas. Multiplícalo por el precio por búsqueda de tu API y súmale, por cada ciclo, una llamada de redacción y una de evaluación al precio de tu modelo.

Compara el resultado con lo que costaría escribir el informe a mano. Si el sistema sale más caro, ya sabes qué mando bajar — y sabrás también que el que más rinde bajar no es el que parece.