Построение конвейера RAG на основе данных из реального веб-трафика (без использования устаревших индексов)

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

Основные выводы

• Классическая система RAG использует данные из статического индекса, поэтому максимальная актуальность результатов ограничивается датой последнего сканирования.
• Система Live-web RAG находит источники с помощью поискового API, загружает и очищает страницы во время обработки запроса, а затем подкрепляет ответ ссылками на источники.
• Сложность заключается не в извлечении данных. Сложность заключается в том, чтобы определить, когда следует запрашивать данные в режиме реального времени, а когда — использовать кэшированный фрагмент, что регулируется временем жизни (TTL) актуальности для каждой темы.
• По прогнозам компании Gartner, к концу 2026 года 40 % корпоративных приложений будут оснащены специализированными ИИ-агентами, тогда как в настоящее время их доля составляет менее 5 %, и этим агентам необходимы актуальные данные.
• Чистый Markdown превосходит необработанный HTML на этапе обработки, поскольку он снижает затраты на токенизацию и удаляет элементы навигации, рекламу и шаблонные фрагменты перед разбиением на блоки.

Классическая модель RAG имела смысл, когда ваш корпус представлял собой медленно обновляемую базу знаний: документацию, политики, заявки. Однако стоит направить её на открытый Интернет — и модель перестаёт работать. Цены меняются, появляются новости, рейтинги меняются, а векторный индекс, построенный в прошлый вторник, уверенно возвращает реальность прошлого вторника. Решением проблемы не является создание более крупного индекса или ускорение графика повторного сканирования. Напротив, решением является перенос запроса данных, которые действительно меняются, на момент выполнения запроса. RAG — это генерация с использованием данных из поисковой системы (RAG): модель формирует ответы на основе документов, которые вы извлекаете и предоставляете ей, а не только на основе своих обучающих весов. В этой статье шаг за шагом рассматривается архитектура, а затем подробно описывается логика актуализации данных, которая отличает RAG с использованием данных из реального Интернета от классической версии. Чтобы получить более полное представление о предоставлении агентам актуальных данных, начните с раздела, посвященного Как предоставить ИИ-агентам доступ к веб-ресурсам в режиме реального времени.

Почему классическая модель RAG теряет актуальность при работе с веб-данными?

Классическая модель RAG теряет актуальность, поскольку предоставляет ответы на основе моментального снимка. Вы выполняете сканирование, разбиваете контент на фрагменты, встраиваете и сохраняете его, а затем каждый запрос обращается к этой «замороженной» копии до следующего сканирования. Для стабильного корпуса данных это вполне подходит. Однако для открытого Интернета это является проблемой, и спрос на агенты, работающие с актуальными данными, растет. По прогнозам Gartner, в 2025 году К концу 2026 года 40 % корпоративных приложений будут оснащены ИИ-агентами, предназначенными для выполнения конкретных задач, по сравнению с менее чем 5 % в 2025 году. Агенты, отвечающие на реальные вопросы, не могут работать на основе устаревших данных.

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

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

Как выглядит архитектура RAG в режиме реального времени?

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

Ниже приводится описание процесса в виде списка шагов:

1. Понимание запроса -> преобразование вопроса пользователя в поисковый запрос
2. Поиск источников -> поисковый API возвращает подходящие URL-адреса
3. Загрузка + очистка -> преобразование каждого URL-адреса в чистый формат Markdown
4. Разбиение на фрагменты + встраивание -> разбиение Markdown на фрагменты и их встраивание во время обработки запроса
5. Получение top-k -> ранжирование фрагментов по встраиванию запроса
6. Обоснование + цитирование -> LLM отвечает, используя только полученные фрагменты, с указанием ссылок на источники
7. Кэширование + TTL -> хранение фрагментов с ограничением срока актуальности для повторного использования

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

Этап 1: понимание запроса

Прежде чем обращаться к веб-ресурсам, преобразуйте исходный вопрос пользователя в поисковый запрос. Удалите разговорные наполнители, разверните аббревиатуры и извлеките сущности и временную значимость. Например, фраза «Какие последние новости о приобретении X?» подразумевает актуальность, в то время как вопрос, касающийся определения, — нет. На этом этапе определяется, насколько активно остальная часть конвейера будет отдавать предпочтение свежим данным перед кэшированными фрагментами. Недорого в эксплуатации, с высокой отдачей в плане качества.

Этап 2: поиск действующих источников

Именно на этапе обнаружения большинство конвейеров незаметно терпят неудачу, поскольку модель не может вывести результаты на страницы, которые она так и не нашла. Выявление источников — это этап, на котором замысел запроса преобразуется в набор возможных URL-адресов, как правило, с помощью поискового API, а не путем угадывания доменов. Здесь важна конечная точка SERP с возможностью геотаргетинга: результаты по запросу «лучшее X рядом со мной» или по ценовому запросу различаются в зависимости от страны и города, и вам нужны именно те источники, которые пользователь действительно увидит. Сравнение вариантов см. API веб-поиска для агентов.

На этом первом этапе в дело вступает Web Render API от Massive. Конечная точка Search (/поиск) извлекает результаты из поисковой выдачи основных поисковых систем и позволяет настраивать географическую таргетировку по стране, региону или городу. Для запросов, в которых учитывается содержание резюме, сгенерированного искусственным интеллектом, в ожидании=ai ожидает появления обзора ИИ в течение одной минуты, и в ожидании ответов вызывает функцию «People-Also-Ask». Вы получаете набор URL-адресов кандидатов, отсортированных в том порядке, в котором их увидел бы реальный пользователь из данного региона.

Этап 3: получение и очистка

Именно при запросе страниц-кандидатов система RAG в режиме реального времени сталкивается с механизмами защиты современного Интернета, а современный Интернет настроен враждебно по отношению к ботам. В 2025 году компания Imperva сообщила, что В 2024 году на долю автоматизированных ботов приходилось 51 % всего веб-трафика— это первый случай за последнее десятилетие, когда количество ботов превысило количество людей, причем доля вредоносных ботов составила 37 %. Сайты реагируют на это активной блокировкой, в результате чего запросы, поступающие из центров обработки данных, подвергаются проверке или получают ложный контент.

На данном этапе необходимо выполнить два условия. Во-первых, ваш запрос должен пройти через систему защиты страницы от ботов, иначе вы попадете на страницу ошибки. Прокси-серверы для частного использования запросы пропускаются через реальные потребительские устройства, благодаря чему трафик исходит с частных IP-адресов, а не из диапазона IP-адресов дата-центра, который может быть заблокирован. API Web Render компании Massive выполняет запросы через сеть реальных потребительских устройств, охватывающую более 195 стран и насчитывающую около 1,3 млн активных устройств в день. По результатам наших тестов, успешность доступа с частных IP-адресов на защищенных сайтах, как правило, значительно выше, чем с центров обработки данных (приблизительные диапазоны: частные IP-адреса — ~85–99 % против центров обработки данных — ~20–40 %); рассматривайте эти данные как ориентир поставщика, а не как результаты независимого исследования.

Во-вторых, вам нужен очищенный текст, а не исходный HTML-код. Конечная точка «Просмотр» (/браузер) поддерживает формат=markdown в качестве конечного результата, возвращая Markdown-код, готовый для обработки в LLM, из которого удалены элементы навигации, реклама и шаблонные фрагменты. Это важно перед разбиением на фрагменты: Markdown значительно сокращает количество токенов по сравнению с исходным HTML-кодом, что снижает затраты на встраивание и генерацию и позволяет сохранить смысловую наполненность фрагментов, а не перегружать их ссылками на меню. Специалисты в этой области зафиксировали тот же эффект (dev.to, Инструменты браузера для ИИ-агентов. Часть 4: Отказ от использования браузера(2026 г.).

Этап 4: разбиение на блоки и закрепление

Разделите очищенный текст в формате Markdown на фрагменты и встраивайте их во время выполнения запроса. Поскольку корпус состоит лишь из нескольких страниц, извлеченных этим запросом, этот процесс выполняется быстро и не требует больших затрат; вы встраиваете всего несколько килобайт, а не результаты сканирования всего Интернета. Сохраняйте соответствие фрагментов структуре Markdown по заголовкам и абзацам, чтобы каждый фрагмент оставался самодостаточным. Заголовки Markdown дают вам естественные границы, которых нет в исходном HTML.

Этап 5: выборка top-k

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

Этап 6: подкрепите свои выводы ссылками

Предоставьте модели только найденные фрагменты и попросите её давать ответы на их основе, указывая ссылку на источник для каждого утверждения. Заземление Это практика, при которой ответ модели ограничивается найденными доказательствами, а не её параметрической памятью; таким образом, договор об обоснованности заключается в следующем: нет фрагмента — нет утверждения. Поскольку каждый фрагмент содержит URL-адрес источника, полученный на этапе 2, ссылки предоставляются бесплатно, и читатель (или последующая проверка) может сверять ответ с актуальной версией страницы. Обоснование на основе текста, полученного буквально секунду назад, и есть весь смысл перехода в режим реального времени.

Этап 7: кэш с временем жизни (TTL)

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

Как избежать устаревания индексов с помощью TTL?

Чтобы избежать использования устаревших индексов, необходимо привязать к каждому кэшированному фрагменту срок хранения (TTL) и повторно загружать актуальные данные по истечении этого срока. A срок годности — это срок хранения (TTL) для каждого фрагмента, который определяет, как долго кэшированные данные остаются достоверными, прежде чем их необходимо обновить. TTL устанавливается для каждой темы отдельно, а не глобально: цена акции может оставаться актуальной в течение нескольких секунд, технические характеристики продукта — в течение нескольких дней, а энциклопедическое определение — в течение нескольких недель. При поступлении запроса вы сначала проверяете кэш, предоставляете фрагменты, срок действия которых ещё не истек, и запускаете запрос к источнику для данных, срок действия которых истек или которые отсутствуют. Это гибридный подход: быстрый, когда это возможно, и актуальный, когда это необходимо.

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

Обеспечение неактуальности данных имеет такое же значение, как и истечение срока хранения. Параметр TTL позволяет решать проблему устаревания данных по времени, однако некоторые события требуют немедленного аннулирования: страница, на которую вы ссылались, возвращает ошибку 404, авторитетный источник публикует исправление или в запросе появляется объект, известный своей изменчивостью (результаты спортивных соревнований в режиме реального времени, последние новости). Создайте явный путь аннулирования для таких случаев, а не ждите, пока истечет срок. Одним словом, сочетание TTL для каждой темы и аннулирования по событиям — это то, что отличает конвейер «живого» веб-контента от классического индекса, который просто повторно сканирует страницы по расписанию cron.

Еще одна причина, по которой в 2025 году динамические данные, как правило, будут превосходить статические индексы: открытый Интернет активно закрывается для массовых сканеров. Компания Cloudflare сообщила, что С 1 июля 2025 года началась блокировка роботов искусственного интеллекта по умолчанию примерно на 20 % веб-сайтов и запустила платформу, работающую по принципу «оплата за сканирование». В результате с каждым кварталом поддержка готового индекса открытого Интернета становится всё сложнее и дороже. Загрузка данных во время запроса через сеть реальных устройств позволяет обойти проблему массового сканирования, поскольку вы загружаете несколько страниц, к которым может обратиться реальный пользователь, а не весь Интернет по расписанию. Если вы хотите предоставить этот конвейер агентам в качестве вызываемого инструмента, ознакомьтесь с инструкциями по создать сервер MCP для извлечения данных из веб-ресурсов.

Когда следует загружать данные в реальном времени, а когда — использовать их из кэша?

Запрашивайте данные в режиме реального времени, если для запроса важна актуальность или срок хранения (TTL) соответствующей записи в кэше истек; повторно используйте кэшированный фрагмент, если он по-прежнему актуален, а запрос не изменяется. Решение принимается для каждого запроса отдельно на основе сигнала о чувствительности к времени, полученного на этапе 1, и оставшегося времени жизни (TTL) фрагмента. Правильная настройка этого правила определяет расходование вашего бюджета на задержку и затраты, поэтому настраивайте его с учетом реального трафика, а не на основе предположений.

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

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

Источники

• Gartner, По прогнозам Gartner, к 2026 году 40 % корпоративных приложений будут оснащены специализированными ИИ-агентами, тогда как в 2025 году их доля составит менее 5 %, 2025 год. https://www.gartner.com/en/newsroom/press-releases/26.08.2025 — Gartner прогнозирует, что к 2026 году 40 % корпоративных приложений будут оснащены ИИ-агентами для выполнения конкретных задач, тогда как в 2025 году их доля составит менее 5 %.
• Imperva, Отчет о вредоносных ботах за 2025 год, 2025 год. https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
• Cloudflare, Cloudflare только что изменила подход к сбору данных в Интернете с помощью ИИ-ботов, 2025 год. https://www.cloudflare.com/press/press-releases/2025/cloudflare-just-changed-how-ai-crawlers-scrape-the-internet-at-large/
• dev.to, Инструменты браузера для ИИ-агентов. Часть 4: Отказ от использования браузера, 2026 год. https://dev.to/stevengonsalvez/browser-tools-for-ai-agents-part-4-skip-the-browser-save-80-on-tokens-304c