Fournir votre propre base de données de vecteurs

Utilisez votre base de données de vecteurs existante pour ancrer les réponses des agents dans des données d’entreprise approuvées, sans dupliquer le contenu ou modifier votre architecture actuelle.

Ce guide montre comment connecter des bases de données de vecteurs gérées en externe (telles que Databricks Vector Search ou Azure AI Search) aux agents UiPath à l'aide de Workflows d'API, en permettant la génération augmentée de récupération (RAG) avec vos propres sources de données.

À la fin de ce guide, vous serez en mesure de :

• Interrogez une base de données de vecteurs externe depuis un agent UiPath.
• Renvoyez le contenu le plus pertinent en tant que contexte structuré.
• Ancrez les réponses des agents dans les données de votre organisation en toute sécurité et en temps réel.

Quand utiliser le modèle Apporter votre propre vecteur de base de données (BYOVD)

Utilisez BYOVD lorsque :

• Vos données sont déjà indexées dans un magasin de vecteurs externe.
• Vous souhaitez que les agents accèdent à des connaissances d’entreprise à jour.
• Vous devez éviter de copier ou de réindexer des données dans UiPath.
• Vous avez besoin d’un contrôle total sur le stockage des données, la sécurité et les intégrations.

Mode de fonctionnement

L’analyse de l’IA générative permet aux agents d’ancrer les réponses de l’IA générative dans vos sources de données approuvées. Au lieu de vous appuyer sur un index d’ancrage dans le contexte intégré, vous utilisez des workflows d’API qui interrogent votre base de données de vecteurs externe et renvoient le contexte pertinent au grand modèle de langage de l’agent.

Cette approche vous donne la flexibilité nécessaire pour intégrer n’importe quelle base de données de vecteurs à une API publique, tout en conservant le contrôle sur l’accès aux données, l’authentification et la logique de récupération.

UiPath active la fonctionnalité BYOVD via des workflows d'API qui servent d'outils aux agents. Au moment de l’exécution :

1. Requête utilisateur: l'utilisateur soumet une requête à l'agent.
2. Sélection d'outils: le LLM de l'agent détermine qu'un contexte supplémentaire est nécessaire et sélectionne l'outil de recherche de vecteurs personnalisés.
3. Exécution du workflow d'API: l'agent invoque le workflow d'API publié, en passant la requête de l'utilisateur comme entrée.
4. Recherche de vecteurs: le workflow interroge la base de données de vecteurs pour récupérer le contenu le plus pertinent sur le plan sémantique.
5. Retour du contexte : le workflow renvoie le contenu récupéré au format JSON structuré.
6. Formulation de réponse: l’agent utilise ce contexte pour générer une réponse précise et ancrée dans le contexte.

Cette approche prend en charge la génération augmentée de récupération (RAG) sans nécessiter d’ingestion native dans le service d’ancrage dans le contexte.

Présentation de l'architecture

La solution BYOVD se compose de trois composants principaux :

• Base de données de vecteurs: votre système existant (par exemple, Databricks Vector Search).

• Workflow d'API: un workflow UiPath Integration Service qui :

  • Accepte une requête.
  • Appelle l'API de la base de données de vecteurs.
  • Renvoie les résultats pertinents.
• Outil d’agent: le workflow d’API publié, ajouté en tant qu’outil que l’agent peut invoquer.

Gestion de la sécurité et des informations d’identification

Avant de créer le workflow, stockez toutes les clés API et tous les secrets en toute sécurité. Ne codez pas les informations d’identification en dur dans votre workflow. Utilisez plutôt le magasin d'informations d’identification Orchestrator :

• Stocker les informations d'identification dans Orchestrator: ajoutez vos clés API et autres clés secrètes en tant que ressources d'informations d'identification dans votre locataire Orchestrator. Il est donc possible d'assurer une gestion centralisée et sécurisée des informations sensibles.
• Récupérer les informations d'identification lors du runtime: dans votre workflow d'API, utilisez l'activité Obtenir l'identifiant pour accéder aux informations d'identification stockées lorsque le workflow s'exécute. L'activité renvoie le nom d'utilisateur sous forme de chaîne et le mot de passe (par exemple, une clé API) sous forme de SecureString, empêchant ainsi l'exposition de clés secrètes dans les journaux ou les définitions de workflow.

Prérequis

Avant de commencer, effectuez les actions suivantes :

• Une base de données de vecteurs actifs (telle que Databricks Vector Search ou Azure AI Search) avec des données indexées.

• Un point de terminaison d'API et des informations d'identification valides stockés en tant que ressources d'informations d'identification dans Orchestrator.

• Un point de terminaison et une clé de modèle d’intégration, également stockés en toute sécurité (.

Configuration

Vous pouvez implémenter l’option BYOVD à l’aide de l’une de ces trois approches : les points de terminaison nœuds natifs du modèle, la Extraction des données du client, ou la Extraction intégrée des données.

Les sections suivantes fournissent des instructions étape par étape pour configurer chaque approche. Les exemples utilisent Databricks et Azure AI Search, mais le même modèle s’applique aux autres bases de données de vecteurs. Choisissez une configuration qui correspond à la façon dont votre base de données de vecteurs gère la vecteur des requêtes.

Recherche de vecteurs Databricks (point de terminaison modèle-natif)

Utilisez cette option lorsque Databricks gère la vecteur des requêtes de manière native.

Pourquoi utiliser cette option :

• Une configuration simple
• Un seul appel API par requête
• Aucun modèle d’intégration distinct requis

Étapes

1. Obtenez les détails de Databricks :
   1. Récupérez l'URL du point de terminaison.
   2. Stockez votre jeton d’accès personnel Databricks en tant que ressource d’informations d’identification dans Orchestrator.
2. Dans Studio, créez un nouveau projet de workflow d'API et définissez les arguments suivants :
   • in_QueryText (String)
   • in_TopK (Int32, avec une valeur par défaut de 5)
   • out_Results (String)
3. Utilisez l'activité Get Credential pour récupérer le jeton d'accès personnel Databricks d'Orchestrator au moment du runtime.
4. Ajoutez une activité Requête HTTP pour appeler le point de terminaison Databricks :
   • Point de terminaison: le point de terminaison de recherche de vecteurs Databricks
   • Méthode: POST
   • En-têtes: Authorization: Bearer <Personal Access Token>
   • Corps: créez le corps JSON requis par l'API Databricks, en mappant vos variables d'entrée.
5. Publiez le workflow sur votre locataire Orchestrator.
6. Ajoutez le workflow en tant qu'outil à votre agent, en fournissant le nom et la description clairs du LLM à utiliser.

Recherche d’IA Azure ( typerisation côté client)

Utilisez cette option lorsque votre index Azure AI Search attend des entrées de vecteurs.

Pourquoi utiliser cette option :

• Contrôle total des modèles d’intégration
• Compatibilité avec les index de vecteurs existants

Étapes

1. Obtenir les détails de l'API :
   • Pour Azure AI Search : récupérez l' URL du point de terminaison, le nom de l'index et stockez votre clé API en tant que ressource d'informations d'identification dans Orchestrator.
   • Pour le modèle d'intégration : récupérez l'URL du point de terminaison et stockez la clé API de votre service d'intégration en tant que ressource d'informations d'identification dans Orchestrator.
2. Dans Studio, créez un nouveau projet de workflow d'API et définissez les arguments suivants :
   • in_QueryText (String)
   • in_TopK (Int32, avec une valeur par défaut de 5)
   • out_Results (String)
3. Tout d’abord, vecteurs de la requête :
   1. Ajoutez une activité Obtenir les informations d’identification pour récupérer la clé API de votre modèle d’intégration.
   2. Ajoutez une activité Requête HTTP pour appeler votre modèle d’intégration avec in_QueryText.
   3. Désérialisez la réponse JSON et enregistrez le vecteur d’intégration obtenu dans une variable (par exemple, queryVector.
4. Interroger la recherche Azure AI :
   1. Ajoutez une activité Obtenir les informations d’identification pour récupérer votre clé API Azure AI Search.
   2. Ajoutez une activité Demande HTTP et configurez-la comme suit :
      • Point de terminaison: votre point de terminaison Azure AI Search.
      • Méthode : POST.
      • En-têtes : ajoutez un en-tête api-key avec votre variable de clé API Azure AI Search, comme suit : api-key: <API key>.
      • Corps : créez le corps JSON pour la requête de recherche du vecteur Azure AI Search en intégrant votre variable queryVector .
5. Publiez le workflow sur votre locataire Orchestrator.
6. Ajoutez le workflow publié en tant qu'outil à votre agent, en fournissant une description claire du LLM à utiliser.

Recherche d’Azure AI (optimisation intégrée)

Utilisez cette option lorsque votre index Azure AI Search prend en charge la vecteur de numérisation intégrée.

Pourquoi utiliser cette option :

• Configuration Azure la plus simple
• Aucun appel d'intégration dans le workflow
• Unique requête API par requête

Étapes

1. Obtenir les détails de l'API :
   • Récupérez votre URL de point de terminaison Azure AI Search, le nom de l'index et stockez votre clé API en tant que ressource d'informations d'identification dans Orchestrator.
2. Dans Studio, créez un nouveau projet de workflow d'API et définissez les arguments suivants :
   • in_QueryText (String)
   • in_TopK (Int32, avec une valeur par défaut de 5)
   • out_Results (String)
3. Ajoutez une activité Obtenir les informations d'identification pour récupérer votre clé API Azure AI Search à partir d'Orchestrator.
4. Ajoutez une activité Demande HTTP et configurez-la comme suit :
   • Point de terminaison:

     https://<service>.search.windows.net/indexes/<index-name>/docs/search?api-version=2023-11-01

   • Méthode: POST
   • En-têtes: ajoutez un en-tête api-key avec votre variable de clé API Azure AI Search, comme suit : api-key: <API key>
   • Corps: créez le corps JSON pour effectuer une recherche de vecteurs à l’aide du texte de la requête. Azure AI Search gère automatiquement la vecteur de la vecteur de données.

     {
       "vectorQueries": [
         {
           "kind": "text",
           "text": "<%= in_QueryText %>",
           "fields": "contentVector",
           "k": "<%= in_TopK %>"
         }
       ],
       "select": "chunk, source_document"
     }

5. Publiez le workflow sur votre locataire Orchestrator.
6. Ajoutez le workflow publié en tant qu'outil à votre agent, en fournissant une description claire du LLM.