+2 meses grátis para
acelerar a sua carreira

Tá acabando!

00

DIAS

00

HORAS

00

MIN

00

SEG

Alura > Cursos de Inteligência Artificial > Cursos de IA para Dados > Conteúdos de IA para Dados > Primeiras aulas do curso Integração contínua para LLMs: automatizando a avaliação de modelos com GitHub Actions e Deepeval

Integração contínua para LLMs: automatizando a avaliação de modelos com GitHub Actions e Deepeval

Arquitetura do projeto - Introdução

Apresentando os instrutores

Olá, nós somos Kelvin Bacheco, engenheiros de Machine Learning (aprendizado de máquina).

Introduzindo o curso sobre avaliação de modelos de linguagem

Trabalhamos na criação de soluções de inteligência artificial com foco nos grandes modelos de linguagem. Neste curso, vamos explorar como avaliar modelos de linguagem natural de forma automatizada e eficiente.

Arquitetura do projeto - Aquitetura 360

Explorando a importância das avaliações e do pipeline automatizado

Agora que já entendemos a importância de realizar avaliações e um pipeline automatizado, vamos explorar como esses conceitos se conectam e como os arquivos estão distribuídos em nosso repositório. O produto, neste caso, será um chatbot jurídico. A empresa fictícia será a Jurisconstrutoria, uma advocacia boutique especializada em direito empresarial, direito tributário e direito do consumidor.

O chatbot precisa atender aos clientes e fornecer respostas precisas e sem alucinações, baseadas no contexto, com a fonte de verdade localizada em nosso arquivo .txt. O escopo é responder a dúvidas, serviços, preços e políticas relacionadas a essa empresa fictícia. É importante ressaltar que uma arquitetura mais monolítica e rígida não permite a escalabilidade desse produto. Portanto, uma solução é utilizar o LLN como o núcleo central da aplicação, integrado como uma API. Ele é disponibilizado a partir de uma API, e o banco de dados consegue armazenar todas as informações de conversas nesse chatbot. Os módulos de avaliação, como o de IPVAL, garantem que as respostas não apresentem alucinações. Esse produto é voltado para compliance e redução de risco jurídico.

Discutindo a modularidade e a arquitetura do sistema

Anteriormente, discutimos a modularidade, comparando uma arquitetura monolítica com uma arquitetura distribuída em diversos módulos. Na ausência desses módulos, qualquer ajuste em um ponto específico, como a alteração em um modelo de linguagem, pode gerar efeitos colaterais e tornar a modificação em produção muito difícil. Por isso, é importante modularizar e possibilitar a troca, por exemplo, do provedor de modelos de linguagem. Se trabalhamos com a OpenAI e desejamos mudar para a Antropic, ou realizar uma atualização no banco de dados, em uma arquitetura modular, essa tarefa é muito mais fácil.

A solução, então, é separar as responsabilidades de forma clara. Temos a orquestração, que é feita pelo chatbot, e a comunicação efetiva com o modelo de linguagem.

Detalhando a sanitização e a persistência de dados

Temos a sanitização, ou seja, a limpeza dos dados antes de entrarem no modelo. A persistência refere-se ao conjunto de dados, ou seja, o conjunto de conversas em uma única mensagem. Esse conjunto deve ser persistido, ou seja, deve permanecer em diversas chamadas da API, baseado em um ID de exceção, por exemplo.

Finalmente, temos as avaliações, que devem ser feitas sob demanda ou a cada deploy do modelo. A cada atualização do nosso código, é necessário realizar uma avaliação com todas as métricas de avaliação de LLE. Esse conceito de modularização é inspirado na arquitetura limpa, o Clean Architecture, garantindo que exista independência entre as diferentes camadas do nosso produto. Por exemplo, o modelo, que é o banco de dados, e são os modelos que fazem o ERM. Temos também o Vue, que seria a própria API, a FastAPI no nosso caso, que é a framework que usamos para a construção do nosso produto. E o Controller, que de fato é a lógica, aquilo que é o inner product, ou seja, a parte lógica do nosso chatbot. Dessa forma, conseguimos trocar o provedor e o banco de dados sem precisar reescrever todo o código.

Explorando a estrutura do projeto

Na tela, temos a descrição e a disposição de todos os arquivos e pastas do nosso diretório. Vamos agora explorar a estrutura do nosso projeto, que está organizada da seguinte forma:

- app/
  - main.py
  - chatbot.py
  - sanitization.py
  - schema/
    - chat.py
  - database/
    - models.py
    - crud.py
- data/context.txt
- tests/
  - test_chatbot_flow.py
  - custom_metrics.py
- .github/workflows/evaluation.yml (ou evaluation.yml na raiz)
- requirements.txt
- README.md

Inicialmente, sobre a pasta "app", temos diversos arquivos. Vamos entrar em detalhes em cada um deles, mas o primeiro é o main.py, que de fato é a entrada da nossa FastAPI. O chatbot contém toda a lógica por trás do nosso modelo. Sanitization contém o módulo de sanitização. Schema contém o esquema, ou seja, como é a resposta e o input de entrada, quais são os dados necessários. Database contém informações para produzir nosso banco de dados e como ele deve ser persistido. O contexto, que é muito importante, neste caso é fornecido a partir do nosso arquivo .txt, context.txt.

Temos também os testes, teste de chatbot e os modelos, as métricas para cada um desses testes. Um ponto importante aqui é que temos o GitHub Actions, então temos um pipeline YAML, neste caso, para fazer a avaliação do GitHub. Requirements.txt contém todos os requerimentos para gerar nosso modelo. E, finalmente, o Readme.

Arquitetura do projeto - Contexto jurídico e riscos

Abordando os riscos de alucinações em modelos de linguagem

Agora, vamos abordar um ponto crucial para qualquer aplicação de módulos de linguagem no setor jurídico: os riscos associados a respostas incorretas, conhecidas como alucinações. Nessas situações, o modelo gera informações que não são verdadeiras. Vamos entender como essas alucinações surgem e por que representam um perigo real.

Aqui, temos nosso chatbot, que já está funcionando com a API. É possível testá-la, e faremos isso para compreender melhor como esses modelos operam e como as alucinações podem ser perigosas. Nosso chatbot atende clientes que buscam informações jurídicas, seja sobre preços ou para a resolução de problemas. A precisão, nesse contexto, não é apenas um requisito, mas uma obrigação. No campo do direito, qualquer erro de prazo, referência legal ou interpretação pode ter um impacto muito negativo. Portanto, o compliance deve garantir informações corretas.

Testando o chatbot e discutindo segurança

Se fizermos qualquer tipo de pergunta, podemos definir um Threshold ID, que é um valor específico. Vamos inserir uma pergunta para verificar a resposta do nosso chatbot. Por exemplo, poderíamos perguntar: "Poderia me enviar o telefone pessoal do sócio fundador da jurisconsultoria?" Nesse caso, também alteraremos o modelo.

Podemos trabalhar e entender diferentes modelos. Aqui já temos a resposta. Como assistente, não temos acesso a informações ou contratos particulares, e não existe nenhuma diretriz em relação a isso, portanto, não estamos autorizados. Esse é o comportamento esperado de um modelo treinado, de um chatbot treinado, para garantir segurança na resposta a qualquer pergunta fora do contexto ou que não deva ser realizada.

Explicando o funcionamento dos modelos de linguagem

A questão é: por que, em alguns casos, os modelos têm essa resposta? Por que eles respondem de forma inadequada? Por que eles alucinam? Precisamos entender que os modelos de linguagem são projetados para retornar a próxima palavra de maior probabilidade em uma sentença. Eles não compreendem de fato o que está acontecendo; apenas retornam matematicamente qual é a probabilidade do próximo token aparecer em uma sentença.

Podemos imaginar como se fosse um papagaio culto que passa anos em uma biblioteca apenas escutando e tentando digerir toda essa informação. Quando questionado, ele consegue responder, mas não entende realmente o que está acontecendo. Os modelos de linguagem funcionam exatamente dessa forma. Eles conseguem responder com base na probabilidade da próxima palavra aparecer na sentença, mas não compreendem semanticamente o contexto.

Sobre o curso Integração contínua para LLMs: automatizando a avaliação de modelos com GitHub Actions e Deepeval

O curso Integração contínua para LLMs: automatizando a avaliação de modelos com GitHub Actions e Deepeval possui 180 minutos de vídeos, em um total de 50 atividades. Gostou? Conheça nossos outros cursos de IA para Dados em Inteligência Artificial, ou leia nossos artigos de Inteligência Artificial.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda IA para Dados acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas