Puntata 233 — La filiera open: dataset → modello → app

Livello: 🧙 Maestro Yoda · Capitolo 21 · Open source e HuggingFace

Le ultime 10 puntate sono state pezzi sparsi. Adesso li mettiamo insieme: un singolo stack che parte da un dataset crudo e arriva a un prodotto live, tutto in open source. Niente API closed, niente lock-in. È più lavoro? Sì. È fattibile? Tantissime startup nel 2026 lo fanno.

una catena di montaggio a sei stazioni con nomi: “DATASET → PRETRAIN → SFT/DPO → QUANT → SERVE → APP”. A ogni stazione un piccolo cartello “100% open source”. Sotto, un cliente in giacca prende il prodotto finito. Sotto: “made in HuggingFace, deployed in Italy”

Lo stack canonico open 2026

[Data layer]      Common Crawl, FineWeb, The Stack, dataset propri
                       ↓
[Pretraining]     OLMo trainer / GPT-NeoX / Megatron-LM (raro, costoso)
                       ↓
[Base model]      Llama / Mistral / Qwen / DeepSeek / Gemma (riusi, non pretraini tu)
                       ↓
[Fine-tuning]     trl / unsloth / axolotl + LoRA / DPO / SFT
                       ↓
[Quantization]    llama.cpp (GGUF) / autoawq / autogptq
                       ↓
[Inference]       vLLM / TGI / Ollama / LM Studio
                       ↓
[Orchestration]   LangChain / LlamaIndex / Haystack / vanilla Python
                       ↓
[App layer]       FastAPI / Next.js / Streamlit / Gradio
                       ↓
[Observability]   Langfuse / OpenLLMetry / Helicone / Phoenix

Tutto questo è open source o open weight. Tutto. Zero dipendenza da OpenAI o Anthropic API.

Caso pratico: un’app di Q&A legale italiana

Ipotesi: piccolo studio legale vuole un chatbot interno che risponda a domande dei clienti su contrattualistica B2B italiana, con cite alle norme.

1. Data layer

Pubblici: Codice Civile italiano (gazzettaufficiale.it, dominio pubblico), giurisprudenza Cassazione (italgiurecms.giustizia.it), Gazzetta Ufficiale.
Proprietari: 5,000 Q&A storiche dello studio (anonimizzate).
Sintetici: 2,000 Q&A generate con Qwen2.5-72B (open) sui template di Q&A reali.

Dataset finale: 7,000 esempi SFT in italiano + corpus normativo per RAG.

Storage: HF Datasets repo privato (mio-studio/legal-qa-it-v1).

2. Pretraining

Salti. Pretrainare from scratch un modello competitivo costa decine di milioni di euro e mesi di lavoro. Non fattibile per uno studio legale.

Usi il pretraining già fatto da qualcun altro: scegli Llama-3.1-8B-Instruct come base (buon italiano, license commerciale, sweet spot di taglia per QLoRA su laptop GPU).

3. Fine-tuning

LoRA QLoRA 4-bit su una 4090 24GB o su Colab Pro+:

Stack: unsloth + trl SFTTrainer.
r=32, lora_alpha=64, all proj.
LR 2e-4, 2 epoche, batch effettivo 32.
Tempo: ~3-5 ore.

Output: adapter LoRA ~150 MB.

Eval: il tuo eval set (500 Q&A held-out) + MMLU-it sample (check no regression). Pass rate atteso: 75-82% sulle Q&A specifiche, vs 60-65% base.

4. Quantization

Merge LoRA → modello full 8B BF16 (~16 GB) → GGUF Q4_K_M (~4.9 GB).

python convert_hf_to_gguf.py merged-model --outfile model.f16.gguf
./llama-quantize model.f16.gguf model-q4_k_m.gguf Q4_K_M

5. Inference

Sul server dello studio (PC con 4090, ~€2,000 di hardware una tantum):

Ollama carica il GGUF.
API REST OpenAI-compatible su porta 11434.
30-40 tok/s decode su 4090.

Per scaling (più di 5 utenti concorrenti): passa a vLLM con la versione AWQ.

6. Orchestration

L’app non è solo “modello → risposta”. Serve:

RAG sul corpus normativo (vedi puntata 238): retrieval dei 5 articoli più rilevanti per ogni domanda, iniettati nel prompt.
Embedding model: sentence-transformers/multilingual-e5-large (open, ottimo per italiano) per i 5,000 chunk di Codice Civile.
Vector DB: pgvector dentro un Postgres esistente o Qdrant standalone (entrambi open).
Pipeline: LlamaIndex o LangChain, oppure 100 righe Python pure.

Flusso per ogni query:

Embed la query.
Top-5 retrieval da Qdrant.
Inject in prompt template (“Basandoti su questi articoli: …”).
Chiama il modello via Ollama API.
Restituisci la risposta + cite agli articoli.

7. App layer

Backend: FastAPI + Pydantic per validazione. Frontend: Next.js semplice con useChat (Vercel AI SDK funziona contro endpoint OpenAI-compatible) oppure Streamlit per MVP. Auth: Auth0 (managed) o Authelia (self-hosted). Deploy: Docker Compose sul server studio.

8. Observability

Langfuse self-hosted o Phoenix (Arize) open source.
Logging di ogni request (prompt, retrieval, response, latency, user feedback).
Eval set rilanciato settimanalmente per regression.
Sample human review settimanale di 50 risposte.

Costi totali (stima realistica)

Voce	Costo una tantum	Mensile
Hardware server (4090 PC)	€2,500	—
Annotazione dataset (interno, 5,000 Q&A)	€5,000	—
Training (Colab Pro+, 3 mesi)	€100	—
Setup & integrazione (consulente o tempo interno)	€5,000-15,000	—
Maintenance	—	€200-500
Energia + connettività	—	€30-80
Totale anno 1	~€12,000-25,000	+ ~€3,000/anno

Confronto: una API enterprise di un provider closed per gli stessi volumi (50 utenti, 200 query/giorno medie) sarebbe ~€500-2,000/mese a regime. Break-even tipico: 12-24 mesi.

Ma il vero valore dell’open stack non è il costo: è la data sovereignty (i dati dei clienti restano on-premise) e la non-dipendenza (nessuno può aumentare i prezzi o cambiare i TOS senza preavviso).

Cosa rende difficile (e quindi raro) l’all-open stack

Lo facevano in pochi pre-2024 perché:

Modelli open non erano competitivi. Risolto da Llama 3, Qwen, DeepSeek.
Tooling era acerbo. Risolto da vLLM, Ollama, unsloth, llama.cpp.
Quantizzazione degradava troppo. Risolto da AWQ, Q4_K_M, QAT.
RAG era artigianale. Risolto da LlamaIndex/LangChain maturi.
Observability era inesistente. Risolto da Langfuse, Phoenix, Helicone.

Stato 2026: lo stack open è production-ready. Le motivazioni a non usarlo sono:

Skill team (richiede comunque competenze tecniche superiori a “uso API”).
Hardware iniziale (server, GPU, sysadmin).
Velocità di iterazione (se sei una startup early-stage, API closed sono più veloci per pivotare).

Le 4 architetture comuni 2026

A) All-managed

OpenAI / Anthropic API + Pinecone + Vercel. Velocissimo da setup, costoso a scala, zero sovereignty.

B) Hybrid (most common)

Frontier API closed (per task hard) + open small model self-hosted (per task semplici, ad alto volume) + RAG self-hosted. Riduce costi 50-80%.

C) All-open self-hosted

Tutto il nostro stack del caso d’uso sopra. Massima sovereignty, max effort.

D) All-open managed

Open weight models ma serviti da provider (Together, Fireworks, Deepinfra, Replicate). Stack open ma operations gestita. Compromesso intelligente: niente lock-in (puoi cambiare provider) + niente devops pesante.

Per le PMI italiane nel 2026, la D è spesso la scelta saggia: usi meta-llama/Llama-3.1-70B-Instruct su Together AI a $0.30 per milione di token, ma se aumentano i prezzi puoi migrare a Fireworks o self-hosted senza riscrivere niente (stesso API OpenAI-compatible).

La filiera è un grafo, non una linea

In pratica:

Stesso dataset può addestrare 3 modelli diversi.
Stesso modello può servire 10 app diverse.
Stessa app può chiamare 3 modelli in cascata (router intelligente).
Stesso vector DB può servire embeddings di 5 fonti diverse.

L’arte dell’AI engineering 2026 è comporre questi componenti, non scrivere niente di nuovo da zero. Quasi tutto esiste. Il valore aggiunto sta nei tuoi dati e nel tuo prompt/dominio.

Glossario lampo

Stack — composizione coordinata di layer (data, model, serving, app) per produrre un’applicazione AI.
Data sovereignty — proprietà tecnica + legale di tenere i dati nel proprio perimetro (on-premise o nazionale). Cruciale per AI Act high-risk.
Embedding model — modello specializzato che produce vector representations per retrieval. Diverso e più piccolo dell’LLM generativo.
All-open managed — quarta architettura: modelli open + provider managed (Together, Fireworks). Niente lock-in, niente devops pesante.

Take-away

Nel 2026 puoi costruire un prodotto AI competitivo end-to-end in tutto open: dataset → fine-tune → quant → serve → app → monitor. È più lavoro che chiamare l’API di OpenAI? Sì, ~2-5×. È più economico a scala? Anche di 10×. Ti dà controllo, sovranità del dato, indipendenza? Totale. La domanda non è più “se è possibile” ma “se vale la pena per il tuo caso d’uso”. Per molte PMI italiane: sempre più sì.

➡️ Prossima puntata: TEST — deploy di un mini-modello in uno Space gratis, end-to-end in 30 minuti.