Embeddinguri AI WordPress: stocare și arhitectură VPS

La 27 iulie 2026, WordPress 7.0 include un AI Client independent de furnizor, dar generarea embeddingurilor nu este încă o interfață stabilă integrată direct în WordPress Core. Embeddingurile sunt disponibile în PHP AI Client, iar integrarea din WordPress a fost mutată după ciclul de lansare WordPress 7.1. Construiește căutarea semantică în spatele unui adaptor, generează vectorii prin joburi de fundal și stochează-i într-un tabel dedicat sau într-un serviciu vectorial. Nu păstra un index vectorial mare de producție în post meta și nu genera embeddinguri în timpul unui request normal de pagină.

Scris de echipa tehnică ServerSpan

Partea dificilă a căutării semantice nu este obținerea unui șir de numere de la un furnizor AI. Partea dificilă este menținerea unei relații recuperabile, interogabile și conștiente de permisiuni între conținutul WordPress, fragmente, modele, vectori și infrastructură.

WordPress AI Client generează rezultate, nu un sistem complet de căutare

WordPress 7.0 a introdus AI Client ca interfață consecventă între pluginuri și furnizorii AI configurați de proprietarul site-ului. Astfel, fiecare plugin nu mai trebuie să implementeze separat un strat de requesturi specific fiecărui furnizor.

PHP AI Client poate genera acum un singur embedding sau un lot ordonat de embeddinguri. Un exemplu la nivelul pachetului arată în prezent astfel:

use WordPress\AiClient\AiClient;

$embedding = AiClient::input( $chunk_text )
    ->usingDimensions( 512 )
    ->generateEmbedding();

$values = $embedding->getValues();

Exemplul descrie interfața PHP SDK, nu garantează că același wrapper public este deja disponibil în fiecare instalare WordPress. Integrarea curentă din pluginul WordPress AI există parțial deoarece suportul nativ pentru embeddinguri din Core a fost amânat pentru WordPress 7.2.

Indiferent ce interfață publică va deveni stabilă, aceasta va rezolva numai etapa de generare. Aplicația trebuie să decidă în continuare:

• Ce articole, pagini, produse sau obiecte personalizate pot fi indexate.
• Cum este curățat și împărțit conținutul în fragmente interogabile.
• Unde sunt stocați vectorii și textele fragmentelor.
• Cum sunt executate eficient interogările de similaritate.
• Cum sunt aplicate limitele dintre conținutul privat, utilizatori și tenanți.
• Cum este reindexat conținutul modificat sau șters.
• Cum este înlocuit un model fără întreruperea căutării.

Tratează AI Client ca pe un strat de abstractizare pentru furnizori. Tratează căutarea semantică drept un subsistem separat al aplicației.

Fluxul complet al căutării semantice

O implementare fiabilă trebuie să aibă un flux vizibil, nu un singur callback supradimensionat atașat la save_post.

1. Selectare: stabilește dacă obiectul este publicat, interogabil și permis în indexul respectiv.
2. Normalizare: elimină fragmentele de navigație, markupul blocurilor fără semnificație, shortcode-urile care nu trebuie indexate și textul repetitiv.
3. Fragmentare: împarte conținutul util în secțiuni coerente, potrivite pentru modelul de embedding și suficient de bogate în context.
4. Hash: calculează un hash stabil pentru fiecare fragment, astfel încât lucrările neschimbate să fie omise.
5. Coadă: creează un job de fundal idempotent în loc să contactezi modelul în timpul requestului editorului.
6. Generare și stocare: generează vectorii în loturi și inserează-i sau actualizează-i împreună cu obiectul WordPress, modelul, limba și metadatele de permisiuni.
7. Interogare: generează embeddingul căutării, filtrează înregistrările eligibile, calculează similaritatea, aplică permisiunile și returnează obiectele WordPress corespunzătoare.

Articolul sau obiectul-sursă rămâne sursa canonică de date. Indexul vectorial este o structură de căutare derivată. Această diferență simplifică ștergerea, reconstruirea și recuperarea în caz de dezastru.

Numără fragmentele, nu articolele WordPress

Estimările de găzduire bazate numai pe numărul articolelor sunt înșelătoare. Un anunț scurt poate produce un singur vector, iar un ghid tehnic lung poate produce 10 sau 20 de fragmente.

Stocarea brută pentru vectorii float32 poate fi estimată astfel:

Octeți vectoriali bruți = numărul fragmentelor × dimensiuni × 4

Dimensiuni	Dimensiune brută per vector	10.000 de fragmente	100.000 de fragmente
512	2 KiB	Aproximativ 19,5 MiB	Aproximativ 195 MiB
1.536	6 KiB	Aproximativ 58,6 MiB	Aproximativ 586 MiB
3.072	12 KiB	Aproximativ 117 MiB	Aproximativ 1,14 GiB

Aceste valori sunt limite minime. Spațiul real ocupat de baza de date include și textul fragmentelor, metadatele obiectelor, overhead-ul rândurilor, indexurile obișnuite, structurile indexului vectorial, spațiul temporar pentru reconstruire, replicarea și backupurile. Un index pentru vecini aproximați poate consuma, de asemenea, o cantitate importantă de RAM în timpul interogării sau reconstruirii.

Reducerea numărului de dimensiuni poate economisi spațiu și memorie, dar numai dacă modelul selectat acceptă dimensionalitatea solicitată, iar calitatea căutării rămâne suficientă pentru conținutul respectiv. Măsoară calitatea rezultatelor folosind interogări reale, nu presupune că un vector mai mare este automat mai bun.

Alege intenționat arhitectura de stocare a vectorilor

Opțiune de stocare	Avantaje	Limitarea principală	Utilizare potrivită
Post meta cu JSON sau vectori serializați	Prototip simplu, fără schemă separată de bază de date	Fără index vectorial practic; PHP sau SQL trebuie să parcurgă și să decodeze multe rânduri	Proof of concept cu un corpus foarte mic
Tabel personalizat în baza de date WordPress	Proprietate, backup și asocieri simple cu ID-urile obiectelor WordPress	Performanța depinde puternic de motorul bazei de date și de suportul pentru indexuri vectoriale	Implementare mică sau medie pe o bază de date compatibilă
Serviciu vectorial pe același VPS cu WordPress	Căutare specializată fără un server suplimentar	Căutarea, indexarea și WordPress concurează pentru același RAM, CPU și disc	Implementare controlată de producție cu sarcină moderată
Serviciu vectorial pe un VPS separat	Scalare independentă, izolare la defecte și alocare predictibilă a resurselor	Necesită mai multă configurare de rețea, autentificare, monitorizare și backup	Corpus în creștere, mai multe site-uri, documente private sau importuri intensive
Serviciu vectorial extern administrat	Administrare minimă a bazei de date și scalare orizontală simplificată	Cost recurent, dependență de transferul datelor, rezidență și vendor lock-in	Echipe care preferă infrastructura administrată în locul self-hostingului

Pentru majoritatea implementărilor WordPress serioase, un tabel personalizat este proiectarea minim acceptabilă. Post meta poate păstra un vector pentru un prototip, dar este o alegere greșită pentru producție deoarece WordPress nu oferă un index nativ de similaritate pentru post meta. Fiecare interogare ajunge să devină o parcurgere costisitoare, o operațiune repetată de decodare sau o comparație realizată în aplicație.

MariaDB și MySQL oferă în prezent căi diferite pentru căutarea vectorială

Nu presupune că o bază de date etichetată „compatibilă MySQL” are aceleași funcții vectoriale ca toate celelalte baze de date din această familie.

MariaDB 11.7 și versiunile ulterioare

MariaDB 11.7 a introdus stocarea relațională și indexarea vectorilor. Implementarea acceptă coloane dimensionale VECTOR(N) și un index pentru vecini aproximați, bazat pe distanță cosinus sau euclidiană.

Un tabel orientativ pentru MariaDB 11.7 sau o versiune ulterioară, destinat unui model cu 1.536 de dimensiuni, poate arăta astfel:

CREATE TABLE wp_ai_chunks (
    chunk_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    object_id BIGINT UNSIGNED NOT NULL,
    chunk_index SMALLINT UNSIGNED NOT NULL,
    language VARCHAR(20) NOT NULL,
    visibility VARCHAR(32) NOT NULL,
    content_hash CHAR(64) NOT NULL,
    model_id VARCHAR(191) NOT NULL,
    chunk_text LONGTEXT NOT NULL,
    embedding VECTOR(1536) NOT NULL,
    updated_at DATETIME NOT NULL,
    PRIMARY KEY (chunk_id),
    UNIQUE KEY object_chunk_model (
        object_id,
        chunk_index,
        model_id
    ),
    VECTOR INDEX (embedding)
        M=8
        DISTANCE=cosine
);

Acesta este un exemplu de arhitectură, nu un script universal de migrare. Adaugă tipul real al obiectului, identificatorul site-ului sau tenantului, statusul și câmpurile de permisiuni necesare aplicației. Un tabel MariaDB poate conține un singur index vectorial, iar coloana indexată trebuie să folosească o dimensionalitate fixă.

MySQL 9 și versiunile ulterioare

MySQL a adăugat tipul VECTOR în MySQL 9.0. MySQL standard permite stocarea și utilizarea funcțiilor vectoriale, dar coloana VECTOR nu poate fi folosită direct drept cheie primară, externă, unică sau de partiționare. Coloanele obișnuite de metadate pot fi indexate în continuare.

Consecința practică este că existența unui tip de date vectorial nu oferă automat indexul pentru vecini aproximați așteptat de la un motor vectorial dedicat. Verifică versiunea exactă MySQL și planul de execuție înainte de a o alege pentru un corpus de căutare semantică aflat în creștere.

Multe platforme de găzduire shared rulează încă versiuni de baze de date fără aceste implementări sau nu permit clientului să aleagă versiunea. Numai această cerință privind baza de date poate justifica mutarea subsistemului de căutare pe un VPS.

Versionează fiecare fragment și embedding

Un embedding este valid numai în contextul modelului și al fluxului de preprocesare care l-a generat. O înregistrare utilă trebuie să păstreze mai mult decât vectorul propriu-zis.

Câmp	Scop
ID-ul și tipul obiectului	Asociază rezultatul cu articolul, pagina, produsul sau obiectul WordPress personalizat
Indexul fragmentului sau un ID stabil	Identifică secțiunea din obiectul-sursă
Textul fragmentului	Oferă pasajul interogabil și permite inspecția sau rerankingul
Hash-ul conținutului	Omite fragmentele neschimbate și identifică vectorii depășiți
Versiunea algoritmului de fragmentare	Identifică regulile de normalizare și împărțire folosite
ID-ul modelului	Împiedică compararea vectorilor generați de modele incompatibile
Dimensiuni	Verifică dacă valoarea corespunde coloanei sau indexului vectorial
Limba	Permite filtrarea lingvistică și deciziile privind indexurile multilingve
Vizibilitatea sau tenantul	Previne scurgerile de date între utilizatori, clienți sau conținut privat
Data actualizării	Susține auditarea, curățarea și urmărirea reindexării

Schimbarea modelului de embedding este o migrare de schemă, nu o simplă modificare de configurare. Modele diferite pot genera vectori cu dimensiuni și geometrii diferite. Creează un index sau un tabel nou, versionat, reconstruiește-l în fundal, testează calitatea rezultatelor și mută traficul de căutare numai după finalizarea noului index.

Generează embeddingurile într-o coadă de fundal

Nu obliga editorul de blocuri să aștepte în timp ce un articol lung este curățat, fragmentat, transformat în embeddinguri și inserat într-un index vectorial. Requestul poate expira, furnizorul poate aplica limitarea ratei, iar editorul poate repeta o operațiune finalizată doar parțial.

Un flux de publicare mai sigur este:

• Hook-ul de salvare calculează noul hash al sursei și creează un element în coadă.
• Un worker încarcă versiunea finală a conținutului salvat și creează fragmente deterministe.
• Hash-urile existente sunt comparate înainte de orice request plătit pentru embeddinguri.
• Fragmentele noi sau modificate sunt trimise în loturi acceptate de furnizor.
• Fiecare vector finalizat este inserat sau actualizat împreună cu modelul și metadatele fragmentului.
• Fragmentele vechi sunt eliminate numai după finalizarea cu succes a setului de înlocuire.
• Erorile temporare de rețea sau ale furnizorului sunt reîncercate cu întârzieri progresive.
• Erorile permanente de validare sunt înregistrate și afișate unui administrator.

WP-Cron poate gestiona lucrări asincrone ușoare, dar este declanșat de traficul site-ului, nu de un scheduler care rulează continuu. Importurile în masă, reindexările mari și procesarea predictibilă necesită de regulă un cron real de sistem, un worker WP-CLI sau o coadă durabilă.

Dezvoltă fluxul de indexare pe o copie de staging realistă înainte de a-l conecta la conținutul de producție. Ghidul ServerSpan despre staging WordPress pe VPS explică modul în care testele pot fi păstrate separat de site-ul live.

O interogare semantică are nevoie de mai mult decât distanța cosinus

Fluxul unei interogări trebuie proiectat la fel de atent ca fluxul de indexare:

1. Normalizează interogarea vizitatorului folosind aceleași presupuneri lingvistice ca în conținutul indexat.
2. Generează un embedding al interogării cu același model folosit de indexul vizat.
3. Filtrează candidații după site, tenant, limbă, tip de obiect, status de publicare și vizibilitate.
4. Solicită indexului vectorial fragmentele cele mai apropiate.
5. Verifică din nou permisiunile WordPress înainte de afișarea rezultatului sau a fragmentului.
6. Grupează fragmentele duplicate care aparțin aceluiași obiect-sursă.
7. Combină opțional similaritatea semantică cu relevanța full-text a cuvintelor-cheie.
8. Returnează URL-ul canonic WordPress și un pasaj care susține în mod real rezultatul.

Filtrarea permisiunilor nu trebuie amânată până după ce o interogare vectorială nerestricționată a returnat aplicației text privat. Căutarea publică trebuie să indexeze numai conținut public, cu excepția cazului în care întreaga arhitectură gestionează utilizatori, roluri, tenanți și permisiuni la nivel de obiect.

Căutarea hibridă este deseori mai utilă decât similaritatea vectorială pură. Căutarea după cuvinte-cheie gestionează bine numele exacte, numerele de model, codurile de eroare și expresiile citate. Embeddingurile gestionează parafrazările și similaritatea conceptuală. Combinarea lor evită obligarea unei singure metode să rezolve toate tipurile de interogări.

Stabilește dacă sarcina vectorială trebuie să rămână pe serverul WordPress

Arhitectura corectă de găzduire depinde de concurența pentru resurse, nu de faptul că funcția este numită „AI”. Generarea la distanță a embeddingurilor poate folosi puține resurse locale, dar indexul vectorial, coada de import și baza de date pot crea în continuare presiune importantă asupra RAM-ului, procesorului și operațiunilor de disc.

Arhitectură	Alege-o când	Depășește-o când
WordPress și vectorii într-o singură bază de date relațională	Corpusul este controlat, motorul are un index vectorial potrivit, iar concurența interogărilor este redusă	Căutările sau reconstruirile indexului încep să afecteze interogările WordPress normale
WordPress și un serviciu vectorial pe același VPS	Ai nevoie de căutare specializată, dar poți limita resursele ambelor servicii și monitoriza concurența	Memoria vectorilor, importurile sau restarturile afectează PHP, serverul web ori baza de date principală
WordPress și serviciul vectorial pe VPS-uri separate	Ai nevoie de scalare independentă, reconstruiri mai sigure, mai mulți consumatori sau izolare mai puternică	Costul operațional depășește valoarea self-hostingului
Model local separat pentru embeddinguri și serviciu vectorial	Datele nu pot părăsi infrastructura proprie și accepți sarcina de calcul și administrarea modelului	Modelul necesită acceleratoare specializate sau operatori dedicați

Un VPS KVM este, de regulă, alegerea mai sigură atunci când arhitectura necesită Docker, o versiune personalizată a bazei de date, control la nivel de kernel sau izolare mai puternică. Un VPS containerizat poate fi potrivit pentru un serviciu Linux convențional care nu necesită propriul kernel. Diferențele tehnice sunt prezentate în comparația KVM VPS versus VPS containerizat pentru Docker, CI/CD, agenți AI și self-hosting.

Nu selecta planul VPS numai după numărul articolelor WordPress. Măsoară numărul rezultat de fragmente, dimensiunile vectorilor, numărul estimat de căutări simultane, memoria indexului, debitul cozii și creșterea bazei de date. Ghidul ServerSpan despre dimensionarea unui plan VPS oferă un cadru mai larg pentru asocierea resurselor CPU, RAM, stocare și trafic cu aplicația.

Backupurile trebuie să includă vectorii sau un proces testat de reconstruire

Vectorii reprezintă date derivate, dar reconstruirea lor poate dura ore, poate consuma requesturi API plătite și poate lăsa căutarea indisponibilă. Alege explicit una dintre următoarele strategii de recuperare:

• Realizează backup pentru depozitul vectorial: include tabelul vectorial sau snapshotul serviciului, metadatele, versiunea modelului și configurația indexului în procesul de disaster recovery.
• Reconstruiește-l: păstrează conținutul-sursă, codul de fragmentare, identificatorul modelului, configurația furnizorului și o comandă testată care recreează întregul index.

A doua opțiune este validă numai dacă reconstruirea a fost testată în practică. Posibilitatea teoretică de a apela furnizorul de embeddinguri nu reprezintă un plan de recuperare.

Înaintea unei migrări de schemă sau de model, păstrează indexul anterior disponibil până când cel nou este complet. Activarea în producție a unui index gol sau reconstruit parțial produce o întrerupere care poate fi evitată.

Monitorizează subsistemul de căutare separat de WordPress

Un test verde de uptime pentru WordPress nu dovedește că funcția de căutare semantică este sănătoasă. Monitorizează cel puțin:

• Joburile de embedding în așteptare, active, eșuate și respinse permanent.
• Vechimea celei mai vechi modificări de conținut care nu a fost procesată.
• Latența requesturilor către furnizor, răspunsurile de limitare și erorile legate de cost sau credit.
• Latența interogărilor vectoriale și rata de eroare.
• Dimensiunea indexului, memoria procesului și creșterea spațiului ocupat de baza de date.
• Numărul fragmentelor care folosesc fiecare model și versiune de fragmentare.
• Obiectele publicate care au embeddinguri lipsă sau depășite.
• Rezultatele respinse de verificările de permisiuni.
• Latența paginilor WordPress în timpul unei reindexări sau al unui import.

Cel mai important indicator operațional este interferența. Atunci când interogările vectoriale, workerii de fundal sau reconstruirile indexului degradează livrarea paginilor, sarcina de căutare a depășit limita de resurse pe care o împarte cu WordPress.

O arhitectură implicită rezonabilă

Pentru un proiect nou de căutare semantică WordPress, arhitectura inițială justificabilă este:

• WordPress rămâne sistemul canonic pentru conținut și permisiuni.
• Un adaptor ascunde evoluția interfeței de generare a embeddingurilor.
• Modificările de conținut creează joburi de fundal idempotente.
• Fragmentele sunt stocate cu hash-uri, versiuni de model, dimensiuni și metadate de vizibilitate.
• Un index vectorial MariaDB 11.7 sau ulterior, ori un serviciu vectorial dedicat, execută căutarea de similaritate.
• Fluxul de interogare aplică filtrele de metadate și verificările de permisiuni WordPress.
• Depozitul vectorial este inclus în backup sau poate fi reconstruit în mod reproductibil.
• Serviciul de căutare este mutat pe un VPS separat atunci când concurența pentru resurse devine măsurabilă.

Regula practică este simplă: folosește WordPress AI Client pentru a abstractiza accesul la modele, dar nu confunda generarea embeddingurilor cu o arhitectură completă de căutare. Versionează datele, procesează-le asincron, aplică permisiunile înainte de returnarea rezultatelor și separă sarcina vectorială de WordPress atunci când începe să concureze cu site-ul pe care trebuie să îl îmbunătățească.