Creazione di app LLM: una chiara guida passo passo | di Almog Baku | Giugno 2024 | Intelligenza-Artificiale

A volte, il tuo “esperimento” fallirà, quindi ruoti leggermente il tuo lavoro e quest'altro esperimento è riuscito molto meglio.

Proprio per questo motivo, Prima Quando progettiamo la nostra soluzione finale, dobbiamo iniziare in modo semplice e coprire i nostri rischi.

1. Definire un “budget” o un intervallo di tempo. Vediamo cosa possiamo fare in X settimane e poi decideremo come e se continuare. Di solito, saranno sufficienti 2-4 settimane per comprendere il PoC di base. Se sembra promettente, continua a investire risorse per migliorarlo.
2. Sperimentare-Sia che tu scelga un approccio dal basso verso l'alto o dall'alto verso il basso per la fase di sperimentazione, il tuo obiettivo è massimizzare il tasso di successione dei risultati. Entro la fine della prima iterazione della sperimentazione, dovresti avere alcuni PoC (con cui le parti interessate possono giocare) e una linea di base raggiunta.
3. Retrospettiva — Al termine della nostra fase di ricerca, saremo in grado di comprendere la fattibilità, i limiti e i costi della creazione di un’app di questo tipo. Questo ci aiuta a decidere se produrlo e come progettare il prodotto finale e la sua UX.
4. Produzione — Sviluppa una versione pronta per la produzione del tuo progetto e integrala con il resto della tua soluzione seguendo le migliori pratiche SWE standard e implementando un meccanismo di feedback e raccolta dati.

Per implementare bene il processo orientato all’esperimento, dobbiamo prendere una decisione informata sull’approccio e sulla costruzione di questi esperimenti:

Iniziare il Lean: l’approccio dal basso verso l’alto

Mentre molti dei primi utilizzatori si buttano rapidamente nel” All'avanguardia” sistemi ad agenti multicatena con Langchain completo o qualcosa di simile, ho trovato “L’approccio dal basso verso l’alto“spesso dà risultati migliori.

Inizia magro, molto magroabbracciando il “un unico suggerimento per domarli tutti” filosofia. Anche se questa strategia potrebbe sembrare non convenzionale e probabilmente produrrebbe inizialmente risultati negativi, stabilisce a linea di base per il tuo sistema

Da lì, itera e perfeziona continuamente i tuoi prompt, utilizzando tecniche di ingegneria tempestiva per ottimizzare i risultati. Quando identifichi i punti deboli della tua soluzione snella, suddividi il processo aggiungendo rami per colmare tali carenze.

Durante la progettazione di ogni “foglia” del mio grafico del flusso di lavoro LLM, o architettura nativa LLM, seguo Il triangolo magico³ per determinare dove e quando tagliare i rami, dividerli o ispessire le radici (utilizzando tecniche di ingegneria immediata) e spremere più limone.

Ad esempio, per implementare “query SQL in linguaggio nativo” con l'approccio bottom-up, inizieremo inviando ingenuamente gli schemi a LLM e chiedendogli di generare una query.

Di solito, ciò non contraddice l'approccio “dall'alto verso il basso”, ma costituisce un ulteriore passo avanti. Ciò ci consente di ottenere risultati rapidi e di attrarre maggiori investimenti nei progetti.

Il quadro generale in anticipo: la strategia top-down

“Sappiamo che il flusso di lavoro LLM non è facile e, per raggiungere il nostro obiettivo, probabilmente ci ritroveremo con un flusso di lavoro o un'architettura LLM nativa.”

L'approccio Top-Down lo riconosce e inizia progettando l'architettura nativa LLM fin dal primo giorno e implementando le sue diverse fasi/catene fin dall'inizio.

In questo modo, puoi testare l'architettura del tuo flusso di lavoro nel suo insieme e spremere l'intero limone invece di perfezionare ciascuna foglia separatamente.

Ad esempio, per implementare l'”interrogazione SQL in linguaggio nativo” con l'approccio top-down, inizieremo a progettare l'architettura prima ancora di iniziare a scrivere il codice e poi passeremo all'implementazione completa:

Trovare il giusto equilibrio

Quando inizi a sperimentare con i LLM, probabilmente inizierai da uno degli estremi (top-down troppo complicato o one-shot super semplice). In realtà, non esiste un vincitore del genere.

Idealmente, definirai un buon SoP¹ e modellerai un esperto prima di codificare e sperimentare il modello. In realtà, fare la modella è molto difficile; a volte potresti non avere accesso a un tale esperto.

Ho trovato difficile ottenere una buona architettura/SoP¹ al primo colpo, quindi vale la pena sperimentare leggermente prima di passare ai pezzi grossi. Tuttavia, ciò non significa questo qualunque cosa deve essere troppo magro. Se hai già un comprensione preliminare quel qualcosa DOVERE essere suddiviso in pezzi più piccoli: fallo.

In ogni caso, dovresti sfruttare il paradigma del Triangolo Magico³ e modellare correttamente il processo manuale durante la progettazione della tua soluzione.