Selezione del modello AI: come scegliere, testare, instradare e governare i modelli in produzione

La selezione del modello AI sembrava una scelta che si effettua una sola volta: scegli il modello più capace, inserisci il suo ID nel codice dell'applicazione e spedisci. Questo approccio si interrompe rapidamente nella produzione. Flussi di lavoro diversi richiedono livelli di qualità, finestre di contesto, modalità, profili di latenza, supporto di strumenti, regole di gestione dei dati e controlli dei costi diversi. Un modello eccellente per la revisione del codice può rivelarsi uno spreco per la classificazione. Un modello a basso costo che sembra interessante in termini di prezzo simbolico può diventare costoso se non supera la convalida, scrive risposte lunghe o attiva ripetute revisioni umane.

L'obiettivo pratico non è trovare un modello universale migliore. L'obiettivo è costruire un modello operativo ripetibile per la scelta, il test, l'instradamento, la sostituzione e il monitoraggio dei modelli tra i fornitori. Questo modello operativo dovrebbe consentire ai team di rispondere a domande di base con prove: quale modello è idoneo per questo carico di lavoro, quanto costa per attività riuscita, cosa succede se fallisce, chi è autorizzato a utilizzarlo e come eseguiamo la migrazione quando un fornitore cambia la disponibilità o ritira un modello precedente?

Per i team che utilizzano sistemi API di produzione, in particolare tra più fornitori, la selezione del modello diventa in parte decisione sul prodotto, in parte progettazione della piattaforma e in parte governance. Un gateway come Model Gate può aiutare con gli aspetti del piano di controllo: alias del modello, endpoint compatibili con OpenAI e Anthropic, visibilità dei prezzi, regole di accesso con chiave API, analisi dell'utilizzo, limiti di spesa, controlli del team e automazione dell'API dei partner. Non elimina la necessità di valutare la qualità del modello, ma può rendere più semplice esporre, limitare, osservare e modificare i modelli selezionati senza disperdere gli ID dei fornitori in ogni applicazione.

Inizia con il carico di lavoro, non con il nome del modello

Una buona selezione del modello di intelligenza artificiale inizia con la classificazione del lavoro. Un chatbot di supporto, un assistente di codifica, una pipeline di estrazione di documenti, un generatore di risposte RAG, un classificatore di moderazione, un flusso di lavoro di trascrizione, un generatore di immagini e un'interfaccia vocale in tempo reale non hanno gli stessi requisiti. Confrontandoli attraverso un'unica tabella di classificazione si nascondono le cose che contano nella produzione.

Per ciascun carico di lavoro, definire l'attività rivolta all'utente e i vincoli operativi. Un lavoro di riepilogo interno può tollerare diversi secondi di latenza se il risultato è accurato e poco costoso. Un flusso di lavoro di chat rivolto al cliente può richiedere output in streaming, comportamento di rifiuto prevedibile, bassa latenza di coda e fallback grazioso. Una pipeline di estrazione di documenti legali potrebbe richiedere un contesto lungo, una rigorosa aderenza allo schema JSON, una bassa tolleranza alle allucinazioni e attente regole di registrazione. Un agente di codifica potrebbe aver bisogno di chiamate a strumenti, contesto del repository, ragionamenti più lunghi e feedback sull'esecuzione dei test.

Questo approccio incentrato sul carico di lavoro trasforma la selezione del modello da un confronto tra marchi a un esercizio di requisiti. Prima di selezionare i candidati, scrivere il contratto di capacità: l'insieme minimo di caratteristiche che un modello o un percorso deve soddisfare prima di poter essere utilizzato. Il contratto dovrebbe includere dimensioni di input, dimensioni di output, modalità supportate, esigenze di output strutturato, chiamate di strumenti o funzioni, streaming, supporto batch, requisiti di sicurezza, obiettivo di latenza, limite di costo, vincoli di conservazione dei dati e compatibilità degli endpoint.

Definire un contratto di capacità

Un contratto di capacità è un pratico guardrail. Impedisce ai team di scambiare modelli basandosi solo sul prezzo o sui punteggi di riferimento quando la sostituzione non è effettivamente in grado di supportare il flusso di lavoro. Il contratto può essere semplice per un classificatore a basso rischio e dettagliato per un assistente regolamentato a contatto con il cliente.

Requisiti principali da acquisire

Come minimo, documenta la dimensione prevista della richiesta, la dimensione massima della risposta, il formato di output, l'utilizzo dello strumento e il budget di latenza. Per i flussi di lavoro RAG, includere requisiti di citazione, controlli di recupero e tolleranza per risposte incerte. Per le attività di estrazione, specificare le regole di convalida dello schema, i campi obbligatori e il modo in cui devono essere gestiti gli output parziali. Per i sistemi multimodali, registra se il flusso di lavoro necessita di input di immagini, output di immagini, audio, trascrizione, interazione in tempo reale o incorporamenti.

Non dare per scontato che la compatibilità dell'API significhi compatibilità delle funzionalità. Due fornitori possono accettare forme di richiesta simili pur differendo nel comportamento di output strutturato, nella semantica dello streaming, nelle chiamate agli strumenti, nella contabilità dei token, nei formati di errore, nei limiti di velocità e nelle politiche sui dati. Se la tua applicazione dipende da una funzionalità nativa del provider, registra tale dipendenza in modo esplicito. La portabilità è utile, ma non è gratuita.

Idoneità prima dell'ottimizzazione

La prima domanda di selezione è se un modello è idoneo. Solo dopo l'idoneità il team dovrà ottimizzare qualità, costi e velocità. Un modello con prezzi interessanti non è idoneo se non è in grado di adattarsi al contesto, di richiamare gli strumenti richiesti, di gestire la modalità, di soddisfare i requisiti di gestione dei dati o di produrre in modo affidabile la forma di output richiesta.

È qui che un gateway modello può aiutare a livello operativo. In Model Gate, i team possono esporre i modelli consentiti tramite chiavi API, ispezionare i metadati del modello tramite l'elenco dei modelli e gli endpoint dettagliati e instradare le richieste delle applicazioni tramite nomi stabili anziché ID provider codificati. Ciò supporta una configurazione API multi-modello regolamentata in cui l'accesso, la fatturazione e l'utilizzo del modello sono visibili in un unico posto.

Costruisci una matrice candidata

Una volta chiaro il contratto del carico di lavoro, crea una matrice dei candidati. Non è necessario che questo sia elaborato, ma dovrebbe essere sufficientemente esplicito da far sì che le decisioni sopravvivano ai cambiamenti del personale, agli annunci dei fornitori e alle revisioni del budget.

Per ciascun candidato, registrare l'ID del modello, il provider, il tipo di endpoint, la finestra di contesto, l'output massimo, le modalità supportate, il supporto dello strumento, il supporto dell'output strutturato, il supporto dello streaming, il supporto batch, i controlli del ragionamento o dello sforzo, le dimensioni dei prezzi, i limiti di velocità, i vincoli regionali, lo stato del ciclo di vita, i termini di gestione dei dati e le incompatibilità note. Includi l'alias o il profilo di produzione che punterebbe al modello se fosse approvato.

I cataloghi dei fornitori cambiano. Prezzi, nomi di modelli, finestre di contesto, limiti di output, stati del ciclo di vita e vincoli degli endpoint non sono sufficientemente stabili per essere codificati a tempo indeterminato. Una matrice dei candidati offre ai team della piattaforma e dell'applicazione una visione condivisa di ciò che è approvato, ciò che è in fase di valutazione, ciò che è legacy e ciò che deve essere ritirato.

Utilizza valutazioni specifiche per attività, non solo benchmark pubblici

I benchmark pubblici sono utili per la scoperta. Aiutano a identificare i candidati che potrebbero essere sufficientemente forti per una classe di compiti. Non dovrebbero costituire il test di accettazione finale per un flusso di lavoro di produzione. I suggerimenti reali sono più complicati dei suggerimenti dei benchmark. Includono istruzioni ambigue, vocabolario specifico del cliente, dati non corretti, input contraddittori, rumore nel recupero, contesto mancante e regole aziendali che una classifica generica non misura.

Inizia con un punto di riferimento di qualità. La linea di base può essere il modello di produzione attuale, un modello deliberatamente forte o un insieme di risultati attesi rivisti manualmente. Quindi valuta i candidati più economici, più veloci o più nuovi rispetto a casi rappresentativi. Includi esempi normali, casi limite, errori di alto valore ed esempi che in precedenza hanno causato incidenti o escalation.

Preferisci controlli deterministici ove possibile

Molte attività di produzione possono essere valutate in parte con controlli deterministici. Per l'estrazione strutturata, convalida lo schema JSON, i campi obbligatori, i valori enum, i formati delle date e i vincoli aziendali. Per la generazione del codice, esegui unit test, analisi statica o compilazione. Per la generazione SQL, convalidare la sintassi ed eseguirla rispetto a dispositivi di test sicuri. Per le risposte RAG, controlla la presenza di citazioni, il supporto della fonte citata e il comportamento di rifiuto quando mancano le prove.

La revisione umana e la valutazione basata su giudici modello sono ancora utili, ma dovrebbero essere utilizzate laddove i controlli deterministici non riescono a raggiungere il livello di qualità. Se viene utilizzato un giudice, calibrare la rubrica rispetto agli esempi noti buoni e cattivi. Senza calibrazione, i punteggi dei giudici del modello possono dare un falso senso di precisione.

Valuta le modalità di fallimento, non solo la qualità media

Il punteggio medio non è sufficiente. Il rischio di produzione spesso si trova nella coda: il modello che fallisce silenziosamente, inventa citazioni, restituisce JSON non valido sotto carico, ignora il risultato di uno strumento o produce una risposta non sicura per un piccolo ma importante gruppo di richieste. Tieni traccia del tasso di fallimento della convalida, del tasso di tentativi, del tasso di escalation, della qualità del rifiuto, dei modelli di allucinazioni, della distribuzione della latenza e del costo per output accettato.

Misura il costo per attività riuscita

Il prezzo per token è solo una parte del prezzo dell'API del modello AI. Un modello con token di input e output più economici può comunque costare di più se necessita di prompt più grandi, produce risposte più lunghe, non supera la convalida dello schema, richiede più tentativi, perde opportunità nella cache o invia più casi alla revisione umana. Al contrario, un modello più costoso può essere complessivamente più economico se risolve l'attività in un unico passaggio con istruzioni più brevi e meno correzioni.

Utilizza il costo per attività riuscita come principale parametro finanziario. Un'attività di successo è quella che soddisfa i criteri di accettazione del flusso di lavoro: output valido, qualità accettabile, entro il budget di latenza e nessuna correzione manuale oltre il processo previsto. Includi token di input, token di output, addebiti per ragionamento o impegno ove applicabile, chiamate a strumenti, costi di immagini o audio, effetti cache, sconti batch, nuovi tentativi, errori di convalida, escalation di supporto e costi di revisione umana quando incidono materialmente sul flusso di lavoro.

I team che gestiscono più applicazioni dovrebbero anche esporre agli sviluppatori i dati sui prezzi e sull'utilizzo. Model Gate pubblica informazioni su modelli e prezzi attraverso i suoi documenti e le superfici API, inclusi i campi dei prezzi specifici delle chiavi, ove pertinente. Per una revisione dettagliata dei prezzi, i team possono confrontare i candidati approvati con gli attuali prezzi dell'API del modello AI prima di promuovere un modello in un profilo di produzione.

Controlla la latenza come parte della selezione

La latenza non è solo una proprietà del provider. È modellato in base al modello selezionato, alle dimensioni del prompt, alla lunghezza dell'output, alla modalità di streaming, al comportamento dei nuovi tentativi, all'integrità del provider, ai limiti di velocità, alla regione, alle chiamate agli strumenti e alla post-elaborazione. Le indicazioni dei fornitori in genere rilevano che la scelta del modello e il conteggio dei token generati contribuiscono in modo determinante alla latenza di completamento, il che significa che la selezione del modello e il controllo dell'output sono inseparabili.

Imposta un budget di latenza per ciascun carico di lavoro. Per la chat interattiva, decidere quale latenza del primo token e la latenza della risposta completa sono accettabili. Per l'elaborazione in background, decidere se l'esecuzione batch è più importante del tempo di risposta immediato. Per i flussi di lavoro degli agenti, prendi in considerazione ogni chiamata allo strumento e cambio di modello anziché cronometrare solo la prima richiesta.

Quando confronti i candidati, normalizza le condizioni del test. Utilizza richieste comparabili, vincoli di output, impostazioni di streaming, livelli di concorrenza e criteri di ripetizione. Un test di latenza che consente a un modello di produrre 100 token e a un altro di produrre 1.000 token non misura la velocità del modello in modo corretto.

Utilizza alias e profili invece di ID modello codificati

L'hardcoding degli ID modello del provider nel codice dell'applicazione è uno degli errori più comuni nella selezione del modello. Rallenta la risposta alla deprecazione, crea un utilizzo incoerente tra i team e trasforma le modifiche del modello in distribuzioni di applicazioni. Un modello migliore consiste nell'utilizzare alias o profili modello rivolti all'applicazione.

Un alias è un nome stabile come support-fast, support-quality, coding-default, extract-json o batch-summary. Dietro l'alias, i proprietari della piattaforma possono aggiungere una versione del modello del fornitore, testare le sostituzioni, promuovere un nuovo candidato o eseguire il rollback dopo una regressione. L'applicazione richiede il contratto del carico di lavoro, non il nome commerciale del fornitore.

Le versioni del modello bloccato sono utili quando la riproducibilità è importante. Gli alias gestiti dal provider possono ricevere miglioramenti, ma possono anche introdurre variazioni di comportamento. La scelta giusta dipende dal flusso di lavoro. Un assistente creativo a basso rischio può trarre vantaggio dai miglioramenti gestiti dal fornitore. Una pipeline di estrazione regolamentata potrebbe richiedere un ID bloccato, un record di modifica e un gate di valutazione prima di qualsiasi migrazione.

Model Gate supporta gli alias dei modelli come meccanismo del piano di controllo, consentendo ai team di mantenere stabili i nomi rivolti alle applicazioni modificando al contempo il modello risolto dietro di essi. L'importante pratica di governance è trattare le modifiche dell'alias come modifiche della produzione: registrare il motivo, i carichi di lavoro interessati, i risultati della valutazione, il piano di implementazione e l'obiettivo del rollback.

Selezione del modello separata dal routing di fallback

Un modello di riserva non è semplicemente la seconda opzione più economica o più disponibile. Deve soddisfare lo stesso contratto di capacità o fallire chiaramente. Il fallback non sicuro può compromettere gli output strutturati, il comportamento degli strumenti, i presupposti del contesto, il comportamento di sicurezza, le norme sui dati o l'esperienza utente.

Separare la decisione di selezione dalla politica di routing. La selezione del modello determina quali modelli sono approvati per un carico di lavoro. Il routing determina quando utilizzare ciascun percorso approvato in base all'integrità del provider, alla latenza, ai limiti di velocità, alla politica del tenant, alle regole sui costi o alla risposta agli incidenti. Questa distinzione impedisce alla logica di disponibilità di modificare silenziosamente la semantica.

Ad esempio, un flusso di lavoro dell'assistenza clienti può avere un alias principale che punta a un modello di alta qualità e un alias di fallback che punta a un modello più veloce di un altro fornitore. Entrambi devono supportare la lunghezza del contesto richiesta, il comportamento dello streaming, le chiamate agli strumenti e le aspettative di sicurezza. Se nessun fallback soddisfa il contratto, il sistema dovrebbe restituire un chiaro motivo di errore anziché peggiorare in modo imprevedibile.

Implementa le modifiche al modello in più fasi

Le modifiche al modello dovrebbero seguire la stessa disciplina delle altre modifiche alla produzione. Un'implementazione tipica prevede cinque fasi: valutazione offline, traffico shadow ove appropriato, canary limitato, espansione monitorata e decisione di rollback. Il processo esatto dipende dal rischio, ma saltare direttamente dal confronto dei benchmark al traffico di produzione completo è raramente giustificato per flussi di lavoro importanti.

Le valutazioni offline stabiliscono se il candidato è plausibile. Il traffico ombra può confrontare gli output senza influire sugli utenti, sebbene le politiche sui dati sensibili possano limitare quando ciò è consentito. L'implementazione di Canary espone una piccola percentuale di utenti reali o tenant interni al nuovo modello. L'espansione monitorata aumenta il traffico solo se i parametri di qualità, latenza, costo ed errore rimangono entro i limiti.

I criteri di rollback dovrebbero essere definiti prima dell'implementazione. Gli esempi includono il tasso di errore di convalida superiore alla soglia, la regressione p95 della latenza, l'aumento del costo per attività riuscita, l'aumento dell'escalation del supporto, i modelli di reclamo degli utenti o specifiche modalità di errore di elevata gravità. Senza criteri predefiniti, i team tendono a discutere le regressioni mentre gli utenti le stanno già sperimentando.

Piano per deprecazioni e pensionamenti

La gestione del ciclo di vita dei modelli fa parte della governance dei modelli di intelligenza artificiale. I fornitori possono contrassegnare i modelli come attivi, legacy, deprecati o ritirati. Quando un modello ritirato smette di accettare richieste, le applicazioni che ancora dipendono da esso possono fallire immediatamente. Il rischio è maggiore quando gli ID modello sono sparsi tra servizi, lavori, notebook e configurazioni specifiche del tenant.

Conserva un runbook sulla deprecazione. Dovrebbe coprire il monitoraggio degli avvisi del fornitore, l'inventario di utilizzo, gli alias interessati, le chiavi API interessate, i proprietari di aziende, i candidati sostitutivi, i requisiti di valutazione, le scadenze di migrazione, la comunicazione con l'inquilino, le fasi di implementazione e l'attribuzione della fatturazione. L'analisi dell'utilizzo è essenziale in questo caso: prima di sostituire un modello, i team devono sapere chi lo utilizza, con quale frequenza, attraverso quali chiavi, a quale costo e per quali flussi di lavoro.

Un gateway aiuta centralizzando l'accesso al modello e i record di utilizzo. Invece di cercare un ID provider in ogni repository, i team possono verificare quali alias e chiavi si risolvono in un modello interessato ed eseguirne la migrazione deliberata.

Gestisci l'accesso, i budget e la proprietà

Con l'aumento dell'utilizzo dei modelli, le decisioni di selezione necessitano del controllo degli accessi. Non a tutti i team, tenant o ambienti dovrebbe essere consentito di utilizzare tutti i modelli. Alcuni modelli potrebbero essere troppo costosi per l'accesso predefinito. Alcuni potrebbero essere approvati solo per dati interni. Alcuni potrebbero richiedere regole di registrazione più rigide o l'attivazione da parte del cliente. Alcuni potrebbero non essere disponibili in determinate regioni o non adatti a carichi di lavoro regolamentati.

La governance inizia con la proprietà. Ogni alias o profilo di produzione deve avere un proprietario, una descrizione del carico di lavoro, tenant o chiavi consentiti, aspettative di budget, comportamento di fallback approvato e una cadenza di revisione. Le regole di accesso dovrebbero essere applicate a livello di chiave API o di tenant, ove possibile, e non solo secondo le convenzioni degli sviluppatori. Per implementazioni sensibili, collega l'accesso al modello con pratiche di gestione delle chiavi API più ampie in modo che credenziali, autorizzazioni, limiti di spesa e audit trail siano gestiti in modo coerente.

Per i creatori, le agenzie o i rivenditori SaaS, gli stessi principi si applicano a tutti gli account dei clienti. L'automazione in stile partner può fornire chiavi tenant, assegnare modelli consentiti, applicare limiti di spesa e attribuire l'utilizzo senza esporre le credenziali del fornitore ai clienti finali. Ciò è particolarmente importante quando i clienti hanno budget, esigenze di conformità o regole di disponibilità dei modelli diversi.

Monitora l'utilizzo reale dopo l'implementazione

Nessuna suite di valutazione è in grado di prevedere completamente il comportamento della produzione. Dopo l'implementazione, monitora l'utilizzo reale per tenant, chiave, flusso di lavoro, alias, modello risolto, percorso del provider, utilizzo del token, latenza, errori, costi ed eventi di fallback. Mantieni un'attribuzione sufficiente per spiegare gli incidenti e le domande di chargeback. Se è consentita la registrazione tempestiva, campionare attentamente e oscurare i dati sensibili dove necessario. Se la registrazione tempestiva non è consentita, l'osservabilità dei soli metadati è comunque preziosa.

I parametri di produzione utili includono volume delle richieste, tasso di output accettato, errori di convalida, nuovi tentativi, tasso di fallback, errori del provider, errori di limite di velocità, latenza del primo token, latenza della risposta completa, token di input, token di output, costo per attività, spesa per chiave e distribuzione del modello per flusso di lavoro. Per i sistemi rivolti agli utenti, combina le metriche tecniche con gli indicatori del prodotto come percentuali di mancata risposta, riassegnazioni di supporto, abbandono o tempo di correzione manuale.

Il monitoraggio dovrebbe alimentare il ciclo di selezione successivo. Un modello che sembrava migliore nelle valutazioni offline potrebbe essere troppo lento in condizioni di concorrenza reale. Un modello più economico può far risparmiare denaro per un tenant e fallire per un altro perché la forma dei dati è diversa. Un percorso di fallback può essere utilizzato raramente ma costoso quando viene attivato. Il modello operativo dovrebbe rendere questi risultati visibili e utilizzabili.

Errori comuni nella selezione del modello IA

Il primo errore è scegliere dai benchmark di marketing senza testare suggerimenti reali. I benchmark aiutano a selezionare i modelli, ma l'accettazione della produzione dovrebbe dipendere da dati rappresentativi e dai costi di fallimento.

Il secondo errore è ottimizzare il prezzo del token ignorando il costo totale dell'attività. Nuovi tentativi, output lunghi, chiamate a strumenti, errori di convalida, cache mancate, comportamento batch e revisione umana possono invertire la classifica apparente.

Il terzo errore è considerare una lunga finestra di contesto come un sostituto del recupero, del riepilogo e della progettazione dei prompt. Un contesto lungo può essere prezioso, ma può anche aumentare i costi e la latenza seppellendo le prove pertinenti.

Il quarto errore è utilizzare alias gestiti dai provider ovunque senza monitorare le derive comportamentali o preservare gli obiettivi di rollback. Gli alias dei provider sono convenienti, ma i flussi di lavoro critici spesso richiedono versioni bloccate e migrazioni controllate.

Il quinto errore è lasciare che il fallback ignori il contratto di capacità. Un fallback che non può produrre il JSON richiesto, utilizzare gli strumenti richiesti, soddisfare la politica sui dati o adattarsi al contesto non è un fallback sicuro.

Il sesto errore è non riuscire a registrare l'alias richiesto, il modello risolto, il percorso del fornitore, la versione del prezzo, l'utilizzo del token, la latenza e lo stato di errore. Senza tale attribuzione, gli incidenti e le controversie sulla fatturazione diventano congetture.

Un pratico flusso di lavoro di selezione

Un flusso di lavoro duraturo può essere semplice. Inventaria l'utilizzo corrente per applicazione, endpoint, tenant, chiave API, flusso di lavoro, famiglia di prompt, costo, latenza, errori e proprietario dell'azienda. Definire classi di carico di lavoro e contratti di capacità. Costruisci una matrice candidata. Stabilire una base di qualità. Esegui valutazioni specifiche dell'attività. Misura il costo per attività riuscita. Scegli deliberatamente i modelli aggiunti o gli alias dei fornitori. Esporre gli alias di produzione alle applicazioni. Definire le regole di fallback. Stendere in più fasi. Monitora l'utilizzo reale. Esamina i deprecamenti e le modifiche ai prezzi in base a un programma.

Questo flusso di lavoro trasforma la selezione del modello in una pratica ripetibile della piattaforma anziché in una serie di decisioni una tantum. Offre ai team applicativi contratti stabili, al settore finanziario e operativo una migliore visibilità dei costi, offre limiti di accesso più chiari alla sicurezza e offre ai team di prodotto un modo più sicuro per migliorare la qualità nel tempo.

Conclusione

La selezione del modello di intelligenza artificiale non significa più solo scegliere un LLM capace. In produzione, il modello selezionato influisce su affidabilità, latenza, fatturazione, conformità, esperienza utente e risposta agli incidenti. La decisione migliore è specifica per il carico di lavoro e basata sull'evidenza: definire il contratto di capacità, testare i candidati su dati rappresentativi, misurare il costo per attività riuscita, controllare l'implementazione e monitorare l'utilizzo reale dopo l'implementazione.

Per i sistemi multi-provider, il modello più forte è quello di mantenere le applicazioni puntate su alias o profili stabili mentre i proprietari della piattaforma gestiscono modelli approvati, percorsi di fallback, regole di accesso, controlli della spesa e modifiche del ciclo di vita dietro le quinte. Model Gate si inserisce in quel modello operativo come gateway e piano di controllo per esporre modelli tramite API compatibili, gestire chiavi e team, visualizzare utilizzo e prezzi e modificare l'accesso al modello senza trasformare ogni decisione sul modello in una riscrittura dell'applicazione.