Integra Gemini e Chrome Summarizer in un assistente React

Per un assistente React, usa Chrome Summarizer per aiutare la persona a leggere il brief e riserva a una richiesta separata al backend la proposta di Gemini. Mantieni il testo originale e applica le modifiche solo dopo la revisione: così il riepilogo locale non avvia da sé una richiesta cloud e una proposta non diventa automaticamente una modifica salvata.

In questa guida

• Due azioni di IA, tre passaggi controllabili
• Quali dispositivi supporta la documentazione di Chrome
• Gestire disponibilità, annullamento e testi lunghi
• Associare la proposta alla bozza corrente
• Rivedere le modifiche prima di salvarle
• Che cosa coprono gli otto controlli riferiti

Due azioni di IA, tre passaggi controllabili

Il flusso descritto da Raju Dandigam per Trip Workbench separa tre operazioni:

1. Riassumere localmente. Chrome Summarizer elabora il brief originale sul dispositivo e restituisce testo da consultare. Chrome afferma che, durante l’uso del modello integrato, i dati non vengono inviati a Google o a terze parti.
2. Chiedere una proposta a Gemini. È un’azione distinta: il brief originale viene inviato al backend dell’applicazione, che gestisce la richiesta cloud. Il riepilogo locale non sostituisce questo passaggio.
3. Rivedere e applicare. L’app presenta la proposta e la persona decide se applicarla tramite il normale percorso di aggiornamento del backend. Nel flusso di Trip Workbench, salvare la bozza è separato dall’invio e non prenota il viaggio.

Il modello integrato richiede una connessione non a consumo per il download iniziale; dopo il download può essere usato senza rete. La dichiarazione di Chrome sulla trasmissione dei dati riguarda l’uso di quel modello, non la richiesta separata a Gemini né le altre comunicazioni dell’applicazione.

Quali dispositivi supporta la documentazione di Chrome

La pagina di Chrome Summarizer, aggiornata il 30 luglio 2025, indica Chrome 138 stabile come versione di partenza e specifica i requisiti riportati qui. Sono condizioni della documentazione pubblicata in quella data, non una verifica in tempo reale del dispositivo.

La documentazione citata esclude Android, iOS e i dispositivi ChromeOS che non sono Chromebook Plus dalle API dei modelli di base trattate nella pagina. Se la funzione locale è essenziale per l’app, considera questi requisiti prima di renderla un passaggio necessario del flusso. Consulta la documentazione di Chrome Summarizer.

Gestire disponibilità, annullamento e testi lunghi

Prima di creare una sessione, chiama Summarizer.availability() con le stesse opzioni previste per Summarizer.create(). Chrome documenta gli stati available, downloadable, downloading e unavailable. Se serve scaricare il modello, la creazione richiede un’attivazione dell’utente: mostra lo stato e avvia il passaggio in risposta a un’interazione, anziché trattare il download come un’operazione silenziosa.

Per interrompere anche una creazione ancora in corso, MDN documenta l’opzione signal di Summarizer.create(). Se il segnale viene annullato prima che la promessa di creazione si risolva, la creazione viene cancellata. Se viene annullato dopo, l’istanza viene rilasciata e le chiamate al Summarizer rifiutano con AbortError. La documentazione MDN descrive il comportamento di signal.

Non fissare nel codice un numero universale di token. MDN specifica che inputQuota dipende dall’implementazione; dopo aver creato la sessione, puoi leggere quella proprietà e usare measureInputUsage() per controllare il testo concreto. MDN documenta la quota e la misura dell’input.

Se il testo supera la quota, Chrome suggerisce di dividerlo in segmenti seguendo paragrafi o argomenti, riassumere ogni segmento e poi riassumere i risultati combinati. La procedura può essere ripetuta, ma più passaggi di sintesi possono ridurre l’accuratezza e aumentare la latenza. Mantieni disponibile il testo originale: il riepilogo dei riepiloghi è un compromesso, non una copia completa del contenuto. Chrome spiega come gestire finestre di contesto ridotte.

Associare la proposta alla bozza corrente

Una proposta cloud può arrivare dopo che la persona ha modificato il brief o la bozza. Per evitare di applicare un risultato non più attuale, Trip Workbench tiene traccia dell’identità di bozza e sessione, della revisione salvata, della versione delle modifiche locali e di quella del brief. Il flusso descritto controlla che il risultato sia ancora valido quando termina l’elaborazione e di nuovo al momento dell’applicazione.

La risposta di Gemini va trattata come un candidato, non come dati già validi per il dominio dell’app. Nell’implementazione descritta, l’adattatore richiede JSON ma non invia uno schema di output; l’applicazione analizza e convalida la risposta prima di usarla. Conservare questa separazione permette di rifiutare una risposta non valida senza trasformarla in una modifica della bozza.

Rivedere le modifiche prima di salvarle

Dopo i controlli di validità e aggiornamento, la persona deve poter decidere se applicare la proposta. In Trip Workbench, l’azione di applicazione passa dal normale percorso di modifica del backend: non invia il viaggio e non lo prenota. Il pulsante di applicazione, quindi, corrisponde al salvataggio della bozza, non alla conferma di un’azione esterna.

Che cosa coprono gli otto controlli riferiti

Raju Dandigam riferisce otto controlli controllati del ciclo di vita eseguiti con un Summarizer fittizio. Nel suo adattatore candidato osserva tre problemi: un errore di availability() non veniva gestito, una richiesta già annullata poteva comunque creare una sessione e la chiamata di creazione non riceveva il segnale di annullamento.

Questi controlli riguardano il comportamento del codice con un sostituto del modello. Dandigam specifica che l’estensione React non era stata montata né verificata con il type-checker; i controlli non stabiliscono il comportamento del modello nativo, la qualità dei riepiloghi, le prestazioni o i payload di rete.