Muitos fatores influem na escolha de um modelo adequado para seu projeto.

A licença do modelo pode restringir a forma como ele pode ser usado. Por exemplo, a licença de um modelo pode impedir que ele seja usado como parte de uma aplicação comercial.

O conjunto de dados usado para treinar o treinamento do modelo tem um impacto direto em seu funcionamento para uma aplicação específica e afeta de forma significativa o risco de que o modelo possa gerar respostas sem sentido, ofensivas ou simplesmente indesejadas. Da mesma forma, modelos treinados em dados protegidos por direitos autorais ou privados podem expor seus usuários a responsabilidade legal. A IBM fornece plena transparência de dados de treinamento e indenização por reivindicações legais decorrentes de seus modelos.

O tamanho do modelo, com quantos parâmetros ele é treinado e o tamanho de sua janela de contexto (o tamanho de uma passagem de texto que o modelo pode aceitar) afetam o desempenho do modelo, os requisitos de recursos e a taxa de transferência. Embora seja tentador seguir a filosofia de "maior é melhor" e escolher um modelo de 20 bilhões de parâmetros, os requisitos de recursos e a melhoria (se houver) na precisão podem não justificar isso. Estudos recentes mostraram que modelos menores podem superar significativamente o desempenho dos maiores para algumas soluções.

Qualquer ajuste fino aplicado a um modelo pode afetar sua adequação a uma tarefa. Por exemplo, a IBM oferece duas versões do modelo Granite: uma ajustada para aplicações gerais de chat e outra ajustada para seguir instruções.

Veja outras considerações ao escolher um modelo incluem:

• Seleção de parâmetros do modelo, como por exemplo, a temperatura do modelo, para equilibrar a criação de texto semelhante ao humano e respostas factuais. Definir a temperatura do modelo em um valor alto gerará respostas consistentes, mas pode resultar em respostas pouco interessantes ou excessivamente breves. Por outro lado, definir a temperatura em um valor baixo introduzirá mais variedade nas respostas, mas aumentará a imprevisibilidade no tamanho e no conteúdo das respostas.

• Seleção e implementação de proteções do modelo para proteção contra resultados ineficazes ou ofensivos.

A escolha do modelo depende da aplicação, do tipo de dados e dos requisitos de compatibilidade com o idioma. Os modelos de incorporação podem ter que ser estendidos para codificar e pesquisar com precisão termos ou acrônimos específicos do setor ou do cliente.

Os banco de dados de vetores são apenas uma opção para implementar o armazenamento de dados de incorporação. O Watson Discovery fornece ferramentas e funcionalidades adicionais que podem melhorar o desempenho e a precisão de uma solução RAG; e alguns bancos de dados "tradicionais" fornecem armazenamento e pesquisa de vetores e/ou pesquisa de similaridade compatíveis com uma solução RAG.

Há também inúmeras opções para bancos de dados de vetores. Bancos de dados in-memory simples incorporados diretamente a aplicações de IA generativa fornecem excelente desempenho de tempo de execução, mas podem não escalar bem para grandes conjuntos de dados e podem apresentar desafios operacionais significativos para se manterem atualizados, ou para escalar para configurações multiservidores. Outros bancos de dados que usam uma arquitetura de servidor central são mais fáceis de operar e escalar, mas podem não atender às necessidades de desempenho da solução específica.

Há vários métodos disponíveis para integrar o modelo de recuperação e geração. Recuperar as k passagens principais e usá-las para aumentar a consulta do usuário é simples e conveniente, mas pode não ter as nuances necessárias para responder a perguntas complexas. A simples pesquisa por palavra-chave também pode produzir resultados satisfatórios.

Soluções mais complexas podem usar um LLM para gerar múltiplas consultas a partir da consulta original do usuário e usá-las para recuperar um conjunto maior de passagens. Lógica adicional pode ser adicionada para classificar e selecionar melhor as passagens recuperadas com maior relevância.

Pré-processar os dados antes de alimentá-los no sistema RAG é uma etapa importante para garantir que os dados de entrada estejam em um formato adequado para o modelo. Métodos simples envolvem a divisão da entrada em fragmentos de tamanho fixo com sobreposições. Por exemplo, os últimos 10 caracteres de um fragmento são os mesmos 10 primeiros caracteres do próximo, mas isso pode perder nuances nos dados de entrada.

Um pré-processamento mais avançado pode manipular o texto de entrada para remover finais comuns de palavras, por exemplo, stopper, stopping e stopped, tudo se torna stop; remover palavras de "parada" não informativas, como the, as, is e semelhantes; e outras técnicas. Isso pode melhorar substancialmente a relevância das informações recuperadas, mas adiciona complexidade às fases de incorporação de dados e de prompts do usuário.

Técnicas ainda mais avançadas podem operar em sentenças completas, para manter o máximo possível do significado no texto.

Avaliar o desempenho de um sistema RAG pode ser desafiador devido à natureza complexa da tarefa. As métricas de avaliação comuns incluem perplexidade, fluência, relevância e coerência, bem como as métricas BLU e ROUGE. É importante escolher métricas que estejam alinhadas com os objetivos específicos da tarefa e os resultados desejados.

O RAG requer texto simples, e a escolha dos métodos de conversão tem um grande impacto na qualidade de dados. Por exemplo, ao converter arquivos PDF, como são manipuladas tabelas, imagens e outros elementos de metadados?

A geração de uma resposta semelhante à humana a partir de um LLM exige recursos computacionais substanciais e pode levar vários segundos, dependendo do tamanho do modelo, da complexidade da consulta do usuário e da quantidade de informações aumentadas passadas para o modelo. Soluções que precisam atender a grandes grupos de usuários ou exigem tempos de resposta rápidos podem precisar implementar um mecanismo para armazenar em cache as respostas do modelo para consultas frequentes.

Incorporar informações proprietárias, potencialmente confidenciais e potencialmente de identificação pessoal nos prompts do LLM é fundamental e necessário para o padrão RAG. As organizações que usam plataformas de modelos hospedados devem estar cientes das políticas do provedor, como a retenção de dados do prompt e as políticas de uso (por exemplo, o provedor captura os dados do prompt e os usa para o retreinamento do modelo?), controles para evitar que os dados do prompt "vazem" para outros usuários etc; e equilibrar tudo isso com suas próprias políticas e controles de segurança da informação.

Embora a transmissão de algumas informações proprietárias seja inevitável, as organizações podem limitar sua exposição ao incluir apenas referências de documentos ou URLs às informações mais confidenciais dos dados processados. Por exemplo, em vez de incorporar uma tabela de descontos de preços nos dados RAG, inclua apenas uma descrição da tabela e uma referência ou link para um documento interno ou site no conteúdo.

A segurança de nível de transporte (TLS) simples em comunicações entre zonas pode ser suficiente para satisfazer os requisitos de segurança de dados, mas os arquitetos podem precisar considerar oferecer proteção extra ao adicionar componentes para criptografar e descriptografar prompts e respostas antes de passá-las para o limite da zona.

O tipo de conexão entre as zonas de implementação tem impactos em vários requisitos não funcionais. O uso de uma conexão de rede privada virtual (VPN) pela internet pública é uma opção de baixo custo, mas pode não aliviar totalmente as preocupações com a segurança e pode não ser capaz de atender aos requisitos de tempo de resposta ou taxa de transferência da solução. Uma conexão de rede privada com o ambiente de hospedagem de modelos tem um custo muito mais alto, mas oferece uma segurança significativamente melhor e proporciona aos arquitetos a capacidade de controlar a latência e a largura de banda da rede.