Se você tem desenvolvido aplicações de IA recentemente, qual é a parte mais frustrante? Provavelmente é este cenário: você alterou o comando pela 17ª vez, rodou alguns casos de teste e sentiu que melhorou, mas, após colocar em produção, um caso de borda (edge case) que você nem imaginou destrói tudo. É exatamente esse o problema que o artigo "Building resilient prompts using an evaluation flywheel", publicado pela OpenAI em outubro de 2025, busca resolver.
O engenheiro da OpenAI, Neel Kapse, junto com o renomado educador de ML da comunidade, Hamel Husain, propuseram o conceito central de Evaluation Flywheel (Volante de Avaliação). Utilizando uma metodologia madura vinda da pesquisa qualitativa em sociologia, eles elevaram o desenvolvimento de aplicações de IA de um modelo de "prompt-and-pray" (ajustar e rezar) para uma verdadeira "disciplina de engenharia". Este artigo traz uma interpretação simplificada desse framework da OpenAI para ajudar você a aplicá-lo em seus próprios projetos de IA.
🎯 Guia Rápido: O cookbook utiliza um "Assistente de Locação de Apartamentos" como caso de estudo, demonstrando todo o fluxo, desde a análise de falhas até o grader automático e a integração com CI. As ferramentas Evals API e Prompt Optimizer mencionadas fazem parte das capacidades avançadas da plataforma OpenAI, que podem ser acessadas via serviços proxy de API como o APIYI (apiyi.com). Desenvolvedores brasileiros podem seguir o fluxo do cookbook e implementar tudo sem dificuldades.
{Flywheel de Avaliação da OpenAI}
{Analisar → Medir → Melhorar · Leve o comando do demo para a produção}
{⚠️}
{comando frágil}
{Frágil}
{muda uma palavra e tudo desmorona}
{falha em cenários de borda}
{comando e reza}
{Avaliação}
{Volante de inércia}
{① Analisar}
{Codificação Aberta + Axial}
{indução manual de modos de falha}
{② Medir}
{Python + Avaliador de Modelo de Linguagem Grande}
{métricas quantitativas automatizadas}
{③ Melhorar}
{Otimizador + edição manual}
{Baseado em falhas para correção}
{↻ girando continuamente}
{✓}
{comando de resiliência}
{Resiliente}
{estabilidade de perturbação de entrada}
{elegância em cenários de borda}
{Pronto para produção}
{Fragilidade → rotação do volante → resiliência · Este é o poder da disciplina de engenharia}
{OpenAI Cookbook · Neel Kapse + Hamel Husain · 06-10-2025}
Caso do Assistente de Locação: Uma aplicação de IA real derrubada por cenários de borda
O caso escolhido no cookbook é muito próximo da realidade: um assistente de IA que responde a dúvidas de locatários sobre dimensões de apartamentos, agendamento de visitas, instalações, etc. À primeira vista, parece um chatbot de atendimento comum, mas, ao ser colocado em produção, os erros surgem das formas mais inesperadas.
Os exemplos de falhas listados no artigo são bastante representativos e qualquer um que já trabalhou com isso vai se identificar:
| Tipo de Falha | Comportamento | Consequência |
|---|---|---|
| Erro de Agendamento | Recomendou horários de visita inexistentes | Cliente viajou à toa, aumento de reclamações |
| Confusão de Status | Não cancelou a reserva original ao reagendar | Reserva dupla, caos no funil de vendas |
| Formatação Quebrada | Lista de instalações virou um bloco de texto | Experiência ruim, informação ilegível |
| Link Quebrado | Link da planta do imóvel com erro 404 | Perda do cliente para a concorrência |
| Desvio de Dados | Horário de funcionamento divergente do real | Usuário enganado, risco jurídico |
Se você já desenvolveu qualquer aplicação de IA, sabe que esses erros não são negligenciados de propósito ao escrever o comando, mas sim porque você nem imaginava que eles poderiam acontecer. A equipe da Fractional resumiu bem esse fenômeno: rodar apenas alguns casos de sucesso (happy paths) nunca detectará os bugs de cauda longa (long tail) do ambiente de produção. É necessário estabelecer um ciclo fechado de "coleta de falhas → indução de padrões → medição automática".
Este ciclo é exatamente o problema central que o Volante de Avaliação se propõe a resolver.
A definição central do volante de avaliação da OpenAI: disciplina de engenharia para substituir o "prompt-and-pray"
O cookbook define o volante de avaliação de forma concisa: um processo de iteração contínua que substitui o palpite por uma disciplina de engenharia estruturada. Ele é composto por três fases e, como uma roda de verdade, gira continuamente, tornando o sistema mais resiliente a cada volta.
As responsabilidades das três fases são muito claras, cada uma resolvendo um problema específico:
| Fase | Problema Central | Atividade Principal | Saída |
|---|---|---|---|
| Analyze (Análise) | "Por que falhou?" | Leitura manual de amostras, identificar padrões | Lista de falhas + proporção |
| Measure (Medição) | "Quão grave é a falha?" | Criar avaliador, rodar dataset | Métricas quantitativas + baseline |
| Improve (Melhoria) | "Como corrigir?" | Ajustar comando, rodar avaliação | Nova versão + comparação |
Muitas equipes pulam a fase de Análise e vão direto para a avaliação automática, o que é a causa mais comum de falha no volante de avaliação. Sem análise qualitativa, a medição automática é um castelo de cartas, pois você não sabe o que está medindo. Este é o insight central deste cookbook e o que o diferencia dos tutoriais comuns de avaliação.
💡 Analogia: O volante de avaliação é como o ciclo PDCA que os gerentes de produto conhecem, mas aplicado à engenharia de comandos com uma metodologia concreta. Analisar corresponde a "encontrar o problema", Medir a "quantificar o problema" e Melhorar a "corrigir o problema". As três etapas são indispensáveis. Recomendamos que, ao usar a API da OpenAI via APIYI (apiyi.com) para rodar avaliações, você consolide a fase de Análise antes de iniciar a medição.
Fase 1 do volante de avaliação da OpenAI: O método de rotulagem em duas etapas da Análise
A fase de Análise é a mais negligenciada, porém a mais crítica. O cookbook apresenta um método profissional: Open Coding (Codificação Aberta) → Axial Coding (Codificação Axial). Essa técnica vem da pesquisa qualitativa em sociologia e é um dos paradigmas mais maduros para analisar dados de texto não estruturados.
Primeiro passo: Open Coding (Codificação Aberta): O trabalho é simples: leia 50 amostras de falha, não predefina categorias e atribua um rótulo descritivo a cada falha. Por exemplo:
- "Recomendou um horário de visita inexistente"
- "Lista de instalações é um bloco de texto confuso"
- "Reagendamento não cancelou o agendamento original"
- "Respondeu com as dimensões de outro apartamento"
- "Link da planta baixa não abre"
Note que, nesta etapa, você não deve buscar uma classificação organizada. Apenas descreva honestamente o que vê. A Codificação Aberta é como tomar notas de leitura: deixe o pensamento fluir, pois classificar cedo demais fará você perder a percepção de padrões marginais.
Segundo passo: Axial Coding (Codificação Axial): Aqui começa a estruturação. Você combina os rótulos dispersos do primeiro passo em categorias de alto nível. Os exemplos do cookbook são:
- Problemas de agendamento (combina: horário errado, não cancelado, agendamento duplo) → 35% das falhas
- Erros de formato (combina: layout quebrado, link inválido) → 10% das falhas
- Precisão de dados (combina: horário de funcionamento errado, dimensões erradas) → X% das falhas
A Codificação Axial é como organizar o sumário de um livro, permitindo ver o "mapa topográfico" das falhas. O número de 35% diz imediatamente o que priorizar, pois o ROI é maior.
| Método de Rotulagem | Objetivo | Mentalidade | Saída |
|---|---|---|---|
| Open Coding | Descoberta | Livre, sem pré-conceitos | 50+ rótulos descritivos |
| Axial Coding | Estruturação | Indutiva, construir categorias | 5-8 categorias de falha |
🔧 Dica prática: Desenvolvedores podem conectar logs de produção via API proxy (como apiyi.com) diretamente à interface de rotulagem de Dataset da plataforma Evals, sem precisar criar um backend próprio. Use o tipo de feedback para Open Coding e o tipo de rótulo para Axial Coding; o fluxo será idêntico ao do cookbook.
Fase 2 do Ciclo de Avaliação da OpenAI: Seleção dos dois tipos de avaliadores (graders) para a etapa de Medição (Measure)
Na fase de Análise, você já entendeu "como é a falha". Agora, na fase de Medição, o objetivo é transformar essas falhas em código de detecção automática. O cookbook apresenta um guia de seleção para dois tipos de avaliadores, que é onde a maioria dos engenheiros costuma se confundir.
| Tipo de Grader | Cenário de Aplicação | Vantagens | Desvantagens |
|---|---|---|---|
| Python Grader | Regras determinísticas (strings, regex, validação de API) | Resultados estáveis, zero alucinação, custo zero | Não consegue avaliar dimensões subjetivas |
| LLM Grader | Julgamento subjetivo (estética da formatação, alinhamento semântico, qualidade do raciocínio) | Flexível, avalia dimensões difíceis de codificar | Requer alinhamento com especialistas (SME), custo de tokens |
Usando o exemplo de um assistente de aluguel de imóveis, ambos os tipos têm seu papel:
- "O horário recomendado está dentro do período real de disponibilidade?" → Python Grader (consulta ao banco de dados ou API)
- "A lista de instalações está bem formatada?" → LLM Grader (atribui uma nota de 0 a 10)
- "O link da planta do imóvel está acessível?" → Python Grader (requisição HEAD)
- "O tom de voz da resposta está alinhado com a marca?" → LLM Grader (pontuação baseada em rubrica)
O cookbook destaca uma prática de engenharia fundamental: o LLM Grader deve passar por um alinhamento com especialistas (SME – Subject Matter Expert); não se deve confiar cegamente na pontuação do GPT-4o. O método específico consiste em dividir os dados em treino/validação/teste e verificar dois indicadores:
- High TPR (True Positive Rate, Taxa de Verdadeiros Positivos): Detecta as falhas reais.
- High TNR (True Negative Rate, Taxa de Verdadeiros Negativos): Não penaliza incorretamente amostras que já estão corretas.
Olhar apenas para a precisão pode mascarar problemas com uma linha de base alta; é obrigatório alinhar ambos os indicadores. Este é o divisor de águas entre um "LLM-as-Judge" que apenas "parece funcionar" e um que "realmente funciona".
📊 Fluxo de Validação: O especialista (SME) rotula 100 amostras como ground truth → O LLM Grader avalia as mesmas amostras → Calcula-se o TPR/TNR → Ajusta-se o comando do avaliador até que ambos os indicadores sejam atingidos. Esse fluxo é suportado nativamente pela plataforma Evals da APIYI, já que a API de Evals é totalmente compatível com o protocolo oficial da OpenAI.
Fase 3 do Ciclo de Avaliação da OpenAI: Experimentos de via dupla para Melhoria (Improve)
Na terceira fase, você finalmente pode colocar a mão na massa e ajustar o comando. O cookbook sugere dois caminhos paralelos de melhoria, que não são excludentes, mas complementares.
Caminho 1: Otimização Automática de Comandos (Prompt Optimizer)
A plataforma da OpenAI possui uma ferramenta integrada de otimização de comandos. Você fornece um conjunto de amostras com falhas e o comando original, e ela testa automaticamente uma série de estratégias de reescrita (adicionar few-shot, chain-of-thought, ajustar a ordem das instruções, etc.), avaliando o impacto no seu conjunto de avaliadores. A vantagem deste caminho é a praticidade, sendo ideal para uma exploração inicial.
Caminho 2: Ajuste Manual baseado em Padrões de Falha
Com base nos padrões de falha identificados na fase de Análise, o engenheiro ajusta o comando manualmente. Por exemplo:
- Erro no agendamento de visitas → Adicionar uma etapa obrigatória no comando para "verificar a tabela de disponibilidade".
- Formatação quebrada → Usar tags XML para especificar claramente o formato de saída.
- Falha ao cancelar reagendamentos → Adicionar uma lógica de máquina de estados: "cancelar antes de agendar novamente".
A vantagem do caminho manual é a precisão; você sabe exatamente qual mudança atende a qual padrão de falha, o que facilita o debug.
Após percorrer ambos os caminhos, você terá N versões candidatas de comandos. É aqui que entra o passo mais crítico da fase de Melhoria: executar todas as versões no mesmo conjunto de dados usando o mesmo conjunto de avaliadores e selecionar o que apresentar os melhores indicadores. Não pule esta etapa, pois os humanos têm um viés natural de "auto-satisfação" com os comandos que criam; a única forma de corrigir isso é através dos números.
Ao finalizar todas as versões, o ciclo se completa. Você descobrirá novos padrões de falha (já que o sistema melhorou, expondo casos de borda mais profundos) e retornará à fase de Análise para a próxima rodada. Essa é a essência do "ciclo" (flywheel) — ele nunca para, girando cada vez mais rápido e tornando o sistema mais resiliente.
A diferença essencial entre comandos resilientes (Resilient Prompts) e comandos frágeis
O termo resilient prompt (comando resiliente) mencionado no título é um conceito fundamental. A definição dada pelo cookbook é: um comando capaz de fornecer respostas de alta qualidade para todas as entradas possíveis. Parece simples, mas, na prática, é um padrão de engenharia extremamente elevado.
As diferenças entre resiliência e fragilidade manifestam-se principalmente em cinco dimensões:
| Dimensão de Comparação | Comando Frágil | Comando Resiliente |
|---|---|---|
| Robustez da entrada | Quebra com qualquer alteração | Estável mesmo com paráfrases |
| Cenários de borda | Saídas estranhas ou alucinações | Degradação elegante ou intervenção humana |
| Observabilidade | Caixa-preta, difícil de diagnosticar | Avaliador (grader) completo para localização |
| Aprovação em produção | Desempenho em demo ≠ produção | Passa por um ciclo completo de avaliação |
| Evolução | Corrigir A quebra B | Protegido por regressão automática |
A intuição de muitos engenheiros é que um comando "está bom o suficiente", mas, ao ser colocado em produção, surgem problemas com 0,1% de probabilidade — o que parece pouco, mas em milhões de invocações, representa 1.000 incidentes. O valor de engenharia de um comando resiliente não é elevar de 80% para 90%, mas sim de 99% para 99,9%.
🚀 Dica de integração: Para elevar seu comando a 99,9% de resiliência, é necessário automatizar o ciclo de avaliação, o que exige o uso estável da API de Evals da OpenAI e ferramentas de otimização de comandos. Recomendamos utilizar plataformas de serviço proxy de API como a apiyi.com, que oferecem interfaces totalmente sincronizadas com a oficial e nós de IDC locais que garantem que tarefas de avaliação de longa duração não sejam interrompidas.
Integração CI/CD do ciclo de avaliação da OpenAI e monitoramento de produção
O último passo enfatizado pelo cookbook é: transformar o ciclo de avaliação em uma disciplina diária de engenharia. A implementação prática divide-se em duas partes:
Primeira parte: Integração CI/CD
Conecte o conjunto de avaliadores (graders) ao seu pipeline de CI, de modo que cada alteração no comando execute automaticamente uma avaliação. Se a degradação das métricas exceder o limite, o merge do PR é bloqueado automaticamente. Este passo transforma a "avaliação" de uma atividade de pesquisa em uma prática de desenvolvimento diária, sendo o marco de que o comando está realmente se tornando um produto de engenharia.
| Tipo de limite CI | Configuração recomendada | Descrição |
|---|---|---|
| Precisão geral | Degradação ≤ 1% | Evita regressão global |
| Grader crítico | Degradação ≤ 0,5% | Controle rigoroso de falhas prioritárias |
| Detecção de novos padrões | Aviso, não bloqueio | Incentiva a descoberta de novos problemas |
| Latência P95 | Aumento ≤ 10% | Controla custos e experiência |
Segunda parte: Monitoramento de produção
Além do CI, é necessário realizar amostragens contínuas no ambiente de produção para descobrir "falhas selvagens" que não estão no conjunto de testes do CI. Esses novos padrões devem ser adicionados ao conjunto de avaliação, impulsionando o ciclo de melhoria.
A prática consiste em amostrar logs de produção em uma proporção específica (por exemplo, 1%), executar o mesmo conjunto de avaliadores e, ao detectar anomalias, realizar uma análise manual. Os novos padrões de falha descobertos, após passarem por codificação aberta (Open Coding) e codificação axial (Axial Coding), são adicionados ao conjunto de testes, reiniciando o ciclo.
Esse loop garante que seu sistema de comandos esteja sempre se tornando mais resiliente, em vez de estagnar após a implantação. Esta é a disciplina de engenharia central que o cookbook deixa para todos os engenheiros de IA.
5 lições práticas do "volante de avaliação" da OpenAI para desenvolvedores brasileiros
Após ler o cookbook, extraí 5 lições que trazem orientações diretas para desenvolvedores que trabalham com IA:
Lição 1: Comece pela análise, não pela medição
Muitas equipes começam configurando avaliadores (graders) e buscando métricas, pulando a análise manual. Isso faz com que o avaliador não meça os verdadeiros padrões de falha; os números ficam bonitos, mas os usuários continuam reclamando. Não inicie a avaliação automática sem antes realizar 50 codificações abertas (Open Coding) manuais.
Lição 2: Não deixe o GPT fazer a codificação aberta (Open Coding)
A codificação aberta deve ser feita por humanos, pois o GPT, ao realizar a indução, pode contaminar seus rótulos com vieses dos dados de treinamento. O momento mais cedo para envolver o LLM é após a codificação axial, na implementação do avaliador. A etapa de "descoberta" na análise é exclusiva dos humanos.
Lição 3: Avaliadores em Python têm prioridade sobre avaliadores baseados em LLM
Sempre que puder usar regras determinísticas, não use um avaliador baseado em LLM. Os motivos são três: estabilidade, custo e a dispensa de alinhamento com especialistas (SME). Deixe os avaliadores baseados em LLM para dimensões verdadeiramente subjetivas que as regras não conseguem cobrir.
Lição 4: Vincule as métricas ao impacto no negócio
35% de problemas de agendamento, 10% de problemas de formatação — essas porcentagens só têm valor de decisão se forem convertidas em "taxa de churn" ou "taxa de reclamação". A métrica por si só não tem significado; o que importa são as consequências para o negócio.
Lição 5: Automatize o volante, não faça dele um projeto único
O ROI de uma única volta no volante pode não ser alto, mas o efeito dos juros compostos a longo prazo é considerável. Transforme o avaliador em uma tarefa de CI, a amostragem de produção em uma tarefa agendada e a detecção de novos padrões em alertas automáticos, deixando o volante girar 24 horas por dia.
Estrutura de código Python para reproduzir o volante de avaliação da OpenAI
Embora o cookbook demonstre principalmente o fluxo de trabalho da interface da OpenAI, a invocação programática da API de avaliações (Evals API) também é suportada. O trecho de código Python abaixo mostra como chamar a API de avaliações para criar um avaliador e executar a avaliação, ideal para desenvolvedores que preferem fluxos de trabalho baseados em código:
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url="https://vip.apiyi.com/v1", # Mude para o gateway de serviço proxy de API da APIYI
api_key="Sua chave API da APIYI"
)
# 1. Criar tarefa de avaliação (definir conjunto de avaliadores)
eval_cfg = await client.evals.create(
name="leasing_assistant_v1",
data_source_config={
"type": "stored_completions",
"metadata": {"version": "v1"}
},
testing_criteria=[
{ # Exemplo de avaliador Python
"type": "string_check",
"name": "tour_time_valid",
"input": "{{sample.output}}",
"operation": "eq",
"reference": "{{item.expected_time}}"
},
{ # Exemplo de avaliador LLM
"type": "score_model",
"name": "format_quality",
"model": "gpt-4o",
"input": "{{sample.output}}",
"instructions": "Dê uma nota de 0 a 10 para a clareza da formatação da saída"
}
]
)
# 2. Executar a avaliação
run = await client.evals.runs.create(
eval_id=eval_cfg.id,
name="baseline_run",
data_source={"type": "completions"}
)
# 3. Obter resultados da avaliação
result = await client.evals.runs.retrieve(eval_id=eval_cfg.id, run_id=run.id)
print(f"Taxa de aprovação: {result.report_url}")
Este código possui três pontos cruciais. O primeiro é a alteração da base_url, que determina se você conseguirá executar tarefas de avaliação de longa duração de forma estável. O segundo é o array testing_criteria, onde você pode configurar todos os avaliadores para rodar de uma só vez. O terceiro é que a Evals API é assíncrona; executar avaliações em grandes conjuntos de dados pode levar de alguns minutos a dezenas de minutos, portanto, certifique-se de implementar a lógica de espera e novas tentativas no seu programa.
FAQ do Flywheel de Avaliação da OpenAI
Q1: Existe diferença entre o Flywheel de Avaliação e plataformas como LangSmith ou Weights & Biases?
O posicionamento é diferente. O LangSmith foca principalmente na "ferramentalização da avaliação", enquanto o Flywheel de Avaliação foca na "metodologia de avaliação". O primeiro diz como implementar, o segundo diz como pensar. Ambos podem ser usados em conjunto: utilize a ferramenta para sustentar a metodologia.
Q2: 50 amostras de falha são suficientes? Não é muito pouco?
Na fase de Open Coding, 50 são suficientes, pois o objetivo é descobrir padrões e não realizar uma exaustão estatística. Na fase de Measure (Medição), o número de amostras depende da taxa de falha: se a taxa for de 5%, você precisará de 1000 amostras para obter um intervalo de confiança estável; se a taxa for de 30%, 200 amostras já bastam.
Q3: Otimizadores de comando automáticos podem substituir totalmente as edições manuais?
Não. Ferramentas automáticas são boas em otimizações locais com base em um grader conhecido, mas não são boas em entender restrições de negócio (como a regra implícita de que "o cliente exige que cada resposta não exceda 80 caracteres"). A combinação de edição manual com otimização automática é a melhor prática.
Q4: A invocação da API de Evals é estável no Brasil/China?
A conexão direta com a OpenAI para tarefas de longa duração (a avaliação geralmente leva de alguns minutos a horas) frequentemente sofre com redefinições de conexão. Recomendamos o uso de um serviço proxy de API como o apiyi.com para realizar as chamadas. Os nós de IDC locais possuem otimizações específicas para conexões de longa duração, reduzindo significativamente a taxa de interrupção das tarefas de avaliação.
Q5: Para qual tamanho de equipe o Flywheel de Avaliação é adequado?
É adequado desde projetos de uma única pessoa até equipes de 100 pessoas; a diferença está apenas na frequência com que o "volante" gira. Um projeto individual pode girar uma vez a cada duas semanas, enquanto grandes equipes podem realizar iterações diárias ou até horárias. O segredo é estabelecer disciplina, não o tamanho da equipe.
Q6: Quem é Hamel Husain e por que este cookbook é tão relevante?
Hamel é um educador extremamente influente na comunidade de aprendizado de máquina, promovendo há tempos as melhores práticas de engenharia para aplicações de Modelos de Linguagem Grandes. Este cookbook é a primeira vez que a OpenAI introduz sistematicamente metodologias de pesquisa qualitativa (como Open Coding) na engenharia de comando, por isso tem gerado tanto debate no setor.
Conclusão
O verdadeiro valor da metodologia do Flywheel de Avaliação da OpenAI é fornecer à comunidade de engenheiros de IA a resposta padrão para a pergunta: "Como fazer engenharia de comando de forma profissional?". Não se trata de uma ferramenta específica, mas de uma disciplina de engenharia que transforma o desenvolvimento de comandos de um "trabalho artesanal baseado em intuição" em uma "prática de engenharia rastreável".
Ao incorporar as fases de Analisar → Medir → Melhorar no seu fluxo de desenvolvimento, sua aplicação de IA deixa de ser apenas um "demo que parece funcionar" e passa a ser um produto "pronto para produção e capaz de cumprir SLA". Por trás dessa evolução, existe um ciclo completo onde as falhas são coletadas sistematicamente, os padrões são estruturados e as melhorias são validadas por medições automáticas.
Se você está criando qualquer aplicação de IA baseada em comandos, recomendamos fortemente que implemente esse Flywheel. Sugerimos utilizar plataformas de API como o apiyi.com para invocar a API de Evals e o Prompt Optimizer; com apenas uma alteração na base_url, você consegue executar todo o fluxo do cookbook sem se preocupar com problemas de estabilidade de rede.
Ao gravar o "Flywheel" na sua memória muscular, seus comandos começarão, a partir de hoje, a trilhar o caminho da resiliência.
📌 Autor: Equipe APIYI — Acompanhamos de perto as práticas de engenharia de APIs multimodais da OpenAI, Anthropic e Google. Para mais interpretações práticas de cookbooks e guias de acesso à API de Evals, consulte a central de documentação em apiyi.com.
