Em meados de 2024, criar uma demonstração de IA que impressione e empolgue pode ser fácil. Pegue um desenvolvedor forte, alguns experimentos rápidos e inteligentes e algumas chamadas de API para um modelo básico poderoso e muitas vezes você poderá construir um bot de IA personalizado em uma tarde. Adicione uma biblioteca como ou para aumentar seu LLM com alguns dados personalizados usando RAG - e uma tarde de trabalho pode se transformar em um projeto de fim de semana.

Chegar à produção, porém, é outra questão. Você precisará de um sistema confiável, observável, ajustável e de alto desempenho em grande escala. Será essencial ir além dos cenários de demonstração inventados e considerar a resposta do seu aplicativo a uma gama mais ampla de prompts que representam todo o espectro do comportamento real do cliente. O LLM pode precisar de acesso a um rico corpus de conhecimento específico de domínio, muitas vezes ausente do seu conjunto de dados pré-formação. Finalmente, se você aplicar IA a um caso de uso onde a precisão é importante, as alucinações deverão ser detectadas, monitoradas e mitigadas.

Embora resolver todos esses problemas possa parecer assustador, torna-se mais fácil desconstruir seu aplicativo baseado em RAG em suas respectivas partes conceituais e, em seguida, adotar uma abordagem direcionada e iterativa para melhorar cada uma delas conforme necessário. Esta postagem irá ajudá-lo a fazer exatamente isso. Nele, focaremos exclusivamente nas técnicas usadas para criar um pipeline de processamento de documentos RAG, em vez daquelas que ocorrem posteriormente no momento da recuperação. Ao fazer isso, pretendemos ajudar os desenvolvedores de aplicações de IA generativas a se prepararem melhor para a jornada do protótipo à produção.

O Data Lake Moderno: O Centro de Gravidade da Infraestrutura de IA

Costuma-se dizer que na era da IA os dados são o seu fosso . Para esse fim, construir um aplicativo RAG de nível de produção exige uma infraestrutura de dados adequada para armazenar, versionar, processar, avaliar e consultar blocos de dados que compõem seu corpus proprietário. Como o MinIO adota uma abordagem de IA que prioriza os dados, nossa recomendação de infraestrutura inicial padrão para um projeto desse tipo é configurar um Data Lake Moderno e um banco de dados vetorial. Embora outras ferramentas auxiliares possam precisar ser conectadas ao longo do caminho, essas duas unidades de infraestrutura são fundamentais. Eles servirão como centro de gravidade para quase todas as tarefas encontradas posteriormente ao colocar seu aplicativo RAG em produção.

Uma arquitetura de referência moderna de Data Lake construída em MinIO pode ser encontrada . Um artigo complementar mostrando como essa arquitetura oferece suporte a todas as cargas de trabalho de IA/ML é .

RAG: etapas do pipeline de documentos

Avaliação

Um passo inicial crítico para construir uma aplicação RAG de nível de produção é estabelecer uma estrutura de avaliação - muitas vezes referida simplesmente como avaliações. Sem avaliações, você não terá como entender com segurança o desempenho do seu sistema, saber quais componentes precisam ser ajustados ou determinar se você está fazendo progresso real. Além disso, as avaliações atuam como uma função de força para esclarecer o problema que você está tentando resolver. Aqui estão algumas das técnicas de avaliação mais comuns:

• Avaliação heurística baseada em código - Pontuação de saída programaticamente usando uma variedade de medidas como contagem de tokens de saída, presença/ausência de palavras-chave, validade JSON, etc. Muitas vezes, elas podem ser avaliadas deterministicamente usando expressões regulares e bibliotecas de asserções para testes de unidade convencionais.

  
  

• Avaliação algorítmica baseada em código – Pontuação de resultados usando uma variedade de métricas conhecidas de ciência de dados. Por exemplo, ao reformular o prompt como um problema de classificação, você pode usar funções de pontuação populares de sistemas de recomendação, como ganho cumulativo descontado normalizado (NDCG) ou classificação recíproca média (MRR). Por outro lado, se um prompt puder ser enquadrado como um problema de classificação, então a precisão, a recuperação e a pontuação F1 podem ser apropriadas. Finalmente, você pode usar medidas como BLEU, ROUGE e similaridade de resposta semântica (SAS) para comparar a saída semântica com uma verdade básica conhecida.

  
  

• Avaliação Baseada em Modelo - Use um modelo para pontuar o resultado de outro, conforme detalhado no papel. Essa técnica está crescendo em popularidade e é muito mais barata do que a escala humana. No entanto, nas fases iniciais de passagem de um projecto do protótipo para a produção, pode ser complicado implementá-lo de forma fiável, uma vez que o avaliador, neste caso, é um LLM frequentemente sujeito a limitações e preconceitos semelhantes aos do próprio sistema subjacente. Fique atento às pesquisas, ferramentas e práticas recomendadas desta área, pois elas estão evoluindo rapidamente.

  
  

• Avaliação Humana - Pedir a especialistas do domínio humano que forneçam a melhor resposta é geralmente o padrão ouro. Embora este método seja lento e caro, não deve ser esquecido, pois pode ser inestimável para obter insights e construir o seu conjunto de dados de avaliação inicial. Se desejar um aproveitamento extra do trabalho executado, você pode usar técnicas como as detalhadas no papel para complementar suas avaliações geradas por especialistas humanos com variações sintéticas.

Junto com sua decisão sobre quais técnicas de avaliação usar, considere criar um conjunto de dados de avaliação de benchmark personalizado - genéricos normalmente usados em tabelas de classificação do Hugging Face, como o conjunto de dados não serve. Seu conjunto de dados de avaliação personalizado conterá uma variedade de prompts e suas respostas ideais que são específicas do domínio e representativas dos tipos de prompts que seus clientes reais inserirão em seu aplicativo. Idealmente, especialistas humanos estão disponíveis para ajudar na criação do conjunto de dados de avaliação, mas se não estiverem, considere fazê-lo você mesmo. Se você não se sentir confiante em adivinhar quais são os prompts prováveis, basta formar uma hipótese operacional e seguir em frente como se ela tivesse sido validada. Você pode revisar continuamente suas hipóteses posteriormente, à medida que mais dados estiverem disponíveis.

Considere aplicar restrições ao prompt de entrada para cada linha em seu conjunto de dados de avaliação para que o LLM responda com um tipo de julgamento concreto: binário, categórico, classificação, numérico ou texto. Uma combinação de tipos de julgamento manterá suas avaliações razoavelmente variadas e reduzirá o viés de produção. Ceteris paribus, mais casos de teste de avaliação são melhores; no entanto, recomenda-se focar na qualidade em vez da quantidade nesta fase. Pesquisa recente sobre ajuste fino de LLM no o artigo sugere que mesmo um pequeno conjunto de dados de avaliação de 1.000 linhas pode melhorar drasticamente a qualidade da saída, desde que sejam amostras representativas da verdadeira população mais ampla. Com aplicativos RAG, observamos uma melhoria de desempenho usando conjuntos de dados de avaliação que consistem em dezenas a centenas de linhas.

Embora você possa começar a executar suas avaliações manualmente de forma ad hoc, não espere muito antes de implementar um pipeline de CI/CD para automatizar a execução do seu processo de pontuação de avaliação. A execução de avaliações diariamente ou em gatilhos conectados a repositórios de código-fonte e ferramentas de observabilidade é geralmente considerada uma prática recomendada de operações de ML. Considere usar uma estrutura de avaliação RAG de código aberto como ou para ajudá-lo a começar a trabalhar rapidamente. Use seu data lake como fonte de verdade para tabelas que contêm os conjuntos de dados de avaliação com versão e as diversas métricas de saída geradas cada vez que uma avaliação é executada. Esses dados fornecerão informações valiosas para serem usadas posteriormente no projeto para fazer melhorias estratégicas e altamente direcionadas.

Extratores de dados

O corpus RAG com o qual você inicialmente inicia a prototipagem raramente é suficiente para levá-lo à produção. Provavelmente, você precisará aumentar seu corpus com dados adicionais continuamente para ajudar o LLM a reduzir alucinações, omissões e tipos problemáticos de preconceito. Isso normalmente é feito caso a caso, criando extratores e carregadores que convertem dados upstream em um formato que pode ser processado posteriormente em um pipeline de documentos downstream.

Embora exista um pequeno risco de tentar ferver o oceano recolhendo mais dados do que o necessário, é essencial ser criativo e pensar fora da caixa sobre as fontes de informação de qualidade às quais a sua empresa tem acesso. Possibilidades óbvias podem incluir a extração de insights de dados estruturados armazenados em seu OLTP corporativo e data warehouse. Fontes como postagens em blogs corporativos, whitepapers, pesquisas publicadas e consultas de suporte ao cliente também devem ser consideradas, desde que possam ser devidamente anonimizadas e eliminadas de informações confidenciais. É difícil exagerar o impacto positivo no desempenho de adicionar até mesmo pequenas quantidades de dados de qualidade no domínio ao seu corpus, portanto, não tenha medo de gastar tempo explorando, experimentando e iterando. Aqui estão algumas das técnicas comumente usadas para inicializar um corpus no domínio de alta qualidade:

• Extração de documentos – PDFs proprietários, documentos de escritório, apresentações e arquivos markdown podem ser fontes ricas de informações. Existe um amplo ecossistema de ferramentas de código aberto e SaaS para extrair esses dados. Geralmente, os extratores de dados são específicos do tipo de arquivo (JSON, CSV, docx, etc.), baseados em OCR ou alimentados por aprendizado de máquina e algoritmos de visão computacional. Comece de forma simples e adicione complexidade apenas quando necessário.

  
  

• Extração de API – APIs públicas e privadas podem ser fontes ricas de conhecimento no domínio. Além disso, APIs da web baseadas em JSON e XML bem projetadas já possuem alguma estrutura integrada, tornando mais fácil realizar a extração direcionada de propriedades relevantes dentro da carga útil, descartando qualquer coisa considerada irrelevante. Existe um vasto ecossistema de conectores de API acessíveis com baixo código e sem código para ajudá-lo a evitar escrever ETLs personalizados para cada API que você deseja consumir - uma abordagem que pode ser difícil de manter e escalar sem uma equipe dedicada de engenheiros de dados.

  
  

• Web Scrapers - As páginas da Web são consideradas dados semiestruturados com uma estrutura DOM semelhante a uma árvore. Se você souber quais informações procura, onde estão localizadas e o layout da página onde residem, poderá construir rapidamente um scraper para consumir esses dados, mesmo sem uma API bem documentada. Existem muitas bibliotecas de scripts e ferramentas de baixo código para fornecer abstrações valiosas para web scraping.

  
  

• Rastreadores da Web - Os rastreadores da Web podem percorrer páginas da Web e criar listas de URLs recursivas. Este método pode ser combinado com raspagem para digitalizar, resumir e filtrar informações com base em seus critérios. Em uma escala mais significativa, esta técnica pode ser usada para criar seu próprio gráfico de conhecimento.

  
  

Quaisquer que sejam as técnicas usadas para coleta de dados, resista à tentação de criar scripts únicos e hackeados. Em vez disso, aplique as práticas recomendadas de engenharia de dados para implantar extratores como pipelines ETL repetíveis e tolerantes a falhas que colocam os dados em tabelas dentro do seu data lake. Certifique-se de que cada vez que você executar esses pipelines - os principais elementos de metadados, como URLs de origem e horário de extração - sejam capturados e rotulados junto com cada parte do conteúdo. A captura de metadados será inestimável para limpeza, filtragem, desduplicação, depuração e atribuição de dados downstream.

Pedaço

A fragmentação reduz grandes amostras de texto em pedaços menores e discretos que podem caber dentro da janela de contexto de um LLM. Embora as janelas de contexto estejam cada vez maiores - permitindo preencher mais pedaços de conteúdo durante a inferência - o chunking continua sendo uma estratégia vital para atingir o equilíbrio certo entre precisão, recuperação e eficiência computacional.

O chunking eficaz requer a seleção de um tamanho de pedaço apropriado. Tamanhos de blocos maiores tendem a preservar o contexto e o significado semântico de uma parte do texto, em detrimento de permitir que um número menor de blocos esteja presente na janela de contexto. Por outro lado, pedaços menores permitirão que pedaços mais discretos de conteúdo sejam inseridos na janela de contexto do LLM. No entanto, sem proteções adicionais, cada parte do conteúdo corre o risco de ter uma qualidade inferior quando removida do contexto circundante.

Além do tamanho do bloco, você precisará avaliar várias estratégias e métodos de agrupamento. Aqui estão alguns métodos de agrupamento padrão a serem considerados:

• Estratégia de Tamanho Fixo - Neste método, simplesmente escolhemos um número fixo de tokens para nossos pedaços de conteúdo e desconstruímos nosso conteúdo em pedaços menores de acordo. Geralmente, alguma sobreposição entre pedaços adjacentes é recomendada ao usar esta estratégia para evitar perder muito contexto. Esta é a estratégia de chunking mais simples e geralmente um bom ponto de partida antes de se aventurar em estratégias mais sofisticadas.

  
  

• Estratégia de tamanho dinâmico - Este método usa várias características de conteúdo para determinar onde iniciar e parar um pedaço. Um exemplo simples seria um chunker de pontuação, que divide frases com base na presença de caracteres específicos, como pontos e novas linhas. Embora um bloco de pontuação possa funcionar razoavelmente bem para conteúdo curto e direto (ou seja, tweets, descrições de produtos com caracteres limitados, etc.), ele terá desvantagens aparentes se usado para conteúdo mais longo e complexo.

  
  

• Estratégia de reconhecimento de conteúdo - os chunkers com reconhecimento de conteúdo são ajustados ao tipo de conteúdo e metadados que estão sendo extraídos e usam essas características para determinar onde iniciar e parar cada fragmento. Um exemplo pode ser um chunker para blogs HTML que usa tags de cabeçalho para delinear os limites dos chunks. Outro exemplo pode ser um chunker semântico que compara a pontuação de similaridade de cossenos aos pares de cada frase com seus vizinhos anteriores para determinar quando o contexto mudou substancialmente o suficiente para garantir o delineamento de um novo pedaço.

  
  

A estratégia de agrupamento ideal para seu aplicativo RAG precisará ser ajustada ao comprimento da janela de contexto do LLM, à estrutura do texto subjacente, ao comprimento do texto e à complexidade do conteúdo em seu corpus. Experimente várias estratégias de agrupamento e execute suas avaliações após cada alteração para entender melhor o desempenho do aplicativo para uma determinada estratégia. Faça a versão do conteúdo fragmentado nas tabelas do data lake e certifique-se de que cada fragmento tenha informações de linhagem para rastreá-lo até o conteúdo bruto e seus respectivos metadados da etapa de extração de dados upstream.

Enriquecimento

Em muitos casos, os blocos de conteúdo indexados para recuperação durante o RAG são contextualmente diferentes dos prompts reais que seu aplicativo encontrará na produção. Por exemplo, se você estiver construindo um bot de resposta a perguntas de IA, poderá ter um vasto corpus de informações proprietárias que contém inúmeras respostas corretas às dúvidas dos clientes. No entanto, em sua forma bruta, é improvável que seu corpus seja pré-organizado no formato de pares de perguntas e respostas, o que é ideal para recuperação de incorporação baseada em similaridade. Neste exemplo, se no momento da recuperação pesquisássemos ingenuamente em nosso corpus por pedaços de conteúdo bruto que sejam semanticamente semelhantes a uma pergunta de cliente recebida, poderíamos encontrar uma relevância abaixo do ideal do conjunto de resultados da recuperação. Isto resulta do facto de estarmos a comparar a semelhança de itens contextualmente díspares - nomeadamente perguntas com respostas. Felizmente, a solução é relativamente simples: podemos usar o poder dos LLMs para enriquecer as nossas respostas possíveis - também conhecidas como pedaços de conteúdo bruto - recontextualizando-as em questões hipotéticas. Em seguida, indexamos essas questões hipotéticas em nosso banco de dados vetorial para recuperação posterior. Essa técnica, chamada , ilustra o poder do uso de LLMs para enriquecer seus dados no pipeline de processamento de documentos. Aqui está um exemplo de uso desta técnica em algum conteúdo do conhecido :

 System Prompt: Given the provided snippet of text, generate three hypothetical questions that could be asked about it. Each question must be able to be answered using the information within the referenced snippet of text and only that information. Be concise. User Prompt: “At the 52nd Annual Grammy Awards, Beyoncé received ten nominations, including Album of the Year for I Am... Sasha Fierce, Record of the Year for "Halo", and Song of the Year for "Single Ladies (Put a Ring on It)", among others. She tied with Lauryn Hill for most Grammy nominations in a single year by a female artist. In 2010, Beyoncé was featured on Lady Gaga's single "Telephone" and its music video. The song topped the US Pop Songs chart, becoming the sixth number-one for both Beyoncé and Gaga, tying them with Mariah Carey for most number-ones since the Nielsen Top 40 airplay chart launched in 1992. "Telephone" received a Grammy Award nomination for Best Pop Collaboration with Vocals.” Response: Here are some questions that could be asked based on the provided text: * How many nominations did Beyoncé receive at the 52nd Annual Grammy Awards? * For which album was Beyoncé nominated for Album of the Year at the 52nd Annual Grammy Awards? * Which song earned Beyoncé a nomination for Record of the Year at the 52nd Annual Grammy Awards?

Se estiver trabalhando com um corpus composto de conteúdo longo e/ou tematicamente complexo, considere fazer um pré-processamento adicional para pré-resumir pedaços de conteúdo e, assim, reduzir sua dimensionalidade semântica. No momento da recuperação, você pode consultar as incorporações dos resumos dos blocos e, em seguida, substituir o texto não resumido pela inserção da janela de contexto. Este método aumenta a relevância ao fazer RAG em um corpus grande, complexo e/ou que muda frequentemente.

Tokenização

Os grandes modelos de linguagem em 2024 são geralmente redes neurais baseadas em transformadores que não compreendem nativamente a palavra escrita. O texto bruto recebido é convertido em tokens, seguido por vetores de incorporação de alta dimensão otimizados para operações de multiplicação de matrizes. Este processo de entrada é geralmente chamado de codificação. O processo de saída invertido é chamado de decodificação. Muitos LLMs só funcionarão para inferência usando o mesmo esquema de tokenização no qual foram treinados. Portanto, é essencial compreender os fundamentos da estratégia de tokenização escolhida, pois ela pode ter muitas implicações sutis no desempenho.

Embora existam esquemas simples de tokenização em nível de caracteres e palavras, quase todos os LLMs de última geração usam tokenizadores de subpalavras no momento da escrita. Consequentemente, focaremos aqui apenas nessa categoria de tokenizadores.

Os tokenizadores de subpalavras dividem recursivamente as palavras em unidades menores. Isto permite-lhes compreender palavras fora do vocabulário sem aumentar muito o tamanho do vocabulário - uma consideração fundamental para o desempenho do treinamento e a capacidade do LLM de generalizar para textos invisíveis.

Um método predominante de tokenização de subpalavras usado hoje é a codificação de pares de bytes (BPE). Em alto nível, o algoritmo BPE funciona assim:

• Divida as palavras em tokens de unidades de subpalavras e adicione-as ao vocabulário. Cada token representa uma subpalavra governada pela frequência relativa de padrões de caracteres adjacentes comuns dentro do corpus de treinamento.

  
  

• Substitua os pares de tokens comuns da etapa acima por um único token representando o par e adicione-o ao vocabulário.

  
  

• Repita recursivamente as etapas acima.

  
  

A tokenização BPE geralmente é um excelente ponto de partida para seu aplicativo RAG, pois funciona bem para muitos casos de uso. No entanto, suponha que você tenha uma quantidade significativa de linguagem de domínio altamente especializada que não esteja bem representada no vocabulário do corpus de pré-treinamento usado para o modelo escolhido. Nesse caso, considere pesquisar métodos alternativos de tokenização – ou explorar o ajuste fino e a adaptação de baixa classificação, que estão além do escopo deste artigo. O problema de vocabulário restrito mencionado acima pode se manifestar como baixo desempenho em aplicativos desenvolvidos para domínios especializados como medicina, direito ou linguagens de programação obscuras. Mais especificamente, prevalecerá em prompts que incluam linguagem/jargão altamente especializados. Use o conjunto de dados eval armazenado em seu data lake para experimentar diferentes esquemas de tokenização e seu respectivo desempenho com vários modelos, conforme necessário. Lembre-se de que tokenizadores, incorporações e modelos de linguagem costumam estar fortemente acoplados – portanto, a alteração de um pode exigir a alteração dos outros.

Conclusão

Um data lake moderno construído sobre um armazenamento de objetos MinIO - fornece uma infraestrutura básica para colocar em produção aplicativos baseados em RAG com segurança. Com isso implementado, você pode criar avaliações e um conjunto de dados de avaliação específico do domínio que pode ser armazenado e versionado dentro de suas tabelas de data lake. Usando essas avaliações, avalie repetidamente e melhore gradativamente cada componente do pipeline de documentos de seus aplicativos RAG - extratores, chunkers, enriquecimento e tokenizadores - tanto quanto necessário para construir um pipeline de processamento de documentos de nível de produção.

Se você tiver alguma dúvida, entre em contato conosco pelo telefone !