Как настроить прокси для RAG-пайплайна

Что такое RAG и зачем ему прокси

RAG (Retrieval-Augmented Generation) — архитектурный паттерн, при котором AI-модель перед генерацией ответа обращается к внешней базе знаний. Это решает ключевую проблему LLM: устаревание данных. Модель обучена на данных до определённой даты, а RAG даёт ей доступ к актуальной информации.

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

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

Архитектура RAG-пайплайна с прокси

┌──────────────┐     ┌───────────────┐     ┌──────────────┐
│  Расписание  │────▶│   Краулер     │────▶│  Парсер      │
│  (cron/APScheduler)│ (через прокси) │     │  (извлечение │
└──────────────┘     └───────────────┘     │   текста)    │
                                           └──────┬───────┘
                                                  │
                     ┌───────────────┐     ┌──────▼───────┐
                     │  LLM + промпт │◀────│  Векторная   │
                     │  (генерация)  │     │  база данных │
                     └───────────────┘     └──────────────┘

Прокси участвуют на этапе краулинга. От их характеристик зависит:

• Скорость обновления базы — быстрые прокси = свежие данные
• Стабильность пайплайна — uptime прокси = uptime вашего RAG
• Полнота данных — без блокировок вы получаете все нужные страницы

Шаг 1: настройка подключения к прокси

Начнём с базового подключения через SOCKS5. Для RAG-задач SOCKS5 предпочтительнее HTTP-прокси, потому что он поддерживает любые протоколы и работает на уровне TCP.

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

PROXY = "socks5://user:pass@fi.infraproxy.ru:1080"

def create_session() -> requests.Session:
    """Создаёт сессию с прокси и retry-логикой."""
    session = requests.Session()
    session.proxies = {"http": PROXY, "https": PROXY}
    session.headers.update({
        "User-Agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36",
        "Accept": "text/html,application/xhtml+xml",
        "Accept-Language": "ru-RU,ru;q=0.9,en;q=0.8",
    })

    retries = Retry(
        total=3,
        backoff_factor=1,
        status_forcelist=[429, 500, 502, 503],
    )
    adapter = HTTPAdapter(max_retries=retries)
    session.mount("http://", adapter)
    session.mount("https://", adapter)

    return session

Retry-логика критична для RAG: если один запрос упал по таймауту, пайплайн не должен останавливаться. С uptime 99.9% у InfraProxy повторные запросы нужны редко, но страховка не повредит.

Шаг 2: краулер с sticky-сессиями для многостраничного обхода

При обходе сайтов для RAG часто нужно пройти несколько страниц в рамках одной «сессии» — например, список статей → каждая статья. Если IP меняется между запросами, сайт может сбросить состояние или показать CAPTCHA.

Sticky-сессии фиксируют IP за вашим подключением на заданное время:

import hashlib
import time

def crawl_site_with_sticky_session(
    base_url: str,
    pages: list[str],
    session_duration_min: int = 10
) -> list[dict]:
    """Обходит несколько страниц сайта с фиксированным IP."""
    session = create_session()
    results = []

    # Sticky-сессия: один IP на весь обход одного сайта
    session_id = hashlib.md5(base_url.encode()).hexdigest()[:8]
    sticky_proxy = f"socks5://user-session-{session_id}:pass@fi.infraproxy.ru:1080"
    session.proxies = {"http": sticky_proxy, "https": sticky_proxy}

    for page_path in pages:
        url = f"{base_url}{page_path}"
        try:
            resp = session.get(url, timeout=15)
            if resp.status_code == 200:
                results.append({
                    "url": url,
                    "text": resp.text,
                    "timestamp": time.time(),
                })
            time.sleep(1)  # вежливая пауза между запросами
        except Exception as e:
            print(f"Ошибка при обходе {url}: {e}")

    return results

Совет: для RAG-пайплайнов ставьте паузу 1–2 секунды между запросами к одному домену. Это снижает нагрузку на целевой сайт и уменьшает риск блокировки. При обходе разных доменов паузы не нужны — запросы идут параллельно.

Шаг 3: извлечение текста для RAG-базы

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

from html.parser import HTMLParser
import re

class TextExtractor(HTMLParser):
    """Извлекает текстовое содержимое из HTML, исключая навигацию и скрипты."""

    SKIP_TAGS = {"script", "style", "nav", "footer", "header", "aside"}

    def __init__(self):
        super().__init__()
        self.result = []
        self.skip_depth = 0

    def handle_starttag(self, tag, attrs):
        if tag in self.SKIP_TAGS:
            self.skip_depth += 1

    def handle_endtag(self, tag):
        if tag in self.SKIP_TAGS and self.skip_depth > 0:
            self.skip_depth -= 1

    def handle_data(self, data):
        if self.skip_depth == 0:
            text = data.strip()
            if text:
                self.result.append(text)

    def get_text(self) -> str:
        return "\n".join(self.result)

def html_to_text(html_content: str) -> str:
    extractor = TextExtractor()
    extractor.feed(html_content)
    text = extractor.get_text()
    # Убираем множественные пробелы и пустые строки
    text = re.sub(r'\n{3,}', '\n\n', text)
    return text.strip()

Шаг 4: расписание обходов

RAG-база актуальна только если данные обновляются регулярно. Частота зависит от типа контента:

| Тип контента | Частота обхода | Пример | |-------------|---------------|--------| | Новости | Каждый час | Информационные агентства, блоги | | Документация | Раз в день | Техническая документация, FAQ | | Каталоги | Раз в неделю | Справочники, базы данных | | Законодательство | Раз в месяц | Правовые базы, ГОСТы |

from apscheduler.schedulers.blocking import BlockingScheduler

scheduler = BlockingScheduler()

# Источники для RAG
sources = [
    {"url": "https://docs.example.com/", "pages": ["/api", "/faq", "/changelog"], "interval": "daily"},
    {"url": "https://news.example.com/", "pages": ["/feed"], "interval": "hourly"},
]

def update_rag_source(source: dict):
    """Обновляет RAG-базу данными из одного источника."""
    results = crawl_site_with_sticky_session(source["url"], source["pages"])
    for r in results:
        text = html_to_text(r["text"])
        # Здесь: разбиение на чанки, эмбеддинги, сохранение в векторную БД
        print(f"Обновлено: {r['url']} ({len(text)} символов)")

for source in sources:
    if source["interval"] == "hourly":
        scheduler.add_job(update_rag_source, "interval", hours=1, args=[source])
    elif source["interval"] == "daily":
        scheduler.add_job(update_rag_source, "interval", hours=24, args=[source])

scheduler.start()

Масштабирование: от 10 до 1000 источников

Когда RAG-база растёт, растёт и нагрузка на прокси. Ключевые метрики, за которыми стоит следить:

• Количество одновременных соединений — не превышайте лимит вашего тарифа
• Распределение по доменам — не отправляйте больше 1 запроса в секунду к одному домену
• Процент успешных ответов — должен быть выше 95%, иначе пересмотрите стратегию ротации

С пулом InfraProxy (100 000+ IP, серверы на AMD EPYC) можно держать сотни параллельных соединений. При этом ротация IP происходит автоматически — каждый новый запрос получает свежий адрес из пула.

Подробнее о масштабировании краулинга — в статье Масштабирование скрейпинга: от 1 000 до 10 000 000 страниц в день.

Мониторинг пайплайна

# Быстрая проверка: работает ли прокси
curl -x socks5://user:pass@fi.infraproxy.ru:1080 \
  -s -o /dev/null -w "%{http_code} %{time_total}s" \
  "https://httpbin.org/ip"

# Ожидаемый результат: 200 0.150s (или быстрее)

Встраивайте проверку прокси в мониторинг пайплайна. Если время ответа прокси превышает 1 секунду или статус не 200 — это сигнал о проблеме.

Типичные ошибки при настройке прокси для RAG

1. Один IP на все запросы — без ротации вас заблокируют после первых сотен запросов
2. Нет retry-логики — сеть нестабильна, 1–2% запросов всегда будут падать
3. Слишком агрессивный краулинг — 100 запросов в секунду к одному домену вызовут блокировку даже с прокси
4. Игнорирование robots.txt — помимо этических аспектов, это ещё и способ узнать о rate-limits сайта

Подробнее о правовых аспектах сбора данных — в статье Правовые аспекты веб-скрейпинга.

Итог: чек-лист для RAG с прокси

| Шаг | Описание | |-----|----------| | 1 | Определить список источников и частоту обхода | | 2 | Настроить подключение к прокси (SOCKS5 или HTTP) | | 3 | Реализовать sticky-сессии для многостраничных обходов | | 4 | Добавить retry-логику и таймауты | | 5 | Настроить извлечение текста и индексацию | | 6 | Запустить по расписанию и настроить мониторинг |

InfraProxy предоставляет стабильную инфраструктуру для RAG: 100 000+ IP, uptime 99.9%, поддержка SOCKS5 и HTTP/HTTPS. Подробнее о возможностях для AI-команд — на странице Прокси для AI.

---

Попробуйте InfraProxy — тестовый доступ за 1 день. Подберём конфигурацию под ваш RAG-пайплайн. Оставить заявку →