Ricerca
Un’architettura di caching a tre livelli per la ricerca web a bassa latenza con LLM su hardware CPU standard
I prodotti di ricerca basati sull’IA, come la ricerca di ChatGPT, AI Overviews di Google e Perplexity, forniscono risposte elaborate dagli LLM e fondate su risultati web in tempo reale. Abbiamo svilup

- arXiv
- 2609.05463
- Pubblicato
- 2026-08-12
- Autori
- Ayushman Bhattacharya, Nihal Gazi
Abstract degli autori
I prodotti di ricerca basati sull’IA, come la ricerca di ChatGPT, AI Overviews di Google e Perplexity, forniscono risposte elaborate dagli LLM e fondate su risultati web in tempo reale. Abbiamo sviluppato OreoLook (in precedenza lixSearch), un motore di risposta open source che usa agenti browser automatizzati e affida l’inferenza degli LLM a diversi fornitori. La sua infrastruttura locale per la ricerca, il caching, la gestione delle sessioni e gli embedding gira su hardware CPU standard; la sintesi delle risposte è eseguita da un fornitore di inferenza remoto. Con l’aumentare dell’utilizzo, le sessioni perdevano il contesto, query equivalenti innescavano elaborazioni ridondanti e gli embedding degli URL venivano calcolati ripetutamente in sessioni diverse. Presentiamo un’architettura di caching a tre livelli: (1) una Session Context Window che mantiene in Redis una finestra scorrevole dei messaggi recenti, trasferendo automaticamente quelli in eccesso in archivi su disco compressi con Huffman; (2) una Semantic Query Cache che riconosce le riformulazioni tramite la similarità coseno tra vettori di embedding, eliminando le chiamate ridondanti agli LLM; e (3) una URL Embedding Cache che evita di ricalcolare gli embedding degli URL in sessioni diverse. Distribuito su un unico server Intel Cascade Lake con 8 vCPU (2 GHz, 32 GB di RAM), su cui girano 30 processi worker Hypercorn in tre repliche containerizzate, il sistema valutato ha registrato un tasso aggregato di hit nell’insieme delle chiavi Redis dell’89,3%, con una latenza di lettura di 0,1 ms e un consumo di memoria aggiuntivo di appena 1,38 MB. Un processo in background che gestisce l’espulsione secondo la politica LRU trasferisce le sessioni inattive da Redis al disco e le ricarica su richiesta, consentendo di riprendere le conversazioni ore o giorni dopo, secondo la politica di conservazione configurata.
Il riassunto di questo paper è disponibile solo in inglese: leggilo nella pagina inglese.
Leggi il paper originale su arXiv