14-01-02 — Orchestrator-Workers e Evaluator-Optimizer

⏱ 12 minFontes validadas em: 2026-04-29

TL;DR

Orchestrator-Workers: um LLM "maestro" decompõe tarefas e delega para LLMs especializados ("workers"), depois consolida. Evaluator-Optimizer: um LLM gera, outro avalia e solicita revisão em loop até atingir qualidade-alvo. Ambos são padrões multi-agente que aumentam qualidade a custo de latência e tokens.

Orchestrator-Workers

O orchestrator recebe o objetivo de alto nível, decompõe em subtarefas, e delega para workers especializados. Cada worker opera no seu domínio e retorna resultado ao orchestrator, que sintetiza a resposta final.

graph TD User[Usuário] --> Orch[Orchestrator LLM] Orch --> |subtask: pesquisa| W1[Worker: Research] Orch --> |subtask: análise financeira| W2[Worker: Finance] Orch --> |subtask: rascunho texto| W3[Worker: Writing] W1 --> |resultado| Orch W2 --> |resultado| Orch W3 --> |resultado| Orch Orch --> |síntese| User

Quando usar:

  • Tarefas que requerem expertise em múltiplos domínios simultaneamente
  • Quando workers especializados têm prompts/contextos muito diferentes entre si
  • Relatórios complexos que combinam análise, pesquisa e redação

Implementação com Semantic Kernel:

// Orchestrator define o plano
var orchestratorPrompt = """
Você é um orquestrador. Dado o objetivo abaixo, crie um plano de subtarefas.
Retorne JSON com array de tasks: [{worker: string, task: string, dependsOn: string[]}]

Objetivo: {{$goal}}
""";

// Workers especializados
var researchAgent = kernel.CreateFunctionFromPrompt(
    "Você é especialista em pesquisa. Encontre informações sobre: {{$task}}",
    functionName: "ResearchWorker"
);

var analysisAgent = kernel.CreateFunctionFromPrompt(
    "Você é analista financeiro. Analise os dados: {{$task}}\nDados: {{$researchResult}}",
    functionName: "AnalysisWorker"
);

// O orchestrator chama os workers na ordem correta
// baseado nas dependências declaradas no plano
💡 Workers não precisam ser LLMs: Workers podem ser funções determinísticas (chamar API, executar SQL, calcular), LLMs menores e baratos, ou até modelos especializados fine-tuned para a tarefa. O orchestrator é o único que precisa de raciocínio complexo.

Evaluator-Optimizer

Loop de geração e avaliação. O Generator produz uma resposta. O Evaluator (outro LLM ou função determinística) verifica qualidade contra critérios definidos. Se não atende, o Generator recebe feedback e tenta novamente.

graph LR Input[Input] --> Gen[Generator LLM] Gen --> |rascunho| Eval[Evaluator LLM] Eval --> |aprovado| Output[Output final] Eval --> |feedback: revisar X| Gen Gen --> |nova versão| Eval

Critérios de avaliação típicos:

  • Groundedness: resposta baseada apenas no contexto fornecido?
  • Completeness: todos os requisitos atendidos?
  • Format compliance: saída no formato exigido (JSON, Markdown, etc)?
  • Safety: conteúdo seguro e appropriado?
  • Length: dentro do limite especificado?
async def evaluator_optimizer(task: str, criteria: list[str], max_iterations: int = 3) -> str:
    draft = await generate(task)
    
    for i in range(max_iterations):
        evaluation = await evaluate(draft, criteria)
        
        if evaluation["passed"]:
            return draft
        
        feedback = evaluation["feedback"]
        print(f"Iteração {i+1}: {feedback}")
        
        # Regenera com feedback
        draft = await generate(
            f"{task}\n\nRascunho anterior:\n{draft}\n\nFeedback para melhorar:\n{feedback}"
        )
    
    # Retorna melhor versão após max_iterations
    return draft
⚠️ Custo do loop: Cada iteração no Evaluator-Optimizer dobra o custo mínimo. Defina max_iterations baseado no ROI: para conteúdo crítico (proposta comercial, relatório para board), 3 iterações justificam-se. Para respostas de chatbot casual, não.

Combinando: Orchestrator com Evaluator por Worker

Padrão avançado: cada worker tem seu próprio evaluator, garantindo qualidade de cada subtarefa antes de retornar ao orchestrator. O orchestrator recebe apenas resultados validados.

PatternLatênciaCustoQualidadeCaso de uso
Single LLMBaixaBaixoBásicaChat simples
Prompt ChainingMédiaMédioBoaWorkflows sequenciais
Orchestrator-WorkersMédiaAltoMuito boaTarefas multi-domínio
Evaluator-OptimizerAltaAltoExcelenteConteúdo crítico

Como isso se conecta

  • 14-01-01 — orchestrator usa routing e parallelization internamente
  • 14-02-01 — workers menores = otimização de custo real
  • 13-02-03 — cada worker deve ter seu próprio Entra Agent ID
  • 14-03-02 — assistente jurídico usa orchestrator-workers na solução

Fontes

  1. Anthropic — Building Effective Agents
  2. Semantic Kernel — Agent Orchestration
  3. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation (Arxiv)
  4. Microsoft AutoGen — Multi-agent framework