# Структурированный веб-анализ в JSON по схеме

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

Канонический URL: https://llmtokenapi.ru/blog/strukturirovannyy-web-analiz-v-json
Опубликовано: 2026-09-05T15:12:48.348Z
Автор: Команда LLMTOKENAPI

Структурированный веб-анализ в JSON превращает вопрос, веб-источники и заранее заданную схему в машиночитаемый результат. Вместо ручной цепочки «поиск — чтение страниц — промпт — разбор ответа» приложение создаёт одно асинхронное задание и получает данные, которые можно проверить до записи в CRM, таблицу или базу.

## Когда обычного поиска недостаточно

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

Structured Web Intelligence нужен там, где заранее известно, какой результат должно принять приложение: карточка компании, список тарифов, таблица характеристик, перечень документов или сводка изменений. Сервис собирает источники, извлекает данные, выполняет смысловой отбор и проверяет итог по заданной схеме. Обзор продукта доступен на странице [Web Intelligence](/web-intelligence).

## Начните со схемы результата

Опишите только те поля, которые действительно использует следующий шаг. Чем меньше неоднозначности в JSON Schema, тем проще валидировать результат и разбирать отсутствие данных. Не заставляйте модель угадывать обязательное значение: если источник может его не содержать, сделайте поле необязательным или разрешите `null`.

JSON Schema — отдельный стандарт описания и проверки JSON-документов; актуальные версии и словари перечислены на [официальной странице спецификации](https://json-schema.org/specification). В запросе LLMTOKENAPI используйте безопасную локальную схему без удалённых ссылок. Это делает контракт самодостаточным и не позволяет его смыслу измениться из-за внешнего файла.

## Создайте разовое задание

Для запуска нужен вопрос, набор конкретных URL либо один домен, `outputSchema`, верхняя граница расходов и уникальный `Idempotency-Key`. Одновременно передавать URL и домен не следует: это разные стратегии выбора источников.

```bash
curl https://api.llmtokenapi.ru/v1/web-intelligence/jobs \
  -H "Authorization: Bearer $LLMTOKENAPI_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: catalog-check-2026-09-05" \
  -d '{
    "question": "Собери названия тарифов и публичные условия",
    "domain": "https://example.com",
    "outputFormat": "json",
    "outputSchema": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "conditions": { "type": "string" },
          "sourceUrl": { "type": "string" }
        },
        "required": ["name", "sourceUrl"]
      }
    },
    "maxSources": 10,
    "maxSpendKopecks": 1500
  }'
```

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

## Сделайте повтор безопасным

Асинхронный запуск может завершиться на сервере, даже если клиент потерял ответ из-за сетевого тайм-аута. Поэтому повторяйте запрос с тем же `Idempotency-Key`, а не создавайте новый ключ при каждой попытке. Так повторная доставка не порождает второе одинаковое задание.

Ключ удобно строить из типа операции, идентификатора бизнес-объекта и временного интервала. Не включайте в него API-ключ, персональные данные или полный текст вопроса. Храните связь между ключом идемпотентности и созданным job рядом с состоянием своей автоматизации.

## Проверяйте не только валидность JSON

Соответствие схеме означает, что типы и обязательные поля корректны. Оно не доказывает истинность каждого значения. Для важных данных проверяйте источники из grounding, дату страницы и соответствие утверждения найденному фрагменту. Если подтверждения нет, безопаснее оставить поле пустым, чем превращать предположение в факт.

Добавьте прикладные проверки после schema validation. Цена не должна быть отрицательной, дата окончания не может предшествовать дате начала, URL должен вести на разрешённый домен, а код валюты — входить в ожидаемый список. Такие правила принадлежат приложению, потому что JSON Schema описывает форму результата, но не всю бизнес-семантику.

## Выберите JSON или таблицу

`outputFormat: "json"` подходит для API, очереди и базы данных. Формат `table` удобен для просмотра человеком или выгрузки, когда каждая запись имеет одинаковый набор столбцов. Выбор формата не отменяет схему: сначала определите контракт, затем решите, как потребитель будет читать результат.

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

## Переведите проверенный запуск в шаблон

Если вопрос и схема стабилизировались, сохраните конфигурацию как template. Шаблон можно запускать вручную или по интервалу, ставить на паузу и связывать с webhook. Сначала добейтесь качественного результата на нескольких разовых запусках, и только потом включайте расписание: автоматизация масштабирует не только пользу, но и ошибочную схему.

При изменении обязательных полей создайте версию контракта на своей стороне. Потребитель должен понимать, какую версию JSON он получил, особенно если результаты попадают в долговременное хранилище. Актуальные endpoints, scopes и параметры шаблонов сверяйте в [документации LLMTOKENAPI](/docs).

Надёжный структурированный веб-анализ разделяет ответственность: Web Intelligence находит и связывает данные с источниками, JSON Schema проверяет форму, а приложение применяет бизнес-правила. Такая граница заметно безопаснее, чем разбирать произвольный текст модели регулярными выражениями.