Especialização · Modelos IA personalizados
O trabalho tem quatro partes: medimos os modelos candidatos nos seus dados, escolhemos entre configuração, pesquisa em documentos e afinação, verificamos os direitos de utilização dos dados e, depois, colocamos o consumo sob orçamento por chave. Ainda não treinámos nenhum modelo em produção e dizemo-lo antes de você perguntar.
Já construídoPartea de măsurare și operare este construită și rulată, cu rezultate păstrate: un banc de probă propriu care a comparat opt sisteme de recunoaștere a vorbirii pe aceleași 200 de enunțuri românești, cu interval de încredere și diferențe pe perechi, plus o descompunere a latenței vocale în șase segmente care se însumează la total cu abatere sub o milisecundă. Partea de operare este un gateway propriu cu 44 de modele configurate, chei per proiect cu listă albă de modele și buget, și o consolidare zilnică a consumului pe utilizator × cheie × model. Partea pe care NU am făcut-o — reglajul fin propriu-zis — e scrisă ca atare: conducta e pregătită și costată, dar nu a rulat niciodată pe GPU. Serviciul rămâne „livrat” pentru că lucrarea pe care o vindem este alegerea informată și operarea, nu antrenarea.
A maioria dos projetos de “modelo personalizado” não precisa de um modelo treinado. Precisa do modelo certo, com a instrução certa, sobre os dados certos, com um custo por chamada que alguém acompanha. O trabalho começa com a pergunta que poucos fazem: como é que o sucesso se parece, medido como, em que conjunto de casos? Sem essa resposta, qualquer comparação de modelos é uma conversa de gostos.
Nós medimos, não aceitamos os números dos fornecedores. Quando precisámos de saber o que reconhece melhor o romeno falado, corremos oito sistemas nas mesmas 200 frases, com o mesmo normalizador, com intervalo de confiança por bootstrap e com diferenças calculadas por pares. Os resultados foram incómodos: o sistema que usávamos em produção tinha 26,26% de taxa de erro por palavra, e um modelo pequeno, de 110 milhões de parâmetros, executado em processador, tinha 6,83%. Publicámos também a parte desagradável — em precisão no romeno perdemos por grande diferença face aos fornecedores comerciais.
A segunda parte do trabalho é a escolha entre três caminhos que muitas vezes se confundem: a configuração do modelo (instrução, ferramentas, parâmetros), a pesquisa nos teus documentos e o ajuste fino. A ordem em que os tentamos não é uma preferência, é economia: os dois primeiros são reversíveis numa tarde, o terceiro exige dados, direitos, GPU e uma medição antes e depois. Recomendamos o ajuste fino apenas quando temos prova de que os dois primeiros não chegam.
A terceira parte, a que fica depois do lançamento: o custo por chamada. Os modelos passam por um gateway próprio, onde cada chave tem lista branca de modelos, orçamento e período. O consumo é consolidado diariamente por utilizador, chave e modelo, o que significa que a pergunta “porque é que a fatura aumentou este mês” tem resposta linha a linha, não por suposições.
Qué incluye
Um conjunto de casos da sua realidade, um critério numérico e um método de normalização fixados por escrito. Para voz usamos a taxa de erro por palavra com normalizador próprio; para respostas de texto, a conformidade com o esquema mais uma verificação de bom senso mais a semelhança com uma resposta de referência. Sem esta etapa, o resto do trabalho não pode ser verificado por ninguém.
As mesmas frases, a mesma máquina, um único modelo carregado de cada vez, cada um no seu próprio processo. Reportamos intervalo de confiança por bootstrap e diferenças por pares, não apenas a média — porque dois modelos podem ter médias diferentes e ainda assim estar em igualdade estatística. Tivemos exatamente esse caso: dois sistemas em 66 de 66 comparações por pares, ou seja, empate, apesar de a tabela de médias sugerir um vencedor.
Num percurso vocal medimos seis segmentos separadamente — a decisão de turno, o reconhecimento de fala, o gate, o tempo até ao primeiro texto do modelo, o primeiro bloco de síntese, a fila e o transporte. A verificação que conta: a soma dos seis dá o tempo total até ao primeiro som com desvio inferior a um milissegundo em cada turno válido. A partir daí vê-se onde está o problema: no caso medido, 68,7% do tempo era a espera pelo primeiro texto do modelo, não o reconhecimento de fala, que ocupava 2,9%.
A pesquisa em documentos está implementada e em funcionamento: pesquisa híbrida, 70% semântica e 30% correspondência de palavras, limiar de semelhança 0,70, cinco fragmentos por pergunta, com registo por consulta que guarda as pontuações e os tempos. O ajuste fino só o propomos com prova de que os dois primeiros não chegam — e com o orçamento e os direitos em cima da mesa antes, não depois.
Não é formalidade, é o que trava projetos. Um corpus de 1.746 horas de romeno que tínhamos considerado revelou-se licenciado para uso não comercial — portanto inutilizável para um modelo comercial. Um conjunto de 270.946 exemplos tinha o código sob licença permissiva, mas os dados sem qualquer licença declarada. E a política de utilização de um fornecedor de voz proíbe explicitamente treinar um modelo com a sua saída. Cada fonte é verificada na sua própria página, não no que está escrito num artigo.
Gateway próprio com 44 modelos configurados, cada um com custo por token e limite de contexto na configuração. A chave do projeto tem lista branca de modelos, orçamento e período, e pode ser rodada mantendo o histórico. O consumo é consolidado diariamente por utilizador × chave × modelo. O encaminhamento usa a estratégia „menos ocupado”, duas novas tentativas e um tempo máximo de 120 segundos.
Os modelos de tipo raciocínio produzem passos internos que a plataforma de acompanhamento de custos não vê, mas o fornecedor cobra-os. A consequência prática: o orçamento bruto definido por chave tem de ser inferior ao plafond desejado, dividido por um fator de raciocínio. Se não fizer essa correção, a chave parece dentro do orçamento e a fatura não está.
Temos funcional uma cadeia local: reconhecimento de fala com um modelo de 0,6 mil milhões de parâmetros no processador e síntese vocal com um modelo de 99 milhões de parâmetros, também localmente. Num produto de monitorização de rádio, a transcrição é feita localmente, e a variante via gateway existe em paralelo — portanto a comparação entre local e alojado foi feita, não pressuposta. O que sai da máquina é texto, não áudio.
Um banco de regressão semanal em casos fixos, que compara a conformidade com o esquema, passa um teste de bom senso e mede a semelhança com as respostas de referência. Um modelo que muda sob si — e muda — vê-se na tabela, não nas reclamações dos clientes.
Qué aspecto tiene
Os casos vêm da sua realidade, não de um conjunto de teste genérico. Fixa-se o critério numérico, o método de normalização e o limiar a partir do qual o resultado é aceitável. Entregamos: o conjunto de casos, o critério escrito e o script que o calcula.
Os modelos candidatos correm em dados idênticos, com intervalo de confiança. Entregamos: a tabela com todos os sistemas testados, incluindo os rejeitados e o motivo, além do comando exato de reprodução. Um modelo que rejeitámos para romeno teve uma taxa de erro de 99,69% porque resvalava para o italiano — o romeno não estava entre as línguas declaradas. Esse resultado está na tabela.
Configuração, pesquisa em documentos ou afinação fina — com o motivo, o custo e o que se perde ao escolher. Entregamos: a decisão fundamentada, além da medição que a sustenta. Se a recomendação for „não treinamos nada”, escrevemo-la de forma igualmente explícita.
A chave do projeto é emitida com orçamento, período e lista de modelos permitidos, com a correção para os tokens de raciocínio aplicada. Entregamos: a chave, o painel de consumo e o limiar a partir do qual alguém recebe um alerta.
Os mesmos casos, o mesmo critério, no modelo em produção. Entregamos: a comparação antes/depois e a lista das alterações com o motivo de cada uma. Um banco de regressão recorrente apanha as mudanças de comportamento do modelo do fornecedor.
Os dados
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
A situação
Tínhamos um sistema de reconhecimento de fala em funcionamento para romeno e uma pergunta em aberto: é o melhor disponível ou apenas o primeiro que integramos? Não havia qualquer medição própria, apenas números publicados por fornecedores, medidos noutras línguas e noutros conjuntos.
Qué construimos
Construímos um banco: 200 enunciados romenos de um conjunto público, a mesma semente para a seleção, 35,1 minutos de áudio, o mesmo normalizador para todos os sistemas, intervalo de confiança por bootstrap, diferenças calculadas por pares. Oito sistemas, cada um carregado sozinho, num processo próprio, na mesma máquina. Escrevemos no relatório tanto a configuração da máquina como o comando exato de reprodução.
Qué salió
O sistema em produção tinha 26,26% de taxa de erro por palavra. Um modelo de 110 milhões de parâmetros, executado em processador com um modelo de linguagem ao lado, tinha 6,83%. Um modelo muito elogiado ficou em 99,69%, porque derivava para o italiano — o romeno não estava entre as línguas declaradas dele. E dois sistemas que pareciam diferentes pela média empataram estatisticamente na comparação por pares. Publicámos toda a tabela, incluindo a linha que contrariava a nossa escolha.
Qué no dice el caso
A medição foi feita num conjunto público de leitura, não em chamadas telefónicas reais, com ruído e sobreposições. Um bom resultado neste conjunto não garante o mesmo resultado por telefone. Por isso, para um cliente, o banco é reconstruído nas suas gravações — caso contrário medimos outra coisa do que lhe interessa.
Perguntas
Não. Nenhum modelo afinado ou treinado por nós está a correr em produção e não existe nenhum checkpoint guardado nos nossos repositórios. O que temos: o pipeline de treino escrito até ao comando exato de arranque da máquina com GPU, o orçamento calculado em três cenários, os dados preparados e as licenças verificadas — e uma lista escrita com o que tem de ser decidido antes da primeira execução. Preferimos dizer isto do que vender uma competência que não exercemos.
Porque o trabalho que traz o resultado, na maioria dos casos, não é o treino. É saber que modelo faz o trabalho nos seus dados, com que latência e a que custo por chamada — e isso exige uma medição que quase ninguém faz. Um exemplo do nosso trabalho: um único valor predefinido errado numa configuração de modelo (uma penalização de repetição definida em 1,2 em vez de 1,0) custou 4,3 pontos percentuais de erro. Não foi preciso treino, mas sim medição.
Comece pela pesquisa em documentos, quase sempre. É reversível, atualiza-se alterando um ficheiro e pode mostrar a fonte da resposta. O ajuste fino altera o comportamento do modelo de formas que não pode inspecionar, exige dados rotulados, direitos de utilização e uma medição antes e depois. Recomendamos o ajuste fino quando temos prova de que a primeira variante não chega — por exemplo, quando demonstrámos que um modelo offline não se torna um modelo em fluxo apenas pela configuração: ao estreitar a janela de atenção sem retreino, o erro aumentou de 8,81% para 22,26% e depois para 48,95%.
Não, e nenhum fornecedor honesto o pode fazer, porque a exatidão depende dos seus dados. O que garantimos é o método: medimos nos seus casos, mostramos o intervalo de confiança e dizemos quando a diferença entre duas opções não é estatisticamente significativa. Tivemos um caso em que um resultado publicado pelos autores de um modelo não se reproduziu connosco — eles reportavam 20,70%, nós medimos 26,68% no mesmo modelo. Escrevemos que não sabemos porquê, em vez de escolher a cifra conveniente.
Depende do caminho escolhido e é uma decisão, não um acidente. Através do gateway, o pedido chega ao fornecedor do modelo. Se isso não for aceitável, temos funcional a cadeia local: reconhecimento de voz e síntese vocal executados na sua máquina, de onde saem apenas texto, nunca áudio. Num produto de monitorização de rádio, a transcrição local e a transcrição via gateway estão ambas implementadas, por isso o compromisso entre elas podemos mostrá-lo com números.
Acontece. Por isso o trabalho inclui um banco de regressão em casos fixos, executado periodicamente, que compara a conformidade com o esquema, passa um teste de bom senso e mede a semelhança com as respostas de referência. E por isso a integração passa pelo gateway: o modelo muda num campo, não por reescrita do código.
A chave do projeto tem lista branca de modelos, orçamento e período, e pode ser rodada mantendo o histórico. O consumo é consolidado diariamente por utilizador, chave e modelo. Uma armadilha que corrigimos desde o início: os modelos de raciocínio produzem passos internos que o sistema de monitorização não vê, mas que o fornecedor cobra — portanto, o orçamento bruto da chave é definido abaixo do teto desejado, dividido por um fator de raciocínio. Quem não faz a correção vê a chave no orçamento e a fatura acima.
Porque "público" e "utilizável comercialmente" são coisas diferentes, e a diferença é descoberta tarde e de forma cara. Três exemplos das nossas verificações: um grande corpus de romeno, licenciado não comercialmente, portanto excluído para um produto comercial; um conjunto de centenas de milhares de exemplos com código sob licença permissiva, mas dados sem qualquer licença declarada; e a política de utilização de um fornecedor de voz, que proíbe explicitamente o treino de um modelo na sua saída. A verificação é feita na página da fonte, não no que repete um artigo.
Não treina hoje modelos fundamentais e não promete um modelo próprio em produção. Não garante percentagens de melhoria. Não compara um modelo com a concorrência com base nas cifras publicadas pela concorrência — se não executámos nós a comparação, dizemos que é uma cifra declarada por eles, não uma medida por nós.
26 delas são código e ficheiros dos nossos repositórios. Não publicamos o nome nem a linha: juntos, numa única página, descreveriam com demasiada precisão como estão construídos sistemas que não são só nossos. Percorremo-los consigo, no repositório, a pedido — a verificação continua possível, só que se faz numa conversa.
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.