Movendo grandes modelos de linguagem (LLM) para aplicativos de negócios do mundo real

Grandes modelos de linguagem estão por toda parte. Cada conversa com o cliente ou pitch de VC envolve perguntas sobre o quão pronta a tecnologia LLM está e como ela conduzirá aplicações futuras. Eu cobri alguns padrões sobre isso em meu post anterior. Aqui falarei sobre alguns padrões do mundo real para uma aplicação na indústria farmacêutica na qual a Persistent Systems trabalhou.

Grandes modelos de linguagem e principais pontos fortes

Os LLMs são bons em entender a linguagem, esse é o forte deles. O padrão mais comum que vemos com aplicativos é a geração aumentada de recuperação (RAG), em que o conhecimento é compilado externamente a partir de fontes de dados e fornecido no contexto como um prompt para o LLM parafrasear uma resposta. Nesse caso, mecanismos de pesquisa super-rápidos, como bancos de dados vetoriais e mecanismos baseados no Elasticsearch, servem como primeira linha de pesquisa. Em seguida, os resultados da pesquisa são compilados em um prompt e enviados ao LLM principalmente como uma chamada de API.

Outro padrão é gerar uma consulta em dados estruturados, alimentando o LLM com um modelo de dados como prompt e uma consulta de usuário específica. Esse padrão pode ser usado para desenvolver uma interface avançada de “fale com seus dados” para bancos de dados SQL como Snowflake, bem como bancos de dados gráficos como Neo4j.

Aproveitando os padrões LLM para insights do mundo real

A Persistent Systems recentemente analisou um padrão para Movimento Explosivo, uma empresa de telemetria esportiva (análise de swing para beisebol, golfe etc.), onde analisamos dados de séries temporais de resumos de jogadores para obter recomendações.

Para aplicações mais complexas, geralmente precisamos encadear as solicitações LLM com processamento entre as chamadas. Para uma empresa farmacêutica, desenvolvemos um aplicativo de trilhas inteligentes que filtra pacientes para ensaios clínicos com base em critérios extraídos de documentos de ensaios clínicos. Aqui usamos uma abordagem de cadeia LLM. Primeiro, desenvolvemos um LLM para ler o documento PDF do teste e usar o padrão RAG para extrair os critérios de inclusão e exclusão.

Para isso, foi utilizado um LLM relativamente mais simples como o GPT-3.5-Turbo (ChatGPT). Em seguida, combinamos essas entidades extraídas com o modelo de dados do banco de dados SQL dos pacientes no Snowflake, para criar um prompt. Esse prompt alimentado a um LLM mais poderoso como o GPT4 nos fornece uma consulta SQL para filtrar pacientes, que está pronta para ser executada no Snowflake. Como usamos o encadeamento LLM, poderíamos usar vários LLMs para cada etapa da cadeia, permitindo-nos gerenciar custos.

Atualmente, decidimos manter essa cadeia determinística para melhor controle. Ou seja, decidimos ter mais inteligência nas chains e manter a orquestração bem simples e previsível. Cada elemento da cadeia é um aplicativo complexo por si só que levaria alguns meses para ser desenvolvido nos dias pré-LLM.

Capacitando casos de uso mais avançados

Para um caso mais avançado, poderíamos usar Agentes como Reagir para solicitar que o LLM crie instruções passo a passo a serem seguidas para uma consulta específica do usuário. É claro que isso precisaria de um LLM de ponta como GPT4 ou Cohere ou Claude 2. No entanto, existe o risco de o modelo dar um passo incorreto que precisará ser verificado usando guarda-corpos. Este é um trade-off entre mover a inteligência em elos controláveis ​​da cadeia ou tornar toda a cadeia autônoma.

Hoje, à medida que nos acostumamos com a era da IA ​​generativa para linguagem, a indústria está começando a adotar aplicativos LLM com Chains previsíveis. À medida que essa adoção crescer, em breve começaremos a experimentar mais autonomia para essas cadeias por meio de agentes. É disso que trata o debate sobre AGI e estamos interessados ​​em ver como tudo isso evolui ao longo do tempo.