Un demo no prueba nada. Producción lo prueba todo.
Las funcionalidades de IA son fáciles de prototipar y difíciles de mantener correctas. La ingeniería está en la evaluación, los guardarrieles, la calidad de la recuperación, y un costo que no te sorprenda.
El problema
Casi cualquier equipo puede construir un prototipo de IA que impresione a la gente en una reunión. La dificultad empieza después, cuando usuarios reales mandan entradas que nadie anticipó y la funcionalidad tiene que acertar lo suficientemente seguido para confiar en ella.
Esa brecha es un problema de ingeniería con partes conocidas. Necesitas un conjunto de evaluación antes de ajustar nada, para que la mejora se mida en vez de sentirse. Necesitas recuperación que devuelva el contexto correcto, porque la mayoría de las respuestas equivocadas son fallas de recuperación disfrazadas. Necesitas guardarrieles sobre lo que el sistema tiene permitido hacer. Y necesitas saber cuánto van a costar mil usuarios antes de tenerlos.
Construimos las cuatro cosas como parte de la funcionalidad y no después del lanzamiento. Una funcionalidad de IA sin arnés de evaluación no es una funcionalidad, es una esperanza.
- Un conjunto de evaluación construido antes de ajustar, para que los cambios de calidad se midan
- La calidad de la recuperación tratada como la palanca principal sobre la corrección
- Guardarrieles sobre las acciones, no solo sobre las palabras
- Costo por operación modelado antes de escalar, no descubierto durante
Qué cubre esto
Funcionalidades de IA aplicada
Asistentes, extracción, clasificación y búsqueda que funcionan sobre tus datos.
Arnés de evaluación
Una medida repetible de lo correcto, para que ajustar sea ingeniería.
Guardarrieles
Restricciones sobre lo que el sistema puede hacer y lo que puede revelar.
Control de costo y latencia
Modelado por operación y probado al volumen esperado.
Recuperación y anclaje
Poner el contexto correcto frente al modelo, de forma confiable.
Plomería de producción
Colas, caché, planes de contingencia y degradación elegante.
Del demo a algo en lo que puedes confiar
Paso 01
Viabilidad, con honestidad
Establecemos si la tarea es una en la que los modelos actuales de verdad son buenos, antes de que alguien se comprometa con un alcance. Algunas no lo son, y descubrirlo en la primera semana es el resultado más barato posible.
Paso 02
Construir el conjunto de evaluación
Un conjunto etiquetado de casos reales con las salidas esperadas, acordado contigo. Esto va antes de cualquier ajuste, porque de lo contrario la mejora es una sensación y no una medición.
Paso 03
Recuperación y anclaje
Poner el contexto correcto frente al modelo. La mayoría de las respuestas equivocadas son fallas de recuperación, así que de aquí sale la precisión de verdad.
Paso 04
Guardarrieles y contingencias
Restringir lo que el sistema puede hacer y revelar. Agregar contingencias entre proveedores y adaptadores modulares, para que el cambio de precios de un proveedor no sea tu caída de servicio.
Paso 05
Modelado de costo y latencia
Medir el costo por operación y probar al volumen que esperas, para que mil usuarios sean un pronóstico y no una factura sorpresa.
Paso 06
Monitorear y volver a evaluar
El comportamiento de los modelos se desvía y los proveedores descontinúan versiones. El conjunto de evaluación corre en un calendario, no una sola vez.
Qué mueve la estimación
Las funcionalidades de IA son lo más fácil de subestimar, porque el prototipo toma dos días y todo el mundo razona a partir de eso. La construcción se cotiza por lo que cuesta hacer que la cosa acierte lo suficientemente seguido para confiar en ella, y casi nada de ese trabajo es escribir prompts.
El costo dominante son tus datos. La calidad de la recuperación es la palanca principal sobre la corrección, y esa calidad depende sobre todo de si el contenido de base está limpio, actualizado y dividido con sentido. Un corpus desordenado es la razón más común por la que una funcionalidad de IA cuesta el doble de lo que el cliente esperaba.
- El estado de los datos de donde tienen que salir las respuestas, que normalmente necesitan trabajo antes que cualquier otra cosa
- Qué tan alta es la barra de precisión, y quién decide cuándo se alcanzó
- Si el sistema solo responde o también tiene permitido actuar, porque las acciones necesitan autorización y auditoría
- El tamaño del conjunto de evaluación, que escala con la cantidad de formas en que la funcionalidad puede equivocarse
- Si una respuesta equivocada es una molestia o un evento regulado
"El agente lo hizo" no es una respuesta
Todo equipo que mete agentes en su proceso de entrega termina escuchando esa frase, y no tiene ningún significado operativo. La persona que delegó el trabajo responde por lo que volvió: el código, las pruebas, el documento, el diseño. Nombrar la herramienta describe la cadena de herramientas, no transfiere la responsabilidad.
Sostenemos esa línea internamente porque no puedes comprarle un alcance comprometido a un aliado que puede señalar un modelo cuando algo sale mal. Cada artefacto que te entregamos tiene una persona que lo leyó y lo aceptó.
El segundo hábito importa igual. Cuando la salida vuelve equivocada, el instinto es decirle al agente que la corrija. Eso no es lo primero que hacemos. Preguntamos qué vacío en la especificación permitió la mala lectura, y corregimos la especificación, porque el mismo vacío va a producir la misma clase de error la próxima semana y la siguiente.
Ese es el cambio real. El trabajo deja de ser escribir el software y pasa a ser diseñar el sistema en el que el software se escribe bien. También es la razón por la que nuestras estimaciones se sostienen: los errores que corregimos son los que se iban a repetir.
- Cada artefacto tiene una persona con nombre que lo revisó y lo aceptó
- Una salida equivocada se trata primero como defecto de especificación y después como defecto de salida
- El contexto se cura, porque un agente va a tratar un documento reemplazado como si fuera el vigente
- Las decisiones reemplazadas se corrigen en la fuente, no se recuerdan de forma selectiva
De qué te vamos a tratar de convencer que no
Un chatbot encima de documentación que nadie mantiene. El bot va a repetir con toda confianza lo que esté desactualizado, y habrás comprado una forma costosa de distribuir una respuesta equivocada más rápido.
Un agente con permiso de escritura sobre un sistema de producción desde el primer día. Empieza en solo lectura, comprueba el criterio, y después otorga acciones una por una, detrás de autorización y de un rastro de auditoría.
El ajuste fino del modelo como primer movimiento. De vez en cuando es la respuesta correcta y casi nunca es la primera respuesta correcta. La recuperación y el diseño de los prompts llegan más lejos por menos, y son reversibles.
Cualquier cosa sin una definición medible de lo correcto. Si no nos podemos poner de acuerdo en cómo se ve una buena salida, no podemos comprometer un alcance, y ninguno de los dos debería pretender lo contrario.
Preguntas que vale la pena hacer
¿Qué pasa cuando el proveedor del modelo cambia precios o descontinúa un modelo?
¿Qué tan precisa va a ser?
¿Pueden agregar IA al producto que ya tenemos?
¿Esto se cotiza distinto del resto de la ingeniería?
¿Tu empresa está lista para la IA? Descúbrelo.
Descubre en qué punto está tu empresa frente a la IA y qué hacer después. Toma unos minutos y te da un puntaje sobre el que puedes actuar.
ScopeGen AI ya ejecuta este flujo
La entrega AI-First es también la forma en que trabajamos internamente. ScopeGen AI convierte una conversación con el cliente en una descomposición de trabajo estimada, y por eso podemos cotizar el alcance antes de construirlo.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.