diff --git a/I-Accompagnement/1_Besoins.qmd b/I-Accompagnement/1_Besoins.qmd index 353316f..3458289 100644 --- a/I-Accompagnement/1_Besoins.qmd +++ b/I-Accompagnement/1_Besoins.qmd @@ -13,4 +13,20 @@ L'objectif de ce chapitre est d'accompagner la réflexion autour de l'identifica * cas d'usages autour de la génération de contenu * cas d'usage autour de la classification et de la recherche de contenu - * cas d'usage autour des interactions conversationnelles \ No newline at end of file + * cas d'usage autour des interactions conversationnelles + + +### Description cas d'usage + + 1. SLM recherche thématique simple en français + 2. Classifier des accords d'entreprise + + +#### Classifier des accords d'entreprise + + Les accords d'entreprise sont publiés sur [LégiFrance](https://www.legifrance.gouv.fr/liste/acco). + Ces accords peuvent concerner plusieurs thématiques (télétravail, compte épargne temps, droit à la deconnexion). + Ces thématiques sont déclarés par les entreprises et sont éventuellement corrigées par la Direction Générale du Travail. + Le besoin est alors de détecter automatiquement les thématiques + à la lecture de l'accord. + Un jeu de données est disponible à l'adresse suivante : [accords_publics_xx_to_2022_themes_et_texte.parquet](https://minio.lab.sspcloud.fr/cthiounn2/Accords/accords_publics_xx_to_2022_themes_et_texte.parquet) diff --git a/II-Developpements/2_RAG.qmd b/II-Developpements/2_RAG.qmd index e2bd600..3af8de3 100644 --- a/II-Developpements/2_RAG.qmd +++ b/II-Developpements/2_RAG.qmd @@ -1,9 +1,477 @@ -# Guide du LLM +# PARTIE II. Développements autour des LLMs (pour les data scientists) -## PARTIE II. Développements autour des LLMs (pour les data scientists) +# 2. RAG (Hugo Malo Jérôme Daphné Katia) -### 2. RAG (Hugo Malo Jérôme Daphné) +## a. pipelines + +## b. Benchmark des différentes bases vectorielles (Katia) + +### Comparatif détaillé des solutions de stockages de données pour la recherche vectorielle approximative + +Toutes les solutions testées sont open-source ou disposant d'une licence permissive, qui donne la possibilité d'héberger localement les données. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +WeaviateMilvusQdrantElasticSearchFAISS
+ +**Open source** + + +:white_check_mark: + + +:white_check_mark: + + +:white_check_mark: +Partiellement + +:white_check_mark: +
+ +**Dev-friendly** + + +\+++ + + +\+ + + +\+++ + + +\++ + + +\+++ +
+ +**Déploiement** + + +:white_check_mark: + + +:white_check_mark: mais difficile à mettre en place, constellation de micro-services + + +:white_check_mark: + + +:white_check_mark: + + +:x: mais possibilité de construire une image Docker custom par exemple +
+ +**Spécifique à la recherche vectorielle** + + +:white_check_mark: + + +:white_check_mark: + + +:white_check_mark: + + +:x: + + +:white_check_mark: +
+ +**Qualité de la documentation** + + +\+++ [\[-\]](https://weaviate.io/developers/weaviate) + + +\++ [\[-\]](https://milvus.io/docs) + + +\+++ [\[-\]](https://qdrant.tech/documentation/) + + +\++ [\[-\]](https://www.elastic.co/guide/index.html) + + +\+ [\[-\]](https://faiss.ai/index.html) +
+ +**Dernière mise à jour** +mai 2024mai 2024mai 2024mai 2024mars 2024
+ +**Latence (ms)\*\*** +438.18322.63 + +**118.25** +338.53 + +\- +
+ +**Requêtes/seconde** + +**(RPS)\*\*** +217.98281.52 + +**710.23** +275.11 + +\- +
+ +**P99 latence (ms)\*\*** +1723.62436.87 + +**144.78** +589.61 + +\- +
+ +**Temps d'upload (minutes)\*\*** +71.61 + +**1.41** +2.07414.33 + +\- +
+ +**Temps d'upload +** + +**indexation (minutes)\*\*** +71.61 + +**9.53** +17.49 + +122.79 + +:x: + + +\- +
+ +**Place en mémoire** + + +`num_vectors * vector_dimension * 4 bytes * 2` [\[-\]](https://weaviate.io/developers/weaviate/concepts/resources#an-example-calculation) + + +Conséquente d'après les avis d'utilisateurs, pas de formules approximative [\[-\]](https://milvus.io/tools/sizing/) + + +`num_vectors * vector_dimension * 4 bytes * 1.5` [\[-\]](https://qdrant.tech/documentation/cloud/capacity-sizing/) + + +`num_vectors * 4 * (vector_dimension + 12)` [\[-\]](https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-knn-search.html) +?
+ +**Type d'index** +HNSWFLAT, IVF_FLAT, IVF_SQ8, IVF_PQ, HNSW, BIN_FLAT, BIN_IVF_FLAT, DiskANN, GPU_IVF_FLAT, GPU_IVF_PQ, and CAGRAHNSWHNSWFLAT, IVS_FLAT, IVF_SQ8, IVF_PQ, HNSW, BIN_FLAT and BIN_IVF_FLAT
+ +**Recherche hybride** + + +:white_check_mark: + + +:white_check_mark: + + +:white_check_mark: + + +:white_check_mark: + + +:x: +
+ +**Ajout d'éléments à la volée, scalabilité** +Partitionnement statique + +Segmentation + +dynamique +Partitionnement statiquePartitionnement statique + +:x: (index + +immutable -\> vector library) +
+ +**Accès contrôlé par rôles** + + +:x: sur le backlog, mais n'avance beaucoup [\[-\]](https://github.com/weaviate/weaviate/issues/2784) + + +:white_check_mark: [\[-\]](https://milvus.io/docs/users_and_roles.md) + + +:white_check_mark: [\[-\]](https://qdrant.tech/documentation/guides/security/) + + +:white_check_mark: [\[-\]](https://www.elastic.co/guide/en/app-search/current/security-and-users.html) + + +:x: +
+ +**Partions et étanchéité des bases de données** + +**(_multi-tenancy_)** + + +:x: pas très clair, mais il semble que ce ne soit pas encore possible [\[-\]](https://forum.weaviate.io/t/understanding-on-multi-tenancy/2067/2) + + +:white_check_mark: Plusieurs systèmes de partitions, très flexible [\[-\]](https://milvus.io/docs/multi_tenancy.md) + + +:white_check_mark: Plusieurs systèmes de partitions, assez flexible [\[-\]](https://qdrant.tech/documentation/guides/multiple-partitions/) + + +:white_check_mark: Possible mais pas très intuitif [\[-\]](https://www.elastic.co/guide/en/elasticsearch/reference/current/document-level-security.html) + + +:x: +
+ +**Autres avantages** + + + + +* Très dynamique car chaque action a son propre node, facile à scaler +* Plusieurs niveaux de partitions + + + + +* Stockage d'autres types de données, par exemple l'historique de conversations +* Très commun comme solution de stockage, donc plus d'utilisateurs déjà familiers de l'outil + + +
+ +**Autres inconvénients** + + + + +* Taille en mémoire (difficile à quantifier par rapport aux autres, mais plus importante selon les benchmarks) + + +* Pas de stockage S3 + + + + +* Bibliothèque de vecteurs, pas vraiment adaptée à un usage persistant +
+ +\*\* [Qdrant benchmark](https://qdrant.tech/benchmarks/) (janvier 2024), dataset = gist-960-euclidean (1M de vecteurs en dimension 960), précision à 0.95 + + +Les solutions présentées recouvrent en fait plusieurs cas d'usage : + +* Les **bibliothèques vectorielles** (_vector library_) de type FAISS sont adaptées à de la rechercher sémantique à la volée, avec constitution de la base et recherche immédiate. Ici il s'agira d'un cas d'usage où l'utilisateur apporte son propre document avec un téléchargement en temps réel, et pose des questions dessus ou demande une synthèse. +* Les **bases de données vectorielles** (_vector database_) sont des dispositifs plus lourds et généralement un peu plus lents, mais avec un stockage permanent et beaucoup plus de flexibilité dans la recherche. Ils sont plus adaptés à un cas d'usage où la base de connaissance est constituée en amont et doit être mise à jour de temps en temps. + +Pour une mise en production rapide et efficace **Qdrant** semble être la meilleure solution, combiné à une base de données plus traditionnelle comme ElasticSearch pour l'historique des conversations. Pour avoir une approche tout-en-en, et plus de flexibilité dans la gestion des collections, c'est **ElasticSearch** qui se détache des autres, malgré des temps d'indexation assez conséquents. + +> Aparté sur les intégrations Langchain : à manipuler avec précaution, les fonctions ne sont pas toujours explicites (par exemple la méthode `from_documents` supprime et recrée en général une collection). De plus certaines fonctionnalités comme l'utilisation de partitions ne sont pas toujours accessibles via Langchain. Il peut être utile de recréer des wrapper qui utilisent en partie Langchain et en partie les fonctions natives de la base de données. + +#### Annexes + +##### Définitions + +**Dev-friendly** -\> Note qualitative après installation de chaque solution (sauf FAISS) dans une image Docker, et utilisation avec Python (avec et sans l'intégration Langchain) + +**Déploiement** -\> Existence d'un écosystème de déploiement + +**Qualité de la documentation** -\> Note qualitative après installation de chaque solution (sauf FAISS) dans une image Docker, et utilisation avec Python (avec et sans l'intégration Langchain) + +**Ajout d'éléments à la volée, scalabilité** -\> Comment l'indexation se fait si la base de données est modifiée. Avec le partitionnement statique (_static sharding_), si la capacité du serveur est augmentée toutes les données doivent être de nouveau partitionnées, ce qui peut être long. + +**Recherche hybride** -\> Possibilité d'effectuer des recherches dans les métadonnées, avec des nombres ou des chaînes de caractères + +**Accès contrôlé par rôles (_RBAC_)**-\> Autorisations prédéfinies pour chaque utilisateur, avec un accès différencié aux documents + +##### Ressources + +https://weaviate.io/blog/vector-library-vs-vector-database + +[ANN Benchmark](https://ann-benchmarks.com/index.html) (avril 2023) - a. pipelines, - b. presentations de modules avec RETEX, CODE!) +### c. presentations de modules avec RETEX, CODE!) \ No newline at end of file diff --git a/III-Deploiements/4_Infras_administrations.qmd b/III-Deploiements/4_Infras_administrations.qmd index af16e58..074eb6d 100644 --- a/III-Deploiements/4_Infras_administrations.qmd +++ b/III-Deploiements/4_Infras_administrations.qmd @@ -24,7 +24,7 @@ Bien que l'état dispose de plusieurs offres cloud internes, la mise à disposit A ce jour, le SSP Cloud via sa plateforme ONYXIA, est la principale plateforme publique mettant à disposition des GPUs à ces utilisateurs. Les ressources sont cependant très limitées et la plateforme est plus orientée autour du développement de projet que de la mise en production. -# TODO Enrichir ce paragraphe avec des RETEX sur l'utilisation de container avec GPU +cf ![Déploiement d'un LLM sur SSP Cloud](#Déploiement d'un LLM sur SSP Cloud) 2. Cloud PI @@ -57,4 +57,31 @@ La qualificiation [SecNumCloud](https://cyber.gouv.fr/secnumcloud-pour-les-fourn - [Hugging face - inference endpoint](https://huggingface.co/inference-endpoints/dedicated) - [Groq](https://wow.groq.com/why-groq/) -Permet de simplifier +### 5. Déploiement d'un LLM sur SSP Cloud + +Sur le DataLab SSP Cloud, il est possible de déployer des LLM à des fins d'expérimentation. Plusieurs cas sont possibles : + +A. Utiliser des librairies d'API de LLM (vLLM, etc.) +B. Déployer des containers Docker avec Kube et Helm + +#### A. Déploiement par API + +* Vous pouvez lancer un service VSCode avec une GPU et installer une API de LLM + +#### B. Déploiement par image Docker + +* Créer une image Docker et la mettre à disposition (Dockerhub) : exemple applicatif avec Streamlit +* Déployer avec Kube et Helm en utilisant un service VSCode avec les droits d'admin pour Kube + + +Exemple avec Kube : + +```bash +kubectl create deployment mon-deploiement --image=mon-image-docker +``` + + +```bash +kubectl proxy +``` + diff --git a/_quarto.yaml b/_quarto.yaml index 0b9eb47..dd8d7bc 100644 --- a/_quarto.yaml +++ b/_quarto.yaml @@ -51,4 +51,6 @@ format: dark: darkly code-copy: true code-overflow: wrap - toc: true \ No newline at end of file + toc: true + +from: markdown+emoji \ No newline at end of file