IA aplicada al trabajo real · 4 de 5 · Probar
Cómo diseñar una prueba de concepto de IA y medir si vale la pena avanzar
Una respuesta bien redactada produce una impresión inmediata de capacidad. Para saber qué podemos hacer con ella necesitamos examinar algo más: de dónde sale la información, cuánto trabajo costó obtenerla y qué sucede ante una consulta diferente.
Una prueba de concepto permite estudiar una capacidad técnica delimitada. Su valor está en la pregunta que ayuda a resolver y en la evidencia que deja para la decisión siguiente.
En nuestra distribuidora, esa pregunta podría ser si la asistencia permite preparar respuestas correctas sobre una familia de repuestos con menos tiempo total de trabajo. Ya preparamos las fuentes y el criterio de revisión. Ahora vamos a organizar la comparación.
Definir qué esperamos observar
En el primer artículo hicimos una cuenta hipotética: pasar de 18 a 8 minutos por consulta. Podemos tomar esa diferencia como una expectativa inicial que habrá que comprobar.
La hipótesis debe indicar también qué significa terminar la tarea. En este caso, obtener una respuesta revisada, con identificación correcta de la pieza, precio tomado de la fuente autorizada y condiciones comerciales comprobadas. Una consulta incompleta debe terminar con una solicitud de información suficiente para poder seguir.
Antes de probar acordaremos el tiempo que justificaría avanzar, los criterios de calidad y los errores que obligarían a corregir la solución. Esas decisiones expresan qué necesita el negocio para considerar útil la capacidad.
Comparar trabajos equivalentes
Primero necesitamos observar el recorrido actual. Mediremos desde que se abre una consulta hasta que queda preparada una respuesta aceptable, incluyendo búsquedas, preguntas y correcciones. Esa será nuestra línea de base.
Después reuniremos consultas que cubran la variedad importante del alcance: pedidos completos, descripciones ambiguas, piezas sin disponibilidad y documentos que requieran interpretación. La selección debe responder al trabajo real. Su tamaño dependerá de esa variedad y de la confianza necesaria para decidir.
Una parte de los ejemplos servirá para desarrollar y ajustar la solución. Reservaremos otros para evaluarla una vez que hayamos fijado la versión a probar. Así podremos observar cómo responde ante casos que no usamos para guiar los ajustes.
La comparación debe cuidar también el efecto del aprendizaje. Si la misma persona resuelve dos veces una consulta, la segunda vez ya conoce parte de la respuesta. Podemos distribuir casos equivalentes entre métodos o variar el orden entre participantes, dejando registrado cómo se organizó la prueba.
Contar también el trabajo de revisar
Supongamos que el borrador aparece en un minuto. La persona dedica después cuatro minutos a verificar las fuentes y tres a corregir y completar. El recorrido asistido lleva ocho minutos. Ese es el tiempo que nos interesa comparar con la referencia de dieciocho.
1 minuto de preparación + 4 de revisión + 3 de corrección = 8 minutos hasta una respuesta utilizable.
Son cifras ilustrativas, todavía pendientes de medición. Ayudan a ver dónde aparece el posible beneficio y qué esfuerzo debemos registrar. Además del promedio, conviene observar cuánto varía el tiempo entre casos y cuáles requieren más intervención.
La calidad necesita su propio registro. Un precio incorrecto y una frase poco clara tienen consecuencias distintas. Debemos clasificarlas, examinar sus causas y comprobar si la persona puede detectarlas durante la revisión prevista.
Cuando la solución consulta documentos, podemos separar dos preguntas: si encontró la información pertinente y si construyó una respuesta adecuada a partir de ella. La documentación de evaluación de Amazon Bedrock contempla estas capacidades. La distinción resulta útil para localizar problemas aunque la solución utilice otras herramientas.
Decidir con lo que la prueba permite afirmar
Al terminar podremos comparar tiempo total, calidad, esfuerzo de revisión y costo de operación. Conviene conservar los resultados por caso, las fuentes utilizadas y la versión evaluada para entender las diferencias.
Encontraremos razones para avanzar, ajustar alguna parte o detener esta línea de trabajo. Si el tiempo de revisión absorbe la mejora esperada, necesitaremos estudiar por qué ocurre. Si los resultados son favorables, podremos preparar un piloto con personas y condiciones de uso controladas.
También debemos registrar los límites. Una evaluación sobre una familia de productos aporta evidencia sobre ese alcance. Observar pocos errores en los casos elegidos deja preguntas pendientes sobre situaciones que todavía no probamos.
De una capacidad demostrada a una práctica posible
El piloto permite estudiar cómo se comporta la solución dentro del trabajo cotidiano: si las personas la utilizan, qué interrupciones aparecen y cuánto esfuerzo requiere sostenerla. Su alcance debe crecer de acuerdo con lo que vayamos comprobando.
La prueba de concepto habrá cumplido su propósito si nos permite explicar qué funcionó, bajo qué condiciones y qué necesitamos averiguar después. Esa comprensión es el recurso que llevaremos a la siguiente etapa: desarrollar e integrar una capacidad que la empresa pueda utilizar de manera habitual.