La recherche générative associe modèles d’IA générative et fonctionnalités de recherche pour compléter les capacités de recherche et de récupération des solutions de recherche par les capacités de génération de contenu et de synthèse des grands modèles de langage (LLM). L’architecture conceptuelle de la recherche générative est présentée dans le diagramme ci-dessous.
- Génération augmentée de récupération
- Discussion avec un agent conversationnel
- Recherche générative
- IA agentique
- Synthèse de documents
- Modernisation et génération de code
- Génération de code pour Ansible
- Génération de code pour Z
- Développement de logiciels augmenté par l’IA avec des agents
Les documents clients comme les documents Word, PDF, données Web et autres textes structurés et non structurés, sont ingérés dans un composant d’analyse de contenu et préparés pour la recherche sémantique.
L’utilisateur envoie une question via l’interface utilisateur Analyse de contenu.
Le composant Analyse de contenu identifie les documents et les passages d’information les plus pertinents pour la question de l’utilisateur. Selon la question de l’utilisateur, le composant envoie la question, ainsi que les documents et passages pertinents, à un LLM pour générer une réponse semblable à celle d’un humain.
Le LLM renvoie la réponse générée, qui est ensuite transmise à l’utilisateur.
Le mappage de la famille de produits IBM watsonx au schéma de recherche générative est illustré dans le diagramme ci-dessous. IBM Watson Discovery est utilisé pour assurer l’ingestion des documents, la compréhension des documents, l’analyse du contenu et les informations du composant Analyse de contenu. IBM watsonx.ai est utilisé pour sélectionner, régler, tester et déployer le grand modèle de langage utilisé pour étendre Watson Discovery.
Certains clients n’ont pas accès à watsonx.ai dans leur région, ou peuvent être dans l’impossibilité d’utiliser la solution watsonx.ai SaaS pour des raisons de sécurité ou d’exigences réglementaires. Nous leur proposons watsonx.ai sous la forme d’un ensemble de services conteneurisés qui peuvent être déployés sur Red Hat Openshift dans leur propre centre de données, ou dans un cloud privé virtuel (VPC) sur l’infrastructure d’un fournisseur de service cloud.
Décisions et considérations relatives à l’architecture
Le choix du modèle dépend de nombreux facteurs.
La licence du modèle peut restreindre son utilisation. Par exemple, elle peut interdire son utilisation dans le cadre d’une application commerciale.
Le jeu de données utilisé pour entraîner le modèle affecte directement la performance de ce dernier sur une application donnée. Le risque que le modèle génère des réponses absurdes, offensantes ou tout simplement indésirables en dépend également. De la même manière, les modèles entraînés sur des données privées ou protégées par le droit d’auteur peuvent engager la responsabilité des utilisateurs. IBM assure une transparence totale des données d’entraînement et une indemnisation en cas de réclamation portant sur ses modèles.
La taille du modèle, c’est-à-dire le nombre de paramètres avec lesquels il est entraîné, et la taille de sa fenêtre contextuelle, c’est-à-dire la longueur des passages de texte que le modèle peut accepter, affectent la performance du modèle, les besoins en ressources et, par extension, le coût et le débit. Bien qu’il soit tentant de suivre le principe « plus c’est grand, mieux c’est » et de choisir un modèle à 20 milliards de paramètres, les besoins en ressources et l’amélioration (éventuelle) en termes de précision ne le justifient pas nécessairement. Selon plusieurs études récentes, les modèles plus petits peuvent s’avérer nettement plus performants que les grands dans le cas de certaines solutions.
Tout réglage fin appliqué aux modèles peut affecter leur adéquation à une tâche donnée. Par exemple, IBM propose deux versions du modèle Granite : l’une adaptée aux applications de chat générales, et une autre conçue pour suivre des instructions.
Autres aspects à prendre en compte pour bien choisir votre modèle :
Sélection des paramètres du modèle, comme sa température, pour concilier génération de textes semblables à ceux rédigé par un humain et réponses factuelles. Définir la température du modèle sur une valeur élevée entraîne la production de réponses cohérentes, mais potentiellement sans intérêt ou trop lacunaires, tandis que le réglage sur une valeur faible permet des réponses plus variées, dont la longueur et le contenu seront toutefois plus imprévisibles.
Sélection et mise en œuvre des garde-fous dans le modèle pour éviter les résultats inefficaces ou offensants.
La langue des données client et des prompts de l’utilisateur doit également être prise en compte. La majorité des LLM sont entraînés sur des textes en anglais et peuvent souvent traduire entre l’anglais et d’autres langues avec des niveaux d’expertise variables. Les applications nécessitant une prise en charge multilingue ou plus localisée peuvent nécessiter l’utilisation de plusieurs modèles entraînés dans chacune des langues prises en charge, ou la mise en œuvre d’une étape de traduction pour traduire les entrées multilingues en anglais ou dans une autre langue « de base ».
Certains clients souhaiteront peut-être disposer d’un mécanisme de feedback pour affiner en permanence les réponses du système. Au fil du temps, ce feedback peut permettre d’améliorer la configuration de Watson Discovery (par exemple, en affinant les paramètres de recherche) et d’affiner le LLM.
Les clients des secteurs réglementés peuvent souhaiter inclure une couche supplémentaire de surveillance pour se conformer aux réglementations et fournir une transparence aux utilisateurs sur la façon dont leurs requêtes sont traitées, ainsi que sur le rôle de l’IA dans la génération des réponses.
Comme pour tout système intégré, surveillez en permanence la performance, la satisfaction utilisateur et les problèmes potentiels. Préparez-vous à faire évoluer l’infrastructure à mesure que la demande des utilisateurs augmente.