Quer aprender Warhammer 40K? Construa este chatbot com vetores e RAG em hardware de commodities

Ao construir um aplicativo de IA generativo que precisa chamar um modelo de linguagem grande (LLM) diversas vezes para concluir uma tarefa, um problema comum é que consultas repetidas ao LLM podem ser caras e imprevisíveis. Modelos grandes, como GPT-3.5/4, consomem muitos recursos para treinar e executar inferência; isso se reflete nas cobranças da API, bem como nas interrupções ocasionais do serviço. ChatGPT foi originalmente lançado como uma prévia de pesquisa e não se destinava a ser usado em aplicativos de produção. No entanto, a sua utilidade numa vasta gama de aplicações é indiscutível, pelo que o interesse em LLMs explodiu.

Desde o início do ChatGPT, os usuários têm procurado maneiras de contornar a falta de privacidade e a incapacidade de controlar o tempo de atividade ou as configurações de inferência ao usar o GPT. Isso levou à popularidade de modelos públicos gratuitos, como o Llama 2 da Meta e, posteriormente, à criação de versões quantizadas e com parâmetros mais baixos do Llama que podem ser executadas em hardware de consumo. Esses modelos públicos são capazes de fornecer praticamente a mesma funcionalidade do GPT com muito menos poder de computação, embora ao custo de menos parâmetros e menos resultados detalhados.

Se seu aplicativo não depende necessariamente do processamento de contextos excessivamente grandes ou da produção de resultados detalhados, hospedar sua própria inferência em instâncias que você controla pode ser uma opção mais econômica. E quando se trata de aplicações reais de geração aumentada de recuperação (RAG), as diferenças de custo podem se tornar ainda mais significativas.

Demonstrarei um método simples para combinar armazenamentos de vetores, pesquisa lexical e engenharia imediata para executar RAG preciso em hardware comum. Usando esse método, você pode reduzir a complexidade de grandes volumes de informações e tornar a execução de aplicativos generativos de IA mais precisa, eficiente e econômica em escala. Ao usar o RAG em armazenamentos específicos de informações, você pode eliminar alucinações e criar agentes eficazes e bem informados a partir de qualquer material de origem, sem precisar pagar por APIs de terceiros.

Para começar, você precisará de uma instância DataStax Enterprise 7 ou DataStax Astra DB para armazenar os vetores e dados de texto, bem como um LLM e um modelo de transformador de frase para gerar respostas e codificar seus dados com vetores. Dependendo da complexidade dos seus dados ou das solicitações do usuário, você também pode considerar combinar isso com um banco de dados DataStax Enterprise 6.8 que pode realizar pesquisas Solr para corresponder a intervalos mais amplos de dados, que foi o que usei neste exemplo. A DataStax trabalha continuamente em melhorias para permitir todas essas operações com um único banco de dados, mas, por enquanto, uso dois bancos de dados.

Resolvendo para alucinações

Independentemente de qual LLM você escolher, todos eles ainda sofrem de alucinações . Por enquanto, essa limitação precisa ser resolvida inserindo informações verdadeiras no contexto dos prompts do LLM, também conhecido como RAG. O método pelo qual você localiza suas informações e as transforma para os prompts depende completamente do seu modelo de dados, mas você pode encontrar informações mais pertinentes de maneira mais eficiente usando bancos de dados vetoriais.

Digamos, por exemplo, que você tenha uma coleção de e-books sobre um assunto que gostaria de explorar, como como jogar Warhammer 40.000 . Em circunstâncias normais, levaria anos para ler a literatura de apoio e ganhar experiência de jogo suficiente para atingir um nível de especialista.

Uma pergunta direcionada como: “O que você pode me dizer sobre Morvenn Vahl da Adepta Sororitas?” seria melhor respondida por um jogador veterano ou qualquer funcionário de uma loja Warhammer. Embora o ChatGPT possa responder a muitas perguntas sobre o jogo, infelizmente não possui dados de treinamento que cubram esse personagem específico:

Compare isso com um LLM de parâmetro Llama 2 13B hospedado em uma estação de trabalho de consumidor com uma placa gráfica Nvidia RTX A4000. Da mesma forma, o modelo pode demonstrar conhecimento básico do universo Warhammer, mas por causa do ajuste, o modelo não se importa que o personagem não seja encontrado e fornece, em vez disso, uma alucinação de melhor esforço:

Se você deseja construir um chatbot que possa ajudar tanto novatos quanto veteranos a jogar Warhammer 40.000, então esses resultados são inaceitáveis. Para ser um guia de jogo eficaz, o chatbot precisa conhecer as regras do jogo, as regras de cada unidade, algumas partes da tradição e algumas estratégias e comentários. Felizmente, todas essas informações sobre as regras da 10ª edição estão disponíveis gratuitamente no Games Workshop e em sites de fãs, e tudo o que você precisa fazer é torná-las pesquisáveis em seu aplicativo chatbot.

Compare isso com o mesmo modelo 13B Llama, onde com RAG, é solicitado que compare algumas fontes em Morvenn Vahl e elabore uma resposta relevante com base no prompt do usuário. Desta vez, o chatbot tem acesso a um banco de dados de busca e um banco de dados vetorial repleto de todas as informações públicas sobre como jogar Warhammer 40.000, 10ª Edição:

Que diferença! Ele não apenas encontra informações pertinentes sobre esse personagem de nicho, mas também mantém seus resultados alinhados com o contexto de como jogar o jogo com as regras da 10ª edição.

A parte mais difícil de tudo isso é realizar uma pesquisa eficaz para encontrar as páginas relevantes para alimentar o LLM. É aqui que os bancos de dados vetoriais podem ser particularmente úteis.

Aplicando vetores

Neste exemplo, usaremos DSE 7 e DSE 6.8 em execução em instâncias Docker para satisfazer os requisitos de banco de dados do aplicativo chatbot, que precisa ser capaz de comparar vetores e realizar pesquisas lexicais. O DSE 7 e o Astra DB introduziram a capacidade de armazenar vetores e realizar pesquisas de vetores, bem como filtrar por correspondências de texto. Precisamos apenas pesquisar este exemplo em algumas dezenas de livros, portanto, executar instâncias DSE no Docker será suficiente para a maioria dos hardwares de consumo.

O uso de vetores em seus bancos de dados ajudará a encontrar documentos semelhantes a uma determinada consulta ou pode ser usado para comparar resultados recuperados de outra pesquisa. Isto pode ajudá-lo a superar as limitações da pesquisa lexical e a melhorar a eficácia dos modelos de dados.

Por exemplo, algo como PDFs de e-books pode se beneficiar ao ser codificado com transformadores de frases como miniLM , e os vetores podem ser usados para executar uma comparação de similaridade entre uma consulta e uma determinada fonte. Nesse caso, um modelo de transformador de frase é usado para criar incorporações do texto de uma página em um e-book, e isso pode permitir a comparação com o prompt do usuário para descobrir se um resultado é relevante para a consulta. As páginas relevantes devem conter uma ou mais instâncias de termos semelhantes à consulta do usuário e resultar em melhores pontuações de similaridade do ponto de vista do modelo.

Dito isto, os vetores são melhor aplicados como complemento a um modelo de pesquisa lexical existente. Se você pesquisar apenas por vetores, poderá acabar recuperando inesperadamente documentos não relacionados e fornecendo-os como contexto onde não se aplicam.

Neste exemplo, a consulta “O que você pode me dizer sobre Morvenn Vahl da Adepta Sororitas?” pode ser transformado por um LLM em um conjunto de termos de pesquisa simples:

Morvenn, Vahl, Adepta, Sororitas

O primeiro passo para encontrar documentos relevantes seria procurar documentos que contenham esses termos básicos. Isso pode ser feito primeiro filtrando as correspondências de texto no banco de dados para encontrar palavras-chave no texto da página que correspondam a essa consulta. A razão para usar um LLM para gerar palavras-chave é fornecer uma gama mais ampla de palavras-chave possíveis para pesquisa, já que muitas vezes tenta adicionar mais palavras-chave relacionadas, mas que não estão no texto do prompt original. Tenha cuidado com isso, entretanto, pois os LLMs também podem gerar caracteres especiais e sequências estranhas que você precisará higienizar.

Depois de ter pelo menos um resultado, você pode vetorizar a consulta do usuário e compará-la com os vetores da pesquisa lexical, criando pontuações de quão relevante é cada resultado. Isso permite que você verifique a precisão dos resultados da pesquisa e defina um limite para rejeitar resultados não relacionados quando se trata de finalmente apresentar seus resultados ao LLM.

Nesse caso, a primeira etapa deve corresponder às páginas que mostram especificamente a ficha de Morvenn Vahl ou a mecânica de jogo, porque descrevem a unidade do personagem em termos de como ele atua no jogo. Se a página atingir um determinado limite de relevância para a consulta do usuário, determinado pelo aplicativo, ela será resumida e colocada em uma lista de resultados.

Finalmente, os resultados da pesquisa podem ser compilados numa lista e enviados de volta ao LLM, onde é solicitado que utilize os contextos mais relevantes para responder à consulta original. Aqui está uma visualização do fluxo:

Como você pode ver, o LLM é chamado com bastante frequência para esse fluxo. O LLM é responsável por transformar o prompt do usuário em palavras-chave, resumir os resultados aplicáveis e escolher qual contexto melhor responde a uma consulta. Cada fonte a ser verificada adiciona outra invocação do LLM, o que pode ser bastante caro ao fazer consultas ao GPT. Mas se você já possui as informações necessárias e deseja apenas resumi-las ou transformá-las, talvez não seja necessário usar um modelo tão grande. Na verdade, mudar para modelos menores pode trazer vários benefícios.

Ao usar um LLM menor, você pode reduzir o custo computacional de cada consulta, o que pode levar a economias significativas ao longo do tempo. Isso também pode resultar em tempos de resposta mais rápidos para seus usuários, o que pode melhorar sua experiência geral. Neste exemplo, onde o RAG é realizado usando um pequeno LLM e pequenos bancos de dados, todos hospedados na mesma instância de GPU, leva cerca de 30 segundos para recuperar 15 fontes, analisá-las quanto à relevância e fornecer uma resposta final. E quanto mais curtos os prompts (fontes), mais rápido as saídas poderão ser retornadas.

Além disso, este método permite maior segurança e escalabilidade. Com engenharia imediata e um pipeline de chamadas para o LLM, você tem controle total sobre como os dados são acessados e o que os usuários receberão em suas respostas. Em termos de uso de recursos, o modelo de parâmetro 13B do exemplo consome apenas pouco mais de 8 GB de VRAM e ainda fornece respostas relevantes. Dependendo das necessidades, isso mostra potencial para executar o RAG em inúmeras outras plataformas, como estações de trabalho de usuários e dispositivos móveis.

Controlando a saída

A engenharia imediata é a chave para fazer com que o RAG faça exatamente o que você deseja. Você controla como o chatbot interpreta os dados e o contexto sob o qual ele deve pensar. Neste exemplo, queremos garantir que o chatbot saiba que estamos buscando especificamente informações sobre Warhammer, para que possamos primeiro pedir que ele ajude a fornecer contexto de suporte à consulta do usuário:

Consulta: “<consulta do usuário>”

Dê-me uma lista mínima separada por vírgulas de palavras-chave Warhammer 40K para um mecanismo de pesquisa. Responda apenas com a consulta. Não use emojis ou caracteres especiais.

Responder:

Warhammer 40.000 está cheio de termos e nomes que podem aparecer em outras culturas populares não relacionadas, por isso é importante definir o contexto do RAG logo na primeira consulta. Este contexto deve estar disponível para seleção ou modificação se seu aplicativo cobrir vários contextos, como se você precisar cobrir várias edições das regras do jogo Warhammer ou combiná-las com os livros oficiais de conhecimento.

Observe que a consulta do usuário é sempre encapsulada entre aspas para este experimento. Isso ajuda o LLM a distinguir entre a consulta que está tentando responder diretamente e as instruções separadas de engenharia de prompt, às quais ele não deve responder diretamente. A parte de pergunta/resposta do prompt pode ser ajustada para se adequar a um contexto específico, mas principalmente, tudo que você precisa fazer é informar ao LLM o que ele deve ou não responder diretamente e como responder.

Neste caso, é seguro assumir que o LLM tem um conhecimento geral do universo do jogo, uma vez que a série é razoavelmente popular e as informações gerais estão disponíveis gratuitamente. A saída desta primeira consulta ajuda a gerar algumas palavras-chave para usar na pesquisa lexical sem que tenhamos que construir uma folha de dicas em nosso aplicativo.

As comparações lexicais e vetoriais podem então ser realizadas em segundo plano, e uma lista de resultados é compilada para revisão pelo LLM. Como o prompt original do usuário nunca é respondido diretamente com inferência na primeira etapa, o LLM apenas transforma o que é encontrado em uma pesquisa e pode ser facilmente impedido de responder a consultas fora de sua proteção ou base de conhecimento.

Se houver resultados relevantes da pesquisa:

Consulta: “<consulta do usuário>”

Revise esses resultados da pesquisa e use-os para responder à consulta.

Resultado 1

Resultado 2

etc.

Responder:

Se não houver resultados relevantes da pesquisa:

Consulta: “<consulta do usuário>”
Diga-me educadamente que você pesquisou, mas não conseguiu encontrar uma resposta para a consulta. Em vez disso, responda com o melhor de seu conhecimento.

Responder:

Para maior segurança, você pode rejeitar ou redirecionar completamente a solicitação quando ela não puder ser atendida.

Consulta: “<consulta do usuário>”

Diga-me educadamente que você pesquisou, mas não conseguiu encontrar uma resposta para a consulta. Instrua-me a entrar em contato com a equipe de suporte ao cliente para obter assistência.

Responder:

Você pode até tornar os resultados mais longos solicitando mais detalhes. Contanto que você consiga ajustar seu material de origem na janela de contexto, o LLM pode transformá-lo para você.

Consulta: “<consulta do usuário>”

Revise esses resultados da pesquisa e use-os para responder à consulta. Seja o mais detalhado possível e cite as fontes.

Resultado 1

Resultado 2

etc.

Responder:

Limitações

O LLM tem uma janela de contexto limitada e não conseguirá processar páginas de texto excepcionalmente grandes. Considere colocar limites no tamanho da linha para que seus dados sejam mais gerenciáveis e mais fáceis de serem processados pelo LLM. Por exemplo, cortar páginas em pedaços de cerca de 1.000 caracteres parece funcionar bem e tente evitar inserir mais de quatro ou cinco respostas detalhadas no prompt.

O LLM não tem memória de uma conversa além do que você pode colocar na janela de contexto. É possível construir um armazenamento permanente de dados de conversas, mas não é possível para um LLM encaixar conversas excessivamente grandes ou contexto detalhado em um prompt; há um limite superior para o que ele pode transformar. Isso significa que não importa o que aconteça, em determinado momento você notará que o LLM parece “esquecer” certos detalhes mesmo quando eles são fornecidos como contexto; esta é apenas uma limitação inerente da ferramenta. É melhor confiar nele apenas para conversas curtas e focar na transformação de pequenas quantidades de texto por vez para minimizar alucinações.

A aleatoriedade no LLM pode ser um problema. Testes e ajustes serão necessários para determinar quais prompts funcionam melhor para seu conjunto de dados e para descobrir qual modelo funciona melhor para seu caso de uso. Em meus testes com um modelo de parâmetro 13B, havia muita imprevisibilidade em relação às palavras-chave de pesquisa geradas a partir do primeiro prompt, especialmente à medida que o comprimento do prompt aumentava. Para obter melhores resultados, siga instruções mais curtas.

Conclusão

Em resumo, aproveitar o RAG combinando modelos de pesquisa vetorial e lexical permite encontrar e classificar de forma mais eficaz resultados relevantes e gerar resultados de agentes que são muito menos propensos a alucinações. Quanto menor o contexto pesquisável, mais precisas e precisas serão as respostas. Construir seu próprio pipeline personalizado de chamadas LLM oferece muito mais flexibilidade no ajuste de respostas para o nível desejado de precisão e barreiras de proteção.

Embora não possa processar quantidades excessivamente grandes de dados dentro da janela de contexto limitada, ele oferece a capacidade de criar assistentes eficazes em bases de conhecimento limitadas, bem como executar mais agentes simultâneos no mesmo hardware ou em menos hardware do que antes. Isto poderia abrir mais possibilidades para assistentes virtuais para aplicações como jogos de mesa ou até mesmo cobrir tópicos mais complexos para uso por governos, escritórios de advocacia e contabilidade, pesquisa científica, energia e muito mais.

Se você estiver pronto para começar a construir, experimente o Astra DB gratuitamente . Crie seu banco de dados e comece a carregar suas fontes RAG hoje mesmo, sem necessidade de experiência em operações de nuvem ou banco de dados.

Por Mario Charnell-Delgado, DataStax

Também publicado aqui .