Um chatbot que responde a perguntas sobre horários e serviços não exige necessariamente o mesmo modelo de inteligência artificial que outro capaz de interpretar contratos, cruzar documentos ou consultar sistemas externos. O primeiro pode funcionar bem com um modelo económico; o segundo poderá precisar de capacidades superiores.
A escolha não deve começar pelo nome do modelo nem pelo preço por milhão de tokens. O objetivo é encontrar a opção que responde com a qualidade necessária, num tempo aceitável e com um custo sustentável. Para isso, é preciso perceber primeiro o que o chatbot terá de fazer e onde podem ocorrer erros.
A tarefa vem antes do modelo
Uma tarefa de classificação é diferente de uma conversa aberta. Se um cliente escrever «Recebi a encomenda, mas veio um artigo errado», identificar o pedido como «apoio ao cliente — encomenda incorreta» pode ser relativamente simples. Já responder a uma pergunta que cruza duas políticas comerciais, contempla exceções e depende de informações em falta exige mais interpretação.
Antes de comparar modelos, importa definir quatro aspetos:
- Função:
- responder a perguntas frequentes, classificar pedidos, consultar documentos, recolher dados ou executar operações.
- Informação:
- fontes utilizadas, atualização dos conteúdos, idiomas e necessidade de considerar mensagens anteriores.
- Risco:
- consequências de uma resposta incorreta e situações em que o chatbot deve pedir esclarecimentos ou encaminhar o pedido.
- Experiência:
- qualidade mínima exigida, rapidez de resposta e custo que o projeto pode suportar.
Estas condições determinam os testes. Um modelo mais capaz pode justificar-se perante instruções complexas ou erros com impacto elevado, mas não há vantagem em pagar por capacidades que o chatbot não utiliza.
O que torna algumas conversas mais exigentes
Qualidade das fontes e interpretação da resposta
Muitos chatbots consultam uma base de conhecimento antes de responder. Numa arquitetura de geração aumentada por recuperação (RAG), o sistema pesquisa conteúdos relevantes e envia-os ao modelo para produzir a resposta. Quando encontra uma fonte clara e suficiente, a tarefa pode ser simples, mesmo para um modelo económico.
Imagine uma política comercial que estabelece portes gratuitos acima de 75 € e um documento antigo que indicava 50 €. Se o sistema recuperar apenas a versão desatualizada, substituir o modelo por outro mais avançado não corrige a origem do erro. É necessário rever os documentos, a indexação, a divisão do conteúdo em segmentos e os critérios de pesquisa e seleção de resultados.
Também acontece o contrário: a pesquisa encontra a regra atual e a respetiva exceção, mas o modelo ignora a exceção ou responde com confiança quando deveria pedir esclarecimentos. Nesse caso, deve analisar-se a geração da resposta, as instruções e a capacidade do modelo. A recuperação da informação e a qualidade da resposta devem ser avaliadas separadamente.
Contexto, instruções e idiomas
Um chatbot pode ter de conciliar a pergunta atual, o histórico da conversa, vários documentos, instruções de comportamento e resultados de sistemas externos. Quanto mais condições e informação concorrente existirem, maior pode ser a dificuldade de identificar o detalhe decisivo.
Uma janela de contexto maior não garante, por si só, uma resposta melhor. Por vezes, é mais eficaz recuperar menos documentos, eliminar informação repetida ou resumir o histórico. Também convém simplificar instruções contraditórias antes de tentar compensá-las com um modelo superior.
A qualidade deve ainda ser testada nos idiomas reais do website, incluindo português de Portugal. Uma pergunta em inglês baseada numa fonte em português, nomes de produtos sem tradução ou terminologia técnica podem produzir resultados diferentes dos obtidos em testes genéricos.
Ferramentas e operações externas
Há uma diferença relevante entre responder «Como acompanho a minha encomenda?» e consultar efetivamente o estado dessa encomenda. No segundo caso, o modelo pode ter de selecionar uma ferramenta, fornecer os parâmetros corretos e interpretar o resultado. O mesmo acontece ao consultar existências, criar um contacto ou pesquisar informação num CRM.
Estas capacidades exigem testes específicos. O modelo pode propor uma chamada, mas a aplicação deve validar as permissões, os dados e as operações autorizadas. Um modelo mais avançado não substitui controlos de acesso nem torna segura, por si só, uma integração com dados privados. Ações com consequências relevantes podem exigir confirmação ou intervenção humana.
Qualidade, velocidade e custo total
O preço por milhão de tokens é apenas um ponto de partida. O custo efetivo de uma conversa depende dos tokens enviados e gerados, das instruções e documentos incluídos, das chamadas necessárias, de eventuais repetições, das ferramentas utilizadas e dos mecanismos de cache disponíveis. Nos modelos que os utilizam, também pode existir consumo de tokens de raciocínio.
Um modelo económico que precise de várias tentativas ou de correções frequentes pode perder parte da vantagem de preço. Por outro lado, um modelo avançado pode responder de forma praticamente idêntica a uma pergunta simples, sem produzir benefício que compense o custo adicional. A comparação relevante é o custo por pedido resolvido com a qualidade exigida, incluindo o trabalho de supervisão quando necessário.
A velocidade também conta. Convém medir o tempo até começar a apresentar uma resposta e o tempo até a concluir, distinguindo o processamento do modelo da pesquisa na base de conhecimento e das chamadas a sistemas externos. Respostas desnecessariamente longas podem aumentar tanto o custo como a demora. Contudo, um modelo mais económico não é obrigatoriamente o mais rápido em todas as configurações: é preciso medir.
Quando faz sentido testar cada tipo de modelo
A tabela indica um ponto de partida, não uma regra universal. Dois modelos da mesma gama de preço podem comportar-se de forma diferente, e a escolha depende dos testes com os conteúdos do projeto.
| Situação | Ponto de partida | O que confirmar |
|---|---|---|
| Classificar mensagens ou extrair campos | Modelo económico | Precisão nos casos ambíguos |
| Responder a perguntas com fonte clara | Modelo económico | Fidelidade à fonte e ausência de informação inventada |
| Interpretar regras com exceções ou cruzar documentos | Comparar com modelo avançado | Interpretação correta e necessidade de esclarecimentos |
| Manter conversas longas ou multilingues | Comparar ambos | Coerência do histórico e qualidade em cada idioma |
| Consultar ferramentas ou executar operações | Modelo compatível, sujeito a testes | Seleção, parâmetros, erros e autorizações |
| Tratar pedidos com consequências relevantes | Priorizar robustez e supervisão | Falhas críticas, limites e encaminhamento humano |
O custo deve entrar na decisão depois de se estabelecer o nível mínimo de fiabilidade. Para tarefas simples, pode ser eficiente começar a avaliação por um modelo económico. Quando os erros têm consequências sérias ou as tarefas são muito complexas, um modelo mais capaz pode servir de referência inicial para a qualidade esperada.
Como comparar modelos com testes reais
As classificações públicas e os testes comparativos gerais ajudam a selecionar candidatos, mas não substituem a avaliação com as perguntas, documentos, idiomas e regras do seu chatbot. O objetivo não é escolher a resposta mais convincente à primeira leitura: é identificar a opção que se comporta melhor de forma consistente.
Um processo de avaliação pode seguir esta sequência:
- Definir os critérios de aceitação. Estabelecer o que constitui uma resposta correta, quando deve haver pedido de esclarecimento e que falhas são inaceitáveis. Fixar também limites de tempo e custo.
- Preparar casos representativos. Incluir perguntas correntes, situações ambíguas, pedidos sem resposta nas fontes, questões fora do âmbito e operações com ferramentas. Um exemplo inicial seria testar 30 perguntas correntes, 10 ambíguas, 10 sem resposta nas fontes, 10 fora do âmbito e 10 com ferramentas, quando existirem. A amostra deve ser adaptada ao projeto.
- Testar os modelos em condições comparáveis. Usar as mesmas fontes e regras de acesso, ajustando as instruções quando isso for necessário para cada modelo. Repetir casos críticos para detetar respostas inconsistentes.
- Registar resultados e causas das falhas. Verificar correção, suporte nas fontes, respeito pelas instruções, pedidos de esclarecimento, utilização de ferramentas, tempo de resposta e custo total. Separar erros de pesquisa, geração e integração.
- Controlar alterações posteriores. Guardar os casos de teste e repeti-los após mudar o modelo, as instruções ou a base de conhecimento. Quando o fornecedor disponibilizar versões fixas do modelo, estas podem reduzir alterações inesperadas de comportamento, mas não eliminam a necessidade de testar atualizações.
Uma taxa média de acerto pode esconder problemas graves: falhar uma pergunta sobre horários não tem o mesmo impacto que expor dados de uma encomenda a quem não está autorizado. A avaliação deve atribuir importância diferente aos erros conforme a sua gravidade.
Reduzir custos sem escolher um modelo inadequado
Nem todas as mensagens precisam de passar pelo mesmo modelo. Num sistema com encaminhamento por tarefa, um modelo económico pode classificar pedidos ou responder a perguntas diretas, enquanto casos complexos seguem para outro mais capaz. Esta divisão só compensa se a melhoria de custo ou qualidade justificar a configuração, os testes e as chamadas adicionais. O encaminhamento pode usar regras explícitas; não deve depender apenas de uma estimativa de confiança não validada produzida pelo próprio modelo.
Convém distinguir este encaminhamento de uma alternativa de contingência: o segundo mecanismo entra em ação quando o serviço principal falha ou fica indisponível. Nesses casos, o sistema deve preservar as restrições de segurança e pode optar por uma resposta limitada ou pelo contacto humano, em vez de apresentar uma resposta pouco fiável.
Outras otimizações podem ter impacto: reduzir conteúdo irrelevante enviado ao modelo, limitar respostas demasiado extensas, evitar chamadas desnecessárias e reutilizar partes repetidas das instruções através de mecanismos de cache, quando suportados. A eficácia da cache depende do fornecedor, do modelo e da repetição real dos conteúdos. Nenhuma destas medidas compensa fontes incorretas ou falhas de segurança.
Conclusão
O melhor modelo para um chatbot não é necessariamente o mais recente, o mais caro ou o mais bem classificado num teste geral. É aquele que cumpre os requisitos do projeto com consistência, velocidade adequada e custo justificável.
A decisão deve resultar de testes reais: usar um modelo económico quando entrega a qualidade necessária e recorrer a maior capacidade quando existe uma melhoria comprovada que o justifica. A fiabilidade final depende também das fontes, das instruções, das permissões e das integrações — não apenas do modelo escolhido.
