Caso studio: costruire per Beyond Tabs un sistema di raccolta dati dai portali carriere basato sul browser
Beyond Tabs non sta cercando di indicizzare ogni offerta di lavoro su Internet.
La scelta è intenzionalmente più stretta: un sito curato per lavori legati a linguaggi di programmazione di nicchia e comunità tecniche adiacenti. Questo rende più interessante il problema della raccolta dei dati. Un risultato utile non è semplicemente “questa azienda ha offerte di lavoro”. È “questa fonte potrebbe contenere lavori rilevanti per il tipo di persone che visitano Beyond Tabs”.
La sfida attuale è il flusso sui portali carriere. Centinaia di aziende hanno portali carriere. Alcune usano sistemi ATS noti. Alcune espongono una pagina con marchio proprio sopra una piattaforma condivisa. Alcune sono siti personalizzati con pochi link. Alcune sono aggregatori da saltare. Alcune rivelano la vera struttura solo dopo l’esecuzione di JavaScript, la chiusura di un banner consenso, il superamento di un filtro per età o il completamento di un reindirizzamento specifico per paese.
È il tipo di lavoro per cui Guida è stato costruito.
Il problema non era solo estrarre dati
Se ogni azienda usasse lo stesso ATS, la soluzione sarebbe lineare. Rilevi la piattaforma, chiami la sua API, normalizzi i risultati e vai avanti.
Il web reale non funziona così.
In una sessione di smistamento, un report carriere conteneva centinaia di portali divisi in categorie ampie: copertura ATS nota, flussi di lavoro aziendali dedicati, siti generici sconosciuti e aggregatori da ignorare. Il gruppo “generico sconosciuto” era quello scomodo. Conteneva di tutto, da piccole pagine carriere statiche a piattaforme globali di recruiting aziendale nascoste dietro URL con marchio proprio.
Un URL da solo non bastava. Alcuni esempi anonimizzati dal lavoro di smistamento:
- Un marchio di largo consumo sembrava avere un URL carriere proprietario, ma dopo un filtro per età mostrava una bacheca SuccessFactors/jobs2web.
- Un’azienda di tecnologia industriale mostrava un sito carriere Oracle HCM sotto un dominio carriere con marchio proprio.
- Un’organizzazione di ricerca mostrava una pagina aziendale rifinita, ma i link alle posizioni andavano a Lever.
- Una società di market intelligence incorporava un widget lavori BambooHR.
- Un’azienda di trading energetico elencava lavori sulla propria pagina, ma i link di dettaglio andavano a HR-ON.
- Una grande impresa esponeva una ricerca carriere personalizzata con migliaia di risultati e pagine di dettaglio specifiche per prodotto.
Queste distinzioni contano perché decidono che tipo di raccolta dati va costruita. Una piattaforma condivisa dovrebbe diventare infrastruttura riutilizzabile. Un sito proprietario personalizzato richiede un processo di lavoro specifico per l’azienda. Un aggregatore va ignorato. Un problema nei dati sorgente va corretto prima che qualcuno scriva codice.
Perché WebView2 ha cambiato il flusso di lavoro
La scorciatoia allettante è classificare tutto con richieste HTTP ed euristiche sugli URL.
Sarebbe stato più veloce. Sarebbe anche stato abbastanza spesso sbagliato da far perdere tempo più avanti.
Guida usa WebView2 come interfaccia di automazione, quindi agente e utente ispezionano la stessa realtà del browser. Le pagine vengono visualizzate con un normale motore browser. JavaScript viene eseguito. I banner cookie appaiono. I reindirizzamenti avvengono. L’utente può autorizzare domini quando serve. L’agente può ispezionare il DOM risultante, link visibili, script e URL finale dalla scheda attiva invece di indovinare dall’HTML grezzo.
Per questo caso studio, il ciclo di lavoro è diventato:
- Partire dal report dei gap del sistema di raccolta.
- Scegliere i prossimi portali non classificati dallo spazio di archiviazione dello spazio di lavoro.
- Riutilizzare quattro schede del browser.
- Applicare layout quad e viewport Full HD.
- Navigare ogni scheda verso una pagina carriere reale.
- Ispezionare contenuto visualizzato, link, script, iframe e indizi di piattaforma.
- Salvare un risultato strutturato indicizzato dalla chiave del portale.
- Continuare con il gruppo successivo.
Il punto non era l’autonomia completa. Il punto era automazione supervisionata. L’utente poteva vedere esattamente quali pagine erano aperte, dove la navigazione si fermava e se l’agente stava classificando la cosa giusta.
Lo spazio di archiviazione è diventato la memoria di lavoro
La prima versione delle note di smistamento viveva in file di testo. Non è durata.
Appena il lavoro ha iniziato a coprire centinaia di portali e più sessioni, le note dovevano diventare dati interrogabili. Lo spazio di archiviazione dello spazio di lavoro di Guida è diventato la memoria di lavoro del processo.
Il report del sistema di raccolta è stato importato in una raccolta indicizzata da un identificatore stabile del portale. I risultati basati sul browser sono stati salvati in una raccolta separata, usando lo stesso identificatore e uno schema coerente. Questo ha reso facile rispondere a domande come:
- Quali portali sono ancora da smistare?
- Quali sono piattaforme condivise?
- Quali richiedono processi di raccolta personalizzati?
- Quali risultati derivano da dati osservati nel browser attivo?
- Cosa ha visto l’agente quando ha preso la decisione?
Questo ha cambiato il carattere del lavoro. Invece di chiedere all’agente di ricordare dove si era fermato, il processo poteva riprendere dai dati.
Il registro conta perché la raccolta dati è lavoro operativo
La raccolta dei dati dai portali carriere non è uno script una tantum. È un flusso di lavoro.
I portali mettono in coda URL di offerte. I processi di fetch visitano pagine. I processi di parse estraggono e indicizzano annunci. Alcuni elementi completano. Alcuni vengono saltati perché esiste già un risultato noto. Alcuni falliscono temporaneamente. Alcuni finiscono nella coda degli scarti. Alcune prese in carico scadono e richiedono ripristino.
È per questo che il registro di tracciabilità dei flussi di lavoro è diventato importante. Un flusso di raccolta senza visibilità operativa lascia l’utente a indovinare. Il registro dà a Guida un posto dove spiegare cosa è successo: esecuzioni, elementi, stati, fasi, tentativi, errori e risultati collegati.
Questa pressione ha poi portato al lavoro dedicato sulla console del registro di tracciabilità dei flussi di lavoro. Per Beyond Tabs, l’utente non dovrebbe chiedersi se la raccolta dati ha finito, è bloccata, sta riprovando o si è rotta in silenzio. L’applicazione dovrebbe mostrarlo direttamente.
Cosa Guida ha fatto bene
Guida ha reso il lavoro ispezionabile.
Il layout a quattro pannelli permetteva all’utente di guardare quattro siti reali alla volta. Il pannello cronologia MCP mostrava le chiamate agli strumenti. Il pannello Archiviazione (Store) mostrava risultati strutturati. Le schede del browser mostravano le pagine effettivamente visualizzate. Questa combinazione è più utile di un flusso di log senza interfaccia grafica, perché l’utente può intervenire quando il web si comporta come il web.
Guida ha anche reso il lavoro riprendibile. Una volta spostati i risultati nello spazio di archiviazione dello spazio di lavoro, i gruppi potevano continuare tra sessioni diverse senza affidarsi alla memoria conversazionale o a note modificate manualmente.
Soprattutto, Guida ha mantenuto l’agente ancorato ai fatti. L’agente non classificava pagine a sensazione o su assunzioni stantie. Guardava dati mostrati dal browser e annotava perché la classificazione era stata fatta.
Cosa deve ancora migliorare
Non è stato un processo privo di attrito.
La navigazione può ancora segnalare errore anche quando la pagina è stata caricata, quindi il flusso di lavoro richiede controlli successivi con URL corrente e DOM. Anche il ciclo di smistamento a quattro schede merita un controllo di livello più alto: “prepara questo gruppo, mantieni queste schede in vista quad e mantieni stabile il layout” dovrebbe essere un’operazione di prima classe invece di una sequenza di chiamate più basse a schede e layout.
Richieste di consenso ed elenchi di domini autorizzati procedono al ritmo umano, ed è corretto così, ma l’interfaccia deve rendere chiare autorizzazioni in attesa e pagine bloccate. Quella lezione di prodotto ha già iniziato a comparire in Guida: il centro di autorizzazione MCP rende visibili le richieste in attesa, e le console dedicate per flussi di lavoro e code spostano il ripristino operativo fuori da pannelli laterali troppo stretti.
Sono problemi di prodotto, non motivi per abbandonare l’approccio. La scommessa di base continua a sembrare giusta: un browser reale, dati visibili, dati strutturati nello spazio di lavoro e uso verificabile degli strumenti IA.
La lezione
La raccolta dati di Beyond Tabs è esattamente il tipo di problema che sta tra navigazione manuale ed estrazione industriale dei dati.
Richiede automazione, ma non automazione cieca. Richiede assistenza IA, ma non un agente invisibile libero di girare sul web. Richiede flussi di dati, ma anche giudizio umano. Deve scalare, ma solo dopo che le classificazioni sono affidabili.
Il ruolo di Guida è rendere pratico quello spazio intermedio.
Per Beyond Tabs, significa usare un flusso di lavoro basato sul browser per decidere quali processi di raccolta costruire, quali piattaforme condivise supportare, quali fonti saltare e quali errori richiedono attenzione. Per Guida, è un caso studio reale sul perché automazione del browser visibile, locale e supervisionata sia diversa dall’ennesimo strumento di estrazione dati senza interfaccia grafica.
L’obiettivo di lungo periodo è semplice: gli utenti non dovrebbero sentirsi al buio mentre l’automazione gira. Dovrebbero poter vedere il browser, ispezionare i dati di tracciamento, fidarsi dei dati salvati e comprendere il flusso.
È la direzione di prodotto che questo caso studio sta aiutando a validare.