Resumo: O ajuste fino de um modelo de incorporação em dados do domínio pode melhorar significativamente a busca e a precisão da geração aumentada por recuperação (RAG). Com o Databricks, é fácil ajustar, implantar e avaliar modelos de incorporação para otimizar a recuperação para o seu caso de uso específico—aproveitando dados sintéticos sem rotulagem manual.
Por que isso é importante: Se a sua busca por vetores ou sistema RAG não está trazendo os melhores resultados, o ajuste fino de um modelo de incorporação é uma maneira simples, porém poderosa, de melhorar o desempenho. Seja lidando com documentos financeiros, bases de conhecimento ou documentação de código interno, o ajuste fino pode fornecer resultados de pesquisa mais relevantes e melhores respostas de LLM downstream.
O que descobrimos: Ajustamos e testamos dois modelos de incorporação em três conjuntos de dados empresariais e vimos melhorias significativas nas métricas de recuperação (Recall@10) e no desempenho downstream do RAG. Isso significa que o ajuste fino pode ser um divisor de águas para a precisão sem exigir rotulagem manual, aproveitando apenas seus dados existentes.
Quer experimentar o aprimoramento de incorporação? Nós fornecemos uma solução de referência para ajudá-lo a começar. Databricks facilita a busca por vetores, RAG, reranking e o ajuste fino de incorporações. Entre em contato com o seu Executivo de Contas Databricks ou Arquiteto de Soluções para mais informações.
Modelos de incorporação potencializam a busca vetorial moderna e os sistemas RAG. Um modelo de incorporação transforma texto em vetores, tornando possível encontrar conteúdo relevante com base no significado, e não apenas em palavras-chave. No entanto, os modelos prontos nem sempre são otimizados para o seu domínio específico—é aí que entra o ajuste fino.
Ajustar um modelo de incorporação em dados específicos do domínio ajuda de várias maneiras:
Neste post, mostramos que o ajuste fino de um modelo de incorporação é uma maneira eficaz de melhorar a recuperação e o desempenho do RAG para casos de uso específicos da empresa.
Nós ajustamos dois modelos de incorporação (gte-large-en-v1.5 e e5-mistral-7b-instruct) em dados sintéticos e os avaliamos em três conjuntos de dados de nossa Suite de Benchmark de Inteligência de Domínio (DIBS) (FinanceBench, ManufactQA e Databricks DocsQA). Em seguida, os comparamos com o text-embedding-3-large da OpenAI.
Principais Conclusões:
Após comparar três conjuntos de dados, descobrimos que o ajuste fino de incorporação melhora a precisão em dois desses conjuntos de dados. A Figura 1 mostra que para FinanceBench e ManufactQA, as incorporações ajustadas superaram suas versões base, às vezes até superando o modelo API da OpenAI (cinza claro). Para o Databricks DocsQA, no entanto, a precisão do text-embedding-3-large da OpenAI supera todos os modelos ajustados. É possível que isso ocorra porque o modelo foi treinado na documentação pública do Databricks. Isso mostra que, embora o ajuste possa ser eficaz, ele depende fortemente do conjunto de dados de treinamento e da tarefa de avaliação.
Em seguida, comparamos os resultados acima com a reclassificação baseada em API usando voyageai/rerank-1 (Figura 2). Um reclassificador normalmente pega os k resultados principais recuperados por um modelo de incorporação, reclassifica esses resultados por relevância para a consulta de pesquisa e, em seguida, retorna os k principais reclassificados (no nosso caso k=30 seguido por k=10). Isso funciona porque os reclassificadores geralmente são modelos maiores e mais poderosos do que os modelos de incorporação e também modelam a interação entre a consulta e o documento de uma maneira mais expressiva.
O que descobrimos foi:
Os reclassificadores geralmente incorrem em latência adicional de inferência por consulta e custo em relação aos modelos de incorporação. No entanto, eles podem ser usados com bancos de dados de vetores existentes e, em alguns casos, podem ser mais econômicos do que a re-incorporação de dados com um modelo de incorporação mais recente. A escolha de usar um reclassificador depende do seu domínio e das suas necessidades de latência/custo.
Para o FinanceBench, uma melhor recuperação se traduziu diretamente em melhor precisão do RAG quando combinado com o GPT-4o (veja o Apêndice). No entanto, em domínios onde a recuperação já era forte, como o Databricks DocsQA, o ajuste fino não adicionou muito - destacando que o ajuste fino funciona melhor quando a recuperação é um gargalo claro.
Aqui estão alguns dos detalhes mais técnicos da nossa geração de dados sintéticos, ajuste fino e avaliação.
Nós ajustamos dois modelos de incorporação de código aberto:
Em seguida, os comparamos com o text-embedding-3-large da OpenAI.
Avaliamos todos os modelos nos seguintes conjuntos de dados da nossa Suíte de Benchmark de Inteligência de Domínio (DIBS): FinanceBench, ManufactQA e Databricks DocsQA.
Conjunto de dados | Descrição | # Consultas | # Corpus |
---|---|---|---|
FinanceBench | Perguntas sobre documentos SEC 10-K gerados por especialistas humanos. A recuperação é feita em páginas individuais de um superconjunto de 360 arquivos SEC 10-K. | 150 | 53,399 |
ManufactQA | Perguntas e respostas coletadas de fóruns públicos de um fabricante de dispositivos eletrônicos. | 6,787 | 6,787 |
Databricks DocsQA | Perguntas baseadas na documentação publicamente disponível do Databricks gerada por especialistas do Databricks. | 139 | 7,561 |
Reportamos recall@10 como nossa principal métrica de recuperação; isso mede se o documento correto está entre os 10 principais documentos recuperados.
O padrão ouro para a qualidade do modelo de incorporação é o benchmark MTEB, que incorpora tarefas de recuperação como BEIR, bem como muitas outras tarefas não de recuperação. Embora modelos como gte-large-en-v1.5 e e5-mistral-7b-instruct se saiam bem no MTEB, estávamos curiosos para ver como eles se saíam em nossas tarefas internas de empresa.
Treinamos modelos separados em dados sintéticos adaptados para cada um dos benchmarks acima:
Conjunto de Treinamento | Descrição | # Amostras Únicas |
FinanceBench Sintético | Consultas geradas a partir de 2.400 documentos SEC 10-K | ~6,000 |
Documentos Sintéticos de QA do Databricks | Consultas geradas a partir da documentação pública do Databricks. | 8.727 |
ManufactQA | Consultas geradas a partir de PDFs de fabricação de eletrônicos | 14,220 |
Para gerar o conjunto de treinamento para cada domínio, pegamos documentos existentes e geramos consultas de amostra baseadas no conteúdo de cada documento usando LLMs como Llama 3 405B. As consultas sintéticas foram então filtradas por qualidade por um LLM-como-juiz (GPT4o). As consultas filtradas e seus documentos associados foram então usados como pares contrastantes para o ajuste fino. Usamos negativos em lote para treinamento contrastivo, mas adicionar negativos difíceis poderia melhorar ainda mais o desempenho (veja o Apêndice).
Realizamos varreduras em:
Todo o ajuste fino foi feito usando as bibliotecas de código aberto mosaicml/composer, mosaicml/llm-foundry, e mosaicml/streaming na plataforma Databricks.
O ajuste fino é apenas uma abordagem para melhorar a busca de vetores e o desempenho do RAG; listamos algumas abordagens adicionais abaixo.
O ajuste fino dos embeddings pode ser uma vitória fácil para melhorar a recuperação e o RAG em seus sistemas de IA. No Databricks, você pode:
Pronto para experimentar? Nós construímos uma solução de referência para facilitar o ajuste fino - entre em contato com o seu Executivo de Contas Databricks ou Arquiteto de Soluções para obter acesso.
Tamanho |
Recall do FinanceBench@10 |
Recall@10do ManufactQA |
DocsQA Recall@10 |
||||
Linha de base |
Ajustado |
Linha de base |
Ajustado |
Linha de base |
Ajustado |
||
gte-large-en-v1.5 |
0.4B |
0.293 |
0.552 |
0.821 |
0.873 |
0.849 |
0.884 |
e5-mistral-7b-instruct |
7B |
0.479 |
0.670 |
0.836 |
0.913 |
0.899 |
0.899 |
text-embedding-3-large |
Desconhecido |
0.44 |
NA |
0.895 |
NA |
0.95 |
NA |
Tabela 1: Comparação de gte-large-en-v1.5, e5-mistral-7b-instruct e text-embedding-3-large. Mesmos dados da Figura 1.
Gerando Dados de Treinamento Sintéticos
Para todos os conjuntos de dados, as consultas no conjunto de treinamento não eram as mesmas que as consultas no conjunto de teste. No entanto, no caso do Databricks DocsQA (mas não do FinanceBench ou ManufactQA), os documentos usados para gerar consultas sintéticas foram os mesmos documentos usados no conjunto de avaliação. O foco do nosso estudo é melhorar a recuperação em tarefas e domínios específicos (em oposição a um modelo de incorporação generalizável de zero-shot); portanto, vemos isso como uma abordagem válida para certos casos de uso de produção. Para o FinanceBench e ManufactQA, os documentos usados para gerar dados sintéticos não se sobrepunham ao corpus usado para avaliação.
Existem várias maneiras de selecionar passagens negativas para treinamento contrastivo. Eles podem ser selecionados aleatoriamente, ou podem ser pré-definidos. No primeiro caso, as passagens negativas são selecionadas dentro do lote de treinamento; estas são frequentemente referidas como "negativas em lote" ou "negativas suaves". No segundo caso, o usuário pré-seleciona exemplos de texto que são semanticamente difíceis, ou seja, eles são potencialmente relacionados à consulta, mas ligeiramente incorretos ou irrelevantes. Este segundo caso é às vezes chamado de "negativos difíceis". Neste trabalho, simplesmente usamos negativos em lote; a literatura indica que o uso de negativos difíceis provavelmente levaria a resultados ainda melhores.
Detalhes do Ajuste
Para todos os experimentos de ajuste, o comprimento máximo da sequência é definido como 2048. Em seguida, avaliamos todos os pontos de verificação. Para todas as referências, os documentos do corpus foram truncados para 2048 tokens (não divididos), o que era uma restrição razoável para nossos conjuntos de dados específicos. Escolhemos as melhores linhas de base em cada referência após varrer os prompts de consulta e a estratégia de agrupamento.
Melhorando o Desempenho do RAG
Um sistema RAG consiste em um recuperador e um modelo gerativo. O recuperador seleciona um conjunto de documentos relevantes para uma determinada consulta e, em seguida, os alimenta para o modelo gerativo. Selecionamos os melhores modelos gte-large-en-v1.5 ajustados e os usamos para a primeira etapa de recuperação de um sistema RAG simples (seguindo a abordagem geral descrita em Desempenho do RAG de LLMs em Contexto Longo e As Capacidades do RAG de Contexto Longo do OpenAI o1 e Google Gemini). Em particular, recuperamos k=10 documentos cada um com um comprimento máximo de 512 tokens e usamos o GPT4o como o LLM gerativo. A precisão final foi avaliada usando um LLM-como-juiz (GPT4o).
No FinanceBench, a Figura 3 mostra que o uso de um modelo de incorporação ajustado leva a uma melhoria na precisão downstream do RAG. Além disso, é competitivo com o text-embedding-3-large. Isso é esperado, uma vez que o ajuste do gte levou a uma grande melhoria no Recall@10 em relação ao gte de base (Figura 1). Este exemplo destaca a eficácia do ajuste fino do modelo de incorporação em domínios e conjuntos de dados específicos.
No conjunto de dados DocsQA do Databricks, não encontramos melhorias ao usar o modelo gte ajustado acima do gte de linha de base. Isso é um pouco esperado, já que as margens entre os modelos de linha de base e ajustados nas Figuras 1 e 2 são pequenas. Curiosamente, embora o text-embedding-3-large tenha um Recall@10 (ligeiramente) maior do que qualquer um dos modelos gte, ele não leva a uma maior precisão do RAG downstream. Como mostrado na Figura 1, todos os modelos de incorporação tiveram um Recall@10 relativamente alto no conjunto de dados Databricks DocsQA; isso indica que a recuperação provavelmente não é o gargalo para o RAG, e que ajustar um modelo de incorporação neste conjunto de dados não é necessariamente a abordagem mais frutífera.
Gostaríamos de agradecer a Quinn Leng e Matei Zaharia pelo feedback sobre este post do blog.
(This blog post has been translated using AI-powered tools) Original Post