mirror of
https://github.com/wassname/ray.git
synced 2026-08-12 12:20:11 +08:00
[docs][tune] Make search algorithm, scheduler docs better! (#8179)
This commit is contained in:
Richard Liaw
@@ -3,9 +3,6 @@
|
||||
Analysis (tune.analysis)
|
||||
========================
|
||||
|
||||
Analyzing Results
|
||||
-----------------
|
||||
|
||||
You can use the ``ExperimentAnalysis`` object for analyzing results. It is returned automatically when calling ``tune.run``.
|
||||
|
||||
.. code-block:: python
|
||||
@@ -41,15 +38,15 @@ You may want to get a summary of multiple experiments that point to the same ``l
|
||||
|
||||
.. _exp-analysis-docstring:
|
||||
|
||||
ExperimentAnalysis
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
ExperimentAnalysis (tune.ExperimentAnalysis)
|
||||
--------------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.ExperimentAnalysis
|
||||
:show-inheritance:
|
||||
:members:
|
||||
|
||||
Analysis
|
||||
~~~~~~~~
|
||||
Analysis (tune.Analysis)
|
||||
------------------------
|
||||
|
||||
.. autoclass:: ray.tune.Analysis
|
||||
:members:
|
||||
|
||||
@@ -3,10 +3,131 @@
|
||||
Loggers (tune.logger)
|
||||
=====================
|
||||
|
||||
Tune has default loggers for Tensorboard, CSV, and JSON formats.
|
||||
Tune has default loggers for Tensorboard, CSV, and JSON formats. By default, Tune only logs the returned result dictionaries from the training function.
|
||||
|
||||
Logging Path
|
||||
------------
|
||||
If you need to log something lower level like model weights or gradients, see :ref:`Trainable Logging <trainable-logging>`.
|
||||
|
||||
Custom Loggers
|
||||
--------------
|
||||
|
||||
You can create a custom logger by inheriting the Logger interface (:ref:`logger-interface`):
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from ray.tune.logger import Logger
|
||||
|
||||
class MLFLowLogger(Logger):
|
||||
"""MLFlow logger.
|
||||
|
||||
Requires the experiment configuration to have a MLFlow Experiment ID
|
||||
or manually set the proper environment variables.
|
||||
"""
|
||||
|
||||
def _init(self):
|
||||
from mlflow.tracking import MlflowClient
|
||||
client = MlflowClient()
|
||||
|
||||
# self.config is the same config that your Trainable will see.
|
||||
run = client.create_run(self.config.get("mlflow_experiment_id"))
|
||||
self._run_id = run.info.run_id
|
||||
for key, value in self.config.items():
|
||||
client.log_param(self._run_id, key, value)
|
||||
self.client = client
|
||||
|
||||
def on_result(self, result):
|
||||
for key, value in result.items():
|
||||
if not isinstance(value, float):
|
||||
continue
|
||||
self.client.log_metric(
|
||||
self._run_id, key, value, step=result.get(TRAINING_ITERATION))
|
||||
|
||||
def close(self):
|
||||
self.client.set_terminated(self._run_id)
|
||||
|
||||
You can then pass in your own logger as follows:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from ray.tune.logger import DEFAULT_LOGGERS
|
||||
|
||||
tune.run(
|
||||
MyTrainableClass,
|
||||
name="experiment_name",
|
||||
loggers=DEFAULT_LOGGERS + (CustomLogger1, CustomLogger2)
|
||||
)
|
||||
|
||||
These loggers will be called along with the default Tune loggers. You can also check out `logger.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/logger.py>`__ for implementation details.
|
||||
|
||||
An example of creating a custom logger can be found in `logging_example.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/logging_example.py>`__.
|
||||
|
||||
.. _trainable-logging:
|
||||
|
||||
Trainable Logging
|
||||
-----------------
|
||||
|
||||
By default, Tune only logs the *training result dictionaries* from your Trainable. However, you may want to visualize the model weights, model graph, or use a custom logging library that requires multi-process logging. For example, you may want to do this if:
|
||||
|
||||
* you're using `Weights and Biases <https://www.wandb.com/>`_
|
||||
* you're using `MLFlow <https://github.com/mlflow/mlflow/>`__
|
||||
* you're trying to log images to Tensorboard.
|
||||
|
||||
You can do this in the trainable, as shown below:
|
||||
|
||||
.. tip:: Make sure that any logging calls or objects stay within scope of the Trainable. You may see Pickling/serialization errors or inconsistent logs otherwise.
|
||||
|
||||
**Function API**:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
def trainable(config):
|
||||
library.init(
|
||||
name=trial_id,
|
||||
id=trial_id,
|
||||
resume=trial_id,
|
||||
reinit=True,
|
||||
allow_val_change=True)
|
||||
library.set_log_path(tune.track.logdir)
|
||||
|
||||
for step in range(100):
|
||||
library.log_model(...)
|
||||
library.log(results, step=step)
|
||||
tune.track.log(results)
|
||||
|
||||
|
||||
**Class API**:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
class CustomLogging(tune.Trainable)
|
||||
def _setup(self, config):
|
||||
trial_id = self.trial_id
|
||||
library.init(
|
||||
name=trial_id,
|
||||
id=trial_id,
|
||||
resume=trial_id,
|
||||
reinit=True,
|
||||
allow_val_change=True)
|
||||
library.set_log_path(self.logdir)
|
||||
|
||||
def _train(self):
|
||||
library.log_model(...)
|
||||
|
||||
def _log_result(self, result):
|
||||
res_dict = {
|
||||
str(k): v
|
||||
for k, v in result.items()
|
||||
if (v and "config" not in k and not isinstance(v, str))
|
||||
}
|
||||
step = result["training_iteration"]
|
||||
library.log(res_dict, step=step)
|
||||
|
||||
Use ``self.logdir`` (only for Class API) or ``tune.track.logdir`` (only for Function API) for the trial log directory.
|
||||
|
||||
In the distributed case, these logs will be sync'ed back to the driver under your logger path. This will allow you to visualize and analyze logs of all distributed training workers on a single machine.
|
||||
|
||||
|
||||
Log Directory
|
||||
-------------
|
||||
|
||||
Tune will log the results of each trial to a subfolder under a specified local dir, which defaults to ``~/ray_results``.
|
||||
|
||||
@@ -51,25 +172,6 @@ to `tune.run`. This takes a function with the following signature:
|
||||
See the documentation on Trials: :ref:`trial-docstring`.
|
||||
|
||||
|
||||
Custom Loggers
|
||||
--------------
|
||||
|
||||
You can pass in your own logging mechanisms to output logs in custom formats as follows:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from ray.tune.logger import DEFAULT_LOGGERS
|
||||
|
||||
tune.run(
|
||||
MyTrainableClass,
|
||||
name="experiment_name",
|
||||
loggers=DEFAULT_LOGGERS + (CustomLogger1, CustomLogger2)
|
||||
)
|
||||
|
||||
These loggers will be called along with the default Tune loggers. All loggers must inherit the Logger interface (:ref:`logger-interface`). You can also check out `logger.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/logger.py>`__ for implementation details.
|
||||
|
||||
An example can be found in `logging_example.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/logging_example.py>`__.
|
||||
|
||||
Viskit
|
||||
------
|
||||
|
||||
@@ -85,13 +187,6 @@ The nonrelevant metrics (like timing stats) can be disabled on the left to show
|
||||
.. image:: /ray-tune-viskit.png
|
||||
|
||||
|
||||
.. _logger-interface:
|
||||
|
||||
Logger
|
||||
------
|
||||
|
||||
.. autoclass:: ray.tune.logger.Logger
|
||||
|
||||
UnifiedLogger
|
||||
-------------
|
||||
|
||||
@@ -118,3 +213,11 @@ MLFLowLogger
|
||||
Tune also provides a default logger for `MLFlow <https://mlflow.org>`_. You can install MLFlow via ``pip install mlflow``. An example can be found `mlflow_example.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/mlflow_example.py>`__. Note that this currently does not include artifact logging support. For this, you can use the native MLFlow APIs inside your Trainable definition.
|
||||
|
||||
.. autoclass:: ray.tune.logger.MLFLowLogger
|
||||
|
||||
|
||||
.. _logger-interface:
|
||||
|
||||
Logger
|
||||
------
|
||||
|
||||
.. autoclass:: ray.tune.logger.Logger
|
||||
|
||||
@@ -1,38 +1,172 @@
|
||||
.. _schedulers-ref:
|
||||
.. _tune-schedulers:
|
||||
|
||||
Trial Schedulers (tune.schedulers)
|
||||
==================================
|
||||
|
||||
FIFOScheduler
|
||||
~~~~~~~~~~~~~
|
||||
In Tune, some hyperparameter optimization algorithms are written as "scheduling algorithms". These Trial Schedulers can early terminate bad trials, pause trials, clone trials, and alter hyperparameters of a running trial.
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.FIFOScheduler
|
||||
All Trial Schedulers take in a ``metric``, which is a value returned in the result dict of your Trainable and is maximized or minimized according to ``mode``.
|
||||
|
||||
HyperBandScheduler
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
.. code-block:: python
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.HyperBandScheduler
|
||||
tune.run( ... , scheduler=Scheduler(metric="accuracy", mode="max"))
|
||||
|
||||
ASHAScheduler/AsyncHyperBandScheduler
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. _schedulers-ref:
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
||||
Tune includes distributed implementations of early stopping algorithms such as `Median Stopping Rule <https://research.google.com/pubs/pub46180.html>`__, `HyperBand <https://arxiv.org/abs/1603.06560>`__, and `ASHA <https://openreview.net/forum?id=S1Y7OOlRZ>`__. Tune also includes a distributed implementation of `Population Based Training (PBT) <https://deepmind.com/blog/population-based-training-neural-networks>`__.
|
||||
|
||||
.. tip:: The easiest scheduler to start with is the ``ASHAScheduler`` which will aggressively terminate low-performing trials.
|
||||
|
||||
When using schedulers, you may face compatibility issues, as shown in the below compatibility matrix. Certain schedulers cannot be used with Search Algorithms, and certain schedulers are only compatible with the :ref:`tune-class-api`.
|
||||
|
||||
.. list-table:: TrialScheduler Feature Compatibility Matrix
|
||||
:header-rows: 1
|
||||
|
||||
* - Scheduler
|
||||
- Class API Required?
|
||||
- SearchAlg Compatible?
|
||||
- Example
|
||||
* - :ref:`ASHA <tune-scheduler-hyperband>`
|
||||
- No
|
||||
- Yes
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/async_hyperband_example.py>`__
|
||||
* - :ref:`Median Stopping Rule <tune-scheduler-msr>`
|
||||
- No
|
||||
- Yes
|
||||
- :ref:`Link <tune-scheduler-msr>`
|
||||
* - :ref:`HyperBand <tune-original-hyperband>`
|
||||
- Yes
|
||||
- Yes
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/hyperband_example.py>`__
|
||||
* - :ref:`BOHB <tune-scheduler-bohb>`
|
||||
- Yes
|
||||
- Only TuneBOHB
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/bohb_example.py>`__
|
||||
* - :ref:`Population Based Training <tune-scheduler-pbt>`
|
||||
- Yes
|
||||
- Not Compatible
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/pbt_example.py>`__
|
||||
|
||||
.. _tune-scheduler-hyperband:
|
||||
|
||||
ASHA (tune.schedulers.ASHAScheduler)
|
||||
------------------------------------
|
||||
|
||||
The `ASHA <https://openreview.net/forum?id=S1Y7OOlRZ>`__ scheduler can be used by setting the ``scheduler`` parameter of ``tune.run``, e.g.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
asha_scheduler = ASHAScheduler(
|
||||
time_attr='training_iteration',
|
||||
metric='episode_reward_mean',
|
||||
mode='max',
|
||||
max_t=100,
|
||||
grace_period=10,
|
||||
reduction_factor=3,
|
||||
brackets=3)
|
||||
tune.run( ... , scheduler=asha_scheduler)
|
||||
|
||||
Compared to the original version of HyperBand, this implementation provides better parallelism and avoids straggler issues during eliminations. **We recommend using this over the standard HyperBand scheduler.** An example of this can be `found here <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/async_hyperband_example.py>`_.
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.AsyncHyperBandScheduler
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.ASHAScheduler
|
||||
|
||||
MedianStoppingRule
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
.. _tune-original-hyperband:
|
||||
|
||||
HyperBand (tune.schedulers.HyperBandScheduler)
|
||||
----------------------------------------------
|
||||
|
||||
Tune implements the `standard version of HyperBand <https://arxiv.org/abs/1603.06560>`__. **We recommend using the ASHA Scheduler over the standard HyperBand scheduler.**
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.HyperBandScheduler
|
||||
|
||||
|
||||
HyperBand Implementation Details
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Implementation details may deviate slightly from theory but are focused on increasing usability. Note: ``R``, ``s_max``, and ``eta`` are parameters of HyperBand given by the paper. See `this post <https://homes.cs.washington.edu/~jamieson/hyperband.html>`_ for context.
|
||||
|
||||
1. Both ``s_max`` (representing the ``number of brackets - 1``) and ``eta``, representing the downsampling rate, are fixed. In many practical settings, ``R``, which represents some resource unit and often the number of training iterations, can be set reasonably large, like ``R >= 200``. For simplicity, assume ``eta = 3``. Varying ``R`` between ``R = 200`` and ``R = 1000`` creates a huge range of the number of trials needed to fill up all brackets.
|
||||
|
||||
.. image:: /images/hyperband_bracket.png
|
||||
|
||||
On the other hand, holding ``R`` constant at ``R = 300`` and varying ``eta`` also leads to HyperBand configurations that are not very intuitive:
|
||||
|
||||
.. image:: /images/hyperband_eta.png
|
||||
|
||||
The implementation takes the same configuration as the example given in the paper and exposes ``max_t``, which is not a parameter in the paper.
|
||||
|
||||
2. The example in the `post <https://homes.cs.washington.edu/~jamieson/hyperband.html>`_ to calculate ``n_0`` is actually a little different than the algorithm given in the paper. In this implementation, we implement ``n_0`` according to the paper (which is `n` in the below example):
|
||||
|
||||
.. image:: /images/hyperband_allocation.png
|
||||
|
||||
|
||||
3. There are also implementation specific details like how trials are placed into brackets which are not covered in the paper. This implementation places trials within brackets according to smaller bracket first - meaning that with low number of trials, there will be less early stopping.
|
||||
|
||||
.. _tune-scheduler-msr:
|
||||
|
||||
Median Stopping Rule (tune.schedulers.MedianStoppingRule)
|
||||
---------------------------------------------------------
|
||||
|
||||
The Median Stopping Rule implements the simple strategy of stopping a trial if its performance falls below the median of other trials at similar points in time.
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.MedianStoppingRule
|
||||
|
||||
PopulationBasedTraining
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
.. _tune-scheduler-pbt:
|
||||
|
||||
Population Based Training (tune.schedulers.PopulationBasedTraining)
|
||||
-------------------------------------------------------------------
|
||||
|
||||
Tune includes a distributed implementation of `Population Based Training (PBT) <https://deepmind.com/blog/population-based-training-neural-networks>`__. This can be enabled by setting the ``scheduler`` parameter of ``tune.run``, e.g.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
pbt_scheduler = PopulationBasedTraining(
|
||||
time_attr='time_total_s',
|
||||
metric='mean_accuracy',
|
||||
mode='max',
|
||||
perturbation_interval=600.0,
|
||||
hyperparam_mutations={
|
||||
"lr": [1e-3, 5e-4, 1e-4, 5e-5, 1e-5],
|
||||
"alpha": lambda: random.uniform(0.0, 1.0),
|
||||
...
|
||||
})
|
||||
tune.run( ... , scheduler=pbt_scheduler)
|
||||
|
||||
When the PBT scheduler is enabled, each trial variant is treated as a member of the population. Periodically, top-performing trials are checkpointed (this requires your Trainable to support :ref:`save and restore <tune-checkpoint>`). Low-performing trials clone the checkpoints of top performers and perturb the configurations in the hope of discovering an even better variation.
|
||||
|
||||
You can run this `toy PBT example <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/pbt_example.py>`__ to get an idea of how how PBT operates. When training in PBT mode, a single trial may see many different hyperparameters over its lifetime, which is recorded in its ``result.json`` file. The following figure generated by the example shows PBT with optimizing a LR schedule over the course of a single experiment:
|
||||
|
||||
.. image:: /pbt.png
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.PopulationBasedTraining
|
||||
|
||||
|
||||
.. _tune-scheduler-bohb:
|
||||
|
||||
BOHB (tune.schedulers.HyperBandForBOHB)
|
||||
---------------------------------------
|
||||
|
||||
This class is a variant of HyperBand that enables the `BOHB Algorithm <https://arxiv.org/abs/1807.01774>`_. This implementation is true to the original HyperBand implementation and does not implement pipelining nor straggler mitigation.
|
||||
|
||||
This is to be used in conjunction with the Tune BOHB search algorithm. See :ref:`TuneBOHB <suggest-TuneBOHB>` for package requirements, examples, and details.
|
||||
|
||||
An example of this in use can be found in `bohb_example.py <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/bohb_example.py>`_.
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.HyperBandForBOHB
|
||||
|
||||
|
||||
FIFOScheduler
|
||||
-------------
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.FIFOScheduler
|
||||
|
||||
TrialScheduler
|
||||
~~~~~~~~~~~~~~
|
||||
--------------
|
||||
|
||||
.. autoclass:: ray.tune.schedulers.TrialScheduler
|
||||
:members:
|
||||
|
||||
@@ -1,73 +1,197 @@
|
||||
.. _searchalg-ref:
|
||||
.. _tune-search-alg:
|
||||
|
||||
Search Algorithms (tune.suggest)
|
||||
================================
|
||||
|
||||
.. _repeater-doc:
|
||||
Tune's Search Algorithms are wrappers around open-source optimization libraries for efficient hyperparameter selection. Each library has a specific way of defining the search space - please refer to their documentation for more details.
|
||||
|
||||
Repeater
|
||||
--------
|
||||
You can utilize these search algorithms as follows:
|
||||
|
||||
.. autoclass:: ray.tune.suggest.Repeater
|
||||
.. code-block:: python
|
||||
|
||||
ConcurrencyLimiter
|
||||
------------------
|
||||
from ray.tune.suggest.hyperopt import HyperOptSearch
|
||||
tune.run(my_function, search_alg=HyperOptSearch(...))
|
||||
|
||||
.. autoclass:: ray.tune.suggest.ConcurrencyLimiter
|
||||
Summary
|
||||
-------
|
||||
|
||||
AxSearch
|
||||
--------
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
* - SearchAlgorithm
|
||||
- Summary
|
||||
- Website
|
||||
- Code Example
|
||||
* - :ref:`AxSearch <tune-ax>`
|
||||
- Bayesian/Bandit Optimization
|
||||
- [`Ax <https://ax.dev/>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/ax_example.py>`__
|
||||
* - :ref:`DragonflySearch <Dragonfly>`
|
||||
- Scalable Bayesian Optimization
|
||||
- [`Dragonfly <https://dragonfly-opt.readthedocs.io/>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/dragonfly_example.py>`__
|
||||
* - :ref:`SkoptSearch <skopt>`
|
||||
- Bayesian Optimization
|
||||
- [`Scikit-Optimize <https://scikit-optimize.github.io>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/skopt_example.py>`__
|
||||
* - :ref:`HyperOptSearch <tune-hyperopt>`
|
||||
- Tree-Parzen Estimators
|
||||
- [`HyperOpt <http://hyperopt.github.io/hyperopt>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/hyperopt_example.py>`__
|
||||
* - :ref:`BayesOptSearch <bayesopt>`
|
||||
- Bayesian Optimization
|
||||
- [`BayesianOptimization <https://github.com/fmfn/BayesianOptimization>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/bayesopt_example.py>`__
|
||||
* - :ref:`TuneBOHB <suggest-TuneBOHB>`
|
||||
- Bayesian Opt/HyperBand
|
||||
- [`BOHB <https://github.com/automl/HpBandSter>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/bohb_example.py>`__
|
||||
* - :ref:`NevergradSearch <nevergrad>`
|
||||
- Gradient-free Optimization
|
||||
- [`Nevergrad <https://github.com/facebookresearch/nevergrad>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/nevergrad_example.py>`__
|
||||
* - :ref:`ZOOptSearch <zoopt>`
|
||||
- Zeroth-order Optimization
|
||||
- [`ZOOpt <https://github.com/polixir/ZOOpt>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/zoopt_example.py>`__
|
||||
* - :ref:`SigOptSearch <sigopt>`
|
||||
- Closed source
|
||||
- [`SigOpt <https://sigopt.com/>`__]
|
||||
- `Link <https://github.com/ray-project/ray/blob/master/python/ray/tune/examples/sigopt_example.py>`__
|
||||
|
||||
|
||||
.. note::Search algorithms will require a different search space declaration than the default Tune format - meaning that you will not be able to combine ``tune.grid_search`` with the below integrations.
|
||||
|
||||
.. note:: Unlike :ref:`Tune's Trial Schedulers <tune-schedulers>`, Tune SearchAlgorithms cannot affect or stop training processes. However, you can use them together to **early stop the evaluation of bad trials**.
|
||||
|
||||
**Want to use your own algorithm?** The interface is easy to implement. :ref:`Read instructions here <byo-algo>`.
|
||||
|
||||
|
||||
Tune also provides helpful utilities to use with Search Algorithms:
|
||||
|
||||
* :ref:`repeater`: Support for running each *sampled hyperparameter* with multiple random seeds.
|
||||
* :ref:`limiter`: Limits the amount of concurrent trials when running optimization.
|
||||
|
||||
|
||||
.. _tune-ax:
|
||||
|
||||
Ax (tune.suggest.ax.AxSearch)
|
||||
-----------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.ax.AxSearch
|
||||
|
||||
BayesOptSearch
|
||||
--------------
|
||||
.. _bayesopt:
|
||||
|
||||
Bayesian Optimization (tune.suggest.bayesopt.BayesOptSearch)
|
||||
------------------------------------------------------------
|
||||
|
||||
|
||||
.. autoclass:: ray.tune.suggest.bayesopt.BayesOptSearch
|
||||
|
||||
TuneBOHB
|
||||
--------
|
||||
.. _`BayesianOptimization search space specification`: https://github.com/fmfn/BayesianOptimization/blob/master/examples/advanced-tour.ipynb
|
||||
|
||||
.. _suggest-TuneBOHB:
|
||||
|
||||
BOHB (tune.suggest.bohb.TuneBOHB)
|
||||
---------------------------------
|
||||
|
||||
BOHB (Bayesian Optimization HyperBand) is an algorithm that both terminates bad trials and also uses Bayesian Optimization to improve the hyperparameter search. It is backed by the `HpBandSter library <https://github.com/automl/HpBandSter>`_.
|
||||
|
||||
Importantly, BOHB is intended to be paired with a specific scheduler class: `HyperBandForBOHB <tune-schedulers.html#hyperband-bohb>`__.
|
||||
|
||||
This algorithm requires using the `ConfigSpace search space specification <https://automl.github.io/HpBandSter/build/html/quickstart.html#searchspace>`_. In order to use this search algorithm, you will need to install ``HpBandSter`` and ``ConfigSpace``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install hpbandster ConfigSpace
|
||||
|
||||
See the `BOHB paper <https://arxiv.org/abs/1807.01774>`_ for more details.
|
||||
|
||||
.. autoclass:: ray.tune.suggest.bohb.TuneBOHB
|
||||
|
||||
DragonflySearch
|
||||
---------------
|
||||
.. _Dragonfly:
|
||||
|
||||
Dragonfly (tune.suggest.dragonfly.DragonflySearch)
|
||||
--------------------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.dragonfly.DragonflySearch
|
||||
|
||||
HyperOptSearch
|
||||
--------------
|
||||
.. _tune-hyperopt:
|
||||
|
||||
HyperOpt (tune.suggest.hyperopt.HyperOptSearch)
|
||||
-----------------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.hyperopt.HyperOptSearch
|
||||
|
||||
NevergradSearch
|
||||
---------------
|
||||
.. _nevergrad:
|
||||
|
||||
Nevergrad (tune.suggest.nevergrad.NevergradSearch)
|
||||
--------------------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.nevergrad.NevergradSearch
|
||||
|
||||
SigOptSearch
|
||||
------------
|
||||
.. _`Nevergrad README's Optimization section`: https://github.com/facebookresearch/nevergrad/blob/master/docs/optimization.rst#choosing-an-optimizer
|
||||
|
||||
.. _sigopt:
|
||||
|
||||
SigOpt (tune.suggest.sigopt.SigOptSearch)
|
||||
-----------------------------------------
|
||||
|
||||
You will need to use the `SigOpt experiment and space specification <https://app.sigopt.com/docs/overview/create>`__ to specify your search space.
|
||||
|
||||
.. autoclass:: ray.tune.suggest.sigopt.SigOptSearch
|
||||
|
||||
SkOptSearch
|
||||
-----------
|
||||
.. _skopt:
|
||||
|
||||
Scikit-Optimize (tune.suggest.skopt.SkOptSearch)
|
||||
------------------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.skopt.SkOptSearch
|
||||
|
||||
ZOOptSearch
|
||||
-----------
|
||||
.. _`skopt Optimizer object`: https://scikit-optimize.github.io/#skopt.Optimizer
|
||||
|
||||
.. _zoopt:
|
||||
|
||||
ZOOpt (tune.suggest.zoopt.ZOOptSearch)
|
||||
--------------------------------------
|
||||
|
||||
.. autoclass:: ray.tune.suggest.zoopt.ZOOptSearch
|
||||
|
||||
SearchAlgorithm
|
||||
---------------
|
||||
.. _repeater:
|
||||
|
||||
.. autoclass:: ray.tune.suggest.SearchAlgorithm
|
||||
:members:
|
||||
Repeated Evaluations (tune.suggest.Repeater)
|
||||
--------------------------------------------
|
||||
|
||||
Searcher
|
||||
--------
|
||||
Use ``ray.tune.suggest.Repeater`` to average over multiple evaluations of the same
|
||||
hyperparameter configurations. This is useful in cases where the evaluated
|
||||
training procedure has high variance (i.e., in reinforcement learning).
|
||||
|
||||
By default, ``Repeater`` will take in a ``repeat`` parameter and a ``search_alg``.
|
||||
The ``search_alg`` will suggest new configurations to try, and the ``Repeater``
|
||||
will run ``repeat`` trials of the configuration. It will then average the
|
||||
``search_alg.metric`` from the final results of each repeated trial.
|
||||
|
||||
|
||||
.. warning:: It is recommended to not use ``Repeater`` with a TrialScheduler.
|
||||
Early termination can negatively affect the average reported metric.
|
||||
|
||||
.. autoclass:: ray.tune.suggest.Repeater
|
||||
|
||||
.. _limiter:
|
||||
|
||||
ConcurrencyLimiter (tune.suggest.ConcurrencyLimiter)
|
||||
----------------------------------------------------
|
||||
|
||||
Use ``ray.tune.suggest.ConcurrencyLimiter`` to limit the amount of concurrency when using a search algorithm. This is useful when a given optimization algorithm does not parallelize very well (like a naive Bayesian Optimization).
|
||||
|
||||
.. autoclass:: ray.tune.suggest.ConcurrencyLimiter
|
||||
|
||||
.. _byo-algo:
|
||||
|
||||
Implementing your own Search Algorithm
|
||||
--------------------------------------
|
||||
|
||||
If you are interested in implementing or contributing a new Search Algorithm, provide the following interface:
|
||||
|
||||
.. autoclass:: ray.tune.suggest.Searcher
|
||||
:members:
|
||||
|
||||
Reference in New Issue
Block a user