Процесс обогащения — документация Entity Enricher

Процесс обогащения

Пошаговое описание того, как Entity Enricher обрабатывает одну сущность — от входных данных через классификацию и параллельное выполнение моделей до структурированного вывода.

Конвейер вкратце

Ввод
JSON сущности
+ схема
Классификация
Необязательная
проверка типа
Параллельные модели
Claude
финансовый
нормативный
общий
GPT-4
финансовый
нормативный
общий
Проверить
Проверка типов
Самоисправление
Вывод
Структурированный
JSON для каждой модели

Шаг 1: Настройте обогащение

Откройте страницу Workflow Editor и настройте свой enrichment. Пошаговый мастер рабочего процесса проведёт вас по этапам конвейера: Sample Data, Schema, Enrichment и Results, — а также по шагу Database Ready, когда schema связана с database sync, подтверждая, что изменения запуска поставлены в очередь для вашей базы данных (или объясняя, почему в сохранении было отказано).

Панель схемы (слева)

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

Панель обогащения (справа)

Настройте параметры обогащения (стратегию, модели, языки, классификацию, а также схему ответа и переключатели строгого структурированного вывода) и заполните ключи поиска сущности (название, веб-сайт, страна и т. д.) для её идентификации.

Панель результатов

Показывает прогресс и результаты в реальном времени для каждой модели. При использовании нескольких моделей появляется кнопка «Объединить результаты» для слияния.

Что проверяется до расходования токенов

Некоторые запросы в принципе не могут дать пригодный результат, и дешевле всего выяснить это до первого обращения к LLM. Поэтому заранее проверяются два контракта.

Контракт входных данных

Схема объявляет, что должны содержать её входные данные: ключевые поля, указывающие, какая это сущность, ключ у каждого элемента передаваемого вами массива и значение для каждого поля, помеченного как preserve (нельзя сохранить то, что не было передано). Запрос, в котором чего-то из этого нет, отклоняется единственной ошибкой, перечисляющей сразу все нарушения, — вместе с полным контрактом схемы, чтобы вы исправили всё за один проход, а не выясняли требования по одному отказу за раз. Контракт публикуется у каждой сохранённой схемы, так что клиент может проверить данные до отправки.

Контракт закрытого массива

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

Шаг 2: Предварительная классификация (необязательно)

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

Неблокирующий режим: Если классификация по какой-либо причине не удаётся, обогащение продолжается в обычном режиме. Классификация носит исключительно рекомендательный характер — она добавляет контекст в prompt обогащения, но никогда не блокирует конвейер.

Шаг 3: Выполнение стратегии

Каждая выбранная модель обрабатывает сущность по указанной вами стратегии — или, по умолчанию, по стратегии, выбранной автоматически на основе структуры вашей схемы, о чём запуск сообщает при старте. Если выбрано несколько моделей, они выполняются параллельно по провайдерам (Claude и GPT-4 работают одновременно), а модели одного провайдера — последовательно, чтобы соблюдать лимиты частоты запросов.

Пример мульти-экспертизы (3 области)
1
Разделить схему по экспертизам
Свойства сгруппированы по области экспертизы: финансовые поля, регуляторные поля, общие поля.
2
Параллельные вызовы LLM
Каждая expertise получает собственный целенаправленный prompt только с релевантными свойствами schema. Все выполняются одновременно.
3
Постепенное объединение результатов
По мере завершения каждой экспертизы её результат объединяется с накопленным результатом. Вы видите частичные результаты в реальном времени.
4
Применить логику сохранения
Исходные значения полей, помеченных как «preserve», восстанавливаются, поэтому ваши входные данные остаются нетронутыми. Внутри массивов обогащённые элементы сопоставляются с вашими исходными элементами по ключевым полям, а не по позиции, поэтому даже при изменённом порядке ответа восстанавливаются правильные значения.

Шаг 4: Валидация и самокоррекция

Каждый ответ LLM проверяется по вашей schema в реальном времени. Когда вывод не соответствует ожидаемым типам или ограничениям, система автоматически отправляет ошибки обратно в LLM для исправления.

Что исправляется автоматически:
Строка вместо числа
«42.2» становится 42.2
Индексированные объекты как массивы
{"0": "a", "1": "b"} превращается в ["a", "b"]
Строковые null
«null» или «None» становится настоящим null
Значения, которые модель не смогла определить
Объявляет их, а не выдумывает — такие пути становятся null

До 5 автоматических повторных попыток на каждый вызов LLM. Каждая повторная попытка содержит конкретную ошибку валидации, поэтому LLM точно знает, что исправлять, — и починка точечная: заново запрашиваются только те листья, которые вернулись неверными, а не весь ответ.

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

Обеспечение вывода на уровне источника

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

Схема ответа
Отправляет вашу схему через собственный канал response-schema провайдера, чтобы JSON проверялся на стороне сервера. По умолчанию выключено — иначе подходящие модели используют канал вызова инструментов.
Строгий структурированный вывод
Ограничивает декодирование по schema (без отклонений) в используемом структурированном канале. Включено по умолчанию; незаметно игнорируется model, которые не могут его применить.

Шаг 5: Потоковая передача в реальном времени

Entity Enricher использует Server-Sent Events (SSE) для потоковой передачи прогресса в реальном времени. Вам не нужно ждать завершения всех моделей — результаты появляются постепенно, по мере того как завершается каждая область экспертизы или модель.

Хронология событий (пример с 2 моделями, 3 областями экспертизы)
0.0sstartedЗадание начинается, 2 модели в очереди
0.1sclassification_startedНачинается предварительная проверка
0.8sclassification_completedСущность подтверждена как «совпадение» (95%)
0.9smodel_startedClaude и GPT-4 запускаются параллельно
1.2sexpertise_completedClaude: финансовые данные готовы, частичный результат передан потоком
1.5sexpertise_completedClaude: общие данные готовы, результат обновлён
1.8sexpertise_completedClaude: нормативная часть готова, полный результат готов
1.9smodel_completedClaude завершил работу с полным структурированным выводом
2.5smodel_completedGPT-4 завершил работу с полным структурированным выводом
2.5scompletedВсе модели завершены, поток закрывается

Шаг 6: Просмотр результатов

Каждая model получает собственную панель результатов, показывающую структурированный вывод JSON, значки прогресса по каждой expertise, использование токенов, стоимость и время обработки. При использовании стратегии multi-expertise значки expertise обновляются в реальном времени по мере завершения каждого домена.

Что вы видите по каждой модели:
  • Значок статуса — Ожидание, Выполняется, Успешно, Ошибка или Частично
  • Значки экспертиз — Цветные метки, показывающие прогресс по каждой области (синий = выполняется, зелёный = готово, красный = ошибка)
  • Прогрессивный JSON — Вывод обновляется после завершения каждой экспертизы
  • Метрики — Время обработки, количество токенов, стоимость в USD
  • Журнал выполнения — Записи с отметками времени для каждого события

Обработка частичного успеха

При использовании стратегии множественной экспертизы одни экспертизы могут завершиться неудачно, а другие успешно. Вместо того чтобы отбросить всё, Entity Enricher возвращает объединённый результат от успешных экспертиз со статусом «Частично». Затем вы можете повторить только неудавшиеся экспертизы, не запуская всё обогащение заново.

Пример: Если 2 из 3 экспертиз успешны, вы получаете структурированный вывод, охватывающий успешные области. Неудавшуюся экспертизу можно повторить, и её результаты будут объединены с существующим выводом.

Что произойдёт дальше?

После завершения обогащения ваши результаты сохраняются на странице «История» для дальнейшего использования. Если вы использовали несколько моделей, вы можете объединить результаты с помощью слияния нескольких моделей.