Un desarrollador logra un 73–86% de coincidencia con un experto al completar cuestionarios de ingeniería

Un ingeniero tiene que completar un cuestionario para el proveedor de un instrumento industrial: debe indicar la presión, los materiales, la adecuación climática y la protección contra explosiones. Las respuestas están repartidas entre cientos de páginas de especificaciones técnicas. Parece una tarea hecha a medida para un LLM: encontrar el fragmento pertinente y trasladar el valor a una tabla. En el proyecto descrito en Habr, la primera versión solo completaba correctamente alrededor de un tercio de las celdas.

En dos meses, el autor logró que el sistema alcanzara un 73–86% de coincidencia con un ingeniero en tres proyectos, contando únicamente las filas que este había respondido. Pero el análisis de los errores resulta más útil que la cifra final. El sistema confundía parámetros cercanos, intentaba adivinar decisiones internas del departamento y trataba como preguntas filas que no requerían ninguna respuesta del ingeniero.

La cita es auténtica, la respuesta es incorrecta

La primera versión seguía un método habitual: para cada celda, la búsqueda devolvía doce fragmentos de las especificaciones técnicas y el modelo generaba un valor y una cita. El código comprobaba si la cita existía realmente. No bastó.

Un ejemplo sencillo: el sistema escribe «Garantía: 30 años». La cifra aparece en el documento, pero se refiere a la vida útil del equipo. La garantía real, de 36 meses, figura cerca. La comprobación de la fuente se supera y el ingeniero recibe una respuesta incorrecta.

El autor dejó la cumplimentación en manos de reglas y una base de referencia, y reservó al modelo la extracción de hechos. En los casos en que se aplicaban las reglas, el 86–92% de las respuestas eran correctas. En el conjunto de las celdas de otros dos proyectos, el resultado fue del 58%. Las reglas también trasladaban particularidades de un proyecto a otro.

Mejorar la búsqueda por sí sola no garantizaba un avance. Tras ajustar un modelo pequeño mediante entrenamiento adicional, el apartado pertinente pasó a ocupar el primer puesto en el 63% de las filas, frente al 52% anterior, pero no aumentó el número de valores correctos. La siguiente etapa seguía tomando el primer fragmento del que conseguía extraer algo. Ayudó añadir condiciones: comprobar una palabra clave del parámetro y la unidad de medida del plazo.

Para un equipo que desarrolla búsquedas sobre documentos corporativos, la lección es importante: hay que medir toda la cadena hasta la respuesta final. Unos resultados de búsqueda mejores no sirven si el siguiente paso los utiliza mal.

Parte del conocimiento reside en el departamento

La revisión de un ingeniero reveló un problema más profundo. Entre las filas no estándar de los primeros cuatro proyectos, el autor no encontró respuestas en los documentos en el 65–83% de los casos. En una revisión manual de veinte de esas filas, aproximadamente la mitad resultaron ser decisiones del departamento que llevaban años pasando de un cuestionario a otro.

El modelo no podía extraer esa información de las especificaciones técnicas. No estaba allí. Por eso se incorporaron al sistema cuestionarios anteriores y normas del departamento. La coincidencia de respuestas en dos proyectos ofrecía una base más sólida para proponer una respuesta análoga que un único ejemplo. Aun así, los parámetros de un entorno de operación concreto exigen cautela: un valor de otro proyecto puede no ser adecuado.

En la interfaz de trabajo, cada respuesta incluye un enlace al apartado del documento, una cita y una página con el pasaje resaltado. Si no hay fundamento, la fila queda vacía y se añade a las preguntas para el cliente. El sistema presenta por separado las conclusiones derivadas de normas, con una explicación, para que las revise el ingeniero.

Un producto así ayuda a recopilar y verificar información. Su valor práctico también depende de lo fácil que le resulte al especialista confirmar un valor, corregirlo y guardar la decisión para el siguiente proyecto.

Los porcentajes atractivos también deben comprobarse

El autor encontró varios errores en su propia evaluación. Las casillas de los formularios se interpretaban mal. Las respuestas del proyecto evaluado se filtraban a la base de datos a través de normas antiguas: el resultado parecía ser del 71%, en lugar del 61% real. La comparación aproximada aceptaba IP54 como IP65, aunque son designaciones de protección distintas.

Por último, más de la mitad de las filas del formulario resultaron ser requisitos, listas y campos de firma. Al excluirlas, el grado de cumplimentación subió del 45 al 81%. No se añadió ni una sola respuesta correcta: se corrigió el denominador.

El 73–86% final también tiene una limitación. Aunque el sistema no había visto las respuestas de los tres proyectos de evaluación, el autor ajustó las reglas a partir de sus errores. En dos proyectos, las tablas de los documentos escaneados se trasladaron manualmente a Excel. Es un resultado de laboratorio; la evaluación con un proyecto nuevo sigue pendiente.

La conclusión práctica para los desarrolladores: antes de cambiar de LLM, conviene revisar la estructura del formulario, las fuentes de conocimiento, la búsqueda y el método de evaluación. Para quien gestiona el producto, la siguiente pregunta es cuánto tiempo dedica el ingeniero a revisar y corregir. Eso mostrará hasta qué punto el sistema ayuda en el trabajo.