L’architecture des traitements distingue deux étapes : l’ingestion et la génération.

Récupération (RAG) et Indexation (ingestion) : ingérer des documents de manière efficace puis utiliser un modèle d’intégrations (Embeddings Model) pour encoder et produire un index vectoriel.

Dans notre approche d’ingestion "à froid", un script particulier ingestcmd.py ou une application Web RAG Manager assurent la récupération et l’indexation.
L’alternative serait d’ingérer et d’indexer à chaque requête, directement dans l’application de génération. Cela est praticable pour de petits documents qu’on ne souhaite pas traiter fréquemment. L’ingestion à froid, en revanche, permet de traiter un grand nombre de documents (typiquement le contenu d’un ou plusieurs sites Web et de centaines de documents).

Etapes de l’ingestion :

Etapes de l’ingestion et de l’embbedding, index vectoriel

Il est important de noter que ce processus est appliqué à chaque thème de façon distincte. Les applications utiliseront l’index et les données des thèmes auxquels elles ont accès.

Raisonnement et génération : utiliser un LLM comme ceux d’OpenAI ou de MistralAI pour traiter les données récupérées, générer des informations ou créer du contenu.

La première étape consiste à sélectionner (Retrieval) les fragments de documents correspondant le mieux à la question.
Puis deux méthodes [1] sont possibles :

– LLM-based Retrieval : Après une recherche locale, on fournit au LLM le contenu des fragments sélectionnés d’après la question (prompt), [2] avec la question elle même. Tout est sous forme de texte. Le LLM refait le travail d’embeddings, de recherche et de synthèse.

LLM based Retrieval

– Embeddings-based Retrieval : On fournit au LLM les embeddings sélectionnés (des noeuds avec vecteurs) ainsi que la question, elle même sous forme d’embeddings.

Embeddings-based Retrieval

Dans un contexte RAG, la deuxième méthode est préférable. En effet, dans le premier cas, des données métier figurent dans les fragments et dans la question sous forme textuelle. Le LLM ne trouvera pas de vecteurs correspondants dans son modèle (sauf à pratiquer le "fine tuning" du modèle). La réponse risque d’être générale voir "hallucinée" car la recherche portera sur sa base de connaissances.

Dans le deuxième cas, il n’y aura pas de recherche de la part du LLM. Seule les fonctions synthetiser et assembler du LLM seront sollicitées pour travailler sur les embeddings fournis. De ce fait, on n’a pas besoin d’un modèle avec une base de connaissance étendue. Cela élimine les hallucinations hors sujet.