Qué es una base de datos vectorial

Una base de datos vectorial no guarda solo texto, PDFs o registros tradicionales. Guarda también embeddings, es decir, representaciones numéricas de un contenido. Esos vectores permiten buscar por significado y no solo por palabras exactas. En la API de OpenAI, una embedding se devuelve como una lista de números flotantes, y entre los modelos disponibles para esta tarea están text-embedding-3-small y text-embedding-3-large.

Eso cambia mucho las reglas del juego. En una base de datos clásica, si buscas “error al entrar”, puede que no encuentres un documento que diga “no puedo iniciar sesión”. En una base vectorial, ambos textos pueden quedar cerca porque expresan una idea parecida. Por eso este tipo de base es tan útil para buscadores semánticos, recomendadores, asistentes con documentación interna y sistemas RAG. La propia extensión pgvector para PostgreSQL está pensada precisamente para búsqueda de similitud vectorial y soporta búsqueda exacta y aproximada de vecinos cercanos.

Qué es el etiquetado de datos y por qué importa

El etiquetado de datos consiste en añadir una interpretación humana a los ejemplos. Un texto como “me habéis cobrado dos veces” puede llevar la etiqueta facturacion; otro como “no recuerdo mi contraseña” puede llevar acceso; y además ambos pueden recibir una segunda etiqueta de urgencia como alta, media o baja. Ese proceso convierte datos crudos en datos útiles para entrenar, evaluar o corregir modelos. Herramientas como Label Studio están orientadas justamente a eso: crear proyectos de etiquetado, trabajar con distintos tipos de datos y exportar anotaciones para usarlas después en flujos de machine learning.

Dicho de forma simple: la base vectorial ayuda a encontrar; el etiquetado ayuda a decidir. Una recupera contexto parecido; la otra enseña al sistema cuál es la clasificación correcta, la prioridad adecuada o la respuesta esperada.

La diferencia que de verdad importa

Mucha gente mezcla ambos conceptos y piensa que son lo mismo. No lo son.

Una base vectorial responde a preguntas como estas:

• “¿Qué documentos se parecen a esta consulta?”
• “¿Qué tickets antiguos son similares a este problema nuevo?”
• “¿Qué párrafos debo recuperar para dar contexto al modelo?”

El etiquetado responde a otras:

• “¿Este ticket es de facturación o de acceso?”
• “¿Esta reseña es positiva, neutra o negativa?”
• “¿Este ejemplo es correcto o incorrecto para entrenar el modelo?”

Cuando juntas ambos enfoques, puedes recuperar ejemplos parecidos y, además, usar sus etiquetas para automatizar decisiones con bastante más criterio.

Caso práctico: un sistema para tickets de soporte

Imagina que tienes una empresa y cada día recibes mensajes como estos:

• “No puedo acceder a mi cuenta”
• “Me habéis duplicado el cobro”
• “La web va lentísima”
• “Quiero cambiar el plan contratado”
• “He recibido un error al subir una factura”

Aquí hay dos problemas distintos.

El primero es buscar contexto útil: cuando entra un ticket nuevo, quieres recuperar incidencias parecidas para ver cómo se resolvieron antes.

El segundo es clasificar el ticket: quieres saber si pertenece a acceso, facturación, incidencias técnicas o ventas, y además si la urgencia es alta, media o baja.

La arquitectura más sencilla sería esta:

1. Guardas cada ticket y su embedding en una base vectorial.
2. Añades etiquetas humanas a una parte de esos tickets.
3. Cuando llega uno nuevo, buscas los más parecidos.
4. Con esos vecinos cercanos puedes ayudar a un agente humano, alimentar un asistente o incluso entrenar un clasificador.

Ese patrón es muy potente porque no exige empezar con un sistema enorme. Puedes arrancar con pocas decenas o cientos de ejemplos y crecer poco a poco.

Cómo empezar con una base de datos vectorial sencilla

Para un prototipo pequeño, una opción cómoda es Chroma, porque permite trabajar en memoria o con almacenamiento persistente local, y está pensada para almacenar e indexar embeddings. Para un entorno donde ya usas PostgreSQL y quieres tener vectores junto al resto de tus datos, pgvector es una opción muy práctica porque añade búsqueda vectorial a Postgres y mantiene ventajas como JOINs y consistencia transaccional.

Ejemplo mínimo con Python + Chroma + embeddings

# pip install openai chromadbfrom openai import OpenAIimport chromadbclient = OpenAI()chroma = chromadb.PersistentClient(path="./mi_vector_db")coleccion = chroma.get_or_create_collection(name="tickets_soporte")tickets = [    {        "id": "1",        "texto": "No puedo acceder a mi cuenta desde esta mañana",        "categoria": "acceso",        "urgencia": "alta"    },    {        "id": "2",        "texto": "Me habéis cobrado dos veces la suscripción mensual",        "categoria": "facturacion",        "urgencia": "alta"    },    {        "id": "3",        "texto": "La web tarda mucho en cargar cuando entro al panel",        "categoria": "incidencia_tecnica",        "urgencia": "media"    },    {        "id": "4",        "texto": "Quiero información sobre un plan superior",        "categoria": "ventas",        "urgencia": "baja"    }]def crear_embeddings(textos):    resp = client.embeddings.create(        model="text-embedding-3-small",        input=textos    )    return [item.embedding for item in resp.data]documentos = [t["texto"] for t in tickets]embeddings = crear_embeddings(documentos)coleccion.add(    ids=[t["id"] for t in tickets],    documents=documentos,    embeddings=embeddings,    metadatas=[        {            "categoria": t["categoria"],            "urgencia": t["urgencia"]        }        for t in tickets    ])consulta = "No me deja iniciar sesión en el panel"embedding_consulta = crear_embeddings([consulta])[0]resultados = coleccion.query(    query_embeddings=[embedding_consulta],    n_results=3)print("Documentos parecidos:")for doc, meta in zip(resultados["documents"][0], resultados["metadatas"][0]):    print("-", doc, "=>", meta)

Este ejemplo hace algo muy importante: guarda el texto, la embedding y además las metadatas. Esas metadatas pueden incluir etiquetas como categoría, urgencia, idioma, producto o canal de entrada. Chroma documenta tanto el uso local como las funciones de embeddings, y la API de embeddings de OpenAI devuelve precisamente los vectores que luego puedes almacenar y consultar.

Cómo hacer un etiquetado sencillo sin complicarte

Para empezar, no necesitas una plataforma compleja. Puedes comenzar con un CSV o una hoja de cálculo con columnas como estas:

texto,categoria,urgencia,estado"No puedo entrar en mi cuenta","acceso","alta","revisado""Se ha duplicado el cobro de marzo","facturacion","alta","revisado""La página tarda demasiado","incidencia_tecnica","media","revisado""Quiero saber precios enterprise","ventas","baja","revisado"

Con algo tan simple como eso ya puedes construir un primer dataset útil. Lo importante es que las etiquetas estén bien definidas.

Un esquema sencillo de etiquetas

Para tickets de soporte, un esquema inicial razonable podría ser:

• categoria: acceso, facturacion, incidencia_tecnica, ventas
• urgencia: baja, media, alta
• requiere_humano: si, no

Con estas tres columnas ya puedes resolver bastante. No conviene empezar con veinte etiquetas. Lo normal es arrancar con pocas clases, claras y mutuamente distinguibles.

Reglas prácticas para etiquetar bien

Aquí suele estar la diferencia entre un sistema que parece listo y uno que realmente funciona.

Primera regla: define las etiquetas antes de anotar. No empieces a etiquetar “a ojo”. Escribe una mini guía de dos o tres líneas por etiqueta.

Segunda regla: separa etiquetas de metadatos. categoria o urgencia son decisiones humanas. fecha, idioma o canal suelen ser metadatos objetivos.

Tercera regla: crea ejemplos frontera. Por ejemplo, “quiero cambiar mi plan porque el actual falla” podría ser ventas o incidencia. Ese tipo de ejemplos debe quedar documentado en tu guía.

Cuarta regla: revisa una muestra. Aunque empieces solo, revisa tus primeras 50 o 100 anotaciones. Muchas veces ahí aparece la ambigüedad del esquema.

Si quieres una interfaz más profesional, Label Studio encaja muy bien porque es open source, permite trabajar con distintos formatos de datos, seguir instrucciones de proyecto, colaborar entre anotadores y exportar anotaciones para reutilizarlas en tus modelos o pipelines.

Cómo se combinan la base vectorial y el etiquetado en un flujo real

Un flujo muy realista para una pyme sería este:

Fase 1. Reúnes entre 100 y 500 textos reales. Fase 2. Los limpias un poco y eliminas duplicados evidentes. Fase 3. Etiquetas manualmente una parte. Fase 4. Generas embeddings y los guardas en tu base vectorial. Fase 5. Cuando entra un texto nuevo, recuperas los 3 o 5 más parecidos. Fase 6. Usas esas coincidencias para ayudar a clasificar, responder o escalar el caso.

Eso ya te permite hacer tres cosas muy útiles sin montar un sistema gigantesco:

• un buscador semántico interno,
• un asistente con contexto,
• un clasificador básico apoyado por ejemplos similares.

Un caso práctico todavía más simple

Supón que quieres montar un mini asistente para una academia online.

Tienes preguntas frecuentes como:

• “No puedo ver el curso”
• “La factura no me llega”
• “¿Dónde descargo el certificado?”
• “Quiero cambiar mi contraseña”

Lo que harías sería:

1. Guardar cada FAQ y cada ticket resuelto en la base vectorial.
2. Etiquetar cada uno con categoria.
3. Cuando llegue una consulta nueva, buscar las preguntas más similares.
4. Mostrar al agente humano o al sistema automático la respuesta parecida y la categoría probable.

Con eso, aunque no tengas todavía un gran modelo entrenado a medida, ya ganas tiempo, consistencia y velocidad de respuesta.

Errores comunes al empezar

El error más habitual es pensar que una base vectorial “entiende” tu negocio por sí sola. No. Solo encuentra cercanía matemática entre representaciones. Si el contenido está mal escrito, mal troceado o mal etiquetado, el sistema heredará ese problema.

El segundo error es crear demasiadas etiquetas desde el primer día. Eso genera ruido, dudas y anotaciones inconsistentes.

El tercero es no revisar resultados reales. Un prototipo de IA no se valida con una demo bonita, sino con casos de uso de verdad: tickets reales, consultas reales y decisiones reales.

Conclusión

Si lo quieres ver de forma muy clara, la idea central es esta:

• la base de datos vectorial te ayuda a recuperar significado,
• el etiquetado de datos te ayuda a convertir significado en decisión.

Una encuentra contexto; la otra construye criterio. Juntas forman una base excelente para asistentes internos, clasificación de incidencias, buscadores semánticos y sistemas RAG que de verdad aporten valor.

Para empezar no necesitas una arquitectura compleja. Con una colección pequeña de textos, un esquema simple de etiquetas y una base vectorial local ya puedes construir un primer sistema útil. Después, cuando el proyecto madure, podrás pasar a PostgreSQL con pgvector, ampliar tu esquema de anotación o incorporar revisión humana y aprendizaje activo.

— Toni Domenech