A ascensão das operações rápidas: Lidando com custos ocultos de IA causados por entradas ruins e excesso de contexto

Este artigo faz parte da edição especial da VentureBeat, “O custo real da IA: desempenho, eficiência e ROI em escala”. Leia mais nesta edição especial.
Os provedores de modelos continuam a implementar modelos de linguagem de grande porte (LLMs) cada vez mais sofisticados, com janelas de contexto mais longas e recursos de raciocínio aprimorados.
Isso permite que os modelos processem e “pensem” mais, mas também aumenta a computação: quanto mais um modelo absorve e emite, mais energia ele gasta e maiores são os custos.
Some isso a todos os ajustes envolvidos no prompt — pode levar algumas tentativas para chegar ao resultado pretendido e, às vezes, a questão em questão simplesmente não precisa de um modelo que pense como um doutorado — e os gastos com computação podem sair do controle.
Isso está dando origem às operações rápidas, uma disciplina totalmente nova na era emergente da IA .
“Engenharia de prompts é como escrever, a criação propriamente dita, enquanto operações de prompts são como publicar, onde você evolui o conteúdo”, disse Crawford Del Prete, presidente da IDC , à VentureBeat. “O conteúdo está vivo, o conteúdo está mudando, e você precisa garantir que está refinando isso ao longo do tempo.”
Uso e custo computacionais são dois "conceitos relacionados, mas distintos" no contexto de LLMs, explicou David Emerson, cientista aplicado do Vector Institute . Geralmente, o preço que os usuários pagam varia com base tanto no número de tokens de entrada (o que o usuário solicita) quanto no número de tokens de saída (o que o modelo entrega). No entanto, eles não são alterados para ações de bastidores, como metaprompts, instruções de direção ou geração aumentada de recuperação (RAG).
Embora contextos mais longos permitam que os modelos processem muito mais texto de uma só vez, isso se traduz diretamente em significativamente mais FLOPS (uma medida de poder computacional), explicou ele. Alguns aspectos dos modelos de transformadores chegam a escalar quadraticamente com o comprimento da entrada, se não forem bem gerenciados. Respostas desnecessariamente longas também podem reduzir o tempo de processamento e exigir computação e custos adicionais para construir e manter algoritmos para pós-processar as respostas e transformá-las na resposta que os usuários esperavam.
Normalmente, ambientes de contexto mais longos incentivam os provedores a fornecer respostas prolixas deliberadamente, disse Emerson. Por exemplo, muitos modelos de raciocínio mais complexos ( o3 ou o1 da OpenAI , por exemplo) frequentemente fornecem respostas longas até mesmo para perguntas simples, gerando altos custos computacionais.
Aqui está um exemplo:
Entrada : Responda ao seguinte problema matemático. Se eu tiver 2 maçãs e comprar mais 4 no mercado depois de comer 1, quantas maçãs eu terei?
Resultado : Se eu comer 1, só me resta 1. Teria 5 maçãs se comprasse mais 4.
O modelo não só gerou mais tokens do que o necessário, como também ocultou sua resposta. Um engenheiro pode então ter que projetar uma maneira programática de extrair a resposta final ou fazer perguntas complementares como "Qual é a sua resposta final?", o que gera ainda mais custos de API.
Alternativamente, o prompt poderia ser redesenhado para orientar o modelo a produzir uma resposta imediata. Por exemplo:
Entrada : Responda ao seguinte problema matemático. Se eu tiver 2 maçãs e comprar mais 4 no mercado depois de comer 1, quantas maçãs eu tenho? Comece sua resposta com "A resposta é"...
Ou:
Entrada : Responda ao seguinte problema matemático. Se eu tiver 2 maçãs e comprar mais 4 no mercado depois de comer 1, quantas maçãs eu terei? Coloque sua resposta final em negrito. .
"A forma como a pergunta é formulada pode reduzir o esforço ou o custo para chegar à resposta desejada", disse Emerson. Ele também destacou que técnicas como o prompting de poucas tentativas (fornecendo alguns exemplos do que o usuário está procurando) podem ajudar a produzir resultados mais rápidos.
Um perigo é não saber quando usar técnicas sofisticadas, como a solicitação de cadeia de pensamento (CoT) (geração de respostas em etapas) ou autorefinamento, que incentivam diretamente os modelos a produzir muitos tokens ou passar por diversas iterações ao gerar respostas, destacou Emerson.
Nem toda consulta exige que um modelo analise e reanalise antes de fornecer uma resposta, enfatizou ele; eles podem ser perfeitamente capazes de responder corretamente quando instruídos a responder diretamente. Além disso, configurações incorretas de API de solicitação (como o OpenAI o3, que exige um alto esforço de raciocínio) incorrerão em custos mais altos quando uma solicitação de menor esforço e mais barata seria suficiente.
“Com contextos mais longos, os usuários também podem ser tentados a usar uma abordagem do tipo 'tudo menos a pia da cozinha', na qual você insere o máximo de texto possível em um contexto de modelo na esperança de que isso ajude o modelo a executar uma tarefa com mais precisão”, disse Emerson. “Embora mais contexto possa ajudar os modelos a executar tarefas, nem sempre é a melhor ou mais eficiente abordagem.”
Não é segredo que uma infraestrutura otimizada para IA pode ser difícil de encontrar hoje em dia; Del Prete, da IDC, destacou que as empresas devem ser capazes de minimizar a quantidade de tempo ocioso da GPU e preencher mais consultas em ciclos ociosos entre as solicitações da GPU.
"Como posso extrair mais dessas commodities tão preciosas?", observou ele. "Porque preciso aumentar a utilização do meu sistema, porque simplesmente não tenho o benefício de simplesmente adicionar mais capacidade ao problema."
As operações de prompt podem contribuir muito para resolver esse desafio, pois, em última análise, gerenciam o ciclo de vida do prompt. Enquanto a engenharia de prompt se preocupa com a qualidade do prompt, as operações de prompt são onde você repete, explicou Del Prete.
"É mais uma orquestração", disse ele. "Eu penso nisso como a curadoria de perguntas e a curadoria de como você interage com a IA para garantir que você esteja aproveitando ao máximo."
Os modelos podem tender a ficar "fatigados", entrando em ciclos onde a qualidade dos resultados se degrada, disse ele. As operações de prompt ajudam a gerenciar, mensurar, monitorar e ajustar os prompts. "Acho que, daqui a três ou quatro anos, isso será uma disciplina completa. Será uma habilidade."
Embora ainda seja um campo emergente, os primeiros provedores incluem QueryPal, Promptable, Rebuff e TrueLens. À medida que as operações de prompt evoluem, essas plataformas continuarão a iterar, aprimorar e fornecer feedback em tempo real para dar aos usuários mais capacidade de ajustar os prompts ao longo do tempo, observou Dep Prete.
Com o tempo, ele previu que os agentes serão capazes de ajustar, escrever e estruturar prompts por conta própria. "O nível de automação aumentará, o nível de interação humana diminuirá e os agentes poderão operar com mais autonomia nos prompts que estão criando."
Até que as operações de prompt sejam totalmente implementadas, não existe um prompt perfeito. Alguns dos maiores erros que as pessoas cometem, de acordo com Emerson:
- Não ser específico o suficiente sobre o problema a ser resolvido. Isso inclui como o usuário deseja que o modelo forneça sua resposta, o que deve ser considerado ao responder, as restrições a serem consideradas e outros fatores. "Em muitos cenários, os modelos precisam de bastante contexto para fornecer uma resposta que atenda às expectativas do usuário", disse Emerson.
- Sem levar em conta as maneiras como um problema pode ser simplificado para restringir o escopo da resposta. A resposta deve estar dentro de um determinado intervalo (0 a 100)? A resposta deve ser formulada como um problema de múltipla escolha em vez de algo aberto? O usuário pode fornecer bons exemplos para contextualizar a consulta? O problema pode ser dividido em etapas para consultas separadas e mais simples?
- Não aproveitar a estrutura. LLMs são muito bons em reconhecimento de padrões e muitos conseguem entender código. Embora usar marcadores, listas de itens ou indicadores em negrito (****) possa parecer "um pouco confuso" aos olhos humanos, observou Emerson, essas chamadas podem ser benéficas para um LLM. Solicitar saídas estruturadas (como JSON ou Markdown) também pode ajudar quando os usuários desejam processar respostas automaticamente.
Há muitos outros fatores a serem considerados na manutenção de um pipeline de produção, com base nas melhores práticas de engenharia, observou Emerson. Entre eles estão:
- Garantir que a vazão do pipeline permaneça consistente;
- Monitorar o desempenho dos prompts ao longo do tempo (potencialmente em relação a um conjunto de validação);
- Configurar testes e detecção de alertas antecipados para identificar problemas na tubulação.
Os usuários também podem aproveitar ferramentas projetadas para auxiliar no processo de prompting. Por exemplo, o DSPy de código aberto pode configurar e otimizar automaticamente prompts para tarefas posteriores com base em alguns exemplos rotulados. Embora este possa ser um exemplo bastante sofisticado, existem muitas outras opções (incluindo algumas integradas a ferramentas como ChatGPT, Google e outras) que podem auxiliar no design de prompts.
E, por fim, Emerson disse: “Acho que uma das coisas mais simples que os usuários podem fazer é tentar se manter atualizados sobre abordagens de prompts eficazes, desenvolvimentos de modelos e novas maneiras de configurar e interagir com modelos”.
venturebeat