Esta postagem foi co-escrita com Stanislav Yeshchenko da Q4 Inc.
As empresas recorrem à Geração Aumentada de Recuperação (RAG) como uma abordagem convencional para a construção de chatbots de perguntas e respostas. Continuamos a ver desafios emergentes decorrentes da natureza da variedade de conjuntos de dados disponíveis. Esses conjuntos de dados costumam ser uma mistura de dados numéricos e de texto, às vezes estruturados, não estruturados ou semiestruturados.
Q4 Inc. precisavam enfrentar alguns desses desafios em um de seus muitos casos de uso de IA desenvolvidos na AWS. Nesta postagem, discutimos um caso de uso de bot de perguntas e respostas que o Q4 implementou, os desafios que os conjuntos de dados numéricos e estruturados apresentaram e como o Q4 concluiu que o uso de SQL pode ser uma solução viável. Por fim, analisamos mais de perto como a equipe do quarto trimestre usou Rocha Amazônica e SQLDatabaseChain para implementar uma solução baseada em RAG com geração de SQL.
Visão geral do caso de uso
A Q4 Inc., com sede em Toronto e escritórios em Nova York e Londres, é uma plataforma líder de acesso aos mercados de capitais que está transformando a forma como emissores, investidores e vendedores se conectam, comunicam e interagem entre si de maneira eficiente. A plataforma Q4 facilita interações nos mercados de capitais por meio de produtos de website de RI, soluções de eventos virtuais, análise de engajamento, gestão de relacionamento com investidores (CRM), análise de acionistas e de mercado, vigilância e ferramentas ESG.
No atual cenário financeiro acelerado e orientado por dados, os Diretores de Relações com Investidores (IROs) desempenham um papel fundamental na promoção da comunicação entre uma empresa e seus acionistas, analistas e investidores. Como parte de suas tarefas diárias, os IROs analisam diversos conjuntos de dados, incluindo CRM, registros de propriedade e dados do mercado de ações. A agregação desses dados é usada para gerar relatórios financeiros, definir metas de relações com investidores e gerenciar a comunicação com investidores existentes e potenciais.
Para atender à crescente demanda por recuperação de dados eficiente e dinâmica, o quarto trimestre teve como objetivo criar uma ferramenta de perguntas e respostas do chatbot que fornecesse um método intuitivo e direto para os IROs acessarem as informações necessárias em um formato fácil de usar.
O objetivo final era criar um chatbot que integrasse perfeitamente os dados disponíveis publicamente, juntamente com dados proprietários específicos do cliente do quarto trimestre, mantendo ao mesmo tempo o mais alto nível de segurança e privacidade de dados. Quanto ao desempenho, o objetivo era manter um tempo de resposta à consulta de segundos para garantir uma experiência positiva aos usuários finais.
Os mercados financeiros são uma indústria regulamentada com grandes riscos envolvidos. Fornecer informações incorretas ou desatualizadas pode impactar a confiança dos investidores e acionistas, além de outros possíveis riscos à privacidade de dados. Compreendendo o setor e os requisitos, o Q4 define a privacidade dos dados e a precisão das respostas como seus princípios orientadores na avaliação de qualquer solução antes que ela possa ser lançada no mercado.
Para a prova de conceito, o quarto trimestre decidiu usar um conjunto de dados de propriedade financeira. O conjunto de dados consiste em pontos de dados de séries temporais que representam o número de ativos possuídos; o histórico de transações entre instituições de investimento, pessoas físicas e empresas públicas; e muitos mais elementos.
Como o Q4 queria garantir que poderia satisfazer todos os requisitos funcionais e não funcionais que discutimos, o projeto também precisava permanecer comercialmente viável. Isto foi respeitado durante todo o processo de decisão sobre a abordagem, arquitetura, escolha da tecnologia e elementos específicos da solução.
Experimentação e desafios
Ficou claro desde o início que para compreender uma questão de linguagem humana e gerar respostas precisas, o Q4 precisaria usar grandes modelos de linguagem (LLMs).
A seguir estão alguns dos experimentos conduzidos pela equipe, juntamente com os desafios identificados e lições aprendidas:
- Pré treino – O quarto trimestre compreendeu a complexidade e os desafios que surgem com o pré-treinamento de um LLM usando seu próprio conjunto de dados. Rapidamente se tornou óbvio que esta abordagem exige muitos recursos, com muitas etapas não triviais, como pré-processamento de dados, treinamento e avaliação. Além do esforço envolvido, teria um custo proibitivo. Considerando a natureza do conjunto de dados de série temporal, o quarto trimestre também percebeu que teria que realizar continuamente um pré-treinamento incremental à medida que novos dados chegavam. Isso exigiria uma equipe interdisciplinar dedicada com experiência em ciência de dados, aprendizado de máquina e domínio conhecimento.
- Afinação – O ajuste fino de um modelo básico pré-treinado (FM) envolveu o uso de vários exemplos rotulados. Esta abordagem mostrou algum sucesso inicial, mas em muitos casos, a alucinação modelo foi um desafio. O modelo teve dificuldade para entender dicas contextuais diferenciadas e retornou resultados incorretos.
- RAG com pesquisa semântica – O RAG convencional com busca semântica foi o último passo antes de passar para a geração SQL. A equipe experimentou usar pesquisa, pesquisa semântica e incorporações para extrair contexto. Durante o experimento de embeddings, o conjunto de dados foi convertido em embeddings, armazenado em um banco de dados vetorial e, em seguida, combinado com os embeddings da questão para extrair o contexto. O contexto recuperado em qualquer um dos três experimentos foi então usado para aumentar o prompt original como uma entrada para o LLM. Essa abordagem funcionou bem para conteúdo baseado em texto, onde os dados consistem em linguagem natural com palavras, frases e parágrafos. Considerando a natureza do conjunto de dados do quarto trimestre, que consiste principalmente em dados financeiros compostos por números, transações financeiras, cotações de ações e datas, os resultados em todos os três casos foram abaixo do ideal. Mesmo ao usar embeddings, os embeddings gerados a partir de números enfrentavam dificuldades com a classificação de similaridade e, em muitos casos, levavam à recuperação de informações incorretas.
Conclusão do quarto trimestre: gerar SQL é o caminho a seguir
Considerando os desafios enfrentados com a metodologia RAG convencional, a equipe passou a considerar a geração de SQL. A ideia era usar o LLM para primeiro gerar uma instrução SQL a partir da pergunta do usuário, apresentada ao LLM em linguagem natural. A consulta gerada é então executada no banco de dados para buscar o contexto relevante. O contexto é finalmente usado para aumentar o prompt de entrada para uma etapa de resumo.
A hipótese do Q4 era que, para obter maior recall para a etapa de recuperação, especificamente para o conjunto de dados numéricos, eles precisavam primeiro gerar SQL a partir da pergunta do usuário. Acreditava-se que isso não apenas aumentava a precisão, mas também mantinha o contexto dentro do domínio de negócios para uma determinada questão. Para a geração de consultas e para gerar SQL preciso, o quarto trimestre precisava tornar o LLM totalmente ciente do contexto de sua estrutura de conjunto de dados. Isso significava que o prompt precisava incluir o esquema do banco de dados, algumas linhas de dados de amostra e explicações de campo legíveis para os campos que não são fáceis de compreender.
Com base nos testes iniciais, este método apresentou ótimos resultados. O LLM equipado com todas as informações necessárias foi capaz de gerar o SQL correto, que foi então executado no banco de dados para recuperar o contexto correto. Depois de experimentar a ideia, o Q4 decidiu que a geração de SQL era o caminho a seguir para enfrentar os desafios de extração de contexto para seu próprio conjunto de dados específico.
Vamos começar descrevendo a abordagem geral da solução, dividindo-a em seus componentes e, em seguida, juntando as peças.
Visão geral da solução
LLMs são modelos grandes com bilhões de parâmetros pré-treinados usando grandes quantidades de dados de diversas fontes. Devido à amplitude dos conjuntos de dados de treinamento, espera-se que os LLMs tenham conhecimento geral em diversos domínios. Os LLMs também são conhecidos por suas habilidades de raciocínio, que variam de um modelo para outro. Esse comportamento geral pode ser otimizado para um domínio ou setor específico, otimizando ainda mais um modelo básico usando dados adicionais de pré-treinamento específicos do domínio ou ajustando usando dados rotulados. Dado o contexto, metadados e instruções corretos, um LLM de uso geral bem selecionado pode produzir SQL de boa qualidade, desde que tenha acesso ao contexto específico do domínio correto.
No caso de uso do quarto trimestre, começamos traduzindo a pergunta do cliente em SQL. Fazemos isso combinando a pergunta do usuário, o esquema do banco de dados, algumas linhas de banco de dados de amostra e instruções detalhadas como um prompt para o LLM gerar SQL. Depois de termos o SQL, podemos executar uma etapa de validação se considerarmos necessário. Quando estivermos satisfeitos com a qualidade do SQL, executamos a consulta no banco de dados para recuperar o contexto relevante necessário para a etapa seguinte. Agora que temos o contexto relevante, podemos enviar a pergunta original do usuário, o contexto recuperado e um conjunto de instruções de volta ao LLM para produzir uma resposta final resumida. O objetivo da última etapa é fazer com que o LLM resuma os resultados e forneça uma resposta contextual e precisa que possa ser repassada ao usuário.
A escolha do LLM usado em cada etapa do processo tem um grande impacto na precisão, no custo e no desempenho. Escolher uma plataforma ou tecnologia que permita a flexibilidade de alternar entre LLMs dentro do mesmo caso de uso (várias viagens de LLM para tarefas diferentes) ou entre diferentes casos de uso pode ser benéfico na otimização da qualidade da saída, da latência e do custo . Abordaremos a escolha do LLM posteriormente neste post.
Blocos de construção da solução
Agora que destacamos a abordagem em alto nível, vamos nos aprofundar nos detalhes, começando pelos blocos de construção da solução.
Rocha Amazônica
Amazon Bedrock é um serviço totalmente gerenciado que oferece opções de FMs de alto desempenho de empresas líderes, incluindo AI21 Labs, Anthropic, Cohere, Meta, Stability AI e Amazon. O Amazon Bedrock também oferece um amplo conjunto de ferramentas necessárias para criar aplicativos generativos de IA, simplificar o processo de desenvolvimento e manter a privacidade e a segurança. Além disso, com o Amazon Bedrock você pode escolher entre várias opções de FM e ajustar ainda mais os modelos de forma privada usando seus próprios dados para alinhar as respostas dos modelos com os requisitos do seu caso de uso. O Amazon Bedrock é totalmente sem servidor e sem infraestrutura subjacente para gerenciar a extensão do acesso aos modelos disponíveis por meio de uma única API. Por último, o Amazon Bedrock oferece suporte a vários requisitos de segurança e privacidade, incluindo elegibilidade para HIPAA e conformidade com GDPR.
Na solução do quarto trimestre, usamos o Amazon Bedrock como um bloco de construção de modelo multifundado, sem servidor e baseado em API. Como pretendemos fazer várias viagens ao LLM dentro do mesmo caso de uso, com base no tipo de tarefa, podemos escolher o modelo mais ideal para uma tarefa específica, seja geração, validação ou resumo de SQL.
LangChain
LangChain é uma estrutura de integração e orquestração de código aberto com um conjunto de módulos pré-construídos (E/S, recuperação, cadeias e agentes) que você pode usar para integrar e orquestrar tarefas entre FMs, fontes de dados e ferramentas. A estrutura facilita a construção de aplicativos generativos de IA que exigem a orquestração de várias etapas para produzir o resultado desejado, sem a necessidade de escrever código do zero. LangChain oferece suporte ao Amazon Bedrock como uma API de modelo multifundação.
Específico para o caso de uso do quarto trimestre, usamos LangChain para coordenar e orquestrar tarefas em nosso fluxo de trabalho, incluindo conexão com fontes de dados e LLMs. Essa abordagem simplificou nosso código porque podemos usar os módulos LangChain existentes.
SQLDatabaseChain
SQLDatabaseChain é uma cadeia LangChain que pode ser importada de langchain_experimental. SLDatabaseChain simplifica a criação, implementação e execução de consultas SQL, usando suas conversões e implementações eficazes de texto para SQL.
Em nosso caso de uso, utilizamos SQLDatabaseChain na geração de SQL, simplificando e orquestrando as interações entre o banco de dados e o LLM.
O conjunto de dados
Nosso conjunto de dados estruturado pode residir em um banco de dados SQL, data lake ou data warehouse, desde que tenhamos suporte para SQL. Em nossa solução, podemos usar qualquer tipo de conjunto de dados com suporte SQL; isso deve ser abstraído da solução e não deve alterá-la de forma alguma.
Detalhes de implementação
Agora que exploramos a abordagem da solução, os componentes da solução, a escolha da tecnologia e das ferramentas, podemos juntar as peças. O diagrama a seguir destaca a solução ponta a ponta.
Vamos examinar os detalhes da implementação e o fluxo do processo.
Gere a consulta SQL
Para simplificar a codificação, usamos estruturas existentes. Usamos LangChain como estrutura de orquestração. Começamos pela etapa de entrada, onde recebemos a pergunta do usuário em linguagem natural.
Nesta primeira etapa, pegamos essa entrada e geramos um SQL equivalente que podemos executar no banco de dados para extração de contexto. Para gerar SQL, usamos SQLDatabaseChain, que depende do Amazon Bedrock para acessar nosso LLM desejado. Com o Amazon Bedrock, usando uma única API, temos acesso a vários LLMs subjacentes e podemos escolher o caminho certo para cada viagem de LLM que fazemos. Primeiro estabelecemos uma conexão com o banco de dados e recuperamos o esquema de tabela necessário junto com algumas linhas de amostra das tabelas que pretendemos usar.
Em nossos testes, descobrimos que 2 a 5 linhas de dados da tabela são suficientes para fornecer informações suficientes ao modelo sem adicionar muita sobrecarga desnecessária. Três linhas foram suficientes apenas para fornecer contexto, sem sobrecarregar o modelo com muitas informações. Em nosso caso de uso, começamos com Anthropic Cláudio V2. O modelo é conhecido por seu raciocínio avançado e respostas contextuais articuladas quando fornecido com o contexto e as instruções corretas. Como parte das instruções, podemos incluir detalhes mais esclarecedores ao LLM. Por exemplo, podemos descrever essa coluna Comp_NAME
representa o nome da empresa. Agora podemos construir o prompt combinando a pergunta do usuário como está, o esquema do banco de dados, três linhas de amostra da tabela que pretendemos usar e um conjunto de instruções para gerar o SQL necessário em formato SQL limpo, sem comentários ou adições.
Todos os elementos de entrada combinados são considerados como o prompt de entrada do modelo. Um prompt de entrada bem projetado e adaptado à sintaxe preferida do modelo tem um grande impacto na qualidade e no desempenho da saída. A escolha do modelo a utilizar para uma tarefa específica também é importante, não só porque tem impacto na qualidade do resultado, mas também porque tem implicações em termos de custos e desempenho.
Discutiremos a seleção de modelos e a engenharia e otimização imediata posteriormente nesta postagem, mas vale a pena notar que, para o estágio de geração de consulta, notamos que Claude Instant foi capaz de produzir resultados comparáveis, especialmente quando a pergunta do usuário é bem formulada e não tão sofisticada. No entanto, Claude V2 produziu melhores resultados mesmo com contribuições mais complexas e indiretas do usuário. Aprendemos que embora em alguns casos Claude Instante pode fornecer precisão suficiente com melhor latência e preço, nosso caso para geração de consultas foi mais adequado para Claude V2.
Verifique a consulta SQL
Nossa próxima etapa é verificar se o LLM gerou com êxito a sintaxe de consulta correta e se a consulta faz sentido contextualmente, considerando os esquemas do banco de dados e as linhas de exemplo fornecidas. Para esta etapa de verificação, podemos reverter para a validação de consulta nativa em SQLDatabaseChain ou podemos executar uma segunda viagem ao LLM incluindo a consulta gerada junto com as instruções de validação.
Se usarmos um LLM para a etapa de validação, podemos usar o mesmo LLM de antes (Claude V2) ou um LLM menor e de melhor desempenho para uma tarefa mais simples, como Claude Instant. Como estamos usando o Amazon Bedrock, esse deve ser um ajuste muito simples. Usando a mesma API, podemos alterar o nome do modelo em nossa chamada de API, que cuida da mudança. É importante observar que, na maioria dos casos, um LLM menor pode fornecer melhor eficiência em termos de custo e latência e deve ser considerado, desde que você obtenha a precisão desejada. Em nosso caso, os testes provaram que a consulta gerada é consistentemente precisa e com a sintaxe correta. Sabendo disso, conseguimos pular essa etapa de validação e economizar latência e custo.
Execute a consulta SQL
Agora que temos a consulta SQL verificada, podemos executá-la no banco de dados e recuperar o contexto relevante. Esta deve ser uma etapa simples.
Pegamos o contexto gerado, fornecemos ao LLM de nossa escolha com a pergunta inicial do usuário e algumas instruções, e pedimos ao modelo para gerar um resumo contextual e articulado. Apresentamos então o resumo gerado ao usuário como resposta à pergunta inicial, tudo alinhado ao contexto extraído do nosso conjunto de dados.
Para o LLM envolvido na etapa de resumo, podemos usar Titan Text Express ou Claude Instant. Ambos apresentariam boas opções para a tarefa de sumarização.
Integração de aplicativos
O recurso de chatbot de perguntas e respostas é um dos serviços de IA do Q4. Para garantir modularidade e escalabilidade, o Q4 cria serviços de IA como microsserviços que são acessíveis aos aplicativos do Q4 por meio de APIs. Essa abordagem baseada em API permite uma integração perfeita com o ecossistema da plataforma Q4 e facilita a exposição dos recursos dos serviços de IA ao conjunto completo de aplicativos da plataforma.
O principal objetivo dos serviços de IA é fornecer capacidades simples para a recuperação de dados de qualquer fonte de dados pública ou proprietária, utilizando linguagem natural como entrada. Além disso, os serviços de IA fornecem camadas adicionais de abstração para garantir que os requisitos funcionais e não funcionais, como privacidade e segurança de dados, sejam atendidos. O diagrama a seguir demonstra o conceito de integração.
Desafios de implementação
Além dos desafios apresentados pela natureza do conjunto de dados numéricos estruturados que discutimos anteriormente, o quarto trimestre enfrentou uma série de outros desafios de implementação que precisavam ser abordados.
Seleção e desempenho do LLM
Selecionar o LLM certo para a tarefa é crucial porque impacta diretamente a qualidade do resultado, bem como o desempenho (latência de ida e volta). Aqui estão alguns fatores que influenciam o processo de seleção do LLM:
- Tipo de LLM – A forma como os FMs são arquitetados e os dados iniciais nos quais o modelo foi pré-treinado determinam os tipos de tarefas nas quais o LLM seria bom e quão bom ele será. Por exemplo, um LLM de texto seria bom para geração e resumo de texto, enquanto um modelo de texto para imagem ou imagem para texto seria mais voltado para análises de imagens e tarefas de geração.
- Tamanho do LLM – Os tamanhos FM são medidos pelo número de parâmetros de modelo que um determinado modelo possui, normalmente em bilhões para LLMs modernos. Normalmente, quanto maior o modelo, mais caro será o treinamento inicial ou o ajuste fino posterior. Por outro lado, em geral, para a mesma arquitetura de modelo, quanto maior for o modelo, mais inteligente esperamos que ele seja na execução do tipo de tarefa para a qual se destina.
- Desempenho do LLM – Normalmente, quanto maior o modelo, mais tempo leva para gerar a saída, supondo que você esteja usando os mesmos parâmetros de cálculo e de E/S (prompt e tamanho de saída). Além disso, para o mesmo tamanho de modelo, o desempenho é altamente impactado pela otimização do seu prompt, pelo tamanho dos tokens de E/S e pela clareza e sintaxe do prompt. Um prompt bem projetado, juntamente com um tamanho de token de E/S otimizado, pode melhorar o tempo de resposta do modelo.
Portanto, ao otimizar sua tarefa, considere as seguintes práticas recomendadas:
- Escolha um modelo adequado para a tarefa em questão
- Selecione o menor tamanho de modelo que pode produzir a precisão que você procura
- Otimize sua estrutura de prompt e seja o mais específico possível com as instruções de uma forma que seja fácil para o modelo entender
- Use o menor prompt de entrada que possa fornecer instruções e contexto suficientes para produzir o nível de precisão que você procura
- Limite o tamanho de saída ao menor tamanho que possa ser significativo para você e satisfaça seus requisitos de saída
Levando em consideração a seleção do modelo e os fatores de otimização de desempenho, começamos a trabalhar para otimizar nosso caso de uso de geração de SQL. Após alguns testes, percebemos que, desde que tivéssemos o contexto e as instruções corretas, Claude Instant, com os mesmos dados de prompt, produziria uma qualidade de SQL comparável à de Claude V2, com desempenho e preço muito melhores. Isso é verdade quando a entrada do usuário é de natureza mais direta e simples. Para entradas mais sofisticadas, o Claude V2 foi necessário para produzir a precisão desejada.
A aplicação da mesma lógica na tarefa de resumo nos levou a concluir que usar Claude Instant ou Titan Text Express produziria a precisão necessária em um ponto de desempenho muito melhor do que se usássemos um modelo maior como Claude V2. Titan Text Expressed também ofereceu melhor relação custo-benefício, conforme discutimos anteriormente.
O desafio da orquestração
Percebemos que há muito o que orquestrar antes de obtermos uma resposta de saída significativa para a pergunta do usuário. Conforme mostrado na visão geral da solução, o processo envolveu diversas viagens ao banco de dados e diversas viagens LLM que estão interligadas. Se construíssemos do zero, teríamos que fazer um investimento significativo no trabalho pesado indiferenciado apenas para preparar o código básico. Rapidamente passamos a usar LangChain como uma estrutura de orquestração, aproveitando o poder da comunidade de código aberto e reutilizando módulos existentes sem reinventar a roda.
O desafio SQL
Também percebemos que gerar SQL não é tão simples quanto mecanismos de extração de contexto, como pesquisa semântica ou uso de embeddings. Precisamos primeiro obter o esquema do banco de dados e algumas linhas de amostra para incluir em nosso prompt do LLM. Há também a etapa de validação SQL, onde precisamos interagir tanto com o banco de dados quanto com o LLM. SQLDatabaseChain foi a escolha óbvia de ferramenta. Por fazer parte do LangChain, foi fácil de adaptar e agora podemos gerenciar a geração e verificação de SQL auxiliada na cadeia, minimizando a quantidade de trabalho que precisávamos fazer.
Desafios de desempenho
Com o uso do Claude V2, e após a engenharia imediata adequada (que discutiremos na próxima seção), fomos capazes de produzir SQL de alta qualidade. Considerando a qualidade do SQL gerado, começamos a observar quanto valor a etapa de validação está realmente agregando. Após uma análise mais aprofundada dos resultados, ficou claro que a qualidade do SQL gerado era consistentemente precisa, de forma que tornava desfavorável o custo/benefício de adicionar um estágio de validação SQL. Acabamos eliminando o estágio de validação SQL sem impactar negativamente a qualidade de nossa saída e reduzindo o tempo de ida e volta da validação SQL.
Além de otimizar para um LLM mais eficiente em termos de custo e desempenho para a etapa de resumo, conseguimos usar o Titan Text Express para obter melhor desempenho e economia.
A otimização adicional do desempenho envolveu o ajuste fino do processo de geração de consultas usando técnicas eficientes de engenharia imediata. Em vez de fornecer uma abundância de tokens, o foco estava em fornecer a menor quantidade de tokens de entrada, na sintaxe correta que o modelo foi treinado para entender e com o conjunto mínimo, porém ideal, de instruções. Discutiremos isso mais detalhadamente na próxima seção — é um tópico importante que se aplica não apenas aqui, mas também em outros casos de uso.
Engenharia e otimização imediatas
Você pode ajustar Claude no Amazon Bedrock para vários casos de uso de negócios se as técnicas corretas de engenharia imediata forem empregadas. Claude atua principalmente como um assistente de conversação que utiliza um formato humano/assistente. Claude é treinado para preencher textos para a função de assistente. Dadas as instruções e os preenchimentos dos prompts desejados, podemos otimizar nossos prompts para Claude usando diversas técnicas.
Começamos com um modelo de prompt formatado adequado que fornece uma conclusão válida e, em seguida, podemos otimizar ainda mais as respostas experimentando prompts com vários conjuntos de entradas que são representativos de dados do mundo real. É recomendável obter muitas informações ao desenvolver um modelo de prompt. Você também pode usar conjuntos separados de dados de desenvolvimento de prompt e dados de teste.
Outra forma de otimizar a resposta de Claude é experimentar e iterar adicionando regras, instruções e otimizações úteis. A partir dessas otimizações, você pode visualizar diferentes tipos de conclusões, por exemplo, dizendo a Claude para mencionar “não sei” para evitar alucinações, pensando passo a passo, usando encadeamento de prompts, dando espaço para “pensar” à medida que gera respostas e verificação dupla de compreensão e precisão.
Vamos usar nossa tarefa de geração de consulta e discutir algumas das técnicas que usamos para otimizar nosso prompt. Alguns elementos principais beneficiaram nossos esforços de geração de consultas:
- Usando a sintaxe humana/assistente adequada
- Utilizando tags XML (Claude respeita e entende tags XML)
- Adicionando instruções claras ao modelo para evitar alucinações
O exemplo genérico a seguir mostra como usamos a sintaxe humano/assistente, aplicamos tags XML e adicionamos instruções para restringir a saída para SQL e instruir o modelo a dizer “desculpe, não posso ajudar” se não puder produzir SQL relevante . As tags XML foram usadas para enquadrar as instruções, dicas adicionais, esquema de banco de dados, explicações adicionais da tabela e linhas de exemplo.
A solução final de trabalho
Depois de termos abordado todos os desafios identificados durante a prova de conceito, cumprimos todos os requisitos da solução. O quarto trimestre ficou satisfeito com a qualidade do SQL gerado pelo LLM. Isso vale para tarefas simples que exigiam apenas uma cláusula WHERE para filtrar os dados, e também para tarefas mais complexas que exigiam agregações baseadas em contexto com GROUP BY e funções matemáticas. A latência ponta a ponta da solução geral ficou dentro do que foi definido como aceitável para o caso de uso: segundos de um dígito. Tudo isso graças à escolha de um LLM ideal em todas as etapas, engenharia imediata adequada, eliminação da etapa de verificação SQL e uso de um LLM eficiente para a etapa de resumo (Titan Text Express ou Claude Instant).
Vale ressaltar que o uso do Amazon Bedrock como um serviço totalmente gerenciado e a capacidade de ter acesso a um conjunto de LLMs por meio da mesma API permitiram a experimentação e a alternância perfeita entre LLMs, alterando o nome do modelo na chamada de API. Com esse nível de flexibilidade, o Q4 conseguiu escolher o LLM de melhor desempenho para cada chamada de LLM com base na natureza da tarefa, seja ela geração de consulta, verificação ou resumo.
Conclusão
Não existe uma solução que se adapte a todos os casos de uso. Numa abordagem RAG, a qualidade do resultado depende muito de fornecer o contexto certo. Extrair o contexto certo é fundamental, e cada conjunto de dados é diferente com suas características únicas.
Neste post, demonstramos que para conjuntos de dados numéricos e estruturados, usar SQL para extrair o contexto usado para aumento pode levar a resultados mais favoráveis. Também demonstramos que estruturas como LangChain podem minimizar o esforço de codificação. Além disso, discutimos a necessidade de poder alternar entre LLMs no mesmo caso de uso para obter precisão, desempenho e custo ideais. Por fim, destacamos como o Amazon Bedrock, sem servidor e com uma variedade de LLMs subjacentes, oferece a flexibilidade necessária para criar aplicativos seguros, de alto desempenho e com custo otimizado com o mínimo de trabalho pesado.
Comece sua jornada rumo à construção de aplicativos generativos habilitados para IA identificando um caso de uso de valor para o seu negócio. A geração de SQL, como aprendeu a equipe do quarto trimestre, pode ser uma virada de jogo na construção de aplicativos inteligentes que se integram aos seus armazenamentos de dados, liberando o potencial de receita.
Sobre os autores
Domador Soliman é arquiteto de soluções sênior na AWS. Ele ajuda os clientes de fornecedores independentes de software (ISV) a inovar, criar e escalar na AWS. Ele tem mais de duas décadas de experiência no setor em consultoria, treinamento e serviços profissionais. Ele é um inventor multipatente com três patentes concedidas e sua experiência abrange vários domínios de tecnologia, incluindo telecomunicações, redes, integração de aplicativos, IA/ML e implantações em nuvem. Ele é especialista em redes AWS e tem uma profunda paixão por machine learning, IA e IA generativa.
Mani Khanuja é líder de tecnologia – Generative AI Specialists, autora do livro – Applied Machine Learning and High Performance Computing on AWS e membro do Conselho de Administração da Women in Manufacturing Education Foundation Board. Ela lidera projetos de aprendizado de máquina (ML) em vários domínios, como visão computacional, processamento de linguagem natural e IA generativa. Ela ajuda os clientes a construir, treinar e implantar grandes modelos de aprendizado de máquina em escala. Ela fala em conferências internas e externas como re:Invent, Women in Manufacturing West, webinars no YouTube e GHC 23. Em seu tempo livre, ela gosta de fazer longas corridas na praia.
Stanislav Yeshchenko é arquiteto de software na Q4 Inc.. Ele tem mais de uma década de experiência no setor de desenvolvimento de software e arquitetura de sistemas. Sua experiência diversificada, abrangendo funções como líder técnico e desenvolvedor full stack sênior, potencializa suas contribuições para o avanço da inovação da plataforma Q4. Stanislav se dedica a impulsionar a inovação técnica e moldar soluções estratégicas na área.
- Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
- PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
- PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
- PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
- PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- :tem
- :é
- :não
- :onde
- $UP
- 100
- 118
- 125
- 15%
- 23
- 7
- a
- habilidades
- habilidade
- Capaz
- abstração
- abundância
- aceitável
- Acesso
- acessível
- Conta
- precisão
- preciso
- Alcançar
- em
- atos
- adaptar
- adicionado
- acrescentando
- Adição
- Adicional
- Adicionalmente
- Adicionais
- endereço
- endereçado
- Ajustamento
- avançado
- Avançando
- Vantagem
- Depois de
- contra
- agentes
- agregar
- AI
- Serviços de IA
- casos de uso ai
- AI / ML
- Destinado
- alinhar
- alinhado
- Todos os Produtos
- permitir
- permitidas
- juntamente
- tb
- Apesar
- am
- Amazon
- Amazon Web Services
- quantidade
- quantidades
- an
- análise
- Analistas
- analítica
- analisar
- análise
- e
- Outro
- responder
- respostas
- Antrópico
- qualquer
- nada
- api
- APIs
- relevante
- Aplicação
- aplicações
- aplicado
- abordagem
- arquitetura
- SOMOS
- AS
- perguntar
- Ativos
- Assistente
- assistida
- sortimento
- At
- aumentar
- aumentado
- autor
- disponível
- consciente
- AWS
- em caminho duplo
- fundo
- baseado
- basic
- BE
- Beach
- passou a ser
- Porque
- sido
- antes
- Começo
- comportamento
- ser
- Acredita
- benéfico
- MELHOR
- melhores práticas
- Melhor
- entre
- bilhões
- Bloquear
- Blocos
- borda
- conselho de administração
- livro
- Bot
- ambos
- largura
- Break
- amplo
- construir
- Prédio
- Constrói
- construído
- negócio
- mas a
- by
- chamada
- veio
- CAN
- Pode obter
- capacidades
- capacidade
- capital
- Mercados capitais
- Cuidado
- casas
- casos
- cadeia
- correntes
- desafiar
- desafios
- construção de desafios
- alterar
- Changer
- mudança
- características
- chatbot
- chatbots
- escolha
- Escolha
- escolha
- clareza
- limpar
- remover filtragem
- mais próximo
- Na nuvem
- código
- Codificação
- Coluna
- combinado
- combinando
- como
- comentários
- comercialmente
- comunicar
- Comunicação
- comunidade
- Empresas
- Empresa
- comparável
- realização
- integrações
- complexidade
- compliance
- componentes
- compreender
- Computar
- computador
- Visão de Computador
- computação
- conceito
- conclui
- Concluído
- conclusão
- conduzido
- conferências
- Contato
- Conexão de
- da conexão
- Considerar
- considerado
- considerando
- consistentemente
- Consistindo
- consiste
- construir
- consultor
- conteúdo
- contexto
- contextual
- continuar
- continuamente
- contribuições
- convencional
- conversação
- conversões
- convertido
- coordenando
- núcleo
- correta
- Custo
- poderia
- crio
- crítico
- CRM
- crucial
- cliente
- Clientes
- diariamente
- dados,
- lago data
- Os pontos de dados
- privacidade de dados
- Privacidade e segurança de dados
- ciência de dados
- orientado por dados
- banco de dados
- conjuntos de dados
- Datas
- década
- décadas
- decidido
- Decidindo
- dedicado
- considerado
- definido
- Demanda
- demonstraram
- demonstra
- depende
- implantar
- Implantações
- descreve
- descrevendo
- desejado
- detalhado
- detalhes
- determina
- Developer
- em desenvolvimento
- Desenvolvimento
- diferente
- diretamente
- diretamente
- Administração
- discutir
- discutido
- mergulho
- diferente
- do
- domínio
- domínios
- não
- dupla verificação
- down
- condução
- dois
- durante
- dinâmico
- cada
- Mais cedo
- fácil
- ecossistema
- Educação
- Eficaz
- eficiência
- eficiente
- eficientemente
- esforço
- esforços
- ou
- elementos
- elegibilidade
- eliminando
- emergente
- empregada
- permite
- final
- end-to-end
- terminou
- engajar
- COMPROMETIMENTO
- Engenharia
- suficiente
- garantir
- equipado
- Equivalente
- ESG
- especialmente
- estabelecer
- avaliação
- avaliação
- Mesmo
- eventos
- Cada
- exemplo
- exemplos
- existente
- esperar
- esperado
- caro
- vasta experiência
- experimentar
- experimentos
- especialista
- experiência
- Explorado
- expresso
- expressa
- estendendo
- externo
- extrato
- Extração
- enfrentou
- facilita
- fatores
- ritmo acelerado
- favorável
- factível
- poucos
- campo
- Campos
- preencher
- filtro
- final
- Finalmente
- financeiro
- dados financeiros
- Primeiro nome
- Flexibilidade
- fluxo
- Foco
- seguir
- seguinte
- Escolha
- formato
- para a frente
- fomento
- encontrado
- Foundation
- QUADRO
- Quadro
- enquadramentos
- Gratuito
- da
- cheio
- Full stack
- totalmente
- funcional
- funções
- mais distante
- jogo
- jogador desafiante
- RGPD
- Conformidade com o GDPR
- engrenado
- Geral
- gerar
- gerado
- gera
- gerando
- geração
- generativo
- IA generativa
- ter
- obtendo
- OFERTE
- dado
- dá
- Dando
- Go
- meta
- Objetivos
- Bom estado, com sinais de uso
- concedido
- ótimo
- Grupo
- Crescente
- tinha
- mão
- feliz
- Ter
- ter
- he
- com sede
- pesado
- levantamento pesado
- ajudar
- ajuda
- sua experiência
- SUA PARTICIPAÇÃO FAZ A DIFERENÇA
- Alta
- Alta performance
- alta qualidade
- superior
- mais
- Destaque
- destaques
- altamente
- dicas
- sua
- história
- capuz
- Como funciona o dobrador de carta de canal
- Contudo
- HTTPS
- humano
- legível para humanos
- i
- idéia
- identificado
- identificar
- if
- imagem
- Impacto
- impactada
- impactando
- Impacto
- executar
- implementação
- implementações
- implementado
- implicações
- importante
- melhorar
- in
- Em outra
- Inc.
- incluir
- Incluindo
- Crescimento
- incrementais
- de treinadores em Entrevista Motivacional
- indivíduos
- indústria
- INFORMAÇÕES
- Infraestrutura
- do estado inicial,
- inicialmente
- inovar
- Inovação
- entrada
- inputs
- instantâneos
- instituições
- instruções
- integrar
- integração
- pretender
- interagir
- interações
- interno
- entrelaçado
- para dentro
- intuitivo
- investimento
- investidor
- Investidores
- envolvido
- emissores
- Isv
- IT
- ESTÁ
- viagem
- jpg
- apenas por
- Guarda
- Chave
- Conhecimento
- Conhecimento
- conhecido
- Laboratório
- lago
- paisagem
- língua
- grande
- Maior
- Sobrenome
- por último
- Latência
- mais tarde
- camadas
- conduzir
- principal
- Leads
- aprendido
- aprendizagem
- mínimo
- levou
- lições
- Lições Aprendidas
- Nível
- facelift
- como
- gostos
- LLM
- lógica
- London
- longo
- olhar
- procurando
- lote
- máquina
- aprendizado de máquina
- moldadas
- a Principal
- principalmente
- Corrente principal
- a manter
- Manter
- fazer
- FAZ
- gerencia
- gerenciados
- de grupos
- fabrica
- muitos
- mercado
- Análise de Mercado
- Dados de mercado
- Mercados
- correspondido
- matemático
- Posso..
- significativo
- significava
- mecanismos
- Conheça
- membro
- conheceu
- Meta
- metadados
- método
- Metodologia
- microsserviços
- mínimo
- minimizando
- misturar
- ML
- modelo
- modelos
- EQUIPAMENTOS
- Módulos
- mais
- a maioria
- na maioria das vezes
- em movimento
- muito
- múltiplos
- múltiplo
- nome
- nativo
- natural
- Processamento de linguagem natural
- Natureza
- necessário
- você merece...
- necessário
- negativamente
- networking
- Novo
- New York
- Próximo
- não
- nota
- notando
- agora
- número
- números
- objetivo
- óbvio
- of
- WOW!
- oferecido
- Oferece
- oficiais
- escritórios
- frequentemente
- on
- ONE
- só
- aberto
- open source
- ideal
- otimização
- Otimize
- otimizado
- otimizando
- Opções
- or
- orquestrando
- orquestração
- ordem
- original
- Outros
- A Nossa
- saída
- Acima de
- global
- Visão geral
- esmagador
- próprio
- propriedade
- propriedade
- parâmetros
- parte
- particular
- passou
- paixão
- patente
- Patentes
- caminho
- Realizar
- atuação
- realização
- escolher
- peças
- plataforma
- platão
- Inteligência de Dados Platão
- PlatãoData
- Jogar
- ponto
- pontos
- positivo
- possível
- Publique
- potencial
- poder
- atribuições
- práticas
- preferido
- presente
- apresentado
- evitar
- preço
- princípios
- política de privacidade
- Privacidade e segurança
- processo
- em processamento
- produzir
- Produzido
- Produtos
- profissional
- profundo
- projeto
- projetos
- solicita
- prova
- prova de conceito
- adequado
- proprietário
- provou
- fornecer
- fornecido
- fornece
- fornecendo
- público
- empresas públicas
- publicamente
- propósito
- colocar
- Dúvidas
- qualidade
- consultas
- questão
- rapidamente
- citações
- Posição
- em vez
- RE
- pronto
- mundo real
- realizado
- receber
- Recomenda
- registros
- referência
- regulamentadas
- relações
- relacionamento
- relevante
- Relatórios
- representante
- representando
- representa
- requerer
- requeridos
- Requisitos
- recurso
- respeitado
- respeitos
- resposta
- respostas
- restringir
- Resultados
- receita
- reverter
- revendo
- certo
- riscos
- Tipo
- papéis
- Quarto
- volta
- regras
- Execute
- é executado
- mesmo
- satisfeito
- satisfeito com
- Salvar
- dizer
- AMPLIAR
- Escala
- Ciência
- arranhar
- desatado
- sem problemas
- Pesquisar
- Segundo
- segundo
- Seção
- seguro
- segurança
- Vejo
- doadores,
- VENDEDORES
- enviar
- senior
- sentido
- separado
- Série
- Serverless
- serviço
- Serviços
- conjunto
- Conjuntos
- vários
- formação
- acionista
- Acionistas
- ela
- rede de apoio social
- mostrou
- mostrando
- Shows
- periodo
- simples
- mais simples
- simplificada
- simplificar
- simplificando
- solteiro
- Tamanho
- tamanhos
- menor
- smart
- mais inteligente
- Software
- desenvolvimento de software
- solução
- Soluções
- alguns
- sofisticado
- fonte
- Fontes
- abrangendo
- vãos
- fala
- especialistas
- especializada
- específico
- especificamente
- Estabilidade
- pilha
- Etapa
- estacas
- suporte
- fica
- começo
- começado
- Comece
- Declaração
- ficar
- Passo
- Passos
- estoque
- mercado de ações
- armazenadas
- lojas
- franco
- Estratégico
- estrutura
- estruturada
- Subseqüentemente
- sucesso
- entraram com sucesso
- tal
- suficiente
- adequado
- suíte
- resumir
- RESUMO
- ajuda
- suportes
- vigilância
- Interruptor
- sintaxe
- .
- mesa
- adaptados
- Tire
- tomado
- toma
- tomar
- Tarefa
- tarefas
- Profissionais
- tecnologia
- Dados Técnicos:
- técnicas
- Tecnologia
- telecom
- dizendo
- modelo
- teste
- ensaio
- testes
- texto
- do que
- obrigado
- que
- A
- O capital
- deles
- então
- Lá.
- Este
- deles
- Pensando
- isto
- três
- Através da
- todo
- tempo
- Séries temporais
- vezes
- titã
- para
- hoje
- juntos
- token
- Tokens
- também
- ferramenta
- ferramentas
- tópico
- Toronto
- para
- Trem
- treinado
- Training
- transação
- Transações
- transformando
- viagem
- verdadeiro
- Confiança
- VIRAR
- dois
- tipo
- tipos
- tipicamente
- incapaz
- para
- subjacente
- compreender
- compreensão
- entende
- Entendido
- único
- Desbloqueio
- desnecessário
- us
- usar
- caso de uso
- usava
- Utilizador
- user-friendly
- utilização
- utiliza
- válido
- validação
- valor
- variedade
- vário
- fornecedor
- Verificação
- verificado
- verificar
- muito
- viável
- Ver
- Virtual
- visão
- andar
- querido
- foi
- Caminho..
- we
- web
- serviços web
- Webinars
- Site
- BEM
- fui
- foram
- Ocidente
- O Quê
- Roda
- quando
- enquanto que
- qual
- enquanto
- precisarão
- de
- dentro
- sem
- Mulher
- palavras
- Atividades:
- trabalhou
- de gestão de documentos
- trabalhar
- Equivalente há
- seria
- escrever
- escrever código
- XML
- ainda
- Iorque
- Vocês
- investimentos
- Youtube
- zefirnet