News

Come opera un Agente AI in un sistema CAE (Moldex3D)

Chi dovrebbe sviluppare il primo agente CAE: il fornitore del software o l’azienda di ingegneria?

Jimmy Chien Engineering Technology Transformation Leader – Moldex3D

La scorsa settimana ho spiegato perché le aziende che introducono agenti CAE non dovrebbero iniziare automatizzando l’intero flusso di lavoro di simulazione.
Un punto di partenza più pratico è rappresentato da un caso d’uso frequente e ben definito, con confini chiari e risultati verificabili.
Una volta individuato tale caso d’uso, sorge spontanea una domanda:
chi dovrebbe sviluppare l’agente CAE?

Engineering Technology Transformation Leader

Il fornitore del software CAE potrebbe sembrare la scelta più ovvia.
I fornitori di software sanno bene:

• quali operazioni il software è in grado di eseguire;
• quali dati di input e impostazioni sono richiesti;
• cosa significano gli stati del solutore, gli avvisi e gli errori;
• come estrarre i risultati e i KPI ingegneristici;
• come mantenere la compatibilità tra le diverse versioni.
  Tuttavia, conoscere il funzionamento di un software CAE non equivale a conoscere le logiche con cui un’azienda prende le proprie decisioni ingegneristiche.

Le regole che guidano un agente AI derivano spesso da un patrimonio di conoscenze specifico dell’azienda:

• quali ipotesi ingegneristiche sono considerate accettabili;
• quando le informazioni disponibili sono sufficienti;
• quali avvisi richiedono ulteriori approfondimenti;
• quali criteri di qualità e validazione devono essere soddisfatti;
• quali operazioni possono essere automatizzate;
• in quali casi l’agente deve coinvolgere un ingegnere.

Forse la domanda corretta non è:
«L’agente dovrebbe essere sviluppato dal fornitore del software o dall’azienda?»
Bensì:
«Quali funzionalità dovrebbe fornire il software vendor e quali valutazioni ingegneristiche deve definire l’azienda?»

Prima di una simulazione, il fornitore può mettere l’agente in condizione di verificare i dati di input necessari; spetta però all’azienda stabilire se tali dati siano sufficienti per la specifica decisione ingegneristica da prendere.
Durante l’esecuzione, il fornitore può aiutare l’agente a interpretare gli stati del solutore e gli eventuali avvisi, ma è l’azienda a dover determinare se un avviso renda il risultato inaccettabile.
Al termine della simulazione, il fornitore può consentire all’agente di estrarre risultati e KPI; tuttavia, spetta all’azienda definire quali risultati siano rilevanti, quali prove di validazione siano richieste e chi sia autorizzato ad approvarli.

Se l’intero agente viene fornito dal vendor, esso potrebbe gestire il software in modo efficiente, ma risultare comunque troppo generico rispetto alle pratiche ingegneristiche specifiche del cliente.
Se, al contrario, l’azienda sviluppa tutto internamente, dovrà farsi carico dell’integrazione con il software, della gestione degli stati di esecuzione, della compatibilità tra le versioni e degli aggiornamenti futuri. Un modello più pratico potrebbe essere il seguente:
Funzionalità CAE fornite dal vendor
＋ Conoscenza del dominio specifica per l’azienda
＋ Vincoli chiaramente definiti
＋ Supervisione umana
I fornitori di software dovrebbero rendere le funzionalità CAE pronte per l’integrazione in agenti.
Le organizzazioni ingegneristiche dovrebbero rendere la propria conoscenza del dominio eseguibile.
Il primo agente CAE affidabile nascerà probabilmente dall’incontro tra funzionalità software solide e conoscenze ingegneristiche specifiche dell’azienda.
Se la vostra organizzazione dovesse introdurre un agente CAE, vi aspettereste una soluzione completa, oppure una base che il vostro team possa adattare con le proprie competenze di dominio?