Toda avaliação de inteligência artificial dentro de casa esbarra na mesma objeção: se eu rodo um modelo aberto na minha infraestrutura, fico com um modelo pior que o de quem chama a API do provedor grande. A objeção é parcialmente verdadeira. O erro não está no fato, está na comparação. Mede-se modelo contra modelo, quando o que decide é modelo contra tarefa.
Esta é a segunda peça da série porque, resolvida a pergunta sobre onde o dado fica, a objeção que aparece logo depois, em boa parte das avaliações da Aptabit, é sobre qualidade, e a resposta honesta começa admitindo que a diferença existe.
A diferença entre o ranking e a tarefa
Os modelos de fronteira são melhores. Foram treinados com recursos que nenhuma organização isolada reúne, e essa distância é o que as avaliações públicas dos próprios fabricantes medem. Um fornecedor que negue isso perde o interlocutor técnico na terceira linha. O que a diferença não é, necessariamente, é decisiva para o trabalho que a sua empresa vai colocar em produção.
Esses testes medem teto de dificuldade. O trabalho corporativo que a inteligência artificial resolve bem costuma ter teto baixo. Classificar um documento, extrair campos de um formulário, responder a partir de uma base fechada de conhecimento, tudo isso tem formato previsível e resposta certa conhecida por alguém da casa. Nesse tipo de tarefa, a pergunta não é qual modelo pontua mais, é se a área de negócio distingue as duas saídas no material dela.
O critério prático é esse. Se a tarefa tem universo fechado, formato estável e alguém capaz de dizer se a resposta está certa, vale medir se a diferença ainda importa. Se a tarefa é aberta e depende de conhecimento que não está no seu acervo, a diferença aparece assim que o material real entra no teste.
Onde a diferença de modelo aparece de verdade
Uma peça que parasse no parágrafo acima seria propaganda. Há pelo menos três famílias de tarefa em que a diferença de modelo pesa, e em que ajustar a instrução costuma não resolver.
Raciocínio longo e aberto. Problemas que exigem sustentar uma cadeia de decisões por muitos passos, sem resposta única e sem gabarito, são onde os modelos maiores tendem a se separar. Análise exploratória, plano em várias etapas, síntese de material contraditório. Se o seu caso é esse, o modelo local custa qualidade, e o custo é visível.
Código difícil e conhecimento raro. Escrever ou depurar código não trivial, e responder sobre assuntos que dependem de conhecimento pouco frequente, seguem sendo território dos modelos de fronteira. Aqui a decisão razoável costuma ser usar o provedor externo, com consciência de que o conteúdo daquele fluxo sai da sua rede, assunto da peça anterior desta série.
Idiomas e domínios de cauda longa. Modelos menores costumam degradar em línguas pouco representadas no treino e em vocabulário técnico muito específico. O termo sai errado e o erro passa despercebido por quem não é da área. A degradação varia de caso a caso e não se lê pelo tamanho do modelo, então esse ponto não se resolve no papel. Só o teste com o seu próprio material responde.
Existe ainda um custo que não é de qualidade. Rodar o modelo dentro de casa troca a fatura por token por capacidade de computação instalada e por gente que saiba operá-la. A conta não desaparece, muda de lugar. A pergunta a fazer é quem opera essa capacidade e a que custo, antes da decisão e não depois dela.
Como montar a avaliação que decide a escolha
Independentemente de a escolha levar à Aptabit ou a outro lugar, estas perguntas dizem se a avaliação foi feita de verdade:
- Os casos vieram do meu acervo real, incluindo os malformados, ou foram escolhidos para demonstração?
- O critério de acerto foi escrito antes de alguém ver as saídas?
- Quem avaliou as saídas sabia qual modelo produziu cada uma?
- O tempo de resposta e o custo de operação foram medidos junto com a qualidade?
- O teste vai ser repetido a cada troca de modelo ou de versão?
A segunda é a mais fácil de pular, e sem ela a avaliação tende a confirmar aquilo que já se queria confirmar.
Por que esta peça vem logo depois da primeira
O site diz que a plataforma roda modelos locais ou em nuvem, sem dependência de fornecedor nem de modelo. Isso não é uma lista de compatibilidade. É a consequência de tratar o modelo como peça trocável, definida junto com o agente e explicitada fluxo a fluxo quando o destino é um provedor externo. Quem trata o modelo como centro amarra o produto ao patamar de um fornecedor e ao que ele decidir sobre preço, disponibilidade e termos de uso. Quem o trata como peça precisa que ele seja bom o suficiente para a tarefa e possa ser trocado quando deixar de ser.
Ir até o dado, em vez de pedir que o dado venha até nós, obriga a admitir que nem todo modelo cabe onde o dado está. Uma peça mais adiante nesta série trata de onde a inteligência roda e do que cada arranjo cobra por isso.