MAYAK monta un pipeline de QA de 58 bloques y detecta 9 de las 10 trampas en un documento de requisitos

El autor del proyecto MAYAK ha montado un pipeline que lleva el documento de requisitos técnicos (ТЗ) hasta la ejecución de pruebas a través de 58 bloques especializados. En un ТЗ sintético con diez defectos incluidos a propósito, el sistema automático detectó nueve. El décimo lo encontró una persona, pero con ayuda del cuestionario que había elaborado la máquina. En 90 segundos, el sistema generó 26 preguntas para los stakeholders y marcó 20 zonas grises; en 26 minutos redactó 37 escenarios BDD.

Primero la documentación, después los botones

El nombre del proyecto fija el orden de trabajo: primero se aclaran los requisitos y luego se escriben y ejecutan las pruebas. La cadena es esta: «ТЗ → canonización → diseño de pruebas → ejecución». A juzgar por el nombre de la etapa, la canonización convierte el texto disperso de los requisitos en una forma estructurada y uniforme, sobre la que después se construye el diseño de pruebas. La lógica es clara: las pruebas derivadas de un ТЗ difuso heredan esa vaguedad y solo la disimulan con un formato pulcro.

El proyecto pertenece a una clase cada vez más numerosa de sistemas en los que un LLM no trabaja con un único prompt, sino con un pipeline largo de pasos acotados. Aquí son 58.

Compuertas de confianza en lugar de adivinar

El principal problema de los modelos de lenguaje en el diseño de pruebas es su tendencia a rellenar lo que falta con detalles concretos que suenan plausibles. Si el ТЗ dice «la página debe abrirse rápido», el modelo responde sin dudar «no más de 2 segundos» y lo presenta como criterio de aceptación. El autor de MAYAK cierra ese hueco con dos reglas:

• cada criterio de aceptación se apoya en una cita del documento original: sin cita, no hay criterio;
• una zona gris se convierte en una pregunta al stakeholder, no en un valor adivinado.

Hay un tercer detalle, de carácter económico. Las ejecuciones repetidas no tienen coste gracias a la caché. Con 58 bloques, esto importa mucho: el ТЗ se corrige a medida que llegan las respuestas a las preguntas, y sin caché cada iteración se pagaría de nuevo.

Qué mostró la ejecución

La comprobación se hizo con un ТЗ sintético en el que el autor había incluido de antemano diez «enfermedades». Resultados del anuncio:

• el sistema automático detectó 9 de las 10 trampas;
• la décima la encontró una persona a partir del cuestionario de la máquina;
• las 26 preguntas para los stakeholders se generaron en 90 segundos;
• se identificaron 20 zonas grises;
• los 37 escenarios BDD estuvieron listos en 26 minutos.

Estas cifras hay que leerlas con cautela. Las trampas las ideó el propio autor, el documento es sintético y se hizo una sola ejecución. Es una demostración de que el sistema funciona, no un benchmark. Los ТЗ reales suelen ser más largos, más contradictorios y, en algunos puntos, los escriben personas que no saben qué quieren. El propio autor promete contar dónde miente la plataforma y qué queda por pulir. Esas secciones están en el texto completo en Habr; el anuncio no incluye detalles, así que de momento no se puede evaluar la magnitud de los errores.

Lo que ocurrió con la décima trampa resulta especialmente interesante. El sistema no la cerró por sí solo, pero su cuestionario ayudó a una persona a encontrarla. En la práctica, esto no es una debilidad, sino un esquema normal: la máquina acota el campo de búsqueda y la persona toma la decisión.

Qué llevarse a la práctica

Se pueden adoptar varias técnicas del proyecto sin copiarlo entero:

• Ejecute su pipeline sobre un documento con defectos incluidos de antemano y calcule la proporción de los detectados. Sin una referencia así, hablar de calidad se queda en opiniones.
• Exija al modelo una cita-fuente para cada criterio de aceptación y descarte automáticamente todo lo que no la tenga.
• Mida no solo el número de escenarios generados, sino también la proporción de preguntas a las que los stakeholders han respondido de verdad. Un buen cuestionario no sirve de nada si nadie lo contesta.
• Almacene en caché los resultados intermedios de los bloques, para que corregir un párrafo del ТЗ no obligue a reiniciar todo el pipeline.
• Deje a una persona en la revisión final. Nueve de diez en un documento sintético no garantiza nada todavía en un documento real.

Si tiene acumulado un archivo de ТЗ cuyos problemas se conocen a posteriori, ya dispone de un conjunto de pruebas listo para este enfoque.