Структурированный веб-анализ в JSON превращает вопрос, веб-источники и заранее заданную схему в машиночитаемый результат. Вместо ручной цепочки «поиск — чтение страниц — промпт — разбор ответа» приложение создаёт одно асинхронное задание и получает данные, которые можно проверить до записи в CRM, таблицу или базу.
Когда обычного поиска недостаточно
Поисковая выдача хорошо находит страницы, но не гарантирует одинаковую структуру данных. В одном сниппете цена указана рядом с названием, в другом спрятана в таблице, а третий источник описывает только условия. Если передать эти фрагменты модели без контракта, поля и форматы будут меняться от запуска к запуску.
Structured Web Intelligence нужен там, где заранее известно, какой результат должно принять приложение: карточка компании, список тарифов, таблица характеристик, перечень документов или сводка изменений. Сервис собирает источники, извлекает данные, выполняет смысловой отбор и проверяет итог по заданной схеме. Обзор продукта доступен на странице Web Intelligence.
Начните со схемы результата
Опишите только те поля, которые действительно использует следующий шаг. Чем меньше неоднозначности в JSON Schema, тем проще валидировать результат и разбирать отсутствие данных. Не заставляйте модель угадывать обязательное значение: если источник может его не содержать, сделайте поле необязательным или разрешите null.
JSON Schema — отдельный стандарт описания и проверки JSON-документов; актуальные версии и словари перечислены на официальной странице спецификации. В запросе LLMTOKENAPI используйте безопасную локальную схему без удалённых ссылок. Это делает контракт самодостаточным и не позволяет его смыслу измениться из-за внешнего файла.
Создайте разовое задание
Для запуска нужен вопрос, набор конкретных URL либо один домен, outputSchema, верхняя граница расходов и уникальный Idempotency-Key. Одновременно передавать URL и домен не следует: это разные стратегии выбора источников.
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.
Надёжный структурированный веб-анализ разделяет ответственность: Web Intelligence находит и связывает данные с источниками, JSON Schema проверяет форму, а приложение применяет бизнес-правила. Такая граница заметно безопаснее, чем разбирать произвольный текст модели регулярными выражениями.
