Modelos

Modelos en la consola. Nada del producto funciona hasta que esta página tiene algo dentro.

Dos capas: los proveedores (una cuenta en alguna parte, con una credencial) y los modelos (lo que ese proveedor te ofrece).

Si estás configurando esto por primera vez, el orden que funciona es: agrega un proveedor, agrega un modelo de chat y ponlo en lo más alto de la cadena de chat, agrega un modelo de embeddings y luego vuelve a por el resto.

Agregar un proveedor

Agregar proveedor, elige uno, dale una credencial. Las claves se guardan cifradas.

La mayoría de los proveedores quieren una clave API. Dos son distintos:

Google Vertex acepta o bien un JSON de cuenta de servicio, o bien las credenciales del propio entorno, más un id de proyecto de GCP y una región.

Custom es cualquier endpoint compatible con OpenAI: un modelo autoalojado, una pasarela, algo en tu propia infraestructura. Le das una URL.

Prueba la conexión antes de guardar. Es más rápido que descubrir que la clave está mal cuando lo descubre un usuario.

Eliminar un proveedor elimina también sus modelos.

Agregar un modelo

Bajo un proveedor, Agregar modelo. Los campos que importan:

ID del modelo es el identificador propio del proveedor. Sal del campo y el precio, la ventana de contexto y el nombre se rellenan solos desde un catálogo público, completando únicamente lo que esté vacío. Revísalo antes de guardar: el catálogo es bueno, no es la autoridad, y un precio equivocado distorsiona en silencio todas las cifras de coste sobre las que te vas a apoyar después.

La ventana de contexto gobierna la compactación automática de las conversaciones. Configúrala bien o las conversaciones largas se compactarán en el punto equivocado.

Modo de pensamiento: Desactivado (no admitido), Opcional (los usuarios tienen el interruptor) o Siempre (el modelo razona en cada solicitud). Esto es lo que pone el icono del cerebro en el cuadro de mensaje.

Búsqueda web integrada marca un modelo que sabe buscar por su cuenta, lo que se combina con el ajuste "preferir la búsqueda propia del modelo" de Organización.

Oculto del selector de chat mantiene un modelo fuera del desplegable que ven los usuarios. Úsalo para cualquier cosa que no esté pensada para conversar.

El precio es obligatorio. Sin él un modelo sigue funcionando, y todas las cifras de uso y coste que toque quedan mal por omisión.

Modelos de chat y la cadena

Los modelos de chat no se eligen de uno en uno. Los ordenas en una cadena de hasta tres, y ese orden lo decide todo:

El modelo que está arriba del todo es el valor por defecto de tu organización. Es con el que arrancan las conversaciones nuevas, y es lo que recibe una solicitud de API que omite model, así que las aplicaciones que no nombran ningún modelo siguen lo que esté aquí en primer lugar. Consulta Modo pasarela. No hay un interruptor aparte de "hacer que este sea el predeterminado": ascender un modelo a lo alto de la cadena es ese interruptor.

Con créditos, la cadena se lee igual que en cualquier otro sitio. Cada modelo lleva una etiqueta de postura en lugar de un precio, Barato y rápido, Buena relación precio/rendimiento o Máxima inteligencia, así que ninguna elección depende de leerse una lista de precios. Tus miembros ven una forma más corta de la misma etiqueta en su propio selector. El modelo con el que se aprovisionó tu organización viene marcado como el recomendado, así que siempre puedes ver de qué te has alejado.

Los modelos que van debajo son el respaldo. Cuando el modelo de arriba falla, se prueba el siguiente, y al usuario se le dice qué modelo respondió realmente en lugar de dejarle con la duda.

La cadena cubre las conversaciones de la aplicación. Quien llama a la API se acoge a ella solicitud a solicitud con enable_fallback, así que una aplicación que no lo pide ve el fallo. Es deliberado: quien llama puede preferir un error limpio a una respuesta de un modelo que no eligió.

Cada modelo se prueba al guardar, así que una cadena que no puede servir se rechaza en ese momento y no en el siguiente mensaje de alguien.

Merece la pena ordenar la cadena antes de necesitarla: la caída de un proveedor se convierte en una degradación en lugar de en una caída. Pon debajo del primero un modelo de un proveedor distinto, o una caída se llevará por delante la cadena entera.

Con créditos funciona de otra manera, y mejor. Tus modelos se alcanzan a través de una pasarela que ya enruta cada uno entre varios proveedores por debajo, así que la caída de un solo proveedor queda absorbida antes de que se consulte tu cadena. Lo que tu cadena añade encima es cobertura para el modelo en sí: pon debajo una familia de modelos distinta, por ejemplo Gemini bajo GPT, y una versión defectuosa o la caída de un modelo entero seguirá teniendo adónde ir.

Tres cosas más que conviene saber:

A tus usuarios se les avisa cuando pasa. Aparece un aviso encima del cuadro de mensaje que nombra el modelo que no estaba disponible y el que respondió en su lugar, y que pueden descartar. Así, un respaldo es una degradación visible y no silenciosa, y es muy posible que alguien te pregunte por ella antes de que tú lo hayas notado.

Mira el patrón, no el incidente. Un aviso suelto es la cadena haciendo su trabajo. Que una cadena se use repetidamente significa que el modelo de arriba no está sano, y eso aparece en la alerta del Panel de control y en el desglose de respaldos de Uso, que merecen un vistazo semanal.

Los embeddings y el reranking no pueden tener cadenas, y el motivo no es que falte una función. Sigue leyendo.

Elegir qué modelos ve tu equipo

Cada modelo tiene un interruptor: Ofrecer este modelo a los usuarios. Apagado, el modelo sigue configurado y desaparece del selector de todo el mundo.

Con créditos, así es como das forma a la lista. Tu organización se aprovisiona con el catálogo entero, y los modelos recomendados ya vienen encendidos. Encender algunos más, o apagar algunos, es la manera normal de decidir qué se le ofrece a tu equipo sin configurar nada.

Modelos de tarea

Tres casillas, para trabajos de fondo en lugar de para conversar. Cada una se elige por separado, y cada una existe por un motivo distinto.

Embeddings

Convierte tus documentos en vectores para que una colección se pueda buscar por significado y no por palabra clave. Se ejecuta cuando se añade un documento y otra vez con cada pregunta que se le hace a una colección.

Sin él, las colecciones no se pueden indexar en absoluto. Los usuarios reciben "modelo de embedding no configurado", sobre lo que no pueden hacer nada. Configura esto antes de que nadie intente crear una colección.

Tres restricciones, y la primera rechazará tu primer intento si te la saltas:

El tamaño del lote es cuántos textos van en una llamada a la API, y cada proveedor lo limita de forma distinta (Voyage permite 1000, Cohere 96). Ponlo en lo que documente tu proveedor.

Si no conoces el límite, sé conservador: 100 o menos. Si es demasiado alto, el proveedor rechaza lotes enteros, lo que se manifiesta como una indexación que falla con los documentos grandes y funciona con los pequeños. Si es demasiado bajo, solo cuesta un poco de rendimiento, y la indexación es un trabajo de fondo.

Sin cadena de respaldo, y no podría tenerla. Una colección se busca con el modelo que la indexó, así que recurrir a otro modelo sería buscar en un índice con los vectores de otro: disparates con aplomo, en lugar de un error.

Reranking

Toma los candidatos que encontró la recuperación y los reordena según lo bien que responden de verdad a la pregunta. Opcional, y se gana su sitio en colecciones grandes, donde la primera pasada devuelve bastante material de aspecto plausible.

Tiene su propio tamaño del lote, con el mismo consejo: iguala el límite documentado por el proveedor, y quédate en 100 o por debajo si no lo conoces.

Sin cadena de respaldo, por el mismo motivo que los embeddings.

Generación de imágenes

Se usa cuando alguien pide una imagen. Opcional: sin él, esa petición simplemente no está disponible.

Tiene que ser un modelo que genere imágenes, no uno que solo las lea. Un modelo de chat con capacidad visual sabe describir una imagen y no sabe producirla. Lo que quieres aquí es un modelo de imagen: los modelos de imagen de Google (los que se comercializan como Nano Banana) o los modelos de imagen de OpenAI.

El coste por imagen es opcional y merece la pena rellenarlo, porque los modelos de imagen se cobran por imagen y no por token, así que dejarlo vacío significa que la generación de imágenes no aporta nada a tus cifras de coste.

Lo que no está en esta página

Dos trabajos para los que la gente espera encontrar una casilla, y no hay ninguna que fijar:

Redactar documentos y presentaciones del Taller se ejecuta con el modelo de chat de la conversación que lo pidió. Si un miembro quiere un documento escrito por un modelo más potente, cambia de modelo en la conversación antes de pedirlo.

Redactar un flujo de trabajo a partir de una descripción se ejecuta con tu modelo de chat por defecto, y baja por su cadena si ese modelo no está disponible.

Los dos siguen al modelo de chat deliberadamente: quien pregunta ya eligió un modelo para la conversación, y responder en silencio con otro haría que el coste y el estilo de escritura no cuadraran con lo que eligió.

Cambiar el modelo de embedding

El único cambio de esta página con consecuencias de verdad, y la consola se explica bien cuando lo intentas.

Cambiarlo vuelve a generar los embeddings de todo lo ya indexado: fragmentos de documentos, entidades del grafo de conocimiento, resúmenes de conversaciones. Se te muestran las cantidades y una duración estimada antes de confirmar.

El diseño es cuidadoso, y merece confianza:

• Los vectores nuevos se construyen junto a los antiguos y solo se intercambian cuando el corpus entero está listo.
• La búsqueda sigue disponible todo el rato. El índice actual sigue respondiendo.
• Puedes cancelar en cualquier momento, y no se pierde nada de lo indexado.
• Si falla, tus vectores existentes quedan intactos y te quedas en el modelo anterior.

No puedes cambiar el modelo de embedding mientras hay un cambio en curso.

Hazlo con intención: en un corpus grande son horas de trabajo, y el motivo para hacerlo es un modelo genuinamente mejor, no la curiosidad.

Una configuración que funciona, de principio a fin

Para una organización que empieza de cero: