PT EN
Voltar ao site

Modelos de IA da plataforma: onde escolher e como conferir

Cada tipo de modelo de IA da plataforma — o modelo do chat, o do DATTA Captain, o de extração de entidades (NER), o de embedding e o de rerank — tem uma escolha, que vale para a plataforma inteira: todos os contextos, todos os serviços e todas as réplicas. Ela é feita em SistemaIA (e, para o Captain, em SistemaDATTA Captain). Nenhum serviço tem modelo próprio no código, nenhum contexto guarda cópia, e o que uma requisição manda no campo model não troca a escolha.

Permissão necessária: CONFIG_EDIT para trocar; CONFIG_VIEW para ver.

Onde trocar cada modelo

ModeloOnde trocarQuem usaQuando a troca vale
Chat (LLM) e RaciocínioSistemaIA → Modelo de Chat (LLM) e Modelo de Raciocínio (Thinking)chat, título da conversa, triagem, regras, SIQL, ferramentas MCP, geração de conhecimento, copilotos do DATTA BI, classificação do tipo de processoaté 60 s
DATTA CaptainSistemaDATTA Captain → card Modeloo Captain (planejamento e visão)até 60 s
Extração de entidades (NER)SistemaIA → Modelo de Extração de Entidades (NER)NER do upload, do Datta Extract e da legislação; análise de URL e classificação do catálogo no uploadaté 60 s, daqui para a frente — o acervo já extraído não muda
EmbeddingSistemaIA → Modelo de Embeddingtodo texto vetorizado e toda busca semânticaquando a troca com backfill termina (horas num acervo grande)
RerankSistemaIA → Modelo de Rerank (Cross-Encoder)segundo estágio da busca do chat e da triagemcerca de 2 minutos (o motor reinicia; nesse meio tempo a busca usa a fusão RRF)

Captain. A primeira opção do card, "Usar o modelo do chat", faz o Captain seguir o Modelo de Chat. Abaixo da lista, o card diz o modelo em uso e de onde ele vem (escolha do Captain ou modelo do chat). Modelos que não servem ao Captain aparecem desabilitados, com o motivo.

Embedding. Escolher outro modelo abre uma troca: o campo do modelo novo é criado nos índices, o acervo é vetorizado de novo e só então o modelo novo passa a valer. Até lá a busca continua inteira no modelo anterior. O passo a passo e os cuidados estão em Embeddings — um campo por modelo.

O que a gravação recusa

A aba não grava uma escolha que a instalação não consegue atender. A recusa vem em português, e nada é gravado, quando:

  • o provedor não é liberado nesta instalação (por exemplo, Gemini numa instalação que não permite o texto sair do cluster);
  • a janela de contexto do modelo é conhecida e menor que o mínimo da plataforma (131.072 tokens);
  • o servidor vLLM da instalação não serve o modelo escolhido;
  • no rerank, o motor não confirma a troca (reranker remoto sem endereço configurado, ou reranker desligado).

Sem modelo escolhido

Não existe modelo "de reserva". Se o Modelo de Chat estiver vazio, o chat e as demais funcionalidades respondem que o modelo não está configurado em Sistema → IA, em vez de responder com um modelo que ninguém escolheu. O NER vazio faz o mesmo nas extrações.

Numa instalação nova, a plataforma preenche a aba uma única vez com os modelos que o instalador colocou no servidor (no pacote offline, o modelo de chat servido em CPU e os motores de embedding e rerank do pacote). Depois disso, a escolha é do administrador: rodar o instalador de novo ou atualizar a plataforma não a troca.

Instalação no macOS

No macOS, embedding e rerank são servidos pelo próprio computador, com um arquivo de modelo fixo. A aba mostra "Servido pelo host: <modelo>" e fica somente leitura para esses dois: trocar exige reinstalar com outro modelo (e reindexar, no caso do embedding).

Velocidade e orçamento do pedido (modo enxuto)

Um modelo servido em CPU lê o pedido devagar — dezenas de tokens por segundo — e o pedido completo do chat (prompt do contexto, ~40 ferramentas, trechos da busca e histórico) não cabe no prazo de uma chamada. Por isso o chat calcula, a cada pergunta, quanto cabe no motor em uso e, quando o pedido passa disso, entra no modo enxuto: só as ferramentas que a pergunta pede, a busca feita pelo próprio modelo quando precisa (em vez de trechos já colados na pergunta) e, se ainda não couber, cortes avisados no fim da resposta (trechos menos relevantes, ferramentas além das essenciais, mensagens mais antigas da conversa). A pergunta e o prompt do contexto nunca são cortados. Nada disso se configura: é a conta que decide, pela velocidade medida do motor. Gemini e Runpod não publicam velocidade e nunca encolhem o pedido.

Em SistemaIA, logo abaixo do Modelo de Chat, a seção Velocidade e orçamento do pedido mostra (só leitura, com CONFIG_VIEW):

  • Pedido do chat — o selo do modo (Modo enxuto, Pedido completo, Decidido por pedido, Sem modelo), o motivo com os números da última pergunta e a conta do orçamento por extenso: quantos tokens de entrada cabem, com a velocidade de leitura e de escrita, o prazo de uma chamada, as rodadas previstas, a saída por rodada, o acerto de prefixo e os caracteres por token.
  • Velocidade por motor — para cada provedor, o prazo de uma chamada, a velocidade de leitura (prefill) e de escrita (decode), o acerto de prefixo e de onde a velocidade veio: medida no motor, última medida guardada (o motor reiniciou e ainda não terminou pedido) ou semente do chart (ainda sem medida). E os caracteres por token de cada modelo, calibrados pelo uso real, ou o padrão do provedor enquanto não há amostra suficiente.
  • Último corte por parte — nos últimos 7 dias, quantos trechos, ferramentas, mensagens do histórico ou resultados de ferramenta foram cortados, quando e em que modelo.
  • Prompt de cada contexto — o tamanho do prompt de cada contexto no motor em uso, quanto tempo ele leva para ser lido a frio e se ele sozinho cabe no orçamento. Um prompt que não cabe não impede a pergunta (ela segue com aviso de que pode passar do prazo), mas é o que mais pesa num motor em CPU: enxugá-lo é decisão de quem cuida do contexto. A tabela mostra cinco contextos por vez; os demais aparecem rolando-a na vertical, com o cabeçalho parado.

Como ler. Semente do chart logo depois de trocar de modelo ou de reiniciar o motor é esperado: depois da primeira pergunta concluída a origem vira medida no motor. Muitos cortes de ferramentas ou de histórico num contexto indicam um prompt de contexto grande demais para o motor — conferir o bloco de prompts. Com o modelo em Gemini ou Runpod a seção mostra Pedido completo e nenhuma velocidade, e não há corte. Os números de cada pergunta ficam no log do chat (linhas Modo enxuto e Pedido acima do orcamento do motor) para a equipe de operação.

Como conferir o que está valendo

  • SistemaIA mostra, para cada tipo, o modelo gravado. Um rerank que veio de uma versão anterior aparece com a observação "migrado de …".
  • O card do Captain mostra o modelo em uso e a origem.
  • No Histórico de requisições de IA, cada chamada registra o provedor e o modelo que de fato responderam.
  • A seção Velocidade e orçamento do pedido mostra se o chat está no modo enxuto e por quê.

A conferência completa depois de uma atualização da plataforma, funcionalidade por funcionalidade, é feita pela equipe de operação.

Referências

  • Modelo de Raciocínio do Chat (Thinking)
  • Embeddings — um campo por modelo
  • DATTA Captain (guia do usuário)
  • Escala dos motores de IA — quantas réplicas cada motor mantém
  • Fluxos longos de LLM (arquitetura) — a conta do orçamento, o prefixo estável e os cortes