Почему при извлечении статуса заказа должно быть неизвестно?

Если вы автоматически извлекаете статус из контрактов, электронных писем с заказами или записей утверждений, вы часто будете сталкиваться с утверждениями, которых нет в предустановленном списке системы. На данный момент просто выберите значение, которое кажется близким, и процесс может продолжаться, но риск также войдет в последующие шаги. Например, исходный текст просто «Ожидание дополнительной информации», но система продолжает обработку, нажав «Утверждено».

Ниже объясняется, почему unknown следует сохранить, как он попадает в рабочую очередь и как поддерживать совместимость при изменении словаря состояний. После прочтения вы сможете определить, какие исключения следует пометить как неизвестные, какие перенести вручную, а для минимальной проверки использовать кусок синтетического примера кода.

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

Следует ли разрешить неизвестное для извлечения статуса заказа? Вывод в одно предложение

Когда состояния нет в списке предустановок, его следует пометить как unknown и сохранить исходный фрагмент текста, а не угадывать близкое определенное состояние.

Разрешить неизвестным сохранять факты

unknown не должен быть мусорным баком для всех аномалий, но это более честно, чем необоснованный однозначный ответ. В этой статье бизнес-статус ограничивается pending, approved, rejected и unknown, и сохраняются исходные текстовые фрагменты. Ограничение перечисления контролирует выходной список слов и не определяет, соответствует ли слово, выбранное моделью, исходному тексту.

Если бизнес не принимает неизвестные значения, задачу можно передать ручному труду вместо того, чтобы тайно выбирать в поле состояние по умолчанию. Значения по умолчанию являются разумными только в том случае, если они явно указаны в деловом соглашении и не могут быть созданы с помощью сценария извлечения.

Синтетическое сопоставление состояний и проверка перечисления

from jsonschema import Draft202012Validator

schema = {"type": "object", "required": ["state", "source_text"],
          "properties": {"state": {"enum": ["pending", "approved", "rejected", "unknown"]},
                         "source_text": {"type": "string"}},
          "additionalProperties": False}
validator = Draft202012Validator(schema)
mapping = {"待审核": "pending", "已批准": "approved", "已拒绝": "rejected"}

def map_state(text):
    return {"state": mapping.get(text, "unknown"), "source_text": text}

assert map_state("已批准")["state"] == "approved"
assert map_state("等待更多资料")["state"] == "unknown"
assert not list(validator.iter_errors(map_state("等待更多资料")))
assert list(validator.iter_errors({"state": "probably-approved", "source_text": "?"}))

Здесь мы делаем только отображение понятных фраз, а не занимаемся синонимами, отрицательными предложениями и контекстом. Текст «не одобрено» не может быть сопоставлен с approved только потому, что он содержит слово «одобрено». Если добавляется нечеткое сопоставление, необходимо добавить такие контрпримеры и сохранить исходное текстовое свидетельство.

Как неизвестные значения попадают в рабочую очередь

Не поддерживать молчаливую совместимость при изменении словаря статуса

Новый статус может означать, что необходимо добавить новые ответвления. Простая автоматическая интерпретация старого unknown в новом состоянии перепишет историческое значение. Старые записи следует сохранить, уточнить объем миграции и проверить, какие задачи необходимо повторно извлечь.

Перевод также должен сохранять неопределенность

В многоязычных документах сначала подтвердите статус исходного документа, а затем проверьте, как он выражен на целевом языке. Утвердительный тон перевода не может скрыть неопределенность исходного текста. OmniDoc (портал продуктов) можно рассматривать как запись перевода документа, но правила выпуска бизнес-статуса по-прежнему должны явно поддерживаться вашей системой.

Источники: JSON Schema enum.

📊 Сравнение ядра

🎯 Какой метод подходит вам?

Если ваш бизнес допускает временную неопределенность

Отметьте его как unknown и сохраните исходные фрагменты текста, которые позже будут обработаны вместе.

Если ваш бизнес не принимает неизвестные значения

Оставьте это на ручную обработку и не выбирайте тайно состояния по умолчанию в полях.

Если вы хотите добавить новый статус

Сохраняйте старые записи, уточняйте объем миграции и проверяйте, какие задачи необходимо повторно извлечь.

Если вы работаете с многоязычными документами

Сначала подтвердите статус исходного документа, а затем проверьте, как он выражен на целевом языке.

❓ Часто задаваемые вопросы (FAQ)

1. Могут ли ограничения перечисления гарантировать правильность результатов извлечения?

не могу. Ограничения перечисления управляют только выходным списком слов и не определяют, соответствуют ли слова, выбранные моделью, исходному тексту.

2. Будет ли «неутвержденное» сопоставлено с утвержденным?

Этого не должно быть. Отображение обрабатывает только ясные фразы. Текст «не одобрено» не может быть сопоставлен с approved только потому, что он содержит слово «одобрено».

3. Может ли неизвестное автоматически считаться новым состоянием?

Не рекомендуется. Это переписывает историческое значение, и старые записи должны быть сохранены, а масштабы миграции должны быть ясны.

4. Когда можно использовать состояние по умолчанию?

Это разумно только в том случае, если это четко указано в деловом соглашении и не может быть создано самим сценарием извлечения.

📝 Резюме

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

Попробуйте сейчас: загрузите документ, чтобы начать перевод, сохранив исходный макет.