Hay un paso en el proceso de desarrollo de herramientas asistidas por modelos de lenguaje grande (LLM) que la mayoría de los equipos omiten porque es tedioso, requiere mucho tiempo y no produce resultados visibles para los usuarios finales: verificar que lo que dice el modelo es realmente correcto. No es fluido, no es coherente, no es relevante para el tema; es correcto en el sentido de identificar con precisión la respuesta correcta al problema específico para el cual se creó la herramienta.
La brecha entre «este resultado me parece correcto» y «este resultado es verificablemente correcto» es donde la mayoría de las herramientas empresariales asistidas por LLM fallan silenciosamente. Pasan la revisión interna porque el resultado suena correcto. Fallan en la producción porque esas personas no estaban revisando contra la verdad del terreno: estaban revisando contra su intuición sobre cómo es una buena respuesta.
Esta distinción es más importante a medida que las herramientas asistidas por LLM pasan de accesorios de productividad a componentes que influyen en las decisiones comerciales reales. Si su herramienta asistida por IA está dando forma a cómo un analista investiga un problema de calidad de datos, cómo un revisor de cumplimiento decide si escala un registro marcado o cómo un equipo de operaciones clasifica una falla de validación, la precisión de su resultado tiene consecuencias reales. «Parece razonable» no es un estándar de evaluación adecuado para eso.
Lo que realmente capta la evaluación cualitativa
El enfoque de evaluación estándar para los resultados de LLM en herramientas empresariales es cualitativo: alguien con conocimiento del dominio revisa una muestra de resultados, la juzga en función de un modelo mental de cómo sería una buena respuesta, y el mensaje se ajusta si demasiados resultados parecen incorrectos.
Esto detecta una clase específica de problemas: resultados obviamente incorrectos, mal formateados o fuera de tema. Estos son problemas reales que vale la pena abordar. También son los fáciles.
Lo que la evaluación cualitativa constantemente pasa por alto es la clase de resultados que están equivocados de maneras que son difíciles de ver sin compararlos con algo externo. Una explicación que identifique con seguridad la causa raíz equivocada, en un lenguaje que parezca autoritario, basada en un razonamiento que parezca plausible, pasa la revisión cualitativa. Falla en el momento en que alguien con el contexto adecuado lo compara con lo que realmente sucedió.
En un sistema cuya propuesta de valor depende de la precisión, «suena plausible» no es lo mismo que «correcto». Los dos pueden divergir significativamente y una revisión cualitativa no le dirá cuándo lo han hecho.
Cómo se ve un arnés de evaluación real
La alternativa es construir un instrumento de evaluación que califique los resultados del modelo comparándolos con la verdad fundamental etiquetada: un conjunto de casos en los que se conoce la respuesta correcta, con los que se puede medir la precisión en lugar de la coherencia.
Creé esto mientras desarrollaba una explicación de la causa raíz de la deriva de la migración de datos: una herramienta que toma un evento de deriva detectado y genera una explicación clasificada de lo que probablemente lo causó. El primer prototipo produjo explicaciones fluidas y específicas que pasaron la revisión cualitativa. Cuando lo probé en casos en los que ya conocía la causa raíz, la explicación era lo suficientemente incorrecta como para importar.
El arnés de evaluación que construí funciona en tres partes.
Primero, un conjunto de datos sintéticos de verdad fundamental: casos en los que la respuesta correcta se conoce por construcción. Esto significó introducir causas específicas y controladas en un proceso de prueba (cambios de esquema, errores de lógica de transformación, cambios de comportamiento del sistema fuente), registrar exactamente lo que introduje y ejecutar el modelo contra los eventos de deriva resultantes. La respuesta correcta para cada caso era la causa que yo había introducido deliberadamente.
Lograr que los escenarios sintéticos fueran lo suficientemente realistas como para ser útiles requirió más cuidado del que esperaba. Las primeras versiones eran demasiado claras: la señal de deriva era obvia de una manera que los eventos de deriva de producción reales no lo son. Agregar ruido realista, señales superpuestas y casos en los que múltiples causas plausibles estaban presentes simultáneamente fue lo que hizo que el conjunto sintético fuera realmente predictivo del rendimiento en el mundo real.
En segundo lugar, una función de puntuación que evalúa la producción clasificada. El binario correcto/incorrecto no es suficiente cuando el modelo produce una lista clasificada de causas probables en lugar de una única respuesta. Una explicación que identifica correctamente la causa raíz como el tercer candidato más probable es significativamente diferente de una que la identifica como la más probable. La función de puntuación evaluó dos dimensiones: presencia (apareció la respuesta correcta en el resultado) y clasificación (qué tan prominente fue en relación con los candidatos incorrectos). Estos se combinaron en una puntuación ponderada que recompensaba tanto por encontrar la respuesta correcta como por clasificarla adecuadamente.
En tercer lugar, una evaluación sistemática de todo el conjunto de datos sintéticos en lugar de una verificación puntual. Pasar el arnés por todo el conjunto revela patrones que la verificación puntual pasa por alto: qué categorías de problemas maneja el modelo de manera confiable, cuáles se equivoca constantemente y qué combinaciones de señales producen la mayor tasa de explicaciones incorrectas y seguras.
Lo que reveló la evaluación
Los resultados fueron más informativos de lo que podría haber sido cualquier revisión cualitativa.
Los escenarios de cambio de esquema obtuvieron buenos resultados: el modelo fue confiable para identificar cambios de esquema ascendentes cuando la evidencia estaba presente y era distintiva. Los errores en la lógica de transformación fueron más difíciles: el modelo identificó consistentemente la categoría general correcta pero atribuyó erróneamente el cambio específico que causó el problema, particularmente cuando se habían realizado múltiples cambios muy juntos. Los escenarios de señales superpuestas fueron los más difíciles: los casos en los que dos causas diferentes ocurrieron cerca en el tiempo produjeron la tasa más alta de explicaciones claramente erróneas.
Ese último hallazgo es el que una revisión cualitativa nunca habría surgido. La confianza expresada por el modelo no se correlacionaba con su precisión: tenía mayor confianza en los casos en los que estaba más equivocado. Sin el arnés de evaluación que midiera la verdad sobre el terreno, ese patrón habría sido invisible.
La implicación práctica para la implementación de la IA empresarial
Para los equipos que implementan herramientas asistidas por LLM en contextos empresariales, particularmente herramientas que influyen en la forma en que las personas investigan problemas, clasifican alertas o toman decisiones de enrutamiento, la pregunta del arnés de evaluación que deben responder antes de la implementación de producción es: ¿Hemos medido la precisión en comparación con los casos en los que sabemos la respuesta correcta, o solo hemos revisado si los resultados parecen razonables?
Si la respuesta es la última, se ha probado la fluidez y coherencia de la herramienta, pero no su corrección. Esas son propiedades diferentes. En el caso de las herramientas que dan forma a las decisiones empresariales, lo que importa es la corrección.
Construir el conjunto de datos sintéticos de verdad sobre el terreno es la parte difícil y en la que vale la pena invertir. Lo obliga a definir con precisión qué significa «correcto» para su caso de uso específico, lo que resulta ser un ejercicio útil independientemente de la evaluación en sí. La función de puntuación y la infraestructura del arnés son relativamente sencillas una vez que se tiene esa definición. Sin él, estás midiendo algo distinto de lo que intentas garantizar.
Arun Mishra es arquitecto empresarial.
¡Bienvenido a la comunidad VentureBeat!
Nuestro programa de publicaciones invitadas es donde los expertos técnicos comparten conocimientos y brindan análisis profundos neutrales y no adquiridos sobre inteligencia artificial, infraestructura de datos, ciberseguridad y otras tecnologías de vanguardia que dan forma al futuro de las empresas.
Leer más de nuestro programa de publicaciones de invitados y consulte nuestro pautas ¡Si estás interesado en contribuir con un artículo propio!
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
