Introduzione: La Genesi di EVE RAG nel Contesto del Web Moderno

L’evoluzione del Content Management System (CMS) WordPress, che alimenta oltre il 40% del web, ha tradizionalmente fatto affidamento su paradigmi di ricerca lessicale. La funzione nativa WP_Query, basata sull’operatore SQL LIKE, rappresenta lo standard de facto per il recupero delle informazioni. Tuttavia, nell’era dell’Intelligenza Artificiale Generativa, questo approccio mostra limiti strutturali evidenti: l’incapacità di comprendere l’intento semantico dell’utente e la dipendenza dalla corrispondenza esatta delle parole chiave.

Il progetto EVE RAG nasce da un’esigenza specifica: dotare questo blog di un’interfaccia conversazionale intelligente in grado di rispondere a quesiti complessi sfruttando il vasto archivio di articoli tecnici, guide e case study presenti sul sito. La sfida ingegneristica non risiedeva tanto nell’integrazione di un modello linguistico (LLM), quanto nell’architettura infrastrutturale.

Mentre le implementazioni standard di architetture RAG (Retrieval-Augmented Generation) si orientano verso stack tecnologici complessi—spesso coinvolgendo container Docker, microservizi in Python (FastAPI/Flask) e database vettoriali dedicati come Pinecone, Milvus o Weaviate — EVE RAG adotta una filosofia diametralmente opposta. Il sistema è stato progettato per operare come un plugin WordPress “nativo”, scritto interamente in PHP e MySQL, senza dipendenze esterne per lo storage vettoriale.

Il vincolo più stringente, e al contempo la caratteristica distintiva del progetto, è l’efficienza delle risorse: il sistema è ingegnerizzato per girare fluidamente su un ambiente di hosting condiviso o su un piccolo Virtual Private Server (VPS) con meno di 1 GB di RAM allocata.

Questo report esplora in dettaglio le scelte architetturali, le ottimizzazioni algoritmiche e le strategie di gestione della memoria che hanno reso possibile questa implementazione “frugale” ma potente.

1. Il Paradigma della Ricerca Semantica e i Limiti di WordPress

1.1 Oltre la Ricerca Lessicale

La ricerca tradizionale in WordPress opera su indici invertiti o, più comunemente, su scansioni parziali del testo. Se un utente cerca “ottimizzazione velocità sito”, il sistema cerca la stringa esatta. Tuttavia, se l’articolo pertinente utilizza termini come “Core Web Vitals”, “LCP” o “riduzione latenza server” senza menzionare esplicitamente “velocità”, il contenuto rimane nascosto. Questo è il “gap semantico”.

La ricerca semantica colma questo divario trasformando il testo in vettori numerici (embeddings) in uno spazio multidimensionale, dove la prossimità geometrica indica la somiglianza concettuale.

1.2 L’Architettura RAG (Retrieval-Augmented Generation)

Il RAG combina la capacità di recupero di un motore di ricerca con le capacità generative di un LLM. Il flusso, nel contesto di EVE RAG, è il seguente:

Interrogazione: L’utente pone una domanda (es. “Come gestisco il crawl budget?”).
Vettorializzazione: La domanda viene convertita in un vettore numerico tramite l’API di OpenAI.
Recupero (Retrieval): Il sistema scansiona il database locale per trovare i frammenti di testo (chunks) del blog che sono matematicamente più vicini alla domanda.
Generazione: I frammenti recuperati vengono iniettati nel prompt di sistema inviato a GPT-4o-mini, che formula una risposta basata esclusivamente su quei dati.

Questo approccio elimina le “allucinazioni” (risposte inventate) e garantisce che il chatbot risponda con la voce e l’autorevolezza tecnica di evemilano.com, citando le fonti interne.

2. Specifiche Tecniche e Stack Tecnologico

La decisione di utilizzare uno stack “puro” PHP/MySQL è stata guidata dalla necessità di mantenere il plugin portabile e leggero, evitando la complessità operativa di gestire database aggiuntivi o servizi in linguaggi diversi.

2.1 Lo Stack Core

Il sistema si integra perfettamente nell’ecosistema LAMP (Linux, Apache, MySQL, PHP) o LEMP (Linux, Nginx, MySQL, PHP) standard.

Componente	Tecnologia Scelta	Motivazione Tecnica
Linguaggio Backend	PHP 8.1+	Utilizzo di funzionalità moderne come `pack()` per la manipolazione binaria e tipi forti.
Database Relazionale	MySQL 8.0 (InnoDB)	Storage persistente dei vettori sfruttando l’ACID compliance e la robustezza di InnoDB.
Motore Vettoriale	Proprietario (PHP)	Implementazione custom di Cosine Similarity per evitare dipendenze esterne come `pgvector` o Redis.
LLM Provider	OpenAI API	Modelli `text-embedding-3-small` (vettorializzazione) e `gpt-4o-mini` (chat) per efficienza costi/prestazioni.
Frontend	React / Vanilla JS	Widget asincrono integrato nel tema WordPress tramite Shortcode o Hook.

2.2 Il Vincolo dell’Hardware: < 1 GB di RAM

L’obiettivo era implementare un sistema RAG leggero, solido, portatile e minimamente invasivo.

La maggior parte dei tutorial su RAG assume risorse abbondanti. Caricare un indice vettoriale (ad esempio un grafo HNSW) in memoria per un dataset di 10.000 chunk richiede centinaia di megabyte, se non gigabyte, di RAM. Su un VPS economico o un hosting condiviso, il processo PHP è spesso limitato a 128MB o 256MB. Superare questo limite provoca un Fatal Error: Allowed memory size exhausted o, peggio, manda il server in swap, degradando le prestazioni dell’intero sito.

EVE RAG affronta questo problema spostando la complessità dallo spazio (RAM) al tempo (CPU), ottimizzando drasticamente il secondo per rendere il trade-off impercettibile all’utente.

3. Architettura Proprietaria: Gestione dei Vettori in Ambiente Hostile

L’innovazione centrale di EVE RAG risiede nel modo in cui gestisce l’archiviazione e il confronto dei vettori senza l’ausilio di un database vettoriale specializzato.

3.1 Lo Schema del Database: BLOB vs JSON

Una decisione critica riguardava il formato di archiviazione dei vettori nel database MySQL. Un vettore di embedding generato dal modello text-embedding-3-small di OpenAI possiede 1536 dimensioni. Ognuna è un numero in virgola mobile (float).

3.1.1 L’Inefficienza del JSON

Memorizzare questo vettore come array JSON ([0.012, -0.231,...]) in una colonna TEXT o JSON è estremamente inefficiente:

Spazio su Disco: Ogni float occupa ~10-15 caratteri come stringa. 1536 x12 byte = 18 KB per riga.
Parsing: Decodificare il JSON in PHP (json_decode) è lento e consuma molta memoria temporanea.

3.1.2 La Soluzione: Binary Packing (BLOB)

EVE RAG utilizza la funzione pack() di PHP per convertire l’array di float in una stringa binaria.

Un float a precisione singola (32-bit) occupa 4 byte.
1536 dimensioni X 4 byte = 6144 byte (6 KB).

Questo rappresenta una riduzione dello spazio di archiviazione del 66% rispetto al JSON. La tabella wp_eve_rag_embeddings è strutturata per massimizzare la velocità di lettura sequenziale:

Nome Colonna	Tipo Dati	Note
`id`	`BIGINT UNSIGNED`	Primary Key, Auto Increment.
`post_id`	`BIGINT UNSIGNED`	Foreign Key verso `wp_posts`. Indicizzato.
`chunk_hash`	`CHAR(32)`	MD5 del contenuto per evitare ricalcoli inutili (cache invalidation).
`vector`	`MEDIUMBLOB`	Il vettore binario pacchettizzato (`pack('f*',...)`).
`content`	`TEXT`	Il testo in chiaro del chunk (per il retrieval).

L’uso di MEDIUMBLOB garantisce che i dati siano archiviati off-page nelle pagine di overflow di InnoDB se necessario, mantenendo l’indice primario compatto.

3.2 Ottimizzazione della Memoria in PHP: Array vs Stringhe

Una delle sfide maggiori documentate nella ricerca è l’overhead degli array in PHP. Un array PHP non è un array contiguo di memoria (come in C), ma una hash table complessa. Ogni elemento è una struttura zval (Zend Value) che comporta un overhead significativo.

Analisi dell’Overhead

Per memorizzare 1536 float in un array PHP standard:

Dati grezzi: 1536 X 4 byte = 6 KB.
Overhead PHP: Ogni elemento dell’array richiede una struttura Bucket + zval. Le stime indicano che un array di 1000 interi può occupare fino a 400 KB di memoria in versioni precedenti di PHP o ~100 KB in PHP 7/8.
Per 10.000 chunk, caricare tutti i vettori in array PHP consumerebbe: 10.000 X 1536 X overhead = centinaia di MB di RAM, saturando immediatamente il server.

La Strategia “Zero-Copy” con `unpack`

EVE RAG aggira questo problema non espandendo mai l’intero dataset in array PHP. Invece, mantiene i vettori come stringhe binarie fino all’ultimo momento possibile.

Lettura: Il vettore viene letto dal DB come stringa binaria. In PHP, una stringa è un tipo semplice con overhead minimo.
Calcolo: La funzione unpack('f*', $binary_string) viene chiamata solo per il vettore corrente durante l’iterazione, o meglio, si utilizzano librerie o estensioni (se disponibili) che operano direttamente sulla stringa. Nel caso di PHP puro, il sistema processa un vettore alla volta, permettendo al garbage collector di liberare la memoria del vettore precedente immediatamente.¹¹

4. Il Core Algoritmico: Ricerca Vettoriale Lineare (Linear Scan)

Data l’impossibilità di mantenere in RAM indici complessi come HNSW (Hierarchical Navigable Small World) che richiedono grafi di navigazione memoria-intensivi, EVE RAG adotta un approccio di Linear Scan (o Brute Force) ottimizzato.

4.1 La Matematica della Cosine Similarity

La similarità del coseno tra due vettori A e B è definita come:

Similarity = cos(0) =AxB / ||A|| ||B||

Dove AxB è il prodotto scalare e ||A|| è la norma (lunghezza) del vettore.

Ottimizzazione Pre-Calcolata

Per ridurre i cicli di CPU durante la ricerca, EVE RAG normalizza tutti i vettori al momento del salvataggio (durante l’ingestione).

Se ||A|| = 1 e ||B|| = 1, allora il denominatore diventa 1.
La formula si semplifica in: Similarity = AxB.
Questo rimuove la necessità di calcolare radici quadrate (sqrt) e divisioni durante la scansione in tempo reale, operazioni costose in termini di CPU.

4.2 Implementazione in Streaming con Generatori PHP

Per rispettare il vincolo del < 1 GB di RAM, il codice non carica mai tutti i risultati del database in una variabile $results. Utilizza invece i Generatori (yield).

/**
 * Pseudo-codice del pattern Generator per basso consumo di memoria
 */
function scan_vectors($query_vector, $pdo) {
    // Query unbuffered per non caricare tutto il result set in memoria RAM client
    $stmt = $pdo->prepare("SELECT id, vector FROM wp_eve_rag_embeddings",);
    $stmt->execute();
    
    while ($row = $stmt->fetch()) {
        $db_vector = unpack('f*', $row['vector']);
        $score = dot_product($query_vector, $db_vector);
        
        // Manteniamo solo i top K risultati in una Priority Queue (SplMinHeap)
        // La memoria usata è costante: O(1) relativo al dataset
        $heap->insert(['id' => $row['id'], 'score' => $score]);
    }
}

Grazie a questo approccio, la memoria utilizzata è pari solo alla dimensione di un vettore (6 KB) più la struttura di heap per i top-5 risultati. Questo permette di scansionare 10.000, 50.000 o 100.000 vettori senza mai superare i 2-3 MB di memoria allocata per lo script.

4.3 Performance e Scalabilità

Molti critici sostengono che PHP/MySQL sia la “scelta peggiore” per la cosine similarity. Tuttavia, questa affermazione non considera la scala.

Small Data: Per un blog con 1.000 articoli, diviso in chunk da 500 token, si ottengono circa 5.000-10.000 vettori.
Benchmark: Un moderno processore server (vCPU) può eseguire milioni di operazioni in virgola mobile al secondo. Calcolare il prodotto scalare per 10.000 vettori in PHP (ben ottimizzato) richiede meno di 100-200 millisecondi.
Risultato: L’utente percepisce una latenza totale (compresa la chiamata API a OpenAI) inferiore a 1-2 secondi, accettabile per un chatbot. L’architettura diventa impraticabile solo sopra i 100.000 – 200.000 vettori, punto in cui EVE RAG non è più il target ideale.

5. Pipeline di Ingestione dei Contenuti

Il cuore del sistema è la capacità di trasformare gli articoli del blog in conoscenza strutturata.

5.1 Chunking Intelligente

Non basta dividere il testo ogni 500 caratteri. EVE RAG implementa un chunking semantico:

Parsing HTML: Il contenuto viene pulito dai tag HTML, ma la struttura (H2, H3) viene usata per guidare il taglio.
Windowing: I chunk sono creati per preservare frasi complete.
Contesto: Ogni chunk viene arricchito con metadati, come il titolo del post e la data, per fornire contesto all’LLM (“Come discusso nell’articolo ‘SEO 2024’ pubblicato il…”).

5.2 Gestione degli Aggiornamenti (Cache Invalidation)

Per evitare costi inutili con l’API di OpenAI, il sistema calcola un hash MD5 del contenuto del chunk prima di inviarlo all’API. Se il post viene aggiornato, solo i chunk modificati vengono ricalcolati e vettorializzati nuovamente. Questo è cruciale per la sostenibilità economica del progetto.

6. Integrazione con OpenAI e Gestione dei Costi

6.1 Scelta dei Modelli

L’architettura sfrutta i modelli più recenti ed economici di OpenAI per massimizzare il ROI:

Embedding: text-embedding-3-small. Costo irrisorio (~$0.02 per 1M token). Offre prestazioni semantiche eccellenti anche con 1536 dimensioni.
Chat: gpt-4o-mini. Questo modello offre un bilanciamento perfetto tra intelligenza (superiore a GPT-3.5) e velocità/costo. È molto più economico di GPT-4 “full” e adeguato per sintetizzare le informazioni recuperate dal blog.

6.2 Prompt Engineering Sistemico

Il prompt inviato a OpenAI è strutturato rigorosamente per prevenire allucinazioni:

“Sei un assistente esperto SEO basato sui contenuti di Evemilano.com. Rispondi alla domanda dell’utente usando ESCLUSIVAMENTE le seguenti informazioni di contesto. Se l’informazione non è presente nel contesto, afferma di non saperlo. Non inventare.”

Questo “grounding” è fondamentale per mantenere la credibilità professionale del blog.

7. Sicurezza, Privacy e Conformità

Operando in un ambiente locale, EVE RAG offre vantaggi significativi in termini di sicurezza rispetto alle soluzioni SaaS.

7.1 Gestione delle API Key

La sicurezza delle chiavi API di OpenAI è critica. Memorizzare le chiavi nel database in chiaro è una vulnerabilità nota. EVE RAG supporta due modalità:

Hardening (Consigliata): Definizione della costante EVE_RAG_OPENAI_KEY nel file wp-config.php. Questo file risiede nella root del server e non è accessibile via web, né viene salvato nei backup del database SQL.
Database Cifrato: Se l’utente inserisce la chiave via UI, questa viene cifrata utilizzando le SALT keys di WordPress e salvata nella tabella wp_options. Non è mai salvata in chiaro.

7.2 Privacy dei Dati (GDPR)

A differenza dei plugin che inviano i dati a servizi terzi (come Pinecone o servizi RAG gestiti), EVE RAG mantiene tutti i vettori e i log delle chat nel database locale del sito.

I dati inviati a OpenAI sono transienti (solo per l’elaborazione).
L’amministratore del sito ha il pieno controllo sulla cancellazione (Diritto all’Oblio) dei log delle chat.
Nessun dato degli utenti viene condiviso con aggregatori di terze parti.

8. Analisi Comparativa: EVE RAG vs Il Mercato

Per comprendere il valore di EVE RAG, è utile confrontarlo con le alternative disponibili nell’ecosistema WordPress.

Caratteristica	EVE RAG (Proprietario)	AI Engine (Jordy Meow) + Pinecone	SearchWP / ElasticPress
Architettura	Nativa PHP/MySQL (No ext. DB)	Ibrida (WordPress + Cloud Vector DB)	Motore di ricerca esterno (Elasticsearch)
Complessità Setup	Bassa (Installa e Attiva)	Media (Richiede account Pinecone/Qdrant)	Alta (Richiede server Java/Elastic)
Costo Operativo	Solo API OpenAI (Basso)	API OpenAI + Abbonamento Vector DB	Costi server elevati (RAM > 4GB)
Requisiti RAM	< 1 GB (Ottimizzato)	Dipende dal server, ma il carico è esterno	Molto Alto (Java Heap)
Privacy	Dati Locali	Dati replicati su Cloud Terzi	Dati su server di ricerca
Scalabilità	Limitata (< 50k post)	Alta (Milioni di vettori)	Molto Alta

EVE RAG vs AI Engine: Plugin come AI Engine sono eccellenti e offrono supporto per Pinecone. Tuttavia, introducono una dipendenza esterna e una latenza di rete aggiuntiva verso il database vettoriale. EVE RAG elimina questo “hop” di rete, eseguendo la ricerca localmente, il che per dataset piccoli (< 10.000 chunk) è spesso più veloce e certamente più economico.

9. Pro e Contro dell’Approccio “Local & Frugal”

9.1 Vantaggi (Pro)

Indipendenza Infrastrutturale: Funziona ovunque giri WordPress. Non richiede accesso root, Docker, o moduli PHP esoterici (eccetto l’estensione standard php-mbstring o php-json).
Costo Zero per l’Infrastruttura Vettoriale: Sfrutta il database MySQL già pagato nel piano di hosting.
Bassa Latenza di Rete: Elimina il round-trip verso un database vettoriale cloud (es. New York -> Virginia -> Milano). Tutto avviene nel localhost o nella LAN del datacenter.
Manutenzione Semplificata: Il backup del sito (file + DB) include automaticamente anche la “conoscenza” dell’AI. Non c’è bisogno di sincronizzare backup disparati.

9.2 Svantaggi (Contro)

Limite di Scala: L’algoritmo di scansione lineare O(N) degrada linearmente. Non è adatto per siti con centinaia di migliaia di articoli.
Carico CPU: Durante la ricerca, il processo PHP consuma il 100% di una vCPU per frazioni di secondo. Se 50 utenti cercano contemporaneamente, si potrebbe verificare un collo di bottiglia sulla CPU (non sulla RAM).
Assenza di Filtri Avanzati: Database come Qdrant offrono filtri complessi (“cerca vettori simili DOVE data > 2024 E categoria = SEO”). Implementare questo in SQL misto a logica vettoriale PHP è possibile ma meno performante di un indice nativo.

10. Conclusioni e Prospettive Future

Il progetto EVE RAG dimostra che l’Intelligenza Artificiale avanzata non è appannaggio esclusivo delle infrastrutture enterprise costose. Attraverso una profonda comprensione dei meccanismi interni di PHP (gestione della memoria, packing binario) e di MySQL, è possibile costruire un sistema RAG performante che risiede comodamente in un ambiente di hosting standard con meno di 1 GB di RAM.

Per evemilano.com, questo significa offrire ai lettori un’esperienza di consultazione all’avanguardia, consolidando l’autorità del brand, senza aumentare i costi fissi dell’infrastruttura.

Sviluppi Futuri

La roadmap tecnica prevede ulteriori ottimizzazioni per spingere il limite oltre i 50.000 chunk:

Quantizzazione a 8-bit: Ridurre ulteriormente la dimensione dei vettori da 6KB a 1.5KB, sacrificando una minima precisione per quadruplicare la velocità di scansione e ridurre l’uso di memoria.
Clustering (IVF nativo in PHP): Implementare un semplice algoritmo K-Means per raggruppare i vettori in 100 cluster. Durante la ricerca, il sistema confronterà la query solo con i centroidi dei cluster, e poi scansionerà solo il cluster più vicino, riducendo il carico computazionale del 90%.

EVE RAG è la prova che, con l’ingegneria corretta, “Less is More” anche nell’era dell’AI.

Appendice: Dettagli di Implementazione del Codice

Esempio di Packing Vettoriale (PHP)

Il seguente snippet illustra la tecnica fondamentale per ridurre l’impronta di memoria.

// Trasformazione da Array API a Stringa Binaria per MySQL
function pack_vector(array $float_array): string {
    // 'f*' indica float a 32-bit (machine dependent size, tipicamente IEEE 754)
    // Per maggiore portabilità si può usare 'g*' (little endian) o 'G*' (big endian)
    return pack('f*',...$float_array); 
}

// Calcolo Cosine Similarity Ottimizzato (Dot Product per vettori normalizzati)
function cosine_similarity_packed(string $binary_vec_a, string $binary_vec_b): float {
    // Unpack rapido
    // Nota: array_values è necessario perché unpack restituisce indici base-1
    $vec_a = array_values(unpack('f*', $binary_vec_a));
    $vec_b = array_values(unpack('f*', $binary_vec_b));
    
    $dot = 0.0;
    $count = count($vec_a);
    
    // Loop unrolling o ottimizzazione JIT in PHP 8 aiutano qui
    for ($i = 0; $i < $count; $i++) {
        $dot += $vec_a[$i] * $vec_b[$i];
    }
    
    return $dot;
}

Configurazione Server Raccomandata

Per garantire stabilità su server piccoli (< 1GB RAM):

PHP Memory Limit: 256M (lascia spazio per WordPress Core + processo RAG).
MySQL buffer pool size: ~300M-500M (deve contenere gli indici di wp_posts e wp_eve_rag_embeddings).
PHP-FPM pm.max_children: Impostare un valore conservativo (es. 5-10) per evitare che troppi processi concorrenti esauriscano la RAM totale durante picchi di traffico.

Approfondimento: La Gestione della Memoria e l’Overhead delle Strutture Dati in PHP

Per comprendere appieno perché l’approccio di EVE RAG basato su stringhe binarie (pack) sia non solo un’ottimizzazione, ma una necessità assoluta per girare su server con < 1 GB di RAM, dobbiamo scendere nei dettagli dell’interprete Zend Engine di PHP.

Il Costo Nascosto degli Array PHP

In linguaggi come C o Fortran, un array di 1000 float è semplicemente un blocco contiguo di memoria di 4000 byte (1000 X 4). In PHP, la struttura dati chiamata “array” è in realtà una hash map ordinata. Questa flessibilità ha un costo enorme in termini di memoria.

Ogni elemento in un array PHP è un contenitore zval (Zend Value). Una zval contiene:

Il valore effettivo (o un puntatore ad esso).
Informazioni sul tipo.
Flag vari (garbage collection, reference counting).
La struttura del Bucket (per la gestione della hash table).

Secondo le analisi di memoria di Nikita Popov (core developer di PHP) e altri benchmark:

Un intero o un float in un array PHP 7/8 occupa circa 32-48 byte di overhead strutturale, oltre ai 4-8 byte del dato stesso.
Per un vettore di 1536 dimensioni:
- Dati puri: 6 KB.
- In Array PHP: 1536 X ~40 byte = 61 KB.
Moltiplicatore: L’array PHP occupa 10 volte lo spazio dei dati grezzi.

Impatto su EVE RAG

Immaginiamo di avere 10.000 chunk di articoli nel blog.

Strategia Array PHP: 10.000 chunk X 61 KB = 610 MB.
- Caricare questo in memoria su un server con 1 GB di RAM (dove il sistema operativo ne usa 200 MB, MySQL 400 MB) porterebbe immediatamente al crash per Out of Memory.
Strategia Packed String (EVE RAG): 10.000 chunk X 6 KB = 60 MB.
- 60 MB è una quantità gestibile, ma EVE RAG va oltre, non caricandoli nemmeno tutti insieme (streaming), mantenendo l’uso attivo della memoria sotto i 10 MB per il processo di ricerca.

Alternative Scartate: Perché non `SplFixedArray`?

PHP offre SplFixedArray, un’implementazione di array più vicina allo stile C (indici interi, dimensione fissa).

Vantaggio: Riduce l’overhead rispetto agli array standard (nessuna hash key).
Svantaggio: Occupa comunque più memoria di una stringa binaria e, soprattutto, la manipolazione (serializzazione/deserializzazione dal DB) è più lenta rispetto al passaggio diretto di un BLOB binario in una stringa PHP.⁹

La scelta di usare stringhe binarie e unpack al volo rappresenta l’ottimo locale per il compromesso tra complessità del codice e utilizzo della RAM.

Analisi della Performance del Database: InnoDB e i BLOB

Un altro aspetto critico dell’architettura di EVE RAG è l’interazione con il motore di storage MySQL InnoDB. La scelta di usare MEDIUMBLOB per i vettori non è casuale.

Storage Off-Page

InnoDB memorizza i dati in pagine (generalmente da 16KB). Quando una riga è troppo grande per entrare in una pagina (che deve contenere almeno 2 righe), InnoDB sposta le colonne voluminose (come i nostri vettori da 6KB) in pagine di overflow esterne (off-page storage).

Implicazione: La scansione della tabella principale (ad esempio per filtrare per post_date o category) rimane veloce perché le pagine dell’indice primario (Clustered Index) non sono “inquinate” dai dati binari pesanti.
Retrieval: I dati BLOB vengono letti dal disco (o dal buffer pool) solo quando la riga specifica viene richiesta. Questo si allinea perfettamente con la logica di EVE RAG: “Filtra prima, leggi i vettori dopo”.

Buffer Pool Thrashing

Su un server con < 1 GB di RAM, il Buffer Pool di MySQL è probabilmente configurato tra 128 MB e 512 MB.

Un indice vettoriale completo di 10.000 chunk occupa ~60 MB.
Questo si adatta interamente nel Buffer Pool, permettendo che le scansioni successive (se la cache è calda) avvengano interamente in memoria RAM di MySQL, senza I/O su disco, garantendo tempi di risposta fulminei.
Se il dataset crescesse a 100.000 chunk (600 MB), inizierebbe il “thrashing” (lettura/scrittura continua dal disco), degradando le performance. Questo conferma il posizionamento di EVE RAG come soluzione per blog medio-grandi, ma non enormi portali di notizie.

Strategie Avanzate di Pre-Filtering (Hybrid Search)

Poiché la scansione vettoriale lineare è costosa, EVE RAG sfrutta la natura strutturata dei dati WordPress per ridurre lo spazio di ricerca prima di iniziare i calcoli matematici. Questa tecnica è spesso chiamata “Hybrid Search” o “Pre-filtering”.

Sfruttare la Tassonomia WordPress

Gli utenti raramente cercano in tutto il sito indistintamente. Il contesto spesso implica una categoria.

Esempio: “Quali sono le migliori pratiche SEO per e-commerce?”

Il sistema può dedurre (tramite un’analisi preliminare della query con LLM o regole euristiche) che la ricerca dovrebbe essere prioritaria nella categoria “E-commerce” o “WooCommerce”.

Query SQL Ottimizzata

Invece di:

SELECT vector FROM wp_eve_rag_embeddings

Il sistema esegue:

SELECT e.vector 
FROM wp_eve_rag_embeddings e
JOIN wp_posts p ON e.post_id = p.ID
JOIN wp_term_relationships tr ON p.ID = tr.object_id
WHERE tr.term_taxonomy_id =

Questo riduce il numero di vettori da scansionare da N a N{subset} (magari solo il 10% del totale), accelerando la risposta di 10x e riducendo il carico CPU. Questo è un vantaggio enorme dell’architettura “Nativa”: l’integrazione con le tassonomie (tag, categorie, autori, date) è immediata tramite semplici JOIN SQL, cosa molto più complessa da sincronizzare con un DB vettoriale esterno.

Il Futuro: PHP e l’AI Nativa

La realizzazione di EVE RAG su evemilano.com non è solo un esercizio di stile, ma un manifesto per il futuro dello sviluppo WordPress. Dimostra che PHP non è un linguaggio “legacy” inadatto all’AI, ma un potente strumento di orchestrazione che, se usato con competenza tecnica (gestione binaria, generatori, SQL avanzato), può competere con stack Python molto più complessi e costosi.

In un web sempre più dominato da soluzioni SaaS costose e “black box”, EVE RAG restituisce il controllo dei dati e dell’intelligenza al proprietario del sito, rispettando i vincoli economici e hardware della maggior parte dei webmaster indipendenti.