La maggior parte dei sistemi RAG immagazzina i documenti a priori e paga costi di storage + ri-embedding indipendentemente dal fatto che qualcuno chieda di loro. Eldric è diverso: la piattaforma prova prima i pesi appresi, poi la memoria associativa, poi la tua base di conoscenza, poi le fonti esterne live — e ingerisce solo il materiale che la piattaforma trova effettivamente utile, quando lo trova utile. Il risultato è uno strato di conoscenza che cresce sul segnale, non sull'accumulo.
Su ogni query, la piattaforma percorre quattro livelli in ordine, fermandosi non appena ha una risposta affidabile:
Ogni livello porta un segnale di confidenza; la piattaforma sale al livello successivo solo quando quello corrente non è abbastanza sicuro. Risparmia cicli, risparmia denaro su API esterne a pagamento, preserva il budget di latenza.
La cascata è il percorso di lettura. Il loop di ritenzione è cosa succede dopo — ed è ciò che fa diventare Eldric più intelligente con l'uso invece che più pesante con l'uso.
Il flusso:
L'intero loop è opt-out per tenant; gli amministratori possono operare con il loop di ritenzione disattivato se vogliono uno strato RAG statico. Di default è attivo, perché quella è la via verso uno strato di conoscenza che migliora con il traffico invece di stagnare.
Il loop di ritenzione gira dietro le quinte. Dalla prospettiva dell'utente, l'unica superficie nuova è il piccolo footer sotto ogni risposta dell'assistente — un pulsante 👍, un pulsante 👎 e un link "vedi fonti" che espande le citazioni inline. Cliccare 👍 (o espandere una citazione, che conta come accettazione soft) avvia l'ingestione. Cliccare 👎 marca la risposta come di bassa qualità; le citazioni non vengono auto-ingerite, il ciclo di sogno le pesa meno, e la piattaforma prova fonti diverse la prossima volta che lo stesso argomento si presenta.
L'utente non vede mai la cascata scegliere i livelli; non deve sapere se la sua risposta è arrivata dai pesi appresi o da OpenAlex live. La risposta arriva con citazioni; il loop gira sullo sfondo.
Meno storage. Un RAG tradizionale a pre-warehouse ingerisce ogni fonte a cui l'operatore riesce a pensare e spera che le rilevanti siano lì dentro. Eldric ingerisce solo le fonti che qualcuno accetta effettivamente — quindi la base di conoscenza resta della dimensione di ciò che la piattaforma usa realmente.
Più veloce nel tempo. Le query che prima richiedevano il tier 3 (ricerca vettoriale) si spostano al tier 2 (memoria compressa) e poi al tier 1 (pesi appresi) man mano che la piattaforma interiorizza i pattern. La latenza scende senza alcun tuning.
API esterne a pagamento meno spesso. Se la risposta a una domanda è nei tuoi documenti o già nei pesi appresi della piattaforma, l'escalation al tier 4 non si attiva mai. Le bollette per embedding o retrieval API a pagamento calano in proporzione.
Il compromesso è onesto: un'installazione nuova di zecca risponde molto al tier 3 / tier 4, perché niente è ancora nei pesi appresi della piattaforma. Dopo qualche settimana di query accettate, tier 1 / tier 2 porta una quota crescente. La piattaforma ripaga il pedaggio del cold-start nel tempo, non tutto in una volta.
La guida pratica lato cliente per il lato RAG: usare RAG. La vista tecnica di come la cascata è cablata tra i worker: come funziona. Lo strato di chunking che determina la qualità degli hit RAG: strategie di chunking. Per i clienti che vogliono insegnare a Eldric le proprie classi di intento (così il tier 1 copre più rapidamente query specifiche del dominio): classificazione personalizzata.