metadata

title: Gossip Retriver
sdk: gradio
app_file: gossip_semantic_search/front/app.py

Gossip Answering

Quick Start

Cette application utilise Gradio pour créer une interface permettant de poser des questions sur des articles provenant de VSD et Public en utilisant des techniques de Retrieval-Augmented Generation (RAG).

Ce projet utilise deux services API, et il vous sera nécessaire de générer des clés pour accéder à ces API. :

Cohere pour générer des embeddings.
Groq pour générer du contenu.

colab

Vous pouvez accéder au notebook disponible sur Google Colab ici.

Dans la première cellule, vous devrez entrer votre GitHub token pour cloner le repo ainsi que les clés des deux API utilisées par ce projet.

Une fois cela fait, exécutez toutes les cellules du notebook, puis rendez-vous sur le lien généré .gradio.live à la fin de la dernière cellule pour accéder à l'application.

Local

Prérequis

Python 3.12.3 (La version utilisée pour ce projet)

Installation

Clonez le dépôt :

Clonez le projet sur votre machine locale en utilisant la commande suivante :
```
git clone https://github.com/PierreBdesG/gossip-semantic-search.git
```
Récupérez les clés API :

Définissez vos API keys comme variables d'environnement :
```
export COHERE_API_KEY=your_cohere_api_key
export GROQ_API_KEY=your_groq_api_key 
```
Installez les dépendances :

Installez les bibliothèques nécessaires à l'aide du fichier requirements.txt :
```
pip install -r requirements.txt
```

Téléchargez le dataset :

Téléchargez le dataset (mis à jour le 19 octobre 2024) :

!curl -L -o dataset.pkl "https://drive.google.com/uc?export=download&id=1g4-pNY3CTRIW5_hinWBREMkTrsZ05GNd"

Lancez l'application :

Exécutez l'application avec la commande suivante, en fournissant le chemin vers le dataset téléchargé :
```
python gossip_semantic_search/front --dataset_path dataset.pkl
```

Création du Dataset

Le dataset utilisé dans ce projet est une List[Article], où chaque élément est un objet Article contenant les informations suivantes :

class Article:
    author: str
    title: str
    link: str
    description: str
    published_date: datetime
    content: str
    embeded_content: NDArray
    questions: list[str]

Les attributs author, title, link, description, published_date et content sont extraits des flux RSS des sites VSD et Public.
Le champ embeded_content correspond aux embeddings générés pour chaque article. Une description détaillée de l'embedding utilisé est disponible ici.
Le champ questions contient une liste de n questions associées à l'article. Ces questions ont été générées à l'aide de Llama-3-70B, via l'API fournie par Groq.

Évaluation

Pour ce dataset, nous avons choisi de générer 3 questions par article. Avec un total de 60 articles, cela constitue un dataset d'environ 180 questions.

Une fois ce dataset créé, nous pouvons évaluer notre modèle de retrieval de la manière suivante :

Effectuer un produit scalaire (similaire a un cosine similarity vue que les normes des embedding=1) entre tous les embeddings des questions et tous les embeddings des contextes.
Pour chaque question, récupérer les k meilleurs contextes correspondant.

ce qui nous donne les resultats suivant:

/!\ regénerer le graph en décalant les absisse de 1

Résultats du Graph

Sur ce graphique, on observe les résultats suivants pour la récupération des contextes :

Si l'on se base uniquement sur le dot product le plus élevé pour chaque question, dans 91.5% des cas, le contexte d'origine est retrouvé.
En élargissant la sélection aux 2 meilleurs contextes, dans environ 99% des cas, le contexte d'origine se trouve parmi les deux contextes sélectionnés.
En prenant les 3 meilleurs contextes, on atteint une précision de 99.5%, où le contexte d'origine se retrouve dans les trois contextes sélectionnés.

Limitation

Ce dataset est un dataset synthétique. Les questions ont été générées par le modèle Llama-3-70B, en prenant en compte un certain article spécifique pour chaque question. Les questions sont donc conçues pour correspondre directement au contenu des articles, créant ainsi un ensemble de données biaisé par apport au réel avec des questions bien alignées avec les informations présentes dans le texte. Lors de l'inférence, les questions posées par les utilisateurs ne seront pas toujours aussi structurées ou spécifiques que celles générées pour ce dataset. Les questions réelles, posées par des utilisateurs humains, seront souvent plus organiques, plus variées, et moins directement liées à un contexte particulier En conséquence, les performances du modèle seront donc moins élevées lorsqu'il sera confronté à des questions plus naturelles

Inférence et génération de réponses

1.Une question est entrée par un utilisateur.

La question est convertie en embedding.
On effectue un dot product entre l'embedding de la question et tous les articles embeddés, qui ont été chargés en RAM lors du lancement de l'application.
On récupère les 3 articles les plus pertinents.
On prend le premier article et on demande à Llama-3-70B si la réponse à la question se trouve dans le contexte de cet article.
- Si oui, on demande à Llama-3-70B de générer la réponse, puis on renvoie la réponse, le lien de l'article et le contexte correspondant.
- Si non, on passe au deuxième article et répète la même procédure.
- Si la réponse n'est trouvée dans aucun des 3 articles, on renvoie le message "incapable de générer une réponse" ainsi que le premier contexte.

Exploration

Si j'avais eu plus de temps, j'aurais :

Généré un jeu de données plus complexe.
Implémenté des KNN plutôt que d'utiliser le produit scalaire pour le retriever.
Mieux exploré et analysé les questions mal classifiées.
Mis en place un reformulateur de questions (multi-query, hyde).
Exploré davantage Cohere et d'autres embedders.
Mis en place ColBERT sur les K meilleurs contextes.

reste a faire: regler le pb de pickle

replot le graph

test

linter