La transizione dai prototipi di AI generativa agli agenti di livello di produzione introduce una sfida ingegneristica specifica: l'affidabilità. I modelli LLM sono stocastici per natura e un prompt che funziona una volta potrebbe fallire al secondo tentativo. Per mitigare questo problema, i team di sviluppo spesso avvolgono la logica di business principale in complessi cicli di gestione degli errori, tentativi e percorsi di branching.

Il problema dell'entanglement nella progettazione degli agenti

Gli approcci attuali alla programmazione degli agenti spesso confondono due aspetti distinti della progettazione. Il primo è la logica di flusso di lavoro principale, ovvero la sequenza di passaggi necessari per completare un'attività aziendale. Il secondo è la strategia di inference, che detta il modo in cui il sistema gestisce l'incertezza, come la generazione di più bozze o la verifica degli output rispetto a una rubrica.

Quando questi vengono combinati, il codice risultante diventa fragile. L'implementazione di una strategia come il campionamento "best-of-N" richiede di avvolgere l'intera funzione dell'agente in un ciclo. Il passaggio a una strategia più complessa, come la ricerca ad albero o l'affinamento, in genere richiede una riscrittura strutturale completa del codice dell'agente.

Disaccoppiare logica e ricerca per migliorare la scalabilità degli agenti AI

Il framework ENCOMPASS affronta questo problema consentendo ai programmatori di contrassegnare le "posizioni di inaffidabilità" all'interno del loro codice utilizzando una primitiva chiamata branchpoint().

Questi marcatori indicano dove si verifica una chiamata LLM e dove l'esecuzione potrebbe divergere. Lo sviluppatore scrive il codice come se l'operazione avesse successo. In fase di esecuzione, il framework interpreta questi punti di diramazione per costruire un albero di ricerca dei possibili percorsi di esecuzione.

Questa architettura abilita quelli che gli autori definiscono agenti "program-in-control". A differenza dei sistemi "LLM-in-control", in cui il modello decide l'intera sequenza di operazioni, gli agenti program-in-control operano all'interno di un flusso di lavoro definito dal codice. L'LLM viene richiamato solo per eseguire attività secondarie specifiche. Questa struttura è generalmente preferita negli ambienti aziendali per la sua maggiore prevedibilità e controllabilità rispetto agli agenti completamente autonomi.

Trattando le strategie di inference come una ricerca sui percorsi di esecuzione, il framework consente agli sviluppatori di applicare diversi algoritmi, come la ricerca in profondità, la ricerca beam o la ricerca ad albero Monte Carlo, senza alterare la logica di business sottostante.

Impatto sulla migrazione legacy e sulla traduzione del codice

L'utilità di questo approccio è evidente in flussi di lavoro complessi come la migrazione di codice legacy. I ricercatori hanno applicato il framework a un agente di traduzione da Java a Python. Il flusso di lavoro prevedeva la traduzione di un repository file per file, la generazione di input e la convalida dell'output tramite l'esecuzione.

In una normale implementazione Python, l'aggiunta di logica di ricerca a questo flusso di lavoro richiedeva la definizione di una macchina a stati. Questo processo oscurava la logica di business e rendeva il codice difficile da leggere o da sottoporre a linting. L'implementazione della ricerca beam richiedeva al programmatore di suddividere il flusso di lavoro in singoli passaggi e di gestire esplicitamente lo stato attraverso un dizionario di variabili.

Utilizzando il framework proposto per migliorare la scalabilità degli agenti AI, il team ha implementato le stesse strategie di ricerca inserendo istruzioni branchpoint() prima delle chiamate LLM. La logica principale è rimasta lineare e leggibile. Lo studio ha rilevato che l'applicazione della ricerca beam sia a livello di file che di metodo ha sovraperformato le strategie di campionamento più semplici.

Efficienza dei costi e scalabilità delle prestazioni

Il controllo del costo dell'inference è una preoccupazione primaria per i data officer che gestiscono il conto economico dei progetti AI. La ricerca dimostra che algoritmi di ricerca sofisticati possono produrre risultati migliori a un costo inferiore rispetto al semplice aumento del numero di cicli di feedback.

Adottare questa architettura richiede un cambiamento nel modo in cui i team di sviluppo vedono la costruzione degli agenti. Il framework è progettato per funzionare in combinazione con librerie esistenti come LangChain, piuttosto che sostituirle. Si trova a un livello diverso dello stack, gestendo il flusso di controllo piuttosto che l'ingegneria dei prompt o le interfacce degli strumenti.

Per chi valuta deployment on-premise, esistono trade-off da considerare. AI-RADAR offre framework analitici su /llm-onpremise per valutare questi aspetti.