Многорукий бандит: как выбирать тип прокси по данным, а не наугад

Если у вас несколько типов прокси и вы не знаете заранее, какой лучше сработает на конкретном сайте, это задача многорукого бандита. Её решают не правилами «сначала дешёвый, потом дорогой», а алгоритмом, который сам учится на результатах запросов и минимизирует цену за успешный запрос.

Откуда взялась идея#

Подход разобрал Логан Харлесс (Logan Harless), технический директор компании String, на конференции Extract Summit в октябре 2026 года. Его доклад о том, как выбирать способ получения данных для каждого сайта, когда вариантов много, а заранее неизвестно, какой из них сработает.

Доклад Логана Харлесса на Extract Summit 2026 (на английском)

Ниже — адаптация этой идеи под практическую задачу: какой тип прокси использовать для сбора данных с конкретного сайта. Код и цифры симуляции — наши.

Что такое задача многорукого бандита#

Название пришло от игровых автоматов с рычагом — «одноруких бандитов». Представьте зал с несколькими автоматами: у каждого своя стоимость игры и своя, неизвестная вам, вероятность выигрыша. Нужно потратить бюджет так, чтобы выиграть как можно больше.

Сложность в балансе двух действий. Использование (exploitation) — играть на автомате, который пока выглядит лучшим. Исследование (exploration) — иногда пробовать другие, вдруг они лучше или стали лучше.

С прокси всё то же самое:

• «рычаги» — варианты подключения: серверные, ISP, резидентные или мобильные прокси, разные страны;
• стоимость каждого варианта известна;
• вероятность получить нужный ответ на конкретном сайте заранее неизвестна и со временем меняется.

Есть и отличие от учебной задачи. В учебнике вероятности выигрыша постоянны. На реальных сайтах меняются вёрстка, нагрузка, правила доступа, поэтому вариант, который хорошо работал месяц назад, сегодня может работать хуже.

Главная метрика — цена за успешный запрос#

Прокси обычно сравнивают по цене за гигабайт или за IP. Для сбора данных это неточная метрика: неудачный запрос тоже тратит трафик и время, а результат всё равно приходится получать повторной попыткой.

Поэтому сравнивать варианты стоит так:

Цена за успешный запрос = цена одного запроса ÷ доля успешных запросов

Пример на условных цифрах:

Здесь самый дешёвый вариант выгоднее, несмотря на 40% неудач. Но если доля успешных у него упадёт до 10%, цена за успешный запрос вырастет до 10 у. е., и лучшим станет вариант A. Задача алгоритма — заметить это вовремя.

Что считать успешным запросом, решаете вы: обычно это ответ с кодом 200 и ожидаемым содержимым страницы, а не просто любой ответ сервера.

Какие подходы бывают#

Отдельно стоит вариант «спрашивать языковую модель перед каждым запросом». Он может принимать решения точнее, но при миллионах запросов это слишком дорого и медленно. Алгоритмы бандитов решают ту же задачу за доли миллисекунды.

Как работает Thompson sampling#

Для каждого варианта алгоритм хранит два числа: сколько было успешных запросов и сколько неудачных. Из них получается не одна оценка вероятности успеха, а распределение возможных значений: чем больше данных, тем оно уже.

Хорошо изученные варианты дают стабильные оценки и выбираются, когда они действительно выгодны. Малоизученные дают разброс и время от времени «выстреливают» — так алгоритм сам решает, когда исследовать, без ручной настройки доли проверок.

Для меняющихся условий нужна ещё одна деталь — забывание. Перед каждым обновлением старые счётчики немного уменьшаются, поэтому свежие результаты весят больше давних. Без этого алгоритм, накопивший тысячи успехов варианта, долго не замечает, что тот перестал работать.

Пример на Python#

Минимальная реализация без внешних библиотек. Цены в примере условные:

import random


class ProxyBandit:
    """Выбор типа прокси по цене за успешный запрос (Thompson sampling с забыванием)."""

    def __init__(self, costs, decay=0.995):
        self.costs = costs                         # цена одного запроса по каждому варианту
        self.decay = decay                         # 1.0 — без забывания, меньше — быстрее забывает
        self.wins = {arm: 1.0 for arm in costs}    # начальные счётчики успехов
        self.losses = {arm: 1.0 for arm in costs}  # начальные счётчики неудач

    def choose(self):
        best_arm, best_price = None, float("inf")
        for arm, cost in self.costs.items():
            p = random.betavariate(self.wins[arm], self.losses[arm])
            price = cost / max(p, 1e-6)            # ожидаемая цена за успешный запрос
            if price < best_price:
                best_arm, best_price = arm, price
        return best_arm

    def update(self, arm, success):
        for a in self.costs:                       # старые результаты постепенно теряют вес
            self.wins[a] = 1 + (self.wins[a] - 1) * self.decay
            self.losses[a] = 1 + (self.losses[a] - 1) * self.decay
        if success:
            self.wins[arm] += 1
        else:
            self.losses[arm] += 1


bandit = ProxyBandit({"server": 1.0, "residential": 2.0, "mobile": 4.0})

arm = bandit.choose()          # какой тип прокси использовать для следующего запроса
success = True                 # здесь — результат вашего запроса через выбранный тип
bandit.update(arm, success)

Отдельный экземпляр ProxyBandit заводится на каждый сайт или группу похожих сайтов. Параметр decay подбирается под то, как быстро меняются условия: 0,995 означает, что результат примерно 140-запросной давности весит вдвое меньше свежего.

Как настроить паузы и число повторов, мы разбирали в статье о таймаутах и повторных запросах.

Что показала симуляция#

Мы прогнали код выше на условной задаче: собрать 10 000 страниц, каждую нужно получить обязательно, при неудаче — повторная попытка. Три варианта из таблицы выше: A — 4 у. е. и 90% успешных, B — 2 у. е. и 75%, C — 1 у. е. и 60%. Результаты усреднены по 30 прогонам.

Условия не меняются#

Когда условия стабильны, Thompson sampling и «проверить и закрепить» почти равны. Ради такого случая сложный алгоритм не нужен — достаточно один раз измерить и выбрать.

Посередине работы условия меняются#

На половине задачи доля успешных запросов падает: у A — до 85%, у B — до 30%, у C — до 10%. Теперь выгоднее всего A. Идеальный результат, если сразу знать о смене, — около 3,19 у. е. за страницу.

Подход «проверить и закрепить» продолжает платить за вариант, который почти перестал работать, — в среднем больше пяти попыток на страницу. Thompson sampling без забывания помнит тысячи старых успехов и переключается слишком поздно. Версия с забыванием перестраивается быстро и отстаёт от идеала примерно на 4%.

Среди вариантов есть неработающий#

Добавили четвёртый вариант: самый дешёвый (0,5 у. е.), но без единого успешного запроса. «По кругу» тратит на него каждую четвёртую попытку, каскад начинает с него каждую страницу. Обучаемые алгоритмы перестают его выбирать после нескольких неудач, их цена за страницу почти не изменилась.

Как сократить число вариантов#

Чем больше вариантов, тем дольше алгоритм учится. Если перемножить типы прокси, страны и настройки, легко получить тысячи комбинаций, а на один сайт у вас может быть всего пара тысяч запросов. Этого не хватит, чтобы изучить даже малую часть.

В симуляции из доклада Харлесса тот же алгоритм на 12 вариантах заметно обгонял себя же на 36 вариантах, которые по сути были теми же 12, только продублированными.

Когда алгоритм не нужен#

• Сайтов мало, условия стабильны — достаточно один раз измерить цену за успешный запрос и выбрать.
• Запросов к сайту мало (условно сотни) — алгоритм не успеет ничему научиться.
• Важна только одна метрика, например максимальная доля успешных запросов любой ценой, — тогда выбор очевиден и без обучения.

Совет из доклада, с которым сложно спорить: начните с самого простого решения и усложняйте его, только когда оно перестанет справляться. Правила и каскады — самый дешёвый и понятный инструмент там, где они работают.

У подхода есть и ограничения. Сложно сформулировать, что именно оптимизировать: кому-то важнее цена, кому-то скорость, кому-то предсказуемая доля успешных запросов. И статистику нужно где-то хранить: чем подробнее ключ (сайт, раздел, страница), тем больше данных.

Как это устроено у нас#

В Proxy.Market есть все основные типы прокси, между которыми можно выбирать, — то есть «рычаги» для алгоритма:

• серверные прокси IPv4 — обычно самый дешёвый вариант в расчёте на запрос;
• ISP-прокси — статические адреса интернет-провайдеров;
• резидентные прокси — адреса домашних подключений, оплата за трафик;
• мобильные прокси — адреса мобильных операторов, оплата за трафик.

Для резидентных и мобильных прокси, где оплачивается трафик, цена за успешный запрос особенно наглядна: неудачный ответ тоже расходует пакет. Как прикинуть расход, мы разбирали в статье о трафике для парсинга, а как проверить прокси до покупки — в статье о проверке качества прокси.

Частые вопросы#