Piloto de IA: elegir casos de prueba con decisiones esperadas claras
Un pequeño plan de casos fija expectativas antes de probar la IA. El ejemplo separa entradas habituales, ambiguas y ajenas a la tarea.
Acordar la tarea y la derivación esperada
Una empresa de software ficticia planifica un piloto de IA para mensajes de soporte. La IA propondrá una derivación: bug, access, review u out-of-scope. Conceder acceso, cambiar estados y cerrar tickets sigue siendo tarea del equipo de soporte. La evaluación se refiere a la propuesta, no a un servicio de soporte completado automáticamente.
Fije la decisión esperada con el equipo que conoce el trabajo antes de ver la salida del modelo. Si los responsables no se ponen de acuerdo, aclare primero la regla. NIST AI RMF recomienda documentar las condiciones de prueba y evaluar en condiciones similares al despliegue.
Elegir ejemplos con distintos objetivos de comprobación
La selección siguiente es ficticia. Los textos ilustran los casos; el piloto real registrará las entradas originales aprobadas con su idioma y procedencia.
Caso | Mensaje de ejemplo | Derivación esperada | Motivo |
|---|---|---|---|
| La aplicación se cierra inesperadamente al guardar una nota de proyecto. |
| Síntoma de error descrito con claridad |
| Denme acceso a mi proyecto, por favor. |
| Petición clara de acceso; aún no es autorización |
| No puedo entrar. |
| No se distingue entre petición de acceso y fallo técnico |
| Al guardar aparece un error; además necesito acceso al proyecto. |
| Peticiones mezcladas; el piloto prevé una categoría por mensaje |
| Apúntese a nuestro seminario promocional. |
| No es una petición de soporte del catálogo acordado |
La última etiqueta no provoca un borrado en este ejemplo. La selección muestra decisiones distintas; no demuestra la frecuencia de los casos ni un tamaño suficiente del conjunto de prueba. La recogida posterior también debe abarcar los idiomas, formatos de entrada e información ausente realmente necesarios.
Separar casos de desarrollo de la comprobación posterior
Los ejemplos usados por el equipo para cambiar el prompt o las reglas de derivación son casos de desarrollo. Reserve otros casos para una comprobación posterior que no hayan guiado antes la optimización. Las copias y reformulaciones cercanas del mismo mensaje inicial no deben repartirse entre ambos lados como pruebas independientes.
Google explica cómo la reutilización de datos de prueba y los duplicados pueden distorsionar la evaluación de aprendizaje automático. De ahí se deriva una precaución práctica para los prompts: los ejemplos conocidos ayudan a diagnosticar errores, pero la comprobación posterior debe incluir otros casos aún no vistos. Editar un prompt no es entrenar un modelo.
Registrar resultados por caso y tipo de error
En la prueba posterior registre las versiones del modelo, del prompt y del conjunto de prueba, la derivación esperada, la salida real y la valoración del equipo. La revisión humana prevista es un resultado apropiado para un caso ambiguo. Una asignación definitiva precipitada puede ser un error.
Informe por separado de entradas habituales, ambiguas y ajenas a la tarea. Si un error se utiliza para adaptar la solución, conserve el hallazgo inicial en el informe; el caso sirve después para desarrollar y comprobar si reaparece ese error conocido. Una nueva comprobación independiente requiere otros ejemplos reservados adecuados. La tabla es un punto de partida razonado para seleccionar, no una prueba ejecutada ni evidencia de idoneidad para producción.
Fuentes
Seguir leyendo
Todos los artículos
IA y automatización con ASES
Asistentes de IA y procesos automatizados