Création d'une grande base de connaissances de questions-réponses de modèle de langage basée sur les services technologiques cloud d'Amazon

Avec l'amélioration évidente de l'effet du grand modèle de langage, ses applications associées continuent d'émerger et montrent une tendance de plus en plus populaire. L'une des voies techniques les plus largement concernées est la méthode du grand modèle de langage (LLM) + rappel de connaissances (Knowledge Retrieval), qui peut bien compenser certaines lacunes du modèle général de grand langage en termes de réponse aux questions de connaissances du domaine privé, et résoudre le problème des grands modèles de langage généraux.Les modèles de langage répondent au manque de base, aux hallucinations et à d'autres questions dans le domaine professionnel. L'idée de base est de découper les documents de connaissances du domaine privé, puis de les vectoriser, puis de les rappeler via la récupération vectorielle, puis de les saisir comme contexte dans le grand modèle de langage pour l'induction et le résumé.

 Dans la pratique spécifique de cette direction technique, la base de connaissances peut être construite à l'aide de deux méthodes d'index basées sur l'inversion et le vecteur, qui jouent un rôle clé dans l'étape de rappel des connaissances dans le processus de réponse aux questions de connaissances, et l'index de document ordinaire ou l'index de journal différent , la vectorisation des connaissances nécessite la capacité sémantique du modèle profond, et il existe des étapes supplémentaires telles que la segmentation des documents, le déploiement et le raisonnement du modèle vectoriel. Dans le processus de construction d'une base de données de vectorisation des connaissances, non seulement la taille du document original doit être prise en compte, mais également la granularité de la segmentation, la dimension vectorielle et d'autres facteurs. En fin de compte, le nombre d'éléments de connaissances indexés par la base de données vectorielles peut atteindre une très grande ampleur, qui peut être déterminée par Causée par les deux aspects suivants :

  • La quantité de documents existants dans divers secteurs, tels que les domaines de la finance, de la médecine et du droit, est très élevée, et la quantité de nouveaux documents est également importante.

  • Afin de poursuivre l'effet de rappel, la segmentation des documents adopte souvent un stockage redondant multi-granularité par phrase ou segment.

 Ces détails posent certains défis aux performances d'écriture et de requête de la base de données vectorielles de connaissances. Afin d'optimiser la construction et la gestion de la base de connaissances vectorisée, basée sur les services de la technologie cloud d'Amazon, le processus de construction de la base de connaissances comme indiqué dans ce qui suit la figure est construite :

  • Le Lambda est déclenché en temps réel via le Handler du Bucket S3 pour démarrer le job Glue correspondant au stockage du fichier de connaissances

  • L'analyse et le fractionnement des documents seront effectués dans le travail Glue, et le modèle d'intégration de SageMaker sera appelé pour la vectorisation.

  • Injecter dans Amazon OpenSearch via Bulk

 Il résume également certaines bonnes pratiques et expériences sur divers aspects impliqués dans l'ensemble du processus, notamment sur la manière de vectoriser les connaissances et d'optimiser la base de données vectorielles.

 vectorisation des connaissances

 Fractionnement de documents

 La pré-étape de la vectorisation des connaissances consiste à diviser les connaissances, et le maintien de l’intégrité sémantique est la considération la plus importante. Discutez sous deux aspects. Comment choisir les deux points d’intérêt suivants résume respectivement une certaine expérience :

 A. Méthode de division des fragments

 Concernant cette partie du travail, Langchain, en tant que grand cadre d'intégration de modèles de langage populaire, fournit de nombreux Document Loader et Text Spiltters, dont certains ont une valeur de référence, mais beaucoup d'entre eux sont répétitifs.

 À l'heure actuelle, la méthode de base la plus utilisée consiste à utiliser le RecursiveCharacterTextSplitter dans Langchain, qui est le séparateur par défaut de Langchain. Il utilise cette liste de caractères délimités à plusieurs niveaux - ["\n\n", "\n", " ", ""] pour diviser. Par défaut, elle sera divisée en fonction du paragraphe en premier. Si la taille du morceau du Le résultat du fractionnement dépasse, puis continuez à utiliser le niveau suivant de caractères séparateurs pour continuer le fractionnement jusqu'à ce que les exigences de chunk_size soient remplies.

 Cependant, cette approche est relativement approximative et peut quand même entraîner le désassemblage de certains contenus clés. Pour certains autres formats de documents, il peut y avoir des pratiques plus nuancées.

  • Le fichier FAQ doit être découpé selon la granularité d'une question et d'une réponse. La saisie vectorisée ultérieure ne peut utiliser que des questions ou des questions + réponses.

  • Pour les fichiers Markdown, "#" est un caractère spécial utilisé pour identifier le titre. MarkdownHeaderTextSplitter peut être utilisé comme séparateur, ce qui permet de mieux garantir que le contenu et le titre sont extraits de manière correspondante.

 Les fichiers PDF contiendront des informations de formatage plus riches. Langchain fournit de nombreux chargeurs, mais l'effet de segmentation de PDFMinerPDFasHTMLLoader dans Langchain sera meilleur.Il convertit le PDF en HTML, et via HTML

Segmentation de blocs, cette méthode peut conserver les informations sur la taille de police de chaque bloc, de sorte que la relation d'affiliation de chaque contenu de bloc puisse être déduite, et le titre d'un paragraphe peut être associé au titre parent du niveau précédent pour rendre les informations plus complet.

 B. Prise en charge du modèle pour la longueur des fragments

 Étant donné que les fragments divisés doivent être raisonnés à travers le modèle vectorisé, la limite Max_seq_length du modèle vectorisé doit être prise en compte. Le dépassement de cette limite peut entraîner une troncature et une sémantique incomplète. Séparés du Max_seq_length pris en charge, il existe actuellement deux types de modèles d'intégration, comme indiqué dans le tableau suivant (ces quatre sont des modèles avec une expérience pratique).

 nom du modèle

 Max_seq_length

 paraphrase-multilingue-mpnet-base-v2(sbert.net)

 128

 text2vec-base-chinois(text2vec)

 128

 text2vec-large-chinois(text2vec)

 512

 text-embedding-ada-002 (openai)

 8192

 Le Max_seq_length fait ici référence au nombre de jetons, qui n'est pas équivalent au nombre de caractères. Selon l'expérience de tests précédents, un jeton des trois premiers modèles comporte environ 1,5 caractères chinois. Pour les grands modèles de langage, tels que chatglm, un jeton comporte généralement environ 2 caractères. S'il n'est pas pratique de calculer le nombre de jetons lors de la segmentation, vous pouvez simplement convertir selon ce rapport pour vous assurer qu'il n'y aura pas de troncature.

 Les trois premiers modèles appartiennent au modèle d'intégration basé sur Bert, et le modèle text-embedding-ada-002 d'OpenAI est un modèle basé sur GPT3. Le premier est adapté à la vectorisation de phrases ou de paragraphes courts, tandis que le second l'interface SAAS d'OpenAI est adaptée à la vectorisation de textes longs, mais ne peut pas être déployée en privé.

 La sélection de validation peut être effectuée sur la base des effets de rappel. D'après l'expérience pratique actuelle, text-embedding-ada-002 peut classer les scores de similarité chinois, mais le degré de discrimination n'est pas suffisant (la concentration est d'environ 0,7), ce qui ne permet pas de juger directement s'il existe un rappel de connaissances similaire à travers le seuil. .

 De plus, il existe un autre moyen d'améliorer le problème de la limitation de longueur. Vous pouvez numéroter les fragments divisés et les nombres de fragments adjacents sont également proches. Lors du rappel d'un des fragments, vous pouvez utiliser la recherche par plage de la base de données vectorielles pour rechercher les fragments à proximité. Le rappel peut également garantir l'intégrité sémantique du contenu rappelé.

 Sélection de modèles vectorisés

 Les quatre modèles mentionnés ci-dessus mentionnent uniquement la différence de prise en charge du modèle pour la longueur du texte, et il n'existe actuellement aucune conclusion faisant autorité sur cet effet. Vous pouvez utiliser le classement pour comprendre les performances de chaque modèle. L'évaluation de la plupart des modèles de la liste est toujours basée sur le benchmark de l'ensemble de données publiques. La question de savoir si la conclusion du benchmark est vraie dans la scène de production réelle doit être examinée au cas par cas. cas. Mais en principe, les aspects d’expérience suivants peuvent être partagés :

  • Le modèle Finetune dans le domaine vertical présente des avantages évidents par rapport au modèle vectoriel original.

  • Les modèles vectorisés actuels se répartissent en deux catégories, symétriques et asymétriques. En l’absence de mise au point, il est recommandé d’utiliser le rappel symétrique pour la FAQ, c’est-à-dire le rappel de Requête à Question. Pour la connaissance des fragments de documents, il est recommandé d'utiliser un modèle de rappel asymétrique, qui est le rappel de la requête à la réponse (fragment de document).

  • S'il n'y a pas de différence d'effet évidente, essayez de choisir un modèle avec une dimension vectorielle courte. Les vecteurs de grande dimension (tels que text-embedding-ada-002 d'openai) exerceront une pression sur la base de données vectorielle en termes de performances de récupération et de coût. .

 parallélisme vectorisé

 Dans des scénarios commerciaux réels, la taille des documents est de l'ordre de cent à un million. Selon la méthode de rappel redondant à plusieurs niveaux, les éléments de connaissances correspondants peuvent atteindre une échelle allant jusqu'à 100 millions. En raison de la grande échelle de l'ensemble du calcul hors ligne, il doit être effectué simultanément, sinon il ne peut pas répondre aux exigences d'ajout de connaissances et d'itération de l'effet de récupération de vecteurs. Les étapes sont principalement divisées en trois étapes de calcul suivantes.

 Segmentation parallèle des documents

 La granularité du calcul de concurrence se situe au niveau du fichier, et les formats de fichiers traités sont également divers, tels que le texte brut TXT, Markdown, PDF, etc., et la logique de segmentation correspondante est également différente. Il n'est pas approprié d'utiliser un framework Big Data tel que Spark pour le traitement parallèle. L'utilisation d'instances multicœurs pour le traitement simultané multi-processus est trop primitive et il n'est pas pratique d'observer et de suivre les tâches. Vous pouvez donc choisir le moteur shell Python d'AWS Glue pour le traitement. Les principaux avantages sont les suivants :

  • Il est pratique d'effectuer la concurrence en fonction de la granularité du fichier, et le degré de concurrence est simple et contrôlable. Avec des mécanismes tels que les nouvelles tentatives et les délais d'attente, il est pratique de suivre et d'observer les tâches, et les journaux sont directement connectés à AWS CloudWatch.

  • Il est pratique de créer et d'exécuter le package de dépendances, qui peut être spécifié par le paramètre –additional-python-modules. Dans le même temps, l'environnement d'exploitation Glue Python est déjà livré avec opensearch_py et d'autres dépendances.

 Parallélisme d'inférence vectorisée

 Étant donné que les paragraphes et les phrases segmentés s'étendent plusieurs fois par rapport au nombre de documents, le débit de raisonnement du modèle vectoriel détermine le débit de l'ensemble du processus. Ici, SageMaker Endpoint est utilisé pour déployer le modèle vectorisé. De manière générale, afin de fournir la capacité de débit du modèle, le raisonnement de l'instance GPU, l'évolutivité élastique multi-nœuds Endpoint/Endpoint et les capacités de raisonnement par lots côté serveur/côté client sont certaines de ces mesures efficaces. Spécifiques à la scène de construction de bases de connaissances vectorielles hors ligne, les stratégies suivantes peuvent être adoptées :

  • Déploiement d'instances GPU : des instances de CPU modèles vectorisées peuvent être déduites. Cependant, dans le scénario hors ligne, la concurrence de raisonnement est élevée et le débit du GPU peut être augmenté d'environ 20 fois par rapport à celui du CPU. Par conséquent, l’inférence GPU peut être utilisée dans des scénarios hors ligne et les stratégies d’inférence CPU peuvent être utilisées dans des scénarios en ligne.

  • Pour la génération temporaire de grands vecteurs simultanés d'un point de terminaison multi-nœuds, elle est traitée en déployant un point de terminaison multi-nœuds et peut être fermée après le traitement.

 Utilisation du raisonnement par lots côté client : pour le raisonnement hors ligne, la construction par lots côté client est très simple. Il n'est pas nécessaire d'activer le raisonnement par lots côté serveur. De manière générale, les lots côté serveur ont un temps d'attente, tel que 50 ms ou 100 ms, ce qui est plus efficace pour les grands modèles de langage avec des délais de raisonnement élevés, mais ne convient pas au raisonnement vectoriel.

 Injection par lots OpenSearch

 L'opération d'écriture d'Amazon OpenSearch peut être mise en œuvre par lots et en masse, ce qui présente de grands avantages par rapport à l'écriture unique.

 Optimisation de la base de données vectorielles

 L'algorithme de recherche approximatif à choisir pour la base de données vectorielles, la sélection d'une taille de cluster appropriée et l'optimisation des paramètres de cluster sont également essentiels aux performances de lecture et d'écriture de la base de connaissances. Les aspects suivants doivent être pris en compte :

 Sélection d'algorithme

 Dans OpenSearch, deux algorithmes k-NN sont fournis : HNSW (Hierarchical Navigable Small World) et IVF (Inverted File).

 Plusieurs facteurs doivent être pris en compte lors du choix d'un algorithme de recherche k-NN. Si la mémoire n’est pas un facteur limitant, il est recommandé de privilégier l’utilisation de l’algorithme HNSW, car l’algorithme HNSW peut garantir à la fois la latence et le rappel. Si l'utilisation de la mémoire doit être contrôlée, envisagez d'utiliser l'algorithme de FIV, qui réduit l'utilisation de la mémoire tout en conservant une vitesse et une qualité de requête de type HNSW. Toutefois, si la mémoire constitue le facteur limitant le plus important, envisagez d’ajouter le codage PQ aux algorithmes HNSW ou IVF pour réduire davantage l’utilisation de la mémoire. Il convient de noter que l’ajout du codage PQ peut réduire le taux de précision. Par conséquent, lors de la sélection des algorithmes et des méthodes d’optimisation, plusieurs facteurs doivent être pris en compte de manière globale pour répondre aux exigences spécifiques des applications.

 Estimation de la taille des grappes

 Une fois l'algorithme sélectionné, la mémoire requise peut être calculée selon la formule pour dériver la taille du cluster k-NN

 Optimisation de l'injection par lots

 Lors de l'injection d'une grande quantité de données dans la bibliothèque de vecteurs de connaissances, il convient de prêter attention à certaines optimisations clés des performances. Voici quelques principales stratégies d'optimisation :

  • Désactiver l'intervalle de rafraîchissement

  • Augmenter le fil d'indexation

  • Augmenter le taux de mémoire knn

Je suppose que tu aimes

Origine blog.csdn.net/caijingshiye/article/details/132479005
conseillé
Classement