Chroma: una base vectorial ligera para prototipos con embeddings

javi
Visualización de vectores y puntos en espacio multidimensional

Chroma es probablemente la base de datos vectorial más sencilla de adoptar en 2023. Si construyes un primer prototipo de búsqueda semántica o un Retrieval-Augmented Generation (RAG), Chroma te permite empezar en minutos sin desplegar infraestructura adicional. Cubrimos cuándo es la opción correcta, cuándo conviene saltar a algo más serio, y los patrones de uso típicos.

El problema que resuelve

Una vector database indexa vectores numéricos (embeddings) y permite buscar los más similares a un vector de consulta usando distancias como coseno o euclídea. Es el componente clave de cualquier sistema RAG: dado un texto de pregunta, encontrar los fragmentos más relacionados en un corpus.

En 2023 hay muchas opciones — Pinecone (managed), Qdrant, Weaviate, Milvus, pgvector. Cada una optimiza distintos puntos del trade-off entre rendimiento, escalabilidad, features y simplicidad. Chroma se posiciona claramente del lado de la simplicidad.

Por qué Chroma destaca para prototipar

  • Cero infraestructura para arrancar. pip install chromadb y ya tienes una BD embebida que persiste a disco.
  • API mínima y consistente. add, query, delete. No hay 20 conceptos a aprender.
  • Generación de embeddings integrada. Por defecto usa sentence-transformers para vectorizar texto, opcionalmente OpenAI Embeddings o cualquier función custom.
  • Integración nativa con LangChain y LlamaIndex. Plug-and-play para los frameworks RAG dominantes.
  • Modos de despliegue gradual. Empieza embebido, escala a cliente-servidor con chroma run, eventualmente a producción.

Esto la hace ideal para validar una idea o construir una primera versión sin bloquearte en decisiones de infraestructura.

Un ejemplo mínimo

import chromadb

client = chromadb.Client()
collection = client.create_collection(name="docs")

collection.add(
    documents=["El kernel de Linux acepta Rust desde 6.1",
               "OpenTofu es el fork comunitario de Terraform"],
    metadatas=[{"tag": "kernel"}, {"tag": "iac"}],
    ids=["d1", "d2"],
)

results = collection.query(
    query_texts=["Quiero saber sobre infrastructura como código"],
    n_results=1,
)
print(results)

Sin configurar embeddings explícitamente, Chroma genera un vector con su modelo por defecto y devuelve el documento más cercano semánticamente. Una funcionalidad similar en otras bases vectoriales requiere más código para arrancar.

Limitaciones que conviene conocer

Chroma es excelente para empezar; es honesto sobre dónde no es la mejor opción:

  • Escala limitada. Su arquitectura no está diseñada para cientos de millones de vectores. Si tu corpus crece más allá de unos cuantos millones, Qdrant o Milvus escalan mejor.
  • Ausencia de filtros complejos avanzados. Los filtros por metadatos son básicos; no hay indexado avanzado al estilo de Weaviate.
  • Sin replicación nativa. La versión cliente-servidor de Chroma corre como proceso único. Para alta disponibilidad necesitas envolver con tu propia capa.
  • Performance bajo carga concurrente. Está optimizado para uso típico de prototipo o RAG de tamaño medio, no para QPS altos sostenidos.

Si tu caso de uso requiere alguno de los puntos anteriores, no es la herramienta. Si tu caso es “necesito buscar entre 100.000 documentos para un asistente RAG interno”, probablemente sea perfecta.

Patrones comunes de RAG con Chroma

La estructura típica que aparece en proyectos:

  1. Ingestión. Cargar documentos (PDF, markdown, web), partirlos en chunks de 200-1000 tokens, generar embeddings, guardar en Chroma con metadatos (fuente, fecha, autor).
  2. Consulta. Recibir pregunta, generar su embedding, buscar top-k chunks más similares (típicamente k=3-5).
  3. Composición de prompt. Construir un prompt para el LLM con la pregunta + contexto recuperado + instrucciones.
  4. Respuesta. El LLM responde basándose en el contexto, citando fuentes si corresponde.

Frameworks como LangChain encapsulan este flujo en pocas líneas, con Chroma como retriever sustituible por cualquier otra BD vectorial el día que crezcas.

Cuándo migrar a otra cosa

Señales claras de que has superado a Chroma:

  • Latencia consistentemente alta (>200ms) en queries.
  • Memoria del proceso saturándose durante búsquedas grandes.
  • Necesidad de búsqueda híbrida (vectorial + keyword + filtros) para mejorar relevancia — aquí brilla Weaviate.
  • Múltiples instancias servidor sin replicación nativa.
  • Compliance que exige BD gestionada con SLA — aquí Pinecone u otras opciones managed.

La migración suele ser razonable porque tu lógica de RAG queda casi igual: cambias la implementación del retriever, no el resto del pipeline. Por eso conviene estructurar el código con esa abstracción desde el principio.

Conclusión

Chroma es la elección por defecto para empezar con embeddings en 2023, especialmente si construyes un primer RAG o experimento. Su simplicidad acelera la fase de exploración cuando no quieres bloquearte en infraestructura. Cuando el proyecto crezca y aparezcan necesidades de escalado, replicación o búsqueda avanzada, hay opciones más maduras a las que migrar — pero esa migración llegará después de haber validado el concepto, no antes.

Síguenos en jacar.es para más sobre IA generativa, RAG y herramientas para prototipar rápido.

Entradas relacionadas