Извлечение данных без выдуманных полей
Классификатор решает, куда направить, извлечение - что именно достать. Главный риск здесь не формат, а выдуманные поля. Если каждое поле обязательно и null запрещён, модель получает прямой стимул заполнить пробел правдоподобной выдумкой. Поэтому extraction-prompt обязан разрешать отсутствие значения.
# Task
Извлеки данные заказа только из текста сообщения.
# Rules
- Не восстанавливай отсутствующие цифры по шаблону.
- Не нормализуй неоднозначную дату без locale.
- Для каждого значения верни evidence_span из исходного текста.
- Если поле не найдено, value = null и reason = "not_present".
- Если найдено несколько кандидатов, reason = "ambiguous".
# Schema
{
order_id: { value: string|null, evidence_span: string|null, reason: string },
date: { value_iso: string|null, evidence_span: string|null, reason: string },
amount: { value: number|null, currency: string|null, evidence_span: string|null }
}Полезно разделять три разных действия, которые часто сливают в одно.
- Extract - копирует наблюдаемое значение и его provenance, ничего не додумывая.
- Normalize - приводит формат по явным locale и timezone.
- Resolve - проверяет сущность через базу или tool, а не по языковой правдоподобности.
Отсюда и типичная ошибка: не смешивайте извлечение, бизнес-решение и write-действие в одном неразличимом ответе. Сначала получите типизированные данные, потом проверьте их, и только потом передайте в policy engine или отдельный workflow.
Пример важнее лишней инструкции. Покажите отдельные cases для null, двух кандидатов, локализованной даты и опечатки в ID. Эти границы ломают extraction чаще, чем обычный успешный пример.