Community per il team open. Pro per la scala produttiva.

Pro integra EuLLM come backend di generazione di default: uno stack di inferenza LLM sovrano europeo costruito attorno a pesi GGUF, con continuous batching e finestra di contesto da 16K token. Ollama resta disponibile come profilo di fallback per la valutazione.

• Continuous batching per throughput elevato su host single-GPU
• Context window da 16K token per contratti lunghi, trascrizioni e report
• Completamente air-gapped: modalità HuggingFace offline, nessuna chiamata casa
• Compatibile con Mistral 7B (made in France) e altri modelli GGUF

La pure vector search manca i match keyword precisi; il puro BM25 manca la semantica. Pro li esegue entrambi, li fonde con Reciprocal Rank Fusion e riordina il risultato con un cross-encoder.

• Vector + BM25 con bilanciamento lessicale-semantico configurabile
• Cross-encoder reranking per precisione sui top-K
• Multi-query expansion per domande ambigue
• Analytics di query su ogni step della pipeline

Pro non si limita a indicizzare i documenti — estrae entità, eventi e importi in un database relazionale normalizzato. Quel database diventa una sorgente di fatti verificati che la pipeline di chat può citare con provenance.

• Schema a sei tabelle: extraction jobs, entities, events, amounts, progress, document summaries
• Colonne indicizzate e foreign key — le query analitiche sono veloci
• SQLite con WAL oggi; portabile a PostgreSQL quando serve scalare
• Quattro profili di dominio: Generic, Intelligence/OSINT, Medical, Legal
• Validazione Pydantic con recovery automatico per JSON LLM malformati
• Ogni fatto estratto è linkato al chunk sorgente per audit

Un piccolo classifier decide a runtime se la domanda è aggregate, semantica o ibrida — poi la indirizza al backend giusto e compone la risposta.

• Domande aggregate (count, elenca, group-by, filtri per data) → warehouse SQL
• Domande semantiche ("perché", "come", "spiega") → vector retrieval
• Domande ibride ricevono entrambi: i fatti SQL iniettati nel prompt LLM come "dati verificati", i chunk recuperati come contesto
• Deterministico, trasparente, ispezionabile per ogni richiesta

L'estrazione è un job pesante. Pro la coordina con le persone che stanno effettivamente usando il sistema, invece di rompere l'esperienza di chat.

• Orario di esecuzione configurabile (default 20:00); polling ogni 60 secondi
• Gli utenti connessi ricevono una notifica WebSocket prima dell'avvio
• Conferma adesso, oppure rinvia — fino a 3 volte, 15 minuti l'una
• Switch dinamico del modello durante l'estrazione: la chat passa da 14B a 8B per liberare VRAM, poi torna su
• Checkpoint per documento: si riprende senza ripartire da zero

Lasci un file in una cartella sorvegliata e finisce sia nell'indice vettoriale sia in coda di estrazione. L'admin panel dà agli operatori un'unica console.

• Folder watcher per ingestion batch — niente step di upload manuale
• Pipeline OCR estesa per moduli compilati a mano, scansioni multi-colonna e fax di qualità bassa
• Resource monitoring (CPU, memoria, GPU) integrato in UI
• Service control: riavvia i componenti dall'admin panel
• Dashboard dei job di estrazione con stato, errori e rerun manuale
• UI di configurazione per scheduler, retention e selezione modello

Community tiene un archivio giornaliero coerente — database applicativo e snapshot vettoriale presi insieme — ma lo tiene come file locale, sullo stesso host della cosa che sta proteggendo. È un buon backup e una pessima strategia di disaster recovery. Pro lo manda altrove, su base schedulata, con una politica di retention.

• Copie schedulate verso lo storage che già usi: object storage S3-compatibile, WebDAV / Nextcloud, SFTP, FTP, Backblaze B2
• Politiche di retention, così gli archivi vecchi scadono da soli invece di riempire il volume
• Restore selettivo — recuperi database, indice vettoriale o documenti sorgente in modo indipendente
• Le credenziali della destinazione vengono conservate offuscate, mai in chiaro
• Gli endpoint di backup e restore sono riservati agli amministratori, con protezione da path traversal in fase di estrazione
• Il database viene copiato a caldo: nessun fermo servizio e nessuno snapshot scritto a metà