A máquina que decide quando parar de pensar

Um sistema de inferência progressiva decide qual modelo deve responder a cada pedido. Perguntas simples seguem para um modelo rápido. Tarefas que exigem várias etapas, código ou análise de documentos sobem para um modelo de raciocínio mais forte.

Vamos construir uma versão mínima desse roteador em Node.js, usando uma API de inferência e apenas o fetch nativo. No fim, teremos um programa que classifica a complexidade de uma pergunta, escolhe entre HiNova e HiMax, mede o uso e salva a resposta. A arquitetura serve como ponto de partida para agentes, suporte técnico e automações internas.

O truque não é fazer o modelo pensar menos

Inferência é o momento em que um modelo treinado recebe uma entrada e produz uma saída. Em modelos de linguagem, essa saída aparece token a token. Quanto mais longa a resposta e quanto mais etapas de raciocínio forem necessárias, maior fica o trabalho computacional.

O erro comum é escolher um modelo grande para tudo. Isso simplifica o código, mas transforma cada saudação, classificação ou reescrita curta em uma operação cara e mais lenta. O erro oposto também existe: usar um modelo pequeno em tarefas que dependem de planejamento, consistência ou código.

A solução é separar duas decisões. Primeiro, um classificador barato estima a dificuldade. Depois, o roteador envia a solicitação ao modelo adequado. Essa estimativa não precisa descobrir a resposta. Ela só precisa responder a uma pergunta mais estreita: “esta tarefa tem sinais de complexidade suficiente para justificar uma segunda marcha?”.

Como princípio de engenharia, a configuração adequada depende da carga; não há uma configuração única para todos os casos. O roteador transforma essa competição em uma regra explícita.

Comece com uma classificação pequena

Crie uma pasta vazia e salve o arquivo abaixo como progressive-inference.mjs. A primeira chamada pede um JSON com duas propriedades: route e reason. A saída estruturada reduz o trabalho de interpretar texto livre.

const apiKey = process.env.HINOW_API_KEY;

if (!apiKey) {
  throw new Error("Missing HINOW_API_KEY environment variable");
}

async function callModel(model, messages, options = {}) {
  const response = await fetch("https://api.example.com/v1/chat/completions", {
    method: "POST",
    headers: {
      Authorization: "Bearer " + apiKey,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model,
      messages,
      ...options
    })
  });

  if (!response.ok) {
    throw new Error(await response.text());
  }

  return response.json();
}

async function classifyTask(userPrompt) {
  const data = await callModel("HiNova", [
    {
      role: "system",
      content:
        "Classify the task. Return only JSON with route equal to fast or deep, and a short reason. Use deep for multi-step reasoning, difficult code, long documents, conflicting constraints, or high-stakes decisions. Use fast for rewriting, extraction, classification, translation, summaries, and simple questions."
    },
    {
      role: "user",
      content: userPrompt
    }
  ], {
    response_format: { type: "json_object" },
    temperature: 0,
    max_tokens: 120
  });

  return JSON.parse(data.choices[0].message.content);
}

async function answerTask(userPrompt, route) {
  const model = route === "deep" ? "HiMax" : "HiNova";

  return callModel(model, [
    {
      role: "system",
      content: "Answer in Brazilian Portuguese. Be direct and explain the reasoning through the result, without inventing facts."
    },
    {
      role: "user",
      content: userPrompt
    }
  ]);
}

const userPrompt = process.argv.slice(2).join(" ").trim();

if (!userPrompt) {
  throw new Error('Usage: node progressive-inference.mjs "your question"');
}

const classification = await classifyTask(userPrompt);
const route = classification.route === "deep" ? "deep" : "fast";
const answer = await answerTask(userPrompt, route);

console.log(JSON.stringify({
  route,
  reason: classification.reason,
  model: route === "deep" ? "HiMax" : "HiNova",
  answer: answer.choices[0].message.content,
  usage: {
    classifier: answer.usage
  }
}, null, 2));

A decisão técnica mais importante está em classifyTask. O classificador usa o modelo equilibrado porque sua função é reconhecer sinais, não resolver o problema. O modelo de raciocínio só entra depois, quando a rota deep foi escolhida.

O código também normaliza qualquer saída diferente de deep para fast. Isso é uma proteção simples contra uma classificação malformada. Em produção, vale validar o JSON com mais rigor e registrar as decisões para auditoria.

Rode o primeiro teste

Defina a chave e execute duas perguntas:

export HINOW_API_KEY="sua-chave"
node progressive-inference.mjs "Reescreva este título de forma mais clara: A reunião foi remarcada"
node progressive-inference.mjs "Projete uma estratégia para detectar inconsistências entre três contratos longos e explique como tratar conflitos"

A primeira foi projetada para seguir a rota fast, e a segunda, para testar a rota deep; confirme o resultado na execução.

Não trate essa classificação como verdade. Ela é uma hipótese operacional. Monte uma amostra com tarefas reais, marque manualmente quais precisam de raciocínio profundo e compare as decisões do roteador. Se o sistema mandar tarefas difíceis para fast, o problema está no classificador ou nas regras. Se quase tudo virar deep, o limiar perdeu utilidade.

O ponto de equilíbrio aparece na conta

Suponha, apenas para ilustrar, que uma chamada ao classificador leve 300 ms, que a resposta do modelo rápido leve 1 segundo e que a resposta do modelo profundo leve 2 segundos. Uma solicitação encaminhada para fast custaria cerca de 1,3 segundo. Uma solicitação encaminhada para deep custaria cerca de 2,3 segundos, porque passa pelas duas chamadas. Esses valores são premissas hipotéticas, não medições da API.

Se dez solicitações fossem simples e duas fossem complexas, o fluxo faria 12 classificações, 10 respostas rápidas e 2 respostas profundas. A latência total serial aproximada seria calculada por 12 × 0,3 + 10 × 1 + 2 × 2, ou 7,6 segundos somados entre as chamadas. Essa conta é apenas um exemplo hipotético com as premissas acima, não uma medição real.

A classificação adiciona custo. Ela só compensa quando evita usar o modelo profundo em tarefas que não precisam dele. Para medir isso, registre três grupos: decisões do roteador, qualidade da resposta e consumo retornado em data.usage. O objetivo não é minimizar chamadas. É minimizar custo sem aumentar erros relevantes.

Uma melhoria óbvia é eliminar o classificador para padrões inequívocos. Comandos como tradução, extração de campos e reformulação podem ir direto para fast. O classificador fica reservado para pedidos ambíguos. Essa abordagem reduz latência, mas cria regras que precisam de manutenção.

Quando a versão mínima deixa de bastar

O roteador inicial olha apenas para o texto da solicitação. Um agente real precisa considerar contexto, tamanho do documento, ferramentas disponíveis e risco da resposta. Uma pergunta curta pode exigir muito raciocínio. Uma pergunta longa pode ser apenas uma cópia para resumir.

Adicione sinais ao prompt do classificador, não um catálogo infinito de exceções. Peça que ele considere número de restrições, necessidade de planejamento, presença de código, conflito entre fontes e impacto de uma resposta errada. Depois compare essas decisões com uma avaliação humana.

Também separe qualidade de confiança. A confiança declarada pelo modelo não garante que a classificação esteja correta. Por isso, para fluxos importantes, use uma segunda verificação: o modelo rápido responde, um avaliador verifica critérios objetivos e só então o sistema decide se precisa escalar. Isso aumenta custo e latência, então deve ficar restrito a tarefas em que o erro é caro.

A API funciona aqui como o ponto único do fluxo: a mesma chamada HTTP permite usar HiNova para triagem e HiMax para raciocínio. O valor da arquitetura está no roteamento explícito, não em esconder a escolha atrás de uma abstração.

O próximo passo é transformar a decisão em dado

Salve, para cada pedido, o texto de entrada, a rota escolhida, o modelo usado, o tempo decorrido, o consumo e uma avaliação de qualidade. Não precisa guardar dados sensíveis. Remova ou anonimize o conteúdo antes de registrar.

Com esse histórico, você pode ajustar as regras por evidência: aumentar a rota rápida quando ela mantém a qualidade, restringir a rota profunda quando o custo cresce sem benefício e criar um terceiro caminho para tarefas de código ou documentos extensos.

A máquina não aprende magicamente quando parar de pensar. Alguém define o que significa “pensar o suficiente”, mede os erros e atualiza o roteador. O sistema fica inteligente quando essa decisão deixa de ser um palpite escondido e vira uma parte observável da arquitetura.