← Все статьи
Вариант использования 5 минут чтения

Проблема повторного сканирования: как поддерживать актуальность RAG-конвейеров

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

ragai-trainingdata-collectionvertical-aiuse-case

Проблема

Вертикальные AI-стартапы упираются в одну и ту же стену примерно на второй месяц. Они выпускают ассистента техподдержки, помощника для юридических исследований или комплаенс-бота. Первое демо привлекает клиентов. Затем данные устаревают, и ответы начинают расходиться с реальностью.

Мы часто видели, как команды аккуратно строят AI-составляющую, оставляя работу с данными на потом. Пайплайн сбора данных представляет собой один Python-скрипт, запущенный на чьем-то ноутбуке. Он один раз парсит 200 исходных URL, выгружает чистый Markdown в векторное хранилище, и все довольны. Через шесть недель половина ответов ссылается на удаленные страницы, устаревшие API или функции продукта, которые вышли в марте и снова изменились в мае.

Решение кажется простым: еженедельно перезапускать сбор данных по всем источникам. На деле все сложнее. К 2026 году около 60% авторитетных сайтов блокируют AI-краулеры (по сравнению с 23% в конце 2023 года), и защита больше не ограничивается банальной проверкой User-Agent. Системы защиты анализируют поведение сессий, ритм запросов и сигналы на уровне TLS-рукопожатия. Примитивный скрипт, работавший в январе, в марте начинает молча отдавать пустые страницы.

Хуже того, некоторые сайты теперь отдают тарпит-контент (сгенерированную марковскими цепями бессмыслицу, похожую на связный текст), что отравляет ваши эмбеддинги. В итоге инженеры тратят полнедели на правку парсера вместо выпуска продукта. Качество поиска падает, клиенты это замечают, а команда, нанятая для разработки AI, превращается в службу поддержки парсеров.

Подход

Задача повторного сбора данных сводится к трем конкретным решениям, которые необходимо принимать при каждом запросе:

  1. Рендерить или нет? Большинство порталов документации отдают чистый HTML. Но все большая их часть (все, что построено на Next.js или использует client-side rendering) требует полноценного рендеринга в браузере для получения полезного контента.
  2. Какой proxy выбрать? Residential, datacenter, мобильный, с геопривязкой или конкретного провайдера. Оптимальный выбор зависит от целевого ресурса.
  3. Сработал ли запрос на самом деле? Ответ 200 с пустым телом или страница проверки является успешным HTTP-запросом, но провалом для краулера.

Платформа вроде FourA решает каждую из этих задач как ключевую функцию.

Для выбора типа рендеринга вы вызываете Single для простых и быстрых сценариев или Browser для страниц с тяжелым JS. Структура тела запроса одинакова, поэтому код пайплайна ветвится один раз по флагу источника, избавляя от необходимости поддерживать сотни специфических хаков под каждый сайт.

Для выбора proxy инструмент Proxy Finder запускается автоматически при каждом вызове Single, Browser и Auto. Платформа подбирает рабочий выходной узел на каждый запрос, возвращает его непрозрачный id в ответе (на верхнем уровне r.proxy в Single/Browser или в r.session.proxy в Auto), и вы используете этот id в последующих вызовах, если нужно сохранить тот же узел. Вашему краулеру не требуется собственный алгоритм ранжирования proxy. (Мы подробно описали, почему размер пула перестал быть решающим фактором, в статье Why Proxy Pool Size Stopped Mattering in 2026.)

А для ответа на вопрос «сработало ли это на самом деле» каждый request поддерживает блок validate. Вы сами определяете критерии успеха: допустимые статус-коды, обязательные значения header, а также строки в body, которые должны присутствовать или отсутствовать. FourA возвращает один из семи результатов, и тарифицируется только success. Ответ с кодом 200, не прошедший проверку ваших правил контента, помечается как application_fail и никогда не попадает в ваш датасет.

Вот как выглядит вызов повторного обхода для портала документации, требующего JS render. Мы доверяем оркестрацию режиму Auto: он выбирает нужный продукт (Single, Proxy или Browser), обходит защиту от ботов и возвращает триплет сессии, чтобы следующий повторный обход мог использовать ту же точку выхода:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Если целевой ресурс отдает заглушку Cloudflare, правило validate.data.fail перехватывает ее. В статистику использования записывается статус application_fail. Вы не платите за этот запрос, а ваш конвейер сбора данных понимает, что нужно повторить попытку через другой proxy, вместо того чтобы скармливать страницу «Just a moment...» в эмбеддинги.

Для основного массива данных этот же паттерн встраивается в вашу текущую очередь задач. Команды, с которыми мы общались, запускают ночной расчет diff относительно предыдущего обхода, заново строят эмбеддинги только для реально изменившихся документов и обновляют базу из 500 источников за пару часов общего времени. Очередь задач остается вашей. Ротация proxy, логика рендеринга и верификация успешности ответа остаются на нашей стороне.

Результаты

Как выглядит цикл обновления данных, когда инфраструктура перестает быть узким местом (показательный сценарий на основе паттернов команд вертикального AI):

  • 500 целевых URL переобходятся еженедельно вместо разового сбора 200 URL на релизе
  • Инженерные затраты на парсер: менее 2 часов в неделю вместо прежних 1-2 дней
  • Окно устаревания данных в поиске: 5-7 дней вместо неконтролируемого срока
  • Доля мусорных данных в векторном хранилище близка к нулю, поскольку заглушки Cloudflare и страницы-ловушки отсекаются на уровне validate до попадания в модель эмбеддингов
  • Предсказуемая стоимость по каждому источнику, так как неудачные попытки обхода не тарифицируются

Суть не в том, что здесь есть какая-то магия. Суть в том, что все это работает рутинно и предсказуемо. А именно такая надежность и нужна production AI. (Подробнее о том, где экономика облачного извлечения через LLM перестает сходиться, читайте в статье When LLM Extraction Stops Paying for Itself.)

Главный вывод

Большинство команд в сфере вертикального AI считают своим главным преимуществом промпты, выбор модели или алгоритм поиска. Это не так. Настоящее конкурентное преимущество заключается в цикле обновления: невидимой инфраструктуре, которая неделя за неделей поддерживает актуальность базы знаний.

Победителями в вертикальном AI к 2026 году станут не те, у кого самые изощренные промпты. Выиграют те, чьи пользователи даже не задумываются о свежести данных, потому что они актуальны всегда.