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

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

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

ragai-trainingdata-collectionvertical-aiuse-case

Сложность

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

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

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

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

Подход

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

  1. Рендерить или нет? Большинство порталов документации отдают чистый HTML. Растущая доля (все, что создано на Next.js, и любые ресурсы с клиентским рендерингом) требует полноценного рендеринга в браузере для получения полезного контента.
  2. Какой proxy? Резидентские, дата-центровые, мобильные, с геопривязкой, привязанные к конкретному провайдеру. Правильный выбор зависит от цели.
  3. Действительно ли это сработало? Код 200 с пустым телом или HTML-страница CAPTCHA представляют собой успешный HTTP-запрос, но неудачное сканирование.

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

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

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

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

Вот как выглядит вызов повторного сканирования для портала документации, которому требуется рендеринг JS. Мы позволяем 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"]    — rendered body
# r["meta"]    — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["meta"]["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...» в эмбеддинги.

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

Результаты

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

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

Суть не в том, что все это магия. Суть в том, что это рутина. Именно рутина нужна ИИ в продакшене. (Подробнее о том, в каких случаях экономика перестает сходиться при извлечении данных с помощью облачных LLM, читайте в статье Когда извлечение данных с помощью LLM перестает окупаться.)

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

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

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