Il modello genera un campo extra. Dovrebbe essere visualizzato direttamente o rifiutato? Vediamo prima se c'è un accordo

Il modello restituisce un campo in più nei risultati dell'estrazione strutturata e il front-end può facilmente visualizzarlo direttamente come informazione utile. Ad esempio, se nel risultato dell'estrazione è presente un confidence aggiuntivo, verrà visualizzato come "credibilità" nella pagina. Il problema è che questo campo potrebbe non essere né definito né calibrato. I campi aggiuntivi non sono necessariamente innocui e possono consentire agli utilizzatori a valle di utilizzare valori non concordati come base per il proprio giudizio.

Questo articolo è adatto agli studenti responsabili della progettazione dell'interfaccia, dell'aggancio front-end e back-end o dei processi di elaborazione dei documenti. Di seguito viene spiegato come decidere innanzitutto se l'interfaccia è aperta o chiusa, come trasformare i campi sconosciuti in errori osservabili e quali informazioni devono essere restituite dopo il rifiuto. Dopo averlo letto potrai decidere se i campi aggiuntivi dovranno essere rifiutati, ignorati o inclusi nella nuova versione.

Questo articolo utilizza campioni sintetici per dimostrare il metodo di elaborazione. Il codice è stato controllato con esempi in un ambiente isolato e non è una garanzia di tutti i file reali o delle prestazioni del prodotto. Prima di elaborare documenti importanti, conservare gli originali e rivederli rispettando i limiti e gli elementi di accettazione nel testo.

È possibile visualizzare direttamente i campi multipli del modello? Conclusione di una frase

Concordare prima il contratto, poi decidere se accettarlo o rifiutarlo: i campi non definiti e calibrati non dovrebbero essere direttamente visualizzati come prova credibile.

Per prima cosa decidi se l'interfaccia è aperta o chiusa

Gli strumenti di esplorazione interna possono consentire campi estesi e le interfacce di distribuzione stabili spesso richiedono confini più ristretti. Quando proprietàaddizionali dello schema JSON è impostato su false, gli attributi non definiti dell'oggetto corrente possono essere rifiutati, ma ogni oggetto nidificato non verrà sovrascritto automaticamente in modo ricorsivo. Ciò che è consentito ad ogni livello dovrebbe essere scritto chiaramente.

Ciò non significa che tutte le interfacce debbano rifiutare tutte le estensioni. La chiave è rendere chiara la scelta e lasciare aperto il meccanismo di controllo delle versioni per gli aggiornamenti. Ignorare silenziosamente i campi con lo stesso nome oggi e utilizzarli improvvisamente domani può facilmente portare a interpretazioni diverse dei dati storici.

Trasforma i campi sconosciuti in errori osservabili

from jsonschema import Draft202012Validator

schema = {"type": "object", "required": ["name", "evidence"],
          "properties": {"name": {"type": "string"},
                         "evidence": {"type": "object", "required": ["page"],
                                      "properties": {"page": {"type": "integer", "minimum": 1}},
                                      "additionalProperties": False}},
          "additionalProperties": False}
validator = Draft202012Validator(schema)
valid = lambda x: not list(validator.iter_errors(x))

assert valid({"name": "Demo", "evidence": {"page": 1}})
assert not valid({"name": "Demo", "confidence": 0.99, "evidence": {"page": 1}})
assert not valid({"name": "Demo", "evidence": {"page": 1, "guess": True}})

Il valore numerico 0.99 nell'esempio è solo un input sintetico che dovrebbe essere rifiutato, non un vero risultato di qualità per nessun modello. L'esempio controlla contemporaneamente i livelli di livello superiore e nidificati per evitare omissioni che chiudono solo il livello esterno e consentono al livello interno di espandersi arbitrariamente.

Fornire informazioni riparabili dopo il rifiuto

📊 Confronto core: interfaccia aperta e interfaccia chiusa

Anche l'eliminazione dei campi è una decisione relativa al trattamento dei dati

Se viene effettivamente utilizzato "leggi campi conosciuti, ignora altri campi", i risultati originali e il comportamento di filtro dovrebbero essere documentati. Altrimenti sarà difficile distinguere se i dati di origine non contengano originariamente un determinato elemento o se il livello dell'interfaccia lo abbia rimosso. Inoltre, l'abbandono del campo non dovrebbe essere un modo per mascherare la non conformità di un modello al protocollo.

Lascia un confine per la traduzione e l'estrazione

L'output della traduzione dei documenti e l'output del campo strutturato sono due contratti diversi. Quando si utilizza OmniDoc per elaborare i documenti, è possibile utilizzare l'elenco dei campi per la verifica post-traduzione, ma non è possibile accettare automaticamente ulteriori giudizi aziendali o campi di confidenza solo perché la traduzione è fluida.

🎯Quale metodo è adatto a te?

Se stai utilizzando strumenti di esplorazione interna

I campi estensione potrebbero essere consentiti, ma dovrebbero comunque essere visualizzati come non definiti.

Se mantieni un'interfaccia di consegna stabile

Racchiudi ogni livello con additionalProperties: false e definisci confini separati per gli oggetti nidificati.

Se vuoi introdurre nuovi campi

Rilascia nuove versioni dello schema, non allentare segretamente le vecchie versioni.

Se il tuo processo deve eliminare i campi ridondanti

Registra i risultati originali e il comportamento di filtraggio per tracciarli facilmente in seguito.

❓ Domande frequenti (FAQ)

1. additionalProperties: false può coprire tutti i livelli?

Non può essere sovrascritto automaticamente. Rifiuta solo gli attributi non definiti dell'oggetto corrente e ciascun oggetto nidificato deve scrivere chiaramente ciò che è consentito separatamente.

2. Più campi di output in un modello sono necessariamente dannosi?

Non necessariamente, ma ciò potrebbe consentire agli utilizzatori a valle di utilizzare come base valori non concordati, pertanto la loro definizione e lo stato di calibrazione dovrebbero essere confermati prima.

3. Cosa deve essere restituito quando si rifiutano campi aggiuntivi?

Dovrebbe includere il nome della chiave sconosciuta, il percorso dell'oggetto (se interno) e la versione del protocollo, non solo un errore JSON.

4. I campi ridondanti possono essere ignorati direttamente?

Sì, ma i risultati grezzi e il comportamento di filtraggio dovrebbero essere documentati ed evitare di utilizzarli per mascherare problemi in cui il modello non aderisce al protocollo.

📝 Riepilogo

I campi aggiuntivi non possono essere visualizzati direttamente solo perché sembrano utili. È necessario prima concordare i limiti dell'interfaccia e poi decidere se accettare, rifiutare o aggiornare la versione. Solo chiarendo le regole a ogni livello i dati storici e l’interpretazione a valle possono essere coerenti.

Provalo subito: carica il documento per iniziare la traduzione, mantenendo il layout originale