En la v0.12, la búsqueda de texto completo y la vectorial dejan de ser un segundo y un tercer sistema. Viven dentro del mismo fichero Arkeion cifrado y versionado, junto a tu SQL — sobre un único historial encadenado por hashes, alcanzable con el mismo AS OF, demostrable con el mismo verify().

El impuesto del segundo sistema

El coste de una pila de búsqueda aparte rara vez es el motor de búsqueda en sí: es todo lo que lo rodea. Cada documento que quieras que sea buscable tiene que ser enviado al otro sistema: un pipeline de indexación, una cola, un trabajo de reconciliación para cuando el pipeline pierda un mensaje. Tus datos viven ahora en dos o tres sitios, lo que significa dos o tres copias que asegurar, y dos o tres respuestas a la pregunta “¿esto está sincronizado ahora mismo?”. La respuesta honesta, bajo carga, suele ser no del todo.

Meter la búsqueda en el fichero hace que todo eso se venga abajo. Cuando haces INSERT de una fila, su texto se indexa en la misma transacción; cuando escribes un embedding, se une al mismo índice de forma atómica. No hay ventana en la que la fila exista pero el resultado de búsqueda no, porque no hay un segundo sistema que se quede atrás.

Texto completo: cómo vive BM25 en el fichero

La búsqueda de texto completo es, por debajo, un índice invertido. Donde un índice normal mapea una fila a sus valores, un índice invertido mapea cada término a la lista de documentos que lo contienen. Entra texto, se tokeniza en términos, y cada término apunta a una posting list: los documentos en los que aparece, con posiciones para consultas de frase y de fragmento.

Dos decisiones de diseño hacen compacta la versión de Arkeion. El diccionario de términos está ordenado, así que los términos adyacentes comparten prefijos largos y solo almacenan la diferencia; y las posting lists van comprimidas por prefijo en lugar de escritas enteras. El resultado, medido sobre el mismo corpus, es un índice que salió más pequeño que el FTS5 de SQLite — y eso rankeando con BM25 (el modelo de relevancia estándar que equilibra la frecuencia de un término frente a lo común que es) y devolviendo fragmentos resaltados.

Seremos honestos con el compromiso: FTS5 sigue construyendo y consultando más rápido. Lleva años de ajuste fino y no está pagando por el versionado. Lo que Arkeion compra con la diferencia es algo que FTS5 estructuralmente no puede ofrecer: una búsqueda que recuerda.

Búsqueda que viaja en el tiempo

Como cada posting vive en el mismo historial encadenado por hashes que tus filas, el índice tiene pasado. MATCH … AS OF ejecuta una consulta de texto completo contra el fichero tal como estaba en una versión anterior — no una copia de seguridad, no un trabajo de snapshots, solo el índice mismo, direccionable en el tiempo.

Vectorial: vecino más cercano sin la tercera caja

La búsqueda vectorial responde a otra pregunta — no “qué documentos contienen esta palabra” sino “qué embeddings están más cerca de este”. Hecho de forma ingenua, eso significa comparar la consulta contra cada vector, lo cual es lineal y lento. Arkeion usa IVF (inverted file): durante la construcción, el espacio vectorial se particiona en celdas alrededor de centroides representativos. En tiempo de consulta solo sondeas el puñado de celdas más cercanas a la consulta, no el conjunto entero.

Sobre IVF, la cuantización de producto (el PQ de IVF-PQ) comprime cada vector reemplazándolo por códigos de pequeños codebooks aprendidos — la razón de que el índice sea tan pequeño. Como PQ es con pérdida, una pasada final de re-rank int8 vuelve a cribar los mejores candidatos con mayor precisión, recuperando la exactitud que la cuantización cede. Y cuando quieres lo mejor de ambos mundos, RRF híbrido (reciprocal rank fusion) fusiona el ranking de texto y el ranking vectorial en un único resultado ordenado.

La recompensa es medible. En SIFT 1M (128-dim, recall ≈ 0.99) una consulta única sostiene ~356 qps, y el índice es 14–21× más pequeño que los índices HNSW contra los que se mide — lo bastante pequeño para caber en una fracción de la RAM, justo al lado de tu SQL. Bajo carga concurrente se mantiene en torno a ~700 qps con ocho núcleos. Y la construcción es paralela y en streaming: el dataset nunca se materializa por completo en memoria, así que escala a decenas de millones de vectores en una máquina modesta en lugar de exigir una dimensionada para todo el corpus de golpe.

Por qué importa un solo fichero

Todo junto, esto es el argumento entero de Arkeion en miniatura. SQL, texto completo y vectores son un fichero, no tres sistemas: ningún pipeline de indexación que ejecutar, ningún servicio que mantener sincronizado, ninguna copia de tus datos saliendo de la frontera que tú controlas. Cada parte está versionada, así que la búsqueda puede viajar en el tiempo; cada parte está encadenada por hashes, así que verify() puede demostrar que el conjunto está intacto. La búsqueda dejó de ser algo que atornillas encima y pasó a ser algo que la base de datos simplemente es.

Consulta los benchmarks para ver todas las cifras, reportadas con honestidad — incluidos los sitios donde un motor dedicado sigue ganando.