Un LLM no es un solver

Por qué importa

Los productos de chat colapsan cuatro afirmaciones distintas en una frase: «el periodo es 0.42 s». Esa frase podría ser un cálculo determinista, una sugerencia de IA, un juicio humano o un resultado validado. No son intercambiables. Mezclarlos es cómo texto no verificado termina en paquetes de cálculo.

Este sitio trata la programación y la IA como herramientas para problemas de ingeniería, no como autoridades. Un modelo de lenguaje puede ayudarte a escribir, buscar y redactar. No reemplaza un solver, una norma ni al ingeniero que firma.

Cuatro roles que el lenguaje de marketing aplana

Mantén estos roles separados en cada flujo, incluidos los que nunca abren una ventana de chat.

Cálculo determinista. Mismos insumos documentados, mismo algoritmo, mismas salidas. El camino es inspeccionable: una derivación, una hoja bloqueada, un modelo OpenSees escrito, una expresión publicada en forma cerrada. Si no puedes repetirlo, no es este rol.

Sugerencia de IA. Generación de tokens condicionada a un prompt y a datos de entrenamiento. El texto puede parecer Tcl, Python o un número de cláusula. Parecer ingeniería no es ejecutar ingeniería. El muestreo, los límites de contexto y los datos de proyecto faltantes cambian la salida. Trátalo como un borrador de un interno sin licencia que nunca ha visto tus planos.

Revisión humana. Una persona con la competencia y la autoridad para la decisión lee la sugerencia, la edita, la rechaza o la acepta en un proceso comprobado. Revisar no es «el modelo sonó seguro». Es un individuo nombrado aplicando juicio a un alcance concreto.

Evidencia de validación. Comparación independiente contra algo que no comparte el mismo modo de falla: un cálculo a mano de un caso reducido, una solución conocida de un libro, un segundo motor de análisis, un resultado de laboratorio o una suite de regresión en la que ya confías. Una captura de un chat no es evidencia.

Si un entregable no puede decir qué rol está desempeñando, asume que es una sugerencia.

Qué hace de verdad un solver

Un solver estructural (OpenSees, un programa comercial de elementos finitos, incluso un script corto que implementa T = 2π√(m/k) para un oscilador SDOF declarado) opera sobre un modelo que tú definiste. Aplica un método numérico a ese modelo. El equilibrio, la compatibilidad y los supuestos constitutivos viven en el modelo y en el método, no en la prosa en español o inglés.

Eso no hace al solver «verdadero». Hace el cálculo reproducible. Puedes cambiar la rigidez de un resorte, volver a correr y ver moverse el periodo. Puedes imprimir la tangente, los residuales, el autovalor. Puedes archivar el mazo de entrada.

La reproducibilidad es el piso. La corrección sigue exigiendo que el modelo coincida con la mecánica pretendida, que las unidades sean consistentes y que alguien compare el resultado con una comprobación independiente.

Qué hace de verdad un modelo de lenguaje

Un modelo de lenguaje predice continuaciones probables de texto. No conoce tus secciones a menos que las hayas pegado. No impone equilibrio. No abre ASCE 7, Eurocódigo 8 o NSR-10 como una base controlada a menos que hayas construido esa capa de recuperación — y aun entonces la frase generada no es el texto legal.

Puede emitir un fragmento plausible de OpenSees con la transformación geométrica equivocada. Puede citar una cláusula que no existe. Puede mezclar ediciones. Esos fallos son normales para la tecnología. Son inaceptables como base de diseño sin revisar.

Una distinción trabajada, no un diseño

Supón que la pregunta de ingeniería es el periodo no amortiguado de un oscilador de un grado de libertad con masa m y rigidez k declaradas.

• Cálculo determinista: computa T = 2π√(m/k) en un entorno comprobado, con las unidades escritas. Archiva m, k y T.
• Sugerencia de IA: un chat responde «unos 0.4 segundos». Ese número no tiene pie hasta que exista el cálculo de arriba.
• Revisión humana: un ingeniero confirma que la idealización SDOF es siquiera la pregunta correcta (a menudo no lo es, para un edificio).
• Evidencia de validación: para este caso de juguete, la expresión en forma cerrada es la referencia. Para un modelo elástico de varios pisos, la evidencia se parece a la comparación con un segundo modelo, un ejemplo de libro con frecuencias publicadas o una regresión de solver — no al acuerdo con un chatbot.

Este ejemplo es pedagógico. No es el periodo de un edificio, un periodo aproximado de norma ni un sustituto del análisis modal de un sistema real.

Un flujo que mantiene los roles honestos

1. Declara la pregunta de ingeniería y la comprobación de aceptación antes de cualquier prompt (¿qué te haría desconfiar de la respuesta?).
2. Usa un modelo, si acaso, para redactar entrada, comentarios o una lista de control.
3. Un humano edita geometría, restricciones, materiales y opciones de análisis hasta ser dueño del modelo.
4. Un solver corre. Advertencias, no convergencia y mecanismos inesperados son resultados de primer orden.
5. Se registra una comprobación independiente. Si no puedes nombrarla, no tienes evidencia de validación.
6. Solo entonces un ingeniero responsable acepta el resultado en un entregable.

Sáltate un paso y vuelves a la sugerencia.

Errores habituales

• Pedirle a un chat «el refuerzo requerido» o «el cortante de piso» y pegar la frase en un informe.
• Tratar citas generadas de normas de diseño como la norma.
• Confiar en un archivo OpenSees o Python generado porque corre. Ejecutar no es verificar.
• Usar el mismo modelo tanto para producir el número como para «confirmarlo».
• Llamar «validación» a una puntuación de confianza, a una respuesta más larga o a un rastro de chain-of-thought.

Limitaciones

Este artículo no clasifica asistentes comerciales, no especifica una jurisdicción y no define el procedimiento de QA de una firma. Las observaciones de SDOF en forma cerrada no son análisis modal de edificios. Las referencias a solvers nombran una clase de herramientas; no respaldan una versión concreta ni un archivo de entrada.

Los sistemas de IA cambian. Un flujo que era inseguro el año pasado no se vuelve automáticamente seguro porque un proveedor añadió «citas». Las citas siguen teniendo que abrirse, comprobarse de edición y aplicarse por una persona autorizada a aplicarlas.

Contexto profesional

La práctica con licencia, la responsabilidad profesional y los cálculos sellados son constructos legales y profesionales. No se transfieren a un proveedor de modelo. Si tu jurisdicción exige comprobaciones documentadas, una transcripción de LLM no cumple ese listón. Si eres estudiante, la misma disciplina aplica: el punto del ejercicio es que tú puedas defender el número.

Material relacionado en este sitio puede recorrer un primer modelo elástico de OpenSees o teoría de dinámica. Esas entradas siguen sin sustituir el análisis específico de un proyecto. Úsalas para practicar los cuatro roles, no para saltártelos.

Referencias

• Documentación de OpenSees — opensees.github.io/OpenSeesDocumentation. Documentación oficial del solver, no una autoridad de IA.
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0) — nist.gov/itl/ai-risk-management-framework. Útil para hablar de medición y riesgo residual; no es una norma de diseño estructural.
• Chopra, A. K. Dynamics of Structures. Usa una edición impresa o licenciada para la teoría. Este artículo no la reproduce.

Evaluación y limitaciones

Trata las notas siguientes como contexto de evaluación, no como un cálculo o una revisión verificados.

Evalúa cualquier flujo asistido por IA nombrando cuál de los cuatro roles ocupa cada artefacto. Si no puedes señalar un cálculo determinista, un revisor nombrado y evidencia de validación registrada, la salida sigue siendo una sugerencia. Este artículo no valida una herramienta de proveedor, un prompt ni una versión de modelo.