DeepEval Framework (2026 Edition)

Olá, daqui fala o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 1 de 18. A maioria das equipas avalia os seus modelos de linguagem com deploy recente lendo manualmente uma folha de cálculo de respostas. É um processo lento, altamente tendencioso e impossível de escalar à medida que uma aplicação cresce. O DeepEval é a framework de avaliação open-source que substitui este trabalho manual, funcionando efetivamente como o Pytest para LLMs. Supõe que a tua equipa está a fazer deploy de uma nova aplicação generativa. Precisas de garantir que ela se comporta corretamente antes de fazeres push para produção. Com o DeepEval, escreves testes exatamente da mesma forma que escreves unit tests standard em Python. Crias um ficheiro chamado test example dot py. Dentro desse ficheiro, constróis um test case. Este objeto de test case contém a prompt de input inicial, o output real gerado pela tua aplicação e quaisquer respostas target esperadas. Em seguida, aplicas uma métrica de avaliação a este test case. Em vez de usares uma verificação de igualdade standard para ver se a variável A corresponde perfeitamente à variável B, usas uma função de assertion especializada fornecida pela framework. Corres este ficheiro a partir da tua command line usando o comando standard do Pytest. A framework executa os testes em paralelo, captura as assertions e reporta os passes e failures diretamente no teu terminal. Aqui está o ponto chave. Testes determinísticos standard não conseguem avaliar a qualidade ou a precisão da linguagem humana. Se um utilizador pedir à tua aplicação um resumo de um documento, existem milhares de maneiras corretas de escrever esse resumo. Padrões de regex e exact string matching são inúteis aqui porque não conseguem interpretar o significado semântico. O DeepEval lida com esta enorme variabilidade usando um conceito chamado LLM-as-a-judge. A framework utiliza um modelo de linguagem generalizado e altamente capaz para avaliar os outputs específicos da tua própria aplicação. O judge model lê o output da tua aplicação, compara-o com os critérios rigorosos da métrica que selecionaste e calcula um score numérico. Mais importante ainda, devolve um resultado boolean indicando se o score atinge o teu threshold predefinido, juntamente com uma justificação em plain text a explicar exatamente por que deu esse score. Isto significa que um teste que falhou dá-te contexto de debugging imediato. Ao desenhar estes test cases, tens de escolher entre dois modos distintos de avaliação. É fácil confundir o scope destes modos, por isso vamos traçar uma linha clara. A avaliação end-to-end analisa apenas o input inicial e o output final. Toda a aplicação é tratada como uma black box. Forneces uma prompt, o sistema dá uma resposta e o judge dá um score a esse texto final. Ele ignora completamente como a aplicação gerou a resposta. A avaliação component-level é uma abordagem white-box. Em vez de apenas verificar a resposta final, este modo faz trace das etapas internas específicas que a tua aplicação executou para chegar lá. Se o teu sistema pesquisa numa base de dados para fazer retrieve de documentos de contexto antes de gerar o seu texto, um teste component-level avalia essa etapa de pesquisa específica. Ele verifica se os documentos obtidos eram realmente relevantes para a prompt do utilizador, de forma totalmente independente da resposta final gerada. Testas o mecanismo interno, não apenas o produto final. Podes ter um sistema que passa num teste end-to-end dando uma resposta correta, mas falha num teste component-level porque extraiu essa resposta do documento interno errado. Avaliar um modelo de linguagem já não é um exercício de leitura subjetiva; é uma parte rígida, automatizada e repetível do teu pipeline de continuous integration. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 2 de 18. Não podes medir o que não definiste. Se as tuas avaliações automatizadas parecem inconsistentes, o problema muitas vezes começa antes mesmo da métrica correr. É provável que estejas a passar os componentes errados do teu prompt para os limites de avaliação errados. A solução é definir rigorosamente a interação com o LLM usando o blueprint do test case do LLM. Um test case de LLM no DeepEval serve como a unidade atómica de avaliação. Obriga-te a isolar uma única interação específica com o teu sistema. Não passas logs completos de conversas ou bases de dados raw para um evaluator. Em vez disso, extrais exatamente o que entrou, o que saiu e que dados de background estiveram envolvidos num único turno distinto. Interações multi-turn têm o seu próprio blueprint específico, mas o test case standard foca-se estritamente num request e response isolados. Cada test case requer dois argumentos obrigatórios. O primeiro é o input. Esta é a string exata que um utilizador ou sistema submeteu ao modelo. O segundo é o actual output. Este é o texto que o teu large language model gerou em resposta. Se não avaliares mais nada, tens de fornecer estes dois parâmetros para medir métricas básicas como toxicidade ou answer relevance. Considera um chatbot de suporte ao cliente. O input é um utilizador a perguntar se pode devolver um par de sapatos usados após trinta e cinco dias. O actual output é o teu modelo a gerar uma resposta que nega a devolução. Para avaliar se essa negação está realmente correta, precisas de fornecer uma baseline truth. O DeepEval dá-te dois parâmetros opcionais diferentes para isto. Estes são o expected output e o context. Os developers confundem isto constantemente. O context é estritamente factual. Contém a verdade raw e não formatada, como uma string de texto da tua política corporativa a declarar um limite estrito de trinta dias para reembolsos. O expected output é muito mais específico. Dita o tom, a linguística e a formatação. Usas o expected output quando queres que o evaluator verifique se o modelo respondeu com um pedido de desculpas educado e específico, em vez de apenas fazer output de uma negação direta. O context fundamenta os factos. O expected output fundamenta o estilo e o fraseamento exato. Aqui está o insight principal. A forma como constróis o resto deste test case muda dependendo da tua arquitetura subjacente. Se estiveres a avaliar uma pipeline de Retrieval-Augmented Generation, tens de definir o retrieval context. Este parâmetro aceita uma lista de strings que representam os chunks exatos de documentos que o teu retriever extraiu da vector database. Não confundas isto com o parâmetro context standard. O context é a verdade ideal que fazes hardcode para o teste. O retrieval context são os dados reais que a tua pipeline encontrou efetivamente em produção. Os evaluators comparam os dois para determinar se o teu algoritmo de pesquisa está a recuperar os documentos certos. Se estiveres a construir um agent em vez de uma pipeline standard, utilizas o parâmetro tools called. Este aceita uma lista de objetos ou strings que representam as funções específicas que o agent decidiu invocar durante esta interação isolada, como acionar uma calculadora de reembolsos interna. Fornecer isto permite-te avaliar as decisões de agentic routing em conjunto com a geração de texto final. A fiabilidade de uma métrica automatizada está inteiramente ligada à higiene destes parâmetros. Um evaluator nunca pode penalizar uma hallucination se falhares em fornecer o context factual estrito contra o qual ele verifica o output. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 3 de 18. Métricas tradicionais de NLP, como BLEU e ROUGE, são péssimas a avaliar large language models modernos, mas fazer o deploy de um humano para cada test run é impossível. A solução para escalar a tua avaliação sem sacrificar a compreensão semântica é o poder do LLM-as-a-Judge. As métricas tradicionais procuram sobreposições exatas de palavras. Se o teu modelo gerar um output com um resumo perfeitamente preciso usando sinónimos diferentes, uma métrica baseada em exact string matching vai avaliá-lo mal porque não consegue perceber o significado. Usar um LLM como judge resolve este problema. Ele lê o output, processa o contexto e avalia a semântica de forma muito semelhante a um revisor humano, mas à velocidade da máquina. No DeepEval, uma métrica avaliada por um LLM executa três ações específicas. Primeiro, calcula um score entre zero e um. Zero é uma falha completa, um é perfeito. Segundo, compara esse score com um threshold rigoroso que tu defines. Se o teu threshold for zero vírgula sete e o modelo tiver um score de zero vírgula seis, o teste falha. Terceiro, devolve um motivo. O LLM que faz a avaliação gera uma explicação em texto a detalhar exatamente porque é que atribuiu esse score específico. Isto diz-te o que correu mal sem te obrigar a ler manualmente os raw logs. O DeepEval divide estas métricas em três categorias. As métricas de RAG avaliam pipelines de retrieval-augmented generation. As métricas agentic avaliam agentes autónomos. As métricas custom permitem-te definir os teus próprios critérios de avaliação do zero. Embora os prompts subjacentes para estas sejam diferentes, todas utilizam o mesmo mecanismo de judge. Ao selecionar uma métrica, os developers costumam confundir reference-based metrics e referenceless metrics. Aqui está o insight principal. As reference-based metrics exigem uma ground truth. Elas precisam de uma resposta correta conhecida para comparar, o que as torna altamente eficazes durante o desenvolvimento e testes iniciais. As referenceless metrics não precisam de uma ground truth. Elas avaliam o output com base inteiramente no contexto fornecido ou no próprio input prompt. Como não dependem de uma resposta pré-escrita, as referenceless metrics são exatamente o que tu usas para monitorização em live production. É tentador associar uma dúzia de métricas a cada prompt para garantir a qualidade. Não faças isto. A regra geral é usar menos de cinco métricas por aplicação. Escolhe as métricas que realmente se alinham com a tua lógica de negócio específica. Correr métricas desnecessárias resulta apenas em testes mais lentos e custos de compute mais altos. Falando em custos, usar um modelo comercial de ponta para avaliar milhares de test runs diários torna-se caro rapidamente. O DeepEval permite-te trocar o evaluator default por custom models. Podes configurar a framework para usar o Azure OpenAI, caso a tua infraestrutura corporativa o exija. Em alternativa, podes fazer o setup de um modelo local usando o Ollama. Ao correr um modelo open-source capaz localmente no teu próprio hardware, crias um judge gratuito e imparcial. Basta inicializares o teu client Ollama local e passares esse model object diretamente para a configuração da métrica. O DeepEval depois trata do resto e executa todo o evaluation pipeline sem chamar billing APIs externas. O verdadeiro valor de um LLM judge não está apenas no score numérico, mas no raciocínio automatizado que ele fornece para te ajudar a fazer debug de cada falha. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex do DEV STORIES DOT EU. DeepEval framework, episódio 4 de 18. Uma coisa é o teu RAG pipeline responder a uma pergunta. Outra coisa completamente diferente é ele inventar, com toda a confiança, detalhes que não existem nos teus documentos de origem. Hoje vamos olhar para a avaliação de RAG generators, especificamente como detetar essas mesmas falhas. Um Retrieval-Augmented Generation pipeline tem duas partes móveis distintas. O retriever vai buscar os documentos relevantes. O generator pega nesses documentos e escreve a resposta final. Hoje vamos ignorar o retriever. Assumimos que o teu sistema já foi buscar os documentos certos. O nosso foco está estritamente no generator a sintetizar o texto. Para garantir que este texto é tanto seguro como útil, dependes de duas métricas: Faithfulness e Answer Relevancy. A primeira métrica é Faithfulness. Este é o teu principal guardrail contra alucinações. Faithfulness mede se a resposta do generator, à qual o DeepEval chama de actual output, pode ser totalmente justificada pelo retrieval context. Considera um cenário padrão. Um utilizador pergunta ao teu chatbot sobre o plano de saúde da empresa. O retriever vai buscar o manual de RH correto. O generator responde que o plano cobre assistência médica, oftalmológica e dentária completa. No entanto, o manual de RH nunca menciona cobertura dentária. O generator sintetizou uma mentira altamente plausível e bem formatada. A métrica de Faithfulness deteta exatamente este comportamento. Ela isola as afirmações feitas no actual output e compara-as com o retrieval context, parte por parte. Se o generator incluir factos ausentes no contexto, o score de Faithfulness desce. Não interessa se o facto por acaso é verdadeiro no mundo real. Se não for explicitamente suportado pelo contexto fornecido, a métrica sinaliza-o como uma falha. Agora, a segunda parte disto é Answer Relevancy. Uma resposta fiel não é necessariamente uma resposta útil. O generator pode devolver um resumo perfeitamente preciso do manual de RH que ignora completamente o que o utilizador realmente perguntou. Answer Relevancy mede o quão bem o actual output aborda diretamente o input original. Avalia se a resposta é completa, concisa e livre de divagações desnecessárias. Se o utilizador perguntar o valor da franquia, e o generator listar a franquia, mas depois adicionar três parágrafos sobre a história do seguro de saúde da empresa, o score de Answer Relevancy diminui. O sistema penaliza informação evasiva ou excessiva com a mesma rigidez que informação em falta. Para avaliar estas métricas, constróis um test case no DeepEval. Tens de fornecer três variáveis. Primeiro, o input, que representa o prompt do utilizador. Segundo, o actual output, que é o texto que o teu generator produziu. Terceiro, o retrieval context, contendo o texto bruto dos documentos que o teu retriever forneceu ao generator. Passas este test case para ambas as métricas. O DeepEval avalia o texto e calcula um score entre zero e um para cada. Defines um threshold de aprovação. Se uma resposta tiver um score de zero vírgula nove em Faithfulness, mas zero vírgula quatro em Answer Relevancy, sabes que o generator é seguro, mas inútil. Se os scores se inverterem, o teu generator é útil, mas está ativamente a alucinar. Aqui está o ponto-chave. Ao avaliar generators, tens de separar sistematicamente a verdade do contexto. Um generator bem-sucedido não diz a verdade absoluta; diz exatamente o que os documentos fornecidos lhe permitem dizer, respondendo apenas ao que foi perguntado, e nada mais. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 5 de 18. Se o teu LLM está a dar más respostas, pode não ser culpa do modelo. O teu retriever pode estar simplesmente a dar-lhe lixo. Hoje vamos falar sobre a avaliação de retrievers de RAG, especificamente usando Contextual Precision, Contextual Recall e Contextual Relevancy. Imagina fazeres uma query a uma grande knowledge base à procura de um detalhe muito específico de uma política. Em vez de extrair exatamente aquele parágrafo de que realmente precisas, o teu retriever vai buscar dez páginas de texto vagamente relacionado. O LLM perde-se no ruído, os custos dos tokens sobem e a resposta final sofre com isso. Para corrigir isto, tens de medir o passo de retrieval de forma completamente separada do passo de generation. A primeira métrica é a Contextual Relevancy. Esta métrica analisa os chunks de texto em bruto que o teu retriever extrai da base de dados e calcula o rácio de frases relevantes em relação ao total de frases. Se fizeres retrieve de mil palavras apenas para capturar uma frase útil, o teu score de relevância cai a pique. Alta relevância significa que estás a passar um contexto limpo e denso para o prompt do LLM, sem desperdiçar tokens com informação de fundo irrelevante. A seguir, temos o Contextual Recall. Este avalia se o teu retriever encontrou toda a informação necessária para responder à query do utilizador. O DeepEval calcula isto pegando no output esperado para uma query e extraindo todas as afirmações factuais do mesmo. Depois, analisa o contexto do teu retrieval para ver se essas afirmações específicas estão realmente presentes. Se faltar no contexto um facto crucial necessário para a resposta, o score de recall desce. Um recall alto garante que o LLM tem realmente a matéria-prima de que precisa para ter sucesso. Depois, temos a Contextual Precision. As pessoas frequentemente confundem precision com recall. Recall significa que não deixaste escapar nada. Precision significa que não incluíste palha. Nas avaliações de RAG, a precision tem um peso enorme no ranking. Esta verifica se os chunks de contexto altamente relevantes aparecem bem no topo da lista do retrieval. Se aquele parágrafo vital estiver enterrado na posição número dez, debaixo de nove chunks inúteis, o teu score de precision é baixo. Os language models geralmente prestam mais atenção ao topo do prompt, por isso a ordem do retrieval muda completamente o resultado. Aqui está o ponto-chave. Existe uma tensão constante entre precision e recall. Se configurares o teu retriever para retornar cinquenta chunks de cada vez, o teu recall será provavelmente perfeito porque lançaste uma rede enorme. Mas a tua precision e relevância vão cair a pique, porque a maioria desses cinquenta chunks é ruído. Por outro lado, se restringires o retriever a exatamente um chunk, a tua relevância será impecável, mas o teu recall vai falhar no momento em que uma query do utilizador exigir a síntese de dois factos diferentes de dois documentos diferentes. Para correr estes testes na framework, defines um objeto de test case. Este objeto guarda o input do utilizador, o output esperado e uma lista das strings de contexto reais que o teu retriever foi buscar à base de dados. Instancias a métrica específica que queres, como uma métrica de Contextual Recall, e passas-lhe o test case. A framework usa depois um modelo de avaliação nos bastidores para ler as strings, mapear as afirmações, calcular uma penalização por informação em falta ou com mau ranking, e retornar um score numérico final entre zero e um. Avaliar o teu retriever obriga-te a confrontar exatamente o que estás a entregar ao teu modelo de generation. Uma pipeline de RAG de alta performance não despeja simplesmente dados num LLM; ela filtra e faz o ranking desses dados de forma implacável. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 6 de 18. Avaliar uma única resposta de texto é simples, comparas o output final com o input. Mas como avalias um agente autónomo que decide os seus próprios passos, faz loops por múltiplos processos de pensamento e aciona tools externas? Se a resposta final estiver correta, mas o agente deu vinte passos desnecessários e chamou a base de dados errada para lá chegar, o teu sistema está quebrado. Corrigir isto requer Agentic Evaluation. Precisamos de separar uma simples API call de um flow de agente autónomo com múltiplos passos. Uma integração standard de um modelo de linguagem segue um caminho predefinido. Envias um prompt, e o modelo retorna uma string. Um agentic flow transfere o controlo para o modelo. O modelo recebe um objetivo amplo e decide autonomamente quais tools internas usar, em que ordem, e que argumentos lhes passar. Se avaliares um agente olhando apenas para o seu text output final, perdes a verdadeira mecânica do seu raciocínio. O DeepEval resolve isto usando a métrica de Task Completion. Em vez de fazer o parsing da string de resposta final, a métrica de Task Completion analisa o execution trace do agente. Um trace é o registo completo e sequencial de cada pensamento, ação e invocação de tool que o agente fez durante uma run específica. A métrica de Task Completion lê este trace para determinar se o agente realmente cumpriu o request do utilizador através de ações válidas. Considera um agente de planeamento de viagens. Um utilizador pede-lhe para reservar um fim de semana em Roma com reservas para jantar. Para ter sucesso, o agente tem de invocar corretamente uma tool de pesquisa de restaurantes, e depois passar esses dados para uma tool de geração de itinerários. Se o agente der output de um itinerário perfeitamente formatado, mas nunca tiver executado a tool de pesquisa de restaurantes, uma métrica standard de avaliação de texto provavelmente vai aprová-lo. O output parece muito convincente. A métrica de Task Completion vai reprová-lo. Ao analisar o trace, a métrica vê que falta a execução necessária da tool. O agente alucinou os dados do restaurante em vez de os recuperar, e o trace prova isso. Isto move a avaliação do output final para os passos operacionais. Também tens de avaliar se as tools foram usadas corretamente. Os test cases do DeepEval lidam com isto usando um parâmetro chamado tools called. Quando constróis um test case de avaliação, passas a lista de tools que o agente invocou durante a sua execução para este parâmetro tools called. Fornecer estes dados permite à framework avaliar a Tool Correctness. A avaliação verifica se o agente selecionou as tools apropriadas para o objetivo específico, se forneceu os input arguments corretos a essas tools, e se processou com sucesso os dados que as tools devolveram. Se o teu agente de planeamento de viagens decidiu corretamente usar a tool de pesquisa de restaurantes, mas passou a cidade de Paris em vez de Roma como argumento, a avaliação de Tool Correctness apanha o erro no ponto exato da falha. Sabes exatamente que passo quebrou a chain. Aqui está o insight principal. Avaliar agentes significa entrar na black box. Estás a verificar a integridade do processo de raciocínio do agente e as suas ações mecânicas passo a passo. Uma resposta final estruturalmente perfeita é completamente inútil se o agente chegou lá através de tools ignoradas, dados alucinados e lógica quebrada. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 7 de 18. Um chatbot pode dar uma ótima primeira resposta, mas esquecer completamente a intenção do utilizador ou a sua própria persona ao terceiro turn. É por isso que usamos a avaliação de conversas multi-turn. Avaliar respostas isoladas é fácil, mas os utilizadores reais não enviam prompts isolados. Fazem perguntas de seguimento, mudam de ideias e referem-se a coisas que disseram há cinco minutos. Os métodos de avaliação standard falham aqui porque olham para um único input e um único output. Não têm qualquer noção de tempo ou memória. Para testares como um modelo lida com um diálogo contínuo, precisas de uma estrutura que capture a thread inteira. Na framework, lidas com isto usando um objeto específico chamado ConversationalTestCase. Em vez de receber uma string de input e uma string de output, recebe um parâmetro chamado turns. O parâmetro turns é uma lista sequencial. Cada item nesta lista representa uma única troca de mensagens entre o utilizador e o sistema. Ordenas estas trocas desde a primeira até à última mensagem. Envolver a sequência num ConversationalTestCase diz ao motor de avaliação para tratar a lista inteira como uma interação contínua e stateful. Há aqui uma armadilha comum. Não passes um ConversationalTestCase para métricas standard, não conversacionais. As métricas standard são construídas para outputs únicos. Se as usares num objeto multi-turn, vão ignorar completamente o contexto histórico. Tens de usar métricas conversacionais dedicadas para avaliar a lista de turns. As métricas conversacionais avaliam a conversa como um todo. Levam em consideração o contexto anterior para julgar o comportamento sustentado do modelo. Dois exemplos principais são a Role Adherence e a Knowledge Retention. Considera um chatbot de suporte ao cliente que recebe instruções explícitas para agir como um pirata. No turn um, o utilizador diz olá, e o bot responde com calão de pirata. No turn dois, o utilizador faz uma pergunta, e o bot mantém a personagem. Mas no turn três, quando o utilizador pergunta sobre um reembolso, o bot responde com um pedido de desculpas corporativo standard. Abandonou completamente a personagem. Podes detetar esta falha automaticamente usando a métrica de Role Adherence. Defines a persona alvo no setup da métrica, e ela avalia a conversa inteira para verificar se o modelo nunca saiu da personagem, mesmo à medida que o contexto foi crescendo. A Knowledge Retention resolve um problema diferente. Se um utilizador fornecer um número de conta no primeiro turn, e pedir uma atualização de status no quarto turn, o bot não deve pedir o número de conta novamente. A métrica de Knowledge Retention examina a lista de turns para garantir que o modelo recupera e aplica com sucesso os factos introduzidos anteriormente no histórico do chat. Construir isto em código leva apenas alguns passos. Primeiro, crias os teus turns individuais, mapeando o input do utilizador para o output do modelo em cada passo do diálogo. A seguir, passas essa sequência inteira para um novo ConversationalTestCase. Depois, configuras a tua métrica conversacional, atribuindo critérios como a persona esperada. Finalmente, executas a métrica no teu test case. A framework processa o histórico completo e devolve um score com base na interação cumulativa. Aqui está o ponto-chave. A avaliação multi-turn muda o foco dos teus testes, passando de medir a precisão técnica isolada para medir a consistência comportamental sustentada ao longo do tempo. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 8 de 18. Às vezes, as métricas standard não se adequam ao teu use case, como verificar se um chatbot financeiro altamente regulamentado soa profissional o suficiente. Precisas de uma forma de medir características subjetivas de forma fiável, e é exatamente aí que entra criar custom metrics com o G-Eval. Antes de definires custom metrics, estabelece que tipo de lógica estás a medir. O G-Eval foi desenhado exclusivamente para critérios subjetivos, como o tom, a coerência ou o flow da conversa. Se precisares de impor uma lógica objetiva rigorosa, deves usar DAGs. O G-Eval lida com as nuances da linguagem humana. Para construíres uma métrica de Profissionalismo para um chatbot financeiro, não escreves regras de parsing complexas. Usas o G-Eval para definir uma custom metric usando linguagem do dia a dia. Instancias a métrica dando-lhe um nome e uma string de critérios em linguagem natural. Para este chatbot, os teus critérios podem dizer: determina se o output real mantém um tom formal e respeitoso, e evita estritamente gírias ou expressões informais. Aqui está o ponto chave. A métrica não se limita a enviar os teus critérios para um large language model e a pedir um score rápido. O G-Eval corre um algoritmo de Chain of Thought em dois passos. O passo um é a geração. O algoritmo lê os teus critérios em inglês simples e gera automaticamente uma lista estruturada de passos de avaliação. Ele escreve a sua própria rubrica de avaliação. Para a métrica de Profissionalismo, pode gerar um passo para procurar saudações informais, e outro passo para verificar o uso de terminologia financeira apropriada. O passo dois é a avaliação propriamente dita. O algoritmo pega nesses passos gerados e aplica-os aos parâmetros específicos do teu test case. Um test case standard do G-Eval inclui tipicamente o input do utilizador e o output real do teu modelo, mas também podes incluir o expected output ou o retrieval context. O avaliador corre a sua rubrica personalizada contra o texto, calcula um score final entre zero e um, e fornece uma razão detalhada a explicar por que deduziu pontos. Escrever critérios eficazes dita a qualidade da tua métrica. Trata a string de critérios como um prompt altamente restrito. Não escrevas instruções vagas como: verifica se a resposta é boa. Define exatamente o que bom significa. Se o uso de gírias deve resultar num score automático de zero, declara isso explicitamente nos critérios. Os passos de avaliação gerados no passo um são apenas tão precisos quanto as instruções que forneces. Isso cobre interações únicas. As conversas apresentam um desafio diferente. Um chatbot pode começar profissional, mas adotar um tom casual à quarta mensagem. Para lidar com isto, usas o Conversational G-Eval. O Conversational G-Eval aplica exatamente o mesmo algoritmo de dois passos a um chat multi-turn. A diferença é o formato de input. Em vez de avaliar um único input e output real, passas um histórico de conversa inteiro. Este histórico consiste em turnos sequenciais a alternar entre o utilizador e o assistente. A métrica lê o transcript inteiro, gera os seus passos de avaliação com base nos teus critérios personalizados, e dá um score à interação como um todo. Isto garante que o output do modelo se mantém consistente desde a primeira saudação até à despedida final. A eficácia de qualquer custom metric depende inteiramente de tratares os teus critérios como uma especificação rigorosa, onde a clareza supera sempre a brevidade. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 9 de 18. Ao avaliar regras de formatação complexas, um único prompt denso pode facilmente fazer com que o teu LLM avaliador alucine a pontuação. Pode ver as palavras certas no texto, ignorar completamente a ordem estrutural e dar uma nota positiva a um teste que devia falhar. A solução para isto é a avaliação determinística com DAG. DAG significa Directed Acyclic Graph. Neste framework, uma métrica DAG permite-te construir uma árvore de decisão rigorosa que controla como o LLM avalia uma resposta. Em vez de pedires a um modelo para ingerir um texto e pontuá-lo com base num bloco massivo de instruções, divides a lógica em operações granulares, passo a passo. Os dados fluem estritamente numa direção, desde os root nodes no início da tua árvore até aos leaf nodes no final. Para construir esta árvore, dependes de três componentes distintos. O primeiro é o Task Node. Um erro comum é tratá-lo como um avaliador. Não é. Um Task Node simplesmente extrai ou processa dados do input ou da resposta gerada. A seguir, temos o Binary Judgement Node. Este nó recebe os dados processados pelo Task Node e avalia-os de acordo com critérios específicos, devolvendo um sim ou não categórico. Finalmente, existe o Verdict Node. Este atua como um leaf node. Ele termina um ramo da tua árvore de decisão e faz o output de uma pontuação numérica final juntamente com uma justificação por escrito. Vamos aplicar isto a um cenário concreto. Estás a testar um LLM que gera resumos de transcrições de reuniões. O teu requisito rigoroso é que cada resumo tenha exatamente três títulos: Introdução, Desenvolvimento e Conclusão, nessa sequência exata. Começas a tua métrica por criar um root Task Node. Instruis este nó a ler o resumo gerado e a extrair uma lista de todos os títulos que encontrar. Esse é todo o seu trabalho. Ele isola os dados de formatação e passa uma lista de texto simples para o próximo nível da árvore. Agora, passas essa lista para um Binary Judgement Node. Defines os critérios para este nó verificar se a lista contém exatamente três itens. Se o nó avaliar isto como falso, ele encaminha a execução para um Verdict Node. Esse Verdict Node dá imediatamente o teste como falhado, atribui uma pontuação de zero e faz o output de uma justificação a afirmar que a contagem de títulos estava incorreta. Se o Binary Judgement Node avaliar como verdadeiro, a execução passa para um segundo Binary Judgement Node. Este nó recebe a mesma lista extraída e verifica a sequência. Verifica se o primeiro item é Introdução, o segundo é Desenvolvimento e o terceiro é Conclusão. Se isto for verdadeiro, encaminha para um Verdict Node final, atribuindo uma pontuação perfeita. Se for falso, encaminha para um Verdict Node diferente, atribuindo um zero devido a uma falha na ordem. Esta é a parte que importa. Ao separar a extração de informação num Task Node da lógica de avaliação nos Judgement Nodes, forças o LLM a seguir um caminho rígido. O modelo lida com a extração semântica, enquanto o teu grafo garante a execução determinística das regras. Obrigado por ouvirem, bom código a todos!

Olá, daqui é o Alex do DEV STORIES DOT EU. Framework DeepEval, episódio 10 de 18. Testar um language model com cinco prompts manuais é engraçado. Mas quando estás a fazer upgrade para uma nova versão do modelo, esses cinco prompts não te vão dizer se estragaste edge cases em centenas de interações históricas. Para estares production-ready, precisas de um repositório da verdade robusto e com controlo de versões. É isso que o Evaluation Dataset te dá. Um Evaluation Dataset no DeepEval é simplesmente uma coleção estruturada de itens chamados Goldens. Antes de avançarmos, precisamos de esclarecer um equívoco comum. Os developers confundem muitas vezes um Golden com um Test Case. Não são a mesma coisa. Um Golden é a linha bruta do dataset. Contém os teus parâmetros de teste estáticos, como o input do utilizador, o output esperado e o contexto de retrieval. Representa o cenário ideal. Um Golden só se torna num Test Case mais tarde, em runtime, depois de a tua aplicação live processar o input e injetar o seu output real. O Golden é o blueprint, enquanto o Test Case é o resultado executado. Vamos contextualizar isto num cenário específico. Tens um log histórico de 500 queries de suporte ao cliente guardadas num ficheiro CSV. Queres testar rigorosamente uma nova versão do modelo contra este set exato de queries. Não precisas de escrever lógica de parsing customizada. Basta inicializares um Evaluation Dataset e usares o método built-in para adicionar dados de um ficheiro CSV. Passas o caminho do ficheiro e defines um mapping. Dizes ao dataset qual é a coluna do CSV que corresponde ao input do utilizador, qual mapeia para o output esperado e qual contém o contexto. A framework trata do parsing e constrói 500 Goldens em memória. Podes fazer exatamente a mesma coisa com um ficheiro JSON, mapeando as keys do JSON para os campos do Golden. Aqui está a ideia principal. O Evaluation Dataset controla um lifecycle específico que liga os teus dados estáticos à tua pipeline de avaliação dinâmica. Primeiro, carregas e guardas os teus Goldens no dataset. A seguir, durante a tua test run, iteras pelo dataset. Extrais o input de cada Golden, passas isso para o teu language model live e capturas a resposta gerada. Depois, anexas essa resposta live ao Golden e convertes isso num Test Case oficial. Finalmente, passas esse Test Case completo para as tuas métricas para scoring. Isto mantém os teus dados brutos completamente separados da tua lógica de execução. Até agora, descrevemos datasets single-turn. Um input do utilizador, um output esperado. Mas muitas aplicações envolvem interfaces de chat. Para isto, o DeepEval suporta datasets multi-turn. Em vez de uma string de input flat, um dataset multi-turn contém uma sequência de interações. Um único Golden multi-turn guarda todo o histórico da conversa, fazendo o tracking de como o utilizador e o sistema interagem ao longo de vários steps. Isto permite que as tuas métricas avaliem o flow e a retenção de contexto de uma conversa, em vez de isolar uma única resposta isolada. Estruturar os teus dados em Evaluation Datasets formais garante que cada tweak no prompt e swap de modelo seja medido contra um standard histórico rigoroso e invariável. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 11 de 18. O maior bottleneck na avaliação de large language models não é a framework de testes que usas. É a falta de test data de alta qualidade para começar. Gerar dados sintéticos com o DeepEval Synthesizer é a forma de contornares este bloqueio. Imagina uma startup a desenvolver um bot interno de RH. Precisas de correr testes imediatamente para verificar se ele faz o retrieval das políticas certas. Mas o bot é completamente novo. Tens zero logs de queries de utilizadores reais. Este é o clássico problema de cold-start para evaluation data. Não podes avaliar um sistema de retrieval sem uma lista robusta de perguntas realistas para lhe fazer. O DeepEval Synthesizer faz o bootstrap de um dataset de avaliação diretamente da tua knowledge base raw. Em vez de escreveres centenas de test cases à mão, apontas a ferramenta para os teus source documents. O método principal para isto chama-se generate goldens from docs. No DeepEval, um Golden é a terminologia para um único test case que contém um input, um expected output e um context. Para o usares, primeiro inicializas um objeto Synthesizer. A seguir, chamas o método generate goldens from docs e passas-lhe um array com os paths dos documentos. Para o bot de RH, isto seriam os file paths para os teus manuais de funcionário, políticas de férias e PDFs de benefícios. Quando corres este método, o Synthesizer processa os ficheiros e divide o texto em chunks fáceis de gerir. Depois, usa um language model avaliador para agir como um utilizador curioso. O modelo revê um chunk específico do manual de RH e gera uma pergunta relevante e realista baseada puramente nesse texto. Esta pergunta é guardada como o input sintético. O Synthesizer também guarda o chunk de texto exato usado para inspirar a pergunta. Isto torna-se no expected context. Finalmente, o modelo formula a resposta ideal e factual para a pergunta e guarda-a como o expected output. Esta é a parte que interessa. As pessoas muitas vezes interpretam mal os limites da geração sintética. O Synthesizer apenas cria os inputs, o expected context e o expected output. Ele não gera o actual output. Encontrar o actual output é o trabalho da tua própria aplicação de RH durante a fase de testes. Pensa no Synthesizer como um professor a escrever um exame e a criar uma chave de respostas. O teu bot ainda tem de fazer o exame. Podes controlar o scope desta geração. Ao chamar o método, podes especificar quantos test cases gerar por documento. Isto mantém o processo rápido e barato para iterações rápidas, ou podes escalá-lo para uma coverage abrangente. Assim que o método terminar, extrais os goldens gerados e guardas-os. Podes exportar o dataset localmente como um ficheiro JSON, ou fazer push diretamente para a Confident AI para monitorizar as versões do teu dataset ao longo do tempo. Fazer o bootstrap de datasets sintéticos permite-te deixar de esperar que utilizadores reais exponham as falhas no teu sistema, para passares a testar sistematicamente os limites absolutos da lógica dos teus documentos logo no primeiro dia. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 12 de 18. Queries sintéticas básicas geradas a partir dos teus documentos são demasiado fáceis. Os language models modernos passam por perguntas simples sem qualquer esforço, deixando lacunas lógicas perigosas completamente por testar. Para encontrares breaking points reais na tua aplicação, precisas de aumentar artificialmente a dificuldade dos teus dados de teste. Conseguimos isto usando Evolving Synthetic Complexity. A standard generation produz perguntas simples e diretas. A evolução complica matematicamente essas perguntas para fazer um stress-test ao teu sistema. Às vezes, as pessoas confundem isto com a alteração dos factos subjacentes. Evoluir uma query sintética não significa mudar a ground truth. Os dados de origem permanecem exatamente os mesmos. O que muda é a dificuldade estrutural da query que pede informações sobre esses dados. No DeepEval, controlas este processo de mutação usando a Evolution Config. Esta configuração aplica estratégias evolutivas específicas para transformar um prompt básico num edge case multi-constraint. Imagina uma pergunta sintética simples como: qual é a política de devoluções? É direta, mas demasiado genérica para ser um teste rigoroso. A primeira estratégia que podes aplicar é a Concretizing evolution. Esta pega numa query abstrata e força-a para um cenário altamente específico e tangível. Em vez de perguntar pela política geral, o concretizing transforma a query em algo como: se eu comprei uma camisa vermelha na terça-feira, posso devolvê-la na próxima semana? O modelo agora tem de mapear constraints específicas do utilizador para a regra geral. A segunda estratégia é a Reasoning evolution. Esta introduz uma camada necessária de dedução. A pergunta evoluída força o modelo a executar passos lógicos antes de poder fornecer a resposta final. Em vez de apenas fazer o retrieval de um facto, a query pode exigir que o sistema calcule datas, compare valores ou siga uma chain de lógica condicional com base no texto de origem antes de formular a sua resposta. A terceira estratégia é a Multicontext evolution. Esta testa o retrieval e a síntese, forçando o modelo a extrair respostas de pedaços de informação desconexos. Modifica a query para que a resposta não possa ser extraída de um único parágrafo. Para ter sucesso, o language model deve combinar a timeline geral de devoluções de um documento com exclusões específicas de artigos em saldo de uma secção completamente diferente. Quando aplicas mutações artificiais a milhares de queries usando estas estratégias, algumas vão inevitavelmente degradar-se. Uma pergunta evoluída pode tornar-se tão complexa que fica genuinamente impossível de responder, ou pode distanciar-se dos factos originais. Este é exatamente o problema que a Filtration Config resolve. Não podes permitir que ruído insolúvel contamine o teu dataset de avaliação. A Filtration emprega um critic model separado para atuar como um guardião de controlo de qualidade. Revê cada nova query evoluída com base em critérios rigorosos antes de ser guardada. Se uma pergunta mutada estiver logicamente quebrada, já não estiver alinhada com o contexto de origem, ou se degradar para um absurdo, o critic model rejeita-a imediatamente. Este processo em dois passos garante que geres perguntas incrivelmente difíceis, mas ainda totalmente válidas. Uma pontuação alta em dados sintéticos básicos não prova nada sobre a resiliência do teu sistema; a verdadeira fiabilidade de um modelo é medida apenas por como ele lida com os edge cases complexos e intencionalmente evoluídos que a standard generation deixa para trás. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 13 de 18. As avaliações end-to-end dizem-te se um sistema falhou, mas deixam-te a adivinhar o porquê. O tracing ao nível do componente diz-te exatamente que função específica falhou. Hoje, vamos olhar para LLM Tracing e Observability. Considera uma pipeline standard de Retrieval-Augmented Generation. Um utilizador faz uma pergunta complexa, e o teu sistema devolve uma resposta com alucinações dez segundos depois. Precisas de saber exatamente o que correu mal. Será que a função de retrieval de embeddings foi buscar documentos irrelevantes à tua base de dados, ou será que o passo final de geração do language model simplesmente falhou a sintetizar o contexto certo? Não consegues fazer debug disto de forma eficiente apenas a olhar para o output final. Precisas de inspecionar os passos internos. Para fazeres isto, tens de perceber dois termos fundamentais que são frequentemente confundidos: Traces e Spans. Um Trace é a árvore de execução completa de uma única operação. Representa a timeline completa desde o momento em que o utilizador envia um prompt até ao momento em que o sistema entrega a resposta final. Um Span, por outro lado, é um componente ou função específica a operar dentro desse Trace. A execução completa da tua pipeline é um Trace. A função que faz a query à base de dados vetorial é um Span. A função que formata o prompt é outro Span. A chamada em si ao large language model é um terceiro Span. Cada Trace é construído a partir destes Spans aninhados. Cada Span regista o seu próprio tempo de início, tempo de fim, parâmetros de input e resultados de output. No DeepEval, capturas esta hierarquia usando o decorator observe. Basta colocares a palavra observe com um símbolo arroba diretamente acima das funções Python que queres monitorizar. Anexas isso à tua função de entry-point principal, e anexas às funções helper internas, como o teu retriever e o teu generator. Quando a tua aplicação corre, o decorator observe interceta automaticamente a execução. Ele faz log dos argumentos exatos passados para a função e dos dados exatos devolvidos. Também monitoriza a latency e quaisquer erros que ocorram. Mais importante ainda, percebe o contexto de execução. Se a tua função principal da pipeline chamar a tua função retriever, o decorator regista automaticamente o retriever como um child Span do Trace principal. Ele mapeia as relações parent-child das tuas funções sem teres de as ligar manualmente. Aqui está o ponto chave. Fazer tracing desta forma é completamente não intrusivo. Não tens de reescrever a codebase da tua aplicação para gerar telemetry. Não precisas de alterar as signatures das tuas funções para passar trace IDs ou objetos de context pela call stack abaixo. Manténs a tua business logic limpa e apenas fazes wrap aos componentes que te interessam. Ao fazeres isto, isolas os dados de cada passo individual. Se quiseres avaliar apenas a lógica de retrieval mais tarde, os inputs e outputs exatos desse Span específico já estão registados em log. Fazes a avaliação end-to-end para medir a experiência final do utilizador, mas fazes o tracing ao nível do componente para realmente localizar e corrigir o código subjacente. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 14 de 18. Em workflows complexos de agentes autónomos, nem sempre sabes qual deve ser o test case até que o agente comece realmente a executar. Não consegues escrever uma test suite estática e abrangente para decisões intermédias que ainda não foram tomadas. As Dynamic Evals em runtime resolvem esta limitação, permitindo-te construir e avaliar test cases a meio do processo. Normalmente, os developers definem test cases estáticos externamente. Crias um ficheiro com inputs e outputs esperados rígidos, e depois corres a tua aplicação contra eles. Essa abordagem falha quando lidamos com sistemas autónomos. Quando um agente recebe um prompt, pode reencaminhar a query, selecionar uma tool especializada e gerar a sua própria search string interna. Esses inputs e outputs intermédios não existem até que o código esteja realmente a correr. As avaliações dinâmicas abandonam o ficheiro externo. Em vez disso, constroem o test case passo a passo à medida que as variáveis são preenchidas dentro da aplicação ativa. Considera um cenário específico. Precisas de avaliar a precisão do contexto dentro de uma função retriever profundamente aninhada. Queres testar apenas esse passo específico a meio da execução, isolado do output final que o utilizador vê. Para isso, o DeepEval fornece duas funções específicas para intercetar dados de execução: update current span e update current trace. Um trace regista todo o ciclo de vida de um request, desde o input inicial do utilizador até à resposta final. Um span representa uma operação específica dentro desse trace, como a tua função retriever. Quando essa função retriever é executada, as variáveis dinâmicas finalmente materializam-se. Agora tens a search string exata que o agente gerou e os chunks de texto específicos que a tua base de dados devolveu. Nesse exato momento, dentro da lógica do retriever, chamas o update current span. Usas esta função para intercetar essas variáveis em tempo real e mapeá-las diretamente para um novo test case. Pegas na search string intercetada e atribuis como input de teste. Pegas nos chunks brutos da base de dados e atribuis-os como contexto de retrieval. Acabaste de construir um golden test case durante a execução. Como construíste este golden dinamicamente dentro do span, podes avaliá-lo imediatamente. Aplicas a tua métrica de precisão de contexto ali mesmo. A métrica corre contra os dados em tempo real, pontua o passo do retriever e anexa essa pontuação diretamente ao span local. Quando revires os teus traces mais tarde, não vês apenas que ocorreu um retrieval. Vês uma avaliação altamente direcionada desse retrieval específico, com base nas condições exatas dessa run. Isto cobre passos granulares. Às vezes, no entanto, uma operação aninhada descobre algo que altera o contexto de todo o request. É aqui que o update current trace se torna necessário. Enquanto o update current span modifica o passo local, o update current trace permite que uma função profundamente aninhada suba e modifique o registo de execução global. Se o teu agente descobrir informações a meio do processo que alterem completamente o aspeto que a resposta final deveria ter, chamas o update current trace para atualizar o output esperado para toda a run. Isto mantém a avaliação global alinhada com a realidade dinâmica e em tempo real da lógica de execução. Aqui está a ideia principal. Mover as avaliações de ficheiros externos para a árvore de execução em runtime transforma o testing de um exercício post-mortem num mecanismo de diagnóstico em tempo real. Ao vincular métricas diretamente aos spans à medida que executam, paras de tentar adivinhar por que um agente multi-step falhou e começas a medir exatamente qual handoff interno causou a falha. Obrigado por ouvirem, e happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 15 de 18. O teu LLM pode responder perfeitamente a todas as perguntas normais. Mas o que acontece quando um utilizador malicioso tenta ativamente fazer um jailbreak à tua aplicação para fazer leak de dados sensíveis? Isso exige uma abordagem completamente diferente, o que nos leva a uma Introdução ao Red Teaming. Para perceberes o red teaming, tens de mudar a forma como olhas para o teu sistema. A avaliação standard testa a funcionalidade. Mede se o teu modelo é útil, preciso e relevante quando usado corretamente. O red teaming testa a segurança, a proteção e as guardrails. Exige uma mudança de mentalidade, passando da verificação de correção para a simulação de agentes maliciosos. Estás ativamente a tentar fazer o modelo falhar. Pensa num cenário comum. Se pedires diretamente à tua aplicação de IA para fazer output de um perfil de utilizador, as guardrails standard provavelmente vão detetar isso. A IA recusa-se estritamente a fazer leak de Personal Identifiable Information, ou PII. Uma avaliação standard marca isto como um sucesso. Mas um agente malicioso não vai pedir diretamente. Podem fazer um prompt ao modelo usando uma persona específica e maliciosa, instruindo a IA a agir como um administrador de base de dados sénior a executar um override de emergência ao sistema. De repente, a IA obedece e faz leak da PII de livre vontade. O red teaming é o processo sistemático de descobrir exatamente estes pontos cegos antes de chegarem a produção. O DeepEval estrutura este processo em torno de quatro componentes principais. O primeiro componente são as Vulnerabilidades. Uma vulnerabilidade é a fraqueza, o risco ou o dano específico que estás a testar. É o problema subjacente que queres prevenir. No nosso cenário de override de emergência, a vulnerabilidade é o leak de PII. Outras vulnerabilidades podem incluir a geração de output tóxico, a exibição de bias não autorizado, ou a oferta de conselhos perigosos. O segundo componente são os Adversarial Attacks. Se a vulnerabilidade é o alvo, o ataque é a arma. Os ataques são as técnicas ou meios específicos usados para explorar uma vulnerabilidade. Adotar uma persona de confiança para enganar a IA é um tipo de ataque. Outros incluem prompt injection, onde instruções maliciosas são escondidas em input normal, ou jailbreaks complexos desenhados para contornar completamente o treino de segurança do modelo. O DeepEval separa a fraqueza da tática porque uma única vulnerabilidade pode ser exposta por muitos tipos diferentes de ataques. O terceiro componente é o Target LLM System. Esta é a aplicação real que estás a avaliar. Não é apenas o foundation model puro, mas a tua arquitetura específica. Isto inclui os teus system prompts personalizados, os teus mecanismos de retrieval, e quaisquer filtros de segurança existentes. Os adversarial attacks são executados diretamente contra este setup para ver como o teu produto real se comporta sob pressão. O quarto componente são as Metrics. Assim que um ataque é executado contra o teu target system para procurar uma vulnerabilidade, precisas de um resultado quantificável. As metrics avaliam a resposta do sistema. Elas determinam se o ataque conseguiu contornar as guardrails com sucesso, ou se o sistema recusou o pedido malicioso em segurança. Uma metric pontua a interação, dando-te um pass ou fail concreto com base no quão seguro o output realmente foi. Aqui está o insight principal. Não podes proteger uma aplicação de IA apenas por provares que ela faz a coisa certa quando lhe pedem educadamente; tens de provar sistematicamente que ela se recusa a fazer a coisa errada quando está sob ataque. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 16 de 18. Não devias ter de escrever manualmente milhares de inputs enganadores para encontrar falhas de segurança na tua aplicação. Em vez de pagares a uma equipa de segurança para tentar quebrar o teu sistema manualmente durante semanas, podes deixar uma IA atacar a tua IA de forma autónoma. Hoje, vamos analisar a Execução de Ataques Adversários. Para orquestrar um ataque automatizado LLM-on-LLM, o scanning engine precisa de uma linha de comunicação direta com a tua aplicação. Estabeleces esta ligação definindo um target model callback. Esta é uma função Python assíncrona que tu escreves. Recebe um único argumento de string, que é o adversarial prompt gerado pelo testing engine, e deve devolver a resposta em string do teu sistema. Num cenário típico com um modelo da OpenAI, definias esta função de callback async, pegavas no parâmetro de prompt recebido, passavas isso para o teu cliente da OpenAI, fazias o await da geração e devolvias o conteúdo de texto final. Este callback funciona como a ponte. O red teaming engine não precisa de conhecer a tua arquitetura interna, chaves de API ou o estado da base de dados. Só precisa de uma função que possa chamar continuamente com inputs maliciosos. Assim que o teu callback estiver pronto, passas o mesmo para a red team function. Este é o orquestrador principal que executa o scan. Para o configurar, forneces duas listas distintas: vulnerabilidades e ataques. É crucial perceber a diferença entre elas. Vulnerabilidades são as falhas estruturais específicas ou comportamentos prejudiciais que queres testar. Por exemplo, se quiseres garantir que a tua aplicação não produz preconceito racial ou de género, importas e passas a vulnerabilidade Bias para a red team function. Ataques, por outro lado, representam a metodologia que o engine vai usar para tentar expor essa vulnerabilidade. Para forçar o modelo a fazer uma declaração tendenciosa, podes querer que o engine use frases enganadoras ou técnicas de jailbreak. Fazes isso ao passar o ataque de Prompt Injection. O engine vai agora gerar de forma autónoma prompts maliciosos direcionados usando prompt injection, especificamente desenhados para contornar os teus system prompts e acionar a vulnerabilidade Bias. Um ponto comum de confusão durante este setup é como os resultados são realmente avaliados. Na avaliação standard, gastas muito tempo a definir e a afinar métricas específicas. Ao executar ataques adversários, não definas métricas manualmente. A framework trata disso completamente nos bastidores. Mapeia automaticamente a vulnerabilidade que selecionaste diretamente para uma métrica de avaliação interna correspondente. Como lhe disseste para testar o Bias, o engine corre automaticamente um bias evaluator contra cada resposta que o teu target model callback devolve. Após a red team function terminar de disparar estes prompts gerados e de avaliar as respostas, produz um Risk Assessment abrangente. Esta avaliação fornece uma análise clara do scan. Mostra exatamente quantos ataques foram tentados, quais as técnicas de ataque específicas que comprometeram o teu sistema com sucesso, e as input strings exatas que causaram a falha. Ficas com uma lista concreta de inputs com os quais o teu sistema atualmente não consegue lidar. Aqui está o insight principal. O verdadeiro poder deste setup é desacoplar o método de ataque da vulnerabilidade alvo, permitindo-te multiplicar a tua cobertura de segurança ao combinar uma única falha, como o bias, com dezenas de vetores de ataque diferentes em simultâneo. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. DeepEval Framework, episódio 17 de 18. Tu nunca farias merge de um pull request de código tradicional sem correr os teus unit tests primeiro. No entanto, as equipas fazem frequentemente deploy de modelos de linguagem não determinísticos e simplesmente esperam que os novos prompts continuem a funcionar. Se queres evitar que más atualizações do modelo quebrem a produção, precisas de CI/CD e Continuous Evaluation. O DeepEval trata as avaliações de modelos de linguagem exatamente como testes de software normais, integrando-se diretamente com o Pytest. Defines uma função de teste, inicializas as tuas métricas de avaliação e fazes um assert para garantir que a métrica passa. Avaliar um modelo com um único input é inútil, por isso precisas de validar as alterações contra um grande batch de inputs de referência aprovados e os respetivos outputs esperados. Este é o teu golden dataset. Para iterar por este dataset de forma eficiente, usas o decorator mark parametrize standard do Pytest. Carregas o teu dataset, extrais os test cases individuais e passas tudo para o decorator. Quando a test suite corre, o Pytest gera dinamicamente uma execução de teste separada para cada item do teu golden dataset. Aqui está o insight principal. Como a framework se integra tão bem com o Pytest, os developers assumem frequentemente que podem simplesmente correr comandos standard do Pytest no seu terminal. Não faças isso. Se correres o Pytest diretamente contra os teus ficheiros de avaliação, vais deparar-te com erros inesperados relacionados com event loops assíncronos e falta de telemetry das métricas. Deves usar sempre a command line interface dedicada. O comando correto é deepeval test run seguido do nome do teu ficheiro Python. Este wrapper lida com o setup assíncrono complexo exigido pelos modelos de linguagem e garante que todos os resultados dos testes são capturados e registados em log corretamente. Integrar este comando no teu deployment pipeline dá-te continuous evaluation. Considera um setup típico de GitHub Actions. Configuras o workflow para fazer trigger sempre que um engenheiro abre um pull request para a main branch. O action runner faz checkout do repository, faz o setup do ambiente Python e corre o deepeval test run contra o script do teu golden dataset. A framework avalia o código ou prompt recém-modificado contra todos os test cases históricos. Se um developer alterar um system prompt para tornar as respostas mais concisas, pode acidentalmente instruir o modelo a remover avisos de compliance obrigatórios. Quando o CI pipeline corre, a avaliação automatizada deteta esta falta de contexto imediatamente. Se a nova lógica fizer com que o teu evaluation score caia abaixo do threshold definido em qualquer test case, o assert falha. O script devolve um exit code diferente de zero, a GitHub Action fica imediatamente vermelha e o pull request é bloqueado de fazer merge. Este check automatizado de pre-deployment atua como um gatekeeper rigoroso. Apanha regressões automaticamente. Já não precisas de fazer spot-check manual aos outputs, nem de esperar que os utilizadores se queixem de que uma troca de modelo partiu um edge case específico. O pipeline prova matematicamente se é seguro fazer deploy da atualização, removendo completamente a subjetividade humana do processo de release. Continuous evaluation significa que paras de tratar a prompt engineering como uma aposta operacional e começas a tratá-la como uma software release previsível, apoiada em dados concretos. Obrigado por ouvires, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Framework DeepEval, episódio 18 de 18. Passas horas a afinar um prompt localmente, obténs um excelente score de avaliação e fazes deploy do código. Duas semanas depois, outro engenheiro atualiza o modelo subjacente e, de repente, a aplicação falha em edge cases que ninguém monitorizou. Correr avaliações localmente é apenas metade da batalha. Este episódio aborda como escalar os teus testes e fazer track de regressões ao longo do tempo com o Confident AI. Primeiro, uma distinção necessária. O DeepEval é a framework open-source que corres no teu terminal ou ambiente Python para correr testes. O Confident AI é a plataforma cloud alojada, construída em cima dela. Usas o DeepEval para definir as tuas métricas e correr as avaliações propriamente ditas. Usas o Confident AI para centralizar, fazer track e analisar esses relatórios de avaliação em toda a organização de engenharia. Ele pega em scripts locais isolados e transforma-os num sistema de registo colaborativo. Passar da execução local para o logging na cloud requer um passo simples. No teu terminal, corres o comando deepeval login. A CLI vai pedir-te para fornecer uma API key gerada a partir do teu workspace do Confident AI. Após a autenticação, o teu workflow diário permanece exatamente o mesmo. Corres os teus ficheiros de teste usando o comando de teste standard. A framework deteta automaticamente a sessão ativa e faz stream dos resultados diretamente para o dashboard na cloud, enquanto continua a imprimi-los localmente. Centralizar os relatórios permite fazer track de regressões de forma metódica. Uma regressão acontece quando uma alteração no teu código ou configuração degrada inadvertidamente a performance do sistema. Para diagnosticar a causa de uma regressão, precisas de fazer track exatamente do que mudou entre os test runs. Isto é feito através do logging de hyperparameters. No contexto de avaliações de modelos de linguagem, um hyperparameter é qualquer variável que altera o comportamento da tua pipeline. Isto inclui a arquitetura do modelo, a configuração de temperature, o chunk size usado para retrieval, ou até mesmo a versão específica do prompt template. Quando configuras o DeepEval para fazer log destes hyperparameters, eles são anexados a cada test run enviado para o Confident AI. Considera uma equipa a tentar atualizar a sua aplicação. Eles querem saber se a troca do GPT-4o para o Claude 3.5 Sonnet realmente melhora o score geral da pipeline. Eles configuram o nome do modelo como um hyperparameter monitorizado. Quando o engenheiro corre a evaluation suite usando o novo modelo, o Confident AI faz log do novo nome do modelo juntamente com os scores resultantes para métricas como contextual precision ou factual consistency. Aqui está o ponto-chave. Como todos os test runs históricos são guardados na cloud, a equipa pode visualizar uma timeline a comparar as alterações exatas de hyperparameters com os scores de avaliação agregados. Se a mudança para o novo modelo aumentar a answer relevancy, mas reduzir drasticamente a factual consistency, o dashboard destaca esta regressão instantaneamente. Todos na equipa veem os mesmos dados. Nunca precisas de fazer parse de outputs antigos da consola ou confiar na memória para decidir se uma alteração de configuração foi um sucesso. A avaliação contínua requer uma baseline histórica. Sem um sistema centralizado que vincule as tuas configurações diretamente aos teus scores de avaliação, estás simplesmente a correr experiências isoladas, não a construir um sistema fiável. Isto conclui a nossa série sobre a framework DeepEval. Recomendo vivamente que explores a documentação oficial e tentes construir estas avaliações hands-on. Se tiveres tópicos técnicos que gostasses de ver abordados numa futura série, visita devstories dot eu para deixares a tua sugestão. Obrigado por ouvires, happy coding a todos!