Me complace anunciar la primera versión pública de pg_infer, una extensión para PostgreSQL 18 y superiores que permite exponer los elementos internos de pequeños modelos de lenguaje basados en transformers —incluyendo activaciones de compuertas, etiquetas de características, asociaciones aprendidas y embeddings (representaciones vectoriales)— como relaciones consultables mediante SQL, así como mediante un método de acceso a índices personalizado.

pg_infer no constituye un sistema de “lenguaje natural a SQL”, ni de “SQL a lenguaje natural”. No incorpora una interfaz conversacional, ni un bucle de agente, ni plantillas de prompts destinadas a generar consultas. pg_infer integra la inferencia del modelo dentro del plan de ejecución como un operador que el planificador puede evaluar en términos de coste, programar, paralelizar y combinar con predicados y operaciones de joins convencionales. El modelo se convierte en una fuente de datos de primera clase —un conjunto de relaciones que el planificador puede explorar, filtrar y combinar— y deja de ser un servicio externo con el que la base de datos interactúa.

Breve ejemplo

-- Register a vindex (extracted model knowledge):
`SELECT infer_create_model('qwen05b', '/data/qwen-0.5b.vindex');`

-- What does the model know about France?

SELECT * FROM describe('France'); -- relation | target | confidence | layer -- -----------+-----------+------------+------- -- capital | Paris | 42.7 | 18 -- language | French | 38.1 | 17 -- continent | Europe | 35.4 | 16 -- ...

-- `ORDER BY` model-knowledge similarity:

«` CREATE INDEX ON documents USING infer (title) WITH (model = ‘qwen05b’);

SELECT * FROM documents
 ORDER BY title <~> 'artificial intelligence'
 LIMIT 5;

«`

El operador <~> se encuentra respaldado por índices, admite la instrucción EXPLAIN (ANALYZE, BUFFERS) y se integra con cláusulas como WHERE, JOIN, agregación y particionamiento de la misma manera que cualquier otro operador.

Lo que hace pg_infer que otras extensiones no hacen

• pgvector / pgvectorscale permite el almacenamiento de vectores de embedding suministrados por el usuario y la ejecución de consultas de distancia basadas en vecinos más cercanos. pg_infer opera a un nivel más profundo, ya que almacena el propio modelo —incluyendo vectores de compuerta, activaciones de características y metadatos de etiquetas— en páginas de 8 KB con registro en WAL, y posibilita responder a cuestiones tales como “¿el modelo considera que A y B están relacionados?”, en lugar de limitarse a “¿estos dos embeddings presentan proximidad?”
• Las integraciones de tipo pg_search y los enfoques RAG convierten las consultas de los usuarios en operaciones de búsqueda mediante embeddings sobre almacenes vectoriales externos. Por su parte, pg_infer expone la estructura interna del modelo directamente a SQL: la función walk(prompt) retorna las activaciones de características por cada capa; describe(entity) devuelve las relaciones que el modelo ha aprendido respecto de una entidad; e implies(a, b) permite evaluar la existencia de soporte direccional entre ambos elementos.
• El access method de índices de pg_infer se ofrece en dos modos de funcionamiento:
  • En el modo “model”, el índice completo (vindex) se registra en el WAL dentro de las páginas de PostgreSQL, garantizando que las operaciones de respaldo, replicación y recuperación a un punto en el tiempo incluyan el modelo de la misma manera que lo hacen con las tablas.
  • En el modo “column”, se asocia un modelo a una columna de texto, permitiendo que las operaciones ORDER BY <~> sobre dicha columna sean ejecutadas de forma indexada.
• El backend local basado en mmap permite que múltiples procesos de PostgreSQL compartan, mediante el caché de páginas del sistema operativo, las páginas del modelo ya decodificadas. Por su parte, el backend remoto (larql-server / larql-router a través de HTTP/2 o de un socket Unix) mantiene una única copia del modelo en cada host y admite enrutamiento con particionado por capas. Las llamadas remotas en curso responden a la función pg_cancel_backend(…) en aproximadamente 100 milisegundos.

Inferencia en CPU, BitNet y cómputo en clústeres inactivos

Los servidores de bases de datos rara vez disponen de unidades GPU. En su lugar, cuentan con numerosos núcleos de alto rendimiento y grandes cantidades de memoria RAM y, en la mayoría de implementaciones en producción, incluyen réplicas standby, réplicas físicas de solo lectura, suscriptores lógicos y servidores de recuperación ante desastres que permanecen la mayor parte del tiempo con una utilización de CPU de un solo dígito, mientras el servidor primario concentra la carga de escritura.

pg_infer y las crates subyacentes de larql están diseñados específicamente para este perfil de hardware:

• Los flujos de ejecución predeterminados operan de manera eficiente sobre CPU, apoyándose en operaciones de álgebra lineal aceleradas mediante BLAS (OpenBLAS) y en vectores de compuertas en precisión f16 que se decodifican de forma diferida a f32.
• pg_infer / larql admiten modelos pertenecientes a la familia Microsoft BitNet b1.58 (“transformadores ternarios de dos bits / 1.58 bits”, https://arxiv.org/abs/2402.17764), los cuales han sido diseñados específicamente para su ejecución en procesadores de uso general, alcanzando una calidad competitiva con un consumo de memoria y energía significativamente inferior al de los modelos base en f16. En combinación con activaciones de compuertas en f16, este enfoque permite realizar inferencia dentro de un backend de PostgreSQL sin requerir aceleradores de hardware especializados.
• El modelo de clúster constituye el elemento fundamental. Una implementación típica de PostgreSQL orientada a alta disponibilidad (HA), recuperación ante desastres (DR) o escalado de lecturas dispone de un nodo primario intensamente utilizado y de una o varias réplicas físicas que permanecen, en gran medida, inactivas, junto con, de manera creciente, un conjunto de suscriptores lógicos. Dichas réplicas ya justifican su coste mediante la provisión de disponibilidad; sin embargo, sus CPUs se encuentran infrautilizadas la mayor parte del tiempo. Mediante el backend remoto de pg_infer, larql-server se ejecuta en los nodos réplica y proporciona operadores de modelo a los planes de ejecución de consultas del nodo primario. El modelo se materializa una única vez por host, la caché de activaciones es compartida y el procesamiento se realiza sobre capacidad previamente adquirida. No se requiere GPU, ni un clúster de inferencia independiente, ni tráfico adicional de salida de red.

Algunas consultas exclusivas de pg_infer

• Un sistema de ordenación de documentos consciente del modelo que no se basa en la coincidencia de palabras clave ni en embeddings previamente calculados:

SELECT id, title FROM papers ORDER BY title <~> 'neural architecture search' LIMIT 10;

This finds "AutoML for Deep Networks" because the model
learned that relationship -- pg_trgm cannot, FTS cannot,
and pgvector can only do so if you computed and stored
embeddings ahead of time with a model whose semantics
happen to agree with your query.

• Vinculación del conocimiento del modelo con datos relacionales:

SELECT c.id, c.name, p.title, p.title <~> c.research_interest AS dist FROM candidates c JOIN papers p ON p.title <~> c.research_interest < 0.2 WHERE c.country = 'DE';

Standard SQL semantics, standard PostgreSQL planner, plus
a model-driven join condition.

• Explorar el conocimiento de un modelo sin necesidad de ejecutarlo:

SELECT relation, target, confidence FROM describe('PostgreSQL') WHERE confidence > 30;

• Auditoría del comportamiento del modelo a lo largo del tiempo. Dado que el vindex se almacena en páginas registradas mediante WAL, la recuperación a un punto en el tiempo (PITR) en un clúster que utilice pg_infer permite reconstruir el estado del modelo en cualquier momento histórico, conjuntamente con el estado de los datos. La pregunta “¿qué afirmaba el modelo acerca de esta entidad a las 03:14 UTC del martes pasado?” constituye, en sentido estricto, una consulta de tipo PITR combinada con describe(…).

Agradecimientos

El proyecto pg_infer no habría sido posible sin el trabajo realizado en el proyecto LARQL por Chris Hayuk (https://github.com/chrishayuk). LARQL fue pionero en la propuesta de hacer accesibles y consultables los componentes internos de los modelos de tipo transformer, mediante la extracción de vectores de compuertas, activaciones de características y asociaciones aprendidas hacia un formato denominado «vindex», el cual permite su exploración interactiva y su expresión mediante un lenguaje de consulta. El formato vindex, el algoritmo de vecinos más cercanos (KNN) aplicado a compuertas y el proceso de etiquetado de características tienen su origen en LARQL; por su parte, pg_infer los adapta e integra como un método de acceso en PostgreSQL, una capa de almacenamiento con registro WAL y un operador visible para el planificador de consultas.

Si las ideas de LARQL resultan de su interés, les invitamos a consultar el trabajo original, así como las videoguías de Chris, en las que se explican en detalle el formato vindex, el algoritmo gate-KNN y el lenguaje de consultas LARQL:

• Chris Hayuk en YouTube: https://www.youtube.com/@chrishayuk
• Repositorio original de LARQL: https://github.com/chrishayuk/larql
• larql-rs (puerto Rust): https://github.com/chrishayuk/chuk-larql-rs

Gracias, Chris, por el trabajo de base y por la apertura en el diseño.

Una nota sobre estabilidad y feedback

pg_infer es un software de reciente creación. La superficie SQL, el método de acceso de índices, el protocolo de backend remoto y el conjunto de pruebas presentan la estabilidad suficiente para una versión 1.0.0, y el formato en disco del vindex mantiene compatibilidad hacia adelante; no obstante, se trata de un proyecto joven, y la combinación de PostgreSQL + pgrx + los componentes internos de los modelos transformer es suficientemente inusual como para que existan, con toda probabilidad, errores que las pruebas actuales aún no logran detectar. No se trata de una beta ni de un prototipo de investigación, sino de software real publicado en una fase temprana, por lo que debe utilizarse con la debida cautela.

Se agradecen mucho los reportes de errores, solicitudes de funcionalidades y pull requests, en particular aquellos que incluyan reproducciones, problemas de compatibilidad con vindex, regresiones en el costo del planificador y sugerencias de integración con otras extensiones de PostgreSQL.

Enlaces

• Repositorio:  https://codeberg.org/gregburd/pg_infer
• Issues:  https://codeberg.org/gregburd/pg_infer/issues
• LARQL:  https://github.com/chrishayuk/larql
• larql-rs:  https://github.com/chrishayuk/chuk-larql-rs

BitNet b1.58:  https://arxiv.org/abs/2402.17764