O custo oculto dos fluxos de trabalho probabilísticos
A fatura que ninguém viu no piloto
O piloto parecia barato. Esse foi o primeiro problema. Uma equipa tinha ligado um passo de IA a um fluxo de trabalho familiar: os documentos recebidos eram classificados, gerava-se um resumo curto, selecionava-se uma rota recomendada e um revisor humano aprovava-a ou alterava-a. A demonstração era elegante. O modelo parecia competente. A fatura de tokens era mais baixa do que o orçamento do almoço, o que fez toda a gente sentir-se financeiramente madura. Alguém disse a palavra escalável, e a sala tornou-se brevemente perigosa.
Três meses depois, a conversa sobre custos mudou. A fatura de tokens continuava a não ser dramática. Os custos ocultos estavam noutro lado. Os revisores gastavam minutos extra a verificar resultados limítrofes. Reexecuções apareciam porque a mesma entrada, por vezes, produzia uma resposta suficientemente diferente. As filas de exceções cresciam. As equipas de dados investigavam porque é que um tipo de documento confundia o classificador. As operações adicionavam amostragem. A área jurídica pedia provas em casos disputados. Os gestores perguntavam porque é que o tempo de ciclo se tornara menos previsível. Os engenheiros adicionavam instruções, depois proteções, depois alternativas, depois monitorização, depois uma folha de cálculo que ninguém adorava, mas que toda a gente abria. O fluxo de trabalho não tinha explodido. Tinha adquirido variância.
Este é o custo oculto dos fluxos de trabalho probabilísticos. A chamada ao modelo é a unidade visível de consumo, mas o custo operacional é suportado pela incerteza em torno da chamada. Um componente probabilístico pode ser útil, poderoso e economicamente sensato. Também pode transferir o custo para a revisão, a reconciliação, as provas, o apoio, a conceção de filas, a análise de incidentes, a medição de qualidade e a atenção humana. Se esses custos não forem concebidos no fluxo de trabalho, chegam na mesma, normalmente com menos paciência.
Os sistemas de fluxo de trabalho tradicionais não são perfeitos. Falham, desviam-se e surpreendem as pessoas à sua própria maneira monótona. Mas têm, muitas vezes, uma propriedade útil: a mesma entrada, o mesmo estado e a mesma regra tendem a produzir o mesmo resultado. Os sistemas probabilísticos enfraquecem essa premissa. Por vezes, é esse o objetivo. Lidam com ambiguidade, linguagem, imagens, documentos desorganizados e intenções difusas. Muito bem. O preço é que as operações deixem de fingir que a incerteza é um pormenor de demonstração. É uma entrada de primeira classe no modelo de custos.
A variância não é um pormenor de implementação
Os componentes probabilísticos introduzem variância em vários pontos. O modelo pode produzir um texto ligeiramente diferente. Um classificador pode colocar um caso-limite de um ou de outro lado de um limiar. Um recuperador pode devolver um conjunto diferente de fontes após uma atualização do índice. Um resumidor pode omitir um detalhe que interessava a um revisor posterior. Um agente que utiliza ferramentas pode escolher uma sequência diferente de chamadas. Nada disto é automaticamente um erro. É simplesmente um material diferente do código determinístico. Tratá-lo como código comum porque tem uma API é um erro de categoria com consequências.
A variância tem consequências operacionais. Aumenta a necessidade de amostragem e revisão. Complica a reprodução de incidentes. Torna o desempenho mais difícil de medir, porque a qualidade média pode esconder instabilidade nos extremos. Cria desacordo entre utilizadores que viram resultados diferentes. Pode tornar os sistemas a jusante frágeis quando estes esperam uma estrutura estável. Pode transformar um simples acordo de nível de serviço numa conversa sobre distribuições de probabilidade, o que é uma excelente forma de descobrir quem na sala gosta verdadeiramente de matemática.
O primeiro custo é o atrito na decisão. Quando os resultados variam, as pessoas gastam tempo a decidir se a variação é relevante. Um rascunho de e-mail que diz o mesmo com palavras diferentes pode ser aceitável. Um resumo médico que omite um medicamento não é. Um classificador de apoio que encaminha um pedido de forma diferente pode ser aceitável. Uma explicação de elegibilidade para benefícios que altera o seu raciocínio não é. O fluxo de trabalho precisa de um modelo de tolerância: que variação é inofensiva, que variação exige revisão e que variação é proibida.
O segundo custo é a reprodutibilidade. Se um cliente, cidadão, auditor ou engenheiro perguntar por que motivo uma decisão aconteceu, a organização precisa de reproduzir o contexto relevante: versão do modelo, instrução, conjunto de recuperação, entrada, política, parâmetros, resultados das ferramentas e ação humana. Sem esse registo, a investigação torna-se teatro. Alguém volta a executar a instrução, obtém uma resposta diferente, e a sala aprende da pior forma que tentar novamente não é prova.
As repetições não são gratuitas só porque são automatizadas
As repetições parecem baratas do ponto de vista do código. Se o modelo der uma resposta fraca, chame-o novamente. Se o classificador estiver incerto, peça outra amostra. Se uma resposta JSON for inválida, repare-a. Se a chamada à ferramenta falhar, tente outra via. A máquina faz o trabalho, por isso o instinto é tratar as repetições como cola de engenharia. Num fluxo de trabalho probabilístico, as repetições são política. Decidem quanta variação o sistema pode esconder antes de um humano a ver.
Há boas razões para repetir. Uma falha transitória não deve interromper um processo. Uma resposta malformada pode muitas vezes ser corrigida. Pedir uma segunda passagem pode melhorar a qualidade. Mas as repetições também criam custo e ambiguidade. Qual resultado conta como registo. Mantemos todas as tentativas. As tentativas posteriores substituem as anteriores. Mostramos ao revisor a instabilidade. As repetições enviesam o sistema para respostas que parecem mais confiantes. Repetimos apenas os casos baratos, tornando acidentalmente os casos importantes mais lentos. Contamos as repetições nos orçamentos de custo e latência. A humilde repetição tem muitas opiniões assim que a convidamos para a produção.
As repetições também alteram os incentivos. Se as equipas souberem que o sistema continuará a tentar até o resultado se ajustar à forma esperada, podem investir menos na qualidade da entrada, no design do esquema, nas restrições das instruções ou no pré-processamento determinístico. A repetição torna-se uma esfregona. As esfregonas são úteis. Uma estratégia de construção baseada em esfregonar é menos impressionante.
Um padrão melhor é classificar os motivos das repetições. A falha de infraestrutura transitória é uma categoria. A correção de formatação é outra. A baixa confiança é outra. O conflito de políticas é outra. O conflito de fontes é outra. Cada categoria precisa de limites, registos e regras de escalada. Uma repetição que esconde a incerteza do utilizador deve ser tratada de forma diferente de uma repetição que apenas recupera de uma falha de rede. O custo não é apenas computacional. É o custo de decidir qual incerteza a organização se sente confortável em esconder.
A fila de exceções é o verdadeiro diagrama de arquitetura
Todos os fluxos de trabalho probabilísticos acabam por revelar o seu verdadeiro design através da fila de exceções. Não o caminho feliz. O caminho feliz é onde os diagramas vão para parecerem empregáveis. A fila de exceções mostra quais os casos que o sistema não compreende, quais as entradas que estão sujas, quais as políticas que entram em conflito, quais os utilizadores que precisam de apoio, quais os limiares que estão errados e quais as promessas que foram feitas cedo demais.
Se a fila de exceções for bem desenhada, torna-se uma superfície de aprendizagem. Os casos são categorizados, amostrados, revistos pelas funções certas, ligados a correções de dados de origem, associados a alterações de políticas e reintroduzidos na avaliação. Se for mal desenhada, torna-se um pântano. Os casos difíceis ficam num backlog. Os revisores inventam hábitos locais. Os gestores veem apenas volume. Os engenheiros veem apenas falhas agregadas. Os utilizadores veem atrasos. O modelo permanece misterioso porque a organização escondeu as suas melhores provas em lodo operacional.
O custo das exceções não é apenas o número de casos. É a sua forma. Uma taxa de exceção de dez por cento pode ser gerível se os casos forem rápidos, de baixo risco e fáceis de encaminhar. Uma taxa de exceção de dois por cento pode ser cara se cada caso precisar de interpretação jurídica, revisão de domínio, contacto com o cliente e reconstrução de provas. A taxa média de automatização é, portanto, uma métrica suspeita. Diz-lhe quanto passou pela máquina, não quanto custo a máquina deslocou.
O design de exceções deve ser explícito. Defina bandas de confiança. Defina a abstenção. Defina quais os conflitos que pausam o fluxo de trabalho. Defina quais as funções que podem resolver quais classes. Defina a idade máxima da fila. Defina a revisão por amostragem para casos aceites, não apenas para os falhados. Defina o que é corrigido quando uma exceção se repete. Caso contrário, a organização não automatizou o trabalho. Automatizou a criação de um segundo emprego, menos visível.
A saída probabilística faz com que os sistemas a jusante negociem
Os sistemas de software preferem contratos. Um campo é uma data. Um estado tem valores permitidos. Um montante tem precisão. Uma regra tem uma ramificação. Os resultados probabilísticos chegam frequentemente sob a forma de linguagem, classificação, confiança ou suposições parcialmente estruturadas. Os sistemas a jusante negociam então. Analisam. Validam. Corrigem. Perguntam novamente. Mapeiam rótulos ambíguos para estados exatos. Criam alternativas de recurso. Cada negociação é um pequeno custo. Custos pequenos suficientes tornam-se arquitetura.
A saída estruturada ajuda, mas não elimina a incerteza. Um modelo pode produzir JSON válido e ainda assim escolher a categoria errada. Pode preencher todos os campos e ainda assim omitir uma condição. Pode citar uma fonte e ainda assim interpretá-la mal. Um esquema deteta erros de forma. Não prova o significado. Esta é uma armadilha comum porque os erros de forma são visíveis para as máquinas e os erros de significado são visíveis para as pessoas. Adivinhe qual é corrigido primeiro.
A negociação a jusante também altera a responsabilidade. Se um caso for mal encaminhado porque o resultado do modelo era vago e a camada de integração adivinhou, quem é o responsável pelo erro. A equipa do modelo. A equipa da plataforma. O responsável pelo processo. O revisor. A equipa de dados. Todos podem apresentar um argumento respeitável, que é como se percebe que o modelo operacional está em falta. Os fluxos de trabalho probabilísticos precisam de responsabilidade na fronteira onde a incerteza se torna um estado do sistema.
Um método prático é separar confiança, completude e consequência. A confiança indica a probabilidade do resultado. A completude indica se as evidências necessárias estão presentes. A consequência indica o dano que uma ação errada pode causar. Um resultado de alta confiança com evidências em falta pode ainda assim exigir revisão. Um resultado de baixa confiança com baixa consequência pode ser encaminhado rapidamente. Um resultado de confiança média com alta consequência pode exigir escalonamento. O fluxo de trabalho não deve tratar toda a incerteza como a mesma cor de amarelo.
A avaliação é um custo operacional recorrente
Muitas equipas tratam a avaliação como uma fase do projeto. Antes do lançamento, reúnem um conjunto de testes, executam prompts, comparam resultados, talvez pontuem a qualidade, e declaram prontidão. Depois chega a realidade com novos documentos, novos utilizadores, novos casos extremos, nova linguagem, novas políticas e novas versões do modelo. O conjunto de avaliação começa a envelhecer. Como queijo, exceto que é menos delicioso e mais provável de causar uma reunião.
Os fluxos de trabalho probabilísticos precisam de avaliação recorrente. Isso significa casos selecionados, casos adversos, amostras recentes de produção, suítes de regressão, revisão de domínio, verificações de imparcialidade quando relevantes, monitorização de custos e latência, e testes que são executados quando prompts, modelos, índices de recuperação, políticas ou dados de origem mudam. A avaliação não é um portão único. É o orçamento operacional para saber se o fluxo de trabalho ainda merece tráfego.
Este custo surpreende as pessoas porque o piloto o esconde. Durante um piloto, os especialistas estão próximos do sistema. Notam problemas informalmente. A mistura de entradas é limitada. Os riscos são contidos. Em produção, o sistema torna-se suficientemente rotineiro para que os especialistas deixem de observar cada resultado, que é exatamente quando a avaliação formal deve assumir o controlo. Um sistema probabilístico sem avaliação recorrente é uma máquina que gasta lentamente a confiança enquanto reporta disponibilidade.
A avaliação também deve estar ligada a decisões. Se a qualidade cair, quem pode pausar. Se a latência aumentar, quem decide se deve reduzir o tamanho do modelo, diminuir as tentativas ou adicionar capacidade de revisão. Se um novo modelo melhora a pontuação média mas piora um subgrupo crítico, quem recusa a atualização. Se o custo aumentar porque as exceções aumentam, quem é responsável pela correção. Um painel que mostra deterioração sem autoridade para agir é apenas uma previsão meteorológica cara.
A revisão humana tem uma fatura de teoria das filas
A revisão humana é muitas vezes acrescentada como uma frase tranquilizadora. Uma pessoa continuará no ciclo. Que encanto. Que pessoa, com que fila, que contexto, que autoridade, que tempo-alvo, que caminho de escalada, que modelo de fadiga e que salvaguarda quando o sistema envia demasiados casos-limite às 16:45 de uma sexta-feira. O ciclo tem logística. A logística tem custos. Os custos têm o hábito encantador de aparecerem depois do diapositivo da arquitetura.
A capacidade de revisão não é linear. Um pequeno aumento de casos incertos pode criar um grande aumento no tempo de espera quando a equipa de revisão está perto da capacidade. A teoria das filas é cruel mas justa. Se as chegadas se tornarem mais variáveis e o tempo de serviço se tornar mais variável, os atrasos podem crescer rapidamente. Os fluxos de trabalho probabilísticos aumentam frequentemente ambos: dificuldade dos casos mais irregular e tempo de revisão mais variável. A organização pode acreditar que automatizou oitenta por cento do trabalho enquanto os restantes vinte por cento controlam silenciosamente o acordo de nível de serviço.
A qualidade da revisão também depende do contexto. Se os revisores veem apenas a resposta final, têm de reconstruir por que razão apareceu. Se veem fontes, confiança, política, tentativas anteriores e incertezas conhecidas, podem agir mais depressa e melhor. Se são medidos apenas pelo débito, aprenderão a confiar demasiado na máquina ou a combatê-la de menos. A revisão humana não é um solvente mágico derramado sobre a incerteza. É trabalho qualificado que precisa de conceção.
O custo oculto é a atenção. As pessoas não conseguem rever ambiguidade indefinida indefinidamente. A fadiga altera os padrões. Aparecem hábitos locais. Alguns revisores tornam-se rigorosos, outros pragmáticos, outros resignados. O fluxo de trabalho começa a produzir resultados diferentes consoante quem apanhou o caso. Depois, o sistema probabilístico é culpado pela inconsistência que a organização amplificou na conceção da revisão. A máquina forneceu a variância. Os humanos forneceram a dinâmica das filas. Um belo dueto, se o objetivo for a dor da auditoria.
A contabilidade de custos tem de incluir a incerteza
Um modelo de custos útil para fluxos de trabalho probabilísticos inclui mais do que chamadas ao modelo. Inclui preparação de entrada, recuperação, repetições, validação, tempo de revisão, tratamento de exceções, avaliação, armazenamento de provas, análise de incidentes, monitorização, apoio ao utilizador, manutenção de instruções e políticas, correção de dados e reparação a jusante. Inclui também opcionalidade: o custo de mudar de modelo, fornecedor, instrução, índice ou fluxo de trabalho quando a configuração atual já não serve.
Isto não significa que os fluxos de trabalho probabilísticos sejam maus. Significa que são reais. Muitos valem o custo. Um sistema que reduz a leitura repetitiva ao mesmo tempo que expõe casos de risco pode ser excelente. Um classificador que lida com linguagem desorganizada melhor do que regras pode poupar tempo. Um resumidor que dá aos especialistas uma boa primeira passagem pode melhorar o serviço. A questão não é evitar a probabilidade. A questão é deixar de esconder o seu orçamento operacional nos calendários de outras pessoas.
Um método de contabilização útil é definir o preço por classe de caso. Os casos de processamento direto têm custos de modelo, validação e amostragem. Os casos assistidos acrescentam tempo de revisão. Os casos de exceção acrescentam custos de triagem, revisão especializada e evidência. Os casos disputados acrescentam custos de reprodução, comunicação e possível retificação. Os casos de melhoria acrescentam custos de manutenção de dados ou de instruções. Isto transforma a taxa de automatização numa imagem mais rica: não apenas quantos casos foram tocados pela IA, mas como a incerteza alterou o trabalho e o risco.
Outro método é acompanhar o orçamento de variação. Quanta variação de resultados é aceitável para esta tarefa. Com que frequência as novas execuções podem diferir. Quantas exceções por dia a fila consegue absorver. Quanto tempo de revisão por caso está orçamentado. Quanta evidência deve ser armazenada. Com que rapidez os resultados disputados devem ser reproduzidos. Estes números não eliminam a incerteza. Tornam-na administrável.
O determinismo ainda tem um papel
A ascensão dos sistemas probabilísticos não torna a engenharia determinística antiquada. Torna os limites determinísticos mais valiosos. Use análise sintática determinística onde a estrutura está disponível. Use regras explícitas onde a política é clara. Use recuperação estável onde as fontes devem ser reproduzíveis. Use esquemas, validadores, estados finitos, instruções com versões, conjuntos de avaliação fixos e parâmetros registados. Use a probabilidade para a parte da tarefa que genuinamente precisa de julgamento perante a ambiguidade, não para a parte que apenas precisava de alguém que escrevesse o código aborrecido.
Isto não é pureza. É controlo de custos. Cada limite determinístico remove um lugar onde a variação pode escapar. Um fluxo de trabalho que usa um modelo para ler texto desorganizado, depois validação determinística para verificar os campos obrigatórios, depois regras para aplicar a política conhecida, e depois revisão humana para a incerteza de alto impacto, será geralmente mais fácil de operar do que um fluxo de trabalho que pede ao modelo para fazer tudo e depois fica surpreendido quando tudo inclui várias opiniões.
O determinismo também melhora a evidência. Se uma regra foi acionada, registe a regra. Se um analisador extraiu um campo, registe a localização da fonte. Se a recuperação classificou documentos, registe a versão do índice e as pontuações. Se o modelo produziu um resumo, registe as instruções, o conjunto de fontes, a versão do modelo e a decisão do revisor. O objetivo não é transformar todos os fluxos de trabalho num tribunal. O objetivo é tornar as perguntas posteriores respondíveis sem convocar toda a equipa de engenharia para uma reunião chamada sincronização rápida.
O limite entre o trabalho determinístico e o probabilístico deve ser explícito em diagramas e orçamentos. Que passo pode variar. Que passo não pode. Que passo pode ser repetido. Que passo deve ser reproduzido exatamente. Que passo pode ser explicado estatisticamente. Que passo precisa de um registo. Se a equipa não consegue desenhar esse limite, não consegue estimar honestamente o custo.
A lição
O custo oculto dos fluxos de trabalho probabilísticos não é motivo para os evitar. É motivo para os contabilizar com honestidade. O custo surge em repetições, revisões, exceções, provas, avaliações, filas, apoio e no trabalho mais lento de decidir que variação é aceitável. Se o fluxo poupa tempo no caminho feliz, mas gasta-o em casos contestados e em nevoeiro operacional, o caso de negócio ficou apenas a meio.
Boas operações probabilísticas começam por tratar a incerteza como um material. Nomeie onde ela entra. Limite onde pode variar. Registe contexto suficiente para repetir decisões. Desenhe filas de exceções como superfícies de aprendizagem. Dê aos revisores autoridade e tempo. Avalie continuamente. Mantenha limites determinísticos onde reduzem custos. Precifique a saída e a mudança. Grande parte disto não é glamoroso. Isso é sinal de que pode sobreviver à produção.
A chamada ao modelo é a rubrica fácil. A verdadeira questão é o que a organização tem de fazer antes e depois dessa chamada para que o resultado possa ser confiável, contestado, reparado e melhorado. A probabilidade pode tornar os fluxos de trabalho mais capazes. Também pode torná-los menos previsíveis. A diferença não é magia. É operações, que continua a ser o lugar onde demonstrações impressionantes se tornam úteis ou caras.