Создание исследовательского набора данных AI с Web MCPОбойдите один раз, переиспользуйте всегда

Большинство рабочих процессов на основе AI создаются для извлечения данных, а не для исследований. Агент получает страницу, вытягивает то, что ему нужно, отвечает на вопрос и идёт дальше. Задайте связанный вопрос завтра, и он снова получит ту же самую страницу. Для разовых поисков это нормально. Всё разваливается в тот момент, когда вы ведёте постоянное исследование по одному и тому же набору источников.

Исследование накапливается. Вы возвращаетесь к источникам, сравниваете их во времени и задаёте новые вопросы к старым данным. Если каждый вопрос запускает новый обход, ваш ассистент ведёт себя как поисковая система, а не как исследовательская система. Узкое место не в обходе. Оно в отсутствии памяти.

Это руководство создаёт недостающую память: постоянный исследовательский набор данных с Crawlbase Web MCP Server. Вы обходите каждую страницу один раз, сохраняете её в Crawlbase Cloud Storage как переиспользуемый Markdown-снимок и запускаете весь последующий анализ по сохранённому набору данных, а не по живому вебу. Сопутствующий репозиторий поставляет промпты, конфигурацию MCP, примеры URL и скрипт загрузки, используемые повсюду в этом руководстве.

Почему AI-исследования постоянно начинаются заново

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

Технически ничего не сломано. Именно так сегодня работает большинство AI-систем скрейпинга. Проблема в том, что каждый вопрос начинается с нуля, потому что система была спроектирована вокруг извлечения: получить, ответить, отбросить.

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

Архитектура: от веб-страниц к исследовательским активам

Как только вы начинаете относиться к веб-контенту как к набору данных, а не как к результату поиска, сбор и анализ становятся двумя отдельными задачами. Web MCP Server обрабатывает обе; Cloud Storage сохраняет снимки после завершения диалога; небольшой манифест выступает каталогом, который их связывает.

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

Подключите Web MCP Server

Прежде чем что-либо создавать, направьте свой MCP-клиент на Crawlbase Web MCP Server. Если сначала хотите более полный обзор того, что предоставляет сервер, посмотрите наше введение в Crawlbase Web MCP Server.

{
  "mcpServers": {
    "crawlbase": {
      "type": "stdio",
      "command": "npx",
      "args": ["@crawlbase/mcp@latest"],
      "env": {
        "CRAWLBASE_TOKEN": "YOUR_TOKEN",
        "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN"
      }
    }
  }
}

Сопутствующий репозиторий включает готовый mcp-config.sample.json. Поместите его в Cursor, Codex или любой MCP-совместимый клиент, замените заполнители токенов своими учётными данными Crawlbase и перезапустите. После этого вы должны увидеть такие инструменты, как crawl_markdown, storage_count, storage_list, storage_get и storage_bulk_get. Отсюда ассистент может обходить, сохранять, извлекать и управлять набором данных без всякого пользовательского кода.

Соберите набор данных один раз

Пример списка URL содержит двадцать публичных страниц с ценами SaaS. Промпт сборки обходит каждую из них, сохраняет Markdown-снимок и записывает метаданные в output/dataset-manifest.json.

Единственная важная настройка это store=true. Без неё страница существует только внутри текущего диалога; когда сессия заканчивается, контент пропадает, и следующий вопрос требует нового обхода. С ней Crawlbase хранит снимок в Cloud Storage и возвращает RID, по которому можно позже вытянуть документ обратно. Именно этот флаг превращает поток временных ответов в переиспользуемый набор данных.

Работайте по набору данных, а не по вебу

Как только страницы сохранены, рабочий процесс меняется: вы делаете запросы к набору данных, а не просматриваете сайты. Промпт анализа начинает с метаданных, а не с документов.

storage_count
storage_list
storage_bulk_get(as=metadata_only)

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

Отслеживайте изменения во времени

«Кто из конкурентов изменил свою модель ценообразования за последние три месяца?» это распространённый вопрос конкурентной разведки, и он работает только в том случае, если вы сохранили историю. Промпт обнаружения изменений сравнивает снимки во времени.

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

Со временем набор данных перестаёт быть грудой страниц и становится записью того, как эти страницы меняются.

Переиспользование и очистка

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

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

Автоматизируйте сбор

Запускать промпты вручную идеально, пока вы исследуете. Как только рабочий процесс становится рутинным (те же источники, по расписанию, растущие наборы данных), автоматизируйте этап сбора. ingest_dataset.py из репозитория делает именно это через Crawling API.

pip install -r requirements.txt
export CRAWLBASE_TOKEN="YOUR_CRAWLBASE_TOKEN"
python ingest_dataset.py --urls urls.saas-pricing.txt

Скрипт читает список URL, запрашивает каждую страницу как Markdown, сохраняет снимок и записывает манифест. Сам запрос намеренно прост:

response = requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": token,
        "url": url,
        "format": "md",
        "md_readability": "true",
        "store": "true",
    },
)

Он запрашивает вывод в Markdown с format=md, включает читаемость с md_readability=true и сохраняет результат с store=true. Вместо того чтобы сохранять тела документов локально, он фиксирует то, что нужно для их последующего извлечения, самое важное это RID, который Cloud Storage возвращает для каждой страницы. Эти записи попадают в output/dataset-manifest.json:

{
  "generated_at": "...",
  "entry_count": 20,
  "stored_count": 20,
  "entries": [...]
}

Считайте манифест каталогом: документы живут в Cloud Storage, а манифест фиксирует, как их найти. Он выполняет ту же работу, что и MCP-процесс, только повторяемо.

Инфраструктура вместо повторного обхода

Создание исследовательского набора данных обычно означает сшивание вместе краулера, слоя хранения, механизма извлечения и рабочего процесса анализа. Crawlbase Web MCP Server сворачивает большую часть этого в инструменты, которые живут внутри Cursor, Codex и других MCP-клиентов, а Cloud Storage сохраняет снимки доступными ещё долго после обхода.

Это меняет экономику. Соберите контент один раз и переиспользуйте его во множестве видов анализа, и каждая страница становится исследовательским активом, а не одноразовым ответом. Ценность набора данных растёт, тогда как стоимость сбора остаётся примерно неизменной. Та же идея лежит в основе конвейеров машинного обучения, где собранные данные переиспользуются в обучении и оценке; посмотрите Веб-скрейпинг для машинного обучения под этим углом. Для постоянного анализа рынка и конкурентной разведки этот сдвиг часто стоит больше, чем сам обход.

Ключевые выводы

• Исследовательские системы и системы извлечения решают разные задачи; большинство AI-процессов создаются для извлечения.
• Повторный обход одних и тех же страниц для каждого вопроса раз за разом оплачивает стоимость сбора.
• Постоянное хранилище отделяет получение от анализа, так что один обход обслуживает множество будущих вопросов.
• Исследование, начинающееся с метаданных, масштабируется лучше, чем загрузка каждого документа.
• Именно исторические снимки делают возможными анализ тенденций и обнаружение изменений.
• Исследовательский набор данных со временем становится ценнее, потому что стоимость сбора распределяется по всем последующим вопросам.
• Crawlbase Web MCP Server объединяет обход, хранение, извлечение и анализ в единый рабочий процесс, а сопутствующий репозиторий это его рабочая реализация.

Часто задаваемые вопросы

В чём разница между исследовательским набором данных AI и базой знаний RAG?

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

Зачем сохранять веб-страницы, а не обходить их каждый раз?

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

Зачем использовать Markdown вместо сырого HTML?

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

Можно ли применить этот подход к данным, отличным от страниц с ценами SaaS?

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

Заменяет ли Crawlbase Web MCP Server векторные базы данных и векторные представления?

Нет. Web MCP Server обрабатывает получение, хранение и извлечение исходных документов. Векторные базы данных и модели векторных представлений вступают в дело, когда вам нужен семантический поиск, конвейеры RAG или извлечение на основе сходства. Многие команды используют Web MCP Server как слой получения, а позже подают сохранённые документы в конвейеры векторизации, векторные хранилища или агентов, так что набор данных становится фундаментом, на котором строятся другие AI-системы.

IK

Ian Kalvin

Инженер технической поддержки · Crawlbase

Инженер технической поддержки в Crawlbase, пишет с переднего края того, что на самом деле ломается в продакшене при скрейпинге и в прокси-конфигурациях.

NZ

Neil Zamora

Старший архитектор · Crawlbase

Старший архитектор в Crawlbase, сосредоточен на системах, стоящих за краулингом в больших масштабах: ротация прокси, устойчивость к anti-bot и API, скрывающие эту сложность.