O Conselheiro de Seleção de Modelos de IA: Encontre o Modelo Ideal para Qualquer Tarefa e Orçamento
Why this prompt matters
Teams routinely either over-pay by defaulting to the most expensive frontier model for a task a small, fast model could handle just as well, or under-deliver by picking a cheap model that can't hit the accuracy bar and has to be scrapped after a costly rollout. A wrong model choice at 40,000 requests/month can mean paying 8-10x more than necessary, or discovering a compliance violation only after PII has already left the required region.
What we use it for
A support-team lead needs to route 40,000 monthly customer tickets into 12 categories with a suggested first-response draft, must stay under 3 seconds per ticket, keep costs under $2,000/month, and cannot send EU customer PII outside the EU — but has no AI infrastructure background to know which model tier fits those constraints without expensive trial and error.
Prompt
Act as a senior AI infrastructure consultant who has deployed dozens of production LLM-based systems across cost-sensitive, latency-sensitive, and compliance-sensitive environments. CONTEXT: - Task to automate: [TASK DESCRIPTION] - Expected monthly volume: [EXPECTED VOLUME] - Maximum acceptable latency per request: [LATENCY REQUIREMENT] - Monthly budget ceiling: [BUDGET CONSTRAINT] - Minimum acceptable quality/accuracy bar: [QUALITY BAR] - Data sensitivity level (e.g., contains PII, regulated data, public data only): [DATA SENSITIVITY LEVEL] - Region/residency requirements, if any: [REGION REQUIREMENT] TASK: Recommend which AI model tier to use for this specific workload. Do not default to recommending the most powerful available model — match the model to the actual requirements. CONSTRAINTS: - Compare at least 3 distinct model tiers (e.g., flagship/frontier, mid-tier, small/fast) — never recommend just one option without showing what was ruled out and why - If data sensitivity or region requirements would rule out standard API access to a given provider, say so explicitly and note the self-hosted or region-locked alternative - If the expected volume makes self-hosting an open-weight model more cost-effective than API calls, flag that as an option even if it adds operational complexity - Do not recommend a model tier that cannot plausibly hit the stated latency requirement - Be explicit about the confidence level of any cost estimate (pricing changes; note the estimate is a snapshot for planning purposes) OUTPUT FORMAT: 1. Requirements Summary (one paragraph restating the constraints as understood) 2. Comparison Table: rows = 3-4 candidate model tiers, columns = estimated cost per 1,000 requests, expected latency, expected quality fit, data-handling fit 3. Primary Recommendation (which tier, and the specific reasoning tying it back to the stated constraints) 4. Fallback / Escalation Plan (what to do if the primary choice underperforms in production — e.g., route to a stronger model on low-confidence outputs) 5. Estimated Monthly Cost at the stated volume, with the assumptions spelled out
Result
1. Requirements Summary
You need to classify 40,000 support tickets per month into 12 categories and draft a suggested first response, with a hard latency ceiling of 3 seconds per ticket, a monthly budget cap of $2,000, a 95%+ category accuracy bar (with a human reviewing before any response is sent), and a strict requirement that customer PII stay within EU data residency at all times.
2. Comparison Table
| Tier | Est. Cost / 1,000 requests | Latency | Quality Fit | Data-Handling Fit |
|---|---|---|---|---|
| Frontier flagship (e.g., Claude Opus-class, GPT-5-class) | $18-25 | 2-4s | Excellent, overkill for 12-way classification | Only compliant via EU-region enterprise endpoints — verify contractually |
| Mid-tier (e.g., Claude Sonnet-class, GPT-5-mini-class) | $4-7 | 1-2s | Meets 95%+ bar comfortably for structured classification + short drafting | Same EU-region requirement applies; most providers offer this |
| Small/fast (e.g., Haiku-class, GPT-5-nano-class) | $0.50-1.20 | under 1s | Classification accuracy likely 85-92% without fine-tuning — risky against a 95% bar | Same EU-region requirement applies |
| Self-hosted open-weight (e.g., a fine-tuned open model on EU cloud) | $1.50-3 (infra amortized) | 1-2s | Can reach 95%+ if fine-tuned on your historical tickets | Full control — easiest to guarantee EU-only data handling |
3. Primary Recommendation
Use a mid-tier hosted model behind an EU-region endpoint as the default path for all 40,000 tickets. At this volume, mid-tier pricing keeps you well under the $2,000 ceiling (roughly $160-280/month for classification plus drafting), comfortably clears the 3-second latency requirement, and reliably hits the 95% accuracy bar on a 12-category taxonomy — this is a well-understood task type for mid-tier models and does not need frontier-level reasoning. Confirm with your provider that the specific endpoint you're billing against is contractually bound to EU data residency; not all "regional" options are equivalent.
4. Fallback / Escalation Plan
Add a confidence threshold: any classification where the model's confidence score falls below 90%, or where the ticket text matches known edge-case patterns (multi-issue tickets, sarcasm, non-native English phrasing), automatically routes to the frontier-tier model for a second pass before reaching the human reviewer. Expect this escalation path to trigger on roughly 8-12% of tickets, adding a manageable ~$15-25/month to the total.
5. Estimated Monthly Cost
At 40,000 tickets/month on the mid-tier recommendation: approximately $180-320/month for the primary pass, plus $15-25/month for the escalation path, totaling roughly $200-350/month — well within the $2,000 ceiling, leaving headroom for volume growth or a future move to fine-tuning if ticket volume triples. This estimate is a planning-stage snapshot; confirm current per-token pricing with your provider before committing to a rollout budget.
A maioria das equipes escolhe um modelo de IA da mesma forma: optam pelo padrão mais capaz ou pelo mais barato, sem de fato mapear a escolha para a tarefa. Ambas as abordagens padrão falham de maneiras previsíveis. Optar pelo modelo principal em uma tarefa simples de classificação de tickets com 12 opções significa pagar de 8 a 10 vezes mais do que o necessário por uma precisão que a tarefa nunca exigiu. Optar pelo modelo mais barato disponível em uma tarefa com uma barra de precisão rigorosa significa entregar algo que parece bom em uma demonstração, mas que desmorona em volume de produção, muitas vezes descoberto apenas após o lançamento já ser público.
Este prompt força uma comparação estruturada em vez de uma escolha baseada em intuição. Ele é construído em torno de cinco entradas que realmente determinam a adequação do modelo — a tarefa em si, o volume esperado, o teto de latência, o orçamento, o nível de qualidade e a sensibilidade dos dados — porque essas cinco variáveis são o que separa uma boa escolha de modelo de um erro caro, e são as mesmas cinco variáveis que um consultor experiente em infraestrutura de IA perguntaria antes de recomendar algo.
Por que as restrições são importantes
O prompt exige explicitamente a comparação de pelo menos três níveis de modelo lado a lado, porque uma única recomendação sem as alternativas descartadas é inverificável — você não consegue saber se é realmente a decisão correta ou apenas a primeira que parece plausível. Ele também força uma menção explícita quando requisitos de residência de dados ou conformidade eliminam certos provedores por completo, que é a restrição com maior probabilidade de ser ignorada em uma implementação apressada e a mais cara de corrigir depois do fato.
A seção do plano de escalonamento existe porque a precisão da produção no primeiro dia nunca é a história completa — um modelo mais barato com um caminho de escalonamento baseado em confiança para um modelo mais forte em casos incertos muitas vezes supera um único modelo caro executado em todas as solicitações, e a maioria das equipes nunca modela essa compensação antes de se comprometer com um nível.
Como usar
Preencha os seis campos entre colchetes com suas restrições reais — seja específico sobre volume e latência, já que entradas vagas produzem comparações vagas. Execute-o antes de se comprometer com um nível de modelo para qualquer novo recurso de IA, e execute-o novamente sempre que o volume mudar em mais de 3 a 5 vezes, pois o nível de custo ideal em 5.000 solicitações/mês muitas vezes não é o nível de custo ideal em 50.000.