Base de datos para IA: qué es y cuándo la necesitas

Esta página te da la versión corta de qué es una base de datos para IA, te dice cuándo no la necesitas y te muestra una consulta que hace tres pasos de IA en un solo SELECT.

Construimos SynapCores, una base de datos nativa para IA. La idea es que esta página te sirva elijas la herramienta que elijas, incluido el caso en que no necesitas una.

Qué es una base de datos para IA

Hoy la mayoría de las funciones de IA se arman por partes:

• Tus filas viven en Postgres o MySQL.
• Tu aplicación manda texto a una API de embeddings y guarda los vectores en una base de datos vectorial aparte.
• Para las predicciones llama a un servicio de modelos.

Cada flecha entre esos sistemas es un trabajo que hay que correr, vigilar y mantener sincronizado.

Una base de datos para IA mete esos pasos en el motor de consultas. Una sola sentencia SQL puede filtrar filas por columnas normales, convertir una pregunta en embedding, ordenar filas por significado y puntuar el resultado con un modelo. Los datos no salen del motor y un solo esquema de permisos cubre todo.

Esa es toda la idea. No hace más inteligentes a los modelos; son el mismo tipo de modelos que podrías correr en Python. Lo que cambia es dónde corren y cuántos sistemas operas. Vale la pena cuando una pregunta necesita varios pasos de IA sobre datos vivos y con permisos.

Base de datos para IA vs. plataforma de datos para IA

Base de datos para IA: un solo motor que guarda tus datos y ejecuta los pasos de IA (embeddings, búsqueda por similitud, puntuación con modelos) dentro de la consulta.

Plataforma de datos para IA: todo el stack alrededor de tus datos. Incluye ingesta, pipelines, almacenamiento, gobierno de datos, servicio de modelos y las interfaces que usan tus apps y agentes. Normalmente son varios sistemas.

Dónde está SynapCores: es la capa de base de datos. Un solo binario self-hosted ejecuta SQL, búsqueda vectorial, un motor de grafos y AutoML dentro de la base de datos. Expone:

• una API REST;
• preguntas en lenguaje natural con /v1/ask;
• memoria para agentes en SQL: CREATE MEMORY, REMEMBER, CURRENT, RECALL y TRACE (cómo funciona);
• un servidor MCP integrado para que agentes como Claude Code consulten tus datos.

También exporta tablas a Parquet con COPY TO LAKE y las vuelve a consultar. Si estás armando una plataforma, es la pieza que consultan tus apps y agentes de IA.

Cuándo NO la necesitas

Sé honesto contigo. Probablemente no necesitas una base de datos para IA si:

• Solo necesitas búsqueda semántica y ya usas Postgres. pgvector es maduro, lo ofrecen muchos hostings y está bien documentado. Calcula los embeddings en tu app o en un trabajo por lotes y listo.
• Tus modelos necesitan GPU o son muy grandes. Los LLM ajustados, la generación de imágenes y los modelos grandes de deep learning van en infraestructura de inferencia dedicada.
• Ya tienes una plataforma de ML que funciona. Si tu equipo entrena, despliega y monitorea modelos bien en Python, pasarlo a una base de datos es una migración con costo, no una ganancia gratis.
• Necesitas el mejor componente de su clase a escala muy grande. Una base de datos vectorial o un motor de búsqueda dedicado puede afinarse más para ese único trabajo.
• Solo quieres un chatbot sobre unos documentos. Una librería de rag, un almacén vectorial administrado y la API de un LLM pueden llevarte ahí más rápido, y lo revisas después.

Pruébalo: filtrar, buscar y verificar en una sentencia

Este ejemplo corre en SynapCores 2.4.8-ce. Hace tres cosas en un solo SELECT:

1. un filtro SQL normal;
2. un orden por similitud vectorial con un embedding calculado dentro de la consulta;
3. una verificación de implicación con un modelo NLI local.

Con Postgres + pgvector, el embedding y el modelo NLI tendrían que correr fuera de la base de datos.

Instala y activa el modelo NLI (viene apagado; son unos 577 MB):

curl -fsSL https://get.synapcores.com | sh
synapcores --config /etc/synapcores/gateway.toml pull nli-default
synapcores --config /etc/synapcores/gateway.toml models enable-nli nli-default
# restart the engine; GET /v1/ai/nli/models then reports state "ready"

Datos de prueba: cuatro fragmentos de una política de facturación y una entrada de preguntas frecuentes que no tiene nada que ver.

CREATE TABLE IF NOT EXISTS learn_kb (
    id INT PRIMARY KEY,
    section TEXT,
    body TEXT,
    embedding VECTOR(384)
);

INSERT INTO learn_kb (id, section, body, embedding) VALUES
  (1, 'billing-policy#refunds', 'Annual plans can be refunded in full within 30 days of purchase.',
      EMBED('Annual plans can be refunded in full within 30 days of purchase.')),
  (2, 'billing-policy#refunds', 'After 30 days, annual plans are refunded pro rata for the unused full months.',
      EMBED('After 30 days, annual plans are refunded pro rata for the unused full months.')),
  (3, 'billing-policy#refunds', 'Monthly plans are not refundable.',
      EMBED('Monthly plans are not refundable.')),
  (4, 'billing-policy#payouts', 'Refunds are issued to the original payment method within 5 to 10 business days.',
      EMBED('Refunds are issued to the original payment method within 5 to 10 business days.')),
  (5, 'office-faq', 'The support office is closed on public holidays.',
      EMBED('The support office is closed on public holidays.'));

Resultado en 2.4.8-ce: rows_affected = 5.

La consulta: solo fragmentos de facturación, ordenados por significado, y cada uno comparado con la respuesta borrador "Refunds arrive within 5 to 10 business days.":

SELECT id, section,
       ROUND(COSINE_SIMILARITY(embedding, EMBED('How long do refunds take?')), 3) AS similarity,
       ROUND(CAST(JSON_EXTRACT(NLI_CLASSIFY('nli-default', body,
             'Refunds arrive within 5 to 10 business days.'),
             '$.scores.entailment') AS DOUBLE), 3) AS supports_answer
FROM learn_kb
WHERE section LIKE 'billing-policy%'
ORDER BY similarity DESC
LIMIT 3;

Resultado en 2.4.8-ce (build 575):

Qué mirar:

• El WHERE saca la entrada de la oficina antes de que empiece cualquier trabajo de IA.
• El fragmento de pagos queda primero, y es el único que respalda la respuesta borrador.

Esa última columna es una señal distinta de la similitud: un fragmento puede parecerse mucho a la pregunta y aun así no respaldar la respuesta.

Limpieza:

DROP TABLE IF EXISTS learn_kb;

Problemas que resuelve, por tarea

Cada guía resuelve un problema y explica la técnica que usa. Por ahora están en inglés, salvo la marcada.

Encontrar cosas (búsqueda vectorial, más filtros SQL y grafos)

• Buscar por significado y no por palabras clave (en inglés): EMBED + COSINE_SIMILARITY junto a filtros WHERE normales.
• Encontrar registros de clientes duplicados, aunque tengan errores (en inglés): similitud de embeddings más agrupación en SQL.

Responder con tus datos (LLM)

• Dejar que un LLM consulte tu base de datos sin exponer datos personales (en inglés): permisos por columna en la clave de API.

Recordar (memoria para agentes)

• Memoria para agentes de IA: tipos y cómo construirla (en español).
• Cómo hacer que un chatbot recuerde conversaciones anteriores (en inglés).

Verificar afirmaciones (NLI)

• Comprobar si una respuesta de IA está respaldada por tus documentos (en inglés): un umbral de similitud + NLI por frase, como en la consulta de arriba.

Predecir y marcar (machine learning dentro de la base de datos)

• Encontrar transacciones inusuales con SQL (en inglés): ANOMALY_SCORE más un salto de grafo para encontrar anillos de fraude.

Siguiente paso

• Sin instalar nada: el Playground puntúa pagos con un modelo de ML, recorre un grafo de fraude y busca notas por significado, todo en el navegador.
• En tu máquina: descarga la Community Edition gratis (sin registro ni tarjeta).
• Para tus agentes: memoria para agentes de IA.
• La página principal en español: la base de datos para IA que corre en tu máquina.