La cerca es muda al fitxer

19-07-2026 Versió v0.12

A la v0.12, la cerca de text complet i la vectorial deixen de ser un segon i un tercer sistema. Viuen dins del mateix fitxer Arkeion xifrat i versionat, al costat del teu SQL — sobre un únic historial encadenat per hashes, accessible amb el mateix AS OF, demostrable amb el mateix verify().

Tres sistemes i les canonades entre ells, davant d'un fitxer que ja conté els tres.

L’impost del segon sistema

El cost d’una pila de cerca a part rarament és el motor de cerca en si: és tot el que l’envolta. Cada document que vulguis que sigui cercable ha de ser enviat a l’altre sistema: un pipeline d’indexació, una cua, una tasca de reconciliació per quan el pipeline perdi un missatge. Les teves dades viuen ara en dos o tres llocs, cosa que vol dir dues o tres còpies per assegurar, i dues o tres respostes a la pregunta “això està sincronitzat ara mateix?”. La resposta honesta, sota càrrega, sol ser no del tot.

Posar la cerca dins del fitxer fa caure tot això. Quan fas INSERT d’una fila, el seu text s’indexa a la mateixa transacció; quan escrius un embedding, s’uneix al mateix índex de manera atòmica. No hi ha cap finestra en què la fila existeixi però el resultat de cerca no, perquè no hi ha cap segon sistema que es quedi enrere.

SQL, text complet i vectors són tres superfícies sobre un mateix fitxer — i el fitxer sencer és versionat, demostrable i navegable en el temps.

Text complet: com viu BM25 dins del fitxer

La cerca de text complet és, per sota, un índex invertit. Allà on un índex normal mapa una fila als seus valors, un índex invertit mapa cada terme a la llista de documents que el contenen. Entra text, es tokenitza en termes, i cada terme apunta a una posting list: els documents on apareix, amb posicions per a consultes de frase i de fragment.

Un índex invertit: termes en un diccionari ordenat, cadascun apuntant als documents que el contenen. Ordenar els termes permet que les postings comparteixin prefixos i es comprimeixin.

Dues decisions de disseny fan compacta la versió d’Arkeion. El diccionari de termes està ordenat, de manera que els termes adjacents comparteixen prefixos llargs i només emmagatzemen la diferència; i les posting lists van comprimides per prefix en comptes d’escrites senceres. El resultat, mesurat sobre el mateix corpus, és un índex que va sortir més petit que l’FTS5 de SQLite — i això rankejant amb BM25 (el model de rellevància estàndard que equilibra la freqüència d’un terme contra com de comú és) i retornant fragments ressaltats.

Serem honestos amb el compromís: FTS5 encara construeix i consulta més de pressa. Porta anys d’ajust fi i no està pagant pel versionat. El que Arkeion compra amb la diferència és una cosa que FTS5 estructuralment no pot oferir: una cerca que recorda.

Cerca que viatja en el temps

Com que cada posting viu al mateix historial encadenat per hashes que les teves files, l’índex té passat. MATCH … AS OF executa una consulta de text complet contra el fitxer tal com estava en una versió anterior — no una còpia de seguretat, no una tasca de snapshots, només l’índex mateix, adreçable en el temps.

L'índex porta el seu propi historial: una consulta de text complet pot apuntar a qualsevol versió passada del fitxer.

Vectorial: veí més proper sense la tercera capsa

La cerca vectorial respon una pregunta diferent — no “quins documents contenen aquesta paraula” sinó “quins embeddings són més a prop d’aquest”. Fet de manera ingènua, això vol dir comparar la consulta contra cada vector, cosa lineal i lenta. Arkeion fa servir IVF (inverted file): durant la construcció, l’espai vectorial es particiona en cel·les al voltant de centroides representatius. En temps de consulta només sondeges el grapat de cel·les més properes a la consulta, no el conjunt sencer.

IVF converteix un recorregut complet en uns quants sondejos de cel·la; la quantització per producte comprimeix després cada vector, i una passada de re-rank int8 recupera la precisió que PQ sacrifica.

Sobre l’IVF, la quantització de producte (el PQ d’IVF-PQ) comprimeix cada vector substituint-lo per codis de petits codebooks apresos — la raó que l’índex sigui tan petit. Com que PQ és amb pèrdua, una passada final de re-rank int8 torna a garbellar els millors candidats amb més precisió, recuperant l’exactitud que la quantització cedeix. I quan vols el millor dels dos mons, RRF híbrid (reciprocal rank fusion) fusiona el ranking de text i el ranking vectorial en un únic resultat ordenat.

Reciprocal rank fusion: dos rànquings independents, un per paraules clau i un altre de semàntic, combinats en una única resposta.

La recompensa és mesurable. A SIFT 1M (128-dim, recall ≈ 0.99) una consulta única sosté ~356 qps, i l’índex és 14–21× més petit que els índexs HNSW contra els quals es mesura — prou petit per cabre en una fracció de la RAM, just al costat del teu SQL. Sota càrrega concurrent es manté al voltant de ~700 qps amb vuit nuclis. I la construcció és paral·lela i en streaming: el dataset no es materialitza mai del tot en memòria, així que escala a desenes de milions de vectors en una màquina modesta en comptes d’exigir-ne una dimensionada per a tot el corpus de cop.

El mateix recall, una fracció de l'espai — vectors que caben a la RAM al costat del teu SQL.

Per què importa un sol fitxer

Tot plegat, això és l’argument sencer d’Arkeion en miniatura. SQL, text complet i vectors són un fitxer, no tres sistemes: cap pipeline d’indexació per executar, cap servei per mantenir sincronitzat, cap còpia de les teves dades sortint de la frontera que tu controles. Cada part està versionada, així que la cerca pot viatjar en el temps; cada part està encadenada per hashes, així que verify() pot demostrar que el conjunt és intacte. La cerca va deixar de ser una cosa que cargoles a sobre i va passar a ser una cosa que la base de dades simplement és.

Consulta els benchmarks per veure totes les xifres, reportades amb honestedat — inclosos els llocs on un motor dedicat encara guanya.