Веб-скрапинг в формате Markdown для LLMчистые данные для ИИ

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

Это руководство показывает более чистый путь. Crawling API может возвращать страницу в виде аккуратного Markdown вместо сырого HTML, поэтому вы передаёте модели читаемый текст, а не суп из тегов. Мы рассмотрим, как запросить вывод в Markdown, почему Markdown лучше HTML для бюджетов токенов LLM и RAG, а также небольшой сквозной конвейер: получить Markdown, разбить на чанки, а затем создать векторные представления или составить промпт. Ключевая фраза для понимания всего сказанного ниже: llm ready markdown web scraping, потому что именно формат вывода упрощает работу всего вашего стека.

Почему Markdown лучше сырого HTML для LLM

HTML создан для рендеринга страниц в браузере. Он несёт всё, что нужно движку макета: вложенные div, имена классов, встроенные стили, скрипты и ARIA-атрибуты. Модели почти ничего из этого не нужно. Когда сырой HTML попадает в рабочий процесс LLM, модели приходится продираться сквозь разметку и шаблонные блоки, прежде чем она доберётся до реального содержимого, а это имеет вполне реальные издержки.

Markdown сохраняет нужную структуру и отбрасывает остальное. Заголовки остаются заголовками, списки остаются списками, таблицы остаются читаемыми, а ссылки остаются полезными, не погружаясь в атрибуты. Практические преимущества выстраиваются чётко:

• Бюджет токенов. Типичная страница со статьёй может быть в несколько раз крупнее в сыром HTML, чем в эквиваленте на Markdown, после удаления меню, скриптов и обёрток. Меньше токенов означает меньшую стоимость каждого вызова и больше места для реального контекста в окне контекста модели.
• Точность. Модель, читающая чистую прозу, с меньшей вероятностью зацепится за случайный ярлык навигации или строку о согласии на cookies, чем та, что разбирает стену из div. Меньше шума на входе, меньше неверных выводов на выходе.
• Разбивка на чанки. Заголовки Markdown дают естественные точки разделения. Вы можете разбивать по границам ## и сохранять семантически связанный текст вместе, а не нарезать посередине предложения при произвольном числе символов.
• Инспектируемость. Когда что-то идёт не так ниже по стеку, вы можете открыть Markdown-файл и прочитать его. Отладка 200 КБ HTML-кода, это совсем другое дело.

Для команд, занимающихся парсингом данных для ИИ, формат вывода, не мелкая деталь. Именно он задаёт потолок качества для всего, что происходит после получения данных. Более широкое представление о том, как очистка данных влияет на результаты модели, см. в статье как структурировать и очищать данные веб-парсинга для ИИ и машинного обучения.

Как запросить Markdown из Crawling API

Crawlbase возвращает Markdown нативно. Вам не нужно подключать отдельный конвертер HTML в Markdown: вы просите Crawling API вернуть Markdown, и он выполняет конвертацию на стороне сервера в рамках обхода.

Управление осуществляется одним параметром. Добавьте format=md к запросу, и API вернёт Markdown вместо HTML.

curl "https://api.crawlbase.com/?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com&format=md"

Если вы хотите получить только основной читаемый контент, добавьте md_readability=true. Это запускает извлечение читаемости перед конвертацией, удаляя меню, боковые панели и подвальный мусор, чтобы Markdown содержал тело статьи и практически ничего лишнего.

curl "https://api.crawlbase.com/?token=YOUR_TOKEN&url=https%3A%2F%2Fexample.com&format=md&md_readability=true"

Оба режима имеют своё место. Простой format=md сохраняет более широкий контекст страницы, включая навигацию и связанные ссылки, что удобно при картировании структуры сайта. Добавление md_readability=true обеспечивает извлечение основного контента, что нужно для векторных представлений, резюмирования и RAG. Если ваша цель, передавать данные модели, начните с включённой читаемостью.

Используйте вывод Markdown в небольшом RAG-конвейере

Retrieval-augmented generation (RAG) даёт модели доступ к внешним знаниям перед ответом. Вместо того чтобы опираться только на обучающие данные, система сначала извлекает релевантный текст, а затем передаёт этот контекст модели. Обычная схема такова: получить контент, разбить на чанки, создать векторные представления этих чанков в векторном хранилище, извлечь релевантные при запросе, а затем составить промпт для модели с ними.

Качество этого конвейера определяется задолго до вызова модели. Если загруженная страница полна повторяющихся меню, баннеров cookie и нерабочих ссылок, этот шум будет разбит на чанки и проиндексирован вместе с полезным текстом, и качество извлечения снизится. Чистый Markdown даёт каждому чанку больше шансов содержать значимый контент. Вот шаг получения данных с включённой читаемостью, чтобы каждый документ состоял преимущественно из основного текста.

import requests

API = "https://api.crawlbase.com/"
TOKEN = "YOUR_TOKEN"

def fetch_markdown(url):
    params = {
        "token": TOKEN,
        "url": url,
        "format": "md",
        "md_readability": "true",
    }
    resp = requests.get(API, params=params, timeout=60)
    resp.raise_for_status()
    return resp.text

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

import re

def chunk_by_heading(markdown, max_chars=1200):
    sections = re.split(r"(?=^#{1,3} )", markdown, flags=re.MULTILINE)
    chunks = []
    for section in sections:
        text = section.strip()
        if not text:
            continue
        if len(text) <= max_chars:
            chunks.append(text)
        else:
            for i in range(0, len(text), max_chars):
                chunks.append(text[i : i + max_chars])
    return chunks

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

url = "https://example.com/some-article"
markdown = fetch_markdown(url)
chunks = chunk_by_heading(markdown)

# Send the most relevant chunks as context to your model
context = "\n\n".join(chunks[:3])
prompt = f"Answer using only this context:\n\n{context}\n\nQ: ..."
print(len(chunks), "chunks ready for embedding or prompting")

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

Во что раньше обходился шаг очистки

Без нативного вывода в Markdown типичный паттерн представлял собой хрупкую цепочку предобработки: получить HTML, разобрать DOM, удалить скрипты и стили, убрать навигацию, найти тело статьи, нормализовать пробелы, а затем конвертировать в Markdown и только после этого разбивать на чанки и создавать векторные представления. Каждое звено этой цепочки может сломаться.

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

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

Проверяйте ответ перед индексацией

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

def is_usable(markdown, min_chars=200):
    if markdown is None:
        return False
    stripped = markdown.strip()
    # Reject empty shells and near-empty error pages
    return len(stripped) >= min_chars

md = fetch_markdown(url)
if not is_usable(md):
    print("Skipping: thin or empty response")
else:
    chunks = chunk_by_heading(md)
    # proceed to embed / index

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

Где LLM-ready Markdown наиболее эффективен

Вывод в Markdown окупается везде, где веб-контент должен стать контекстом, готовым для модели:

• Чат-боты для документации. Превратите страницы центра помощи и страницы документации продукта в чистые чанки Markdown для поиска и извлечения, обновляя их с помощью периодического повторного обхода.
• Агенты ИИ-исследований. Получайте статьи, отчёты и публичные документы в формате, который модель может быстро прочитать, не тратя бюджет на разметку.
• Мониторинг конкурентов и рынка. Отслеживайте страницы цен, функций и журналы изменений в виде читаемого текста, а не разбирая сырой HTML при каждом запуске.
• Внутренний поиск. Создавайте индекс знаний с более чистым исходным материалом, собранным со всего интернета.
• Конвейеры резюмирования. Сворачивайте длинные страницы в краткие резюме с гораздо меньшей предобработкой.

Агенты особенно выигрывают. Когда инструмент возвращает Markdown, отфильтрованный по читаемости, вместо сырого HTML, модель сразу получает нечто близкое к готовому документу. Это облегчает резюмирование, извлечение полей, сравнение источников и принятие следующего действия, что, как правило, создаёт более чистый цикл агента. Если вы направляете трафик агентов через ротирующие IP, статья что такое AI-прокси объясняет, как этот уровень соотносится с такими инструментами, как Smart AI Proxy и сервер Web MCP. А когда цель, структурированные поля, а не проза, Crawling API возвращает разобранный JSON.

Сохраняйте обход незаблокированным

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

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

Что такое LLM-ready Markdown web scraping?

Это означает сбор веб-контента в формате, который языковая модель может использовать немедленно, практически без очистки. Вместо сырого HTML, полного скриптов, стилей и навигации, вывод представляет собой чистый структурированный Markdown, который легко разбить на чанки, создать векторные представления, резюмировать и вставить в промпты. В Crawlbase это достигается добавлением format=md к запросу Crawling API.

Как получить вывод в Markdown из Crawlbase Crawling API?

Добавьте format=md к запросу, и API вернёт Markdown вместо HTML. Если вы также хотите извлечь основной контент перед конвертацией, добавьте md_readability=true, что удаляет меню, боковые панели и подвальный мусор, оставляя в Markdown преимущественно тело статьи. Оба параметра являются частью стандартного запроса, поэтому дополнительная настройка не требуется.

Почему Markdown лучше HTML для RAG-конвейеров?

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

Снижает ли вывод в Markdown использование токенов в LLM?

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

Можно ли получить полный контекст страницы, а не только основную статью?

Да. Используйте format=md без md_readability=true. Простой Markdown сохраняет более широкий контекст страницы, например навигацию и связанные ссылки, что полезно для анализа структуры сайта. Включайте читаемость только тогда, когда вам нужен изолированный основной контент для векторных представлений, резюмирования или промптов.

Нужен ли JavaScript-токен для получения Markdown с динамических страниц?

Если целевая страница рендерит контент на стороне клиента, то да. Форматирование Markdown применяется к тому, что API успевает загрузить, поэтому для страницы с JavaScript-рендерингом передайте JS-токен, чтобы страница сначала отрендерилась в настоящем браузере, а затем запросите format=md. Для статических страниц достаточно обычного токена.

IK

Ian Kalvin

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

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

NZ

Neil Zamora

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

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