No, i modellini piccoli non sono l'"Opzione di bilancio" (Italiano (Italian))

No, i modellini piccoli non sono l'"Opzione di bilancio"

Sunday, 28 December 2025

//

8 minute read

I LLMs piccoli e locali sono spesso inquadrati come l'alternativa economica ai modelli di frontiera. Quell'inquadratura è sbagliata. Non sono una versione degradata della stessa cosa. Sono una scelta architettonica diversa, selezionata per controllo, prevedibilità, e modalità di guasto sopravvivebile.

Sono colpevole come chiunque altro per aver spinto la narrazione 'sono liberi'... come se fosse l'unico fattore decisivo. Ma come scegliere una piattaforma di database / hosting per un sistema che devi capire Che compromessi stai facendo?.

Utilizzando un piccolo modello via OllamaCity name (optional, probably does not need a translation), LM Studio, ONNX Runtime, o simili non è (solo) di risparmiare denaro. Si tratta di scegliere dove il non-determinismo è consentito di esistere.

La differenza reale: modalità di guasto

I grandi modelli di frontiera sono più ampi e fluenti. Essi densificano più della logica umana espressa, abbracciano più domini, e producono tracce di ragionamento più convincenti. più pericoloso nei sistemi che richiedono garanzie.

I modelli Frontier hanno senso quando l'ampiezza è richiesta e le uscite sono consultive dal design - stesura creativa, esplorazione aperta, o sintesi in domini sconosciuti. Ma non è la maggior parte dei sistemi di produzione.

I loro fallimenti sono semantico piuttosto che strutturale. Questo è l'errore di categoria: trattando una componente probabilistica come se fosse un limite di sistema. Generano uscite dall'aspetto valido che sono sbagliate in modi sottili. Questi fallimenti sono:

  • Costoso da rilevare
  • Costoso per il debug
  • Spesso visibile solo dopo che il danno è fatto

I piccoli modelli falliscono in modo diverso.

Quando un piccolo modello è confuso, tende a:

  • Rompere gli schemi
  • Emit JSON non valido
  • Tronca gli output
  • Perdere traccia della struttura

Questi sono fallimenti a buon mercato. Sono rilevabili con semplice validazione. Attivano ritriti o ripiegamenti immediatamente. Non avanzano silenziosamente stato.

Questa non e' una debolezza, e' una caratteristica.

Da dove viene questo principio

Questa intuizione non è teoria astratta - è il fondamento della Dieci comandamenti di utilizzo di LLM. Il principio fondamentale:

I LLM interpretano la realtà e non devono mai essere autorizzati a definirla.

Quando si segue questo principio, si scopre qualcosa di sorprendente: smetti di aver bisogno di modelli costosi. Un modello di parametro 7B che funziona localmente può classificare, riassumere e generare ipotesi semplicemente bene - perché i sistemi deterministici intorno a esso gestiscono tutto ciò che effettivamente deve essere corretto.

I piccoli modelli non sono "deboli" - sono spesso sufficiente perché il problema è già stato ridotto nel momento in cui li raggiunge.

I modelli di frontiera stanno vendendo l'affidabilità si dovrebbe costruire te stesso.

Il modello mentale destro

Proprio come DuckDB non è "a buon mercato SQL" e Postgres non è "peggiore Azure SQL," piccoli LLM occupano un punto diverso nello spazio di progettazione. Li scegli quando:

Presupposto Vantaggio per il modello piccolo
Località Corre sul vostro hardware, la vostra rete, la vostra giurisdizione
Verificabilità Ogni inferenza è registrata, riproducibile, ispezionabile
Raggio di scoppio I guasti sono contenuti, non propagati attraverso catene API
Applicazione della correttezza La convalida avviene al di fuori del modello
Non-determinismo confinato L'incertezza è strettamente limitata

Come uso questo in pratica

Questo non è ipotetico. I miei progetti dimostrano questo schema ripetutamente:

GraphRAG con tre modalità di estrazione

La mia implementazione di GraphRAG offre tre modalità:

Modo Chiamate LLM Migliore per
Euristico 0 per pezzo Determinismo puro via IDF + struttura
Ibrido 1 per documento Il modello piccolo convalida i candidati
LLM 2 per pezzo Qualità massima quando necessario

La modalità ibrida è il punto dolce: l'estrazione euristica trova candidati (deterministic), poi un piccolo modello locale li convalida e li arricchisce. Una chiamata LLM per documento, non per pezzo.

Con Ollama in esecuzione localmente, il costo è di $0. Ma non è per questo che lo uso - risparmi di costo sono un effetto collaterale di corretta astrazione, non l'obiettivo. Io lo uso perché i fallimenti sono economici e ovvi.

ONNX Embeddings: No LLM required

Ricerca semantica con ONNX e Qdrant mostra un altro modello: alcune attività non hanno bisogno di un LLM. BERT embeddings via ONNX Runtime dare:

  • Inferenza CPU-friendly - nessuna GPU richiesta
  • Risultati deterministici - lo stesso input produce sempre la stessa inserzione
  • Esecuzione locale - nessuna chiamata API, nessuna latenza, nessun limite di velocità
  • ~90MB modello - corre ovunque

Per ricerca ibridaIl LLM appare solo al momento della sintesi - e anche allora, un piccolo modello locale funziona bene perché è spiegazione struttura che i sistemi deterministici hanno già convalidato.

DocSummarizer: Struttura Prima, LLM Seconda

DocSummarizer Incarna questa filosofia:

  1. Parsa documenti con librerie deterministiche (OpenXML, Markdig)
  2. ChunkCity name (optional, probably does not need a translation) contenuto che utilizza regole strutturali (ruote, paragrafi, blocchi di codice)
  3. Incorpora pezzi con ONNX BERT
  4. Recupera parti rilevanti attraverso la ricerca vettoriale
  5. Sintesi con Ollama - l'unico passo probabilistico

La LLM è la ultimo passo, lavorando su contenuti pre-convalidati e pre-strutturati. Può fallire - e quando lo fa, il fallimento è evidente perché la struttura è già corretta.

TinyLLM: Chat locale con i confini

TinyLLMCity name (optional, probably does not need a translation) dimostra l'utilizzo locale di LLM in un'app desktop Windows. Supporta:

  • Backend Ollama
  • Caricamento diretto del modello GGUF
  • Memoria RAG (con recupero deterministico)

L'interfaccia chat è probabilistica. La memoria, la gestione dei file e la gestione dello stato sono deterministiche. Il fallimento in uno non corrompe l'altro.

Le tre questioni

I modelli Frontier sono strumenti potenti quando utilizzati deliberatamente, ma aumentano la potenza espressiva più velocemente di quanto riducano il rischio. I modelli piccoli, quando incorporati all'interno di sistemi deterministici, danno sufficiente incertezza da esplorare - senza oscurare la verità o la responsabilità.

La domanda giusta non è "quale modello è migliore?"

È:

  1. Dove deve essere la probabilita'?
  2. Dove deve essere assoluto il determinismo?
  3. Quali fallimenti possono sopravvivere a questo sistema?

Se la risposta comporta stato, effetti collaterali, denaro, politica, o garanzie - il modello non dovrebbe mai essere responsabile. E se il modello è solo lì per classificare, riassumere, rango, o proporre ipotesi, un piccolo modello locale è spesso il scelta correttaNon quella economica.

Il modello: macchinario di noia + piccolo modello

Questa è l'architettura che funziona:

┌─────────────────────────────────────────────────────┐
│                 DETERMINISTIC LAYER                 │
│  State machines, queues, validation, storage        │
│  (DuckDB, Postgres, Redis, file systems)           │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                   INTERFACE LAYER                   │
│  Schema validation, retries, fallbacks             │
│  (Polly, FluentValidation, custom guards)          │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│                  PROBABILISTIC LAYER                │
│  Classification, summarisation, hypothesis gen     │
│  (Ollama, ONNX, small local models)                │
└─────────────────────────────────────────────────────┘

L'LLM è al fondo, non la parte superiore. Si propone; gli strati deterministici si disfano.

Affidabilità non è di evitare il fallimento

Tutte e tre le prospettive - le domande, il modello, e questo principio finale - riducono alla stessa regola:

Affidabilità è di scegliere i fallimenti si può sopravvivere.

Con i LLM, ciò significa gestire il non-determinismo attraverso pratiche deterministiche:

Piccoli modelli rendono questo più facile perché i loro fallimenti sono forte. JSON non valido. Produzione troncata. Violazioni dello schema. Questi sono regali - ti dicono immediatamente che qualcosa è andato storto.

I fallimenti del modello di frontiera sono tranquillo- Sciocchezze incredibili, allucinazioni sicure, deriva semantica che diventa visibile solo quando un cliente si lamenta o un audit fallisce.

Prendero' ogni volta dei forti fallimenti.

Lettura correlata

La filosofia

L'attuazione

L'architettura

Risorse esterne

Finding related posts...
logo

© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.