El auge de las operaciones rápidas: cómo abordar los costos ocultos de la IA derivados de las entradas incorrectas y la sobrecarga de contexto

Este artículo forma parte del número especial de VentureBeat, «El coste real de la IA: rendimiento, eficiencia y retorno de la inversión a gran escala». Lea más en este número especial.

Los proveedores de modelos continúan lanzando modelos de lenguaje grande (LLM) cada vez más sofisticados, con ventanas de contexto más amplias y capacidades de razonamiento mejoradas.

Esto permite que los modelos procesen y “piensen” más, pero también aumenta la capacidad de procesamiento: cuanto más absorbe y produce un modelo, más energía gasta y mayores son los costos.

Si a esto le sumamos todos los ajustes necesarios para generar indicaciones (pueden necesitarse varios intentos para llegar al resultado deseado y, a veces, la pregunta en cuestión simplemente no necesita un modelo que pueda pensar como un doctor), el gasto de cálculo puede salirse de control.

Esto está dando lugar a operaciones rápidas, una disciplina completamente nueva en la era naciente de la IA .

“La ingeniería de prompts es similar a la escritura, la creación en sí, mientras que las operaciones de prompts son como la publicación, donde se evoluciona el contenido”, declaró Crawford Del Prete, presidente de IDC , a VentureBeat. “El contenido está vivo, cambia, y es importante asegurarse de perfeccionarlo con el tiempo”.

El uso y el costo computacional son dos conceptos relacionados, pero separados, en el contexto de los LLM, explicó David Emerson, científico aplicado del Vector Institute . Generalmente, el precio que pagan los usuarios varía en función de la cantidad de tokens de entrada (lo que el usuario solicita) y de la cantidad de tokens de salida (lo que el modelo entrega). Sin embargo, no se modifican para acciones internas como metaindicaciones, instrucciones de dirección o generación aumentada por recuperación (RAG).

Si bien un contexto más extenso permite a los modelos procesar mucho más texto a la vez, esto se traduce directamente en un número significativamente mayor de FLOPS (una medida de potencia de cómputo), explicó. Algunos aspectos de los modelos de transformador incluso escalan cuadráticamente con la longitud de entrada si no se gestionan adecuadamente. Las respuestas innecesariamente largas también pueden ralentizar el tiempo de procesamiento y requerir cómputo adicional y costos adicionales para desarrollar y mantener algoritmos que posprocesen las respuestas y las conviertan en la respuesta que los usuarios esperaban.

Normalmente, los entornos de contexto más extensos incentivan a los proveedores a proporcionar respuestas deliberadamente detalladas, afirmó Emerson. Por ejemplo, muchos modelos de razonamiento más complejos ( como o3 u o1 de OpenAI ) suelen proporcionar respuestas extensas incluso a preguntas sencillas, lo que genera elevados costes de computación.

He aquí un ejemplo:

Entrada : Responde el siguiente problema matemático. Si tengo 2 manzanas y compro 4 más en la tienda después de comerme 1, ¿cuántas manzanas tengo?

Resultado : Si como 1, solo me queda 1. Tendría 5 manzanas si compro 4 más.

El modelo no solo generó más tokens de los necesarios, sino que también ocultó su respuesta. Un ingeniero podría entonces tener que diseñar un método programático para extraer la respuesta final o formular preguntas adicionales como "¿Cuál es tu respuesta final?", lo que genera aún más costos de API.

Como alternativa, se podría rediseñar la indicación para guiar al modelo y producir una respuesta inmediata. Por ejemplo:

Entrada : Responde el siguiente problema matemático. Si tengo 2 manzanas y compro 4 más en la tienda después de comerme 1, ¿cuántas manzanas tengo? Empieza tu respuesta con «La respuesta es»…

O:

Entrada : Responde el siguiente problema matemático. Si tengo 2 manzanas y compro 4 más en la tienda después de comerme 1, ¿cuántas manzanas tengo? Escribe tu respuesta final en negrita. .

“La forma en que se formula la pregunta puede reducir el esfuerzo o el costo para obtener la respuesta deseada”, afirmó Emerson. También señaló que técnicas como la incitación rápida (proporcionando algunos ejemplos de lo que el usuario busca) pueden ayudar a obtener resultados más rápidos.

Un peligro es no saber cuándo utilizar técnicas sofisticadas como la estimulación en cadena de pensamiento (CoT, por sus siglas en inglés) (generar respuestas en pasos) o el autorefinamiento, que alientan directamente a los modelos a producir muchos tokens o pasar por varias iteraciones al generar respuestas, señaló Emerson.

No todas las consultas requieren que un modelo las analice y vuelva a analizar antes de proporcionar una respuesta, enfatizó; podrían ser perfectamente capaces de responder correctamente cuando se les indica que respondan directamente. Además, las configuraciones incorrectas de la API de solicitud (como OpenAI o3, que requiere un alto esfuerzo de razonamiento) generarán mayores costos cuando una solicitud más económica y de menor esfuerzo sería suficiente.

“Con contextos más extensos, los usuarios también pueden verse tentados a usar un enfoque de 'todo menos lo esencial', donde se introduce la mayor cantidad de texto posible en el contexto de un modelo con la esperanza de que esto ayude al modelo a realizar una tarea con mayor precisión”, dijo Emerson. “Si bien un mayor contexto puede ayudar a los modelos a realizar tareas, no siempre es el mejor ni el más eficiente”.

No es ningún secreto que hoy en día puede ser difícil conseguir una infraestructura optimizada para IA; Del Prete de IDC señaló que las empresas deben poder minimizar la cantidad de tiempo de inactividad de la GPU y completar más consultas en ciclos de inactividad entre solicitudes de GPU.

"¿Cómo puedo aprovechar al máximo estos recursos tan preciados?", señaló. "Porque tengo que aumentar la utilización de mi sistema, ya que simplemente no tengo la ventaja de simplemente aumentar la capacidad para solucionar el problema".

Las operaciones de avisos pueden ser de gran ayuda para abordar este desafío, ya que, en última instancia, gestionan el ciclo de vida del aviso. Si bien la ingeniería de avisos se centra en la calidad del aviso, las operaciones de avisos son donde se repite, explicó Del Prete.

"Es más una orquestación", dijo. "Lo considero la selección de preguntas y la forma de interactuar con la IA para asegurarnos de sacarle el máximo provecho".

Los modelos tienden a fatigarse, dando vueltas en círculos donde la calidad de los resultados se degrada, dijo. Las operaciones de avisos ayudan a gestionar, medir, monitorear y ajustar los avisos. "Creo que, dentro de tres o cuatro años, será toda una disciplina. Será una habilidad".

Si bien aún es un campo emergente, entre los primeros proveedores se incluyen QueryPal, Promptable, Rebuff y TrueLens. A medida que las operaciones de avisos evolucionen, estas plataformas continuarán iterando, mejorando y brindando retroalimentación en tiempo real para brindar a los usuarios mayor capacidad para ajustar los avisos con el tiempo, señaló Dep Prete.

Con el tiempo, predijo, los agentes podrán ajustar, escribir y estructurar sus propios mensajes. «El nivel de automatización aumentará, el nivel de interacción humana disminuirá y los agentes podrán operar de forma más autónoma en los mensajes que creen».

Hasta que las operaciones de aviso se implementen plenamente, no existe un aviso perfecto. Algunos de los errores más comunes que comete la gente, según Emerson:

• No ser lo suficientemente específico sobre el problema a resolver. Esto incluye cómo el usuario desea que el modelo proporcione su respuesta, qué se debe considerar al responder, las restricciones a considerar y otros factores. «En muchos entornos, los modelos necesitan un buen contexto para ofrecer una respuesta que cumpla con las expectativas de los usuarios», afirmó Emerson.
• No se tienen en cuenta las maneras en que se puede simplificar un problema para limitar el alcance de la respuesta. ¿Debería la respuesta estar dentro de un rango determinado (de 0 a 100)? ¿Debería formularse la respuesta como un problema de opción múltiple en lugar de algo abierto? ¿Puede el usuario proporcionar buenos ejemplos para contextualizar la consulta? ¿Puede el problema dividirse en pasos para consultas separadas y más sencillas?
• No aprovechar la estructura. Los LLM son muy buenos en el reconocimiento de patrones y muchos pueden comprender código. Si bien el uso de viñetas, listas detalladas o indicadores en negrita (****) puede parecer un poco recargado, Emerson señaló que estas referencias pueden ser beneficiosas para un LLM. Solicitar resultados estructurados (como JSON o Markdown) también puede ser útil cuando los usuarios buscan procesar las respuestas automáticamente.

Emerson señaló que existen muchos otros factores a considerar para el mantenimiento de una tubería de producción, según las mejores prácticas de ingeniería. Estos incluyen:

• Asegurarse de que el rendimiento del oleoducto se mantenga constante;
• Monitorear el desempeño de los mensajes a lo largo del tiempo (potencialmente contra un conjunto de validación);
• Configuración de pruebas y detección de alertas tempranas para identificar problemas en las tuberías.

Los usuarios también pueden aprovechar las herramientas diseñadas para facilitar el proceso de generación de indicaciones. Por ejemplo, el DSPy de código abierto puede configurar y optimizar automáticamente las indicaciones para tareas posteriores basándose en algunos ejemplos etiquetados. Si bien este puede ser un ejemplo bastante sofisticado, existen muchas otras opciones (incluidas algunas integradas en herramientas como ChatGPT, Google y otras) que pueden facilitar el diseño de indicaciones.

Finalmente, Emerson afirmó: "Creo que una de las cosas más sencillas que pueden hacer los usuarios es intentar mantenerse al día con los enfoques de estimulación eficaces, los desarrollos de modelos y las nuevas formas de configurar e interactuar con los modelos".