Trabajo como ingeniero de inteligencia artificial en un nicho particular: la automatización de documentos y la extracción de información. En mi sector, el uso de modelos de lenguaje de gran tamaño ha presentado una serie de desafíos en lo que respecta a las alucinaciones. Imaginemos que una IA lee incorrectamente el importe de una factura como 100 000 dólares en lugar de 1000, lo que da lugar a un pago excesivo de 100 veces. Cuando nos enfrentamos a tales riesgos, prevenir las alucinaciones se convierte en un aspecto fundamental para crear soluciones de inteligencia artificial sólidas. Estos son algunos de los principios clave en los que me centro al diseñar soluciones que pueden ser propensas a las alucinaciones.
Existen varias formas de incorporar la supervisión humana en los sistemas de IA. A veces, la información extraída siempre se presenta a un humano para su revisión. Por ejemplo, se puede mostrar un currículum analizado a un usuario antes de enviarlo a un sistema de seguimiento de candidatos (ATS). Más a menudo, la información extraída se agrega automáticamente a un sistema y solo se marca para su revisión humana si surgen posibles problemas.
Una parte crucial de cualquier plataforma de IA es determinar cuándo incluir la supervisión humana. Esto suele implicar distintos tipos de reglas de validación:
1. Reglas simples, como garantizar que los totales de cada artículo coincidan con el total de la factura.
2. Búsquedas e integraciones, como validar el monto total frente a una orden de compra en un sistema de contabilidad o verificar los detalles de pago frente a los registros anteriores de un proveedor.
Estos procesos son buenos, pero tampoco queremos una IA que active constantemente medidas de seguridad y obligue a la intervención humana manual. Las alucinaciones pueden frustrar el propósito de usar una IA si activa constantemente estas medidas de seguridad.
Una solución para prevenir las alucinaciones es utilizar modelos de lenguaje pequeños (SLM, por sus siglas en inglés), que son “extractivos”. Esto significa que el modelo etiqueta partes del documento y recopilamos estas etiquetas en resultados estructurados. Recomiendo intentar utilizar un SLM siempre que sea posible en lugar de utilizar modelos de lenguaje pequeños por defecto para cada problema. Por ejemplo, en el análisis de currículums para bolsas de trabajo, esperar más de 30 segundos para que un modelo de lenguaje pequeño procese un currículum suele ser inaceptable. Para este caso de uso, hemos descubierto que un SLM puede proporcionar resultados en 2 o 3 segundos con mayor precisión que modelos más grandes como GPT-4o.
Un ejemplo de nuestro pipeline
En nuestra startup, un documento puede ser procesado por hasta 7 modelos diferentes, de los cuales solo 2 pueden ser LLM. Esto se debe a que un LLM no siempre es la mejor herramienta para el trabajo. Algunos pasos, como la Generación Aumentada de Recuperación, se basan en un pequeño modelo multimodal para crear incrustaciones útiles para la recuperación. El primer paso (detectar si algo es un documento) utiliza un modelo pequeño y superrápido que logra una precisión del 99,9 %. Es vital dividir un problema en pequeños fragmentos y luego determinar para qué partes son más adecuados los LLM. De esta manera, se reducen las posibilidades de que se produzcan alucinaciones.
Cómo distinguir entre alucinaciones y errores
Me propongo diferenciar entre alucinaciones (el modelo que inventa información) y errores (el modelo que malinterpreta la información existente). Por ejemplo, seleccionar la cantidad de dólares incorrecta como total de un recibo es un error, mientras que generar una cantidad inexistente es una alucinación. Los modelos extractivos solo pueden cometer errores, mientras que los modelos generativos pueden cometer errores. ambos errores y alucinaciones.
Cuando utilizamos modelos generativos necesitamos alguna forma de eliminar las alucinaciones.
Toma de tierra Se refiere a cualquier técnica que obliga a un modelo de IA generativa a justificar sus resultados con referencia a alguna información autorizada. La forma en que se gestiona la puesta a tierra es una cuestión de tolerancia al riesgo para cada proyecto.
Por ejemplo, una empresa con una bandeja de entrada de uso general podría intentar identificar elementos de acción. Por lo general, los correos electrónicos que requieren acciones se envían directamente a los gerentes de cuentas. Una bandeja de entrada general que está llena de facturas, correo no deseado y respuestas simples («gracias», «OK», etc.) tiene demasiados mensajes para que los revisen los humanos. ¿Qué sucede cuando se envían acciones por error a esta bandeja de entrada general? Las acciones se pasan por alto con frecuencia. Si un modelo comete errores pero, en general, es preciso, ya está haciendo mejor las cosas que no haciendo nada. En este caso, la tolerancia a los errores o alucinaciones puede ser alta.
Otras situaciones pueden justificar una tolerancia al riesgo especialmente baja, como los documentos financieros y el “procesamiento directo”. En este caso, la información extraída se agrega automáticamente a un sistema sin que la revise un humano. Por ejemplo, una empresa podría no permitir que las facturas se agreguen automáticamente a un sistema de contabilidad a menos que (1) el monto del pago coincida exactamente con el monto de la orden de compra y (2) el método de pago coincida con el método de pago anterior del proveedor.
Incluso cuando los riesgos son bajos, siempre soy cauteloso. Siempre que me concentro en la extracción de información sigo una regla simple:
Si se extrae texto de un documento, debe coincidir exactamente con el texto que se encuentra en el documento.
Esto es complicado cuando la información está estructurada (por ejemplo, una tabla), especialmente porque los archivos PDF no contienen ninguna información sobre el orden de las palabras en una página. Por ejemplo, la descripción de un elemento de línea puede dividirse en varias líneas, por lo que el objetivo es dibujar un cuadro coherente alrededor del texto extraído independientemente del orden de izquierda a derecha de las palabras (o de derecha a izquierda en algunos idiomas).
Obligar al modelo a señalar el texto exacto en un documento es una «base sólida». La base sólida no se limita a la extracción de información. Por ejemplo, se podría exigir a los chatbots de atención al cliente que citen (textualmente) respuestas estandarizadas en una base de conocimiento interna. Esto no siempre es ideal, dado que las respuestas estandarizadas podrían no ser capaces de responder la pregunta de un cliente.
Otra situación complicada es cuando es necesario inferir información a partir del contexto. Por ejemplo, una IA de asistente médico podría inferir la presencia de una afección basándose en sus síntomas sin que la afección médica se mencione expresamente. Identificar dónde se mencionaron esos síntomas sería una forma de “fundamentación débil”. La justificación de una respuesta debe existir en el contexto, pero el resultado exacto solo se puede sintetizar a partir de la información proporcionada. Un paso de fundamentación adicional podría ser obligar al modelo a buscar la afección médica y justificar que esos síntomas son relevantes. Esto puede requerir aún una fundamentación débil porque los síntomas a menudo se pueden expresar de muchas maneras.
El uso de la IA para resolver problemas cada vez más complejos puede dificultar el uso de la fundamentación. Por ejemplo, ¿cómo fundamentar los resultados si se requiere que un modelo realice un “razonamiento” o infiera información del contexto? A continuación, se presentan algunas consideraciones para agregar fundamentación a problemas complejos:
- Identificar decisiones complejas que se puedan desglosar en un conjunto de reglas. En lugar de hacer que el modelo genere una respuesta a la decisión final, haga que genere los componentes de esa decisión. Luego, utilice reglas para mostrar el resultado. (Advertencia: esto a veces puede empeorar las alucinaciones. Si se le hacen varias preguntas al modelo, este tendrá múltiples oportunidades de alucinar. Podría ser mejor hacerle una sola pregunta, pero hemos descubierto que los modelos actuales son generalmente peores en el razonamiento complejo de varios pasos).
- Si algo se puede expresar de muchas maneras (por ejemplo, descripciones de síntomas), un primer paso podría ser lograr que el modelo etiquete el texto y lo estandarice (lo que suele denominarse “codificación”). Esto podría abrir oportunidades para una base más sólida.
- Configurar «herramientas» para que el modelo las llame y que restrinjan la salida a una estructura muy específica. No queremos ejecutar código arbitrario generado por un LLM. Queremos crear herramientas que el modelo pueda llamar y dar restricciones sobre lo que contienen esas herramientas.
- Siempre que sea posible, incluya conocimientos básicos sobre el uso de herramientas (por ejemplo, validando las respuestas frente al contexto antes de enviarlas a un sistema posterior).
- ¿Hay alguna manera de validar el resultado final? Si no es posible crear reglas personalizadas, ¿podríamos crear un mensaje para la verificación? (Y seguir las reglas anteriores también para el modelo verificado).
- Cuando se trata de extracción de información, no toleramos resultados que no se encuentren en el contexto original.
- Continuamos con pasos de verificación que detectan errores y alucinaciones.
- Todo lo que hacemos más allá de eso tiene que ver con la evaluación y minimización de riesgos.
- Divida los problemas complejos en pasos más pequeños e identifique si es necesario un LLM.
- Para problemas complejos utilice un enfoque sistemático para identificar tareas verificables:
— Una base sólida obliga a los licenciados en derecho a citar textualmente fuentes confiables. Siempre es preferible utilizar una base sólida.
—La base débil obliga a los LLM a hacer referencia a fuentes confiables pero permite la síntesis y el razonamiento.
—Cuando un problema se pueda dividir en tareas más pequeñas, utilice una base sólida para las tareas siempre que sea posible.