Mejores prácticas para controlar las alucinaciones LLM a nivel de aplicación

Los modelos de lenguaje grandes (LLM) ofrecen un potencial transformador para el desarrollo de aplicaciones, pero plantean un desafío crítico con las alucinaciones. Descubra estrategias prácticas, basadas en la ingeniería, para desarrollar funciones fiables basadas en LLM.

Los modelos de lenguaje grandes (LLM) se están integrando en las aplicaciones a un ritmo vertiginoso, prometiendo revolucionar la experiencia del usuario. Pero, como cualquier equipo que trabaja en primera línea te dirá, esto conlleva un desafío crítico: las alucinaciones.

La capacidad de un LLM para inventar, extrapolar y fabricar información con seguridad no es un error que deba corregirse, sino una característica esencial de su naturaleza creativa. Para los desarrolladores, esto significa que no podemos simplemente esperar que un modelo no presente alucinaciones esta vez y esperar que todo salga bien. Debemos construir sistemas que anticipen este comportamiento y lo controlen a nivel de aplicación.

En Parasoft, mientras integración de LLMs En nuestros productos de prueba de software, nos hemos topado con el desafío de gestionar las alucinaciones. En un proyecto interno inicial, le dimos a un LLM información resumida de una definición de servicio OpenAPI y le pedimos que creara escenarios a partir de... APIComo señaló uno de nuestros ingenieros: «A veces respondía con dos API reales y una inventada».

Sin ningún tipo de protección, los LLM son impredecibles, lo que hace que las aplicaciones que dependen de ellos no sean confiables.

En este blog, quiero compartir algunas estrategias prácticas basadas en ingeniería que nuestros equipos han desarrollado para crear funciones confiables con LLM.

1. Establezca límites en sus indicaciones

La primera línea de defensa contra las alucinaciones es el estímulo mismo, y el enfoque más eficaz suele ser el más directo.

Una técnica muy básica consiste en proporcionar al LLM reglas fundamentales sobre su comportamiento, como indicarle que no invente información. Por ejemplo, se pueden usar indicaciones como:

• "Por favor, responda únicamente la información que le proporcioné".
• "Por favor, no crees elementos nuevos que no existían".

Este enfoque actúa como una barrera de seguridad principal. Evita que el modelo recurra a sus tendencias creativas y fundamenta su respuesta en el contexto específico que usted ha proporcionado.

Hasta ahora, consideramos que esta es una forma sencilla de empezar a gestionar las alucinaciones desde su origen. Además, los LLM admiten un parámetro llamado "temperatura" que controla la creatividad del modelo. Cuando la consistencia y la precisión son importantes, configure la temperatura del modelo en un valor bajo (~0) y auméntela solo cuando necesite que el LLM sea más creativo. Pero sea directo y dígale exactamente lo que quiere.

2. Imponer la estructura de salida con esquemas

Las instrucciones claras son un buen comienzo, pero para una verdadera fiabilidad, se necesita cumplimiento. Aquí es donde se pasa de "decirle" al LLM lo que se desea a "obligarlo" programáticamente a cumplir con un formato de salida específico mediante salidas estructuradas.

La mayoría de los principales proveedores de modelos permiten definir un esquema JSON obligatorio en la llamada a la API que indica al modelo el formato específico en el que se desean los datos mediante una función llamada "salidas estructuradas". Esto limita la respuesta del modelo, garantizando que se ajuste a los campos, tipos de datos y estructura definidos, para que el código pueda depender de ese formato específico.

Por ejemplo, cuando le pedimos a un modelo que genere una tabla de datos, utilizamos un esquema como este:

JSON

"data": {

  "type": "object",

  "description": "The generated data table based on user requirements.",

  "properties": {

    "columnNames": {

      "type": "array",

      "description": "Header row of the table containing the column names.",

      "items": { "type": "string" }

    },

    "generatedDataRows": {

      "type": "array",

      "items": {

        "type": "array",

        "description": "A row of data with the generated values for each column.",

        "items": { "type": "string" }

      }

    }

  }

}

Esto garantiza que el modelo devuelva un objeto JSON limpio que contenga un columnNames matriz y una generatedDataRows Matriz: no un párrafo sin estructura ni un JSON mal formado. El uso de salidas estructuradas se volvió esencial cuando vimos que el LLM devolvía una respuesta que no contenía los datos en un formato programático.

Para manejar modelos que no admiten salidas estructuradas, descubrimos que podemos incluir el esquema JSON en el propio indicador del sistema, lo que no garantiza el resultado esperado pero es una alternativa sorprendentemente efectiva.

3. Fundamentar las respuestas con evidencia externa (Recuperación-Generación Aumentada)

Si bien las instrucciones directas y los resultados estructurados le brindan control sobre la solicitud y el formato de resultado, también necesita controlar el conocimiento que utiliza el LLM para generar su respuesta.

En lugar de permitir que el modelo se base únicamente en sus vastos y, a veces, obsoletos datos de entrenamiento internos, puede fundamentarlo en el conocimiento del dominio mediante la técnica de recuperación-generación aumentada (RAG). Esto incorpora un paso adicional para mejorar los resultados de LLM al agregar información de fuentes de conocimiento externas antes de generar una respuesta.

Al proporcionar información adicional específica del dominio, se cambia la tarea de "recordar una respuesta de la memoria general" a "obtener una respuesta a partir de estos datos específicos". Esto reduce drásticamente las alucinaciones.

Por ejemplo, en lugar de pedirle al modelo que nombre las API relacionadas de memoria (donde podría inventar una), una técnica RAG primero recuperaría las definiciones reales de las API válidas y luego le pediría al LLM que las resuma.

Esto sitúa el modelo en el contexto relevante y mantiene la información actualizada.

4. Dividir la lógica compleja en agentes separados

Un error inicial común al trabajar con LLM es crear indicaciones complejas llenas de lógica condicional, intentando "programar" el LLM para que se comporte de forma diferente según las condiciones. Este tipo de sobreexplicación suele confundir a los LLM, de modo que se centran en información errónea y ofrecen resultados inesperados. Incluso si la indicación compleja funciona para un modelo, puede no funcionar para otros.

Nos dimos cuenta de que una mejor estrategia es dividir el flujo de trabajo en agentes más pequeños, cada uno de los cuales sabe cómo realizar una tarea específica. A medida que el flujo de trabajo avanza, el control se transfiere entre los agentes según la información del usuario y el siguiente paso. En lugar de intentar controlar el comportamiento del modelo con una sola indicación, se divide el comportamiento entre los diferentes agentes. Esto permite que el LLM se centre en la tarea específica en cada paso.

5. Verificación automatizada

Incluso con indicaciones directas sencillas y RAG, un LLM puede malinterpretar el material original o distorsionar la verdad. El siguiente nivel de defensa es un paso de "confianza, pero verificación" que verifica el resultado del modelo antes de continuar con el flujo de trabajo.

Los LLM de "juicio" ligeros pueden comparar el resultado del LLM con la información recuperada utilizada en RAG para asignar un puntaje de confianza. Los resultados que caen por debajo de un umbral específico se presentan al LLM de nuevo de una manera diferente, o incluso se rechazan automáticamente, lo que permite que el flujo de trabajo continúe con el contenido ya examinado.

Otra técnica consiste en utilizar filtros de posprocesamiento basados en reglas que validan la salida de LLM según las expectativas conocidas. Es importante aclarar que estas comprobaciones no juzgan la calidad semántica de la La respuesta de la IAPor ejemplo, al preguntar: "¿Es una buena idea?", validan su integridad estructural o el contenido de su resultado.

Como lo expresó uno de nuestros ingenieros, es necesario que el código verifique la respuesta. Esto garantiza que el resultado se ajuste a las reglas de negocio conocidas antes de que la aplicación lo utilice.

6. Verifique con un humano en el circuito

Las técnicas que hemos mencionado pueden ayudarle a reducir las alucinaciones, pero al final, a menudo es necesario incorporar supervisión humana al flujo de trabajo respaldado por el producto, para que el usuario tenga la decisión final sobre lo que se produce.

La necesidad de esto depende de la gravedad de las consecuencias de la información incorrecta. En algunos casos, podría requerirse condicionalmente la intervención humana basada en la validación automatizada del resultado del LLM, como se mencionó anteriormente.

Para solicitar retroalimentación humana, implementamos un flujo de agente de varios pasos que solicita la participación humana en varios puntos del proceso. Un excelente ejemplo es nuestro Agente de Creación de Escenarios de Prueba:

1. Triaje. La solicitud de un usuario ("crear un nuevo escenario de prueba") se envía al agente de creación de pruebas especializado.
2. Aclaración. El agente interactúa con el usuario para recopilar la información necesaria, como una URL de definición de servicio.
3. Propuesta. El agente propone un plan de las pruebas que creará y solicita la aprobación del usuario.
4. Ejecución. Solo después de que el usuario haga clic en "Aprobar" se genera y guarda el escenario de prueba.

Este patrón de proponer-luego-ejecutar otorga al usuario el control final, creando un punto de control crucial que evita que el sistema actúe según una alucinación que parece plausible pero que en realidad es incorrecta.

Construir para la realidad añade confiabilidad y reduce el estrés

Controlar las alucinaciones no consiste en encontrar una única indicación mágica. Se trata de construir un sistema de defensa multicapa dentro de la aplicación, basado en técnicas como las que hemos mencionado.

Dado que los LLM van a alucinar, es necesario construir una serie de defensas para garantizar resultados fiables. Al combinar instrucciones resilientes, esquemas reforzados y un proceso de verificación robusto, se puede pasar de esperar que un LLM se comporte bien a diseñar un sistema que compense posibles errores y produzca resultados fiables.

A medida que la tecnología evolucione, es posible que estas barreras a nivel de aplicación cambien. Mientras tanto, téngalas en cuenta para obtener mayor fiabilidad de los LLM al integrarlos en sus aplicaciones.