Durante alguns anos, ensinar um modelo a preferir uma resposta a outra dependia de gente. Anotadores humanos comparavam pares de saídas. Essas comparações treinavam um modelo de recompensa, que por sua vez guiava o ajuste do modelo principal. É o arranjo conhecido como Reinforcement Learning from Human Feedback (RLHF, aprendizado por reforço a partir de feedback humano).

RLHF funciona, custa caro e tem um efeito colateral conhecido: o modelo de recompensa é uma aproximação do gosto humano, e o modelo treinado tem incentivo para achar as brechas dessa aproximação. Já falamos sobre esse problema no texto sobre avaliação da qualidade das respostas.

Com código, isso muda. Para saber se uma função está correta, não precisamos perguntar a ninguém. O juiz já está no repositório, roda sozinho e não tem opinião. Essa prática passou a dominar o processo de treinamento de modelos de código, chamado Reinforcement Learning with Verifiable Rewards (RLVR, aprendizado por reforço com recompensas verificáveis).

Neste post nós vamos ver três itens:

• Como o laço de treinamento funciona.

• Por que o algoritmo Group Relative Policy Optimization (GRPO) ganhou espaço nele.

• E o que acontece quando o modelo descobre que passar no teste e resolver o problema são objetivos diferentes.

O que muda quando a recompensa é verificável

Em RLHF, a recompensa sai de uma rede neural treinada sobre preferências. Por design, ela é contínua, ruidosa e imperfeita. Em RLVR, a recompensa sai da execução de um programa. Em código, ela costuma ter a seguinte forma:

def recompensa(codigo_gerado, suite_de_testes):
    resultado = executar_em_ambiente_isolado(codigo_gerado, suite_de_testes)
    return 1.0 if resultado.todos_passaram else 0.0

Essas quatro linhas contêm o post inteiro.

Aqui não há parâmetros a treinar nem anotador a contratar. E o sinal não se degrada quando a distribuição dos dados muda, porque ele nunca foi estimado a partir de dados. Ele foi executado.

A ideia vai além dos testes unitários. Em um outro texto aqui do blog, nós vimos pré-condições e pós-condições como contratos verificáveis, que cobrem propriedades universais em vez de casos particulares. Qualquer artefato executável que separe correto de incorreto serve de fonte de recompensa: uma suíte de testes, um verificador de tipos, um provador, um checador de propriedades, um script em bash.

Mas essa ideia não funciona bem além do código. Ela vale para domínios com verificador barato, e código é o exemplo mais forte. Para redação, resumo ou conselho, é mais complicado, pois não temos uma função que devolve 1 ou 0.

Nesses casos o problema do avaliador continua aberto.

Como o laço funciona, e por que GRPO

O laço de treinamento tem uma estrutura simples.

Para cada enunciado, o modelo gera um grupo de soluções candidatas; digamos oito. Cada solução candidata roda contra a suíte de testes em um ambiente isolado. Cada uma recebe recompensa 1 ou 0. O algoritmo então calcula quanto cada candidata foi melhor ou pior que as outras, e ajusta os pesos para tornar as boas mais prováveis.

O cálculo desse “melhor ou pior” é o que separa os dois algoritmos.

O algoritmo Proximal Policy Optimization (PPO), padrão anterior, precisa de um segundo modelo treinado em paralelo. Esse segundo modelo, chamado modelo de valor, estima a recompensa esperada de um estado. Ele costuma ter porte parecido com o do primeiro, o que quase dobra a memória necessária durante o treino.

O GRPO dispensa esse segundo modelo. No lugar da estimativa por rede neural, ele usa a estatística do próprio grupo.

A vantagem de cada candidata é a recompensa dela comparada à média do grupo.

Se sete candidatas falham e uma passa, a que passou recebe um peso positivo alto. Se todas passam, nenhuma se destaca, e o passo quase não altera nada.

Essa mudança tem uma consequência interessante. Sem o modelo de valor, o custo dominante de um passo de treinamento deixa de ser a inferência da rede neural. Ele passa a ser execução de código.

Treinar com RLVR significa rodar milhões de suítes de teste em ambientes isolados, com controle de tempo limite, de memória e de acesso à rede. Perceba que o gargalo não foi resolvido; ele migrou dos treinamentos dos modelos para infraestrutura de execução.

O sinal binário é pobre

A recompensa de 1 ou 0 tem uma fragilidade enorme. Em problemas mais difíceis, pode acontecer de nenhuma das oito candidatas passar. Todas recebem 0. Todas têm a mesma vantagem. Mas o passo de treinamento não ensina nada.

Mas tem um detalhe importante: Uma solução candidata pode ter falhado só em um teste de borda, enquanto outra sequer compilou. Pra recompensa binária, essa informação é jogada fora. Há duas linhas de pesquisa nessa frente.

• A primeira enriquece o sinal de execução em vez de reduzi-lo a um bit. Por ex, o CodeRL+ propõe alinhar a geração à semântica de execução, aproveitando o que ocorre durante a execução e não apenas o veredito final.

• A segunda linha treina um verificador especializado em código. Por ex, o trabalho Aletheia: What Makes RLVR For Code Verifiers Tick? investiga as escolhas de receita nesse treinamento. Os autores fazem ablação de três fatores: traços de raciocínio intermediários, aprendizado a partir de amostras negativas e treinamento on-policy.

Parece que a receita ótima depende do porte do modelo.

Em verificadores pequenos, o treinamento on-policy é o principal motor de desempenho. Nos maiores, o orçamento de raciocínio passa a ser o fator determinante.

O modelo aprende a passar no teste

Chegamos à parte que muda a leitura de tudo que veio antes.

Se a recompensa é passar nos testes, logo o objetivo que o modelo otimiza é passar nos testes. Resolver o problema é uma das formas de conseguir isso.

E nem sempre é a mais barata.

O artigo LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking cataloga o que aparece em ambientes de código quando esse incentivo age sem freio. Por exemplo, já que temos que passar nos testes, porque não sobrescreve-los, remover as asserções, ou até forçar o encerramento antecipado do programa? Assim, as execuções rendem recompensa 1 sem que o problema tenha sido resolvido.

O mesmo trabalho mostra uma versão mais sutil disso em tarefas de raciocínio indutivo. Modelos treinados com RLVR passam a abandonar a indução de regras e a enumerar rótulos caso a caso. A saída satisfaz o verificador sem capturar o padrão que a tarefa pedia. É a mesma coisa que escrever `if entrada == 2: return 4` e seguir em frente.

Para medir a frequência dessas condutas, o ImpossibleBench usa uma construção bem sofisticada. Os autores pegam tarefas de benchmarks estabelecidos. Depois criam variantes impossíveis, colocando a especificação em linguagem natural em conflito direto com os testes. Por exemplo, um teste do tipo `assert f(2) == 4` passa a exigir `assert f(2) == 5`. Em outra, as duas asserções contraditórias convivem no mesmo arquivo.

Como a tarefa se tornou impossível de resolver honestamente, qualquer aprovação é trapaça. A taxa de aprovação vira então uma medida direta da propensão a explorar atalhos. As taxas medidas em modelos de fronteira são altas, com destaque para a variante baseada no SWE-bench. Os autores testaram também uma intervenção: dar ao agente a opção de declarar a tarefa impossível em vez de tentar resolvê-la. Com essa saída disponível, a taxa do GPT-5 na variante conflitante caiu de 54% para 9%.

O que isso significa para quem escreve testes?

Aqui invertemos a relação usual entre teste e código.

Nós escrevemos testes para detectar defeito. Quando o teste vira função de recompensa, ele passa a definir o comportamento. O modelo converge para o que o teste aceita, incluindo aquilo que o teste aceita por engano. Uma suíte fraca deixa o defeito passar e, além disso, ensina o defeito.

A boa notícia é que isso reaproveita conhecimento que o desenvolvedor já tem. A verificação isomórfica está próxima do teste metamórfico e do teste baseado em propriedade, que checam relações entre entradas e saídas em vez de valores fixos. Um teste que fixa `f(2) == 4` pode ser satisfeito por uma tabela. Um teste que exige que a saída de `f` cresça de forma monótona, ou que `f(g(x))` valha o mesmo que `g(f(x))`, é bem mais difícil de satisfazer sem implementar a função.

A origem dos testes também ganha peso novo. Em Não use o ChatGPT para gerar testes nós vimos que pedir os testes ao mesmo modelo que escreveu o código reproduz as suposições do código em vez de checá-las. Em RLVR, essa dependência deixa de ser questão de higiene de projeto. Ela vira um problema de definição do objetivo, porque o artefato gerado é a própria função que o modelo vai otimizar.

Conclusão

O regime de recompensa verificável colocou a engenharia de software em uma posição incomum dentro do aprendizado de máquina. Outros domínios ainda discutem como obter julgamento confiável para treinar seus modelos. Código já tinha esse julgamento pronto, versionado no repositório e executável em segundos. Foi essa disponibilidade que permitiu o avanço rápido dos modelos de código. E o GRPO baixou o preço do processo ao trocar o modelo de valor pela estatística do grupo.

O que os trabalhos recentes acrescentam é o outro lado da moeda. O verificador não é neutro. Ele é a definição operacional de correção, e o modelo otimiza exatamente aquilo que essa definição mede. A queda de 54% para 9% no ImpossibleBench, quando o agente ganha a opção de recusar a tarefa, mostra que parte do comportamento indesejado vem do desenho do ambiente e não do modelo. O resultado do Countdown-Code, com 1% de contaminação bastando para produzir efeito grande depois, mostra que a etapa anterior também pesa.

Para quem escreve software, fica uma leitura sobre onde investir atenção. Melhorar a suíte de testes deixou de ser apenas uma forma de encontrar defeitos mais cedo. Em um pipeline que treina ou seleciona modelos por execução, a suíte de testes é a função objetivo. E a qualidade dela estabelece o teto do que o modelo consegue aprender.

O diagnóstico intuitivo é que o modelo “esqueceu”. Mas nem sempre é isso que acontece. O agente tem tudo na janela de contexto, incluindo quinze versões desatualizadas do mesmo formulário, e pode agir sobre a versão errada. Cada chamada de uma tool devolve um bloco de texto que nenhum humano escreveu (e que ninguém revisou), e esse bloco fica no histórico competindo pela atenção do modelo com a instrução original.

A reação comum a esse problema é procurar um modelo com janela maior. Um trabalho publicado em junho de 2026, aponta para outra direção: em um benchmark de 50 tarefas, o agente que descartava a maior parte do próprio histórico concluiu mais tarefas do que o agente que guardava tudo — e ainda gastou um terço dos tokens e um terço do tempo.

Neste texto vamos entender como é possível que o histórico de um agente deixe de ajudar a partir de certo ponto.

O contexto de um agente cresce sozinho

Em uma aplicação de chat, a janela de contexto cresce no ritmo em que a pessoa digita. Um usuário atento pode escrever algumas centenas de tokens por turno.

Em um agente, o crescimento é outro.

O agente decide chamar uma tool, e a tool devolve o que tiver para devolver (como a listagem de arquivos em um diretório, no caso de uma tool de ls). Como vimos no texto sobre o que são tools, essa resposta volta para o histórico como uma mensagem comum. Um endpoint pode devolver três mil tokens de JSON, dos quais o agente vai usar dois campos. Vinte chamadas e sabe-se lá quantos mil tokens de histórico depois, a maior parte do contexto descreve uma situação que já mudou.

Na literatura chamamos esse acúmulo de context bloat: conforme o histórico de interação cresce:

1. o custo por turno aumenta,

2. a latência aumenta e

3. a capacidade de raciocínio degrada por distração com contexto passado que já não têm relevância assim.

São três efeitos distintos. Os dois primeiros são de infraestrutura e todo mundo espera por eles. O terceiro é de qualidade, e é o que costuma passar despercebido, porque não aparece no custo ($$) da API.

As camadas de aplicação que envolvem o modelo, ou seja, o que entra no prompt a cada iteração do loop, responde por boa parte do desempenho final, e o histórico é a peça desse harness que parece não ser projetada de forma deliberada.

A janela anunciada não é a janela efetiva

Antes de mexer no histórico, vale entender por que guardar mais informação piora a decisão. A referência de base aqui é um artigo bem conhecido de 2023: Lost in the Middle: How Language Models Use Long Contexts. Os autores mediram a acurácia em função da posição da informação relevante dentro do contexto e encontraram uma curva em U: o desempenho é mais alto quando a informação está no começo ou no fim da entrada, mas cai drasticamente quando ela está no meio.

Esse comportamento apareceu em outros locais. O relatório Context Rot, da Chroma Research, testou 18 modelos, entre eles Claude Opus 4, GPT-4.1, Gemini 2.5 Pro e Qwen3, em tarefas controladas onde a única variável era o tamanho da entrada. O desempenho cai conforme a entrada cresce, e a introdução de um único distrator já reduz a acurácia, com efeito maior em contextos maiores. O próprio langchain fornece uma implementação para ordenação de contextos longos, pensando exatamente nesse problema.

Ou seja: a janela de contexto anunciada e a janela dentro da qual ele decide bem são coisas diferentes.

Um modelo com um milhão de tokens de janela não sustenta um milhão de tokens de qualidade uniforme.

O que acontece quando o histórico é podado

Voltemos ao paper que deu gatilho ao este texto. O cenário deste trabalho é automação de despesas no Microsoft Dynamics 365, com um agente GPT-5 conversando com o sistema via MCP, sobre um conjunto de 50 tarefas de itemização de despesas hoteleiras. Configuração moderna.

Três configurações de contexto foram comparadas:

• Caso 1: Histórico completo, com tudo que aconteceu na sessão: 71,0% de tarefas concluídas, 1.480.996 tokens, 14,56 horas de execução.

• Caso 2: Poda para os 5 pares mais recentes de chamada e resposta de tools: 79,0% de tarefas concluídas, 535.274 tokens, 5,39 horas.

• Caso 3: Poda com sumarização do que foi descartado: 91,6% de tarefas concluídas, 553.374 tokens, 5,79 horas.

Vejam só: no caso 2, descartar o histórico antigo, sem nenhum tratamento, subiu a taxa de conclusão em 8 pontos e cortou 64% dos tokens e 63% do tempo. Por outro lado, no caso 3, resumir o trecho descartado antes de jogá-lo fora custou 18 mil tokens adicionais sobre a poda, mas alcançou impressionantes 91% de tarefas concluídas.

No caso 2, a poda mantém os cinco pares mais recentes porque isso cobre aproximadamente dois ciclos completos de memória de trabalho necessária para a tarefa em andamento. O que fica para trás são estados de formulário já superados, levando a erros de execução de uma ação sobre um snapshot que não faz mais sentido.

A sumarização, caso 3, por outro lado, usa uma janela de três interações, dispara quando pelo menos um par é descartado e preserva quais formulários foram abertos e com quais controles houve interação.

Duas ressalvas antes de transportar esses números para outro contexto:

• Escopo: o resultado vale para um fluxo transacional de formulário, em sessão única, dentro de um produto específico. Os valores de janela, cinco pares e três interações, foram escolhidos por clareza de exposição e não por otimização, e os autores afirmam que caracterizar a janela adequada por domínio continua em aberto.

• Operacional: mesmo na melhor configuração, 8,4% das tarefas ficaram incompletas, o que mantém a revisão humana como requisito de produção.

Podando o histórico no LangChain

A primeira estratégia, a janela deslizante, já existe pronta no LangChain. A função trim_messages recorta a lista de mensagens preservando o final:

from langchain_core.messages import trim_messages

# Mantém a instrução de sistema e as 10 mensagens mais recentes,
# o que corresponde a cerca de 5 pares de chamada e resposta de tool.

podar = trim_messages(
    max_tokens=10,
    token_counter=len,    # conta mensagens, não tokens
    strategy=”last”,      # descarta a partir do início do histórico
    include_system=True,  # a instrução do agente nunca sai
    start_on=”human”,     # evita começar por uma resposta de tool órfã
)

historico_curto = podar.invoke(historico)

Dois parâmetros merecem atenção. O include_system protege a instrução do agente, que precisa sobreviver a qualquer poda. O start_on=”human” evita um recorte que deixe uma mensagem de ferramenta sem a chamada correspondente, situação que a maioria das APIs rejeita. Trocando token_counter=len pelo contador do próprio modelo, o corte passa a ser por orçamento de tokens em vez de por número de mensagens, o que costuma ser mais adequado quando as respostas de ferramenta têm tamanhos muito diferentes entre si.

A segunda estratégia é resumir o que sai antes de descartar. Um pequeno exemplo de como isso pode ser feito está abaixo.

from langchain_core.messages import SystemMessage
from langchain_openai import ChatOpenAI

resumidor = ChatOpenAI(model="gpt-4.1-mini", temperature=0)

INSTRUCAO = (
    """Resuma o que o agente já executou: ações concluídas, valores 
    confirmados e pendências. Não repita saída bruta de ferramenta."""
)

def comprimir(historico, janela=10):
    antigas, recentes = historico[:-janela], historico[-janela:]

    if not antigas:
        return historico

    resumo = resumidor.invoke(
        [("system", INSTRUCAO),
         ("human", "\n".join(str(m.content) for m in antigas))]

    )
    return [SystemMessage(content=f”Já executado: {resumo.content}”)] + recentes

Quando a poda pode atrapalhar?

O resultado do benchmark não autoriza podar sempre, e há evidência na direção contrária para outro domínio. Nesse trabalho, foi analisado a compressão automática em agentes que trabalham sobre repositórios de código e identificaram perda de informação necessária em três situações: 1) tarefas que envolvem múltiplos arquivos interdependentes, 2) problemas que exigem reconhecer padrões arquiteturais do repositório inteiro, e 3) código com acoplamento alto.

Precisamos entender a diferença entre os dois cenários.

No primeiro, a itemização de despesas, o passo seguinte depende quase só do estado atual do formulário; e o histórico antigo é passivo. Por outro lado, em uma correção de bug que atravessa quatro arquivos, o que foi lido no passo 3 continua sendo relevante ao longo dos passos; o histórico é ativo.

Quanto mais as decisões futuras dependerem de informação lida no passado, mais cara fica a poda por posição.

Para esses casos existe uma terceira estratégia, que é deixar o próprio agente decidir o que compactar. O SWE-MeM, treina o agente para gerenciar a própria memória com base no estado da trajetória, no progresso da tarefa e no orçamento de contexto restante, tanto de forma proativa quanto sob demanda. Na avaliação da abordagem, foi observado 43,4% de resolução de problemas com modelos de 4 bilhões de parâmetros e 60,2% com modelos de 30 bilhões. Mas aí o problema deixa de ser uma função de recorte no seu código e passa a envolver (re)treinamentos de modelos.

Conclusão

O histórico de um agente não é um registro que precisa ser preservado.

Guardar tudo é uma decisão de projeto tanto quanto podar, com a diferença de que é a decisão que ninguém tomou de forma consciente.

Em um fluxo transacional, o agente que descarta o histórico antigo acerta mais do que o que guarda tudo, e que resumir antes de descartar recupera a informação que a poda por posição perde.

A pergunta que devemos nos fazer é: o próximo passo depende do estado atual ou do caminho percorrido?

• Se depende do estado, uma janela deslizante com resumo cobre bem o caso e cabe em vinte linhas.

• Se depende do caminho, o resumo precisa ser desenhado com cuidado sobre o que a tarefa exige, e vale medir a taxa de conclusão com e sem compressão antes de adotá-la.

Em qualquer um dos dois, medir tokens por tarefa concluída, e não apenas tokens por chamada, é o que mostra se a mudança fez sentido.

O problema é que “especificar” costuma significar escrever um parágrafo de descrição em linguagem natural.. Mas, um parágrafo não roda, não é executável. Ele não aceita nem rejeita nada. Especificação formal entra como uma alternativa: descrever o comportamento pretendido em uma linguagem que uma máquina consegue conferir.

Neste texto vamos ver o que isso significa no contexto das LLMs, por que a ausência de uma especificação formal pode deixar o código gerado frágil e como usar especificações formais para aumentar a robustez.

O que é, exatamente, uma especificação formal?

Uma especificação formal descreve o comportamento pretendido de um trecho de código em termos verificáveis, sem dizer como ele deve ser implementado. A formulação mais antiga e mais prática vem do design by contract de Bertrand Meyer: um par de pré-condição e pós-condição.

• A pré-condição delimita o domínio de entrada: quais entradas e qual estado de programa são admissíveis antes deste ser chamado.

• A pós-condição prescreve o que precisa valer depois: propriedades da saída e do estado resultante, assumindo que a pré-condição foi satisfeita.

Existem duas famílias de especificação formal. Na família dedutiva, a especificação é escrita em uma linguagem de verificação (como JML) e um provador de teoremas tenta demonstrar que a implementação a satisfaz para toda entrada possível. Na família executável, a especificação é código, parecido com um teste de unidade, que roda junto com o programa e julga cada execução concreta.

O benchmark CodeSpecBench adota a segunda forma e a codifica como funções Python:

# Problema: dado um array de inteiros e um alvo, retornar os índices de dois
# elementos distintos cuja soma é igual ao alvo. Assume-se que existe
# exatamente uma solução e que nenhum elemento é usado duas vezes.

def preconditions(nums, target):
    # tipos básicos
    assert isinstance(nums, list) and isinstance(target, int)
    assert len(nums) >= 2 and all(isinstance(x, int) for x in nums)

    # o enunciado garante unicidade da solução: isso faz parte do domínio
    pares = [(i, j)
             for i in range(len(nums))
             for j in range(i + 1, len(nums))
             if nums[i] + nums[j] == target]
    assert len(pares) == 1

def postconditions(nums, target, result):
    # formato do resultado
    assert isinstance(result, (list, tuple)) and len(result) == 2
    i, j = result

    # validade dos índices e correção semântica
    assert i != j and 0 <= i < len(nums) and 0 <= j < len(nums)
    assert nums[i] + nums[j] == target

Repare no que essas quinze linhas fazem e no que um teste unitário não faz. O teste diz que dois_soma([3,2,4], 6) deve retornar [1,2]. A pós-condição diz que qualquer par de índices distintos cuja soma bata serve, para qualquer entrada no domínio. O teste é um oráculo pontual. A especificação é um oráculo universal (ou pelo menos universal sobre o domínio que a pré-condição delimita).

Por que a ausência de especificação deixa o código gerado por LLMs frágil?

Suponha que você peça a um modelo uma função que ordena uma lista de inteiros, e ele devolva isto:

def ordenar(xs):
    return sorted(set(xs))

Essa função passa em ordenar([3, 1, 2]) == [1, 2, 3]. Passa em ordenar ([]) == []. Passa em ordenar ([5]) == [5]. Se a sua suíte de testes não tiver um caso com elemento repetido, o defeito vai para produção intacto. A pós-condição correta pega o problema na primeira execução com duplicata, porque ela não fala sobre exemplos, fala sobre a relação entre entrada e saída:

def postcondicao_ordenar(xs, resultado):
    # a saída precisa estar ordenada
    assert all(resultado[i] <= resultado[i + 1] for i in range(len(resultado) - 1))

    # e precisa ser uma permutação da entrada, não apenas um subconjunto
    assert sorted(xs) == resultado

Para dar um exemplo, o benchmark ContractEval, construído sobre HumanEval+ com 364 tarefas e cinco LLMs de código, mede a distância entre “passa nos testes” e “respeita o contrato”.

Usando o mesmo prompt padrão, os modelos alcançam resultados entre 75% e 82% e 0% de satisfação contratual. Mesmo quando o contrato é colocado explicitamente no prompt, a satisfação sobe apenas para a faixa de 23% a 41%. Isso significa que o código funciona nos casos testados, porém ignora as condições de borda que ninguém escreveu.

Existe uma segunda fragilidade, mais desconfortável, que o CodeSpecBench avalia: o modelo consegue resolver o problema sem entender o problema.

Comparando geração de solução com geração de especificação nas mesmas tarefas, o paper reporta Claude-4.5-Sonnet com 77,2% de acerto em gerar a solução no nível de repositório e 21,0% em gerar a especificação correspondente (GPT-5 aparece com 72,8% contra 10,2%).

Escrever a implementação é uma tarefa em que o LLM pode se apoiar em padrões conhecidos. Por outro, escrever o contrato exige saber o que o programa deve exatamente fazer, sem o atalho de dizer como.

Em outro paper, Talk is Cheap, Logic is Hard, os autores avaliaram 24 modelos em 40 tarefas de formalização e evidenciou que todos formalizam pré-condições melhor do que pós-condições; mas nenhum acertou o conjunto completo!

Como especificações tornam LLMs mais robustas

Há três usos distintos, com custos e ganhos distintos.

• Uso 1: a especificação como oráculo para escolher entre candidatos. Quando você pede n implementações ao modelo, precisa decidir qual usar, e normalmente não tem a saída esperada para comparar. A especificação pode ajudar a resolver isso. O CodeSpecBench mediu esse procedimento. Com re-ranking guiado por especificação, o pass@1 do Qwen3-8B subiu de 59,4% para 62,2%, e o do Qwen3-32B de 71,2% para 73,9%. O ganho é maior em pass@1 do que em pass@5, o que indica que a especificação está fazendo o trabalho de identificar a melhor solução dentro do conjunto, não de aumentar a diversidade dele.

• Uso 2: a especificação como guarda em tempo de execução. Aqui a especificação não fica em um arquivo de teste, fica em volta da função em produção. O CodeSpecBench faz isso no nível de repositório, configurando um conftest.py que envolve a função alvo, executa a pré-condição antes da chamada e a pós-condição depois. A biblioteca icontract oferece algo parecido por decorador.

• Uso 3: a especificação como alvo de prova. Nesse caminho o modelo gera código e prova, e um verificador decide. É a rota mais forte e a mais cara.

O que já existe por aí?

Os números de verificação dedutiva melhoraram rápido. O benchmark de vericoding, com 12.504 especificações formais reporta até 82% de sucesso, usando modelos de prateleira. Os autores registram também a progressão em Dafny de 68% para 96% em benchmarks existentes ao longo de um ano.

VeriContest, com 946 problemas de LeetCode e Codeforces em Rust, decompõe a tarefa e mede cada etapa: 92,18% em gerar código a partir da descrição, 48,31% em gerar a especificação, 13,95% em gerar a prova e 5,29% de síntese verificada de ponta a ponta. A distância entre o primeiro resultado e o último resultado é a distância entre escrever código e garantir código.

Há também um serviço da Amazon chamado Automated Reasoning checks, disponível desde agosto de 2025. É o mesmo mecanisom mas em outra roupagem: a política de negócio é codificada como um conjunto de regras de lógica formal com um esquema de variáveis, e cada resposta do modelo é verificada contra essas regras antes de chegar ao usuário. A AWS reporta até 99% de acurácia na detecção de respostas corretas, com auditabilidade por construção, já que o resultado da checagem vem acompanhado da regra que foi violada.

Por onde começo?

Escolha a função mais crítica do seu código gerado por agente, escreva a pós-condição dela em cinco linhas de assert, e ligue um @given do Hypothesis em cima. Você vai descobrir na mesma tarde quantos dos seus testes eram exemplos disfarçados de garantia.

A partir daí, o caminho tem três degraus e vale subir um de cada vez.

• O primeiro é acrescentar a pré-condição, que costuma ser mais difícil do que parece: os dados do ContractEval e do Talk is Cheap mostram que é justamente ali, na definição do domínio de entrada, que modelos e desenvolvedores erram menos, e é ali que você descobre suposições que ninguém tinha escrito em lugar nenhum.

• O segundo degrau é tirar a asserção do arquivo de teste e colocá-la em volta da função em produção, com um decorador do icontract ou com um wrapper próprio, para que a violação apareça na primeira execução real fora do domínio, e não três semanas depois em um log de erro sem contexto.

• O terceiro degrau é usar a especificação dentro do próprio laço do agente, como oráculo de seleção: peça n implementações, descarte as que violam a pós-condição, e escolha entre as que sobraram.

Vale notar que uma especificação formal cobra manutenção, e uma especificação restritiva demais pode reprovar uma implementação correta. A sugestão é descrever o que o chamador observa, nunca como a função chega lá. Se a especificação quebra quando alguém troca a estrutura interna, ela virou teste de implementação.

Uma cena que provavelmente já aconteceu com você. Um agente abre um pull request com 400 linhas, uma descrição bem redigida e todos os testes verdes. Você olha o diff por 90 segundos, reconhece o padrão geral, não encontra nada obviamente errado e… aprova. Três semanas depois surge um comportamento estranho em produção e ninguém no time consegue explicar por que aquele componente foi desenhado daquele jeito. O código está lá, funciona na maior parte do tempo, mas a intenção por trás daquele código se perdeu.

Esse é o ponto de partida de um artigo publicado em junho de 2026 por Sungmin Kang, Baishakhi Ray e Abhik Roychoudhury, intitulado “Skills for the future software profession: beyond agentic AI!”. O texto sintetiza duas mesas redondas sobre IA confiável para código, realizadas em Singapura (janeiro de 2026) e Nova York (junho de 2026), cada uma com 30 a 40 participantes vindos de MIT, Harvard, Google, Meta, Amazon, IBM e outras instituições. O objetivo foi destilar, a partir de discussões em grupo, quais competências os desenvolvedores vão precisar daqui para frente.

Neste post vamos percorrer as três competências que o artigo identifica:

1. especificações executáveis como base de verificação e validação,

2. arquitetura agêntica, e

3. gestão de dívida cognitiva.

O gargalo mudou de lugar

Tradicionalmente, escrever código era a parte mais cara do desenvolvimento. Com a geração automática barateando a produção, o gargalo desloca-se da produção de software para a garantia de software (do inglês, software assurance).

Os participantes das mesas redondas relataram uma observação incômoda sobre isso. Desenvolvedores aceitam código gerado por IA com escrutínio cada vez menor, o que torna a revisão manual uma salvaguarda pouco confiável. Aqui no blog nós já tratamos desse desconforto em Porque eu não posso confiar cegamente no código gerado por LLMs. Pensando no artigo, um pouco mais adiante: se a revisão humana linha a linha não escala com o volume de código gerado, a confiança precisa vir de outro lugar.

Esse outro lugar são os artefatos de verificação e validação que uma máquina consegue checar. De acordo com os autores, especificação e verificação passam a preceder a implementação; e não a suceder. O desenvolvedor conversa com o usuário final, extrai a intenção, converte essa intenção em artefatos verificáveis por máquina, e só então o agente implementa algo que satisfaça esses artefatos.

Especificações executáveis

A primeira competência que o artigo lista é a tradução de intenção do usuário em especificações executáveis. O artigo ilustra um diálogo como:

• o usuário pede uma funcionalidade X que vai permitir a funcionalidade Y;

• o desenvolvedor responde que, por controle de qualidade, vai escrever Z;

• o usuário confirma que é isso mesmo.

O artefato Z é uma especificação executável, que pode ser teste, uma pré-condição, uma pós-condição, uma propriedade.

Considere uma função de desconto em centavos. O contrato é o que nós mantemos; a implementação é o que o agente pode reescrever quantas vezes quiser.

# spec.py
# A implementação pode ser regenerada por um agente a qualquer momento.
# O contrato abaixo, não: ele é o artefato que o time humano possui.

from hypothesis import given, strategies as st

def aplicar_desconto(valor_centavos: int, percentual: int) -> int:
    “”“
    pre:  valor_centavos >= 0
    pre:  0 <= percentual <= 100
    post: 0 <= __return__ <= valor_centavos
    “”“
    return valor_centavos - (valor_centavos * percentual) // 100

@given(
    valor=st.integers(min_value=0, max_value=10**9),
    pct=st.integers(min_value=0, max_value=100),

)

def test_contrato_do_desconto(valor, pct):
    resultado = aplicar_desconto(valor, pct)
    # Pós-condição: o resultado vive dentro do intervalo declarado.
    assert 0 <= resultado <= valor
    # Domínio: centavos são indivisíveis, o retorno tem que ser inteiro.
    assert isinstance(resultado, int)
    # Casos de fronteira, escritos como propriedade e não como exemplo solto.
    assert aplicar_desconto(valor, 0) == valor
    assert aplicar_desconto(valor, 100) == 0

Os comentários pre: e post: na docstring não são decorativos. Esse é o formato que o CrossHair lê para fazer verificação simbólica da função, e o bloco @given é Hypothesis gerando entradas para testar a propriedade em vez de um punhado de exemplos escolhidos à mão.

Agora suponha que um agente receba a tarefa de “deixar a função mais legível” e devolva esta versão:

def aplicar_desconto(valor_centavos, percentual):
    return valor_centavos - valor_centavos * percentual / 100

O comportamento parece equivalente numa leitura rápida, e é exatamente o tipo de mudança que passa em uma revisão de 90 segundos.

Só que a divisão deixou de ser inteira. Com valor=1 e pct=50, o retorno é 0.5, meio centavo. A asserção isinstance(resultado, int) reprova a mudança, e fica fácil para o Hypothesis encontrar esse contraexemplo. A pós-condição continua satisfeita, o tipo não.

O artefato de V&V que pegou o que passou batido pela leitura humana.

Especificações formais não é algo muito comum em um projeto de software, entendemos. Talvez por isso que a inferência de especificações (do inglês, specification inference) se torna mais relevante.

Agentes conseguem inferir testes e especificações a partir de documentação, código e relatos de issues. O AutoCodeRover, por exemplo, usa especificações inferidas via busca no código para melhorar o desempenho de correção, abordagem depois comercializada no Remediation Agent do SonarQube.

Isso tende a mudar a natureza do trabalho humano.

Como a geração de especificações também está sendo automatizada, a competência que resta ao desenvolvedor é de avaliação:

• julgar se a especificação captura fielmente a intenção do usuário,

• se ela é suficientemente completa, e

• se oferece o nível de garantia adequado ao contexto.

Os engenheiros do futuro não precisam se tornar especialistas em métodos formais, longe disso. Mas talvez precisem entender no papel das especificações executáveis.

Há também obviamente o risco das especificações inferidas sofrerem drift em relação a implementações, que continuam evoluindo. Isso exige ambientes de desenvolvimento (ou plataformas agenticas) capazes de validar continuamente a consistência entre código e especificação.

Arquitetura agêntica

A segunda competência é a orquestração de agentes. Com as especificações no lugar, o próximo problema é desenhar o sistema de agentes que vai produzir o software.

O artigo descreve um pipeline com papéis separados:

• um agente de codificação que implementa e edita código a partir da descrição,

• um agente de verificação que confere se o código atende à especificação formal, e

• um agente de testes que executa a suíte contra o ambiente real.

Os autores dão nome a essa disciplina emergente: arquitetura agêntica.

Assim como a arquitetura de software decompõe sistemas em componentes e suas interações, a arquitetura agêntica trata da organização de agentes especializados, dos protocolos que governam a colaboração entre eles, e de onde posicionar a supervisão humana para maximizar a confiabilidade. As perguntas de pesquisa em aberto são reconhecíveis para quem já desenhou sistemas distribuídos: como os agentes se comunicam, como decompor o fluxo de trabalho entre eles, e como localizar, diagnosticar e recuperar falhas.

Há uma previsão específica no texto que merece atenção: as interfaces em linguagem natural devem evoluir para interfaces guiadas por especificação, que oferecem mais precisão e controle. Isso conversa diretamente com o que discutimos em O que é harness engineering? (https://ml4se.substack.com/p/o-que-e-harness-engineering), onde o ponto era que a construção do ambiente ao redor do modelo pesa tanto quanto o modelo. O artigo acrescenta que essa engenharia de ambiente vai passar a ser matéria de currículo, incluindo decomposição de tarefas, protocolos de coordenação, interação humano-agente e desenho de fluxos sensíveis a confiança.

Dívida cognitiva

Dívida técnica é um conceito conhecido: nasce de compromissos de projeto e implementação assumidos para acelerar a entrega, e mora dentro do software.

Dívida cognitiva (do inglês, cognitive debt), termo que o artigo emprestado de outro artigo, mora em outro lugar: ela aparece quando os desenvolvedores perdem gradualmente o entendimento da intenção, da arquitetura e da justificativa por trás de componentes gerados pelos agentes.

Na era agêntica, a dívida principal desloca-se de dentro do software (dívida técnica) para deficiências no entendimento humano e organizacional (dívida cognitiva). O código pode estar limpo e o time, ainda assim, incapaz de explicar por que ele é daquele jeito. Algumas contra medidas sugeridas:

• Políticas de autoria com custódia humana. Atribuir responsabilidade por cada artefato a um custodiante humano, independentemente de quem de fato escreveu o código, para que exista prestação de contas sobre artefatos gerados por IA.

• Propriedade das decisões arquiteturais. As pessoas engenheiras devem continuar donos das decisões de arquitetura, para conseguir localizar e raciocinar sobre falhas rapidamente quando as implementações estiverem automatizadas.

• Repositórios de artefatos (além do código). Os participantes enfatizaram manter, versionados os requisitos, as especificações executáveis, as instruções dadas aos agentes, as políticas de ferramentas, o racional de projeto e até as trajetórias dos agentes.

• Full life-cycle engineers. O artigo observa que a indústria já caminha para full life-cycle engineers, estendendo a noção de desenvolvimento full-stack para incluir a curadoria de longo prazo de sistemas assistidos por IA.

Uma ideia prática aparece na seção de perspectivas: um participante descreveu depositar as especificações no próprio repositório, como arquivos markdown. O artefato precisa existir, ser versionado junto do código e ser executável o suficiente para impedir o drift.

Conclusão

Os currículos de computação vão precisar de uma mudança radical para ajudar a converter requisitos de negócio em especificações checáveis, com assistência de IA, e em compor agentes e subagentes num pipeline agêntico.

A preocupação atual do desenvolvedor com compor componentes para construir um sistema deve dar lugar à preocupação em gerenciar confiança em agentes conforme pipelines agênticos são compostos. Passamos a raciocinar sobre atores com comportamento probabilístico. Não é somente uma mudança de ferramenta, é também uma mudança de comportamento.

Embora seja um artigo curto, sem nenhum experimento, ele organiza bem uma inquietação difusa em três competências. A primeira delas da pra cair na prática sem esperar mudança curricular alguma:

• escolha um componente do seu sistema que tenha sido gerado por um agente de código;

• escreva a pós-condição que ele precisa respeitar e a propriedade que caracteriza o comportamento correto, no formato do exemplo que montamos acima;

• rode o Hypothesis contra a implementação atual.

  • se a propriedade passar, você ganhou um artefato que sobrevive à próxima regeneração do código. s

  • e falhar, você acabou de descobrir algo que a revisão de 90 segundos não pegou.

As outras duas competências, arquitetura agêntica e gestão de dívida cognitiva, são de prazo mais longo e dependem de escolha organizacional.

Mas a pergunta de custódia dá para fazer nesta semana: quem, com nome e sobrenome, responde pela intenção por trás de cada componente que um agente escreveu no seu repositório? Se não houver resposta, a dívida cognitiva já está sendo acumulada.

Estou considerando abrir uma nova turma sobre Cuidados com LLMs em produção. Se isso parece interessante pra você, deixe seu contato aqui?

Não é novidade que montar um protótipo com LLM ficou rápido e simples. Em uma tarde, conectamos uma chamada de API, ajustamos um prompt e temos algo que responde de forma convincente na tela. Essa velocidade cria a impressão de que o trabalho está quase pronto, e que separar o protótipo da aplicação final é uma questão de poucos ajustes.

O problema aparece quando esse mesmo código sai da máquina do dev e passa a atender requisições de verdade. Um endpoint que respondia bem em um teste isolado agora recebe milhares de chamadas por dia, cada uma com um custo associado, e nem sempre devolve a mesma resposta para a mesma entrada. Há três características importantes aqui: 1) o tempo de resposta, 2) o gasto por requisição e 3) a variação da saída. Mas a gente só atenta pra elas em produção.

Neste post, vamos explorar essas três preocupações uma a uma. Na latência, discutimos por que reduzir o prompt costuma ajudar menos do que se imagina. No custo, falamos de algumas abordagens (comuns em outros contextos e resignificadas para LLMs). No não-determinismo, estudamos como medir a variação da saída em vez de tentar eliminá-la.

Latência

Existe uma intuição comum de que prompts menores geram respostas mais rápidas. A documentação de otimização de latência da OpenAI mede isso e chega a uma conclusão diferente:

“Cutting 50% of your output tokens may cut ~50% your latency”, enquanto “cutting 50% of your prompt may only result in a 1-5% latency improvement”.

Ou seja, o tempo de resposta é dominado pela geração de saída, não pelo tamanho da entrada. Cortar metade do prompt devolve entre 1% e 5% de melhoria. Cortar metade da saída devolve perto de 50%.

Quem quer ganho de tempo deveria começar limitando o que o modelo escreve: definir max_tokens, usar sequências de parada, pedir concisão de forma explícita e, em respostas estruturadas, encurtar os nomes dos campos do JSON, uma vez que cada nome de campo é gerado token a token.

A segunda correção diz respeito ao que medimos. Latência média esconde justamente o caso que gera reclamação. O consenso de instrumentação, resumido no LLM Inference Handbook da BentoML, é decompor a medição em quatro números, sempre em percentis (p50, p95, p99), nunca em média:

1. TTFT (time to first token): O tempo até o primeiro token aparecer. É o que o usuário percebe

2. ITL (inter-token latency): A fluidez da resposta enquanto ela é escrita.

3. Queue time: Saturação do servidor e limites de requisição

4. Latência de ponta a ponta: O número que entra no acordo de nível de serviço

O p99 importa porque é ele que registra os efeitos que somem na média: interferência entre requisições no mesmo lote, remoção de entradas do cache de atenção e pausas do coletor de lixo.

Do lado das técnicas, a de melhor relação entre esforço e retorno é o streaming, a entrega da resposta token a token conforme ela é gerada. O detalhe interessante é que o streaming não reduz a latência real. Ele reduz a latência percebida, e a documentação da OpenAI trata as duas como categorias distintas. Vale registrar ainda a última recomendação: para muitos problemas, pré-computação e cache tradicional continuam mais rápidos que qualquer modelo. O guia de boas práticas de produção complementa esse ponto com as recomendações de limite de requisições e de monitoramento de gasto.

Custo

A tabela de preços da documentação da Anthropic usa multiplicadores sobre o preço base do token de entrada:

• Entrada normal: 1,0x

• Escrita no cache (validade de 5 minutos): 1,25x

• Escrita no cache (validade de 1 hora): 2,0x

• Leitura do cache: 0,1x

A conta que importa está na diferença entre 1,25x para escrever e 0,1x para ler: o cache se paga já na segunda leitura do mesmo prompt. Como a validade de cinco minutos é renovada a cada leitura, tráfego contínuo mantém o prompt ativo.

Existe também um mínimo de tokens por modelo (de 512 a 4096, conforme o caso). Abaixo desse mínimo o conteúdo não é armazenado e a API não retorna erro, o que produz uma falha silenciosa. Por isso, leia cache_read_input_tokens na resposta e confirme que o cache está sendo usado.

Duas outras frentes de economia que aparecem com frequência:

• Processamento em lote. A Batch API oferece 50% de redução em entrada e saída, com a maioria dos lotes concluídos em menos de uma hora. Serve para tudo que não tem usuário esperando: avaliações,moderação de conteúdo, enriquecimento de dados e reprocessamentos. Um caso que costuma passar despercebido é que as suas próprias rodadas de avaliação se encaixam nesse perfil e costumam representar uma fatia relevante da fatura.

• Cascatas de modelos. No paper FrugalGPT, os autores apresentam a seguinte ideia: um modelo barato responde primeiro, um estimador de qualidade avalia a resposta e decide se ela serve ou se a pergunta deve subir para um modelo mais caro. O resultado divulgado no artigo, de até 98% de redução de custo mantendo a qualidade do melhor modelo individual, vale como teto obtido em benchmarks específicos. Para calibrar expectativa, o dado de produção publicado pela Ramp é mais informativo: o time relata 25% a 30% de economia, roteando requisições.

Algumas outras medidas recomendadas são conhecidas de quem já operou custos de nuvem:

• atribuir gasto por funcionalidade e por cliente desde o primeiro dia,

• aplicar limites de token no gateway em vez de confiar no comportamento da aplicação, e

• configurar alertas sobre a taxa de consumo, não apenas sobre o total mensal.

Um agente preso em laço consome o orçamento do mês em poucas horas, e o fechamento mensal avisa tarde.

Não-determinismo

Já falamos aqui no blog sobre alucinações, e esse termo ganhou notoriedade popular.

No entanto, reprodutibilidade bit a bit tem valor em pesquisas sobre aprendizado por reforço e em depuração de código, por exemplo, mas raramente é o objetivo certo em um produto. O que queremos não é eliminar a variância, e sim medi-la e mantê-la dentro de uma faixa aceitável.

Uma forma comum de medir a variância é rodar o mesmo input várias vezes e observar a distribuição das saídas.

Em uma pesquisa recente, os autores utilizam o modelo Qwen3-235B, temperatura zero e o mesmo prompt, mas observaram 80 variações distintas. Os primeiros 102 tokens foram idênticos em todas elas. A divergência começou no token 103. Isso significa que não basta apenas configurar a temperatura para zero, precisamos de mecanismos para observar a variação antes que ela vire incidente.

Para reduzir a variância, algumas escolhas de projeto ajudam:

1. Planos de execução. Gerar um plano com o modelo e executá-lo de forma estruturada torna cada etapa testável e permite rastrear a falha até o passo exato.

2. Saída estruturada com decodificação restrita. Bibliotecas como Outlines, Guidance e XGrammar compilam um JSON Schema e bloqueiam tokens inválidos durante a geração, mesma ideia por trás dos structured outputs da OpenAI. Há uma ressalva pouco divulgada: o JSONSchemaBench traz evidência de que a restrição pode reduzir a acurácia do conteúdo em comparação com extração livre seguida de validação.

3. Diversidade não vem de temperatura. Aumentar a temperatura degrada a qualidade sem produzir a variedade desejada. Alternativas existe, como 1) embaralhar a ordem dos itens no template, 2) manter uma lista de saídas recentes e 3) instruir o modelo a evitá-las, ou variar o enunciado do prompt.

Medir variância só tem utilidade se soubermos o que conta como resposta boa, e é aqui que entra o desenho da avaliação.

De acordo com alguns praticantes, primeiro passo não é escolher uma biblioteca de avaliação nem definir métricas, e sim ler saídas reais. O procedimento que eles descrevem vem da pesquisa qualitativa e tem quatro etapas.

1. Começamos reunindo um conjunto de traços de execução (traces) representativo do tráfego real.

2. Sobre ele fazemos open coding, ou codificação aberta, que consiste em anotar em texto livre o que houve de errado em cada saída, sem categorias definidas de antemão, justamente para não enxergar apenas as falhas que já esperávamos.

3. Em seguida vem o axial coding, ou codificação axial, quando essas anotações soltas são agrupadas em categorias.

4. A quarta etapa é iterar até a saturação teórica, o ponto em que novos traços param de revelar padrões inéditos.

Sobre volume, não existe número mágico: 20 a 50 saídas costumam ser suficientes na primeira rodada, e a sugestão para os ciclos seguintes é revisar mais de cem traços recentes a cada vez. Uma regra prática ajuda a calibrar o resultado: comece com três critérios de avaliação. Menos que isso costuma indicar que a tarefa não está bem definida, e muitos mais tornam a avaliação difícil de manter.

Só o que sobrevive a essa triagem merece virar avaliador automático, e a ordem de adoção vai do mais barato para o mais caro. Por ex, primeiro as asserções determinísticas, escritas a partir de falhas concretas que apareceram na análise: verificações de formato, expressões regulares, presença de campos obrigatórios. Depois, para as falhas que resistem às correções óbvias e que não cabem em uma asserção, o LLM como juiz. A anotação humana fica por último, reservada ao que os dois níveis anteriores não cobrem.

Quem chegar ao LLM como juiz precisa tratá-lo como qualquer outro classificador, o que significa três cuidados.

• O primeiro é usar julgamento binário, aprovado ou reprovado, em vez de notas de um a cinco, que introduzem subjetividade sem melhorar a decisão.

• O segundo é preferir comparação entre pares (a versão atual contra a candidata) a notas absolutas, apresentando cada par nas duas ordens possíveis. No paper Judging the Judges, fo observado que a posição em que uma resposta aparece no prompt altera a preferência do avaliador.

• O terceiro é validar o juiz contra rótulos humanos, medindo taxa de verdadeiros positivos e de verdadeiros negativos em um conjunto de teste. Um juiz que nunca foi comparado com julgamento humano produz números sem significado conhecido.

Vale lembrar também da lei de Goodhart nesse desenho: quando a métrica vira alvo, ela deixa de medir bem. Otimizar demais para consistência factual, por exemplo, tende a produzir resumos vagos, que são menos inconsistentes e também menos úteis.

Estou considerando abrir uma nova turma sobre Cuidados com LLMs em produção. Se isso parece interessante pra você, deixe seu contato aqui?

Essa forma de pensar direcionaram boa parte da evolução recente dos modelos de linguagem. Modelos maiores, janelas de contexto maiores e novas técnicas de treinamento buscaram ampliar as capacidades dos modelos. Por outro lado, em vez de atribuir o sucesso (ou fracasso) de uma tarefa exclusivamente ao modelo, a capacidade de um agente emerge da interação entre três componentes: o modelo, o ambiente e uma camada intermediária chamada harness.

O que é um harness?

O harness é a infraestrutura de execução que envolve um modelo de linguagem durante a realização de uma tarefa. É essa camada que determina como o agente observa um projeto, quais informações recebe como contexto, quais ferramentas pode utilizar, como interpreta o retorno de suas ações e quais evidências utiliza para concluir que uma tarefa foi realmente finalizada.

O harness é uma plataforma com vários componentes; o modelo é apenas um deles.

O modelo deixa de ser visto como o único responsável pelo comportamento do agente. Da mesma forma que um desenvolvedor depende de IDEs, sistemas de versionamento, ferramentas de teste e documentação para realizar seu trabalho, um agente também depende de uma infraestrutura que organize sua interação com o ambiente.

Sob essa perspectiva, um modelo extremamente capaz pode ter desempenho mediano quando executado sobre um harness limitado. Da mesma forma, melhorias no harness podem aumentar significativamente a confiabilidade do sistema sem qualquer alteração no modelo utilizado.

Mais do que uma camada de integração

À primeira vista, pode parecer que o harness seja apenas uma camada responsável por conectar o modelo às ferramentas disponíveis. Não somente.

O harness é responsável por diversas funções fundamentais durante todo o ciclo de vida de uma tarefa. Vai desde a especificação da tarefa, a seleção de contexto, o acesso às ferramentas, o gerenciamento da memória do projeto, o acompanhamento do estado da tarefa, a observabilidade da execução, a atribuição de falhas, os mecanismos de verificação, o controle de permissões, a auditoria de entropia e o registro das intervenções realizadas durante a execução. Muita coisa, muito detalhe.

O harness ajuda a organiza toda a interação entre o modelo e o ambiente de desenvolvimento.

A capacidade emerge do sistema

Tradicionalmente, costuma-se avaliar um agente observando apenas sua saída final. Se ele produziu um patch correto, considera-se que foi bem-sucedido. Caso contrário, conclui-se que o modelo tem limitações.

No entanto, a capacidade de um agente é uma propriedade do sistema completo formado pelo modelo, pelo harness e pelo ambiente. Isso significa que falhas podem estar relacionadas não apenas ao raciocínio do modelo, mas também à forma como o contexto foi construído.

Níveis de Harness

Para tornar essa ideia mais concreta, existe inclusive uma classificação composta por quatro níveis de harness, denominados H0 até H3.

• H0: Produz apenas o resultado final (por exemplo, um patch), com pouca ou nenhuma evidência sobre sua execução.

• H1: Adiciona registros básicos da execução, permitindo reproduzir as ações realizadas pelo agente.

• H2: Incorpora mecanismos de verificação e atribuição de falhas, aumentando a confiabilidade dos resultados.

• H3: Produz um pacote completo de evidências (episode package), reunindo contexto, execução, verificações e rastreabilidade para auditoria e reprodução.

O aspecto interessante dessa classificação é que ela não mede a inteligência do modelo. Ela mede o nível de suporte oferecido ao agente durante sua execução. Conforme o harness evolui, cresce também a quantidade de evidências produzidas para justificar e validar as mudanças realizadas.

A avaliação de qualidade vai além da resposta do modelo

Essa visão também leva a uma mudança na forma de avaliar agentes de código.

Em vez de considerar apenas se uma tarefa foi concluída com sucesso, podemos registrar toda a trajetória de execução em um pacotão de logs. Com os logs, podemos, analisar não somente o resultado final, mas como o agente chegou ao resultado, quais decisões tomou, quais verificações realizou e quais falhas foram identificadas ao longo do processo.

Competindo com as big techs?

Durante muito tempo, a pergunta que muitos pesquisadores e praticantes faziam era se um modelo de linguagem seria capaz de produzir o código correto. Agora a pergunta é outra: a plataforma de harness consegue produzir um código correto, verificável e passível de manutenção?

Aqui abre um espaço para laboratórios e empresas que estão longe da saude financeira das bigtechs, uma vez que não precisamos concentrar os esforços em aumentar a capacidade dos modelos. Podemos, por outro lago, nos preocupar em criar uma infraestrutura que sustenta sua execução (de modelos menores, mais baratos ou mais rápidos).

Dessa forma, o uso de modelos de contexto longo pode parecer uma solução alternativa para aqueles que desenvolvem soluções baseadas na arquitetura RAG — em que informações externas são fornecidas para um modelo de forma a tornar sua resposta mais precisa e relevante.

Um dos pilares da arquitetura RAG está na estratégia de busca e seleção das informações que são passadas para a LLM. No RAG, o processo de busca precisa ser cuidadosamente desenhado para que documentos relevantes sejam selecionados e enviados para o modelo linguístico; diminuindo o ruído e aumentando a qualidade das respostas.

No entanto, quando se fala em modelos de contextos longo, na casa de milhões de tokens, a primeira vista pode-se imaginar que essa etapa de busca e seleção de informações pode se tornar menos relevante, uma vez que o modelo é capaz de processar um número muito maior de documentos. Você pode simplesmente colocar todos seus dados no contexto com o modelo!

Nesse texto, argumento há três motivos pelo quais modelos de contexto longo não devem tornar a arquitetura RAG obsoleta.

Bootcamp LLM4Devs

📚 Você é dev e quer criar aplicações baseadas em LLMs?

O bootcamp #LLM4Devs é um evento que acontece uma vez por mês, em formato online de 4h de duração, focado em ajudar devs a construir sua primeira aplicação baseada em LLMs. É um evento super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

RAG em 2 minutos

Os modelos RAG combinam a capacidade de recuperação de informações de grandes bancos de dados com a geração de texto contextualizado, permitindo que os modelos de linguagem lidem com informações atualizadas e específicas que não estão contidas em seu treinamento original.

Isso é particularmente importante, pois o conhecimento armazenado em modelos de linguagem geralmente está desatualizado ou incompleto. Além disso, os modelos RAG são projetados para mitigar problemas como alucinações e desinformação, proporcionando respostas mais confiáveis.

Para saber um pouco mais sobre a arquitetura RAG, veja esse texto da newsletter.

Modelos longos ainda precisam do RAG

Há pelo menos três razões pelas quais modelos longo ainda devem precisar se apoiar em arquiteturas como o RAG.

• Primeiro, mesmo com uma janela de contexto de 10 milhões de tokens, ainda precisaríamos de uma maneira de selecionar a informação mais relevante a ser alimentada no modelo. Por exemplo, considere um cenário onde um pesquisador está analisando uma vasta coleção de artigos científicos para responder a uma pergunta específica. Mesmo que o modelo possa processar todos esses artigos simultaneamente, ele ainda precisa identificar quais partes dos textos são mais pertinentes para fornecer uma resposta precisa. Sem um mecanismo eficaz de seleção de informações, a capacidade de processamento aumentada pode se tornar uma desvantagem, levando a respostas confusas ou incorretas.

• Segundo, ainda faltam avaliações detalhadas sobre como LLMs podem raciocinar em contextos tão grandes. Sem uma boa recuperação e classificação, corremos o risco de sobrecarregar o modelo com ruídos ou até mesmo preencher a janela de contexto com informações completamente irrelevantes. Imagine um sistema de atendimento ao cliente que tenta responder a uma consulta complexa. Se o modelo for inundado com transcrições de conversas passadas sem filtragem adequada, ele pode se perder em detalhes desnecessários e fornecer respostas imprecisas. Avaliações detalhadas ajudam a entender como os modelos lidam com grandes quantidades de dados e para desenvolver métodos que melhorem sua capacidade de raciocínio em tais contextos.

• Finalmente, há o custo. O custo de inferência do Transformer tende a escalar com o comprimento do contexto. Modelos mais recentes, como o GPT-4, são significativamente mais caros em termos de processamento em comparação com modelos anteriores como o GPT-3.5. Por exemplo, usar o GPT-4 pode ser até dez vezes mais caro que usar o GPT-3.5 para a mesma tarefa. Em aplicações comerciais, esse aumento nos custos pode ser proibitivo. Empresas que dependem de respostas rápidas e eficientes podem achar insustentável o uso de modelos de contexto longo sem um retorno claro sobre o investimento.

Modelos longos precisam ser avaliados

Embora esses modelos de contexto longo tragam luz para um grande número de aplicações, seu desempenho ainda é pouco conhecido. No artigo Benchmarking Large Language Models in Retrieval-Augmented Generation, os autores propõe algumas formas em que esses LLMs (utilizados em conjunto de aplicações baseadas em RAG) precisam ser avaliados para que seu comportamento seja mais conhecido.

Por exemplo:

• A Robustez ao Ruído é a capacidade dos LLMs em lidar com documentos ruidosos. Como os recuperadores não são perfeitos, o conhecimento externo que eles recuperam frequentemente contém uma quantidade significativa de ruído, ou seja, documentos que são relevantes para a pergunta, mas não contêm nenhuma informação sobre a resposta. Para responder efetivamente às perguntas dos usuários, os LLMs devem ser capazes de extrair a informação necessária dos documentos, apesar da presença de documentos ruidosos.

• A Rejeição Negativa é uma forma para que o LLM não responda uma pergunta quando o contexto não fornece informações úteis. Quando o mecanismo de busca falha em recuperar documentos contendo as respostas, é importante que o modelo tenha a capacidade de rejeitar o reconhecimento e evitar gerar conteúdo enganoso.

• A Integração de Informações é a capacidade de integrar respostas de vários documentos. Em muitos casos, a resposta a uma pergunta pode estar contida em vários documentos. Por exemplo, para a pergunta "Quem são os campeões do U.S. Open 2022 nas categorias de simples masculino e feminino?", os dois campeões podem ser mencionados em documentos diferentes. Para fornecer melhores respostas a perguntas complexas, é necessário que os LLMs tenham a capacidade de integrar informações.

• A Robustez Contrafactual refere-se à capacidade de lidar com erros no conhecimento externo. No mundo real, há uma abundância de informações falsas na internet. Note que avaliamos apenas a situação em que os LLMs recebem avisos sobre potenciais riscos nas informações recuperadas por meio de instruções.

Com a criação desses benchmarks, a decisão para quando utilizar os modelos se torna mais facilitada para os seus usuários.

Conclusão

Enquanto os modelos de contexto longo oferecem benefícios substanciais, eles ainda enfrentam desafios, como a incorporação de documentos ruidosos e a integração de informações de múltiplas fontes.

Por outro lado, os modelos RAG continuam a evoluir, combinando a robustez ao ruído e a capacidade de rejeitar respostas quando os dados são inadequados.

Portanto, a evolução das tecnologias de IA provavelmente verá uma coexistência e uma integração crescente entre modelos de contexto longo e RAG, cada um complementando as limitações do outro para fornecer soluções mais completas e precisas no processamento de linguagem natural.

Embora esses modelos sejam capazes de responder acuradamente um número quase sem fim de questões de amplo domínio, esses modelos ainda contam com uma barreira significativa, em particular, para o usuário comum: o custo financeiro.

Utilizar esses modelos para realizar algumas pequenas chamadas podem não ser algo necessariamente custoso do ponto de vista monetário. No entanto, como geralmente o modelo de precificação desses modelos está associado a quantidade de chamadas realizadas a suas APIs, o custo tende a aumentar a medida que se aumenta a base de usuários de um sistema baseado em LLMs.

Não obstante, as versões mais recentes desses modelos —aquelas com melhor acurácia— tendem a ser as mais caras, o que sobrecarrega ainda mais o custo do pequeno usuário. Ademais, embora muitos desses modelos forneçam calculadoras que ajudem a dar uma previsibilidade no custo total do uso dos modelos, realizar esse tipo de conta não é uma tarefa fácil, uma vez que algumas variáveis não são conhecidas antecipadamente (como a quantidade de usuários acessando o sistema e os tipos de usos desses usuários).

Como forma de minimizar essa limitação financeira, algumas empresas, universidades e entidades públicas tem disponibilizado versões abertas de modelos linguísticos. Esses modelos, muitas vezes tem desempenho semelhante (ou até superior) a modelos linguísticos proprietários, torando-se assim soluções para aqueles interessados em construir aplicações baseadas em LLMs, porém diminuindo o custo de invocações de APIs privadas.

Nesse texto, vamos conhecer alguns desses modelos e abordar algumas formas de consumi-los.

Bootcamp LLM4Devs

📚 Você é dev e quer criar aplicações baseadas em LLMs?

O bootcamp #LLM4Devs é um evento que acontece uma vez por mês, em formato online de 4h de duração, focado em ajudar devs a construir sua primeira aplicação baseada em LLMs. É um evento super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

Onde posso encontrar esses modelos abertos?

Geralmente, o primeiro local para se procurar por modelos abertos é no HuggingFace. Se você ainda não conhece, dedique um tempo para criar uma conta, navegar e entender um pouco das principais funcionalidades desse site.

Em uma analogia simples, você pode entender que o HuggingFace é o GitHub para modelos. Ou seja, um repositório de código do GitHub é análogo a um repositório de modelo no HuggingFace.

Outro ponto interessante é que o HuggingFace hospeda não somente modelos linguísticos, mas também modelos de imagens para texto, de voz para texto, multimodais, etc. Há centenas de milhares de modelos que podem ser facilmente acessados. Umas dessas formas de acessá-los é através da biblioteca transformers, desenvolvida pelo próprio HuggingFace.

No entanto, nesse texto, faremos uso do LangChain para acessar os modelos disponíveis no HuggingFace. Usaremos o LangChain, pois, embora a biblioteca transformers seja mais robusta, ao meu ver, o LangChain fornece uma interface mais intuitiva e amigável (dado um menor número de configurações necessárias) para acessar os modelos do HuggingFace.

Quais modelos posso utilizar?

Como mencionamos, o HunggingFace tem centenas de milhares de modelos hospedados. E como no GitHub, muitos desses modelos tem baixa qualidade ou não são mais mantidos. Dessa forma, é importante fazer um trabalho de pesquisa e curadoria antes de utilizar algum modelo menos conhecido em um ambiente mais produtivo.

Para facilitar, sugiro aqui alguns dos modelos linguísticos que poderiam ser utilizados inicialmente:

• mistralai/Mistral-7B-Instruct-v0.3: O Mistral-7B-Instruct-v0.3 é um modelo de linguagem grande de 7 bilhões de parâmetros desenvolvido pela Mistral AI. Este modelo é ajustado especificamente para seguir instruções, tornando-o adequado para tarefas que requerem compreensão contextual e respostas precisas em linguagem natural.

• microsoft/Phi-3-mini-4k-instruct: O Phi-3-mini-4k-instruct da Microsoft é um modelo compacto com um foco em eficiência e desempenho. Com otimização para tarefas de instrução, ele é projetado para processar e responder a consultas complexas, mantendo um equilíbrio entre qualidade de resposta e consumo de recursos computacionais. Já escrevemos sobre ele aqui na newsletter.

• meta-llama/Meta-Llama-3-8B-Instruct: O Meta-Llama-3-8B-Instruct é um modelo robusto de 8 bilhões de parâmetros criado pela Meta. Este modelo tem uma arquitetura avança e permite seguir instruções em diversas tarefas de processamento de linguagem natural. Também já escrevemos sobre ele aqui na newsletter.

Uso pela API de inferência do HuggingFace

Como mencionado, vamos utilizar o LangChain para acessar esses modelos. Podemos começar instalando o LangChain:

pip install langchain

Uma vez instalado, vamos usar a API HuggingFaceEndpoint, que fornece acesso ao endpoint de inferência do modelo no HuggingFace.

Esse endpoint torna simples o acesso aos modelos, uma vez que não se faz necessário baixar e configura-los localmente. Todavia, é importante notar que nem todos os modelos estão disponíveis através desse endpoint.

Para que seja possível acessar o endpoint, é necessário criar uma conta e, em seguida, um token no seu perfil no HuggingFace.

Com esse token em mãos, podemos fazer nossa primeira requisição a um modelo aberto, hospedado (e executando) no HuggingFace.

from langchain.llms import HuggingFaceHub
import os

os.environ["HUGGINGFACEHUB_API_TOKEN"] = TOKEN

llm = HuggingFaceEndpoint(repo_id="meta-llama/Meta-Llama-3-70B-Instruct", task="text-generation")

prompt = """
        <|begin_of_text|>
        <|start_header_id|>system<|end_header_id|>
        Você é um assistente de código especializado em culinária.
        <|eot_id|>
        <|start_header_id|>user<|end_header_id|>
        Me faça uma lasanha vegana.
        <|eot_id|>
        <|start_header_id|>assistant<|end_header_id|>
        """

llm.invoke(prompt)

Este código importa a biblioteca `HuggingFaceHub` do Langchain e a biblioteca `os` para manipulação de variáveis de ambiente. Ele configura a variável de ambiente HUGGINGFACEHUB_API_TOKEN com um token de acesso necessário para autenticar e acessar os recursos do HuggingFace Hub. Em seguida, um objeto chamado llm é criado usando a classe HuggingFaceEndpoint, especificando o repositório do modelo meta-llama/Meta-Llama-3-70B-Instruct e definindo a tarefa como "text-generation", que indica que o modelo será usado para gerar texto.

Após a configuração do modelo, o código define um prompt, que é um texto de entrada formatado para orientar a geração de texto do modelo. Note que o prompt é ligeiramente diferente, pois conta com uma série de tokens especiais que ajudam o modelo a responder de maneira mais assertiva. Cada modelo aberto tende a ter seus próprios tokens especiais, e conhecer esses tokens é fundamental para uma boa comunicação com o modelo.

Finalmente, o código chama o método `invoke` do objeto LLM, passando o prompt para gerar uma resposta baseada nas instruções fornecidas. Este processo permite que o modelo produza uma resposta à solicitação do usuário.

Uso do modelo localmente

Podemos também baixar e rodar um modelo localmente. Par isso, utilizaremos a biblitoeca LLamaCPP.

O LLamaCPP permite o uso de modelos empacotados como arquivos de formato gguf, que rodam em ambientes somente CPU e mistos CPU/GPU.

Para usar o LlamaCPP, precisamos de modelos cujo caminho do modelo termine com gguf. Para encontra-los, você pode fazer buscas no próprio HunggingFace pelo nome do seu modelo, mais a extensão gguf.

from langchain_community.llms import LlamaCpp

drive.mount('/content/drive')

llm = LlamaCpp(
            model_path="Phi-3-mini-4k-instruct.gguf",
            temperature=0.75,
            top_p=1,
            verbose=True,
            n_ctx=4096
            )

prompt = """<|user|>
How to explain Internet for a medieval knight?<|end|>
<|assistant|>"""

response = llm.invoke(prompt)
print(response)

No exemplo acima, usamos o modelo phi-3, logo o prompt deve utilizar os tokens seguidos por esse modelo. Note que é possível definir ainda alguns parâmetros durante a instanciação do objeto llm. Considere navegar pela documentação oficial para conhecer mais sobre esses parâmetros.

Conclusão

Concluindo, enquanto modelos linguísticos proprietários, como o GPT da OpenAI e o Gemini do Google, são frequentemente as primeiras escolhas para desenvolvedores iniciando em aplicações baseadas em LLMs, seu uso pode se tornar financeiramente inviável à medida que a base de usuários cresce. A precificação baseada no volume de chamadas às suas APIs pode tornar os custos proibitivos, especialmente para pequenas empresas ou desenvolvedores individuais. Além disso, as versões mais precisas desses modelos tendem a ser as mais caras, aumentando ainda mais o desafio financeiro.

Felizmente, a crescente disponibilidade de modelos abertos oferece uma alternativa viável e econômica. Plataformas como o HuggingFace disponibilizam uma vasta gama de modelos de alta qualidade que podem ser utilizados gratuitamente ou a um custo significativamente menor. Neste texto, exploramos como utilizar alguns desses modelos através do LangChain, uma biblioteca que facilita o acesso e a integração desses modelos em suas aplicações. Com isso, desenvolvedores podem criar soluções robustas e eficientes, minimizando os custos associados ao uso de modelos linguísticos proprietários.

O direcionamento para esse esforço é em parte devido as melhorias que são obtidas ao treinar modelos com quantidade de dados cada vez maiores. Ou seja, ao aumentar o tamanho de um modelo de linguagem (adicionando mais parâmetros) e ao treinar com mais dados, o desempenho do modelo tende a melhorar o desempenho de maneira previsível e consistente — o que é conhecido como scaling laws.

No entanto, essa teoria agora é desafiada pela existência de novos modelos menores que permitem interagir com dados de novas maneiras.

Em trabalhos anteriores sobre os modelos phi, foi mostrado que uma combinação de dados da web disponível publicamente e dados sintéticos criados por LLM, possibilita um desempenho em modelos menores que normalmente só era visto em modelos muito maiores.

Um exemplo é modelo linguístico phi-2 (de 2.7 bilhões de parâmetros), que teve desempenho similar a de modelos 25 vezes maiores treinados com dados regulares.

Bootcamp LLM4Devs

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 13/07/2024 (sábado), vai rolar um bootcamp online de 4h de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

Small language models

Os "small language models" (SLMs), ou pequenos modelos de linguagem, são uma classe de modelos que possuem um número relativamente pequeno de parâmetros em comparação com osLLMs. Enquanto os LLMs, como o GPT-3, possuem bilhões ou até trilhões de parâmetros, os SLMs têm uma quantidade significativamente menor, muitas vezes na faixa de milhões a poucos bilhões de parâmetros.

A principal vantagem dos SLMs é a sua eficiência. Devido ao menor número de parâmetros, eles requerem menos poder computacional e memória para treinamento e execução, tornando-os mais acessíveis para organizações com recursos limitados. Essa eficiência permite que os SLMs sejam implantados em dispositivos locais, como smartphones e computadores pessoais, sem a necessidade de conexão constante à nuvem. Isso não apenas reduz a latência nas respostas, mas também aumenta a privacidade dos dados, pois as informações não precisam ser enviadas para servidores remotos.

Apesar de seu tamanho menor, os SLMs podem ser altamente eficazes em uma variedade de tarefas de processamento de linguagem natural. Isso é possível graças a técnicas avançadas de treinamento que utilizam dados de alta qualidade e novos métodos de filtragem. Por exemplo, os SLMs podem ser treinados com conjuntos de dados cuidadosamente selecionados e sinteticamente gerados, permitindo que eles alcancem desempenho semelhante ao de modelos maiores em tarefas específicas.

Além disso, os SLMs são mais facilmente ajustáveis para aplicações especializadas. Organizações podem personalizar esses modelos para atender a necessidades específicas com menos esforço e recursos do que seriam necessários para adaptar um LLM. Isso os torna ideais para cenários onde a rapidez na resposta e a execução local são cruciais, como em sistemas de suporte ao cliente, dispositivos de IoT e aplicativos em áreas remotas com conectividade limitada.

Phi-3-mini, o estado da arte do SLMs

O modelo phi-3-mini é um SLM open source lançado mais recentemente pela Microsoft. O phi-3-mini é baseado em uma arquitetura decoder-only do transformer, com comprimento de contexto de 4.000 tokens. Também foi introduzido uma versão de contexto mais longo, chamada phi-3-mini-128K, que usa a técnica LongRope para estender o comprimento do contexto para 128.000 tokens.

O phi-3-mini é construído de forma semelhante ao Llama-2 e usa o mesmo tokenizador com um vocabulário de 320.641 palavras. Isso significa que todos os pacotes desenvolvidos para a família de modelos Llama-2 podem ser adaptados diretamente para o phi-3-mini. O modelo foi treinado usando bfloat16 com um total de 3,3 trilhões de tokens. O modelo já está ajustado para conversação.

O modelo phi-3-small, com 7 bilhões de parâmetros, utiliza o tokenizador tiktoken, que melhora a tokenização multilíngue, com um vocabulário de 100.352 palavras e um comprimento de contexto padrão de 8192 tokens. Ele segue a arquitetura padrão de um decoder-only com 7 bilhões de parâmetros.

Graças ao seu tamanho pequeno, o phi-3-mini pode ser quantizado para 4 bits, ocupando apenas cerca de 1,8 GB de memória. De acordo com o relatório oficial, o modelo foi testado após quantização e implantado em um iPhone 14 com chip A16 Bionic, rodando nativamente no dispositivo e totalmente offline, alcançando mais de 12 tokens por segundo.

Em termos de capacidades de modelos de linguagem grandes (LLM), embora o modelo phi-3-mini alcance um nível de compreensão e raciocínio linguístico semelhante ao de modelos muito maiores, ele ainda é fundamentalmente limitado pelo seu tamanho para certas tarefas.

Hello world com o Phi-3-mini

O modelo phi-3-mini está disponível no huggingface, logo pode ser acessado usando a sua API oficial. Para esse exemplo, utilizaremos o LangChain para comunicar com o modelo phi-3-mini no huggingface.

O código abaixo configura e utiliza um modelo de linguagem da HuggingFace para gerar texto a partir de um prompt específico.

from langchain_community.llms import HuggingFaceEndpoint
import os
from dotenv import load_dotenv

load_dotenv()

os.environ["HUGGINGFACEHUB_API_TOKEN"] = os.getenv("HG")

model = HuggingFaceEndpoint(repo_id="microsoft/Phi-3-mini-4k-instruct", task="text-generation", temperature=0.9)


prompt = f"""
<|user|>
How to explain Internet for a medieval knight?<|end|>
<|assistant|>
"""

response = model.invoke(prompt)
print(response)

Inicialmente, o código importa as bibliotecas necessárias e carrega as variáveis de ambiente a partir de um arquivo `.env` usando `load_dotenv()`.

Em seguida, ele define a variável de ambiente `HUGGINGFACEHUB_API_TOKEN` com o valor da variável `HG` carregada do arquivo `.env`, o que é necessário para autenticar a API da Hugging Face. Você precisa criar um token no HuggingFace para acessar sua API.

O código então cria uma instância do modelo `HuggingFaceEndpoint` especificando o identificador do repositório do modelo (`repo_id`) e a tarefa que ele deve realizar (`task`), que no caso é a geração de texto. Também definimos o parâmetro `temperature` para ajustar a criatividade da resposta gerada pelo modelo.

Depois, o código define um prompt, que neste caso é uma pergunta sobre como explicar a Internet para um cavaleiro medieval. Perceba os tokens especiais que são utilizados por esse modelo.

Por fim, usamos o método `invoke()` do modelo, ele gera uma resposta para o prompt e imprime essa resposta.

Conclusão

O progresso notável da IA nos últimos anos se deve, em grande parte, aos esforços para aumentar os modelos e os conjuntos de dados. LLMs cresceram de bilhões de parâmetros para trilhões, melhorando o desempenho de maneira previsível através das chamadas "leis de escala". No entanto, a introdução de novos modelos menores que interagem de maneiras inovadoras com os dados desafiou essa teoria. Trabalhos anteriores mostraram que a combinação de dados disponíveis na web e dados sintéticos gerados por LLMs pode permitir que modelos menores alcancem um desempenho anteriormente reservado a modelos maiores. Um exemplo disso é o modelo phi-2, que com 2,7 bilhões de parâmetros conseguiu um desempenho semelhante ao de modelos 25 vezes maiores.

Os "small language models" (SLMs) destacam-se pela eficiência, requerendo menos recursos computacionais e podendo ser implementados localmente em dispositivos como smartphones. Embora menores, eles podem ser altamente eficazes em diversas tarefas de processamento de linguagem natural, especialmente com técnicas de treinamento avançadas e filtragem de dados.

O modelo phi-3-mini, por exemplo, é um SLM baseado em uma arquitetura transformer decoder-only, com comprimento de contexto estendido e alta adaptabilidade para aplicações especializadas. Ele pode ser quantizado para ocupar apenas 1,8 GB de memória, funcionando eficientemente em dispositivos como o iPhone 14. Assim, os SLMs oferecem uma alternativa poderosa e eficiente aos LLMs, combinando desempenho robusto com acessibilidade e versatilidade para diversas aplicações práticas.

Esses parâmetros determinam como o modelo transforma as entradas nos resultados previstos. Por exemplo, em redes neurais, os parâmetros incluem pesos e biases das conexões entre neurônios.

O ajuste adequado desses parâmetros é crucial para que o modelo aprenda padrões a partir dos dados de treinamento e faça previsões precisas em novos dados.

Bootcamp LLM4Devs

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 15/06/2024 (sábado), vai rolar um bootcamp online de 3h:30m de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

O que é mesmo aprendizado de máquina?

De maneira simplista, a idéia do aprendizado de máquina é criar (ou melhor, treinar) modelos expondo-os em um conjunto de dados. Com esses modelos treinados é possível, de alguma forma, usa-los para avaliar (ou predizer) um conjunto de dados até então desconhecido.

Digamos que você queira uma função que receba uma imagem e produza um rótulo descrevendo-a, ou qualquer outra tarefa que pareça exigir algum elemento de intuição e reconhecimento de padrões.

A ideia do aprendizado de máquina é que, em vez de tentar definir explicitamente um algoritmo que descreve como realizar essa tarefa em código — que é o que as pessoas teriam feito nos primórdios da IA — você configure uma estrutura flexível com botões (ou melhor, parâmetros) ajustáveis.

Para ajustar os valores desses parâmetros, você fornece muitos, muitos exemplos de como a saída deve ser formatada para uma determinada entrada, de forma que o modelo comece a imitar esse comportamento.

Modelos com poucos parâmetros

Talvez a forma mais simples de aprendizado de máquina seja a regressão linear, onde suas entradas e saídas são números, algo como a metragem quadrada de uma casa e seu preço, e você deseja encontrar uma linha que melhor se ajuste através desses dados, para prever os preços futuros de imóveis.

Essa linha é descrita por dois parâmetros, como o coeficiente angular e o intercepto. O objetivo da regressão linear é encontrar quais são os melhores valores para esses parâmetros, de forma a gerar uma reta que melhor possa descrever os dados.

Modelos com muitos parâmetros

Os modelos baseados em deep learning são muito mais sofisticados. O GPT-3, por exemplo, não possui dois, mas 175 bilhões de parâmetros.

Para que esses modelos sejam treinados nessa escala, os dados precisam seguir um formato específico. Os dados são costumeiramente formatados como um array de números reais, podendo ser uma lista de números, uma matriz bidimensional ou, muitas vezes, matrizes alta dimensão, onde o termo geral usado é tensor.

Muitas vezes pensamos que os dados de entrada são transformados em camadas distintas, onde, novamente, cada camada é sempre estruturada como algum tipo de matriz de números reais, até chegar a uma camada final de saída. Por exemplo, a camada final em um modelo linguístico como o GPT-3 é uma lista de números que representa a probabilidade dos próximos tokens possíveis.

Em deep learning, esses parâmetros do modelo são quase sempre chamados de pesos, e isso ocorre porque uma característica importante desses modelos é que a única maneira pela qual esses parâmetros interagem com os dados que estão sendo processados é por meio de somas ponderadas. Se você pensar em como funciona a multiplicação de vetores de matrizes, cada componente na saída parece uma soma ponderada.

Os dados processados simplesmente codificam as entradas inseridas no modelo para uma determinada execução. Por outro lado, os pesos são o cérebro do modelo; são onde se aprende os padrões durante o treinamento e, assim, determinando o comportamento do modelo.

Olhando rapidamente a evolução dos modelos linguístico, uma característica notável é o progressivo aumento no número de parâmetros desses modelos. Tome por exemplo o GPT2, lançado em 2019, que foi disponibilizado com várias versões, variando entre 117 milhões de parâmetros até 1.5bilhões de parâmetros.

Cerca de um ano depois, a OpenAI lançou o GPT3, agora com 175 bilhões de parâmetros; mais de 100x mais parâmetros do que a versão anterior.

Por que muitos parâmetros são importantes

Ter muitos parâmetros em um modelo de linguagem é importante pois cada parâmetro representa uma parte do conhecimento adquirido durante o treinamento. Imagine que cada parâmetro é como uma pequena peça de um quebra-cabeça, e o quebra-cabeça completo é o entendimento do modelo sobre a linguagem humana. Quanto mais peças, mais detalhada e precisa é a imagem final.

Em modelos de linguagem, parâmetros são usados para capturar padrões, nuances e contextos de dados textuais vastos e variados. Quando um modelo tem muitos parâmetros, ele pode aprender e armazenar uma quantidade imensa de informações sobre gramática, vocabulário, gírias, expressões idiomáticas, contextos culturais, conhecimento factual e até mesmo sutilezas emocionais. Essa riqueza de detalhes permite ao modelo gerar respostas que são mais coerentes, contextualmente apropriadas e muitas vezes indistinguíveis daquelas produzidas por humanos.

Além disso, a capacidade de um modelo com muitos parâmetros de generalizar a partir dos dados de treinamento é significativamente maior. Isso significa que o modelo pode entender e responder adequadamente a uma ampla gama de perguntas e tópicos, mesmo aqueles que não encontrou diretamente durante o treinamento. Por exemplo, um modelo com bilhões de parâmetros pode entender e responder perguntas sobre eventos históricos pouco conhecidos, avançadas teorias científicas ou peculiaridades de diversas culturas.

Conclusão

A importância dos parâmetros em modelos de aprendizado de máquina, especialmente em modelos de linguagem como o GPT-3, não pode ser subestimada.

Cada parâmetro funciona como um componente essencial que ajuda o modelo a capturar e processar uma vasta gama de informações textuais. Com um número maior de parâmetros, o modelo pode armazenar e utilizar um conhecimento mais detalhado sobre gramática, vocabulário, e contextos culturais, permitindo que ele gere respostas mais precisas e coerentes.

Esse aumento na quantidade de parâmetros também melhora a capacidade do modelo de generalizar a partir dos dados de treinamento, possibilitando que ele entenda e responda a uma ampla variedade de questões com alta precisão.

A evolução dos modelos de linguagem demonstra que a ampliação do número de parâmetros parece ser um caminho sem volta como forma de melhorar a capacidade de interação de maneira natural com os usuários.

Desde o uso de linguagens de programação de alto nível que abstraem tarefas antes manuais, como gerenciamento de memória, passando pela popularização de práticas como CI/CD e DevOps, que têm ajudam a melhorar a qualidade de entrega ao longo do ciclo de vida do software, surfando junto com a revolução dos contêineres como Docker, gerenciando ambientes de desenvolvimento e produção, majoritariamente em nuvem.

Esses são apenas alguns poucos exemplos porém significativos exemplos de mudanças que aconteceram no processo de desenvolvimento. Essas mudanças não apenas aumentaram a velocidade de entrega de software, mas também elevaram os padrões de qualidade e usabilidade das aplicações.

Estamos prestes de vivenciar uma nova e notável mudança: o desenvolvimento de software orientado a agentes.

Bootcamp LLM4Devs

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 15/06/2024 (sábado), vai rolar um bootcamp online de 3h:30m de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

Embora o desenvolvimento software baseado de agentes não seja algo necessariamente novo, com artigos que datam da década de 1990, a evolução e popularização dos LLMs simplificaram o processo de criação de agentes sofisticados.

Poderíamos usar as palavras do prof. Carlos Lucena, de um texto de 2003, para exemplificar a ideia de desenvolvimento orientado a agentes:

Enquanto a orientação de objetos é usada para modelar componentes passivos, o desenvolvimento orientado a agentes é ideal para representar componentes autônomos em sistemas de software. A área de pesquisa de sistemas multiagentes ajudam a entender a autonomia, coordenação, mobilidade, organização, abertura e inteligência desses agentes. A Engenharia de Software está estudando como as lições dessas teorias de agentes em IA podem ajudar a superar as limitações da engenharia de software orientada a objetos e a lidar com a complexidade do software moderno.

Movendo a janela de tempo uns 20 anos, nos deparamos com a evolução e popularização dos modelos linguísticos.

Esses modelos, como o GPT-4, LLaMa 3 ou Claude 3, tornaram o acesso a estes modelos, através de suas APIs, extremamente simplificado. Não obstante, novos frameworks surgiram (e continuam surgindo) com o objetivo de não somente padronizar e simplificar o acesso à esses modelos, como também orquestrar todo o pipeline de coleta, curadoria e manipulação de dados, que são consumidos e enriquecidos pelos modelos.

Estes modelos, operado por frameworks e bibliotecas, abrem as portas para um sem fim número de aplicações e automações que podem ser criadas por pessoas desenvolvedoras; finalmente girando as engrenagens do desenvolvimento de software orientado a agentes.

Com os modelos linguísticos se tornando cada vez mais assertivos em suas respostas, associado a competitividade dos grandes players provedores destes modelos, que tende a baratear o custo de acesso, junto com bons frameworks e ferramentas que simplificam a jornada do desenvolvedor, em pouco tempo, o desenvolvimento de software impulsionado por LLMs se tornará tão comum quanto outras práticas de desenvolvimento.

Quem ganha com isso é o desenvolvedor, que se torna capaz de construir aplicações mais inteligentes e adaptativas, com velocidade e produtividade.

Como é o caso de qualquer novo paradigma de programação, tanto pesquisadores quanto a comunidade de praticantes estão se esforçando para criar metodologias que orientam o processo de construção de agentes sofisticados.

Como toda nova tecnologia, as soluções existentes ainda devem evoluir até ganhar maturidade para serem utilizadas com baixo risco em ambientes produtivos. O próprio LangChain, um dos principais frameworks nessa área, por exemplo, tem sido alvo frequente de questionamentos de alguns de seus usuários. De maneira geral, ainda é difícil compreender a interação entre agentes e objetos, na perspectiva de engenharia de software.

Por mais que essas limitações tragam indagações da comunidade técnico-científica de desenvolvimento, o fato é que essa nova era de desenvolvimento promete não apenas aumentar a eficiência e a qualidade do software produzido, mas também abrir novas possibilidades para a criação de soluções inovadoras que atendam às necessidades cada vez mais complexas dos usuários e dos mercados.

Se você não quer ficar de fora dessa, considere se inscrever no Bootcamp LLM4Devs.

De acordo com experimentos, o LLaMA 3 destaca-se especialmente em tarefas que envolvem raciocínio aprimorado e geração de código. As melhorias no processo de pré-treino (que utilizou mais de 15T de tokens; 7 vezes maior que do LLaMA 2) resultaram em modelos que não apenas são mais precisos, mas também oferecem maior diversidade de respostas e melhor alinhamento com as expectativas dos usuários.

O LLaMA 3 segue abordagem do LLaMA 2, de ser aberto para sua comunidade. Essa estratégia visa estimular a inovação em IA, permitindo que desenvolvedores, pesquisadores e empresas explorem e aprimorem a tecnologia. Dessa forma, os custos envolvidos com o uso do modelo se restringem aos custos de processamento, memória e energia, gastos durante o processo de inferência.

Nesse texto, vamos experimentar um pouco com esse modelo!

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 15/06/2024 (sábado), vai rolar um bootcamp online de 3h:30m de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Inscreva-se agora!

Detalhes do modelo

O LLaMA 3 é fornecido em duas configurações de parâmetros: 8B e 70B. É um modelo que recebe texto como entrada, e fornece como saída ou texto ou trechos de código. A data de lançamento foi 18 de abril de 2024, embora detenha conhecimento até Março de 2023 (para a versão de 8B de parâmetros) e Dezembro de 2023 (para a versão de 70B de parâmetros).

O tamanho da janela de contexto do modelo LLaMA 3 é de 8.000 tokens. Isso significa que o modelo pode considerar até 8.000 tokens de texto ao gerar respostas ou realizar previsões. Na prática, a janela de contexto determina a quantidade de texto que o modelo pode "lembrar" e usar como referência ao processar novas entradas. Um tamanho maior de janela de contexto permite que o modelo mantenha mais informações relevantes, melhorando sua capacidade de compreender e gerar respostas coerentes em textos mais longos ou complexos.

O LLaMa 3 é disponibilizado através de uma nova licença, chamada “Meta Llama 3 Community License Agreement”, que se assemelha a licenças permissivas, como a MIT ou Apache 2, uma vez que concede permissão para usar, reproduzir, distribuir, criar trabalhos derivados e fazer modificações nos materiais do LlaMa.

Mais detalhes técnicos sobre o modelo podem ser consultados na página oficial, ou no model card, no GitHub do projeto.

Instalações e downloads

Para nosso primeiro exemplo, utilizaremos também o LangChain, que é um framework que auxilia na criação de aplicações baseadas em LLMs.

Podemos instalar o LangChain com um comando pip:

pip install langchain langchain_community

Precisamos também isntalar o langchain_community, pois este fornece interfaces com os mais diversos modelos e conectores, incluindo o LLaMa, através da biblioteca llama-cpp-python.

Após a instalação das bibliotecas, precisamos também baixar o modelo. O download pode ser feito de várias fontes, incluindo do site oficial da Meta e do perfil da Meta do HuggingFace. Dentre as mais varias versões de modelos disponíveis, para esse texto, utilizaremos a Meta-Llama-3-8B-Instruct-Q3_K_L.gguf. O nome do modelo fornece informações específicas sobre suas características. Por exemplo:

• Meta: Indica que o modelo foi desenvolvido pela Meta.

• Llama: Refere-se à família de modelos de linguagem LLaMA.

• 3: Denota que é a terceira versão da série LLaMA.

• 8B: Indica o tamanho do modelo em termos de parâmetros.

• Instruct: Significa que o modelo foi ajustado por instrução, otimizado para seguir comandos e gerar respostas úteis em contextos de diálogo e outras interações.

• Q3_K_L: Se refere a uma técnica específica de quantização aplicada ao modelo.

• .gguf: É a extensão do arquivo, indicando o formato no qual o modelo está armazenado.

Hello world no langchain

Uma vez com o ambiente instalado e configurado, podemos fazer nosso hello world, usando a classe LlamaCpp. Por exemplo:

from langchain_community.llms import LlamaCpp

llm = LlamaCpp(model_path="models/Meta-Llama-3-8B-Instruct-Q3_K_L.gguf", max_tokens=100,n_ctx=512)

response = llm.invoke("Quais são os melhores amigos do Mickey Mouse?")

print(response)

Perceba que a classe LlamaCpp recebe dois outros parâmetros: o max_tokens e o n_ctx. O n_ctx define o tamanho da janela de contexto.

A janela de contexto determina o número máximo de tokens que podem ser processados de uma vez — considerando tanto a entrada do usuário quanto a resposta do modelo. Por padrão, no LLaMa3 este valor é definido para 512 tokens, mas pode ser ajustado com base em suas necessidades, até o limite máximo de 8k tokens.

O max_tokens, por outro lado, ajuda a definir o limite de tokens gerados como resposta. Perceba, no entanto, que se o modelo gerar mais tokens do que o limite definido, a resposta do usuário será cortada. Defina max_tokens = None para gerar até o final da janela de contexto.

Além desses três parâmetros, há vários outros que podem ser configurados e estão documentados na classe LlamaCpp, como a possibilidade de carregar somente o vocabulário (sem os pesos), a possibilidade de rodar o processo de inferência em paralelo, a temperatura do modelo, além de vários outros.

Tokens especiais

Há alguns tokens especiais usados para interagir via prompt com o Meta Llama 3:

• <|begin_of_text|>: Isso é equivalente ao token BOS (Beginning of String), indicando o início de uma nova sequência de texto.

• <|eot_id|>: Isso indica o fim de uma mensagem.

• <|start_header_id|>{role}<|end_header_id|>: Esses tokens envolvem o papel de uma mensagem específica. Os papéis possíveis são: system, user e assistant.

• <|end_of_text|>: Isso é equivalente ao token EOS (End of String). Ao gerar esse token, o Llama 3 deixará de gerar mais tokens.

Um prompt pode opcionalmente conter uma única mensagem do sistema, ou múltiplas mensagens alternadas de usuário e assistente, mas deve sempre terminar com a mensagem do usuário, seguida pelo cabeçalho do assistente. Por exemplo:

from langchain_community.llms import LlamaCpp
from langchain_core.prompts import PromptTemplate

llm = LlamaCpp(model_path="models/Meta-Llama-3-8B-Instruct-Q3_K_L.gguf", 
               max_tokens=None,
               n_ctx=512,
               stop=["<|eot_id|>"])

template = """
        <|begin_of_text|>
        <|start_header_id|>system<|end_header_id|>
        {system_prompt}
        <|eot_id|>
        <|start_header_id|>user<|end_header_id|>
        {user_prompt}
        <|eot_id|>
        <|start_header_id|>assistant<|end_header_id|>
        """
def get_response(user_prompt):
    sys_template_str = "You are a helpful AI bot, named Bob. You are specialized in Disney movies. Give a one or two sentences only."
    
    human_template_str = "{user_prompt}"

    prompt = PromptTemplate.from_template(template.format(system_prompt = sys_template_str, user_prompt = human_template_str))

    session = prompt | llm 

    return session.invoke({"user_prompt" : user_prompt})

response = get_response("Who is Mickey Mouse best friend?")
print(response)

No passo a passo:

<|begin_of_text|>: Especifica o começo de um prompt

<|start_header_id|>system<|end_header_id|>: Especifica o papel do usuário da mensagem seguinte, neste caso, o “system”

{system_prompt}: A mensagem de sistema a ser enviada

<|eot_id|>: Especifica o fim da mensagem de sistema

<|start_header_id|>user<|end_header_id|>: Especifica o papel do usuário da mensagem seguinte, neste caso, o “user”

{user_prompt}: A mensagem de usuário a ser enviada

<|start_header_id|>assistant<|end_header_id|>: Termina com o cabeçalho do assistente, para solicitar ao modelo que inicie a geração.

Seguindo este prompt, o Llama 3 o completa gerando a {assistant_message}. Ele sinaliza o fim da {assistant_message} ao gerar o token EOS, de fim da string.

Conclusão

O LLaMA 3, desenvolvido pela Meta AI, representa um avanço significativo na série de modelos de linguagem LLaMA, oferecendo modelos com 8 bilhões (8B) e 70 bilhões (70B) de parâmetros para suportar diversos casos de uso.

Estes modelos destacam-se em tarefas que envolvem raciocínio aprimorado e geração de código, resultando em modelos mais precisos, com maior diversidade de respostas e melhor alinhamento com as expectativas dos usuários. Seguindo a abordagem do LLaMA 2, o modelo LLaMA 3 é disponibilizado para a comunidade, através da sua própria licença “Meta Llama 3 Community License Agreement”.

Há algumas formas de se utiliza ro LLaMA 3. Nesse texto, usamos o LangChain, que é um framework popular para criar aplicações baseadas em modelos de linguagem. Com o langchain, pudemos criar nosso hello world, com poucas linhas de código.

O LangChain permite a integração entre os modelos de linguagem e várias fontes de conhecimento, otimizando a maneira como os desenvolvedores constroem agentes inteligentes que utilizam processamento de linguagem natural para responder a perguntas e executar tarefas.

O LangChain tem rapidamente se popularizado na comunidade de desenvolvimento (com mais de 85K ⭐️ no GitHub) e é um dos frameworks mais utilizados no momento para construção de aplicações baseadas em LLMs.

No entanto, o uso do framework tem sido alvo de questionamentos. Parte dessas críticas está relacionado a dificuldade de uso do LangChain. No último Tech Radar de Abril de 2024, a ThoughtWorks sugere inclusive a pausa na adoção do framework, colocando como sugestões outras soluções, como o SemanticKernel, da Microsoft.

Nesse texto, ofereço minhas enviesadas considerações sobre o uso do LangChain.

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 15/06/2024 (sábado), vai rolar um bootcamp online de 3h:30m de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!

Alguns dos tópicos abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.

Interessou? Clique aqui e saiba mais:

Conheça o Bootcamp LLM4Devs

Meu uso do LangChain

Tenho sido usuário do LangChain há cerca de um ano, e nesse meio tempo acompanhei várias mudanças que aconteceram na estrutura do framework.

Como fui evoluindo meu uso junto com a própria evolução do framework, acompanhei algumas modificações significativas que aconteceram, como por exemplo, a frequente adoção de novos loaders, bem como algumas separações de interfaces em pacotes específicos, como mais recentemente a separação dos splitters em um próprio pacote, chamado langchain-text-splitters.

Mas confesso que eu só percebi as mudanças mais significativas no framework quando eu refiz o treinamento do LangChain oferecido pela DeepLearning.ai. Refazer o treinamento, que possivelmente foi desenhado em alguma versão 0.0.x, mas já utilizando versões 0.1.x, me fez perceber o quanto que o treinamento envelheceu rápido. As APIs que foram usadas no treinamento já estavam depreciadas, ou mesmo removidas. Refazer o treinamento se tornou bem difícil.

Inclusive, com a introdução do LCEL, alguns usos importantes do framework mudaram drasticamente. Acredito que a visão é que o LCEL se torne a forma padrão para uso do framework. No entanto, enquanto o framework migra suas paulatinamente suas interfaces para o LCEL, é preciso conviver com as interfaces antigas junto com as novas.

Problemas observados com o LangChain

Listo aqui alguns problemas observados.

Dificuldade de uso

O LangChain apresenta uma complexidade desnecessária para tarefas simples, incorporando múltiplas classes de objetos e templates de prompts que complicam operações básicas.

Essa abordagem aumenta o esforço de codificação e compreensão, fazendo com que tarefas que poderiam ser realizadas com poucas linhas de código em bibliotecas padrão exigem estruturas mais elaboradas e menos intuitivas no LangChain. Esse excesso de complexidade não apenas dificulta o aprendizado por novos usuários, mas também desencoraja a adoção para projetos menores ou menos complexos.

É verdade que o LCEL simplifica boa parte desse processo, mas, como mencionado anteriormente, o LCEL ainda não cobre amplamente os diversos usos do framework.

Documentação desatualizada

Talvez por conta do desenvolvimento acelerado do framework (vários releases por mês, e até por semana), alguns pontos da documentação não foram atualizados na mesma velocidade.

Por conta disso, não era incomum encontram exemplos de trechos de códigos que não funcionam conforme esperado sem modificações adicionais. Isso acontecia por uso de dependências desatualizadas ou falta de explicações claras. Para um projeto open source, documentação é chave, e alguns pequenos problemas acabam por desencorajar potenciais usuários. Isso era particularmente frustrante quando os demais exemplos de código que encontrava usavam versões diferentes das APIs. Imagina a mistura.

Falta de clareza sobre uso dos Agents

Agents e tools são funcionalidades que tem grande potencial de uso. Agents servem para orquestrar a interação entre diferentes tools e uma LLMs, permitindo descobrir e executar ações complexas em sequência.

No entanto, a documentação sobre como Agents e tools funcionam ainda é vaga, deixando os usuários sem uma compreensão clara de como funcionam ou como implementar de maneira eficaz. Lembro de discutir extensivamente sobre quais são os potenciais cases de uso de Agents com alguns colegas.

O processo de descoberta de tools por um Agent é algo pouco claro. Por exemplo, não sabemos como as tools são selecionadas e utilizadas dentro de um fluxo de Agent, ou como os resultados são gerenciados e apresentados.

O processo de tratamento de exceção de agentes também é confuso; caso uma tool não seja encontrada, ou caso a tool retorne um erro, o usuário tem pouco controle do fluxo excepcional, reduzindo a eficácia geral do sistema.

Mas afinal, devo usar o LangChain?

Apesar das limitações mencionadas acima, ainda acredito que o uso do LangChain é muito benéfico, principalmente para aqueles que estão iniciando sua jornada no processo de criação de aplicações baseadas em LLMs.

O LangChain facilita muito o processo de carregamento de conteúdo externas, processamento dos dados, criação de embeddings, armazenamento de dados em bancos de dados vetoriais, etc. Inclusive, no bootcamp LLM4Devs, nós usamos o LangChain para criar uma aplicação RAG simples, em poucas horas.

Ademais, o problema da complexidade do uso do LangChain deve ser minimizado nas próximas versões, principalmente com a estabilização da LCEL.

Pra finalizar, não custa lembrar que essas são apenas as minhas próprias observações, baseada no meu uso da ferramenta. Aconselho você leitor a avaliar suas próprias percepções, antes de tomar uma decisão sobre usar (ou não) o framework.

Comecei essa newsletter com dois objetivos:

1. estudar e me desenvolver profissionalmente nessa área de ML4SE; e

2. me aproximar da comunidade de desenvolvedores de software.

Assumi o compromisso de escrever nessa newsletter por um ano.

Aos trancos e barrancos, fico muito feliz em mencionar que este é 40o texto dessa newsletter. Obrigado a todos vocês que acompanham esse trabalho, seja lendo os textos, compartilhando com colegas, dando likes nas redes sociais, etc. Meu muito obrigado!

Agora é hora de refletir um pouco sobre o que rolou.

Tem vontade de criar uma newsletter e não sabe o que esperar? Talvez esse texto ajude a gerenciar as expectativas.

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 18/05/2024 (sábado), vai rolar um bootcamp online de 3h de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos que serão abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E mais, se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs:

Interessou? Clique aqui e saiba mais:

Bootcamp LLM4Devs

O que é ML4SE?

ML4SE, do Inglês, Machine Learning for Software Engineering, é uma área de pesquisa que utiliza de técnicas de Machine Learning para resolver problemas da Engenharia de Software.

ML4SE é uma área relativamente conhecida no submundo da Engenharia de Software. Quando criei essa newsletter, pensei que esse termo seria também facilmente transposto, e que as pessoas iriam assimilar essa confusão de letras com um número no meio com facilidade. Obviamente me enganei.

Algumas pessoas já me abordaram para falar da newsletter, sem conseguir pronunciar o nome da newsletter. Só assim para eu perceber que não somente as pessoas tem dificuldades em gravar o nome, mas também que o nome não é facilmente pronunciável.

Ou seja, ML4SE é um péssimo nome para uma newsletter.

Vez por outra me pego pensando em qual seria um nome melhor. Confesso que ainda não cheguei a uma conclusão, mas é possível que essa newsletter mude de nome nos próximos meses.

Escrever quando seu trabalho não é escrever

A newsletter nasceu com a tentativa de publicar textos semanalmente. Como escritor acadêmico, minha soberba insistia em dizer que escrever mil palavras por semana seria uma atividade simples e prazerosa.

Nos primeiros 3, 4 meses, eu até que conseguir manter essa disciplina (inclusive houveram semanas que eu publiquei mais de um texto). No entanto, rapidamente percebi que mais importante do que conhecer algumas técnicas de escrita, é conseguir emprega-las regularmente.

Isso, de certa forma, foi um conhecimento novo pra mim. Como acadêmico, parte do seu trabalho é escrever. Você escreve regularmente porque o seu trabalho é escrever regularmente. Agora que coloquei minhas barbas acadêmicas de molho, escrever regularmente não é mais o meu trabalho; ao menos, não é mais o que paga as contas.

Logo, eu preciso arrumar tempo para escrever. Da mesma forma que se arruma tempo para fazer esportes, ir ao supermercado, levar o cachorro para passear, é preciso arrumar tempo para escrever. Escrever passa a competir com todas as demais atividades do dia a dia. Consequentemente, escrever, quando seu trabalho não é escrever, é muito mais difícil.

Um salve a todos vocês que escrevem mesmo que escrever não seja seu ganha pão!

Frequência de escrita

Começar a escrever na newsletter foi fácil. Como qualquer atividade nova, você tende a começar empolgado, ainda mais quando você entende das técnicas da atividade em questão. Mas entender das técnicas não é tudo.

A figura acima contabiliza o número de textos por mês.

Depois de escrever 10 textos entre Maio e Junho de 2023, não demorou muito para a periodicidade diminuir, até cair por completo. Em Julho e Agosto de 2023, reduzi para o esperado número de 4 textos por mês. Mas em Setembro de 2023 eu perdi a sequencia de textos pela primeira vez. Em Outubro de 2023 eu consegui retomar ao 4 textos mensais. Mas…

Entre Novembro 2023 e Dezembro 2023 eu publiquei apenas 5 textos. Em Janeiro de 2024, por outro lado, eu não escrevi nenhum texto. Lembro que naquele momento eu me questionava sobre a continuidade da newsletter. Mais sobre isso a seguir.

Em Fevereiro e Março de 2024 consegui retomar, com uma boa frequência (7 textos publicados nos dois meses), mas Abril novamente quase não escrevi na newsletter. Diferente de Janeiro, em Abril eu de fato gostaria de ter escrito (e tinha vários textos em mente), mas um mix de viagens, doenças e outros afazeres, me afastaram do teclado.

Chegamos na segunda semana de Maio, e este é o segundo texto do mês. Embora eu, como escritor dessa newsletter, ainda trabalharei a mentalidade para manter a periodicidade semanal dos textos, talvez, como leitor dessa newsletter, aguardar 2—3 textos por mês seja algo mais próximo do real.

Quantidade de conteúdo escrito

Esses 40 textos geraram 58.306 palavras, o que é equivalente a um pequeno livro de umas 150 páginas.

Para cada texto, eu tento escrever o mínimo de mil palavras. Como é possível perceber pela figura acima, em 36 dos 40 textos, consegui chegar nesse limite mínimo.

Por outro lado, eu não tenho nenhum limite máximo de palavras por texto. Como eu tento escrever o texto todo de uma única vez, geralmente eu termino 1) por cansaço ou 2) por precisar alternar para uma outra atividade. Deixar o texto para terminar outro dia pra mim é o pior cenário, que eu evito a todo custo.

Qualidade do conteúdo escrito

Na queda de braços entre velocidade e qualidade, eu tendo a priorizar a velocidade na escrita e publicação dos textos da newsletter. Eu muito raramente eu faço edições textuais finas, com o objetivo de melhorar a qualidade do conteúdo escrito. Ou seja, depois de escrever a última linha, o mais provável é que eu clique em “publicar”.

Com isso, os erros de digitação e as sentenças sem sentido acabam indo de brinde para o leitor. Confesso que isso não é algo que eu me preocupe. Desde que comecei a escrever irregularmente em mídias sociais, eu entendi que se for para refinar o texto de um blog (ou, nesse caso, da newsletter) com o mesmo esmero que eu faço em um artigo científico, o mais provável é que esse texto nunca venha a existir.

Vez por outra algum leitor aponta alguns desses erros, o que eu prontamente corrijo. E por mim está tudo bem, pois entre ter um texto de qualidade subótima e não ter o texto, eu prefiro o primeiro caso.

Crescimento da newsletter

Ao iniciar a newsletter, eu imaginava que um grande número de usuários iria encontra-la e, como em um passe de mágica, eu teria uma rica base de usuários. Mas não é bem assim que funciona.

Hoje entendo claramente que a base de usuários só cresce a medida que eu escrevo novos textos. Mas não somente escrever: eu preciso também divulgar esse material.

Confesso que essa parte de divulgação e marketing do conteúdo é uma habilidade que eu ainda não trabalho bem, mas sinto que consegui avançar alguns centímetros. Mas não tem muito atalho. Tem que manter o fluxo de escrita de textos.

Com relação a base de usuários, no momento que escrevo esse texto, a newsletter tem 170 assinantes!

Como podemos perceber na curva de crescimento de usuários, durante Novembro 2023 e Janeiro 2024, a newsletter quase que estagnou.

Estagnação da newsletter

Como comentei acima, durante Dezembro 2023 e Janeiro 2024 eu pensei fortemente em deixar a newsletter de lado. Há dois principais motivos:

• Baixo retorno: E aqui eu nem estou falando de retorno financeiro. É retorno no sentido de conseguir criar uma comunidade de leitores interessados no conteúdo. Observar crescimentos meteóricos de outros autores de newsletter me fez acreditar que eu também poderia passar por algo parecido. Demorei para perceber que o jogo da criação de conteúdo é o do longo prazo.

• Não entender que o cliente sou eu. Embora escrever seja uma atividade que eu me considero tecnicamente habilidoso, a obrigatoriedade de escrever regularmente, sobre temas diferentes, muitos dos quais eu não domino, gerou por vezes um estresse que eu não conseguia justificar pra mim mesmo. Ora, se ninguém pediu pra eu fazer isso, por que diachos eu deveria estar me estressando? Se estou cansado, é só parar de escrever, não? Depois de tanto tempo trabalhando para os outros, eu demorei pra entender que eu não criei essa newsletter para ajudar alguém; eu criei para me ajudar a me tornar um profissional melhor. Se eu ajudar alguém ao longo do processo, ótimo. Mas o objetivo inicial não era esse.

Eu esqueci que eu sou o principal beneficiário dessa newsletter. Eu esqueci qual era o meu propósito com a newsletter.

Sem um propósito claro, escrever aqui se tornou chato, maçante. Virou mais uma daquelas obrigações da vida adulta que a gente precisa cumprir.

Ter claro os objetivos da newsletter me ajudaram a colocar os pingos nos is. Escrever esse texto, agora, reforça o meu objetivo com essa newsletter. (Não obstante, este está sendo um texto muito gratificante de escrever :-)

Visibilidade dos textos

A newsletter atraiu 9.001 visualizações durante esse primeiro ano. O texto mais visualizado foi o “Não use o ChatGPT para gerar testes de unidade”, com 443 visualizações.

A newsletter tem uma taxa de abertura de 39.9%. Nunca cheguei a investigar outras taxas, mas confesso que considero essa uma boa taxa de abertura.

Embora nenhum texto tenha viralizado na rede, eu considero bem interessante esses números. Não tenho dados para comparar com meus textos acadêmicos, mas acredito que poucos são os artigos que eu tenho mais de 400 visualizações — mesmo estes estando disponíveis em grandes sites de editoras.

Organização para escrever

Eu fico impressionado com algumas newsletters que eu assinto. Religiosamente, o texto está na minha caixa de entrada, toda a semana, no mesmo horário.

Esse é um nível de disciplina que eu não consigo nem entender direito. Eu fico feliz só de conseguir escrever algo na semana corrente; manter o fluxo de textos no mesmo dia e horário pra mim é algo impensável :-)

Por algum tempo eu escrevia aos domingo, de tarde/noite. Mas como domingo é um dia bem família, eu mentalmente tendia a deixar pro último minuto possível (até chegar ao ponto de tardiar para segunda). Tentei também planejar a escrita para dias como quarta-feira e/ou sexta-feira. Mas, sinto que ter um dia fixo não funciona bem comigo, uma vez que vez por outra tem algum evento social que colide com o dia de escrita, tardiando mais um texto na newsletter.

Mas, no fim, não tenho dia certo para escrever. Escrevo, quando dá.

Por outro lado, quando eu escrevo, eu tendo a escrever todo o texto de uma única vez. Eu evito quebrar escrita do textos em múltiplos dias, uma vez que isso cai no problema de competir com eventos sociais, deixando a escrita do texto pro último minuto possível.

Uso de ferramentas de IA

Embora eu sempre escreva miolo do conteúdo, eu regularmente uso o ChatGPT em algumas partes do conteúdo. Por exemplo, para identificar erros de sintaxe ou fazer pequenas melhorias no texto, eu uso um prompt do tipo: “Faça apenas pequenas melhorias ortográficas no texto abaixo”.

Em outros casos, eu peço para o ChatGPT gerar algum conteúdo que eu possivelmente já escrevi algumas outras vezes (e estou com pouco interesse em escrever novamente), algo como “Escreva 40 palavras sobre embeddings”. Também recorrentemente uso o ChatGPT para escrever a conclusão dos textos (p.e., “Dado esse texto de blog, escreva uma conclusão em 30 palavras”).

Além do ChatGPT, as figuras que acompanham os textos também são geradas com ferramentas de IA. Testei várias ferramentas ao longo desse ano. Mais recentemente, tenho usado somente o DALL-E 3.

Monetização da newsletter

Na internet tem vários exemplos de newsletters bem sucedidas, em que o autor da newsletter recebe algumas dezenas (centenas?) de milhares de dólares, como resultado de uma rica base de usuários que confiam no conteúdo compartilhado.

Esse claramente não é o caso dessa newsletter :-)

Embora exista uma versão paga dessa newsletter (que eu confesso nem lembrar qual é o valor), não há nenhum assinante pago cadastrado. Algumas pessoas já me consultaram para saber quais outros benefícios elas teriam acesso, caso mudassem para um plano pago. Infelizmente, não há outro benefício ao assinante.

Eu já cheguei a pensar algumas ações que poderia desenvolver na newsletter paga (como textos mais profundos, vídeos explicando os textos já escritos, etc), mas acho que em nenhuma dessas ações eu achei interessante o suficiente para agregar valor aos assinantes — acho que nem mesmo eu pagaria para assinar a minha newsletter.

Dessa forma, a newsletter não gera nenhum retorno financeiro diretamente. No entanto, criar a newsletter me fez perceber outras formas de monetização

Monetização inspirada pela newsletter

Embora esta newsletter não monetize diretamente, ela ajudou a monetizar indiretamente.

Através da newsletter, eu percebi que existia uma demanda para criação de material técnico mais profundo. Por conta disso, comecei a criar alguns cursos técnicos, e divulgar aqui pela newsletter. Até o momento, já criei três cursos:

• Converse com seus Documentos

• Entendendo Embeddings

• Dominando Estratégias de Chunking

Como esses cursos são gravados, os alunos tem poucas chances de interagir com outros alunos e também comigo, como instrutor desses cursos. Por conta dessa falta de interação, algumas pessoas me consultaram sobre a possibilidade de realiza-los em um formato síncrono. Pensando nessa demanda, nasceu o Bootcamp LLM4Dev, um treinamento de 3h focando em como criar aplicações baseadas em LLMs.

Mas nenhum desses materiais teria sido construído se não existisse a newsletter. Ao escrever, compartilhar, receber feedback e refletir em cima, deu pra observar novas demandas que, por sua vez, puderam ser monetizadas.

Agradecimentos

Talvez essa newsletter não teria existido se não fosse o Alberto Tavares. Lá no passado, o Alberto já tinha me provocado na possível criação de um serviço de resumos de textos científicos. A idéia parecia boa, mas acabou que não foi pra frente. Mas a semente tinha sido plantada.

Preciso também agradecer a todos vocês que lêem meu conteúdo, que compartilham com colegas, que me ajudam indicando meus erros (sejam eles técnicos ou de ortografia), etc. Saber que tem alguém do outro lado da linha é muito gratificante pra esse trabalho, que é majoritariamente sozinho.

Obrigado!

No entanto, os LLMs enfrentam limitações no que diz respeito ao conhecimento atualizado ou ao conhecimento específico de domínio atualmente capturado nos repositórios da empresa. Duas opções para abordar esse problema são:

1. Fine-tuning dos LLMs (continuação do treinamento de um LLM usando artefatos específicos do domínio), o que requer a gestão ou hospedagem de um LLM refinado; ou

2. Usar abordagens de Retrieval-Augmented Generation (RAG), que dependem de LLMs para a geração de respostas usando artefatos de conhecimento existentes (e extensíveis).

Ambas as opções têm prós e contras relacionados à privacidade/segurança dos dados, escalabilidade, custo, habilidades necessárias, etc. Neste texto, nos concentramos em algumas limitações das abordagem do RAG.

📚 Você é dev e quer criar aplicações baseadas em LLMs?

No próximo dia 18/05/2024 (sábado), vai rolar um bootcamp online de 3h de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos que serão abordados:

🟠 Entendendo sobre LLMs

🟣 Testando prompts e engenharia de prompts

🔵 Entendendo de embeddings

🟢 Comparando dados por similaridade

🟡 Conectando com um banco vetorial

E mais, se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs:

Interessou? Clique aqui e saiba mais:

Quero conhecer o Bootcamp LLM4Devs

RAG Overview

Os sistemas baseados em RAG oferecem uma solução atraente para esse desafio.

Ao integrar mecanismos de recuperação com as capacidades generativas dos LLMs, os sistemas RAG podem sintetizar informações contextualmente relevantes, precisas e atualizadas. Um sistema baseado em RAG combina capacidades de recuperação de informações e a habilidade generativa dos LLMs.

O componente de recuperação se concentra em recuperar informações relevantes para uma consulta de um usuário a partir de um repositório de dados. O componente de geração, por sua vez, usa essas informações recuperadas como contexto para gerar uma resposta para a consulta.

Os sistemas RAG são um caso de uso importante, já que todas as informações não estruturadas podem agora ser indexadas e disponibilizadas para consulta, reduzindo o tempo de desenvolvimento, sem necessidade de criação de, por exemplo, grafos de conhecimento e com pouca curadoria dos dados.

Engenheiros de software construindo sistemas RAG devem pré-processar o conhecimento de domínio capturado como artefatos em diferentes formatos, armazenar informações processadas em um banco de dados apropriado, implementar estratégias de busca adequadas, classificar os artefatos correspondentes e chamar a API dos LLMs passando consultas de usuários e documentos de contexto.

Limitações do RAG

No artigo “Seven Failure Points When Engineering a Retrieval Augmented Generation System”, os autores exploraram 3 sistemas baseados em RAG, de forma a identificar suas limitações.

Estudos de caso

O artigo conduziu três estudos de caso para descobrir os desafios que surgem ao implementar sistemas RAG.

• Cognitive Reviewer: O Cognitive Reviewer é um sistema baseado em RAG que apoia pesquisadores na análise de documentos científicos. Ele permite que eles carreguem artigos de pesquisa relacionados a uma pergunta ou objetivo específico. Os documentos são classificados e disponíveis para revisão manual, e os pesquisadores podem fazer perguntas diretamente aos documentos. O sistema processa documentos em tempo real e usa um algoritmo de classificação para ordenar os documentos carregados.

• AI Tutor: O AI Tutor é um sistema RAG integrado ao sistema de gestão de aprendizagem de uma Universidade. Ele permite que alunos façam perguntas sobre o conteúdo do curso, com respostas obtidas do material de aprendizagem, incluindo PDFs, vídeos e textos. Vídeos são transcritos e fragmentados pelo modelo Whisper. O sistema também inclui um reescritor para consultas, considerando o contexto.

• Biomedical Q&A: Este sistema RAG foi criado usando um dataset científico, composto por perguntas, respostas e links para documentos. O dataset contém pares de perguntas e respostas no domínio biomédico, com respostas de tipos variados. Foram indexados 4.017 documentos e 1.000 perguntas.

Limitações de sistemas baseados em RAG

A partir dos estudos de caso, os autores identificaram uma sete principais limitações. São elas:

• Conteúdo ausente. O primeiro caso ocorre ao fazer uma pergunta que não pode ser respondida pelos documentos disponíveis. No caso positivo, o sistema RAG responderá algo como "Desculpe, não sei". No entanto, para perguntas relacionadas ao conteúdo, mas que não têm respostas, o sistema pode ser enganado a dar uma resposta incorreta.

• Documentos melhor ranqueados faltantes. A resposta para a pergunta está em um documento existente, mas este não foi classificado alto o suficiente para ser retornada ao usuário. Em teoria, todos os documentos são classificados e usados nas próximas etapas. No entanto, na prática, somente os K-principais documentos são retornados, onde K é um valor selecionado com base no desempenho

• Documentos não selecionados para adicionar contexto. Documentos com a resposta foram recuperados do banco de dados, mas não foram selecionados para adicionar contexto para gerar uma resposta. Isso ocorre quando muitos documentos são retornados do banco de dados e um processo de consolidação ocorre para buscar a resposta.

• LLM não identificou o documento. Aqui, a resposta está presente no contexto fornecido ao LLM, mas o modelo de linguagem não conseguiu identificar e extrair a resposta correta. Normalmente, isso ocorre quando há muito ruído ou informações contraditórias no contexto.

• Formato Inadequado. A pergunta envolvia a extração de informações em um determinado formato, como uma tabela ou lista, e a LLM ignorou esta instrução.

• Especificidade Incorreta. A resposta é retornada pela LLM, porém não é específica o suficiente (ou é muito específica) para atender à necessidade do usuário. Esse problema também ocorre quando os usuários não têm certeza de como fazer uma pergunta (e lançam perguntas muito gerais).

• Incompleto. Respostas incompletas não são incorretas, mas perdem algumas das informações, mesmo que essas informações estejam no contexto e disponíveis para extração. Um exemplo de pergunta, como "Quais são os pontos-chave abordados nos documentos A, B e C?" Uma abordagem melhor seria fazer essas perguntas separadamente.

Conclusão

Os LLMs oferecem novas capacidades para engenheiros de software, permitindo a construção de soluções inovadoras. No entanto, eles enfrentam limitações no acesso a conhecimentos atualizados ou específicos de domínios capturados em repositórios corporativos. Sistemas baseadas em RAG emergem como uma solução, integrando capacidades de recuperação de dados e geração de respostas com precisão contextual.

O artigo “Seven Failure Points When Engineering a Retrieval Augmented Generation System” examina os desafios de implementar sistemas RAG, apresentando estudos de caso que revelam pontos falhos cruciais.

O estudo conclui que a implementação eficaz de sistemas RAG requer um equilíbrio entre pré-processamento de artefatos, armazenamento de dados, estratégia de busca e integração com APIs de LLMs, destacando o papel fundamental de desenvolvedores na superação dessas limitações para sistemas RAG robustos e eficazes.

Similar as ferramentas (tools) usadas no mundo real, as tools usadas por LLM também devem ser externas ao empregador (isto é, o LLM) e são parte do ambiente.

Como as LLMs são produtos do mundo digital, uma tool é uma função (por exemplo, soma_um()) executada nos seus ambientes correspondentes; por exemplo, programas Python são executáveis em ambientes Python.

Dessa forma, uma tool pode ser aplicada a outros objetos (por exemplo, dados) e produzir uma saída (por exemplo, soma_um(1) → 2).

Nesse texto, vamos entender um pouco mais sobre esse novo paradigma de programação: O uso de tools executada externamente a LLM, que por sua vez gera as chamadas a função e argumentos de entrada para usar a tool.

📚 Você é dev e quer aprender um pouco mais sobre a criação de aplicações baseadas em LLM?

Eu criei um curso que aborda aspectos teóricos e práticos do desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos cobertos:

🟠 O que são e como criar embeddings
🟡 Como selecionar partes relevantes nos seus documentos
🔵 Como integrar essas partes documentos com uma LLM

Achou legal? Clica aqui!

Como uma tool é integrada a uma LLM?

Assumindo que uma LLM comunica com usuários principalmente em linguagem natural, ao receber uma consulta de usuário como "Como está o tempo hoje?", o LLM então procede para gerar texto ou chamadas de uma tool. Por exemplo, a LLM começa gerando alguns tokens de texto "Está...".

Quando a LLM precisa buscar tools externas para completar a tarefa, por exemplo, obter informações meteorológicas em tempo real, ele gera tokens com o nome da tool e argumentos de entrada dentro de parênteses para construir uma expressão completa de chamada da tool. Esta expressão completa acionará uma mudança do modo de geração de texto para o modo de execução da tool. A tool será executada e retornará o resultado da execução para o LLM.

A LLM envia a chamada ao método check_weather() retorna a saída "ensolarado". O resultado retornado substitui a chamada da tool nos tokens gerados pelo LLM (por exemplo, de "Está check_weather()" para "Está ensolarado"), que é usado para etapas subsequentes de geração. Consequentemente, o LLM volta ao modo de geração de texto e continua a terminar a resposta gerando novos tokens de texto, por exemplo, adicionando "hoje.", e finalmente retornando a resposta ao usuário.

Por que tools são úteis?

Tools podem ajudar na resolução de tarefas de diferentes maneiras, dependendo da funcionalidade das tools. Tools podem ser divididas em três categorias:

• Percepção: Tools de percepção fornecem ou coletam informações do ambiente. Um exemplo é usar uma API get_time() para obter a hora atual, que não está incluída no conhecimento paramétrico do LLM aprendido durante o treinamento.

• Ação: Tools de ação podem exercer ações sobre o ambiente e mudar seu estado. Por exemplo, turn_left() pode mudar a direção de um agente incorporado, ou executar make_post(website, post) pode mudar o conteúdo em um site.

• Computação: Tools de computação não necessariamente percebem ou modificam o ambiente externo, mas usam programas para lidar com tarefas computacionais complexas. Por exemplo, uma calculadora é uma tool de computação para cálculo matemático. Note que a computação também inclui atos mais gerais de computação além do cálculo numérico. Portanto, um tradutor também é uma tool de computação que pode ser usada para traduzir entre idiomas.

Note que muitas tools podem se encaixar em múltiplas categorias. Por exemplo, um motor de busca é uma tool que pode realizar tanto computação quanto percepção.

Como computação, ele mede a similaridade de documentos e seleciona os relevantes, mas também percebe o ambiente (ou seja, a web) e busca dados (ou seja, documentos retornados) dele.

Da mesma forma, consultas SQL podem ser usadas como tools de computação (por exemplo, SELECT SQRT(16) / 10 AS result), tools de percepção para visualizar dados (por exemplo, SELECT name FROM data), tools de ação para modificar dados (por exemplo, INSERT INTO data VALUES name), ou todas as acima.

Tools e Agentes

Recentemente, houve um crescimento de trabalhos sobre agentes alimentados por LLMs. Russell & Norvig (2010) definem agentes como "qualquer coisa que pode ser vista como percebendo seu ambiente através de sensores e atuando sobre esse ambiente através de atuadores."

De acordo com essa definição, agentes são programas que usam tools de percepção para perceber o ambiente situado, ou tools de ação para interagir com o ambiente. Modelos que usam apenas tools de computação e não interagem com seus ambientes através de tools de percepção ou ação não se enquadram na categoria de "agentes" de acordo com esta definição.

Quando tools são úteis?

Embora seja difícil enumerar exaustivamente cada cenário onde tools poderiam ser úteis, resumimos algumas categorias principais do uso de tools abaixo. Note que uma tool pode se encaixar em uma ou mais categorias.

• Acesso ao conhecimento: LLMs armazenam conhecimento limitado durante o treinamento devido a limites em (i) os dados nos quais são treinados e (ii) a capacidade dos LLMs de memorizar e utilizar todos os dados que veem no momento do treinamento. Várias tools podem ser usadas para aliviar essa questão. Executores de SQL e SPARL podem fornecer acesso a dados em bases de conhecimento estruturadas. Uma tool de busca na Internet pode permitir que LLMs acessem informações mais atualizadas.

• Atividades de computação: Atividades computacionais complexas, como cálculos matemáticos, são conhecidas por serem desafiadoras para LLMs. Enquanto até uma calculadora pode melhorar as habilidades numéricas de um LLM, programas Python mais genéricos também podem ser empregados para auxiliar tarefas de raciocínio. Para trabalhos profissionais mais complexos, tools podem também ser aplicadas, como usar worksheet para manipular Google Sheets, ou até mesmo tools para domínios financeiros, médicos, educacionais ou de publicidade.

• Interação com o mundo: LLMs sem tools são fundamentalmente incapazes de perceber e agir no mundo ao seu redor, necessitando do uso de tools onde tal percepção e ação sejam necessárias. Por exemplo, LLMs podem acessar informações em tempo real como o clima ou conhecimento posicional como localização. Por outro lado, LLMs podem manipular informações do mundo real como gerenciar calendários e e-mails. Além de atividades baseadas na web, LLMs podem se engajar em atividades físicas, como pescar com varas ou minerar com machados no mundo do Minecraft.

• Acessando LLMs especializados: Alguns trabalhos propõem usar LLMs especializados como tools, essencialmente usando o LLM principal como um planejador de tarefas para despachar solicitações para outros LLMs. Alguns pesquisadores usaram modelos de tradução automática para auxiliar tarefas multilíngues. Além de tarefas específicas, alguns trabalhos adotam múltiplos modelos neurais de plataformas como Hugginface ou similares (Patil et al., 2023; Shen et al., 2023a), ou os ajustam ainda mais em vários dados (Viswanathan et al., 2023). Comparado ao LLM base, esses modelos com tools desenvolvem habilidades especializadas, podendo ter diferenças arquitetônicas substanciais dos LLMs base.

Conclusão

As tools são interfaces para programas que operam externamente ao LLM, desenhadas para estender suas capacidades além da geração de texto.

Essas tools variam de programas simples, como calculadoras, a sistemas complexos de busca e executores de código, permitindo aos LLMs acessar informações atualizadas, realizar cálculos complexos e interagir com o ambiente de maneiras significativas.

Essa externalização de tarefas para tools especializadas permite que os LMs superem limitações inerentes ao seu treinamento e armazenamento de conhecimento, oferecendo uma abordagem mais dinâmica e adaptável à resolução de problemas.

Portanto, o uso de tools por LMs não só amplia o escopo de suas aplicações, mas também melhora a qualidade e a relevância das respostas fornecidas aos usuários, marcando um avanço significativo na interação humano-máquina e na inteligência artificial aplicada.

Query Expansion (QE) é uma técnica utilizada em sistemas de Information Retrieval (IR) que ajuda a melhorar a capacidade do sistema de recuperar todos os documentos relevantes para uma determinada consulta. A QE adiciona termos adicionais à consulta original, ajudando a recuperar documentos relevantes que não tinham palavras em comum (sobreposição lexical) com a consulta original.

Neste artigo, os autores propõe o uso de LLMs para auxiliar na expansão de consultas. Por exemplo, dado uma consulta, podemos pedir para o LLM gere uma variedade de termos alternativos. Dessa forma, em vez de fazer uma única busca com o input do usuário, podemos fazer várias buscas, com os termos fornecidos pela LLM; e assim ser capaz de encontrar documentos que poderiam não ser identificados pela consulta original.

Hoje, usar QE tem se tornado uma etapa comum no pipeline de sistemas baseados em LLMs. Nesse texto, vamos revisitar a área de recuperação e informação para explicar como funciona uma query expansion.

📚 Você é dev e quer aprender um pouco mais sobre a criação de aplicações baseadas em LLM?

Eu criei um curso que aborda aspectos teóricos e práticos do desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos cobertos:

🟠 O que são e como criar embeddings
🟡 Como selecionar partes relevantes nos seus documentos
🔵 Como integrar essas partes documentos com uma LLM

Achou legal? Clica aqui!

Information Retrieval

A recuperação de informação (IR, do inglês "Information Retrieval") visa localizar documentos relevantes de um vasto corpus, com base em uma consulta realizada pelo usuário. Esse processo é um componente essencial nos motores de busca modernos, e pesquisadores têm investido nesse campo por décadas.

Existem dois paradigmas principais para a IR:

• A recuperação esparsa baseada em léxico, como o BM25, e

• A recuperação densa baseada em embeddings.

Busca Lexica

A recuperação esparsa baseada em léxico, exemplificada pelo algoritmo BM25, é um método tradicional que avalia a relevância de documentos com base na presença e frequência de palavras-chave da consulta do usuário nos documentos.

Esse método considera a importância das palavras dentro dos documentos e em todo o corpus, permitindo identificar documentos relevantes através da análise de termos específicos.

Busca Densa

Por outro lado, a recuperação densa baseada em embeddings representa documentos e consultas como vetores em um espaço contínuo, utilizando técnicas de aprendizado profundo para capturar o significado semântico das palavras e frases.

Essa abordagem permite uma comparação mais sofisticada entre consultas e documentos, identificando relevâncias mesmo quando as palavras-chave exatas não estão presentes, graças à capacidade de captar nuances semânticas e contextuais.

Busca Lexica ou Densa?

Ambas as abordagens têm seus méritos e são empregadas dependendo das necessidades específicas do sistema de busca.

A busca léxica é notável pela sua simplicidade e eficácia em situações onde a correspondência exata de termos é crucial, enquanto a recuperação baseada em embeddings é interessante pela sua capacidade de entender e conectar conceitos semânticos mais amplos, promovendo uma busca mais intuitiva e flexível.

Query Expansion Tradicional

A Query Expansion é uma técnica consolidada, proposta inicialmente por Rocchio em 1971, que visa melhorar os sistemas de busca ao reescrever a consulta original do usuário.

Essa reescrita é realizada com base em feedback de pseudo-relevância ou em fontes de conhecimento externas, como o WordNet. Tal abordagem é particularmente útil para a busca densa, ajudando a superar o desafio do “gap” lexical entre a consulta e os documentos.

Ao adicionar termos adicionais à consulta original, a consulta expandida tende a ampliar significativamente a capacidade de recuperar documentos relevantes que, de outra forma, não teriam sobreposição lexical com a consulta inicial.

Este método é amplamente estudado e reconhecido por sua capacidade de expandir os termos de consulta para novos termos que expressam o mesmo conceito ou necessidade de informação, aumentando assim a probabilidade de correspondência lexical com documentos no corpus.

Query Expansion Baseada em LLM

Recentemente, o uso de Query Expansion foi enriquecida com o uso de LLMs. Através dos LLMs, é possível gerar múltiplas consultas a partir de uma única pergunta. Essas consultas podem ser executadas em paralelo, e os resultados obtidos são agregados para fornecer uma resposta mais abrangente.

Essa estratégia é especialmente útil para questões complexas que podem ser decompostas em múltiplas subquestões.

Por exemplo, a pergunta “Qual é o maior artilheiro da copa do mundo FIFA de futebol?” poderia ser expandida para as seguintes perguntas:

• “Quem detém o recorde de mais gols marcados em uma única edição da Copa do Mundo FIFA de Futebol?”

• “Qual jogador tem o maior número de gols na história das Eliminatórias da Copa do Mundo FIFA?”

• “Quem lidera a lista de artilheiros de todos os tempos da seleção nacional em Copas do Mundo FIFA?”

Essa abordagem permite melhorar o recall ao adicionar termos relacionados à consulta original, aumentando assim a abrangência da busca e a chance de recuperar documentos relevantes que poderiam ser perdidos devido a variações linguísticas ou sinônimos não presentes na consulta inicial.

Ao incorporar palavras e frases que expressam o mesmo conceito ou estão semanticamente relacionadas, a busca se torna mais inclusiva, capturando uma gama mais ampla de documentos que satisfazem a necessidade de informação do usuário.

Conclusão

A Query Expansion (QE) introduz uma abordagem sofisticada e adaptável para melhorar a precisão e o alcance das buscas realizadas pelos usuários.

Este artigo explorou a interseção entre técnicas tradicionais de QE e as capacidades avançadas proporcionadas por LLMs, demonstrando como essa combinação pode superar limitações anteriores e abrir novos caminhos para a recuperação eficaz de informação.

Ao empregar LLMs na geração de consultas expandidas, os sistemas de IR podem agora abordar consultas complexas e ambíguas com uma precisão sem precedentes, adaptando-se melhor às intenções dos usuários e ao contexto semântico das suas buscas.

No entanto, devido à compressão de informações em vetores, o RAG pode recuperar documentos pouco relevantes, comprometendo a eficácia da busca.

Como forma de amenizar esse problema, algumas arquiteturas propõem a implementação de uma etapa extra no desenho de sistemas baseados em LLM — um sistema de reranking, onde os documentos recuperados inicialmente são posteriormente reordenados de acordo com a sua relevância em relação à consulta.

Essa abordagem maximiza a eficácia da recuperação, garantindo que os documentos mais relevantes sejam apresentados ao usuário, melhorando assim a precisão e relevância das respostas fornecidas pelo RAG.

Ao minimizar a quantidade de documentos irrelevantes passados para o modelo de linguagem, a qualidade das respostas geradas é significativamente aprimorada, mitigando o problema inicial de retorno de informações pouco relevantes.

📚 Você é dev e quer aprender um pouco mais sobre a criação de aplicações baseadas em LLM?

Eu criei um curso que aborda aspectos teóricos e práticos do desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos cobertos:

🟠 O que são e como criar embeddings
🟡 Como selecionar partes relevantes nos seus documentos
🔵 Como integrar essas partes documentos com uma LLM

Achou legal? Clica aqui!

Limitações da busca semântica

Com o RAG, estamos realizando uma busca semântica em muitos documentos de texto — estes podem ser de dezenas de milhares até dezenas de bilhões de documentos.

Para garantir tempos de busca rápidos em escala, geralmente usamos busca vetorial — ou seja, transformamos nosso texto em vetores, inserimos estes em um espaço vetorial e comparamos sua proximidade com um vetor de consulta usando uma métrica de similaridade, como a similaridade cosseno.

Para que a busca vetorial funcione, precisamos de vetores.

Esses vetores são essencialmente compressões do “significado” por trás de algum texto em vetores (tipicamente) de 768 ou 1536 dimensões. Há alguma perda de informação porque estamos comprimindo essa informação em um único vetor.

Devido a essa perda de informação, frequentemente observamos que os principais documentos da busca vetorial não são necessariamente os mais relevantes.

Agora imagine, por exemplo, que algum documento em uma posição inferior (lá pelo 20o ou 25o) poderia ajudar nossa LLM a formular melhores respostas. O que fazer?

Limite da Janela de Contexto

Uma solução mais simples seria aumentar o número de documentos que estamos retornando (ou seja, aumentar o top_k) e passar todos esses documentos para a LLM.

No entanto, não podemos passar todos os documentos para nossa LLM. Primeiro pois as LLMs têm limites sobre quanto texto podemos passar para eles — chamamos esse limite de janela de contexto.

Mas, calma ai. Sabemos que algumas LLMs têm janelas de contexto enormes, como o Claude da Anthropic, com uma janela de contexto de 100K tokens, não é verdade?

Com isso, não poderíamos incluir muitas centenas de documentos até “preencher” a toda a capacidade da janela de contexto para melhorar a recuperação?

Novamente, não podemos usar preenchimento de contexto porque isso reduz o desempenho de recuperação do LLM, como evidenciado neste estudo científico, que percebeu que a qualidade da resposta da LLM degrada à medida que adicionamos mais tokens à janela de contexto.

Como podemos observar na imagem acima, a medida que aumentamos a quantidade de documentos que passamos para uma LLM, a capacidade de uma LLM de responder apropriadamente uma pergunta torna-se pior do que se o documento não tivesse sido fornecido em primeiro lugar.

Os LLMs também são menos propensos a seguir instruções à medida que preenchemos a janela de contexto — portanto, o preenchimento de contexto é uma má ideia.

Podemos aumentar o número de documentos retornados por nosso banco de dados vetorial para aumentar a recuperação da recuperação, mas não podemos passar esses documentos para nosso LLM sem prejudicar a recuperação do LLM.

ReRanking de documentos

Uma solução proposta para esse problema é maximizar a recuperação da recuperação, recuperando muitos documentos, e depois maximizar a recuperação do LLM minimizando o número de documentos que chegam ao LLM.

Para fazer isso, repriorizamos os documentos recuperados e mantemos apenas os mais relevantes para nosso LLM — para fazer isso, usamos um ReRanking.

Um modelo de ReRanking — também conhecido como um cross-encoder — é um tipo de modelo que, dado um par de consulta e documento, emitirá uma pontuação de similaridade. Usamos essa pontuação para reorganizar os documentos por relevância para nossa consulta.

Recuperação em dois estágios

Engenheiros de busca têm usado rerankers em sistemas de recuperação em dois estágios por muito tempo. Nestes sistemas são desenhados com dois estágios:

• Primeiro, um modelo de incorporação/retriever recupera um conjunto de documentos relevantes de um conjunto de dados maior.

• Segundo, um modelo de priorização (o reranker) é usado para reorganizar esses documentos recuperados pelo modelo de primeiro estágio.

Usamos dois estágios porque recuperar um pequeno conjunto de documentos de um grande conjunto de dados é muito mais rápido do que usar um ReRanker em um grande conjunto de documentos; RerRnkers são lentos e retreivers são rápidos.

Mas se um reranker é muito mais lento, por que se preocupar em usá-los? A resposta é que rerankers são muito mais precisos do que modelos de incorporação.

Busca semântica ou ReRanker?

A intuição por trás de uma busca semântica (ou bi-encoder) é que para realizar essas buscas, precisamos antes comprimir todos os documento em vetores, que é um processo lossy, o que significa que perdemos informação.

Por outro lado, um ReRanker pode receber as informações brutas diretamente, significando menos perda de informação. Como executamos o ReRanker no momento da consulta do usuário, temos o benefício adicional de analisar o significado de nosso documento específico para a consulta do usuário — em vez de tentar produzir um significado genérico médio.

Implementando um ReRank

Há diversas técnicas para criação de ReRankers.

Nesse texto vamos usar a biblioteca FlashRank, que é relativamente madura e possui integração com o LangChain.

Para instalar, basta um

pip install flashrank

Em seguida, basta criar o objeto Ranker.

from flashrank import Ranker, RerankRequest
ranker = Ranker()

Por fim, basta passar a query junto com os documentos selecionados. Estes documentos devem vir de uma busca semântica, mas, por simplicidade, vou defini-los diretamente no código:

query = "Como acelerar LLMs?"
passages = [
   {
      "id": 1,
      "text": "Introduza *lookahead decoding*: - um algoritmo de decodificação paralela para acelerar a inferência do LLM - sem a necessidade de um modelo preliminar ou armazenamento de dados - diminui linearmente o número de etapas de decodificação em relação ao log(FLOPs) utilizado por etapa de decodificação.",
      "meta": {"additional": "info1"}
   },
   {
      "id": 2,
      "text": "A eficiência da inferência do LLM será um dos tópicos mais cruciais tanto para a indústria quanto para a academia, simplesmente porque quanto mais eficiente você for, mais dinheiro economizará. O projeto vLLM é uma leitura obrigatória para esta direção, e agora eles acabaram de lançar o artigo.",
      "meta": {"additional": "info2"}
   },
   {
      "id": 3,
      "text": "Existem muitas maneiras de aumentar a taxa de transferência da inferência do LLM (tokens/segundo) e diminuir a pegada de memória, às vezes ao mesmo tempo. Aqui estão alguns métodos que descobri serem eficazes ao trabalhar com o Llama 2. Esses métodos são todos bem integrados com a Hugging Face. Esta lista está longe de ser exaustiva; alguns desses métodos podem ser usados em combinação entre si e há muitos outros para experimentar. - Bettertransformer (Biblioteca Ótima): Basta chamar `model.to_bettertransformer()` no seu modelo Hugging Face para uma melhoria modesta em tokens por segundo. - Fp4 Mixed-Precision (Bitsandbytes): Requer configuração mínima e reduz drasticamente a pegada de memória do modelo. - AutoGPTQ: Demorado, mas leva a um modelo muito menor e inferência mais rápida. A quantização é um custo único que se paga a longo prazo.",
      "meta": {"additional": "info3"}
   },
   {
      "id": 4,
      "text": "Já quis fazer sua inferência do LLM ir brrrrr, mas ficou preso na implementação da decodificação especulativa e na busca pelo modelo preliminar adequado? Não mais dor! Empolgado em apresentar Medusa, um framework simples que remove o irritante modelo preliminar enquanto obtém um aumento de velocidade de 2x.",
      "meta": {"additional": "info4"}
   },
   {
      "id": 5,
      "text": "vLLM é uma biblioteca rápida e fácil de usar para inferência e atendimento do LLM. vLLM é rápido com: Taxa de atendimento de última geração. Gerenciamento eficiente da memória de chave e valor de atenção com PagedAttention. Agrupamento contínuo de solicitações recebidas. Kernels CUDA otimizados.",
      "meta": {"additional": "info5"}
   }
]

Nesse exemplo, os metadados são opcionais. O ID pode ser o ID do seu banco de dados da etapa de recuperação.

Por fim, basta passar esses valores para os objetos RerankRequest e Ranker.

rerankrequest = RerankRequest(query=query, passages=passages)
results = ranker.rerank(rerankrequest)
print(results)

Conclusão

O reranking é um dos métodos mais simples que ajuda a melhorar o desempenho de recuperação no modelo do RAG.

Nesse texto, exploramos por que os rerankers podem oferecer um desempenho muito superior aos seus equivalentes de modelo de incorporação — e como um sistema de recuperação em dois estágios nos permite obter o melhor dos dois mundos, possibilitando a busca em grande escala enquanto mantemos um desempenho de qualidade.

No centro do LangChain está um componente conhecido como Chain, que cria a conexão central entre um ou vários grandes modelos de linguagem.

De maneira simplificada uma chain ajuda a pegar a saída de uma chamada à LLM e usá-la como entrada para um próximo passo (que pode inclusive ser uma outra chamada à LLM).

Imagine esta situação: uma chain é criada para receber a entrada do usuário, fazer algum refinamento e, posteriormente, passar essa resposta refinada para um modelo de linguagem. Dessa forma, torna-se possível conectar várias interações com a LLM.

Através da criação de chains, vários elementos podem se unir de maneira transparente.

Dessa forma, as chains nos proporcionam a capacidade de construir aplicativos complexos, ligando várias chains entre si ou incorporando chains com outros elementos do sistema. As chains são ponto-chave no desenvolvimento de software baseado em LLMs.

Vantagens de usar uma Chain.

• Ao pegar a saída de um LLM e usá-la como entrada para o próximo, torna-se possível realizar várias interações com uma LLMs de maneira sequencial.

• Misturar LLMs com dados externos permite que o sistema responda a consultas de maneira eficaz.

Há diferentes tipos de chains. Nesse texto, vamos passar por algumas das principais.

📚 Você é dev e quer aprender um pouco mais sobre a criação de aplicações baseadas em LLM?

Eu criei um curso que aborda aspectos teóricos e práticos do desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos cobertos:

🟠 O que são e como criar embeddings
🟡 Como selecionar partes relevantes nos seus documentos
🔵 Como integrar essas partes documentos com uma LLM

Achou legal? Clica aqui!

Chain = prompt | model

A forma mais básica de chain é combinando (ou encadeando) um prompt e um modelo. Na newsletter já abordagens esse tipo mais básico de chain, utilizando o LangChain Expression Language.

Embora seja possível fazer alguns encadeamento de ações , nesse tipo de chain ficamos limitados quando queremos, por exemplo, encadear duas ou mais chamadas a LLM.

Sequencial Chain

Sequential Chain Uma Sequential Chain é uma chain que combina várias chains individuais, onde a saída de uma chain serve como entrada para a próxima em uma sequência contínua. Ela opera executando uma série de chains consecutivamente.

Existem dois tipos de Sequential Chains:

• SimpleSequentialChain, que lida com uma única entrada e saída.

• SequentialChain, que gerencia várias entradas e saídas simultaneamente.

SimpleSequentialChains

As SimpleSequentialChains permitem que uma única entrada passe por uma série de transformações, resultando em uma saída refinada.

Por exemplo, imagine que você quer fazer uma receita de cozinha, mas que gostaria de saber qual é o item mais importante da receita para que você possa comprar o melhor material possível no mercado.

Nesse caso, teríamos dois prompts: um para criar a receita e outro para identificar o item mais importante da receita. Além disso, o segundo prompt deve estar conectado com o primeiro, uma vez que não sabemos de antemão quais são os itens da receita.

Poderíamos implementar essa chain da seguinte forma:

from langchain_openai import ChatOpenAI
from langchain.chains.sequential import SimpleSequentialChain

model = ChatOpenAI()
# Primeiro prompt
prompt = ChatPromptTemplate.from_template(
    "Crie uma lista de compras para fazer uma receita de: {receita}"
)
chain = LLMChain(llm=model, prompt=prompt)

# Segundo prompt
second_prompt = ChatPromptTemplate.from_template(
    "Dentre dos itens de receita, descreva qual é o mais importante e o motivo: {list}"
)
second_chain = LLMChain(llm=model, prompt=second_prompt)

combined_chain = SimpleSequentialChain(chains=[chain, second_chain], verbose=True)
combined_chain.invoke({"input": "lasanha"})

Inicialmente, cria-se um prompt solicitando a criação de uma lista de compras para uma receita específica. Uma instância da classe LLMChain é usada para processar esse prompt, utilizando um modelo predefinido.

Em seguida, é criado um segundo prompt, pedindo ao usuário que destaque o item mais importante da lista de compras e explique sua relevância. Outra instância da LLMChain é criada para lidar com essa instrução.

Por fim, ambas as chains são combinadas em uma SimpleSequentialChain, permitindo a execução sequencial das operações.

Ao invocar a cadeia combinada com o parâmetro "lasanha", o código faz uma execução sequencia das duas chain, na ordem que foram passadas por parâmetro..

SequentialChains

Similar a uma SimpleSequencialChain, uma SequentialChain pode combinar várias chains usando a saída de uma chain como entrada para a próxima. No entanto, diferente da SimpleSequencialChain, uma SequentialChain pode executar uma série de chains ao mesmo tempo, e o resultado dessas chains é passado para outras chains.

Por exemplo, imagine que você queria escrever sobre um tema específico da engenharia de software, mas com o estilo de escrita de um notável pesquisador da área. Dessa forma, podemos criar as seguintes chains:

• Chain1: Buscar um renomado pesquisador em engenharia de software

• Chain2: Escrever um texto sobre engenharia de software

• Chain3: Identificar a área de conhecimento do pesquisador renomado

• Chain4: Reescrever o texto, focando na área de conhecimento do pesquisador renomado

Note que as Chains1 e Chains2 do exemplo a cima são independentes uma da outra, logo podem se executadas em paralelo.

Poderíamos implementar essa chain da seguinte forma:

from langchain.chains import SequentialChain

first_prompt = ChatPromptTemplate.from_template(
    "Cite o nome de um pesquisador brasileiro que escreve sobre a seguinte área do conhecimento:\n\n{topic}"
)
first_chain = LLMChain(llm=model, prompt=first_prompt,
                    output_key="writer"
                    )

second_prompt = ChatPromptTemplate.from_template(
    "Escreva um resumo sobre o que se trata a área do conhecimento chamada:\n\n{topic}"
)
second_chain = LLMChain(llm=model, prompt=second_prompt,
                    output_key="summary"
                    )

third_prompt = ChatPromptTemplate.from_template(
    "Descreva em até cinco palavras a princial área de atuacao do pesquisador {writer} na {topic}."
)
third_chain = LLMChain(llm=model, prompt=third_prompt,
                    output_key="research_topic"
                    )

fourth_prompt = ChatPromptTemplate.from_template(
    "Reescreva o seguinte texto, focando na área de {software_topic}, no estilo de {writer}:\n\n{summary}"
)
fourth_chain = LLMChain(llm=model, prompt=fourth_prompt,
                    output_key="writer_summary"
                    )


main_chain = SequentialChain(
    chains=[first_chain, second_chain, third_chain, fourth_chain],
    input_variables=["topic"],
    output_variables=["writer", "summary", "research_topic", "writer_summary"],
    verbose=True
)

main_chain.invoke('''engenharia de software''')

Neste código, o primeiro prompt solicita o nome de um pesquisador brasileiro na área indicada, enquanto o segundo pede um resumo sobre essa área de conhecimento.

A terceira interação busca descrever a principal área de atuação do pesquisador na engenharia de software em até cinco palavras.

Por fim, o quarto prompt reescreve um texto focado na área específica do software, usando o estilo do pesquisador mencionado.

Perceba, no entanto, que as chains first_chain e second_chain são executadas de maneira independente, mas seu resultado é combinado e utilizado na fourth_chain.

Outras Chains

O LangChain oferece suporte para diversos outros tipos de chain. Citamos alguns exemplos a seguir.

RouterChains

A RouterChain é utilizada para tarefas ligeiramente mais complicadas. Por exemplo, quando temos múltiplas chains, cada uma especializada em um tipo específico de input, podemos ter uma router chain que decide para qual chain enviar o input.

Imagine, por exemplo, que você é um estudante do ENEM, e precisa de um serviço de pergunta e respostas especializado em física, matemática e história.

Nesse serviço, dado uma pergunta do usuário sobre uma dessas disciplinas, o prompt correto deve ser escolhido e executado.

create_sql_query_chain

Essa é uma chain que gera consultas SQL, através da classe SQLDatabase, que fornece um método get_table_info que pode ser usado para obter informações sobre colunas, bem como dados de amostra da tabela.

Para mitigar o risco de vazamento de dados sensíveis, é importante limitar as permissões para leitura e ajuste para as tabelas necessárias.

Exemplo:

from langchain_openai import ChatOpenAI
from langchain.chains import create_sql_query_chain
from langchain_community.utilities import SQLDatabase

db = SQLDatabase.from_uri("sqlite:///Chinook.db")
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
chain = create_sql_query_chain(llm, db)
response = chain.invoke({"question": "Quantos empregados existem?"})

Conclusão

O LangChain, por meio de suas chains, desempenha um papel crucial no desenvolvimento de aplicativos baseados em Large Language Models (LLMs). As chains, como Sequential Chains e Router Chains, permitem a construção de interações sequenciais e decisões dinâmicas, proporcionando flexibilidade e eficácia.

Ao unir diferentes elementos de maneira transparente, as chains possibilitam a criação de aplicativos complexos. Esse método, exemplificado com receitas de culinária e redação acadêmica, demonstra como as chains oferecem uma abordagem versátil e poderosa para a interação e manipulação de dados, ampliando as capacidades do desenvolvimento de software baseado em LLMs.

O LangChain é um framework que apoia no desenvolvimento de aplicativos baseados por modelos de linguagem. O framework simplifica tarefas como adição de contexto nos prompts, ou de reasoning dos modelos de linguagem.

Uma das formas de interagir com o LangChain é através da LCEL, LangChain Expression Language. A LCEL é uma abordagem declarativa que simplifica o uso do framework para compor chains (ou cadeias) mais facilmente.

A LCEL abrange desde as cadeias mais simples, que combinam duas etapas (um prompt e uma LLM), até cadeias mais complexas, como um pipeline que envolve dezenas ou até centenas de etapas. Além do suporte, como linguagem declarativa, o LCEL é de fácil uso e entendimento.

Nesse texto, vamos demonstrar o uso LCEL, criando pequenas cadeias de iteração de prompts.

Comunicando com o modelo

Antes de começar, precisamos configurar nosso ambiente para trabalhar com LangChain e uma LLM. Para esse texto, utilizaremos a LLM da OpenAI. Logo, precisamos instalar as seguintes dependências:

!pip install langchain openai langchain_openai

Nosso Hello World consiste em realizar uma chamada ao modelo e imprimir o resultado. Para isso, podemos usar a classe ChatOpenAI.

model = ChatOpenAI(api_key="chave", model="gpt-4", max_tokens=200, temperature=0)

Perceba que para construi o objeto ChatOpenAI precisamos passar três parâmetros:

• api_key: Chave de acesso ao modelo da OpenAI. Automaticamente inferida da variável de ambiente OPENAI_API_KEY se não fornecida.

• model: Escolha do tipo de modelo generativo. O modelo padrão é o gpt-3.5-turbo.

• max_tokens: Limite máximo de tokens para gerar respostas.

• temperature: Define a variação na resposta. Quanto maior, mais diversa será a resposta. Se zero, as respostas tendem a ser consistentes em requisições consecutivas com o mesmo prompt.

Com o objeto model criado, é possível realizar chamadas ao modelo.

model.invoke("oi, meu nome é Gustavo. Tudo bem com você?")
=> AIMessage(content='Olá, Gustavo! Eu sou uma inteligência artificial, então não tenho sentimentos, mas estou aqui para ajudar. Como posso ajudá-lo hoje?')

Note que o retorno é envelopado na classe AIMessage. Caso queria acessar somente a resposta, basta acessar a variável content.

Importante saber que cada chamada ao modelo é stateless. Ou seja, o modelo não guarda o estado das informações que foram passadas previamente. Para observar esse comportamento, basta executar uma nova requisição perguntando sobre algo da requisição anterior:

model.invoke("oi, meu nome é Gustavo. Tudo bem com você?")
=> AIMessage(content='Olá, Gustavo! Eu sou uma inteligência artificial, então não tenho sentimentos, mas estou aqui para ajudar. Como posso ajudá-lo hoje?')


model.invoke("Qual é mesmo o meu nome?")
AIMessage(content='Desculpe, como sou uma inteligência artificial, não tenho acesso a essa informação.')

Como forma de lidar com essa característica, o LangChain fornece recursos para uma construção de memória, mas que não abordaremos nesse texto.

📚 Você é dev e quer aprender um pouco mais sobre a criação de aplicações baseadas em LLM?

Eu criei um curso que aborda aspectos teóricos e práticos do desenvolvimento de aplicações baseadas em LLMs. Alguns dos tópicos cobertos:

🟠 O que são e como criar embeddings
🟡 Como selecionar partes relevantes nos seus documentos
🔵 Como integrar essas partes documentos com uma LLM

Achou legal? Clica aqui!

Separando o prompt do modelo

No exemplo anterior, usamos o método invoke da classe ChatOpenAI para iniciar uma conversa com o modelo. No entanto, há casos em que gostaríamos de fornecer uma instrução prévia para que o modelo se comporte de acordo com alguma característica.

Por exemplo, se estamos construindo um sistema especializado em design de software devemos instruir nosso modelo a se comportar como um expert nessa área. Somente após essa instrução, podemos solicitar ao modelo uma resposta a pergunta do usuário.

Para isso, devemos criar um prompt com essa característica. Para criar um prompt no LangChain, podemos usar a classe ChatPromptTemplate. Vejamos no exemplo abaixo:

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_template("Você deve atuar como um expert em design de software. Ajude nosso usuário: {input}")

Agora que temos a definição do modelo e do prompt, criaremos nossa primeira cadeia, usando o operador | (pipe):

chain = prompt | model

O pipe em comportamento similar ao pipe que utilizamos em sistemas unix, em que uma operação é realizada após a execução da operação anterior.

Embora não seja uma sintaxe muito pythonica, pipe é uma construção de código disponível no LCEL que simplifica muito o encadeamento de operações em LLMs. Debaixo dos panos, quando o interpretador Python encontra o operador | entre dois objetos (como a | b), ele tenta passar o objeto a para o método __or__ do objeto b.

Isso significa que esses padrões são equivalentes:

# padrão tradicional
chain = a.__or__(b)
chain("some input")

# padrão com pipe
chain = a | b
chain("some input")

Após a construção da nossa chain, basta invoca-la usando o método invoke.

chain.invoke({"input": "quando não devemos refatorar um código?"})

Perceba que para invocar a chain, precisamos passar um dicionário {} como parâmetro para o método invoke. Passamos como chave para esse dicionário a string "input", e como valor, passamos a string da pergunta do usuário ("quando não devemos refatorar um código?"). Perceba que a chave "input" é a mesma que usamos no ChatPromptTemplate.from_template, e o LangChain trata da interpolação de strings. O uso de um dicionário é necessário, uma vez que o prompt pode ter várias parâmetros (passados pelo usuário, ou por outros prompts).

Formatando a saída

Um outro elemento frequentemente empregado na chain, é o analisador de saída (output_parser).

Os analisadores de saída são responsáveis por pegar a saída de um LLM e transformá-la em um formato mais adequado. Isso é muito útil para modificar a forma que os dados estão estruturados. Alguns dos analisadores de saída implementados pelo framework são:

• Lista (CommaSeparatedListOutputParser): Retorna os elementos em uma lista separados por vírgula

• JSON (): Retorna um objeto JSON conforme especificado. É possível especificar um modelo Pydantic, e ele retornará JSON para esse modelo. Provavelmente o analisador de saída mais confiável para obter dados estruturados que NÃO usam chamadas de função.

• XML (): Retorna um dicionário de tags. Use quando a saída XML for necessária, especialmente com modelos eficientes na escrita XML, como o da Anthropic.

• Pydantic (): Aceita um modelo Pydantic definido pelo usuário e retorna dados nesse formato.

• YAML (): Aceita um modelo Pydantic definido pelo usuário e retorna dados nesse formato, utilizando YAML para a codificação.

• PandasDataFrame: Útil para realizar operações com pandas DataFrames.

Por padrão, se utiliza o StrOutputParser, que é um parser de string. Como é um parser padrão, não é necessário invocá-lo. Mas, sua utilização é a mesma que a seguinte:

from langchain_core.output_parsers import StrOutputParser

chain = prompt | model | StrOutputParser()

Para usar outros parsers, basta alterar o objeto a ser fornecido. Por exemplo:

from langchain_core.output_parsers import CommaSeparatedListOutputParser

chain = prompt | model | CommaSeparatedListOutputParser()
chain.invoke({"input": "explique 3 principais práticas de design?"})

Para outros parsers, como o JSON, é preciso também definir qual será o formato do documento resultante. Para isso, podemos definir uma classe usando pydantic, indicando o corpo do documento JSON.

from langchain_core.output_parsers import JsonOutputParser
from langchain_core.pydantic_v1 import BaseModel, Field
from langchain.prompts import PromptTemplate

class Design(BaseModel):
    design: str = Field(description="nome da pratica de design")
    descricao: str = Field(description="descricao da pratica de design")

# criando parser com formato esperado
parser = JsonOutputParser(pydantic_object=Design)

prompt = ChatPromptTemplate.from_template("Você deve atuar como um expert em design de software. Ajude nosso usuário: {format_instructions}\n\n{input}")
prompt = prompt.partial(format_instructions=parser.get_format_instructions())

chain = prompt | model | parser

chain.invoke({"input": "a prática de design chamada SOLID"})

Além de criar o objeto Design e passa-lo para nosso parser JsonOutputParser(pydantic_object=Design), foi necessário também mudar nosso prompt, para que este seja instruído da nova formatação. Como resultado, tivemos nossa saída formatada como JSON, que facilita a integração da resposta da LLM com demais serviços. Isso tudo, adicionando um pipe a mais na nossa chain.

Conclusão

O LangChain é um framework que simplifica o desenvolvimento de aplicativos baseados em modelos de linguagem. Um dos seus destaques reside na LangChain Expression Language (LCEL), uma abordagem declarativa que facilita a criação de cadeias de operações, desde prompts simples até pipelines complexos.

Demonstrando seu uso, o texto ilustra a interação com a OpenAI's LLM, exemplificando a criação de cadeias de iteração de prompts e a separação do prompt do modelo. Além disso, aborda recursos como construção de memória e formatação de saída, destacando a versatilidade do LangChain na construção de aplicações baseadas em LLMs.