Когда извлечение с помощью LLM перестает окупаться
Firecrawl берет 1 кредит за скрапинг страницы и 5 кредитов за извлечение структурированных полей из нее же (Firecrawl pricing, 2026). Это наценка в 5 раз за тот же HTML, пропущенный через модель.
Идея понятна: описываете желаемое, получаете JSON, не нужно поддерживать селекторы. Для нестабильной верстки и разовых задач это оправдывает наценку. Но для production пайплайна, который тянет 500 тысяч страниц товаров в день с одних и тех же пяти магазинов, это не работает.
Мы видели, как команды внедряют извлечение через LLM по умолчанию, получают счет за месяц и начинают искать выход. Решение обычно не в отказе от LLM. Нужно просто поставить их в правильное место в пайплайне.
Математика быстро портится
Возьмем Firecrawl по минимальной цене. Скрапинг плюс AI извлечение стоит 6 кредитов за страницу без кроулинга, 7 кредитов с кроулингом (ScrapeGraphAI breakdown, 2026). 100 тысяч страниц в день на тарифе growth обойдутся примерно в $21K в месяц без учета ретраев, и это до оплаты хотя бы одного proxy.
Запустите свой LLM пайплайн, и математика изменится, но не станет меньше. GPT-4o стоит $2.50 за миллион входящих токенов и $10 за миллион исходящих (PricePerToken, 2026). Страница товара после конвертации в markdown занимает 4K-8K входящих токенов. Допустим, 6K на вход и 200 на выход для JSON объекта. При 100 тысячах страниц в день это $360 ежедневно, $11K ежемесячно за работу, которую CSS селекторы делают бесплатно после однократной настройки.
И это дешевая модель. Перейдите на Claude Sonnet 4.6 ($3 на вход, $15 на выход), и счет удвоится (PE Collective, 2026). Перейдите на reasoning модель и добавьте наценку в 3-10 раз в зависимости от времени обдумывания перед ответом.
И это без учета ошибок. Уровень галлюцинаций в 3-5% звучит безобидно, пока вы не посчитаете. На 100 тысячах страниц в день это 3,000-5,000 неверных записей, поступающих в ваше хранилище, и они выглядят в точности как правильные, потому что модель вернула их уверенно. Как отметили в DataHen: "Проблема не в том, что AI иногда ошибается. Проблема в том, что он делает это уверенно." (DataHen, 2026).
Что на самом деле делают опытные команды
Почитайте документацию вендоров, которые реально запускают скраперы в production, и вы увидите единый паттерн: гибрид. Используйте LLM, чтобы один раз разобрать страницу, а затем запускайте дешевый детерминированный код для всего остального.
Zyte прямо пишет в своей документации: "Вместо использования LLM для каждой страницы, используйте LLM для генерации CSS селекторов нужных полей на основе сырого HTML первой страницы, и используйте эти селекторы для парсинга всех остальных страниц." (Zyte LLM guide, 2026). Apify рекомендует тот же флоу в своем руководстве 2026 года: сначала пробуйте CSS селекторы, переходите на LLM при их ошибке (Apify 2026 guide). Статья в DEV Community о внедрении в production в точности описала эту архитектуру: закешированный путь через селекторы ничего не стоит, LLM запускается только при ошибке валидации (DEV.to, 2026).
Поэтому разделение в production выглядит так:
- LLM создает селектор (один вызов на цель, доли цента)
- Селектор запускается для каждой страницы (бесплатно)
- Валидатор (обычно regex или проверка наличия) ловит изменения верстки
- Изменения запускают повторное создание селектора спустя недели или месяцы
Стоимость за страницу падает с ~$0.005 до уровня значительно ниже $0.0001. Качество растет, потому что детерминированный парсинг не галлюцинирует. И вы тратите токены на ту работу, в которой LLM действительно хороши: чтение новой структуры, а не повторение уже размеченной.
Где LLM все-таки окупают свои счета
Это не статья против LLM. Существует множество задач по извлечению, где модель является правильным инструментом и математика кредитов сходится:
- Нестабильная верстка, которая меняется еженедельно. Селекторы, ломающиеся каждый вторник, стоят больше инженерного времени, чем LLM-извлечение стоит в токенах. Запускайте модель.
- Цели из длинного хвоста, к которым вы больше не вернетесь. Написание селектора не окупится. Запускайте модель.
- Неструктурированный контент, где результат сам по себе является выжимкой. Описания вакансий в навыки, статьи в тезисы, отзывы в тональность. Селекторы здесь не помогут. Запускайте модель.
- Страницы с опциональными полями, разбросанными по вариантам верстки. Один шаблон с двадцатью условными рендерами, это именно то место, где LLM превосходят цепочки regex.
Посмотрите на свой пайплайн. Отсортируйте цели по объему. Топ 20% по числу запросов почти всегда имеют стабильную структуру (поэтому они в топе 20%, вы интегрировали их осознанно). Это кандидаты для селекторов. Длинный хвост, вот где место модели.
Что это значит для вашего стека
Вендоры в 2026 году хотят, чтобы вы использовали LLM-извлечение по умолчанию. Цены в кредитах делают это разумным на небольших проектах. Это перестает быть разумным при масштабировании, так же, как размер пула proxy перестал гарантировать реальный успех, когда сломался базовый сигнал.
Три вывода для команд, строящих реальные пайплайны:
- Разделяйте получение данных и парсинг. Если ваш вендор для скрапинга возвращает только JSON извлеченный через LLM, вы не сможете откатиться на селекторы, когда придет счет. Выбирайте инфраструктуру, которая выдает HTML и позволяет выбирать путь извлечения.
- Агрессивно кешируйте на уровне селекторов. Сгенерированные селекторы можно переиспользовать на тысячах страниц. Дорогим вызовом является генерация, а не использование.
- Считайте стоимость записи, а не страницы. Пайплайн, который стоит $0.001 за страницу, но выдает 5% плохих записей, обходится дороже того, что стоит $0.005 за страницу и выдает чистые данные. Хранение, последующие запросы и итоговая очистка имеют свой вес.
Выбирайте скучную половину
LLM-извлечение по умолчанию, это правильный формат для демо и неправильный для production. Команды, которые все делают верно, относятся к LLM как к инструменту для понимания страницы, а не для ее чтения. Скучный детерминированный код все еще выигрывает в объемах в 2026 году, модель выигрывает в новизне. Обоим есть место в стеке.
В FourA инструменты Single и Browser возвращают сырой ответ (HTML, отрендеренный DOM, заголовки, тело) и на этом останавливаются. Будете ли вы парсить через селекторы, отправите в модель или сделаете и то, и другое, решать вам. Мы не добавляем множитель кредитов за извлечение, которое мы не делали.