Постепенное наполнение вашей системы RAG свежими данными с веба
TL;DR
Пайплайн ingestion RAG требует кроллинга с источником правды, стабильной идентификации документа и пути обновления; одних только встраиваний недостаточно для актуальности ответов.
Используйте кроллинг сайта для ограниченного открытия документации, затем проверяйте каждую страницу перед очисткой, делением на части, встраиванием и индексацией.
Храните source_url, crawled_at, content_hash и стабильный идентификатор страницы с каждым сегментом, чтобы обновления и ссылки оставались управляемыми.
Рассматривайте код ниже как интеграционную схему: поля API соответствуют текущей документации Nstdata и библиотеки, но путь от начала до конца не был протестирован с живыми учетными данными.
Введение: Свежие данные веба — это проблема ingestion
Nstdata Crawl — это слой сбора в этом рабочем процессе; его обзор продукта описывает извлечение страниц и сайтов для инициирования потоков данных.
Языковая модель может объяснить API из своих обучающих данных и все равно дать вам устаревшее имя параметра. Система RAG сокращает этот разрыв, извлекая документы во время получения ответа, но извлечение актуально только до тех пор, пока документы уже проиндексированы. Чтобы обеспечить систему RAG свежими данными веба, вам нужен повторяемый путь от исходных URL к проверенным записям и способ замены или удаления старых записей.
Этот гид строит этот путь для публичной документации: Nstdata Crawl → Проверка Markdown → сегменты с учетом заголовков → встраивания → Chroma → извлечение. Он сосредоточен на ingestion и свежести, а не на обучении модели. Nstdata Crawl отвечает за получение страниц и преобразование контента; ваша программа все еще контролирует политику данных, деление на части, индексацию, контроль доступа и оценку ответов. Текущий гид по Crawl описывает вывод Markdown, задачи с страницами/сайтами, SDK на Python, статус задач и ссылки на большие результаты в своей документации по Crawl.
Попробуйте Nstproxy Crawl - Начните Бесплатно Уже Сегодня
Что означает ingestion данных RAG
Ingestion данных RAG — это процесс, который превращает исходный материал в записи, по которым может искать система извлечения. Данные для обучения модели «впечатываются» в веса модели. Индекс RAG — это внешняя, заменяемая коллекция документов и встраиваний. Свежие данные веба — это то, что ваш сборщик извлекает с сайта сейчас; они не доходят до модели, пока ваш поток данных не проверит и не проиндексирует их.
Если страница документов изменяется в 10:00, но ваш индекс перестраивается раз в неделю, запрос в 10:05 все еще может вернуть инструкции прошлой недели. Ответ может звучать свободно и все равно быть устаревшим. Записывайте как когда источник был собран, так и какая версия контента была проиндексирована, чтобы сделать эту задержку видимой.
Пайплайн в одно мгновение
Этап
Вход → выход
Основная проверка
Открытие
домен, карта сайта или список URL → разрешенные URL
Являются ли URL в пределах и разрешены ли?
Кроллинг
URL → Markdown и метаданные страницы
Завершилась ли задача и содержит ли тело ожидаемый контент?
Нормализация
извлеченная страница → каноническая запись документа
Стабильны ли URL, заголовок, версия и хеш контента?
Деление на части
документ → извлекаемые отрывки
Остались ли заголовки, код и таблицы целыми?
Встраивание и хранение
отрывки → векторы плюс метаданные
Совпадают ли размеры вектора и идентификаторы записей с индексом?
Извлечение и ответ
вопрос → доказательства и указанный ответ
Можно ли проследить ответ к текущим исходным отрывкам?
Предварительные условия и пример стека
Используйте Python 3.10 или более позднюю версию, токен Nstdata Crawl, ключ провайдера встраивания и коллекцию Chroma. Установите SDK и зафиксируйте разрешенные версии в вашем проекте после стадии тестирования:
Точные версии должны быть записаны в вашем lockfile, так как поведение SDK может измениться. Среда, использованная для подготовки этого черновика, не имеет учетных данных Crawl или OpenAI, поэтому ниже приведенные вызовы сервисов не были выполнены в режиме реального времени.
Шаг 1: Выбор и открытие веб-источников
Начните с короткого инвентаря, а не с кроллинга целого домена. Для сайта с документацией включите текущие страницы продуктов и API-справочников, затем исключите страницы входа, поиска, архивы историй изменений и нерелевантные маркетинговые пути, если они вне базы знаний. Используйте карту сайта и навигационные ссылки вместе, когда вам нужно сравнить объявленные URL с достижимыми страницами. Карта сайта является подсказкой для открытия, а не доказательством того, что каждая перечисленная страница полезна или актуальна.
Используйте одностраничный скрапинг, когда известный URL является единственным входом. Используйте кроллинг по сайту, когда вам нужно ограниченное открытие с начальной страницы. Текущие запросы Crawl открывают maxDepth, maxPages, includeUrls, excludeUrls, ignoreQuery и onlyMainContent; выберите консервативные границы и проверьте список обнаруженных страниц перед индексацией. Для отдельного обзора секторов векторной базы данных смотрите Crawl to Pinecone.
Шаг 2: Кроллинг страницы в Markdown
Документированный Python SDK предоставляет submit_scrape_task_sync и get_markdown(). Этот запрос подходит для известного URL с предсказуемым временем ответа:
import os
from nstdata_ai_crawl import Format, NstDataClient, ScrapeRequestDto
with NstDataClient(os.environ["NSTDATA_API_TOKEN"])as client: result = client.submit_scrape_task_sync(ScrapeRequestDto( url="https://docs.example.com/api/authentication", formats=[Format.MARKDOWN], timeout=60_000, onlyMainContent=True,))markdown = result.data.get_markdown()ifnot markdown orlen(markdown.strip())<200:raise ValueError("Crawl вернул пустой или неожиданно короткий контент")
Успешный HTTP обмен не равен этому, чтобы страница была пригодной для использования. Проверьте успешность задачи, длину тела, ожидаемые заголовки или известную фразу, а также возвращенные метаданные, прежде чем отметить страницу как принятую. Для медленных страниц используйте асинхронный поток задач и опрашивайте возвращенный ID; официальный справочник также документирует прогресс страницы и ссылки на результаты. Не предполагается, что существует обратный вызов вебхука: текущая документация говорит, что вебхуки не поддерживаются.
Для страниц, рендеримых на JavaScript, сначала проверьте, отсутствует ли необходимый текст в обычном выводе. Включайте рендеринг браузера или задокументированное ожидание/действие только тогда, когда страница действительно требует этого. Дополнительное рендеринг увеличивает задержку и может сделать анализ краулера более сложным.
Шаг 3: Нормализовать и сохранить происхождение
Перед разбивкой преобразуйте полученный результат в стабильную запись. Держите метаданные источника отдельно от текста тела:
from dataclasses import dataclass
from datetime import datetime, timezone
from hashlib import sha256
@dataclassclassPageRecord: url:str title:str markdown:str crawled_at:str content_hash:strdefmake_record(url:str, title:str, markdown:str)-> PageRecord: normalized ="\n".join(line.rstrip()for line in markdown.splitlines()).strip()return PageRecord( url=url, title=title or url, markdown=normalized, crawled_at=datetime.now(timezone.utc).isoformat(), content_hash=sha256(normalized.encode("utf-8")).hexdigest(),)
Хэш контента позволяет пайплайну пропустить неизменные страницы. Нормализуйте только шум, который действительно не имеет значения: сохраните заголовки, контейнеры кода, таблицы параметров, предупреждения и ссылки на источники. Удаление стандартных частей не является разрешением переписывать факты автора.
Шаг 4: Разбить вокруг структуры документа
Для технической документации разбивайте по заголовкам, прежде чем применять предел токенов или символов. Часть должна сохранить свой путь заголовка, чтобы извлеченный абзац все еще имел контекст:
defheading_sections(markdown:str): current =[] body =[] in_fence =Falsefor line in markdown.splitlines():if line.strip().startswith("```"): in_fence =not in_fence
if line.startswith("#")andnot in_fence and body:yield" / ".join(current),"\n".join(body).strip() body =[]if line.startswith("#")andnot in_fence: level =len(line)-len(line.lstrip("#")) current = current[:level -1]+[line[level:].strip()] body.append(line)if body:yield" / ".join(current),"\n".join(body).strip()
Этот небольшой разделитель сохраняет примеры в контейнерах вместе, но не устанавливает потолок токенов. Добавьте второй проход, осведомленный о токенизаторах, для длинных разделов и протестируйте его с вашим самым длинным образцом кода. Пользователи фреймворка могут сравнить эту базу с текущими концепциями текстового разделителя LangChain. Избегайте предположений о универсальном размере блока: сравните извлечение по вопросам, требующим деталей параметров, контекста сечений и кода.
Шаг 5: Встраивание и хранение записей
Создайте встраивание для каждого блока и запишите текст и метаданные вместе с ним. Chroma может сохранить локальную коллекцию; его API upsert и query задокументированы в руководстве по коллекциям Chroma. Модель провайдера и размер встраивания Chroma должны совпадать, если вы передаете предварительно рассчитанные векторы. Текущая руководство по встраиванию OpenAI документирует конечную точку текст-в-вектор, использованную в этом примере.
В производстве отправляйте векторы пакетами, повторяйте попытки только в случае временных ошибок поставщика и ограничивайте размер пакета в соответствии с ограничениями поставщика. Делайте идентификаторы детерминированными, например, sha256(canonical_url + heading_path + chunk_text). Когда страница изменяется, удаляйте старые идентификаторы фрагментов страницы перед вставкой нового набора, или используйте версионированное пространство имен и переключайтесь после проверки.
Шаг 6: Извлечение и ответ с доказательствами
Встраивайте вопрос пользователя в ту же модель, запрашивайте коллекцию и передавайте верхние фрагменты плюс исходные URL в LLM. Требуйте, чтобы ответ ссылался на предоставленные URL и сообщал, когда полученные доказательства недостаточны. Результат извлечения — это доказательство для проверки, а не доказательство того, что ответ правильный.
Полезный набор оценок включает прямые факты, вопросы по параметрам API, вопросы, ответы на которые охватывают два раздела, и вопросы, которые должны возвращать "не найдено". Отслеживайте коэффициент успешных извлечений и правильность цитирования отдельно от текучести ответа.
Шаг 7: Поддерживайте индекс в актуальном состоянии
Запланируйте повторные обходы в соответствии с изменчивостью источника и последствиями устаревших ответов. Храните последний успешный хеш для каждой канонической URL. Если новый успешный обход имеет тот же хеш, пропускайте повторное встраивание. Если он отличается, замените старые фрагменты. Рассматривайте тайм-аут или временные 403 как неизвестные, а не как доказательство удаления источника. Подтвердите удаление с помощью повторных проверок или изменения авторитетной карты сайта перед удалением индексированного контента.
Задание cron может запустить команду Python для загрузки, но задача должна записывать запись выполнения: идентификатор выполнения, время начала/окончания, обнаруженные URL, принятые страницы, измененные хеши, удаленные страницы, неудачные URL и количество встраиваний. Для получения обзора того, что обрабатывает Crawl, в отличие от работы, принадлежащей приложению, см. руководство Nstdata по стеку веб-данных.
Затраты, масштабирование и распространенные режимы отказа
Подсчет страниц не является полным оценочным расчетом. Включите запросы Crawl, отдельно оплачиваемый прокси-трафик при использовании, токены встраивания для измененного контента, записи/хранение векторов и использование модели во время ответа. Ваша собственная формула должна быть:
ежемесячные затраты на загрузку = успешные единицы обхода + прокси-трафик + токены встраивания измененного текста + хранение векторов + планировщик/операции
Измеряйте принятые страницы, а не отправленные URL. Распространенные отказы включают индексацию пустых страниц, несовпадающие размеры встраивания, оставленные устаревшие векторы после обновления, потерю исходных URL во время фрагментирования и измерение только качества ответа, при этом игнорируя пропуски извлечения. Добавьте контроль валидности перед индексацией и тест источника на наличие противодействия перед тем, как сделать результаты обхода доступными для модели.
Полный контрольный список по загрузке
Ведите белый список и инвентаризацию URL с каноническими URL.
Проверяйте статус, полноту тела, заголовок и метаданные источника после каждого обхода.
Сохраняйте заголовки, код, таблицы и хеши контента через нормализацию.
Используйте детерминированные идентификаторы фрагментов и храните отображение страницы на фрагмент.
Пере-встраивайте только измененный контент; отличайте удаленные страницы от неудачных запросов.
Оценивайте извлечение, цитаты, поведение устаревших ответов и затраты по фиксированному набору вопросов.
Свежие веб-данные достигают ответа RAG только после того, как ваш конвейер обнаружит, извлечет, проверит, нормализует, разобьет, встроит и индексирует их. Nstdata Crawl может предоставить слой извлечения страниц и конверсии Markdown; приложение должно по-прежнему обладать происхождением, политикой обновления, жизненным циклом векторов и проверками ответов. Начните с небольшого набора репрезентативных URL, подтвердите поведение охвата и удаления, а затем масштабируйте расписание.
Загрузка данных RAG преобразует исходные документы в валидированные, разбитые, встроенные записи, которые может искать система извлечения.
В: Как мне поддерживать веб-данные в RAG свежими?
Отслеживайте канонические URL и хеши контента, проводите повторный обход по расписанию, соответствующему изменчивости источника, и заменяйте или удаляйте старые фрагменты только после проверки нового состояния источника.
В: Может ли RAG напрямую использовать живые веб-сайты?
Индекс RAG не обновляется автоматически с живого веб-сайта; сборщик и задание загрузки должны извлекать и индексировать новый контент, прежде чем извлечение сможет его использовать.
В: Как часто мне следует обновлять базу знаний RAG?
Выберите интервал обновления исходя из того, как часто изменяется источник и какой эффект старого ответа, затем измеряйте фактические темпы изменений и задержки обновления.
В: Заменяет ли Crawl фрагментацию и встраивание?
Нет. Crawl извлекает и преобразует страницы; ваше приложение по-прежнему выбирает фрагменты, модели встраивания, хранение векторов, правила обновления и оценку.
Понимание семи измерений качества данных RAG и того, как проверять проиндексированные страницы, сравнивать чистые и сырые данные, сохранять происхождение и диагностировать ошибки извлечения. Это разделяет ошибки извлечения, получения и генерации, чтобы команды могли отлаживать правильный этап.
Lena Zhou
Oct. 20th 2026
Сканируйте целые сайты одним API-запросом
Успешность 99,8% с рендерингом JavaScript
Получайте чистые данные для LLM в разных форматах
Преобразуйте любой сайт в Markdown, HTML, JSON, ссылки, PDF и другие форматы без управления инфраструктурой сканирования.
