Chroma Context-1: Un subagente de búsqueda de 20 mil millones para un RAG agente más económico y preciso

En la mayoría de los sistemas RAG, la recuperación de información es el eslabón débil. Puedes utilizar GPT-4, Claude, Gemini o cualquier modelo de vanguardia en la capa superior, y si el paso de búsqueda devuelve datos inútiles, el modelo seguirá generando respuestas erróneas, pero seguras y bien redactadas.

Imagina una búsqueda en un documento legal donde la respuesta a una pregunta está distribuida en tres archivos, y el agente debe localizarlos todos. La configuración habitual consiste en un modelo de vanguardia dentro de un bucle ReAct con herramientas de búsqueda vectorial. Funciona, pero con un costo de aproximadamente 0,12 dólares y quince segundos por consulta, solo sirve como demostración y no como característica de un producto real. Context-1 de Chroma aborda exactamente ese problema de costo y latencia.

Qué es Context-1

Context-1 es un modelo de lenguaje con 20 mil millones de parámetros creado para una sola tarea: la recuperación de información. No genera respuestas finales ni realiza razonamientos generales. Solo busca.

En una configuración típica de RAG con agentes, un único modelo frontal hace todo: planifica qué buscar, realiza la búsqueda, decide si se necesita más información y escribe la respuesta. Eso es como contratar a un cirujano cerebral para que también haga las compras. En cambio, Context-1 actúa como un subagente de búsqueda dedicado que encuentra los documentos, mientras que un modelo frontal separado se encarga del razonamiento y la redacción. Se trata de una separación de responsabilidades aplicada a la arquitectura de IA.

El modelo está basado en gpt-oss-20B, un modelo base abierto, y se entrenó mediante ajuste fino supervisado seguido de aprendizaje reforzado usando el método CISPO de Chroma (Optimización de Políticas Muestreadas con Importancia Recortada). El resultado es un modelo pequeño que obtiene resultados muy superiores a los esperados para su tamaño en pruebas de recuperación de información.

Por qué el RAG con agentes convencional no es suficiente

Un pipeline clásico realiza un solo paso: se incrusta la pregunta, regresan los fragmentos de los top-K y un LLM escribe la respuesta.

User Query → Embedding Search → Top-K Chunks → LLM → Response

Eso presenta problemas bien conocidos. Se reciben fragmentos y nunca documentos completos, por lo que se pierde el contexto general. Una sola pasada no puede relacionar hechos dispersos en varios documentos. Además, la similitud semántica no es lo mismo que la relevancia, ya que un fragmento puede compartir vocabulario con la pregunta y aun así no responderla.

La actualización basada en agentes envuelve todo esto en un bucle ReAct, donde el modelo planifica, busca, examina los resultados y decide si debe buscar de nuevo.

User Query → Plan → Search → Observe → Need more info? → Search again → Generate

Mejor, pero hay un problema. El mismo modelo de gran tamaño se encarga de cada paso: planificación, llamada a herramientas, evaluación de resultados y eliminación de fragmentos irrelevantes, todo a precios elevados. Los modelos más pequeños no pueden competir, porque ya el prompt del sistema y las definiciones de las herramientas los confunden, y no logran seguir el ciclo de manera fiable. Al final, pagas tarifas premium por un trabajo que no necesita inteligencia de alto nivel.

Cómo funciona

Chroma no se limitó a ajustar un modelo. Creó un entorno especial para agentes y entrenó al modelo dentro de él, de modo que el modelo y sus herramientas vienen juntos. Cuatro herramientas forman parte del entrenamiento:

• search_corpus realiza búsquedas híbridas, combinando la coincidencia de palabras clave BM25 con búsquedas vectoriales densas mediante fusión de rangos recíprocos, lo que permite obtener coincidencias exactas junto con una comprensión semántica.
• grep_corpus realiza búsquedas con expresiones regulares en todo el corpus y devuelve hasta cinco fragmentos que coinciden, lo cual es útil para una fecha, nombre o número de caso específico.
• read_document obtiene un documento completo por su ID cuando un fragmento parece prometedor.
• prune_chunks permite al modelo eliminar fragmentos de su propio contexto cuando decide que son irrelevantes. Este es el aspecto más destacado.

Un seguimiento muestra el patrón. En la primera fase, el modelo busca algo como sanciones por fusiones y adquisiciones, y regresan ocho fragmentos mientras el contador de tokens indica 8,432 de 32,768. En la segunda fase, lee un documento completo y vuelve a buscar, luego elimina lo que no fue útil, liberando espacio para seguir buscando.

Turn 1: search_corpus("merger acquisition penalties 2024")
  → Retrieves 8 chunks [Token usage: 8,432/32,768]
Turn 2: read_document("doc_14") + search_corpus("SEC filing penalties")
  → Retrieves 4 more chunks [Token usage: 18,203/32,768]
Turn 3: prune_chunks(["chunk_3", "chunk_7", "chunk_9", "chunk_11"])
  → Removes 4 irrelevant chunks [Token usage: 14,203/32,768]
Turn 4: search_corpus("specific penalty amounts regulatory action")
  → Retrieves 3 final chunks [Token usage: 21,847/32,768]
→ Returns ranked supporting documents to the reasoning model

El contexto de autoedición

La práctica habitual en la mayoría de los pipelines es recuperar un grupo de fragmentos, incluirlos todos en la instrucción y confiar en que el modelo ignore aquellos que no son relevantes. Las investigaciones demuestran que los modelos no solo ignoran el ruido, sino que también se confunden por él, un efecto conocido como deterioro del contexto. Context-1 aborda este problema directamente. Su ventana de contexto es de 32,000 tokens y el sistema de gestión monitorea su uso en tiempo real:

1. Después de cada llamada a una herramienta, el modelo ve su uso actual, en un formato similar a [Uso de tokens: 14,203/32,768].
2. Alrededor de los 24K tokens, el sistema de gestión indica que es momento de recortar o finalizar el proceso.
3. Al superar un límite máximo configurable, el modelo solo puede recortar o terminar, sin poder recuperar más información, lo que evita un crecimiento descontrolado del contexto.
4. La decisión de podar corresponde al propio modelo. No se utiliza ningún reordenador ni heurística separada; el modelo que obtuvo los fragmentos es el que los evalúa.

La precisión en la poda alcanza el 0,941, frente al 0,824 del modelo base, por lo que identifica los fragmentos irrelevantes en aproximadamente el 94 % de los casos. Esto supera al Provence de Naver Labs, que empleaba un modelo dedicado para podar oraciones. Aquí, el agente de búsqueda realiza la poda como parte de su flujo de trabajo normal, sin necesidad de un modelo adicional.

Tres niveles

Chroma insiste, y es un consejo acertado, en que Context-1 debe utilizarse únicamente para la recuperación de información, no para la generación. La arquitectura cuenta con tres niveles: la capa de datos, el subagente de búsqueda Context-1 y, por encima, un modelo de razonamiento avanzado. Esta división ofrece ventajas en cuatro aspectos:

• Cada componente puede mejorarse por separado, lo que permite sustituir el recuperador por uno mejor al día siguiente sin afectar a la generación.
• El modelo costoso solo procesa un contexto limpio y seleccionado, no datos brutos de búsquedas.
• Context-1 genera de 400 a 500 tokens por segundo en una Nvidia B200, lo cual es rápido para búsquedas de múltiples pasos.
• El sistema de razonamiento recibe material enfocado y produce respuestas de mejor calidad.

Es de nuevo el principio de los microservicios: no haga que un solo modelo haga todo.

Cómo se entrenó

Afinamiento supervisado. El modelo maestro fue Kimi K2.5, un modelo de vanguardia de gran tamaño. El equipo generó trayectorias de búsqueda con él dentro del conjunto de cuatro herramientas, las filtró según el nivel de recuperación y entrenó a Context-1 para imitar tanto las búsquedas exitosas como las fallidas. Las búsquedas fallidas se mantuvieron intencionadamente, ya que incluso las búsquedas con bajo nivel de recuperación contienen llamadas a herramientas bien estructuradas, descomposición de consultas y decisiones de poda. El modelo estudiante aprende la mecánica de la búsqueda a partir de aquellas búsquedas que no lograron encontrar lo buscado.

Aprendizaje por refuerzo con CISPO. Cada paso de entrenamiento utilizó 128 consultas con 8 iteraciones cada una, lo que da un total de 1,024 trayectorias, a lo largo de 5 épocas, convergiendo cerca del paso 230. Cada token contribuye al aprendizaje, incluidos aquellos raros pero cruciales como las decisiones de poda. La recompensa combina varios términos:

Reward = F1_score (recall-weighted)
       + trajectory_recall_bonus
       + final_answer_bonus (+1.0)
       - repeated_pruning_penalty (0.1 per excess)
       - turn_count_penalty

El entrenamiento también siguió un plan de estudios en dos etapas. Al principio se utilizaron tareas simples de un solo salto, donde la recuperación tenía un peso 16 veces mayor que la precisión, lo que fomenta una exploración agresiva. Más tarde se pasó a tareas más difíciles de varios saltos, con un peso 4 veces mayor, lo que enseña selectividad. Esto se asemeja al entrenamiento de un perro de búsqueda: primero encontrar cualquier rastro y luego el específico.

El pipeline de datos

Una de las cosas más útiles que lanzó Chroma podría ser su pipeline de generación de datos sintéticos, de código abierto en GitHub, que funciona como modelo a seguir para crear datos de entrenamiento de recuperación en cualquier área. Sigue un patrón de explorar, verificar y ampliar:

Seed Topic → Explore Web → Extract Verifiable Facts → Generate Tasks
     ↓
Add Distractors → Chain Into Multi-Hop → Verify Answers

1. Exploración. A partir de un tema inicial, como un título aleatorio de Wikipedia, un agente navega por la web y recopila documentos que contienen hechos únicos verificables.
2. Generación de tareas. Los documentos se convierten en pistas y preguntas que requieren un razonamiento multietapa real, no solo una búsqueda simple.
3. Distractores. El proceso genera pasajes que se asemejan a la respuesta correcta pero apuntan a otra dirección, imitando el ruido real en la recuperación de información.
4. Enlace entre tareas. Las tareas de un solo paso se conectan utilizando una respuesta para formular la siguiente pregunta, creando desafíos de uno a cuatro pasos de profundidad.

Soporta cuatro dominios de forma predeterminada: la web, los registros SEC para asuntos financieros, las patentes del USPTO para trabajos legales y el correo electrónico, utilizando conjuntos de datos al estilo Enron. La confianza en los datos proviene de una verificación basada en la extracción, en la que los modelos LLM extraen citas de los documentos y citas de pistas correspondientes, las normalizan y confirman que el texto está fundamentado. La precisión de alineación supera el 80% en cada dominio, y la verificación humana pasa de leer documentos completos a comparar pares de citas.

Pruébalo hoy mismo

Existen tres opciones.

La API alojada es la más sencilla, ya que el manejo está ya incluido, aunque requiere estar en una lista de espera.

Los pesos están disponibles en Hugging Face bajo la licencia Apache 2.0:

from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained(
    "chromadb/context-1",
    torch_dtype="auto",
    device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained("chromadb/context-1")

La gran limitación es que el propio soporte técnico, es decir, la ejecución de herramientas, los presupuestos de tokens, el recorte de contexto y la deduplicación, aún no es público. Sin él no podrás reproducir los resultados del informe técnico. Este patrón es familiar de los agentes de programación: el mismo modelo se comporta de manera muy diferente dentro de diferentes herramientas, porque el soporte técnico marca la diferencia. Context-1 sin él es como un motor de Fórmula 1 sin el coche. Chroma afirma que planea publicar el soporte técnico y el código de evaluación.

La tercera opción es crear tu propio soporte técnico alrededor de las cuatro herramientas documentadas. Este pseudocódigo da una idea general, pero no coincidirá con la versión final de Chroma:

# Pseudocode for a basic Context-1 harness

tools = {
    "search_corpus": hybrid_bm25_vector_search,    # BM25 + dense vector via RRF
    "grep_corpus": regex_pattern_search,             # Regex matching, max 5 chunks
    "read_document": full_document_retrieval,        # Full doc by ID
    "prune_chunks": context_pruner                   # Remove chunks from context
}
context_budget = 32_768  # tokens
soft_threshold = 24_000
current_usage = 0
while not done:
    # Get model's next action
    response = model.generate(conversation_history)
    # Execute tool calls (model may call multiple in parallel)
    for tool_call in response.tool_calls:
        result = tools[tool_call.name](**tool_call.args)
        conversation_history.append(result)
        current_usage = count_tokens(conversation_history)
    # Enforce context budget
    if current_usage > soft_threshold:
        # Suggest pruning or concluding
        conversation_history.append(
            f"[Token usage: {current_usage}/{context_budget}] "
            "Consider pruning irrelevant chunks or concluding search."
        )

Límites actuales

• Está entrenado para la profundidad, es decir, para encontrar elementos específicos. Las búsquedas de amplitud que requieren localizar todos los documentos que cumplan con un criterio no son su punto fuerte.
• No escribe código, por lo que no puede generar SQL para consultar datos estructurados. Solo busca en documentos.
• No aprende la estructura ni los metadatos de tus datos, por lo que el descubrimiento de esquemas depende de tu infraestructura.
• Sin el soporte oficial, no se pueden obtener los resultados reportados, lo que impide el uso de esta herramienta a muchos equipos por el momento.
• Una ventana de 32K, incluso con capacidad de autoedición, podría ser insuficiente como memoria de trabajo para algunas tareas.

Qué sugiere

El Context-1 es importante más allá de Chroma. Durante los últimos dos años, la práctica habitual ha sido elegir el modelo más potente que permita el presupuesto y dejar que se encargue de cada paso del proceso. El Context-1 indica que los modelos especializados de menor tamaño pueden igualar a los más avanzados en tareas específicas, y que combinar especialistas como un recuperador de información, un razonador y un generador de código permite contar con un sistema que funciona más rápido, cuesta menos y, con frecuencia, da respuestas mejores que un modelo monolítico. El software experimentó el mismo cambio cuando las aplicaciones monolíticas grandes se dividieron en microservicios. Los monolitos seguían funcionando bien, pero los componentes pequeños y especializados se escalaban con mayor facilidad.

Para quienes desarrollan sistemas RAG en 2026, la pregunta relevante ha cambiado. En lugar de preguntarse qué modelo de vanguardia debe manejar todo, hay que preguntarse qué especialista es adecuado para cada etapa. Un modelo de 20 mil millones de parámetros que mantiene el mismo rendimiento que GPT-5.4 y Opus-4.5 en tareas de recuperación de información pone en duda la idea de que cuanto mayor es el modelo, mejor es, idea que el marketing ha promovido constantemente.

Leer más

• RAG con estado en Databricks: memoria multi-turno con Lakebase y LangGraph — Otorga a un agente RAG de Databricks una verdadera memoria de conversación: analiza PDFs, crea búsquedas vectoriales, guarda los chats en Lakebase Postgres y luego despliega el sistema mediante MLflow y Model Serving.
• Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agentes — Guía paso a paso de las Notas prácticas: Los tres niveles de Google Cloud RAG: Búsqueda vectorial, motor RAG y recuperación por agentes: contratos, verificaciones y espacios para código listo para usar.
• RAG, ajuste fino o agentes: Elegir la capa adecuada y el orden para construirla — Comparación práctica de la recuperación de información, el ajuste fino y los agentes que abarca costos, latencia, modos de fallo, reglas prácticas y un ejemplo de un asistente de recursos humanos que muestra el orden de construcción.
• Recuperación agente y contexto suficiente: cuando RAG no sabe lo suficiente — El RAG estándar suele responder demasiado pronto. Aprenda a planificar búsquedas, dirigir las fuentes, evaluar las pruebas y volver a buscar hasta que el contexto sea suficiente, con un ejemplo de Acme.
• RAG agente: dejar que el LLM decida cuándo y dónde recuperar información — Por qué el RAG estático falla en preguntas de múltiples pasos y sensibles al tiempo, y cómo un agente de LangGraph dirige la búsqueda entre Qdrant y búsquedas en la web, con medidas de seguridad y advertencias.
• Trazado de un agente Voice RAG con LiveKit, Qdrant y MLflow — Crea un asistente de hipotecas de voz a voz utilizando LiveKit, LlamaIndex y Qdrant, con trazas de OpenTelemetry en MLflow que muestran cada paso de recuperación y de procesamiento del LLM.
• OKF + RAG: Una arquitectura híbrida para agentes de IA fiables — El formato de conocimiento abierto de Google proporciona a los agentes respuestas precisas controladas por Git, mientras que RAG gestiona archivos desorganizados. Descubre cómo un enrutador sencillo combina ambos.
• Recomendador de K-drama con múltiples agentes: BERTopic, RAG y fusión de rango recíproco — Cómo un recomendador de K-drama consciente del gusto combina etiquetas BERTopic, recuperación desde ChromaDB, un agente de entrevistas, expansión de consultas y fusión de rango recíproco antes de que un LLM realice una nueva clasificación.
• Notas prácticas: Construir un agente de IA autocorregible con Self-RAG y LangGraph — Guía paso a paso de las notas prácticas: Construir un agente de IA autocorregible con Self-RAG y LangGraph: contratos, verificaciones y espacios de código listos para usar para los equipos que implementan este patrón.
• Notas prácticas: ¿Qué pasa si el modelo de embedding de tu agente está a punto de dejar de ser utilizado? — Guía paso a paso de las Notas prácticas: ¿Qué pasa si el modelo de embedding de tu agente está a punto de dejar de ser utilizado?: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.
• Elegir un modelo de embedding para RAG: ¿Por qué el costo de cambio es más importante que el precio? — Comparación entre OpenAI, Cohere y modelos de embedding locales para RAG en producción: por qué el costo mensual apenas importa y el costo de reconstruir tu índice es el factor decisivo.