Come diventare un applied AI engineer

Ho scritto questa guida come avrei voluto averla prima di passare all'Ingegneria AI Applicata.

Il ruolo si sovrappone ampiamente all'ingegneria del software tradizionale, ma aggiunge alcuni concetti importanti che la maggior parte degli ingegneri software deve imparare durante la transizione. Ti suggerisco di usarla come schema dei temi principali da comprendere, seguendo poi le risorse linkate nell'articolo per approfondire.

Alla fine, dovresti avere un'idea molto più chiara di cosa sia l'Ingegneria AI Applicata, cosa richieda realmente il lavoro e come vada oltre l'ingegneria del software tradizionale.

Se sei interessato a lavorare su alcuni dei problemi più interessanti nell'AI Applicata con un team di ingegneri di grande talento, assumiamo sempre. Candidati sul nostro sito varickagents.com o segnala un candidato per un bonus di 20.000 $.

Detto questo, il modo migliore per capire l'Ingegneria AI Applicata è iniziare dal cambiamento nel modo di pensare alla creazione di software.

Ingegneria del software vs Ingegneria AI

La differenza più grande tra un ingegnere software e un ingegnere AI è che l'ingegneria del software tradizionale ti allena a pensare in modo deterministico, mentre l'AI applicata ti costringe a pensare in modo probabilistico.

Nel software normale, scrivi la logica, la fai funzionare e quando qualcosa si rompe di solito riesci a tracciarlo – un input strutturato produce deterministicamente un output strutturato.

L'AI applicata non funziona così. Stai costruendo attorno a una chiamata API non deterministica all'intelligenza, il che significa che lo stesso input può restituire risultati diversi ogni volta. Per questo motivo, il lavoro non consiste più solo nel costruire il software, ma diventa misurare se il sistema si comporta effettivamente come dovrebbe.

Il modo in cui lo facciamo è attraverso le valutazioni (eval), quindi spiegherò come costruire una suite di valutazione che garantisca che l'agente che sviluppi non commetta errori. Ho imparato che questa è una delle competenze più importanti per uno sviluppatore di AI applicata, data la natura non deterministica del lavoro che svolgiamo.

La parte successiva dell'articolo riguarda lo sviluppo di ogni parte di un agente AI (tranne il modello stesso, ovviamente), perché puoi chiamare un'API per un modello ma devi costruire tutto il resto da solo. Questo si chiama ingegneria dell'harness.

E infine, spiegherò come passare da un agente in produzione a più agenti – e perché è un problema di sistemi distribuiti. Se riesci ad arrivare alla fine di questo articolo, non c'è motivo per cui tu non possa fare la transizione per diventare un ingegnere AI Applicato.

Valutazioni (Evals)

Un ingegnere AI applicato trasforma l'incertezza in fiducia misurata usando le valutazioni. Nello sviluppo software tradizionale, ti fidi del sistema perché hai scritto la logica e testato il codice. Nell'AI applicata, non puoi fidarti del sistema in quel modo perché il modello può comportarsi diversamente tra un'esecuzione e l'altra. Quindi l'ingegnere AI deve costruire un livello di misurazione attorno all'agente.

Una valutazione è il processo di assegnare un compito a un agente, lasciarlo eseguire e valutare cosa ha fatto. L'obiettivo è dimostrare due cose: che l'agente ha completato correttamente il lavoro e che è rimasto entro i confini stabiliti.

Il primo passo è valutare il risultato. Questo è il passo più semplice del processo di valutazione. Per un agente di fatture, quelli su cui lavoro di solito, significa assicurarsi che la fattura finisca nel posto giusto o che il duplicato venga segnalato. Stai solo confrontando il risultato finale con ciò che sarebbe dovuto accadere.

Il secondo passo è valutare la traiettoria. Questo è il percorso che l'agente ha seguito per arrivare a quel risultato: gli strumenti che ha chiamato, i campi che ha toccato, gli argomenti che ha passato e le azioni che ha tentato lungo il percorso. Questo è importante perché un agente può raggiungere la risposta finale corretta mentre fa comunque qualcosa di pericoloso nel processo. Può classificare correttamente una fattura mentre cambia anche i dettagli bancari o invia un pagamento prima dell'approvazione.

La traiettoria stessa è solo un log: un elenco ordinato di ogni strumento chiamato dall'agente e degli argomenti passati – valutarla significa semplicemente scrivere controlli su quel log.

Alcuni controlli sono deterministici – assicurarsi che send_payment non appaia mai prima di una chiamata di approvazione, verificare che gli unici campi scritti fossero quelli che l'agente era autorizzato a scrivere. Altri sono valutazioni di giudizio – se un'escalation era appropriata, se il ragionamento giustificava l'azione. Questi vanno a un secondo modello con una rubrica.

Il principio generale da seguire è che i controlli deterministici di solito catturano le violazioni di sicurezza, mentre il modello giudice valuta la qualità.

Il risultato sono due voti per ogni caso di test: l'agente ha ottenuto la risposta giusta e si è comportato correttamente per ottenerla. Questi devono essere riportati separatamente, perché un agente che classifica correttamente le fatture il 95% delle volte ma tocca un campo proibito nel 4% delle esecuzioni sembra ottimo con un punteggio combinato ma causa gravi complicazioni aziendali in produzione.

Questo articolo funge da introduzione alle valutazioni e a tutti gli altri argomenti trattati, quindi ho linkato altre risorse per aiutarti ad approfondire. Alcune che mi hanno aiutato a capire come costruire valutazioni efficaci sono:

• Il corso sulle valutazioni di Anthropic
• La guida completa alle valutazioni di Lenny
• Le FAQ sulle valutazioni di Hamel

Ti consiglio di esaminarle tutte, ma di iniziare con quelle di Lenny e Hamel prima di passare al corso sulle valutazioni (che è leggermente più pratico).

Ma una valutazione ha comunque bisogno di un agente da testare, e tutto ciò che circonda il modello deve essere costruito da te. Questo sistema circostante si chiama harness – la prossima sezione spiega come pensare a ogni parte del processo di ingegneria dell'harness, dalla chiamata agli strumenti all'ottimizzazione della finestra di contesto.

Ingegneria dell'Harness

Un modello da solo non è un agente. Un modello può ragionare, classificare, scrivere e decidere, ma non può operare da solo all'interno di un'azienda. Può dire quale azione dovrebbe accadere, ma non può eseguire quell'azione in sicurezza a meno che tu non costruisca il sistema attorno ad esso – e quel sistema è l'harness.

L'harness è tutto ciò che sta attorno al modello e trasforma una chiamata API in un agente funzionante: gli strumenti che può usare, il contesto che vede, lo stato che ricorda, i guardrail che lo vincolano e il ciclo che gli permette di continuare a lavorare fino al completamento del compito.

La prima parte dell'harness è l'esecuzione degli strumenti.

I modelli leggono e scrivono solo testo, quindi quando un modello decide di fare qualcosa, in realtà non la esegue. Emette una richiesta strutturata (una stringa JSON) per aggiornare un record, inviare un'email o cercare in un database.

L'harness riceve quella richiesta, la convalida, esegue l'operazione reale e invia il risultato al modello come testo.

La seconda parte è la gestione del contesto. Ogni istruzione, menu degli strumenti, risultato degli strumenti e messaggio precedente occupa spazio nella finestra di contesto del modello. L'harness deve decidere cosa il modello deve vedere in questo momento, cosa dovrebbe essere riassunto e cosa dovrebbe essere rimosso. Senza questo, gli agenti si perdono in una storia irrilevante.

Scriverò un articolo più completo che approfondisce ogni parte del processo di sviluppo dell'harness, ma per ora ti consiglio di ascoltare questo intervento di un ingegnere di Arize, la piattaforma di apprendimento continuo per agenti, che approfondisce il loro processo di pensiero sulla gestione del contesto.

Per saperne di più su come applicare una gestione efficace del contesto ai tuoi agenti nella pratica, leggi questi blog:

• L'articolo sulla gestione del contesto di OpenAI
• Una guida pratica alla gestione del contesto
• La guida all'ingegneria del contesto di Anthropic

La terza parte nell'ingegneria dell'harness è lo stato e la memoria. I modelli sono senza stato tra una chiamata e l'altra, quindi tutto ciò che l'agente deve ricordare deve vivere al di fuori del modello (di solito in un database, un archivio di file o un record di attività). Il contesto è ciò che il modello sta guardando in questo momento. Lo stato è tutto ciò che l'agente sa ma che non sta attualmente guardando.

La quarta parte sono i guardrail. Poiché il modello può richiedere l'azione sbagliata con la stessa sicurezza di quella giusta, l'harness deve verificare i permessi, convalidare gli input, bloccare le azioni non sicure e instradare i passaggi ad alto rischio agli umani.

Infine, tutto questo viene collegato insieme nel ciclo dell'agente: costruisci il contesto, chiami il modello, ispezioni la sua risposta, esegui lo strumento se consentito, memorizzi il risultato, aggiorni il contesto e ripeti fino al completamento del compito.

L'ingegneria dell'harness è la maggior parte di ciò che farai come ingegnere AI Applicato, quindi prenditi il tuo tempo con questa sezione. Come ingegnere AI applicato, il tuo intero lavoro è costruire l'ambiente operativo che permette a un sistema probabilistico di funzionare all'interno di un software deterministico.

Ma la produzione di solito non si ferma a un agente.

Man mano che il flusso di lavoro diventa più grande, l'istinto naturale è di dividere il lavoro. Ma una volta che aggiungi quel secondo agente, la progettazione del sistema cambia.

Con un agente, la maggior parte della complessità vive all'interno di un ciclo. Con più agenti, ora hai diversi cicli che agiscono sullo stesso ambiente. Ogni agente potrebbe leggere uno stato che un altro agente ha appena cambiato, scrivere in una memoria da cui un altro agente dipende, o chiamare uno strumento il cui risultato influisce sull'intero flusso di lavoro.

A quel punto, la parte difficile non è più solo il prompting, le valutazioni o la progettazione dell'harness. Diventa un problema di sistemi distribuiti: chi possiede quale stato, chi può scrivere in memoria, quali strumenti sono sicuri da riprovare e cosa succede quando due agenti ragionevoli intraprendono azioni nell'ordine sbagliato.

Le distribuzioni multi-agente sono un problema di sistemi distribuiti

Quando il primo agente funziona e il flusso di lavoro diventa più grande, un nuovo ingegnere AI applicato ha naturalmente l'istinto di dividere il lavoro in ruoli: un agente ricerca, uno pianifica, uno esegue, uno revisiona.

Ma il secondo agente cambia l'unità di progettazione dall'agente al sistema. Diversi cicli ora agiscono nello stesso ambiente – un agente può aggiornare lo stato del cliente mentre un altro è a metà della pianificazione scrivendo sullo stato obsoleto. Entrambi hanno preso decisioni ragionevoli, ma il sistema ha permesso a quelle decisioni di interagire nell'ordine sbagliato.

Questo è un problema di sistemi distribuiti. La buona notizia è che gli ingegneri dei sistemi distribuiti hanno risolto questi fallimenti decenni fa. Il tuo compito è applicarli a cicli che contengono un LLM. Di seguito è riportato un elenco di soluzioni dai sistemi distribuiti che si applicano all'ingegneria AI:

Principio del singolo scrittore. Ogni pezzo importante di stato ha esattamente un agente che può scriverci – altri agenti lo leggono o inviano richieste di modifica. Applica questo a livello di strumento: se l'agente di esecuzione è l'unico che può scrivere nel CRM, l'agente di ricerca non può corrompere il CRM, non importa quanto male ragioni.

Chiavi di idempotenza. Gli agenti riprovano le chiamate agli strumenti quando qualcosa fallisce o scade, ma i tentativi possono essere pericolosi quando lo strumento cambia qualcosa nel mondo reale. Non vuoi che un agente invii lo stesso pagamento due volte solo perché la prima richiesta sembrava fallita. La soluzione è allegare una chiave univoca a ogni chiamata di strumento mutante – ovvero qualsiasi azione che modifica i dati in un sistema esterno. Se lo strumento vede la stessa chiave di nuovo, dovrebbe restituire il risultato originale invece di eseguire l'azione una seconda volta. L'API di Stripe funziona in questo modo – e si applica allo sviluppo di agenti quando si ha a che fare con pagamenti, email, ecc.

Precondizioni sulle scritture. Gli agenti spesso agiscono su una visione obsoleta del mondo. Qualcosa potrebbe essere cambiato tra il momento in cui l'agente ha fatto il suo piano e il momento in cui tenta di aggiornare un sistema esterno. Per prevenire scritture obsolete, gli strumenti mutanti dovrebbero richiedere una condizione prima di apportare la modifica. Ad esempio: "imposta lo stato su Approvato solo se è ancora In sospeso." Se lo stato è già cambiato, lo strumento dovrebbe fallire chiaramente invece di sovrascrivere silenziosamente lo stato più recente.

Passaggi espliciti. Passa il lavoro come messaggi con uno schema definito, sequenziati da un orchestratore. Un agente dovrebbe ricevere il suo compito, non scoprirlo.

TLDR

Questo articolo funge da panoramica degli argomenti più importanti che ho imparato come ingegnere AI Applicato: valutazioni, ingegneria dell'harness e progettazione di sistemi multi-agente.

Se c'è una cosa che dovresti portare via, è questa – il modello fornisce l'intelligenza, ma tutto ciò che lo rende affidabile (il livello di misurazione, l'ambiente operativo, le regole di coordinamento) è progettato da te. Comprendi questi concetti e la transizione dall'ingegneria del software diventa un'estensione delle competenze che già possiedi.

Se sei interessato a questo tipo di lavoro e vuoi venire ad affrontare alcuni dei problemi più interessanti nell'AI Applicata con un team di ingegneri di grande talento, assumiamo sempre. Candidati sul nostro sito varickagents.com e potremmo farti iniziare il prima possibile. D'altra parte, se segnali un candidato di successo, ti daremo un bonus di 20.000 $ per la segnalazione.