2023 Revisão de artigos antigos: um guia para o processo de construção e avaliação do sistema RAG

O Retrieval Augmented Generation (RAG) está se tornando um dos aplicativos mais populares de modelos de linguagem grande (LLMs) e bancos de dados vetoriais. WeaviateOs aplicativos RAG são comumente usados em chatbots e sistemas de perguntas e respostas. o processo de aumentar a entrada de um modelo de linguagem grande com o contexto recuperado.

Como qualquer sistema de engenharia, a avaliação de desempenho é importante para RAG O pipeline do RAG é dividido em três componentes:

1. indexação
2. recuperar (dados)
3. gerando

A avaliação do RAG é desafiadora devido à complexidade das interações entre esses componentes e à dificuldade de coletar dados de teste. Este artigo demonstrará um desenvolvimento interessante no uso do LLM para avaliação e o estado atual dos componentes do RAG.

Em poucas palavras: Somos inspirados por uma parceria com Ragas Um diálogo entre Jithin James e Shauhul Es, os criadores do LLM, em... Esses novos desenvolvimentos na avaliação LLM dos sistemas RAG, iniciados por Ragas e ARES, nos levaram a refletir sobre as métricas existentes e a fazer um balanço dos parâmetros RAG ajustáveis. No decorrer de nossa pesquisa, refletimos ainda mais sobre as possíveis formas de software de rastreamento experimental RAG e esclarecemos melhor como os sistemas RAG diferem dos sistemas de agentes e como eles são avaliados.

Nossas postagens de blog contêm as cinco seções principais a seguir:

• Avaliação do LLMTendências emergentes na pontuação do desempenho do RAG usando LLM, incluindo zero amostras, poucas amostras e ajuste fino do tamanho do avaliador LLM.
• Indicadores RAGMétricas comuns usadas para avaliar a geração, a pesquisa e a indexação e como elas interagem.
• Parâmetros regulatórios do RAGQuais são as decisões que afetam o desempenho do sistema RAG de maneiras significativamente diferentes?
• agendamentoComo faço para gerenciar o rastreamento da configuração do experimento para o sistema RAG?
• Do RAG à avaliação do agenteDefinimos um RAG como um processo de três etapas de indexação, recuperação e geração. Esta seção descreve quando um sistema RAG é transformado em um sistema de agente e como avaliar suas diferenças.

Avaliação do LLM

Vamos começar com a parte mais nova e mais empolgante: a avaliação do LLM! A história do aprendizado de máquina se baseou muito no trabalho de anotar dados manualmente, como determinar se uma avaliação do Yelp é positiva ou negativa ou se um artigo é relevante para a consulta "Quem é o técnico principal do Boston Celtics?" O LLM está se tornando gradualmente mais eficiente na anotação de dados com menos esforço manual. Essa é uma **"nova tendência "** fundamental que está acelerando o crescimento dos aplicativos RAG.

deixar (para alguém) Ragas A técnica mais comum utilizada por estruturas como a Zero Sample LLM Evaluation é a Zero Sample LLM Evaluation. A avaliação do LLM com amostra zero envolve a solicitação do modelo de linguagem grande com modelos como "Classifique a relevância desses resultados de pesquisa em uma escala de 1 a 10. A consulta é {query} e os resultados da pesquisa são {search_results}." A figura a seguir mostra como o LLM pode ser usado para avaliar o desempenho de um sistema RAG.

Há três grandes oportunidades de ajuste na avaliação do LLM de amostra zero: 1. as métricas de design, como precisão, recall ou nDCG, 2. o idioma específico dessas dicas e 3. o modelo de idioma usado para a avaliação, por exemplo, GPT-4, Coral, Llama-2, Mistral e assim por diante. A principal preocupação no momento é o custo de usar o LLM para avaliação. Por exemplo, avaliar 10 resultados de pesquisa usando o GPT-4 (supondo 500 tokens por resultado, mais 100 tokens para a consulta e o comando, em um total de cerca de 6.000 tokens) custaria cerca de US$ 1.000 por resultado. Token 0,005, ou US$ 3 para avaliar 100 consultas.

Como estruturas como o Ragas promovem a avaliação do LLM com amostra zero, as pessoas estão começando a questionar a necessidade de uma avaliação do LLM com menos amostras. Como a avaliação de LLM de amostra zero é "boa o suficiente", ela pode ser suficiente para servir como a Estrela do Norte para o ajuste do sistema RAG. Conforme mostrado na figura abaixo, a pontuação do RAGAS consiste em quatro solicitações de LLM de amostra zero para cada uma das duas métricas geradas:Fidelidade responder cantando Relevância da resposta (Relevância da resposta)bem como dois indicadores de recuperação:Precisão de contexto (Precisão de contexto) responder cantando Recuperação de contexto (Recuperação de contexto).

 fonte (de informações etc.)

A mudança da avaliação LLM de amostra zero para amostra menor é simples. Incluímos alguns exemplos anotados da relevância dos resultados da pesquisa para a consulta nos modelos de instrução, também conhecidos como aprendizado de contexto. A descoberta dessa técnica foi um dos principais avanços do GPT-3.

Por exemplo, adicionar 5 pontuações de relevância manual ao exemplo acrescentaria 30.000 tokens ao prompt. Assumindo os mesmos custos acima, avaliamos um aumento de US$ 3 para US$ 15 para 100 consultas. Observe que este é um exemplo de estimativa simples e não se baseia em um modelo de preço real para o LLM. Uma consideração importante é que a adição de menos exemplos de amostras pode exigir modelos contextuais mais longos que normalmente têm preços acima do LLM para entradas menores.

Esse tipo de avaliação de LLM com base em zero ou poucas inferências de amostra já é muito atraente, mas pesquisas posteriores mostraram que o custo da avaliação de LLM pode ser reduzido ainda mais por algoritmos de treinamento por meio da destilação de conhecimento. Isso se refere ao uso do LLM para gerar dados de treinamento para uma tarefa de avaliação e ajustá-los em um modelo menor.

existir ARESARES: Em uma estrutura automatizada para avaliar sistemas generativos aprimorados por recuperação, Saad-Falcon et al. descobriram que o treinamento do próprio avaliador LLM pode superar as dicas de amostra zero. Inicialmente, o ARES requer três entradas: uma coleção de parágrafos do corpus de destino, 150 ou mais pontos de dados de validação de preferência humana e 5 exemplos de consultas com amostragem insuficiente dentro do domínio. O ARES usa esses exemplos com amostragem insuficiente para gerar uma grande quantidade de dados de consultas sintéticas, filtrados pelo princípio da consistência de loop: ou seja, ao pesquisar com uma consulta sintética, ele pode recuperar o documento que gerou a consulta sintética? . Em seguida, o ARES gera os dados para a relevância contextualeAutenticidade das respostas responder cantando Relevância das respostas Ajuste fino de classificadores leves.

Ajuste fino experimental do autor DeBERTa-v3-grandeO modelo contém 437 milhões de parâmetros mais econômicos, com cada cabeça de classificador compartilhando o modelo de idioma básico, adicionando um total de três cabeças de classificação. Ao dividir os dados sintéticos em conjuntos de treinamento e teste, a avaliação do sistema ARES constatou que o modelo ajustado superou significativamente o desempenho do GPT-3.5-turbo-16k com zero e poucas amostras. Para obter mais detalhes (por exemplo, uso inovador de intervalos de confiança na inferência orientada por previsão (PPI) e detalhes dos experimentos), consulte Saad-Falcon et al.Tese.

Para entender melhor o possível impacto do LLM na avaliação, continuaremos a descrever a metodologia de benchmarking sistemático do RAG existente e suas variações específicas na avaliação do LLM.

Indicadores RAG

Apresentamos as métricas do RAG a partir da perspectiva de nível superior de geração, recuperação e indexação. Em seguida, apresentamos os parâmetros de ajuste do RAG a partir da perspectiva de nível inferior de criação de índices, métodos de recuperação de ajuste e opções de geração.

Outro motivo para apresentar as métricas do RAG de uma perspectiva de nível superior é que os erros na indexação são transmitidos para a pesquisa e a geração, mas os erros na geração (como as camadas que definimos) não afetam os erros na indexação. No estado atual da avaliação de RAGs, raramente há uma avaliação de ponta a ponta da pilha de RAGs, e geralmente se supõe que o contexto do oráculo talvez termo de interferência controlada (CIT)(por exemplo, o experimento Lost in the Middle) para determinar a veracidade gerada e a relevância da resposta. Da mesma forma, as incorporações são normalmente avaliadas com um índice violento que não leva em conta o erro do vizinho mais próximo aproximado. O erro do vizinho mais próximo aproximado geralmente é medido encontrando-se o ponto ideal de precisão em termos de compensação entre consulta por segundo e recuperação, sendo que a recuperação de ANN são os verdadeiros vizinhos mais próximos da consulta, e não os documentos marcados como "relevantes" para a consulta.

Geração de indicadores

O objetivo geral do aplicativo RAG é gerar resultados úteis, apoiados pelo uso do contexto recuperado. A avaliação deve levar em conta que o resultado usa o contexto e não é extraído diretamente da fonte, evitando informações redundantes e impedindo respostas incompletas. Para pontuar o resultado, é necessário desenvolver métricas que abranjam cada critério.

Ragas Duas pontuações são introduzidas para medir o desempenho do resultado do Large Language Modelling (LLM): plausibilidade e relevância da resposta.grau de credibilidade Avalie a precisão factual da resposta com base no contexto da pesquisa.Relevância das respostas Determine a relevância da resposta em relação à pergunta. As respostas podem ter pontuações altas de credibilidade, mas pontuações baixas de relevância da resposta. Por exemplo, uma resposta plausível pode replicar diretamente o contexto, mas isso resulta em uma baixa relevância da resposta. As pontuações de relevância da resposta são penalizadas quando as respostas não são completas ou contêm informações duplicadas.

Em 2020, o Google lançou MeenaO objetivo da Meena é mostrar que ela pode conduzir Razoável e específico do diálogo. Para medir o desempenho dos chatbots de domínio aberto, eles introduziram a métrica de avaliação Sensibleness and Specificity Average (SSA). A razoabilidade da resposta do bot precisa fazer sentido no contexto e ser específica (média de especificidade). Isso garante que o resultado seja abrangente e não ambíguo.2020 Para isso, é necessário que um ser humano converse com o chatbot e o pontue manualmente.

Embora seja bom evitar respostas vagas, é igualmente importante evitar que modelos de linguagem grandes apareçam fruto da imaginação de alguém . A ilusão refere-se ao fato de que as respostas geradas pelo Big Language Model não se baseiam em fatos reais ou no contexto fornecido.LlamaIndex fazer uso de FaithfulnessEvaluator (Avaliador de fidelidade) métricas para medir isso. As pontuações são baseadas no fato de a resposta ser consistente com o contexto recuperado.

A avaliação da qualidade das respostas geradas depende de vários indicadores. As respostas podem ser factuais, mas não relevantes para a consulta em questão. Além disso, a resposta pode ser vaga e carecer de informações contextuais essenciais para apoiar a resposta. Em seguida, voltaremos à camada anterior do pipeline e discutiremos as métricas de recuperação.

Recuperação de indicadores

A próxima camada da pilha de avaliação é a recuperação de informações. A avaliação do histórico de recuperação exige que os humanos anotem quais documentos são relevantes para a consulta. Assim, para criar uma anotação de consulta, talvez seja necessário anotar a relevância de 100 documentos. Essa já é uma tarefa extremamente difícil para consultas de pesquisa gerais, e o desafio é ainda mais exacerbado ao criar mecanismos de pesquisa específicos de um domínio (por exemplo, contratos legais, históricos de pacientes médicos etc.).

Para aliviar os custos de anotação, a heurística é frequentemente usada para determinar a relevância da pesquisa. A mais comum delas é o registro de cliques, ou seja, dada uma consulta, os títulos clicados podem ser relevantes, enquanto os títulos não clicados não são. Isso também é conhecido como supervisão fraca no aprendizado de máquina.

Quando o conjunto de dados estiver pronto, as três métricas comumente usadas na avaliação são: nDCG eRecall responder cantando Precisão O NDCG (Ganho cumulativo com desconto normalizado) mede as classificações por várias tags de relevância. Por exemplo, um documento sobre vitamina B12 pode não ser o resultado mais relevante para uma consulta sobre vitamina D, mas é mais relevante do que um documento sobre o Boston Celtics. Devido à complexidade adicional da classificação relativa, os rótulos de relevância binária (1 para relevante e 0 para irrelevante) são usados com frequência. O Recall mede quantas amostras positivas são capturadas nos resultados da pesquisa e a Precisão mede a proporção de resultados da pesquisa que são rotulados como relevantes.

Assim, o Big Language Model pode calcular a precisão com a seguinte solicitação: "Quantos dos seguintes resultados de pesquisa estão relacionados à consulta {query}? {search_results}". Um proxy para Recall também pode ser obtido com o prompt do Big Language Model: "Esses resultados de pesquisa contêm todas as informações necessárias para responder à consulta {query}? {search_results}". Também incentivamos o leitor a conferir algumas das dicas em Ragas aqui (literário).

Outra métrica que vale a pena explorar é o LLM Wins, em que o prompt do Big Language Modelling é: "Com base na consulta {query}, qual conjunto de resultados de pesquisa é mais relevante? Conjunto A {Conjunto_A} ou Conjunto B {Conjunto_B}. Muito importante! Por favor, limite o resultado a 'Set A' ou 'Set B'".

Agora vamos nos aprofundar um pouco mais e entender como comparar índices vetoriais.

Indicadores indexados

Os usuários experientes e familiarizados com o Weaviate devem saber que Benchmarks ANNO teste de benchmarking inspirou Desenvolvimento da API gRPC na versão 1.19 do WeaviateO benchmark ANN mede as consultas por segundo (QPS) em relação à recuperação e inclui a consideração de detalhes, como limitações de thread único. Enquanto os bancos de dados são normalmente avaliados com base na latência e nos custos de armazenamento, os índices de vetores aleatórios são mais focados em medidas de precisão. Isso contrasta com Cálculos aproximados em instruções SQL select Algo semelhante, mas prevemos que os erros causados por aproximações receberão mais atenção à medida que a indexação de vetores se tornar mais popular.

A precisão é medida pelo Recall. Na indexação de vetores, a recuperação refere-se à razão entre o número de vizinhos mais próximos verdadeiros retornados pelo algoritmo de indexação aproximada e o número de vizinhos mais próximos determinados pela pesquisa de força bruta. Isso é diferente do uso típico de "recall" na recuperação de informações, que se refere à proporção de documentos relevantes recuperados em relação a todos os documentos relevantes. Ambos são geralmente medidos com um parâmetro @K associado.

No contexto da pilha RAG completa, há uma questão interessante:Quando os erros de precisão da RNA levam a erros na recuperação de informações (RI)? Por exemplo, talvez consigamos atingir 1.000 QPS com uma revocação de 80% ou 500 QPS com uma revocação de 95%. Qual é o impacto nas métricas de pesquisa mencionadas acima (por exemplo, a pesquisa de pontuações de revocação de nDCG ou Large Language Modelling (LLM))?

Resumo dos indicadores RAG

Em resumo, mostramos métricas para avaliar a indexação, a recuperação e a geração:

• gerandoA métrica de detecção de alucinações em larga escala (por exemplo, Rationality and Specificity Average, Sensibleness and Specificity Average, SSA).
• recuperar (dados)Novas oportunidades para precisão contextual vs. recuperação contextual na pontuação LLM e uma visão geral da anotação humana para medir a recuperação, a precisão e o nDCG.
• indexaçãoRecall: O Recall é medido pelo número de vizinhos mais próximos verdadeiros retornados pelo algoritmo de pesquisa vetorial. Acreditamos que a principal questão aqui é:Quando os erros de ANN se transformam em erros de IR?

Em geral, todos os componentes podem ser negociados entre desempenho e latência ou custo. Ao usar um modelo de linguagem mais caro, podemos obter uma geração de maior qualidade; ao filtrar os resultados com um reordenador, podemos obter uma recuperação de maior qualidade; ao usar mais memória, podemos obter uma indexação de maior recall. Como gerenciar essas compensações para melhorar o desempenho pode ficar mais claro à medida que continuarmos a investigar os "botões do RAG". Como observação final, optamos por apresentar as métricas de uma perspectiva de cima para baixo, desde a geração até a pesquisa e a indexação, porque o tempo de avaliação está mais próximo da experiência do usuário. Também apresentaremos os botões de ajuste de uma perspectiva de baixo para cima, da indexação à busca e geração, pois isso é mais semelhante à experiência de um desenvolvedor de aplicativos RAG.

Parâmetros de ajuste do RAG

Agora que já discutimos as métricas para comparar os sistemas RAG, vamos nos aprofundar nas principais decisões que podem afetar significativamente o desempenho.

Parâmetros de ajuste do índice

O parâmetro de ajuste de indexação mais importante ao projetar um sistema RAG é a configuração de compactação de vetor, introduzida no Weaviate 1.18 em março de 2023 como Product Quantization (PQ), um algoritmo de compactação de vetor que agrupa fragmentos consecutivos de vetores, agrupa os valores no conjunto e reduz a precisão pelo centro de massa. Por exemplo, um fragmento contíguo de quatro números de ponto flutuante de 32 bits leva 16 bytes para ser representado, enquanto um fragmento de comprimento 4 com oito centros de massa leva apenas 1 byte, atingindo uma taxa de compactação de memória de 16:1. Avanços recentes na reordenação de PQ reduziram significativamente a perda de recall devido à compactação, mas ela ainda deve ser considerada com cautela em níveis muito altos de compactação.

O próximo é o índice de roteamento usado. Para conjuntos de dados com menos de 10 mil vetores, os aplicativos RAG podem ficar satisfeitos com a indexação de força bruta. No entanto, à medida que o número de vetores aumenta, a latência da indexação de força bruta é muito maior do que a indexação baseada em algoritmos de gráfico de proximidade, como o HNSW. Conforme descrito nas métricas do RAG, o desempenho do HNSW é normalmente medido pelo ponto ideal de Pareto, que pondera a consulta por segundo em relação à recuperação. Isso é feito ajustando o tamanho da fila de pesquisa usada para inferência. ef para que isso aconteça. Maior ef realizará mais comparações de distância durante o processo de pesquisa, o que o torna significativamente mais lento, mas produz resultados mais precisos. Os próximos parâmetros incluem aqueles usados na construção do índice, como efConstruction (o tamanho da fila ao inserir dados no gráfico) e maxConnections (número de bordas por nó, a ser armazenado com cada vetor).

Outra nova direção que estamos explorando é o efeito do viés distributivo no centro de massa dos PQs e a relação com algoritmos híbridos de agrupamento e indexação de gráficos, como DiskANN talvez IVFOADC+G+P) interações. O uso da métrica de recuperação pode ser suficiente para determinar se o centro de massa precisa ser readaptado, mas a questão permanece: qual subconjunto de vetores usar para readaptação. Se usarmos os 100 mil vetores mais recentes que fazem com que a recuperação caia, talvez estejamos ajustando demais a uma nova distribuição, portanto, talvez seja necessário fazer uma amostragem de uma mistura de linhas de tempo de distribuição de dados. Esse tópico está intimamente relacionado ao nosso ponto sobre otimização contínua de modelos de aprendizagem profunda e pode ser discutido mais detalhadamente na seção "Otimização regulatória".

A fragmentação de dados é uma etapa importante antes de inserir dados no Weaviate. A fragmentação converte documentos longos em partes menores. Isso melhora a recuperação porque cada parte contém informações importantes e ajuda a manter-se dentro dos limites de tokens do modelo de linguagem grande (LLM). Há várias estratégias de análise de documentos. A figura acima mostra um exemplo de análise de um artigo de pesquisa com base em seu título. Por exemplo, o bloco 1 é o resumo, o bloco 2 é a introdução e assim por diante. Há também maneiras de combinar pedaços e criar sobreposições. Isso inclui uma janela deslizante que pega um token do bloco anterior e o usa como o início do próximo bloco. Uma leve sobreposição de blocos melhora a busca, pois o recuperador consegue entender o contexto/bloco anterior. A imagem a seguir mostra um esquema de alto nível do texto em blocos.

recuperar (dados)

Há quatro parâmetros principais ajustáveis na pesquisa: o modelo de incorporação, os pesos da pesquisa híbrida, o uso ou não do AutoCut e o modelo de reordenação.

É provável que a maioria dos desenvolvedores de RAG concilie imediatamente o modelo de incorporação usado, por exemplo, OpenAI, Cohere, Voyager, Jina AI, Sentence Transformers e muitas outras opções! Os desenvolvedores também precisarão considerar a dimensionalidade do modelo e seu efeito na compactação de PQ.

A próxima decisão importante é como ajustar os pesos de agregação para métodos de recuperação esparsos e densos na busca híbrida. Os pesos são baseados no parâmetro alfa.alfa 0 é puro bm25 Pesquisar.alfa para 1 é uma pesquisa vetorial pura. Portanto, definir alfa Depende de seus dados e aplicativos.

Outro desenvolvimento emergente é a eficácia dos modelos de reordenação de amostra zero. A Weaviate oferece atualmente 2 Modelo de reordenação de Cohere::rerank-english-v2.0 responder cantando rerank-multilingual-v2.0. Como o nome sugere, esses modelos diferem principalmente devido aos dados de treinamento usados e aos recursos multilíngues resultantes. No futuro, esperamos oferecer mais opções em termos de recursos do modelo, o que envolve uma compensação inerente entre desempenho e latência que pode fazer sentido para alguns aplicativos, mas não para outros. No processo de ajuste dos parâmetros na recuperação, foi um desafio descobrir que tipo de reordenador capaz era necessário e quantos resultados de recuperação precisavam ser reordenados. Esse também é um dos pontos de entrada mais fáceis para o ajuste fino de modelos personalizados na pilha RAG, que discutiremos mais detalhadamente em "Otimização regulatória".

Outro parâmetro de ajuste interessante é a pesquisa multi-index. Semelhante à nossa discussão sobre chunking, isso envolve mudanças estruturais no banco de dados. A questão geral é:Quando devo usar uma coleta seletiva em vez de um filtro? deve transferir blogs responder cantando documentação em dois conjuntos, ou armazená-los em conjunto em uma coleção com um fonte atributo Documento Na categoria?

O uso de filtros nos proporciona uma maneira rápida de testar a utilidade desses rótulos, pois podemos adicionar vários rótulos a cada bloco e, em seguida, ablacionar para analisar como o classificador faz uso deles. Há várias ideias interessantes, como rotular explicitamente a origem do contexto na entrada de contexto para o LLM, por exemplo, "Os seguintes são resultados de pesquisa de blogs {search_results}. Aqui estão os resultados de pesquisa de documentos {documentação}". Como o LLM é capaz de lidar com entradas mais longas, esperamos que a fusão de contexto entre várias fontes de dados se torne mais comum, de modo que surja outro hiperparâmetro relevante: quantos documentos são recuperados de cada índice ou filtro.

gerando

A primeira coisa a se concentrar em relação à geração é qual modelo de linguagem grande (LLM) escolher. Por exemplo, você pode escolher modelos da OpenAI, Cohere, Facebook e muitas opções de código aberto. Muitas estruturas de LLM (por exemplo LangChaineLlamaIndex responder cantando Módulo de geração da Weaviate) oferece fácil integração com uma variedade de modelos, o que é uma grande vantagem. A escolha do modelo pode depender de fatores como, por exemplo, se você deseja que seus dados permaneçam privados, custo, recursos etc.

Um parâmetro de regulação comum e específico do LLM é a temperatura. A configuração de temperatura controla a aleatoriedade do resultado. Uma temperatura de 0 significa que a resposta é mais previsível e menos variável; uma temperatura de 1 permite que o modelo introduza aleatoriedade e criatividade na resposta. Portanto, se você executar o modelo generativo várias vezes com a temperatura definida como 1, a resposta poderá ser diferente a cada nova execução.

Os modelos de contexto longo (LCMs) são uma direção emergente na escolha de um LLM para seu aplicativo. Adicionar mais resultados de pesquisa como entrada melhora a qualidade da resposta? A pesquisa sobre o experimento Lost in the Middle levanta alguns sinais de alerta. Em "Lost in the Middle" (Perdido no meio) Nele, pesquisadores de Stanford, UC Berkeley e Samaya AI realizaram experimentos controlados mostrando que, se as informações relevantes forem colocadas no meio de um resultado de pesquisa, em vez de no início ou no final, o modelo de linguagem pode não ser capaz de integrar essas informações ao gerar uma resposta. Outro artigo de pesquisadores do Google DeepMind, Toyota e Purdue University observa:"Modelos de linguagem grandes são facilmente distraídos por contextos irrelevantes.". Apesar do potencial dessa direção, até o momento em que este artigo foi escrito, o RAG de contexto longo ainda está em seus estágios iniciais. Felizmente, métricas como as pontuações Ragas podem nos ajudar a testar rapidamente novos sistemas!

Semelhante às recentes descobertas na avaliação de LLM que discutimos anteriormente, o aspecto generativo do ajuste é dividido em três estágios: 1. ajuste do prompt, 2. exemplos de poucas tentativas e 3. ajuste fino. O ajuste do prompt envolve o ajuste de expressões linguísticas específicas, como "Por favor, responda à pergunta com base nos resultados de pesquisa fornecidos". versus "Por favor, responda à pergunta. Importante, siga atentamente as instruções abaixo. Sua resposta à pergunta deve se basear somente nos resultados de pesquisa fornecidos!!!" A diferença entre.

Conforme mencionado anteriormente, uma amostra menos um exemplo refere-se à coleta de vários pares de perguntas, contextos e respostas escritos manualmente para orientar a geração de um modelo de linguagem. Estudos recentes (por exemplo "Vetor de contexto") demonstra ainda mais a importância de inicializar o espaço potencial dessa forma. No projeto Weaviate Gorilla, usamos o GPT-3.5-turbo para gerar consultas Weaviate e, quando adicionamos linguagem natural à tradução da consulta dos exemplos de amostra menores, o desempenho melhorou significativamente.

Por fim, o ajuste fino do LLM para aplicativos RAG está recebendo cada vez mais atenção. Aqui estão algumas abordagens a serem consideradas. Voltando novamente à nossa discussão sobre a avaliação do LLM, talvez queiramos gerar dados de treinamento usando um LLM mais robusto para criar um modelo menor e mais acessível de nossa propriedade. Outra ideia é fornecer anotação humana da qualidade da resposta para que o LLM possa ser ajustado com o comando a seguir. Se você estiver interessado no ajuste fino do modelo, confira a contribuição de Brev sobre como usar a biblioteca HuggingFace PEFT em tutoriais.

Resumo das opções de ajuste do RAG

Em resumo, descrevemos as principais opções de ajuste disponíveis no sistema RAG:

• Indexação: no nível mais alto, precisamos considerar quando usar somente a pesquisa de força bruta e quando introduzir a indexação ANN. Isso é particularmente interessante ao ajustar casos de uso de vários locatários com usuários novos versus usuários mais fortes. Na indexação ANN, temos hiperparâmetros para PQ (fragmentação, centro de massa e limites de treinamento). hNSW inclui (ef, efConstruction e maxConnections).
• Recuperação: seleção de um modelo de incorporação, ajuste de pesos de pesquisa híbrida, seleção de um reordenador e particionamento de uma coleção em vários índices.
• Gerar: selecione um LLM e decida quando fazer a transição do ajuste de dicas para exemplos com menos amostras ou ajuste fino.

Depois de entender as métricas RAG e como melhorar seu desempenho por meio do ajuste, vamos discutir as possíveis implementações do rastreamento experimental.

agendamento

Considerando os recentes avanços no campo da avaliação de LLMs (Large Language Model) e uma visão geral de alguns dos parâmetros ajustáveis, há uma excelente oportunidade de combinar tudo isso com uma estrutura de rastreamento de experimentos. Por exemplo, um orquestrador simples com uma API intuitiva poderia ser usado para que o usuário executasse o seguinte: 1. solicitar um teste completo de 5 LLMs, 2 modelos incorporados e 5 configurações de indexação; 2. executar os experimentos; e 3. retornar um relatório de alta qualidade para o usuário.O Weights & Biases criou um caminho de rastreamento experimental notável para o treinamento de modelos de aprendizagem profunda. Esperamos que o interesse pelo suporte experimental RAG cresça rapidamente com os parâmetros ajustáveis e as métricas descritas neste documento.

Estamos seguindo duas direções de desenvolvimento nessa área. Por um lado, os LLMs de amostra zero existentes (por exemplo, GPT-4, Command, Claude, bem como as opções de código aberto Llama-2 e Mistral) não são tão eficazes em ter um contexto do oráculo teve um desempenho muito bom na época. Portanto, há uma grande oportunidade para Concentre-se na parte da pesquisa . Para isso, é necessário encontrar maneiras de compensar erros de ANN, modelos incorporados, ponderação de pesquisa híbrida e reordenação de PQ ou HNSW em várias configurações, conforme descrito anteriormente neste documento.

O Weaviate 1.22 apresenta índices assíncronos e APIs de estado de nó correspondentes, que esperamos que, por meio de parcerias focadas na avaliação de RAG e na orquestração de ajuste, possam ser aproveitadas para determinar quando os índices terminaram de ser criados e, em seguida, executar testes. Isso é particularmente interessante quando se considera o ajuste das interfaces de orquestração com cada locatário com base nesses estados de nó, em que alguns locatários podem confiar na pesquisa de força bruta, enquanto outros precisam encontrar o modelo de incorporação e a configuração de HNSW corretos para seus dados.

Além disso, talvez queiramos acelerar os testes paralelizando a alocação de recursos. Por exemplo, avaliar 4 modelos de incorporação ao mesmo tempo. Conforme mencionado anteriormente, outra parte interessante é o ajuste de blocos ou outros metadados simbólicos que podem vir do importador de dados. Por exemplo, o conjunto de dados do Weaviate Verba contém 3 pastas do Weaviate BlogseDocumentação responder cantando Vídeo Transcrição. Se quisermos comparar tamanhos de pedaços de 100 e 300, não há necessidade de chamar novamente o rastreador da Web. Talvez precisemos de outro formato, seja de dados armazenados em buckets de armazenamento do S3 ou de outra forma, com metadados associados, mas é uma maneira mais econômica de fazer experimentos.

Por outro lado, temos o ajuste fino do modelo e a aprendizagem contínua baseada em gradiente em vez da inserção ou atualização de dados. Os modelos mais comuns usados no RAG são modelos incorporados, modelos reordenados e, é claro, LLMs. Manter os modelos de aprendizado de máquina atualizados com novos dados tem sido um foco de longa data das estruturas de aprendizado contínuo e das orquestrações de MLops que gerenciam o retreinamento, o teste e a implantação de novos modelos. Começando com o LLM de aprendizagem contínua, um dos maiores argumentos de venda do sistema RAG é a capacidade de estender a data de "corte" da base de conhecimento do LLM para mantê-la em sincronia com seus dados. Não achamos que esteja claro o quanto o treinamento contínuo interage bem com o simples fato de manter as informações atualizadas por meio do RAG. Alguns estudos (por exemplo, MEMIT) fizeram experiências com análises de mediação causal da atribuição de peso, atualizando fatos como "LeBron James joga basquete" para "LeBron James joga futebol". " e assim por diante. Essa é uma técnica bastante avançada, e outra oportunidade pode ser simplesmente rotular os blocos usados no treinamento (por exemplo, "LeBron James joga basquete") e treiná-los novamente usando dados de treinamento aprimorados por recuperação que contenham as novas informações. Essa é uma área importante que estamos observando atentamente.

Conforme mencionado anteriormente, também estamos considerando como integrar esse tipo de ajuste contínuo diretamente na Weaviate usando centros principais de PQ. O centroide PQ para os primeiros K vetores que entram na Weaviate pela primeira vez pode ser afetado por alterações significativas na distribuição de dados. O treinamento contínuo de modelos de aprendizado de máquina sofre com o infame problema do "esquecimento catastrófico", em que o treinamento do último lote de dados prejudica o desempenho de lotes anteriores. Essa é uma das considerações que levamos em conta ao projetar a readaptação do centro de massa do PQ.

Do RAG à avaliação do agente

Ao longo deste artigo, vamos nos concentrar na RAG Em vez de Agente Avaliação. Em nossa opinião.RAG definido como o processo de indexação, recuperação e geração, e o Agentes O escopo do sistema é mais aberto. O diagrama abaixo ilustra como vemos os principais componentes, como planejamento, memória e ferramentas, que juntos fornecem recursos significativos para o seu sistema, mas também dificultam a avaliação.

Uma próxima etapa comum dos aplicativos RAG é adicionar um mecanismo de consulta avançado. Para os leitores que não conhecem esse conceito, confira nossa série LlamaIndex e Weaviate, que fornece exemplos de código Python sobre como começar. Há muitos mecanismos de consulta avançada diferentes, como mecanismos de consulta de subperguntas, roteadores SQL, mecanismos de consulta autocorretiva e outros. Também estamos considerando possíveis formas da API promptToQuery ou do extrator de consultas de pesquisa no módulo Weaviate. Cada mecanismo de consulta tem suas próprias vantagens no processo de recuperação de informações, portanto, vamos nos aprofundar em alguns deles e em como podemos avaliá-los.

O mecanismo de consulta multi-hop (também conhecido comoMecanismo de consulta de subquestões) é perfeito para dividir problemas complexos em subproblemas. No diagrama acima, temos a pergunta "O que é Ref2Vec no Weaviate?" Para responder a essa pergunta, você precisa saber o que são Ref2Vec e Weaviate, respectivamente. Para responder a essa pergunta, você precisa saber o que são Ref2Vec e Weaviate, respectivamente. Portanto, seu banco de dados precisa ser chamado duas vezes para ambas as perguntas a fim de recuperar o contexto relevante. As duas respostas são então combinadas para produzir um único resultado. A avaliação do desempenho de um mecanismo de consulta multihop pode ser feita observando as subperguntas. É importante que o LLM crie subperguntas relevantes, responda a cada pergunta com precisão e combine as duas respostas para fornecer um resultado factualmente preciso e relevante. Além disso, se você estiver fazendo perguntas complexas, é melhor usar um mecanismo de consulta com vários saltos.

Os problemas de vários saltos dependem, antes de tudo, da precisão das subperguntas. Poderíamos usar uma avaliação LLM semelhante aqui, com a seguinte solicitação: "Dada a pergunta: {query}. Um sistema decidiu dividi-la em subperguntas {sub_pergunta_1} e {sub_pergunta_2}. Essa decomposição da pergunta faz sentido?" Em seguida, realizamos duas avaliações RAG separadas para cada subpergunta e avaliamos se o LLM pode combinar as respostas de cada pergunta para responder à pergunta original.

Como outro exemplo da evolução da complexidade de RAGs para Agentes, vamos considerar os mecanismos de consulta de roteamento. A figura abaixo ilustra como um agente pode rotear uma consulta para uma consulta de banco de dados SQL ou vetorial. Esse cenário é muito semelhante à nossa discussão sobre roteamento de vários índices, e podemos usar uma abordagem semelhante para avaliar os resultados gerados, sugerindo a necessidade de declarar bancos de dados SQL e vetoriais e, em seguida, perguntar ao roteador LLM se ele tomou a decisão correta. Também poderíamos usar a pontuação de relevância do contexto RAGAS para resultados de consultas SQL.

Para resumir a discussão de "Do RAG à avaliação de agentes", acreditamos que atualmente é impossível dizer quais são os padrões comuns de uso de agentes. Mostramos intencionalmente mecanismos de consulta multi-hop e roteadores de consulta porque são relativamente fáceis de entender. Quando adicionarmos avaliações mais abertas relacionadas a loops de planejamento, uso de ferramentas e como avaliar a capacidade de um modelo de formatar solicitações de API de ferramentas, bem como dicas de gerenciamento de memória meta-interna, como as do MemGPT, será difícil fornecer uma abstração comum sobre como avaliar os agentes.

chegar a um veredicto

Muito obrigado por ler nossa visão geral da avaliação do RAG! Para recapitular rapidamente, primeiro apresentamos a nova tendência de usar LLMs para avaliação, o que proporciona uma economia significativa de custo e tempo para sistemas RAG iterativos. Em seguida, apresentamos mais informações sobre as métricas tradicionais usadas para avaliar pilhas de RAGs, da geração à pesquisa e à indexação. Para os criadores que desejam melhorar o desempenho dessas métricas, mostramos alguns parâmetros ajustáveis para indexação, pesquisa e geração. Apresentamos os desafios do rastreamento experimental desses sistemas e descrevemos nossos pontos de vista sobre as diferenças entre a avaliação do RAG e a avaliação do agente. Esperamos que este artigo seja útil para você!