> For the complete documentation index, see [llms.txt](https://public-intelligence.gitbook.io/taina-agente-ia-ogtic/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://public-intelligence.gitbook.io/taina-agente-ia-ogtic/recomendaciones/recomendaciones/guia-de-produccion-para-chromadb.md).

# Guía de producción para ChromaDB

La base vectorial ChromaDB permite dar “memoria” a asistentes de voz o sistemas RAG mediante embeddings, búsquedas de similitud, filtrado por metadatos y persistencia.\
Aquí presentamos los *principales patrones de despliegue en producción*, cuándo usar cada uno, sus ventajas y cuándo “rompen”.

### 0. Modelo mental base

El sistema típico se compone de:

1.⁠ ⁠STT → transcripción\
2.⁠ ⁠LLM (planner / intent / retrieval-augmented reasoning) → la parte de retrieval usa ChromaDB\
3.⁠ ⁠Escrituras en DB / herramientas / memoria\
4.⁠ ⁠LLM responde\
5.⁠ ⁠TTS

ChromaDB se coloca en el paso 2 (y en algunos casos también como memoria histórica) pero lo que varía es dónde se ejecuta, quién escribe, cómo se escala.

### 1. Patrón “Embedded / in-process”

*Qué es*: El cliente de Chroma (SDK) está embebido en la aplicación, corre en el mismo proceso o contenedor y persiste en volumen local (por ejemplo DuckDB/parquet)\
\&#xNAN;*Cuándo sirve*: escenarios de hasta decenas de millones de embeddings, baja concurrencia, despliegue simple.\
\&#xNAN;*Cuándo no sirve*: cuando necesitas múltiples réplicas, aislamiento por cliente, alta disponibilidad.\
\&#xNAN;*Documentación oficial relevante*: ver “Chroma Clients” para configuración local.

### 2. Patrón “Chroma como servicio central”

*Qué es*: Se ejecuta Chroma como microservicio o conjunto de pods contenedores, con API (HTTP/gRPC) y almacenamiento persistente, al que acceden los servicios de inferencia vía red.\
\&#xNAN;*Ventajas*: separación de responsabilidades, escalabilidad del motor de inferencia, backups centralizados.\
\&#xNAN;*Cuándo llega su límite*: cuando la instancia única de Chroma se convierte en cuello de botella (memoria, concurrencia, latencia).

### 3. Patrón “Sharded / multi-tenant”

#### 3A – Tenant-por-shard

Cada cliente empresarial tiene su propia instancia o colección dedicada.\
\&#xNAN;*Ventajas*: aislamiento, escalabilidad independiente por cliente, contención de fallos.\
\&#xNAN;*Desventajas*: infra más compleja, análisis global más difícil.

#### 3B – Sharding semántico (por dominio)

Se separan embeddings por dominio (“producto”, “facturación”, “memoria usuario”), y cada shard tiene su propia instancia.\
\&#xNAN;*Ventajas*: memoria caliente en hardware rápido, conocimiento frío en hardware más barato.\
\&#xNAN;*Consulta*: router decide qué shards consultar, ejecuta en paralelo y combina resultados.

El apartado “Deployment Patterns” del Cookbook de la documentación oficial cubre variantes de despliegue que permiten construir estos modelos.

### 4. Patrón “Chroma como caché semántica frente a backend vectorial a gran escala”

*Qué es*: Chroma se convierte en un caché rápido (in-memory + SSD) para el conjunto de trabajo actual del asistente. El corpus completo vive en otro sistema escalable (ej. Milvus, Weaviate, Pinecone, etc.).\
\&#xNAN;*Arquitectura típica*:\
•⁠ ⁠*Tier 1*: Chroma local (< 5 ms)\
•⁠ ⁠*Tier 2*: Vector DB global (\~40-100 ms)\
•⁠ ⁠*Refill*: Si Chroma falla en recall, recupera del Tier 2.\
\&#xNAN;*Usos*: cientos de miles de usuarios activos diarios, latencias de voz estrictas.\
\&#xNAN;*Desafíos*: invalidez de caché, gobernanza estricta (no mezclar datos entre tenants).

### 5. Actualizaciones event-driven / streaming en Chroma

Aunque no sea un “topología” en sí, es una modalidad de operación clave en producción:\
•⁠ ⁠Ingestas de memoria (embeddings, blobs de resumen, resultados de tools) por cola de eventos (Kafka, Pub/Sub, Kinesis).\
•⁠ ⁠Procesamiento de workers asíncronos que hacen upsert en Chroma.\
\&#xNAN;*Beneficios*: evita bloqueos síncronos en pods de inferencia, permite replay de eventos, mejora durabilidad.\
Relacionado con doc oficial: en la sección “Optimizing Performance” se mencionan estrategias de ingestión por lotes

Para más información, visitar la documentación oficial de ChromaDB: [Chroma Docs: Introduction](https://docs.trychroma.com/)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://public-intelligence.gitbook.io/taina-agente-ia-ogtic/recomendaciones/recomendaciones/guia-de-produccion-para-chromadb.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.