Il router di Eldric classifica ogni query in una classe di intento prima di scegliere dove instradarla. La piattaforma include 128 classi predefinite (11 intenti principali + 117 sotto-domini scientifici). Per i workflow in cui le classi predefinite non portano le distinzioni giuste — un ospedale potrebbe volere una classe "PatientTriage", uno studio legale una classe "ContractReview", uno stabilimento una classe "AnomalyTrend" — Eldric supporta classi personalizzate a livello di tenant. Due strade: addestrare un classificatore overlay, oppure ricadere su un LLM con la tua tassonomia.
Quando fai una domanda, il router fa passare la query prima attraverso un piccolo classificatore — un singolo passaggio neurale che restituisce un'etichetta di classe e un punteggio di confidenza. La classe determina quale worker gestisce la richiesta, quali basi di conoscenza vengono cercate, quale modello viene scelto, e se la cascata prova prima i pesi appresi / matrix memory / RAG / fonti live.
Le classi predefinite coprono le forme top-level più ovvie: chat semplice, query RAG, invocazione di agent, richiesta swarm, store/recall di memoria, operazione sui dati, query scientifica, richiesta media, richiesta comm, richiesta di training, richiesta IoT — più i 117 sotto-domini scientifici per genomica / fisica delle particelle / clima / ecc. Le classi personalizzate stanno accanto a queste, con la stessa semantica di routing; estendono la tassonomia invece di sostituirla.
La strada di alta qualità. Fornisci esempi etichettati — qualche centinaio di query per ogni nuova classe, ciascuna taggata con la classe desiderata — ed Eldric addestra un overlay sopra il classificatore di base. L'addestramento è locale (i tuoi dati non lasciano il cluster), richiede minuti su una piccola GPU e produce un file classificatore .enrn per tenant che il router carica accanto a quello di base.
Il flusso:
{"query": "...", "class": "ContractReview"}./api/v1/router/custom-classes/train con il tuo tenant id. Il training worker (porta 8898) esegue la pipeline overlay ENRN..enrn con accuratezza in valutazione sopra la tua soglia (default 0.8), il router lo ricarica a caldo.Tier Pro+. Il corpus di training, il file overlay e il report di valutazione restano sul tuo cluster — nessuna parte del workflow "telefona a casa".
La strada del fast-start. Se non hai ancora esempi etichettati ma sai le classi che vuoi, il router può ricadere su un LLM con un prompt che include la tua tassonomia. Due configurazioni:
Quando il classificatore di base restituisce una confidenza sotto la soglia (default 0.7), il router scala: chiede a un piccolo LLM "classifica questa query in una di: [la tua lista di classi]" e usa la risposta dell'LLM come etichetta di routing. Aggiunge 50–100 ms alla query per il round-trip LLM; si attiva solo sulle query su cui il classificatore di base non era sicuro. Gratis con qualsiasi tier che abbia un modello chat-capable configurato.
Per tenant senza alcuna sovrapposizione con le classi predefinite (un workflow regolamentato di nicchia con vocabolario mai visto dalla piattaforma), puoi disabilitare il classificatore di base per quel tenant e far passare ogni query attraverso il percorso LLM-con-tassonomia. Più lento per query, ma non serve addestramento. Il costo dipende dal modello a cui lo punti — Inferenced locale è gratis per richiesta, gli LLM cloud a pagamento fatturano per token.
Sia la Strada A sia la Strada B sono configurate per tenant. Un tenant può operare con il classificatore overlay per la maggior parte del traffico e il fallback LLM per i casi a bassa confidenza.
La console di amministrazione → pagina Router mostra una coda live delle decisioni di classificazione: query (anonimizzata di default), classe assegnata, confidenza, sorgente (base / overlay / fallback-LLM) e il worker a cui la richiesta è stata instradata. Utile per il debug di "perché questa query è finita lì" e per individuare lacune nella tassonomia delle classi — quando molte query finiscono nella classe catch-all "general" con bassa confidenza, è un segnale per aggiungere una nuova classe.
Gli stessi dati sono esposti tramite API:
curl -X POST -H "X-API-Key: $ELDRIC_API_KEY" \
-H "Content-Type: application/json" \
-d '{"query":"puoi riassumere la clausola di indennizzo del contratto X"}' \
https://<tuo-host>/api/v1/router/classify
# {
# "class": "ContractReview",
# "confidence": 0.91,
# "source": "overlay",
# "fallback_chain": ["base", "overlay"]
# }
Gli operatori collegano questo flusso ai propri dashboard quando vogliono un quadro più chiaro di quali query la piattaforma sta vedendo.
Per la guida pratica RAG: usare RAG. Per il comportamento a cascata: RAG a richiesta. Per come il router si inserisce nel resto del sistema: come funziona. Per il lato training-worker che produce i file overlay .enrn: funzionalità § Training.