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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 2: поиск активных источников

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

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

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

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

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

Во-вторых, вам нужен очищенный текст, а не исходный HTML-код. Конечная точка «Просмотр» (/browser) поддерживает format=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 устанавливается для каждой темы отдельно, а не является глобальным: цена акции может оставаться актуальной в течение нескольких секунд, технические характеристики товара — в течение нескольких дней, а энциклопедическое определение — в течение нескольких недель. При поступлении запроса вы сначала проверяете кэш, предоставляете фрагменты, срок действия которых ещё не истек, и запускаете запрос к источнику для данных, срок действия которых истек или которых в кэше нет. Это гибридный подход: быстрый, когда это возможно, и актуальный, когда это необходимо.

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

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

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

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

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

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

Настройте пороговые значения, отслеживая два типа сбоев. Устаревшие ответы (слишком длительный срок хранения в кэше (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