Decider V1.1 27B è il checkpoint decisionale aggiornato di Perplexity. Valuta i contenuti forniti rispetto a una domanda definita e produce probabilità sulle risposte valide. Il suo artefatto nativo dispone di una testa di lettura decisionale anziché di una testa di generazione linguistica sull'intero vocabolario. Il risultato utile è una distribuzione decisionale vincolata e la sua risposta interpretata, non una spiegazione aperta o una risposta di chat generica.
Perplexity identifica questo modello come un aggiornamento di Decider V1 27B che mantiene la stessa rete di base, con modifiche alla configurazione dell'attenzione e più dati di addestramento. La sua rete di base è Qwen3.8-27B. L'edizione V1.1 deve mantenere il proprio nome e la propria configurazione invece di essere descritta come una copia intercambiabile del checkpoint precedente.
L'esempio pubblicato fornisce una riga contenente uno stato e una domanda di scelta tipizzata. La domanda include istruzioni e criteri le cui chiavi sono le risposte semantiche e le cui descrizioni definiscono quando si applica ciascuna. Il modello prevede le probabilità, poi la funzione di risposta del produttore interpreta tali probabilità per la domanda. L'esempio di inferenza può elaborare un elenco di righe, con una decisione legata alle prove e alla domanda di ciascuna riga.
Per l'instradamento delle richieste, fornisci il messaggio effettivo e il contesto pertinente, quindi definisci i reparti o le categorie disponibili. Un'attività illustrativa potrebbe distinguere un errore di integrazione, un problema di accesso e una richiesta di informazioni sul prodotto. Rendi ogni descrizione abbastanza precisa da risolvere un caso limite e conserva le definizioni delle opzioni insieme al risultato. Una distribuzione per categorie può quindi supportare una decisione di instradamento o una fase di revisione quando le alternative restano vicine. Il risultato scelto dal modello non esegue di per sé l'azione del flusso di lavoro.
L'implementazione nativa accetta immagini insieme allo stato e alla domanda, tramite file immagine, immagini in memoria o dati immagine codificati. Per l'immagine di un documento o una schermata, fornisci la prova visiva e poni una domanda chiusa le cui opzioni descrivano gli esiti pertinenti. Indica la caratteristica visibile rilevante e fornisci il contesto testuale necessario per interpretarla. Ad esempio, classifica se un articolo raffigurato appartiene a una delle categorie di prodotto fornite, invece di chiedere al modello decisionale di scrivere una descrizione completa del prodotto.
Il processore mantiene le proporzioni durante il ridimensionamento e arrotonda i lati dell'immagine a multipli di 32 pixel. L'area elaborata documentata parte da 65.536 pixel ed è limitata da un massimo configurabile; il valore predefinito è 4.194.304 pixel, ovvero 2048 per 2048. Ogni riquadro di 32 per 32 contribuisce con un token visivo, quindi il valore predefinito consente fino a 4.096 token visivi per immagine. Questi valori descrivono la preparazione nativa delle immagini del produttore, non un contratto generale di caricamento per le applicazioni.
La fase di preparazione documentata richiede che il testo e tutte le immagini di una decisione rientrino in 8.192 token. Un input troppo grande viene rifiutato anziché troncato silenziosamente. Più immagini condividono questo budget con lo stato scritto e la domanda. Riduci il testo di origine irrilevante o il limite di dimensione delle immagini quando prepari una decisione combinata, mantenendo il dettaglio che determina la risposta.
La configurazione di addestramento e di valutazione riportata limitava le immagini a 512 per 512, corrispondenti a 262.144 pixel e fino a 256 token visivi. Il limite configurabile in inferenza può conservare più dettagli, ma la scheda avverte che una risoluzione più alta è al di fuori di quella distribuzione di addestramento e richiede più memoria e tempo di elaborazione. Un'impostazione di immagine più grande non garantisce quindi una decisione migliore. Mantieni la preparazione dell'input coerente con la domanda e verifica che la caratteristica visiva necessaria sia rappresentata chiaramente.
I livelli ad attenzione completa del checkpoint nativo usano una modalità di attenzione non causale salvata, mentre i livelli ad attenzione lineare mantengono il proprio comportamento. Il produttore afferma che l'inferenza causale predefinita non riproduce la configurazione valutata. La sua implementazione della previsione applica la temperatura di calibrazione salvata; se si usano direttamente i logit, tale temperatura viene applicata una sola volta e le probabilità vengono normalizzate sui candidati validi correnti. Questi dettagli appartengono all'esatto profilo decisionale e vanno preservati quando si interpretano i suoi output numerici.
La testa di lettura decisionale separata distingue inoltre questo artefatto da un'esportazione generativa. Una conversione verso un'interfaccia di generazione basata sul vocabolario richiede una mappatura esplicita e deve preservare il comportamento dell'attenzione. Prepara domande chiuse per il profilo decisionale nativo; usa un modello di generazione adatto quando l'attività richiede chat, codice, spiegazioni o richieste di strumenti.
Un artefatto finale utile mantiene associati lo stato, la domanda, le risposte consentite e la distribuzione risultante. Definisci la domanda in base alle prove effettivamente presenti, esamina i casi ambigui rispetto a tali prove e usa esempi etichettati dell'attività prevista per decidere come gli output numerici debbano influire sull'instradamento o sulla classificazione. Il modello fornisce probabilità decisionali; i criteri e l'applicazione circostante determinano come tali probabilità diventino un'azione utile o un'etichetta registrata.
", "aboutText": "Decider V1.1 27B è il checkpoint decisionale aggiornato di Perplexity. Valuta i contenuti forniti rispetto a una domanda definita e produce probabilità sulle risposte valide. Il suo artefatto nativo dispone di una testa di lettura decisionale anziché di una testa di generazione linguistica sull'intero vocabolario. Il risultato utile è una distribuzione decisionale vincolata e la sua risposta interpretata, non una spiegazione aperta o una risposta di chat generica.\n\n### Cosa cambia nell'edizione V1.1\n\nPerplexity identifica questo modello come un aggiornamento di Decider V1 27B che mantiene la stessa rete di base, con modifiche alla configurazione dell'attenzione e più dati di addestramento. La sua rete di base è Qwen3.8-27B. L'edizione V1.1 deve mantenere il proprio nome e la propria configurazione invece di essere descritta come una copia intercambiabile del checkpoint precedente.\n\n### Stato, domanda e risposte valide\n\nL'esempio pubblicato fornisce una riga contenente uno stato e una domanda di scelta tipizzata. La domanda include istruzioni e criteri le cui chiavi sono le risposte semantiche e le cui descrizioni definiscono quando si applica ciascuna. Il modello prevede le probabilità, poi la funzione di risposta del produttore interpreta tali probabilità per la domanda. L'esempio di inferenza può elaborare un elenco di righe, con una decisione legata alle prove e alla domanda di ciascuna riga.\n\nPer l'instradamento delle richieste, fornisci il messaggio effettivo e il contesto pertinente, quindi definisci i reparti o le categorie disponibili. Un'attività illustrativa potrebbe distinguere un errore di integrazione, un problema di accesso e una richiesta di informazioni sul prodotto. Rendi ogni descrizione abbastanza precisa da risolvere un caso limite e conserva le definizioni delle opzioni insieme al risultato. Una distribuzione per categorie può quindi supportare una decisione di instradamento o una fase di revisione quando le alternative restano vicine. Il risultato scelto dal modello non esegue di per sé l'azione del flusso di lavoro.\n\n### Prove testuali e visive\n\nL'implementazione nativa accetta immagini insieme allo stato e alla domanda, tramite file immagine, immagini in memoria o dati immagine codificati. Per l'immagine di un documento o una schermata, fornisci la prova visiva e poni una domanda chiusa le cui opzioni descrivano gli esiti pertinenti. Indica la caratteristica visibile rilevante e fornisci il contesto testuale necessario per interpretarla. Ad esempio, classifica se un articolo raffigurato appartiene a una delle categorie di prodotto fornite, invece di chiedere al modello decisionale di scrivere una descrizione completa del prodotto.\n\nIl processore mantiene le proporzioni durante il ridimensionamento e arrotonda i lati dell'immagine a multipli di 32 pixel. L'area elaborata documentata parte da 65.536 pixel ed è limitata da un massimo configurabile; il valore predefinito è 4.194.304 pixel, ovvero 2048 per 2048. Ogni riquadro di 32 per 32 contribuisce con un token visivo, quindi il valore predefinito consente fino a 4.096 token visivi per immagine. Questi valori descrivono la preparazione nativa delle immagini del produttore, non un contratto generale di caricamento per le applicazioni.\n\n### Limiti dell'input combinato e ambito della risoluzione\n\nLa fase di preparazione documentata richiede che il testo e tutte le immagini di una decisione rientrino in 8.192 token. Un input troppo grande viene rifiutato anziché troncato silenziosamente. Più immagini condividono questo budget con lo stato scritto e la domanda. Riduci il testo di origine irrilevante o il limite di dimensione delle immagini quando prepari una decisione combinata, mantenendo il dettaglio che determina la risposta.\n\nLa configurazione di addestramento e di valutazione riportata limitava le immagini a 512 per 512, corrispondenti a 262.144 pixel e fino a 256 token visivi. Il limite configurabile in inferenza può conservare più dettagli, ma la scheda avverte che una risoluzione più alta è al di fuori di quella distribuzione di addestramento e richiede più memoria e tempo di elaborazione. Un'impostazione di immagine più grande non garantisce quindi una decisione migliore. Mantieni la preparazione dell'input coerente con la domanda e verifica che la caratteristica visiva necessaria sia rappresentata chiaramente.\n\n### Attenzione, testa di lettura e calibrazione delle probabilità\n\nI livelli ad attenzione completa del checkpoint nativo usano una modalità di attenzione non causale salvata, mentre i livelli ad attenzione lineare mantengono il proprio comportamento. Il produttore afferma che l'inferenza causale predefinita non riproduce la configurazione valutata. La sua implementazione della previsione applica la temperatura di calibrazione salvata; se si usano direttamente i logit, tale temperatura viene applicata una sola volta e le probabilità vengono normalizzate sui candidati validi correnti. Questi dettagli appartengono all'esatto profilo decisionale e vanno preservati quando si interpretano i suoi output numerici.\n\nLa testa di lettura decisionale separata distingue inoltre questo artefatto da un'esportazione generativa. Una conversione verso un'interfaccia di generazione basata sul vocabolario richiede una mappatura esplicita e deve preservare il comportamento dell'attenzione. Prepara domande chiuse per il profilo decisionale nativo; usa un modello di generazione adatto quando l'attività richiede chat, codice, spiegazioni o richieste di strumenti.\n\nUn artefatto finale utile mantiene associati lo stato, la domanda, le risposte consentite e la distribuzione risultante. Definisci la domanda in base alle prove effettivamente presenti, esamina i casi ambigui rispetto a tali prove e usa esempi etichettati dell'attività prevista per decidere come gli output numerici debbano influire sull'instradamento o sulla classificazione. Il modello fornisce probabilità decisionali; i criteri e l'applicazione circostante determinano come tali probabilità diventino un'azione utile o un'etichetta registrata.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "a665f4933cf00957bf483581b04fa542a417903d81fdec7df0a01a585bb2a6ed", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "it", "methods": [ { "html": "perplexity/pplx-decider-v1.1-27bDecider V1.1 27B di Perplexity valuta uno stato e una domanda forniti e restituisce probabilità sulle risposte consentite. Il suo checkpoint decisionale nativo supporta testo e immagini, con una testa di lettura dedicata e limiti documentati per la preparazione dell'input, anziché un contratto di generazione di testo in forma libera.
Questa descrizione illustra le funzionalità del modello. Gli input, gli output e le opzioni disponibili in Ailoot per il metodo selezionato sono elencati di seguito.
Decider V1.1 27B è il checkpoint decisionale aggiornato di Perplexity. Valuta i contenuti forniti rispetto a una domanda definita e produce probabilità sulle risposte valide. Il suo artefatto nativo dispone di una testa di lettura decisionale anziché di una testa di generazione linguistica sull'intero vocabolario. Il risultato utile è una distribuzione decisionale vincolata e la sua risposta interpretata, non una spiegazione aperta o una risposta di chat generica.
Perplexity identifica questo modello come un aggiornamento di Decider V1 27B che mantiene la stessa rete di base, con modifiche alla configurazione dell'attenzione e più dati di addestramento. La sua rete di base è Qwen3.8-27B. L'edizione V1.1 deve mantenere il proprio nome e la propria configurazione invece di essere descritta come una copia intercambiabile del checkpoint precedente.
L'esempio pubblicato fornisce una riga contenente uno stato e una domanda di scelta tipizzata. La domanda include istruzioni e criteri le cui chiavi sono le risposte semantiche e le cui descrizioni definiscono quando si applica ciascuna. Il modello prevede le probabilità, poi la funzione di risposta del produttore interpreta tali probabilità per la domanda. L'esempio di inferenza può elaborare un elenco di righe, con una decisione legata alle prove e alla domanda di ciascuna riga.
Per l'instradamento delle richieste, fornisci il messaggio effettivo e il contesto pertinente, quindi definisci i reparti o le categorie disponibili. Un'attività illustrativa potrebbe distinguere un errore di integrazione, un problema di accesso e una richiesta di informazioni sul prodotto. Rendi ogni descrizione abbastanza precisa da risolvere un caso limite e conserva le definizioni delle opzioni insieme al risultato. Una distribuzione per categorie può quindi supportare una decisione di instradamento o una fase di revisione quando le alternative restano vicine. Il risultato scelto dal modello non esegue di per sé l'azione del flusso di lavoro.
L'implementazione nativa accetta immagini insieme allo stato e alla domanda, tramite file immagine, immagini in memoria o dati immagine codificati. Per l'immagine di un documento o una schermata, fornisci la prova visiva e poni una domanda chiusa le cui opzioni descrivano gli esiti pertinenti. Indica la caratteristica visibile rilevante e fornisci il contesto testuale necessario per interpretarla. Ad esempio, classifica se un articolo raffigurato appartiene a una delle categorie di prodotto fornite, invece di chiedere al modello decisionale di scrivere una descrizione completa del prodotto.
Il processore mantiene le proporzioni durante il ridimensionamento e arrotonda i lati dell'immagine a multipli di 32 pixel. L'area elaborata documentata parte da 65.536 pixel ed è limitata da un massimo configurabile; il valore predefinito è 4.194.304 pixel, ovvero 2048 per 2048. Ogni riquadro di 32 per 32 contribuisce con un token visivo, quindi il valore predefinito consente fino a 4.096 token visivi per immagine. Questi valori descrivono la preparazione nativa delle immagini del produttore, non un contratto generale di caricamento per le applicazioni.
La fase di preparazione documentata richiede che il testo e tutte le immagini di una decisione rientrino in 8.192 token. Un input troppo grande viene rifiutato anziché troncato silenziosamente. Più immagini condividono questo budget con lo stato scritto e la domanda. Riduci il testo di origine irrilevante o il limite di dimensione delle immagini quando prepari una decisione combinata, mantenendo il dettaglio che determina la risposta.
La configurazione di addestramento e di valutazione riportata limitava le immagini a 512 per 512, corrispondenti a 262.144 pixel e fino a 256 token visivi. Il limite configurabile in inferenza può conservare più dettagli, ma la scheda avverte che una risoluzione più alta è al di fuori di quella distribuzione di addestramento e richiede più memoria e tempo di elaborazione. Un'impostazione di immagine più grande non garantisce quindi una decisione migliore. Mantieni la preparazione dell'input coerente con la domanda e verifica che la caratteristica visiva necessaria sia rappresentata chiaramente.
I livelli ad attenzione completa del checkpoint nativo usano una modalità di attenzione non causale salvata, mentre i livelli ad attenzione lineare mantengono il proprio comportamento. Il produttore afferma che l'inferenza causale predefinita non riproduce la configurazione valutata. La sua implementazione della previsione applica la temperatura di calibrazione salvata; se si usano direttamente i logit, tale temperatura viene applicata una sola volta e le probabilità vengono normalizzate sui candidati validi correnti. Questi dettagli appartengono all'esatto profilo decisionale e vanno preservati quando si interpretano i suoi output numerici.
La testa di lettura decisionale separata distingue inoltre questo artefatto da un'esportazione generativa. Una conversione verso un'interfaccia di generazione basata sul vocabolario richiede una mappatura esplicita e deve preservare il comportamento dell'attenzione. Prepara domande chiuse per il profilo decisionale nativo; usa un modello di generazione adatto quando l'attività richiede chat, codice, spiegazioni o richieste di strumenti.
Un artefatto finale utile mantiene associati lo stato, la domanda, le risposte consentite e la distribuzione risultante. Definisci la domanda in base alle prove effettivamente presenti, esamina i casi ambigui rispetto a tali prove e usa esempi etichettati dell'attività prevista per decidere come gli output numerici debbano influire sull'instradamento o sulla classificazione. Il modello fornisce probabilità decisionali; i criteri e l'applicazione circostante determinano come tali probabilità diventino un'azione utile o un'etichetta registrata.
POST /v1/systemonetext, imagedecisions| Campo | Tipo | Requisito | Valori e limiti | Predefinito |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObbligatorio | Valori e limiti perplexity/pplx-decider-v1.1-27b | Predefinito— |
Campoprovider | Tiposchema | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campoquestions | Tipoobject | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Camposession_id | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campostate | Tiposchema | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campotrace | Tiposchema | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campouser | Tipostring | RequisitoFacoltativo | Valori e limiti | Predefinito— |
Campoquestions.<id>.type | Tipostring | RequisitoObbligatorio | Valori e limiti noul, choice, score | Predefinito— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti | Predefinito— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoFacoltativo | Valori e limiti Condizioni: choice/score: obbligatori; noul: facoltativo. I criteri di choice sono un oggetto; score è un array con minItems1. | Predefinito— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti Si applica quando: Oggetto criteria noul fornito | Predefinito— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObbligatorio | Valori e limiti Si applica quando: Oggetto criteria noul fornito | Predefinito— |
noul · Obbligatorio: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obbligatorio: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obbligatorio: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parametro | Contratto |
|---|---|
Parametrocontent_type | Contrattoapplication/json |
Parametrorequired | Contrattomodel, state, questions |
Parametromaterial_types | Contrattotext, image |
Parametrooptional_controls | Contrattoprovider, session_id, trace, user |
Parametromultimodal_input_binding | ContrattoUsa esclusivamente la rappresentazione esatta dichiarata per lo stato o il documento. La sola capacità del produttore di elaborare immagini non stabilisce una modalità accettata di trasmissione delle immagini specifica del modello. |
Ciclo di vita: synchronous
Invia l'ID esatto del modello e conserva l'intera risposta nativa.
Le tariffe non aggiungono opzioni alla richiesta. I parametri supportati sono elencati nel metodo selezionato.
Associa ogni costo alle condizioni indicate. Usa una sola tariffa per ogni insieme di configurazioni alternative.
| Configurazione | Listino delle tariffe | Token di contesto, più di | Token di contesto, fino al limite incluso | Costo |
|---|---|---|---|---|
| ConfigurazioneTariffe di base dei token | Listino delle tariffeTariffa base | Token di contesto, più di— | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.00004 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
| ConfigurazioneFascia 1 di lunghezza della richiesta | Listino delle tariffe— | Token di contesto, più di0 | Token di contesto, fino al limite inclusoNessun limite superiore | Costo Input · Token in input $0.00004 / 1K token Output · Token in output $0 / 1K token Input · Lettura dalla cache — / 1K token Input · Scrittura nella cache — / 1K token Input · Scrittura nella cache, 1 ora — / 1K token |
Ailoot prenota un importo stimato prima di una richiesta. Dopo il risultato, addebita il costo finale in base all’utilizzo misurato. Per lo streaming, l’addebito usa il record finale di utilizzo. Come funzionano la prenotazione e l’addebito finale →
{\n "model": "perplexity/pplx-decider-v1.1-27b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='perplexity/pplx-decider-v1.1-27b'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Conserva ogni risposta, file e parte di contenuto restituiti per intero.
Viene conservata ogni risposta associata all'ID della domanda fornito, con il tipo esatto, il valore noul/choice/score, la confidenza, le probabilità e la legenda. L'intero JSON originale viene memorizzato e restituito solo dopo il conguaglio dell'addebito.
Conserva l'operazione originale e la risposta completa o parziale; non ripetere POST.
| Campo | Tipo |
|---|---|
Campomodel | Tipostring |
Campoid | Tipostring |
Campoprovider | Tipostring |
Campoanswers.<id>.type | Tipostring |
Campoanswers.<id>.noul | Tiponumber |
Campoanswers.<id>.choice | Tipostring |
Campoanswers.<id>.score | Tiponumber |
Campoanswers.<id>.confidence | Tiponumber |
Campoanswers.<id>.probabilities | Tipoobject |
Campoanswers.<id>.legend | Tipoobject |
Campousage.input_tokens | Tipointeger |
Campousage.output_tokens | Tipointeger |
Campousage.cost | Tiponumber |
| Risposta | Condizione | Passaggio successivo |
|---|---|---|
Risposta400 · invalid_request_error | CondizioneCampo obbligatorio, rappresentazione o valore non valido | Passaggio successivoCorreggi il campo della richiesta indicato. |
Ailoot Ultra perplexity/pplx-decider-v1.1-27b
Usa i percorsi dei metodi indicati sopra.