Enfoque de configuración de los tokens de contexto de los LLM

¿Qué es el contexto?

El contexto de un LLM (large language model) suele referirse al rango de información previa que el modelo puede considerar al generar texto. Para un LLM, el contexto funciona como su «memoria», lo que le permite determinar la siguiente acción en función del contenido visto o generado con anterioridad. El contexto puede ser una sola frase, un párrafo, un documento o incluso una colección de varios documentos, según la arquitectura y el diseño del modelo.

El contexto es crucial para los modelos de lenguaje, ya que ayuda al modelo a comprender la tarea actual y a generar respuestas coherentes y pertinentes basadas en información previa. Por ejemplo, en una conversación, el contexto puede incluir todos los turnos hasta ese momento, lo que permite al modelo generar respuestas alineadas con el tema y el tono de la conversación.

Sin embargo, debido a las limitaciones de recursos de computación y memoria, los modelos de lenguaje suelen tener una longitud de contexto fija. La longitud de contexto de los modelos convencionales actuales oscila aproximadamente entre 128K y 1M tokens. A medida que evolucionen los LLM, el soporte de contextos más largos se convertirá en una tendencia habitual. No obstante, desde la perspectiva del coste de tokens, la calidad de las respuestas del LLM y el tiempo de respuesta en entornos empresariales, es esencial una gestión del contexto más precisa y eficiente.

Un token puede ser una palabra, un signo de puntuación o cualquier otra unidad lingüística.

Enfoque de configuración del contexto

Dado que se sabe que el contexto es la «cantidad de información que un LLM puede procesar de una sola vez», la manera de asignar recursos dentro de este espacio de información limitado es un aspecto crítico del diseño de un agente. GPTBots define el contexto del LLM como: Long-term Memory, Short-term Memory, Identity Prompts, User Question, Tools Data y Knowledge Data. Una única interacción con el LLM puede incluir todos estos tipos de contexto, cada uno con prioridades distintas.

Nota: Si la longitud total de todos los tipos de contexto en una sola interacción con el LLM supera el límite del LLM, GPTBots truncará los tipos de contexto de menor prioridad para garantizar el porcentaje de éxito de las llamadas al LLM.

Pregunta del usuario

El contenido de entrada más reciente del usuario durante una conversación con el agente incluye varios tipos de mensajes enviados mediante el cuadro de entrada:

• Text Messages introducidos manualmente
• Audio Messages grabados mediante audio
• Image Messages, Video Messages, Document Messages y File Messages cargados como adjuntos.

Nota:
Cuando la opción «Agent-Configuration-Input-Attachment» se establece en System Recognition, GPTBots reconocerá todos los adjuntos cargados como contenido de texto para tratarlos como Pregunta del usuario.
Para los mensajes de tipo archivo, GPTBots convertirá el archivo en un enlace para tratarlo como Pregunta del usuario.

Prompts de identidad

La información de identidad configurada para el LLM en el agente de GPTBots sirve como un principio importante que guía el trabajo del agente de IA. GPTBots adaptará esto automáticamente a un mensaje del sistema o un mensaje del desarrollador en función de la versión del modelo.

• Los prompts de identidad son cruciales en entornos empresariales y deben redactarse de forma clara y completa para orientar el trabajo y las respuestas de la IA.
• Por lo general, no es necesario preocuparse por la longitud de los prompts de identidad. En comparación con la longitud, la calidad de los prompts de identidad es más importante y merece invertir más tokens.
• Al redactar prompts de identidad, una expresión clara, una lógica correcta y unas instrucciones precisas son fundamentales. Un buen prompt de identidad debe expresar con claridad sus objetivos, principios, habilidades y lógica de trabajo, evitando instrucciones ambiguas.

Memoria a corto plazo

La información de las últimas X rondas de conversación entre el usuario y el agente se incluye en cada solicitud al LLM. Si la función de memoria a corto plazo está desactivada o la conversación acaba de crearse, esta parte estará vacía.

Al configurar, conviene tener en cuenta:

• Si el escenario de negocio del agente no requiere contexto o si el contexto afecta negativamente a la calidad de respuesta de la IA, se puede desactivar la memoria a corto plazo para ahorrar tokens y mejorar el rendimiento del agente.
• Si el agente depende en gran medida del contexto (p. ej., necesita el contexto para responder a preguntas), se debe establecer el recuento de rondas de memoria lo más alto posible.

Datos de conocimiento

Según la entrada del usuario, el agente recupera fragmentos de conocimiento desde la base de conocimiento correspondiente mediante búsqueda vectorial. Si el agente no tiene contenido en la base de conocimiento o no puede recuperar resultados, esta parte estará vacía.

Al configurar, conviene tener en cuenta:

• Si el agente no implica consultas a la base de conocimiento, se puede desactivar la recuperación de conocimiento para ahorrar tokens.
• Si el agente depende en gran medida de los resultados de las consultas a la base de conocimiento (p. ej., escenarios de preguntas y respuestas sobre documentos), se deben configurar el número máximo de fragmentos recuperados, la puntuación de relevancia y otros parámetros en la «Knowledge Base» (base de conocimiento) para garantizar la cantidad y la calidad de RAG (retrieved augmented generation).

Memoria a largo plazo

Según la entrada del usuario, se incluirán los registros históricos de conversación recuperados de todas las conversaciones del agente mediante búsqueda vectorial. Si la función de memoria a largo plazo está desactivada o la conversación acaba de crearse, esta parte estará vacía.

Al configurar, conviene tener en cuenta:

• Si el escenario de negocio del agente depende del contenido histórico de conversaciones (p. ej., personajes virtuales), se debe habilitar la función de memoria a largo plazo.
• Si el escenario del agente no implica el uso de contenido histórico de conversaciones, se puede desactivar para ahorrar tokens.

Datos de herramientas

Cuando el sistema envía datos de solicitud al LLM, incluirá los datos de herramientas seleccionados por el agente para ayudar al LLM a elegir correctamente la herramienta necesaria para la invocación. Tras invocar correctamente la herramienta, los resultados devueltos por el servicio de la API deben enviarse de nuevo al LLM. Si el agente desactiva la función de herramientas, esta sección permanecerá vacía.
Al configurar, conviene tener en cuenta lo siguiente:

• Si el escenario del agente no implica el uso de herramientas, se puede omitir añadir herramientas al agente para ahorrar tokens.
• Cuando una herramienta contiene varias API, se pueden desactivar API específicas innecesarias en la configuración de la herramienta. Las API desactivadas no se enviarán al LLM, con lo que se ahorran tokens.

Salida del LLM

La longitud de tokens de los datos de salida del LLM se determina y se reserva al solicitar el LLM. GPTBots ya permite configurar la longitud de los tokens de respuesta del LLM, y esta sección no se ve afectada por la longitud de la sección de entrada anterior.

Caso práctico

Se ilustra la asignación de tokens de contexto con un ejemplo. Supóngase que se utiliza un modelo de LLM con un límite de contexto de 8K tokens:

Escenario: asistente de atención al cliente

Un agente asistente de atención al cliente en línea necesita:

• Recordar el contenido reciente de la conversación del usuario
• Consultar la base de conocimiento de productos
• Invocar la interfaz de consulta de pedidos
• Mantener una imagen profesional de atención al cliente

Plan de gestión de tokens

Sugerencias de optimización

1. Ajuste dinámico
   • Cuando la consulta del usuario es corta, los tokens ahorrados se pueden asignar automáticamente a los datos de conocimiento.
   • Cuando no se utilizan herramientas, el espacio reservado se puede asignar automáticamente a la memoria a corto plazo.
2. Ejecución por prioridad
   • Cuando el total de tokens supera el límite, truncar según la prioridad:
   • Conservar: Pregunta del usuario, Prompts de identidad, Memoria a corto plazo, Datos de conocimiento, Datos de herramientas
   • Comprimir/Eliminar: Memoria a largo plazo
3. Garantía de eficacia
   • Garantizar la integridad de las funciones principales (p. ej., consulta de pedidos) cuando los tokens son insuficientes.
   • Se puede sacrificar la memoria a largo plazo para garantizar la calidad de la respuesta.

Mediante esta planificación, se pueden implementar las funciones principales del asistente de atención al cliente dentro del espacio de tokens limitado, manteniendo a la vez la coherencia conversacional y la profesionalidad.