Apresentação: SafeChat: Criação de sistemas de segurança baseados em IA em grande escala num mercado em tempo real

Transcrição

Bruna Pereira: Sou a Bruna. Sou engenheira de software na DoorDash. Hoje, vou contar-vos a história de um sistema que criámos para resolver um problema de segurança real em produção e que, quando funcionou, deitámos fora para criar algo ainda mais potente. No final, quero deixar-vos com duas coisas: como criámos o SafeChat na DoorDash e um padrão arquitetónico que podem levar para casa e utilizar em praticamente qualquer caso de utilização de IA que tenham. Sou engenheira de software na DoorDash há um ano e meio. Lidero a equipa de engenharia de confiança e segurança a partir do nosso centro em São Paulo, no Brasil. Antes disso, passei três anos a construir a minha própria startup. A minha experiência é principalmente na área da FinTech, na construção de sistemas altamente escaláveis.

O Marketplace da DoorDash (Segurança em Primeiro Lugar)

A DoorDash é um marketplace. Temos uma aplicação através da qual os consumidores podem encomendar comida. Temos os Dashers que entregam a comida. Temos os comerciantes que preparam a comida. Estes três grupos podem interagir em diferentes fases do processo. Podem comunicar entre si por chat. Podem ligar-se uns aos outros durante as entregas em curso e, claro, podem encontrar-se pessoalmente. Para a DoorDash, há duas coisas igualmente importantes: que as pessoas estejam seguras e que se sintam seguras na plataforma. Para nós, ambas as métricas são igualmente importantes para o produto. Quando falamos de segurança, uma parte significativa dos incidentes de segurança que observamos na plataforma está relacionada com abuso verbal. Seja no chat ou por voz, não faz diferença. Temos de agir imediatamente quando percebemos que algo perigoso está a acontecer, especialmente porque, ao contrário de uma plataforma de redes sociais, não conseguimos construir relações sólidas entre estas partes.

Essas relações duram entre 40 minutos e, no máximo, 6 minutos. Temos de agir imediatamente quando vemos que algo inseguro está a acontecer. Falando em escala, temos mais de 4 milhões de mensagens trocadas no chat todos os dias. Mais de 400 000 chamadas são trocadas entre os consumidores e os Dashers durante as entregas. São trocadas mais de 200 000 imagens no chat ou mesmo por SMS. No que diz respeito especificamente ao chat, o nosso objetivo é garantir que todas as mensagens que chegam ao destinatário sejam classificadas como seguras por nós. É isto que aumenta a dificuldade deste sistema, porque veja a quantidade de mensagens que temos. No chat, temos apenas uma fração de segundo para decidir se uma mensagem é segura ou não. Caso contrário, estaríamos a perturbar a experiência de chat. Quando falámos sobre isto pela primeira vez, a primeira reação, especialmente por parte dos responsáveis de negócios, foi simplesmente recorrer a um LLM para resolver o problema. Basta consultar um LLM e perguntar se a mensagem é segura ou não.

Se for segura, enviá-la. Se não for, bloqueá-la. Sim, teria funcionado teoricamente, mas, na prática, com o volume que temos, se já tiver utilizado LLMs em contexto de produção, deve saber que a latência destas chamadas ao LLM pode variar bastante. No nosso caso de utilização, temos uma latência média de 2 a 10 segundos para cada uma destas chamadas. Além disso, imagine qual seria o valor da fatura por chamar o LLM 4 milhões de vezes por dia. Simplesmente não funcionaria.

A criação do SafeChat

A questão passou a ser: como podemos ser inteligentes na utilização dos LLMs? A primeira coisa que fizemos foi tentar compreender os nossos dados. Passámos alguns meses a perceber o que significa «insegurança» no nosso contexto e também qual é a percentagem de mensagens que são, de facto, inseguras. Porque sabemos que a maioria das mensagens é insegura, mas quantas mensagens? O objetivo não era começar a tomar decisões nesta fase. O objetivo era apenas aprender com os dados de que dispomos. Implementámos o chat. Utilizámos uma API de moderação gratuita disponível no mercado. Chamámos essa API de forma assíncrona para perceber: qual é a categoria de mensagens inseguras que temos aqui? Esta é a etapa aborrecida que toda a gente quer saltar. É esta a conversa que tenho frequentemente no trabalho. Vamos dedicar alguns meses a compreender os nossos dados antes de agirmos, porque não importa se o modelo é barato ou caro.

Se não conhecermos os nossos dados, não conseguiremos tirar nada deles. Quando realizámos esta análise, confirmámos o que já sabíamos. A maioria das mensagens é segura, mas chegámos a quantificar isso. Apenas uma pequena percentagem de um único dígito das mensagens era insegura. Isto moldou toda a nossa arquitetura, porque nos indicou que podíamos construir uma camada agressiva e barata que estivesse correta quase sempre.

Depois, criámos um pequeno classificador. Trata-se de um modelo de aprendizagem automática treinado com os dados que recolhemos na etapa anterior. Tinha três funções. Tinha de ser rápido e responder em menos de 100 milissegundos em 90% dos casos. Tinha de ser económico, ou seja, sem custos por chamada, apenas com o custo da nossa infraestrutura. Tinha de ser bom numa coisa: identificar o que é obviamente seguro. Esta camada não é o juiz final. É como se estivesses num aeroporto dos EUA e passasses pelo detetor de metais. Um detetor de metais não diz que está em perigo. Apenas indica que vale a pena dar-lhe uma olhadela mais atenta. Para as mensagens que este modelo, que treinámos internamente, não consegue classificar como seguras, recorremos a um LLM, o que representa menos de 10% das mensagens. Eis a escolha de design que importa.

Quando recorremos ao LLM, não lhe perguntamos se a mensagem é segura ou não. Em vez disso, pedimos-lhe que a classifique ou que atribua uma pontuação em vários eixos. Vou explicar-vos, em alguns slides, porque é que isto é importante. O que perguntamos depende do contexto; no nosso caso, perguntamos quão ameaçadora é esta mensagem, quão obscena é ou quão sexual é. Esta é a camada em que o modelo se revela inteligente, porque só lhe fazemos as perguntas difíceis.

Falando da arquitetura geral, quando uma mensagem chega, filtramos todo o ruído. Removemos as mensagens vazias e os anexos de imagem, porque esses seguem para um fluxo de trabalho diferente. Removemos também as coisas que se assemelham a formalidades comuns. Em seguida, a mensagem segue para esta primeira camada, que é o modelo pequeno, o classificador. Se a mensagem for segura, simplesmente a enviamos. Se não for, segue para a camada 2, que é o LLM. O LLM classifica em vários eixos. Com esse resultado, podemos tomar uma ação graduada. É esta a estrutura que vos irei mostrar ao longo de toda a palestra. A camada de baixo custo que processa a maioria das mensagens, a camada de alto custo e, por fim, a ação. Cada camada desempenha a função em que é mais eficaz, ao custo adequado. Essa é a parte importante. Este é o slide que quero que se lembrem caso venham a construir o vosso próprio sistema de moderação.

Não peçam ao LLM um valor booleano. Em vez disso, peçam-lhe uma pontuação. A razão para isso é que um valor booleano é um indicador, enquanto uma pontuação é um regulador. Com uma pontuação, podem tomar medidas graduais dependendo da pontuação que receberam. Podem adicionar novas categorias mais tarde sem terem de voltar atrás e recriar tudo. Pode ajustar os limiares se achar que estão demasiado altos ou demasiado baixos. Além disso, isto aproveita aquilo em que os LLMs são bons. Imagine que lhe apresento uma frase e pergunto: «Esta mensagem é segura ou insegura?» Provavelmente, as vossas respostas serão todas diferentes, porque o que é inseguro no vosso contexto e como classificaríamos algo como inseguro? Em vez disso, compreenda o que significa «insegurança» e peça ao LLM para atribuir uma pontuação neste eixo. Os resultados serão muito mais estáveis.

É por isso que a pontuação também é importante, porque temos de agir de acordo com a gravidade da mensagem. Para nós, no nosso contexto, conteúdo de baixa gravidade significa, por exemplo, um palavrão. Se disseres um palavrão, limitamo-nos a censurar a mensagem e deixamo-la passar. Se for uma mensagem de gravidade média, por exemplo, se insultaste alguém, podemos bloquear a mensagem na totalidade e não a deixamos passar. Se for uma mensagem de gravidade elevada, por exemplo, uma ameaça, podemos bloquear a mensagem e oferecer à parte afetada a possibilidade de cancelar a encomenda sem pagar nada. Se for um conteúdo de gravidade muito elevada, também cancelamos a encomenda, bloqueamos a mensagem, advertimos o infrator e retiramos completamente a parte afetada deste ciclo. Esta carta só é possível porque dispomos dessas pontuações. Se não as tivéssemos, não seríamos capazes de diferenciar o que é rude do que é realmente perigoso. Falei sobre o chat, mas, no que diz respeito à voz e à imagem, a estrutura é praticamente a mesma.

Temos o mesmo motor de pontuação subjacente. Algumas coisas são diferentes. No caso das imagens, por exemplo, em vez daquela camada interna de baixo custo, temos uma API de visão comercial que já é suficientemente eficaz na identificação de violência, nudez e imagens perigosas. Utilizamos essa API como a camada de baixo custo. No caso da voz, a situação é mais complicada, porque no chat podemos ler a mensagem e decidir se a enviamos ou não. Na voz, no momento em que transcrevemos a mensagem e a analisamos, as palavras já foram ouvidas pelo destinatário. Não há forma de evitarmos que a mensagem seja entregue. A única coisa que podemos fazer de forma diferente é agir. Podemos desligar a chamada assim que identificarmos que há algo perigoso, e podemos, claro, propor o cancelamento da encomenda ou cancelá-la nós próprios. O mecanismo é praticamente o mesmo.

O resultado

Depois de fazermos isso, medimos quantos incidentes motivados por abuso verbal tivemos antes e depois de implementarmos o que chamamos de SafeChat. Verificámos que tivemos uma redução de cerca de 50% nesses incidentes. Este número não se assemelha a uma melhoria na precisão do modelo que tivemos. Trata-se de uma redução real de danos causados a pessoas. Este é o número que podemos utilizar para justificar os meses que dedicámos a compreender os nossos dados, com o objetivo de criar algo suficientemente poderoso para ajudar os nossos clientes.

Uma Plataforma de Moderação Independente do Conteúdo — Blocos de Construção

Este seria o momento em que eu encerraria a apresentação e lançaria o produto, a equipa seria promovida e todos iriam para casa. O que aconteceu foi que deitámos tudo fora. Não os ensinamentos que adquirimos. Não o modelo que treinámos. Não os dados que recolhemos. O que deitámos fora foi o sistema, o sistema SafeChat. Vou explicar-vos por que razão o fizemos. Quando começámos a implementar o SafeChat, outras pessoas na DoorDash e de outras equipas diziam: «Gosto do que estão a fazer. Também quero fazer o mesmo para o meu caso de utilização.» As pessoas começaram a perguntar-nos: podemos moderar as fotos de perfil dos Dashers e dos consumidores? Podemos moderar o nome no registo? Podemos moderar as avaliações de comida, por exemplo? Mesmo em casos que não têm nada a ver com segurança, como: podemos identificar fraudes no chat e nas chamadas telefónicas?

Percebemos que, se começássemos a implementar cada um desses pedidos, estaríamos a reconstruir tudo do zero, repetidamente. Percebemos que o que eles realmente queriam não era o SafeChat, não era o sistema que criámos. O que eles queriam era o padrão que criámos. Aquela ação que começa por ser simples, depois mais complexa e, por fim, graduada. Era isso que eles queriam. Pensámos: por que não transformá-lo numa plataforma que qualquer pessoa possa utilizar para qualquer caso de utilização? Foi isso que criámos. Criámos uma plataforma de moderação independente do conteúdo. A ideia aqui é que não precisamos de saber o que o seu conteúdo significa. Não precisamos de conhecer a vossa lógica de negócio. O que sabemos, o que sabemos fazer, é como registar decisões, como integrar com diferentes fornecedores de modelos e como alterar as etapas com condições entre elas. As equipas trazem o significado e a plataforma orquestra isso. É essa a ideia.

O que prometemos às equipas é que podem fazer isso sem escrever qualquer código. Podem aceder à plataforma através de uma interface de utilizador. Podem configurá-la e podem tomar as medidas que desejarem. É essa a flexibilidade que oferecemos. Conseguimos isso. Não importa se se trata de uma diretriz de conteúdo, de um caso de fraude ou de um caso de segurança. Para nós, isso não faz diferença. A plataforma possui alguns blocos de construção que tornam isso possível, e vou mostrar-vos quais são.

Atualmente, temos três tipos de modelos nesta plataforma. Temos o que chamamos de modelos internos, que são modelos que podemos treinar, ajustar e implementar nos nossos próprios servidores. Temos modelos externos, que são modelos que podemos simplesmente adquirir através de um contrato com um fornecedor. Temos um prompt externo. Um prompt externo é um prompt que pode ser escrito para ser utilizado em qualquer LLM de qualquer fornecedor disponível no mercado. No que diz respeito aos modelos internos, estes são treinados e alojados internamente. Temos uma plataforma de ML que nos ajuda a utilizar qualquer modelo disponível no mercado, utilizando os nossos próprios dados rotulados. Se tivermos dados rotulados, podemos utilizá-los para treinar esses modelos. Podemos implementá-los na nossa própria infraestrutura. Estes modelos são disponibilizados através de uma API que podemos utilizar dentro da nossa plataforma. A ideia é que sejam económicos e rápidos.

Quando os treinamos, temos um esquema de entrada e saída predefinido que, uma vez definido, todos — todos os clientes — podem utilizar seguindo esse esquema. O pequeno classificador que criámos para o SafeChat é, na verdade, um modelo interno agora. Temos os modelos externos. A ideia aqui não é reinventar nada que já esteja disponível no mercado. Por exemplo, a segurança de imagens é algo que já está resolvido. Não precisamos de o construir de novo. A ideia aqui é que a plataforma não recrie coisas só porque sim. Temos isso disponível. Temos um contrato com eles. Integramos uma única vez na nossa plataforma e qualquer cliente é livre de a utilizar. Temos apenas chaves de API diferentes para podermos rastrear a faturação em conformidade. Temos os prompts externos. Os prompts externos são os mais flexíveis. Utilizamos um gateway LLM para nos integrarmos com praticamente qualquer modelo de qualquer fornecedor disponível no mercado.

Se estiver mais interessado em saber como construímos este gateway LLM, há uma palestra da equipa da DoorDash sobre como construímos o gateway LLM na DoorDash. A ideia aqui é que este gateway se situe entre a plataforma e todos os modelos de todos os fornecedores disponíveis no mercado. Os clientes podem escolher os modelos que pretendem utilizar. Podem selecionar os esquemas de entrada e de saída para cada prompt de que dispõem. Podemos utilizar as funcionalidades disponíveis neste gateway LLM para definir estratégias de fallback e de nova tentativa sem ter de escrever mais código. Utilizamos o fallback e a nova tentativa para, por exemplo, se já utilizou modelos LLM, deve saber que, por vezes, estes simplesmente não respondem. Os fornecedores estão todos inativos ou os modelos não estão a funcionar como esperado. Se criou um prompt que visa um modelo que não está disponível, existe algum outro prompt que possa utilizar como alternativa enquanto este não voltar a funcionar corretamente? Além disso, define qual é o esquema de saída que pretende dessa chamada LLM. É o utilizador que define esse JSON. Por vezes, os LLMs simplesmente não respondem a isso. Pode definir quantas vezes pretende tentar novamente antes de devolver um erro estruturado ao cliente.

Criação de Agentes de Moderação

Estes são os blocos de construção. Com estes blocos de construção, pode compor o que chamamos de agentes de moderação. Um agente de moderação é um pipeline ou um fluxo de trabalho cujas etapas pode compor. Eis um exemplo de um modelo interno no qual pode selecionar uma condição. Esta condição irá utilizar o que for devolvido por este modelo interno. Com esta condição, pode avançar para uma etapa ou para outra. Neste caso, o fluxo segue para um fornecedor externo ou para um prompt de LLM. No entanto, pode alterá-lo e, no final, pode tomar uma ação. A ação é da responsabilidade do cliente. É o cliente que decide. Nesta altura, o cliente dispõe do resultado de cada etapa presente no seu agente de moderação. Com isso, pode tomar qualquer ação que desejar, ou nenhuma, se necessário. Falando de condições, a forma como as expressamos é, mais uma vez, inteiramente a partir da interface do utilizador.

Pode escrever e expressar quaisquer condições que desejar, simples ou complexas, utilizando a saída do modelo anterior. Este é, na verdade, o pipeline do SafeChat. É super simples. Possui um modelo interno. Se o rótulo de insegurança devolvido por este modelo interno for superior a 0,5, então passa para o prompt do LLM. O prompt do LLM vai responder com um conjunto de categorias e a pontuação de cada uma delas. Segue-se uma ação. Se este valor não for superior a 0,5, passa-se diretamente para uma ação. Neste caso, sei que não tomamos qualquer ação. Na verdade, censuramos a mensagem se houver palavrões na mesma. Pode definir qualquer condição entre quaisquer etapas e criar o seu agente de moderação. O seu agente de moderação pode ser de dois tipos diferentes. Pode ser um agente de moderação síncrono, o que significa que é uma chamada HTTP.

A ligação permanece aberta enquanto o agente de moderação está a ser executado. Executamos todas as etapas que temos no agente. Utilizamos a moderação síncrona apenas quando queremos bloquear uma decisão. Por exemplo, no chat, queremos poder bloquear a mensagem se esta for insegura. Há uma desvantagem em utilizar a moderação assíncrona, porque é necessário limitar a latência de cada uma das etapas de acordo com a latência global da chamada. Tentamos evitar isso tanto quanto possível e preferimos utilizar a versão assíncrona do agente de moderação. Pode escolher a que preferir ao criar o agente. Para a moderação assíncrona, recebemos um pedido de execução do agente de moderação. Confirmamos que o pedido foi feito e executamos todo o agente em segundo plano. Quando terminamos, publicamos uma mensagem num tópico do Kafka ao qual o cliente está subscrito, e este pode reagir à mensagem assim que a receber. É muito mais flexível. Ajuda-o a não limitar tanto a latência da execução e permite-lhe adicionar passos mais complexos e, na verdade, mais passos dentro do agente de moderação.

Outra funcionalidade que temos na plataforma de moderação é o backtesting. Isto é interessante porque, por vezes, quando criamos um prompt, pensamos: «Isto vai funcionar com certeza», mas não temos tanta certeza assim. Testamo-lo com um, dois, três exemplos, mas não é suficiente para garantir que funciona realmente em produção. Imagine também um agente tão complexo como o que mostrei anteriormente; provavelmente não sabe o que vai resultar disso. A ideia é que possa utilizar a funcionalidade de backtesting da plataforma para construir o seu agente. Se tiver um conjunto de dados históricos, pode testar o seu agente com base nesse conjunto de dados e pode até testá-lo em relação a um único passo, se quiser. Uma pessoa pode intervir e classificar os resultados de cada etapa ou de cada agente como corretos ou incorretos e, em alguns casos, podemos até rotulá-los como verdadeiro positivo, verdadeiro negativo, falso positivo ou falso negativo. No final, utilizamos essa informação introduzida pelo utilizador para calcular algumas métricas, de modo a perceber se é suficientemente bom para entrar em produção ou se precisamos de o aperfeiçoar ainda mais. É isto que torna o princípio «teste antes de confiar» um verdadeiro fluxo de trabalho integrado na nossa plataforma.

Lições aprendidas

Tenho aqui três lições que gostaria de partilhar convosco. Uma delas é: se tiverem um caminho de tráfego intenso com elevado volume e quiserem utilizar um LLM para o mesmo, coloquem um modelo económico à frente dele. Normalmente, 90% do conteúdo que tem a certeza de que não deve chegar ao LLM pode ser captado por um modelo barato que pode treinar em casa. Leva algum tempo. Tem de aprender com os seus dados. Essa parte que o LLM faz por si, tem de a fazer primeiro por si próprio. Não salte essa parte. Resista a isso. Se alguém te perguntar: «Sim, mas vamos adicionar o LLM só porque ainda não o temos», diz «nem pensar». Porque, do ponto de vista económico, só faz sentido se fizeres apenas as perguntas difíceis ao LLM. Ao usar o LLM, não peças rótulos. Não perguntes: «É verdade ou falso?».

Pede-lhe um nível de gravidade, pede-lhe uma pontuação. Também não lhe peças uma pontuação de 5 dígitos, porque os LLMs não estão a calcular nada, estão a raciocinar. Pede-lhe uma pontuação de uma forma simples, de modo a que o LLM consiga responder. Sabe quando deves descartar um sistema. Se criares algo e perceberes que é bom, e as pessoas estiverem a pedir a sua própria versão disso, talvez o sistema que criaste não seja o teu verdadeiro trunfo. Talvez o padrão é que, e possas transformá-lo em algo que todos possam usar. Reparei que hoje em dia é tão barato criar código que as pessoas simplesmente avançam com isso. Sim, não precisamos de reutilizar porque podemos construir o nosso próprio código, já que é tão barato. É barato criar código, mas não é barato mantê-lo.

Resumo

Esta é a palestra na íntegra, resumida. Temos este filtro económico que criámos, que aprende com os dados de que dispomos. Temos o «juiz inteligente» que utiliza LLMs. Temos a ação graduada. Tudo isto numa plataforma que podemos utilizar. Modelos internos, modelos que implementamos e disponibilizamos a partir da nossa própria infraestrutura. Temos fornecedores, contratos e APIs que podemos utilizar e disponibilizar a qualquer cliente. Temos os LLMs. O gateway LLM é, na verdade, uma peça muito importante desta plataforma. Tudo isto com configuração declarativa, pelo que não é necessário programar para o efeito. Já está tudo configurado de forma a que só precises de selecionar os elementos na interface do utilizador e criar o teu próprio pipeline. O backtesting também é extremamente importante. É terrível avançar às cegas com algum prompt para a produção, só para ver o que acontece quando o colocas lá. Tenho quase a certeza de que, se tiver um problema de moderação em casa, ao utilizar esse padrão, conseguirá resolvê-lo de forma fácil.

Perguntas e Respostas

Participante 1: Mencionaste que os modelos internos eram baratos. Podes dar-nos uma ideia de quão baratos são? Porque imagino que também haja recursos gastos na manutenção e no treino desses modelos internamente. Quão barato é em comparação com os modelos de nível inferior do próprio fornecedor?

Bruna Pereira: O quão barato depende do volume que tiver. Porque o custo baixo reside no facto de, de certa forma, só precisarmos de o implementar nos nossos servidores. Depende da infraestrutura que tiver. A questão é que não paga por cada chamada. Paga-se apenas para o implementar. Quanto à parte do treino, sim, há alguns custos, mas são únicos. Na verdade, no caso do SafeChat, por exemplo, estamos na 9.ª versão. Treinámo-lo nove vezes. É como um custo único para 4 milhões de chamadas por dia. É assim que calculamos o que é barato e o que é caro. Depende muito do caso de utilização e da vossa infraestrutura.

Participante 2: Já encontraram alguma forma de quantificar o backtesting, tipo, quanto é suficiente ou se precisamos de mais cenários?

Bruna Pereira: Isso é difícil. Vou dar-lhe um exemplo que acabámos de utilizar: segurança versus fraude. No que diz respeito à segurança, as mensagens inseguras são claramente inseguras. O modelo interno nem sempre consegue identificar o que é seguro ou não. No que diz respeito à fraude, por exemplo, há situações que parecem bastante fraudulentas, mas que, no final, não o são. Porque dizem: «Sim, vou pagar-te quando chegares aqui.» Querem apenas dar uma gorjeta extra ao Dasher porque este está a fazer um favor. Será fraude ou não? Depende do grau de zona cinzenta do seu caso de utilização. Normalmente, o que fazemos é evitar testar mais de mil exemplos, porque precisamos que uma pessoa os analise manualmente e classifique o que é verdadeiro e o que não é. Se tiver 100 000, não será possível fazê-lo. Mil é um número em que realmente confiamos. As pessoas dedicam-se a isso e dão importância a isso. Porque já tentámos com mais exemplos e as pessoas respondiam com qualquer coisa, o que se reflete nas pontuações que obtemos. Se tivesse de dar um número, diria que mil é um bom número.

Participante 3: O modelo básico alguma vez foi super determinístico, tipo apenas uma lista de palavrões, antes de se tornar mais complicado do que isso? Então, também atribuem uma pontuação ao modelo básico, em vez de se limitarem a uma verificação de segurança de aeroporto do tipo «sim», «não», «isto é seguro», «isto não é seguro»?

Bruna Pereira: Sim, o modelo simples também é pontuado. Tem uma escala de 0 a 1, indicando o quão inseguro ou seguro é. Sim, tivemos alguns problemas com isso, porque quando fizemos a nossa primeira ronda, tentámos apenas recolher algumas mensagens inseguras que tínhamos. Quando a mensagem nos chega, já é suficientemente má. Porque se não for assim tão má, ninguém se vai queixar. Na primeira ronda de treino que fizemos, havia um monte de mensagens realmente más e um monte de mensagens aceitáveis. O modelo era quase binário. Depois, realizámos uma segunda ronda, utilizando uma API de moderação disponível no mercado, que é extremamente lenta. É por isso que não funciona para nós. Demora segundos a devolver um resultado. No entanto, ajudou-nos a classificar os dados como: sim, isto é extremamente inseguro; isto é um pouco inseguro; e isto é seguro.

Ajudou-nos a obter resultados graduais e mais razoáveis do modelo. Definitivamente, o modelo não funciona em termos de verdadeiro ou falso. É também uma pontuação. É difícil definir qual é a pontuação a partir da qual se pode dizer que, com essa pontuação, se deve passar para a segunda camada. Porque se indicar «sim», com 85% de probabilidade de ser uma mensagem insegura, passa para a segunda camada ou não? Isto é algo que é preciso aprender com os dados e ajustar os limiares quando for necessário. Nesse sentido, a equipa da plataforma de ML, os engenheiros de dados e os engenheiros de aprendizagem automática ajudaram-nos imenso com isso.

Participante 4: A vossa plataforma também ajuda a automatizar a criação de novos modelos internos para se adaptarem a outros casos de utilização, como, por exemplo, para a etapa económica e rápida?

Bruna Pereira: Não, neste momento não. Na verdade, a parte do treino, do retreino e do ajuste fino é algo que é totalmente gerido pela equipa da plataforma de ML. Contamos com a plataforma deles para fazer isso. Não precisamos de o fazer nós próprios. Esta é uma boa separação de responsabilidades, porque, como mencionei aqui, os engenheiros de ML possuem conhecimentos que nós não temos. Não queremos que haja esta sobreposição. A plataforma de moderação é apenas um cliente deste modelo que já está treinado.

Participante 5: Mencionaste que retreinas o modelo algumas vezes, o mais económico. Como é que decides isso?

Bruna Pereira: Primeiro, fizemos uma análise aleatória dos dados. Além disso, esses casos de risco geram incidentes que são encaminhados aos agentes, e os agentes fornecem-nos feedback com a informação de que, sim, essa mensagem chegou ao cliente e não foi detetada pelo modelo. Então, quando reparamos nisso, tentamos perceber qual é o padrão que nos escapou e em que etapa? Foi na camada 1 ou 2? Vou dar-lhe um exemplo. Fizemos um novo treino. Da última vez que o treinei, concentrei-me nas abreviaturas. Não importa se o LLM compreende a abreviatura, porque a mensagem nunca chegou a essa fase, já que a primeira camada diz, naturalmente, que é segura. Não há nada de inseguro aqui. Tive de encontrar uma quantidade significativa de exemplos de mensagens inseguras que utilizassem abreviaturas e, em seguida, executar outro conjunto de treino nesta primeira camada. Com o volume que temos, não conseguimos ver todas as mensagens que passam. Normalmente, o fluxo chega a um responsável pela segurança. Eles vêm ter connosco e tentamos identificar qual é o padrão que nos escapou.

Participante 5: Quando se recorre à parte inteligente da plataforma, está-se a ligar o modelo externo. Qual é o plano de contingência se isto se tornar demasiado lento, por exemplo, uma vez que mencionou que é necessária baixa latência nas mensagens? Qual é o plano de contingência?

Bruna Pereira: Na verdade, uma coisa que não mencionei aqui é que o plano de contingência pode ser qualquer tipo de modelo. Temos este modelo interno, mas, por vezes, os nossos servidores falham. Temos um plano de contingência com esta camada de moderação que é fornecida por um prestador de serviços externo. Utilizamo-la enquanto não recuperamos os nossos servidores. É mais lenta, mas é melhor do que nada. O plano de contingência aqui pode ser qualquer um. Pode-se utilizar, como plano de contingência, o LLM, por exemplo. Não o usaríamos especificamente para o chat porque o volume é demasiado elevado. Pode adicionar como alternativa qualquer tipo de modelo. Se tiver um fornecedor que não esteja a funcionar corretamente, talvez possa usar um LLM apenas enquanto o fornecedor recupera a sua API e, depois, pode voltar a usar o fornecedor.

Participante 6: Apenas para falar um pouco sobre o backtesting, referiu-se um pouco à necessidade humana de realmente produzir isso. Trata-se de dados que já existiam ou de dados que tiveram de ser calculados quando iniciou este projeto? Já dispunham de um conjunto completo de mensagens inseguras ou foi algo que tiveram de fazer ao rever dados antigos e identificá-las como parte deste processo?

Bruna Pereira: Quando começámos, tínhamos apenas alguns dados, porque ainda não tínhamos implementado a monitorização no chat. Não tínhamos quaisquer dados para utilizar no treino. O que fizemos primeiro foi identificar os casos de segurança que surgiram devido a abuso verbal. A partir daí, conseguimos encontrar exemplos de mensagens inseguras. Implementámos o sistema de monitorização no chat. Quando começámos, passámos cerca de um mês e meio apenas a recolher dados. A partir daí, passámos a dispor dos dados necessários para retreinar o modelo sempre que quiséssemos. Houve alguns aspetos que nos escaparam. Por exemplo, a parte das abreviaturas escapou-nos porque não conseguimos analisar todas as mensagens. Por vezes, aprendemos coisas quando uma pessoa nos aborda e diz que algo está errado; só então conseguimos identificar o padrão e integrá-lo nos prompts ou nos modelos de que dispomos. Um exemplo que tivemos foi o seguinte: começámos com um conjunto de categorias e depois percebemos que a maioria das reclamações que chegavam a um ser humano estavam relacionadas com falta de respeito e não com insegurança. Adicionámos uma categoria de «falta de respeito» ao nosso LLM para identificar o grau de falta de respeito de uma mensagem, por exemplo. Sim, não basta fazê-lo uma vez e esperar que funcione para sempre. É preciso continuar a iterar e a aperfeiçoá-lo.

Participante 7: À medida que começaram a resolver o problema mais complexo da fraude, também perceberam que tinham de começar a lidar com a injeção de prompts ou outros problemas emergentes?

Bruna Pereira: Acho que já estávamos bem preparados para este problema. Especialmente o gateway do LLM, que também nos ajuda a bloquear ou a não permitir este tipo de coisas. Sim, temos algumas formas de lidar com isso. Mesmo antes dos casos de fraude, já tínhamos coisas desse tipo, sem dúvida.

Veja mais apresentações com transcrições