Когда извлечение данных с помощью LLM перестает окупаться

Firecrawl берет 1 кредит за скрапинг страницы и 5 кредитов за извлечение структурированных полей из той же страницы (Firecrawl pricing, 2026). Это пятикратная наценка за тот же HTML, пропущенный через модель.

Обещание заманчивое: опишите, что вам нужно, получите JSON в ответ, и никаких селекторов для поддержки. Для нестабильной верстки и разовых задач это оправдывает наценку. Но для production-пайплайна, который собирает 500 тысяч страниц товаров в день с одних и тех же пяти ритейлеров, это не так.

Мы видели, как команды внедряли извлечение через LLM по умолчанию, получали счет в конце месяца и начинали искать альтернативы. Решение обычно заключается не в отказе от LLM. Оно в том, чтобы использовать их на правильном этапе пайплайна.

Цифры быстро перестают радовать

Возьмем Firecrawl как относительно дешевый вариант. Скрапинг плюс извлечение с помощью ИИ стоит 6 кредитов за страницу без crawl, 7 кредитов с crawl (ScrapeGraphAI breakdown, 2026). 100 тысяч страниц в день на их тарифе Growth обойдутся примерно в 21 тысячу долларов в месяц до учета повторных попыток (retries) и до оплаты хотя бы одного proxy.

Если запустить собственный пайплайн на базе LLM, цифры изменятся, но не станут незначительными. GPT-4o стоит 2,50 доллара за миллион входящих токенов (input tokens) и 10 долларов за миллион исходящих (output tokens) (PricePerToken, 2026). Страница товара после конвертации в markdown занимает от 4 до 8 тысяч входящих токенов. Допустим, это 6 тысяч входящих и 200 исходящих токенов для JSON. При 100 тысячах страниц в день это 360 долларов ежедневно или 11 тысяч долларов в месяц за работу, которую CSS-селекторы делают бесплатно после однократной настройки.

И это дешевая модель. Переход на Claude Sonnet 4.6 (3 доллара за входящие, 15 долларов за исходящие) удваивает счет (PE Collective, 2026). Перейдите на reasoning-модель и добавьте наценку от 3 до 10 раз в зависимости от того, сколько она думает перед ответом.

И это без учета ошибок. Уровень галлюцинаций от 3% до 5% кажется безобидным, пока вы не посчитаете общую сумму. При 100 тысячах страниц в день это от 3000 до 5000 неверных записей, попадающих в ваше хранилище данных (warehouse). Они выглядят точно так же, как правильные, потому что модель выдала их с высокой уверенностью. Как отметили в DataHen: "Проблема не в том, что ИИ иногда ошибается. Проблема в том, что он ошибается уверенно." (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 или проверка на наличие элемента) фиксирует изменения верстки (drift)
Изменение верстки запускает повторную инициализацию спустя недели или месяцы

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

Где LLM все же оправдывают свои затраты

Эта статья написана не против LLM. Есть множество задач по извлечению данных, где модель является оптимальным инструментом и экономика кредитов сходится:

Нестабильная верстка, которая меняется каждую неделю. Селекторы, которые ломаются каждый вторник, обходятся дороже в плане рабочего времени инженеров, чем извлечение через LLM в токенах. Используйте модель.
Редкие целевые ресурсы (long-tail), к которым вы больше не вернетесь. Писать селектор нет смысла. Используйте модель.
Неструктурированный контент, где результатом является сводка. Преобразование описаний вакансий в навыки, статей в тезисы, отзывов в тональность. Селекторы здесь бесполезны. Используйте модель.
Страницы с необязательными полями, разбросанными по разным вариантам верстки. Один шаблон с двадцатью условными рендерами, это как раз тот случай, когда LLM превосходят цепочки regex.

Посмотрите на свой пайплайн. Отсортируйте целевые ресурсы по объему. Верхние 20% по количеству запросов почти всегда имеют стабильную структуру (именно поэтому они в топе, вы интегрировали их осознанно). Они подходят для использования селекторов. А для длинного хвоста (long tail) как раз нужна модель.

Что это значит для вашего стека

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

Три вывода для команд, создающих реальные пайплайны:

Разделяйте получение данных (fetch) и их парсинг. Если ваш вендор скрапинга возвращает только извлеченный с помощью LLM JSON, вы не сможете вернуться к селекторам, когда придет огромный счет. Выбирайте инфраструктуру, которая отдает вам HTML и позволяет самостоятельно определять путь извлечения.
Активно кэшируйте на уровне селекторов. Сгенерированные селекторы можно использовать повторно на тысячах страниц. Дорогостоящим является именно процесс генерации, а не использование.
Оценивайте стоимость одной записи, а не одной страницы. Пайплайн, который стоит 0,001 доллара за страницу, но выдает 5% некорректных записей, обходится дороже, чем пайплайн за 0,005 доллара за страницу, но с чистыми данными. Хранение, последующие запросы и итоговая очистка данных, все это требует затрат.

Выбирайте скучную часть

Использование извлечения через LLM по умолчанию отлично подходит для демо-версий, но не годится для production. Команды, которые делают все правильно, относятся к LLM как к инструменту для понимания страницы, а не для ее чтения.

Скучный детерминированный код по-прежнему выигрывает по объемам в 2026 году, в то время как модель побеждает в работе с новыми форматами. В стеке есть место для обоих решений.

В FourA продукты Single и Browser возвращают необработанный response (HTML, отрендеренный DOM, headers, body) и на этом останавливаются. Будете ли вы парсить данные с помощью селекторов, отправлять их в модель или делать и то, и другое, решать вам. Мы не начисляем повышающие коэффициенты за извлечение данных, которое мы не выполняли.