J'ai reçu d'excellents retours d'un membre de la communauté sur ma soumission au concours Python 2024. J'espère que ça va si je le reposte ici :
vous construisez un conteneur plus de 5 fois la taille d'un IRIS pur
et cela prend du temps
le démarrage du conteneur est également lent mais se termine
le backend est accessible comme décrit
une production traîne
le frontend réagit
Je ne comprends pas ce qui est destiné à montrer
l'explication est destinée aux experts autres que moi
La soumission est ici : https://openexchange.intersystems.com/package/IRIS-RAG-App
J'apprécie vraiment ce retour, notamment parce que c'est une excellente incitation pour un article sur le projet. Ce projet comprend une documentation assez complète, mais il suppose une familiarité avec les intégrations vectorielles, les pipelines RAG et la génération de texte LLM, ainsi qu'avec Python et certaines bibliothèques Python populaires, comme LLamaIndex.
Cet article, écrit complètement sans IA, est censé être une tentative d'explication de ces choses et de la manière dont elles s'articulent dans ce projet pour démontrer le RAG flux de travail sur IRIS.
Le conteneur est volumineux car les dépendances de bibliothèque nécessaires aux packages Python impliqués dans la création d'intégrations vectorielles sont très volumineuses. Il est possible que grâce à des importations plus sélectives, la taille puisse être considérablement réduite.
Il faut du temps pour construire initialement le conteneur, mais une fois que vous l'avez fait, il faut moins de temps pour le démarrer. Le temps de démarrage pourrait encore certainement être amélioré. La principale raison pour laquelle le démarrage prend autant de temps est que le fichier Entrypoint.sh a été mis à jour en supposant que des modifications auraient pu être apportées à n'importe quelle partie de l'application depuis le dernier démarrage, y compris les migrations de bases de données, les configurations CSS, les configurations Javascript et Python. code backend, et il recompile l’intégralité du projet à chaque démarrage. Cela permet de faciliter le démarrage du développement sur ce projet, car sinon, il peut être difficile d'exécuter correctement les versions frontend et backend chaque fois que des modifications sont apportées. De cette façon, si vous modifiez le code du projet, il vous suffit de redémarrer le conteneur, peut-être de récupérer la production dans le backend, et vos modifications devraient être reflétées dans l'interface et le fonctionnement de l'application.
Je suis presque sûr que la production dans le backend est ce qui transmet les requêtes http à l'application Django et est cruciale pour l'interopérabilité de ce package. Cependant, je suis nouveau sur la plateforme IRIS et j'ai encore plus à apprendre sur les productions.
Ensuite, j'aimerais fournir une explication complète des intégrations vectorielles, des LLM et des RAG. Le premier d’entre eux à être inventé a été l’intégration vectorielle. Nous pouvons d’abord décrire un vecteur. Dans la plupart des contextes, un vecteur est une direction. C’est une flèche pointant quelque part dans l’espace. Plus formellement, un vecteur est « une quantité ayant une direction ainsi qu'une ampleur ». Cela pourrait être illustré par un feu d’artifice qui se propage dans une direction particulière et explose à un point particulier de l’espace. Disons que chaque feu d'artifice est tiré à partir du même point central, un point d'origine, [0,0,0], mais qu'ils s'envolent tous et explosent dans un nuage autour de ce point d'origine. Mathématiquement, vous pourriez décrire l'emplacement de chaque explosion de feu d'artifice en utilisant un système à trois coordonnées, [x, y, z] et ce serait une « intégration vectorielle » pour une explosion de feu d'artifice. Si vous preniez beaucoup de vidéos d'un feu d'artifice et enregistriez toutes les explosions de feux d'artifice sous forme d'ensemble de données, vous créeriez alors une sorte de base de données d'intégration de vecteurs, ou magasin de vecteurs, du feu d'artifice.
Que pourriez-vous faire avec cette information sur le feu d'artifice ? Si je signalais un feu d'artifice particulier et demandais le feu d'artifice qui a explosé le plus près du même point tout au long de l'ensemble de l'exposition, vous pourriez trouver ces autres feux d'artifice qui ont explosé à des points proches de l'espace. Il vous suffit de trouver ceux qui sont les plus proches, et il y a des mathématiques pour faire cela.
N'oubliez pas que nous n'avons enregistré que trois nombres pour chaque feu d'artifice, les coordonnées x, y et z dans un espace tridimensionnel avec [0,0,0] étant le lanceur de feux d'artifice au sol.
Et si je voulais également connaître le feu d'artifice qui a explosé à la fois le plus près en distance et le plus proche dans le temps d'un autre feu d'artifice particulier ? Pour le savoir, il faudrait revoir nos séquences vidéo du feu d’artifice et enregistrer également l’heure de chaque explosion. Nous avons maintenant un vecteur tridimensionnel avec 4 nombres : la position tridimensionnelle de l'explosion du feu d'artifice et l'heure de l'explosion. Nous disposons désormais d'un type d'intégration plus descriptif pour le feu d'artifice en ajoutant une autre dimension à nos intégrations vectorielles.
Comment cela se traduit-il en apprentissage automatique ? Pour faire court, en traitant une énorme quantité de données textuelles, les informaticiens ont réussi à créer des modèles d'intégration capables de transformer un morceau de texte comme une phrase, un paragraphe ou même une page, et de le transformer en une très longue série. de nombres qui représentent un point dans un espace théorique de grande dimension.
Au lieu de 4 chiffres, il y en a 300, ou 700, voire 1500. Ceux-ci représentent 1500 façons dont un morceau de texte peut être « proche » ou « loin » d’un autre, soit 1500 dimensions de sens. C'est un concept captivant pour beaucoup que nous ayons les moyens de créer des nombres qui représentent en quelque sorte la signification sémantique d'un morceau de texte.
Grâce aux mathématiques, deux de ces intégrations vectorielles de texte de grande dimension peuvent être comparées pour découvrir à quel point elles sont similaires ou « proches » l'une de l'autre si elles l'étaient. créé par le même modèle.
C'est la première chose qui se passe dans cette application. L'utilisateur doit insérer un document et le nommer, puis choisir un type d'intégration. Le serveur prend ce document, le divise en morceaux de texte, puis transforme chacun de ces morceaux en une intégration vectorielle, et ce morceau est enregistré sous forme de ligne dans un tableau dédié à ce document. Chaque document est stocké dans sa propre table dédiée pour permettre la longueur variable des incorporations vectorielles créées par différents modèles d'incorporation de texte.
Une fois qu'un document est stocké dans la base de données sous forme d'intégrations vectorielles, l'utilisateur peut saisir une requête pour « demander » le document. La requête est utilisée de deux manières. La première façon consiste à rechercher le document. Nous ne faisons pas de recherche textuelle traditionnelle, mais plutôt une « recherche vectorielle ». L'application prend la requête, la transforme en intégration vectorielle, puis recherche les sections du document avec les intégrations les plus similaires à l'intégration vectorielle de requête. Un score de similarité entre 0 et 1 est ensuite généré pour chaque section du document, et plusieurs sections sont récupérées de la base de données vectorielles en fonction du top_k_similarity et du similarity_threshold. Fondamentalement, vous pouvez lui demander combien de sections de document récupérer et dans quelle mesure elles doivent être similaires à votre requête pour pouvoir être récupérées.
C'est la génération augmentée de récupération dans la récupération. La prochaine étape est la génération.
Une fois que les informaticiens ont compris comment convertir du texte en intégrations vectorielles numériques sémantiquement significatives, l'étape suivante consistait à créer des modèles capables de produire du texte. Ils l'ont fait avec beaucoup de succès, et nous disposons désormais de grands modèles de langage comme GPT-4, LLama3 et Claude 3.5. Ces LLM peuvent prendre une invite, ou une requête, et fournir une complétion, ou une réponse, qui est le texte qu'ils pensent le plus susceptible de continuer à partir du texte présenté, l'invite.
Les LLM doivent être formés sur de grandes quantités de données textuelles, et leurs réponses, ou achèvements, sont limitées à ces données de formation. Lorsque nous souhaitons que les LLM fournissent des achèvements qui peuvent inclure des données ne figurant pas dans leurs ensembles de formation, ou fondent leurs achèvements sur un ensemble particulier de connaissances, une façon d'y parvenir est d'inclure des données contextuelles supplémentaires dans l'invite. Fondamentalement, si nous voulons une réponse d'un LLM sur quelque chose sur lequel il n'a pas été formé, nous devons lui donner les informations dans l'invite.
De nombreuses personnes se sont retrouvées dans une situation dans laquelle elles souhaitaient que chatGPT ou leur installation LLama locale puisse fournir des réponses basées sur leurs propres documents personnels. Il est assez simple de rechercher ces informations dans vos documents, de les coller dans l'invite et de poser votre question, et les gens se sont retrouvés à le faire manuellement. Il s’agit de sa propre forme de génération augmentée de récupération. RAG consiste simplement à automatiser la recherche d'informations pertinentes pour la requête de l'utilisateur et à lui fournir la requête au LLM pour une réponse plus précise ou plus utile.
Dans cette application, les sections du document que nous récupérons avec la recherche vectorielle sont envoyées avec la requête au LLM choisi, étiqueté dans l'interface comme Modèle, à fournissez le contexte de la réponse.
Dans l'exemple vidéo que j'ai réalisé pour ce projet, je pose la question « Qui est le méchant dans cette pièce ? » avec les documents « Hamlet » et « King Lear », qui contiennent l'intégralité du texte des deux pièces de Shakespeare. La base de données IRIS contient déjà deux tables, une pour Hamlet et l'autre pour le roi Lear. Chaque tableau est rempli de rangées d'intégrations vectorielles créées en divisant le texte de chaque pièce en sections. Ces intégrations sont de longues séries de nombres représentant les nombreuses dimensions du sens dans chacune des sections du document.
Le serveur convertit la question « Qui est le méchant dans cette pièce » en un vecteur numérique en utilisant le même modèle texte-vecteur qui a généré les intégrations vectorielles pour le Roi Lear et trouve les sections du tableau du Roi Lear qui lui ressemblent le plus. Ce sont probablement des sections qui mentionnent le mot méchant, oui, mais peut-être d'autres choses crapuleuses, telles que la trahison, la trahison et la tromperie, même si la méchanceté n'est pas explicitement mentionnée. Ces sections de document sont ajoutées à la requête et envoyées ensemble sous forme d'invite à un LLM qui répond ensuite à la question en fonction des sections de document fournies.
Cela se fait séparément pour chaque document, et c'est pourquoi la réponse à la requête est différente selon le document interrogé. Ceci complète l'acronyme, puisque nous augmentons la génération de notre réponse à partir du LLM avec la récupération d'informations contextuelles pertinentes en utilisant la puissance de la recherche vectorielle.
Un grand merci à tous ceux qui prendront le temps de lire ceci et je serais heureux de développer l'un de ces sujets dans un prochain article. Les commentaires sont toujours les bienvenus.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!