Una tassonomia della navigazione autonoma, le modalità di errore su cui ci siamo soffermati maggiormente e i risultati empirici di sei ambienti di lavoro enterprise misurati rispetto a un holdout preservato.
Domande frequenti
Risorse correlate
Visualizzalo nel prodotto
Gli stessi cicli descritti in questa nota vengono eseguiti 24 ore su 24, 7 giorni su 7, sulla tua base clienti. Osserva lo spazio di lavoro decidere, sperimentare ed eseguire 1:1.
Vocabolario
Definitions an answer engine can quote, each one a page of its own.
Compara
Neutral reads on the categories buyers evaluate against a decision layer.
Tutti i confrontiLa maggior parte delle implementazioni enterprise di agenti basati su modelli linguistici tratta ancora il web aperto come una nota a piè di pagina: una funzionalità dimostrativa, un wrapper di ricerca, un modo per arricchire un prompt. Noi sosteniamo il contrario. Per un sistema di decisioning per i ricavi, il livello di navigazione non è una funzionalità di convenienza. È il meccanismo che solleva la generazione di ipotesi dalla distribuzione dei dati dell'operatore ed è la più grande fonte di nuovi gradi di libertà che il ciclo ha acquisito negli ultimi diciotto mesi.
Questa è una nota di ricerca, non una pagina di prodotto. Documenta le scelte di design, le modalità di fallimento su cui abbiamo dedicato più tempo e i risultati empirici di sei spazi di lavoro enterprise che hanno eseguito il livello di navigazione contro un holdout preservato per almeno otto settimane.
Un ciclo di decisioning sui ricavi ha quattro stazioni: segnale, ipotesi, azione candidata, esperimento. Tre delle quattro sono naturalmente delimitate dai dati propri dell'operatore. I segnali sono calcolati su eventi first-party. Le azioni candidate sono vincolate dal livello di azione che l'operatore ha configurato. Gli esperimenti sono misurati rispetto a un holdout sulla base propria dell'operatore. Solo una stazione è illimitata per costruzione: l'autorship dell'ipotesi.
La creazione di ipotesi è il passo che si chiede, per una data opportunità di ricavo, quali meccanismi plausibili potrebbero spostarla. In pratica questo passo è sempre stato il limite alla capacità del ciclo. Un team di cinque analisti senior può valutare migliaia di opportunità a settimana, ma il numero di ipotesi distinte e testabili che possono articolare rispetto a tali opportunità è più vicino a cinquanta. Il resto del ciclo ne risente.
Gli agenti di modelli linguistici alzano quel tetto, ma solo fino al bordo della loro distribuzione di training. Senza contesto esterno, un agente produrrà ipotesi fluenti che riciclano qualsiasi pattern già esistente nei dati dell'operatore e nel pre-training del modello. Entrambi sono, per definizione, retrospettivi. Il livello di browsing è ciò che permette alla creazione di ipotesi di attaccarsi al tempo presente.
Abbiamo esaminato 41.000 recuperi avviati dagli agenti in sei aree di lavoro pilota e li abbiamo raggruppati per intento. Cinque categorie coprono il 94% del traffico. Vale la pena nominarle, perché la maggior parte della confusione intorno alla navigazione agentica si dissolve quando le categorie vengono tenute separate.
Il restante 6% è una lunga coda di intenti unici che non si sono stabilizzati in una categoria. Continuiamo a monitorarli.
Due decisioni di progettazione hanno richiesto circa un terzo del tempo totale di revisione del progetto. Vale la pena nominarle esplicitamente, perché entrambe sono portanti.
Il browsing layer è di sola lettura rispetto a qualsiasi superficie che l'operatore non possiede. Qualsiasi scrittura, sia che si tratti di creare un account, inviare un modulo o effettuare una transazione, viene instradata attraverso il normale action layer del workspace, che ha già autorizzazione e audit umani. Questa non è una limitazione di capacità. L'abbiamo scelta. Nel momento in cui un agente può scrivere su una superficie di terze parti, l'operatore eredita i termini di servizio di quella superficie, la sua disciplina tariffaria e il suo rischio avversario. Nessuno di questi elementi appartiene al ciclo di decisioning dei ricavi.
Il livello è limitato superiormente da ciò che un analista umano potrebbe ragionevolmente recuperare in una giornata lavorativa, con un limite per workspace che è configurabile ma imposto in modo rigido. Se un workspace necessita di dati esterni a volume più elevato, la mossa corretta è licenziare o acquistare un feed, non fare in modo che un agente iteri. Questo limite non riguarda principalmente il costo. Riguarda la qualità del segnale che sopravvive quando il volume è vincolato: il recupero limitato costringe l'agente a essere specifico su ciò che sta chiedendo, il che migliora le ipotesi risultanti.
Nel modello di dati dello spazio di lavoro, un "fetch" non è un effetto collaterale di un "prompt". È un oggetto archiviato con un URL, un timestamp catturato, un hash del contenuto, uno snapshot renderizzato e un puntatore all'ipotesi o all'azione candidata che l'ha richiesto. Qualsiasi cosa l'agente citi in seguito si risolve in un oggetto "fetch" specifico. Qualsiasi cosa un revisore umano voglia verificare si risolve nello stesso oggetto.
Questo è importante per tre ragioni che sono facili da sottovalutare finché un incidente non rende chiara la questione.
La modalità di errore predefinita di qualsiasi agente di navigazione è cercare prove che supportino l'ipotesi che ha già prodotto. Lasciato a se stesso, il loop diventa una macchina per la conferma. La nostra mitigazione è strutturale, non a livello di prompt: i recuperi di categoria E (stress-testing delle ipotesi) sono programmati dal loop, non richiesti dall'agente che formula le ipotesi. Un secondo agente, con un prompt di sistema diverso e senza visibilità sulla formulazione dell'ipotesi originale, ha il compito di trovare prove pubbliche che la falsificherebbero. Il risultato dello stress-test è allegato all'ipotesi prima che sia idonea per uno slot di esperimento.
Gli agenti lasciati a se stessi convergono su un piccolo numero di fonti ad alta autorità. Questo è efficiente e sbagliato. Restringe la distribuzione tonale e analitica esattamente dove il livello di navigazione è destinato ad ampliarla. La nostra mitigazione è una metrica di diversità delle fonti per workspace, calcolata settimanalmente, con un soft floor. Quando la metrica scende, il ciclo indirizza i recuperi verso fonti sottorappresentate per la settimana successiva. È una piccola correzione, applicata continuamente, e ha mantenuto i workspace pilota lontani dall'attrattore di monocultura per l'intera finestra di osservazione.
Una pagina recuperata porta un timestamp, ma il contenuto della pagina potrebbe avere anni. Gli agenti tratteranno qualsiasi contenuto recuperato come recente a meno che non siano costretti a ragionarci sopra. La mitigazione è un campo 'data di estrazione' richiesto su qualsiasi recupero di categoria C o D, con l'estrazione stessa ricontrollata da un secondo passaggio. I recuperi che non possono risolvere una data estratta vengono declassati nel contesto dell'autore dell'ipotesi.
Le pagine pubbliche sono una superficie di input non attendibile. La mitigazione è standard ora, ma non era ovvia un anno fa: il contenuto recuperato non viene mai composto direttamente in un system prompt. Viene passato attraverso un parser che elimina le istruzioni, conservato come dati in uno slot di contesto separato, e l'agente viene invitato a trattarlo come prova su cui ragionare, non come direttive da seguire. Ogni workspace esegue settimanalmente una suite di iniezione di red team contro un pool rotante di pagine reali che gli agenti hanno recuperato.
Sei aree di lavoro, da otto a quattordici settimane ciascuna, livello di browsing abilitato su un 50% randomizzato degli slot di creazione di ipotesi e disabilitato sull'altro 50%. Il confronto è a livello di ipotesi, non a livello di esperimento, perché l'effetto del livello di browsing è a monte della selezione dell'esperimento.
La metodologia completa, la composizione della coorte e le variazioni per workspace sono nell'appendice distribuita agli operatori pilota. Pubblicheremo una versione anonima una volta che una seconda coorte sarà terminata nel Q3.
Il browsing layer non riduce il numero di persone coinvolte nel ciclo. Cambia ciò che fanno. Prima, la rara abilità dell'analista senior era l'autorialità dell'ipotesi stessa: sapere cosa chiedere a una data opportunità di ricavo. Dopo, la rara abilità è l'aggiudicazione dell'ipotesi: sapere quale delle ipotesi proposte dall'agente merita l'holdout. Questo è un lavoro genuinamente diverso, più vicino a un revisore scientifico che a un analista, e i workspace che hanno ottenuto il maggiore uplift sono stati quelli che hanno adeguato il personale per riflettere questo cambiamento.
Il valore del livello di navigazione non è che gli agenti possano leggere internet. Gli agenti sono in grado di leggere internet da anni. Il valore è che all'interno di un ciclo di decisioning con provenienza rigorosa, mitigazioni strutturali per la ricerca di conferma e misurazione randomizzata contro un holdout preservato, il contesto esterno diventa un input che può essere valutato rigorosamente come qualsiasi segnale di prima parte. Il web smette di essere una demo e diventa una fonte controllata di varianza nell'unica stazione del ciclo che è mai stata realmente limitata dall'immaginazione.
Per il modello operativo più ampio in cui questo si inserisce, vedi Dai calendari delle campagne al decisioning continuo. Per il modello di provenienza a cui si fa riferimento in tutto il documento, vedi Provenienza nel feed delle opportunità.
