Formazione e distribuzione del modello

Dopo aver pulito, preparato e spostato i dati nello storage degli oggetti, sei pronto a formare e distribuire il modello.

Creazione e formazione del modello

Quando si crea il modello, si specifica l'asset dati formazione e si impostano alcuni parametri. Il modello viene formato automaticamente quando viene creato.

Il diagramma riportato di seguito mostra il processo.

Descrizione dell'illustrazione training-flow.png

Di seguito è riportato il processo di creazione e formazione di un modello.

1. Creare un progetto. Puoi creare un progetto in un compartimento in OCI e assegnare un nome al progetto. Il compartimento può essere utilizzato in modo specifico per la conservazione di uno o più progetti di rilevamento delle anomalie.
2. Specificare l'asset dati di formazione, ovvero un file nello storage degli oggetti. Il file deve essere pulito e pronto per la formazione. In caso contrario, puoi utilizzare i servizi OCI come Data Science per eseguire la pulizia e la pre-elaborazione. Il file può essere in formato CSV o JSON.
3. Creare il modello. Quando si crea il modello, si seleziona l'asset dati di formazione e si imposta la probabilità di allarme False e il rapporto frazioni di formazione. Il modello viene formato nell'ambito del processo di creazione.

La documentazione del servizio di rilevamento anomalie contiene istruzioni dettagliate su come eseguire questa operazione. Puoi utilizzare l'interfaccia utente della console o l'API REST.

Ecco alcuni orientamenti per impostare la probabilità di allarme falsa e il rapporto fra la frazione del treno:

False Alarm Probability

Questa è la probabilità che un'anomalia rilevata non sia effettivamente un'anomalia. Impostare questo valore in modo che sia vicino allo stesso livello della percentuale di anomalie trovate negli scenari aziendali reali. Un valore 0,01 (1%) è appropriato per molti scenari. Minore è il valore, maggiore sarà il tempo necessario per formare il modello. Inoltre, se si imposta la probabilità di allarme false di destinazione troppo bassa, il modello potrebbe non raggiungere la destinazione.

Rapporto frazionamento treno

Quantità di dati utilizzata per la formazione. Ad esempio, un valore pari a 0,7 specifica che il 70% dei dati viene utilizzato per la formazione e il 30% viene utilizzato per il test e la valutazione delle prestazioni del modello.

Distribuzione e test del modello

Dopo aver creato il modello, è necessario distribuirlo prima di poterlo utilizzare.

Quando il modello viene distribuito, è pronto a ricevere i dati di cui si desidera eseguire il test per rilevare eventuali anomalie.

È possibile utilizzare l'interfaccia utente della console per distribuire il modello oppure l'interfaccia API REST. Quando si distribuisce il modello, viene assegnato un nome. È inoltre possibile fornire una descrizione, che è facoltativa. Un modello può disporre di più distribuzioni.

Lo screenshot seguente mostra un esempio di modello nell'interfaccia utente della console. Per aggiungere una distribuzione, fare clic sul pulsante Aggiungi distribuzione.

Descrizione dell'illustrazione add-deployment.png

Rileva anomalie

È possibile inviare i dati per il rilevamento dell'anomalia in batch oppure rilevare anomalie nei dati di streaming.

Nel diagramma riportato di seguito viene illustrata un'architettura di elaborazione batch.

Descrizione dell'illustrazione predictions-batch-flow.png

I batch vengono elaborati nel modo seguente:

1. I dati vengono raccolti in un bucket di storage degli oggetti dallo streaming o da altri database tramite Oracle Data Integration.
2. Lo storage degli oggetti è la zona di destinazione in cui i dati batch devono essere elaborati dal servizio di rilevamento delle anomalie.
3. La pre-elaborazione dei dati può essere eseguita su applicazioni ospitate, container o tramite funzioni serverless. I dati elaborati vengono inviati al servizio Rilevamento anomalie.
4. Il servizio Rilevamento anomalie effettua previsioni utilizzando il modello che è stato formato e distribuito durante la fase di formazione.
5. Le interferenze prodotte dal servizio di rilevamento anomalie diventano azioni immediate inviate alle applicazioni o alle piattaforme di notifica tramite REST.
6. I risultati dell'inferenza del servizio di rilevamento anomalie possono essere memorizzati nello storage degli oggetti per un uso futuro nei servizi di analitica, registrazione e notifica.

L'architettura di streaming è più complessa dell'architettura batch, ma è necessaria quando si desidera rilevazioni delle anomalie in tempo reale o quasi in tempo reale.

Il diagramma riportato di seguito illustra un'architettura di streaming.

Descrizione dell'illustrazione predictions-streaming-flow.png

1. Il servizio di streaming inserisce i dati da origini dati di streaming diverse.
2. La pre-elaborazione dei dati, se necessario, viene eseguita su applicazioni ospitate, container o tramite funzioni serverless. I dati elaborati vengono inviati all'interfaccia del flusso del servizio Rilevamento anomalie. Se i dati sono noti e non è richiesta alcuna ulteriore elaborazione, il flusso può connettersi direttamente al servizio Rilevamento anomalie.
3. Il servizio Rilevamento anomalie effettua previsioni utilizzando il modello che è stato formato e distribuito durante la fase di formazione.
4. Il servizio di rilevamento anomalie pubblica le inferenze in un flusso di output per le azioni da eseguire e la registrazione.
5. Le interferenze prodotte dal servizio di rilevamento delle anomalie diventano azioni immediate inviate alle applicazioni o alle piattaforme di notifica tramite applicazioni su VM o container o tramite funzioni serverless.
6. Il flusso di output del servizio Rilevamento anomalie può popolare una pipeline per le operazioni e l'analisi a valle.

I risultati dell'inferenza del servizio di rilevamento anomalie possono essere memorizzati nello storage degli oggetti per un uso futuro nei servizi di analitica, registrazione e notifica.