Chroma: una base vectorial ligera para prototipos con embeddings

Actualizado: 2026-05-03

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

Puntos clave

• pip install chromadb y tienes una BD embebida que persiste a disco — sin infraestructura adicional.
• API mínima: add, query, delete. Generación de embeddings integrada por defecto con sentence-transformers.
• Integración nativa con LangChain y LlamaIndex como retriever sustituible.
• Límite práctico: corpus de unos pocos millones de vectores; por encima, Qdrant o Milvus escalan mejor.
• Señal de migración: latencia >200 ms en queries o necesidad de búsqueda híbrida avanzada.

El problema que resuelve

Una base de datos vectorial 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 el ecosistema actual 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; soporta 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 infraestructura 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 honesta sobre dónde no es la mejor opción:

• Escala limitada. Su arquitectura no está diseñada para cientos de millones de vectores. Si el corpus supera unos cuantos millones, Qdrant o Milvus escalan mejor.
• Filtros por metadatos básicos. No hay indexado avanzado al estilo de Weaviate para filtros complejos.
• Sin replicación nativa. La versión cliente-servidor corre como proceso único. Para alta disponibilidad necesitas envolver con tu propia capa.
• Performance bajo carga concurrente alta. 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 estos puntos, 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 cuando crezcas. Para entender en profundidad qué modelos de embedding elegir antes de indexar, ver el artículo sobre embeddings de texto aplicados.

Cuándo migrar a otra cosa

Señales claras de que has superado a Chroma:

• Latencia consistentemente alta (>200 ms) 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 — exactamente lo que hacen los wrappers de LangChain.

Conclusión

Chroma es la elección por defecto para empezar con embeddings, 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.

1. Chroma