AgentOps
¿Cómo elegir modelos de IA para cada tarea de la empresa?
Una empresa decide incorporar inteligencia artificial a dos procesos distintos.
En el primero, el modelo debe clasificar solicitudes de compras en categorías predefinidas. En el segundo, necesita analizar contratos, localizar cláusulas relevantes y explicar posibles divergencias a un equipo especializado.
Los dos procesos utilizan lenguaje, pero no presentan la misma complejidad, el mismo riesgo ni los mismos requisitos operativos.
La clasificación de compras puede exigir respuestas rápidas, estructuradas y consistentes. El análisis contractual puede necesitar mayor capacidad de interpretación, un contexto más amplio, identificación de las evidencias utilizadas y revisión de especialistas.
Adoptar el mismo modelo para los dos procesos puede elevar costos sin mejorar la tarea más simple y producir una falsa sensación de seguridad en la tarea más compleja.
La selección debe comenzar por el trabajo que se ejecutará.
Defina la tarea antes de comparar modelos
Una descripción genérica como “analizar documentos” no ofrece criterios suficientes para la elección.
Es necesario detallar qué documentos se procesarán, qué resultado debe producir el modelo, qué errores son aceptables, cuánto tiempo puede tardar la respuesta y quién utilizará el resultado.
También es importante aclarar si el modelo solo apoyará una decisión o si su respuesta será utilizada automáticamente por otro sistema. Cuanto mayor sea el impacto de una respuesta, mayor debe ser el cuidado con la evaluación, la supervisión y el registro.
PwC recomienda que las organizaciones evalúen cada opción en el contexto del caso de uso, considerando los datos involucrados, los requisitos de desempeño, la tolerancia a fallas y la capacidad de la empresa para operar y proteger el modelo a lo largo del tiempo [1].
Antes de investigar proveedores, la empresa necesita responder algunas preguntas concretas.
¿Qué entrada se recibirá? ¿Qué salida se considerará correcta? ¿La respuesta debe seguir un formato estructurado? ¿El proceso exige consulta a documentos internos? ¿Existe revisión humana? ¿Cuál es el impacto de una respuesta errónea?
Sin esa definición, la comparación tiende a privilegiar la popularidad, el tamaño o las capacidades generales de los modelos, en lugar de evaluar su adecuación al proceso.
Los criterios deben reflejar el trabajo
No existe un único criterio capaz de determinar qué modelo debe elegirse.
La decisión debe combinar requisitos funcionales, operativos, económicos y de riesgo. Esos criterios también deben recibir pesos distintos según la tarea.
Una evaluación inicial puede considerar:
- Capacidad funcional: verificar si el modelo atiende las modalidades, los idiomas, el tamaño de contexto, el formato de salida, el uso de herramientas y los demás recursos exigidos por el proceso.
- Calidad: medir si las respuestas son correctas, completas, consistentes y útiles dentro de la tarea evaluada.
- Desempeño operativo: observar latencia, capacidad de procesamiento, estabilidad y comportamiento en períodos de mayor demanda.
- Datos y seguridad: analizar qué información se enviará, dónde podrá procesarse, cómo será tratada y qué controles de acceso y retención serán necesarios.
- Integración: evaluar la compatibilidad con aplicaciones, APIs, mecanismos de identidad, monitoreo y arquitectura existente.
- Costo total: considerar consumo, infraestructura, desarrollo, integración, revisión humana, retrabajo y operación continua.
BCG recomienda que la elección parta de la finalidad y considere el equilibrio entre desempeño, costo y capacidad operativa. El modelo más conocido o de mayor tamaño no será necesariamente el más adecuado para todas las tareas [3].
Un proceso de clasificación interna puede priorizar costo, velocidad y consistencia. Una aplicación que analiza contratos puede exigir mayor capacidad de interpretación, evidencias verificables, tratamiento cuidadoso de los documentos y participación de especialistas.
Los benchmarks ayudan a formar la lista de candidatos
Los benchmarks públicos son útiles para reducir el número inicial de alternativas.
Permiten observar cómo se comportan distintos modelos en tareas estandarizadas de razonamiento, conocimiento, seguridad, codificación, latencia y capacidad de procesamiento.
Sin embargo, una puntuación agregada no representa todas las condiciones de una aplicación empresarial.
Un modelo bien posicionado en una evaluación general puede no presentar el mismo desempeño al clasificar documentos internos, interpretar el vocabulario de un sector determinado o producir respuestas en el formato exigido por una integración.
PwC destaca que los benchmarks públicos pueden orientar la decisión, pero no sustituyen pruebas con tareas empresariales representativas, patrones reales de datos, límites de calidad, requisitos de latencia y tolerancia a fallas [1].
La documentación técnica de AWS y Microsoft ofrece mecanismos para realizar evaluaciones automáticas, aplicar conjuntos de prompts propios, utilizar modelos evaluadores e incorporar revisión humana [6][7]. Esos recursos son útiles para ejecutar las pruebas, pero los criterios de éxito deben ser definidos por la propia organización.
El benchmark ayuda a formar la lista de candidatos. La decisión debe confirmarse en el proceso real.
Compare los modelos en las mismas condiciones
Una comparación confiable exige que todos los modelos reciban las mismas instrucciones, los mismos ejemplos y los mismos criterios de evaluación.
La muestra debe representar situaciones comunes, casos difíciles y excepciones relevantes. Los datos utilizados deben estar autorizados para ese tipo de prueba. Cuando haya información sensible, el equipo debe evaluar el uso de anonimización, enmascaramiento o datos sintéticos adecuados al objetivo.
La evaluación también debe definir de antemano qué se considerará éxito.
En una tarea de clasificación, puede ser posible comparar el resultado con categorías esperadas. En un análisis contractual, la evaluación puede exigir especialistas que verifiquen si las cláusulas fueron identificadas correctamente, si la explicación está sustentada en el documento y si se omitió información relevante.
Las evaluaciones automáticas aceleran la comparación. Los modelos evaluadores también pueden ayudar a examinar grandes volúmenes de respuestas. Aun así, el resultado producido por otro modelo no debe tratarse como verdad absoluta.
Para procesos importantes, la revisión humana y los criterios del negocio siguen siendo necesarios.
NIST recomienda que las organizaciones evalúen capacidades relevantes y medidas de seguridad antes del despliegue y de forma continua, considerando el contexto, la tolerancia al riesgo y los posibles impactos [5].
El menor precio por procesamiento no representa el costo total
Una comparación limitada al precio de entrada y salida puede distorsionar la decisión.
Un modelo aparentemente más barato puede exigir instrucciones mayores, generar más retrabajo o depender de mayor revisión humana. Otro puede costar más por ejecución, pero reducir correcciones y entregar respuestas estructuradas que simplifican la integración.
McKinsey aborda este problema como parte de la economía más amplia de la inteligencia artificial. El costo depende de la selección del modelo, del enrutamiento, del diseño del flujo, del comportamiento de los agentes, del volumen de llamadas y de la cantidad de procesamiento desperdiciado [2].
El costo total también puede incluir preparación y actualización de prompts, recuperación de documentos, almacenamiento, llamadas a herramientas, revisión humana, corrección de errores, observabilidad y mantenimiento de las integraciones.
BCG agrega que modelo, arquitectura y plataforma de control representan decisiones relacionadas, pero distintas. Optimizar solo el precio divulgado por un proveedor puede ocultar costos de integración, dependencia tecnológica, gobernanza y operación [4].
Una diferencia pequeña por ejecución puede volverse relevante a gran escala. De la misma forma, ahorrar en el modelo puede no compensar si la tasa de retrabajo aumenta.
La pregunta correcta no es solo cuánto cuesta una llamada. La empresa necesita saber cuánto cuesta alcanzar un resultado aceptable para el proceso.
Un ejemplo de selección por tarea
Considere una empresa que desea automatizar la clasificación de solicitudes de compras.
La tarea consiste en leer una descripción corta, identificar la categoría correspondiente y devolver una estructura simple. La empresa posee ejemplos históricos revisados y puede definir claramente las categorías esperadas.
Los modelos candidatos pueden compararse por precisión de la clasificación, estabilidad del formato, tiempo de respuesta y costo para el volumen estimado.
En otro proceso, la misma empresa quiere apoyar el análisis de contratos. El modelo necesita trabajar con documentos extensos, localizar cláusulas, relacionar fragmentos y producir una explicación para revisión especializada.
La evaluación pasa a considerar contexto, fundamentación de las respuestas, capacidad de indicar los fragmentos utilizados, omisiones relevantes, privacidad de los documentos y calidad de la revisión humana.
El resultado puede indicar modelos distintos para cada tarea.
Eso no obliga a la empresa a crear una arquitectura compleja desde el inicio. Solo significa que la selección fue orientada por el trabajo a realizar, y no por el intento de estandarizar prematuramente toda la organización en una única alternativa.
Una empresa puede terminar con más de un modelo
Después de evaluar tareas distintas, la organización puede concluir que modelos diferentes atienden mejor partes distintas de sus procesos.
Un modelo menor puede realizar clasificaciones, extracciones y transformaciones estructuradas. Otro puede reservarse para análisis que exigen mayor capacidad de razonamiento o interpretación. También puede haber diferencias relacionadas con datos, idiomas, modalidades o condiciones de despliegue.
PwC observa que la selección de modelos no necesita tratarse como una elección binaria entre una única opción abierta o cerrada. Un portafolio puede combinar modelos y formas de despliegue conforme a los requisitos de cada caso de uso [1].
Este enfoque también reduce la dependencia de una única familia de modelos. Sin embargo, aumenta la necesidad de criterios comunes, integración, control de acceso, observabilidad y seguimiento de costos.
El entorno multimodelo debe ser consecuencia de las decisiones por tarea. No debe surgir solo porque muchas alternativas están disponibles.
La elección debe revisarse a lo largo del tiempo
Los modelos, los precios, las versiones y las condiciones de uso cambian. El proceso atendido también puede recibir nuevas reglas, datos e integraciones.
Por eso, la decisión debe documentarse.
La empresa debe registrar qué versión se evaluó, qué datos se utilizaron, qué criterios se aplicaron y qué resultados justificaron la elección.
Los cambios relevantes deben provocar una nueva evaluación. Eso incluye sustitución de versión, alteración del prompt principal, inclusión de nuevas herramientas, ampliación del público y uso del resultado en decisiones de mayor impacto.
La capacidad de sustituir un modelo también debe formar parte de la arquitectura. La inversión más duradera no está solo en el modelo elegido, sino en el proceso de evaluación, en los controles, en los datos de prueba y en los mecanismos que permiten revisar la decisión cuando cambien las condiciones [1].
De la selección a la operación: ARGUS
Después de que la organización define qué modelos atienden a cada tarea, surge el desafío de controlar cómo las aplicaciones y los agentes acceden a esos recursos en producción.
Con recursos de AI Gateway, ARGUS puede centralizar el acceso a los modelos integrados, aplicar políticas definidas por la organización y registrar consumo e interacciones. La plataforma también puede apoyar el seguimiento operativo de los agentes que utilizan esos modelos.
Esta capa de control permite relacionar el uso del modelo con el agente, la aplicación y el proceso atendido. También facilita la observación de consumo, fallas, latencia y cambios operativos en los componentes integrados.
ARGUS no elige automáticamente el mejor modelo para cada tarea. La definición de los criterios, la preparación de las muestras y la decisión sobre calidad, riesgo y costo siguen siendo responsabilidad de la organización.
La plataforma transforma una elección documentada en políticas y evidencias operativas que pueden seguirse a lo largo del tiempo.
Sobre Target Solutions
Target Solutions actúa desde hace más de 15 años apoyando a organizaciones en la evolución de sus operaciones de infraestructura, monitoreo, observabilidad, automatización e inteligencia operativa.
A lo largo de esa trayectoria, participó en proyectos en entornos complejos de telecomunicaciones, tecnología, gobierno, energía y grandes empresas, contribuyendo a aumentar la eficiencia operativa y la confiabilidad de los servicios.
En la selección de modelos de IA, Target Solutions puede apoyar la definición de los casos de uso, de los criterios de comparación y del proceso de evaluación. Los servicios también pueden abarcar arquitectura, gobernanza, integración, observabilidad y preparación del modelo operacional necesario para poner las aplicaciones en producción.
Esta actuación no está restringida a la implantación de una plataforma específica. El objetivo es ayudar a la empresa a estructurar decisiones técnicas y operativas adecuadas a sus tareas. Cuando tenga sentido para el entorno, Target Solutions también puede apoyar la implantación y la integración de una plataforma como ARGUS.
Sobre el autor
Paulo Florêncio de Menezes es cofundador de Target Solutions y actúa desde hace más de 15 años en proyectos relacionados con infraestructura, monitoreo, observabilidad, automatización y operaciones de TI y telecomunicaciones.
Es graduado en Procesamiento de Datos por la Universidad Federal de Amazonas (UFAM), tiene un MBA en Gestión Empresarial por la Fundação Dom Cabral (FDC) y una Maestría Profesional en Economía por la Fundação Getulio Vargas (FGV).
En su investigación de maestría, desarrolló el IBEOP-IA (Índice Brasileño de Exposición Ocupacional Potencial a la Inteligencia Artificial), investigando la exposición potencial de las ocupaciones brasileñas a las capacidades de la IA mediante la combinación de datos ocupacionales, patentes de inteligencia artificial y técnicas de procesamiento de lenguaje natural.
Referencias
[1] PwC. The open-weight decision: What CISOs should consider before they say yes.
[2] McKinsey & Company. The cost of intelligence: How CIOs can manage AI demand at scale.
[3] Boston Consulting Group. Laying the Foundation for Gen AI Success.
[4] Boston Consulting Group. There’s More to Cloud AI Cost Than Token Price.
[5] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
[6] Amazon Web Services. Evaluate the performance of Amazon Bedrock resources.
[7] Microsoft. Model leaderboards in Microsoft Foundry.