Le service Knowledge Storage convertit vos documents métier en Chunks que les applications de génération augmentée par récupération (RAG) peuvent interroger. Ce service gère l'analyse, le découpage, l'intégration vectorielle, l'indexation et la récupération des documents. Votre application n'a qu'à maintenir les documents et transmettre les résultats récupérés à un grand modèle de langage (LLM).
Qu'est-ce que le service Knowledge Storage ?
Le service Knowledge Storage est une solution RAG serverless entièrement gérée, construite sur Alibaba Cloud Tablestore. Vous n'avez pas besoin de déployer ni de maintenir des serveurs physiques ou une infrastructure sous-jacente.
Une fois que vous avez importé des documents via la console, un SDK ou l'interface CLI, le système les analyse et les découpe automatiquement, génère leurs vecteurs et construit les index. Lors de la phase de récupération, le service effectue une recherche hybride et renvoie les Chunks pertinents.
Toutes les données sont stockées dans les ressources Object Storage Service (OSS) et Tablestore de votre propre compte. Le service ne conserve ni ne copie vos données. Le stockage et le calcul sont dissociés et facturés indépendamment. Dans un flux de travail d'application d'IA typique, le service Knowledge Storage assure la gestion et la récupération des connaissances.
Pour plus d'informations sur la facturation du service Knowledge Storage, consultez la rubrique Facturation du produit. Pour essayer rapidement le service Knowledge Storage, reportez-vous à la section Créer votre première base de connaissances.
Le service Knowledge Storage est disponible dans les régions suivantes : Chine (Pékin), Chine (Shanghai), Chine (Hangzhou), Chine (Shenzhen), Chine (Hong Kong) et Singapour. Sélectionnez la région la plus proche pour optimiser l'accès.
Fonctionnalités et avantages
Architecture serverless et élastique — L'architecture serverless entièrement gérée fonctionne selon un modèle de paiement à l'utilisation, sans frais minimum. Le stockage et le calcul sont facturés séparément. Une seule base de connaissances prend en charge jusqu'à 10 millions de documents par défaut. S'appuyant sur l'architecture distribuée de Tablestore, le service s'adapte à la croissance de votre activité. Pour connaître les limites spécifiques, consultez la page Quotas et limites.
Pipeline de base de connaissances entièrement géré — Dès qu'un document est téléchargé, le système réalise automatiquement son analyse, son découpage, sa vectorisation, la construction des index et toutes les autres étapes de traitement. Le service prend en charge les formats de document courants, notamment PDF, Word (doc/docx), Excel (xls/xlsx), PowerPoint (ppt/pptx), texte brut (txt) et Markdown (md). Vous n'avez pas besoin de concevoir un pipeline de traitement de documents, de gérer le déploiement et l'exploitation des modèles d'intégration, ni de construire et maintenir manuellement des index vectoriels. Le service gère automatiquement l'intégralité du cycle de vie de la base de connaissances.
Propriété des données et contrôle total — Toutes les données brutes, intermédiaires et finales générées durant le processus sont stockées dans votre propre compte de service cloud, au sein d'un compartiment OSS ou d'une instance Tablestore. Le service ne détient ni ne duplique vos données. Cette architecture garantit que la propriété et la sécurité des données restent entièrement sous votre contrôle, répondant ainsi aux exigences strictes de conformité des secteurs tels que la finance, le gouvernement et la santé.
Personnalisation flexible et récupération précise — Le service propose une récupération hybride à double canal, combinant la recherche vectorielle et la recherche en texte intégral (similarité sémantique + correspondance exacte de mots-clés). Il met à disposition trois stratégies de reclassement (
RRF,WEIGHTetMODEL) que vous pouvez sélectionner selon votre cas d'usage. Vous pouvez contrôler avec précision les modules principaux via des API et des paramètres, depuis le choix du modèle d'intégration (Model Studio intégré ou personnalisé) et la configuration de la stratégie de récupération, jusqu'aux conditions de filtrage des métadonnées et à la gestion du contenu au niveau des Chunks.
Scénarios d'application typiques
| Scénario | Description |
| Système de questions-réponses basé sur les connaissances de l'entreprise | Importez la documentation interne sur les produits, les manuels techniques, la FAQ, les politiques et autres supports dans une base de connaissances, puis combinez-les avec un LLM pour créer un système intelligent de questions-réponses. Lorsqu'un employé ou un client pose une question, le système récupère les Chunks de contenu les plus pertinents depuis la base de connaissances et les transmet au LLM afin de générer des réponses précises et traçables. Cette approche s'applique aux services clients, aux ressources humaines, aux services juridiques, aux opérations informatiques et à d'autres départements. |
| Recherche et synthèse intelligente de documents | Remplacez un moteur de recherche traditionnel par mot-clé par une récupération vectorielle qui comprend l'intention de recherche de l'utilisateur et renvoie les Chunks de documents sémantiquement les plus pertinents. Combinez cette fonctionnalité avec un filtrage par métadonnées selon la date, la catégorie, l'auteur et d'autres dimensions pour offrir une récupération de documents précise. |
| Base de connaissances SaaS multi-locataires | Utilisez Subspace pour isoler les données des différents locataires, tels que les utilisateurs, les départements et les clients, au sein d'une même base de connaissances. Chaque locataire ne peut récupérer que les documents présents dans son propre Subspace, ce qui assure une isolation native des données sans nécessiter de base de connaissances distincte pour chaque locataire. Cela réduit considérablement la complexité de gestion et les coûts. |
| Intégration de pipeline RAG | Utilisez le service Knowledge Storage comme couche de récupération dans une architecture RAG et intégrez-le aux frameworks d'IA populaires tels que LangChain et LlamaIndex. Ingérez les documents dans une base de connaissances, appelez l'API Retrieve pendant l'inférence pour obtenir le contexte pertinent, ajoutez-le à l'invite (prompt) et envoyez-le au LLM pour permettre une génération enrichie par les connaissances. |
| Gestion et audit des documents de conformité | Utilisez ce service pour gérer les documents de conformité dans des secteurs tels que la finance, la santé et le gouvernement. Toutes les données sont stockées dans votre propre compte cloud afin de respecter les exigences de conformité en matière de résidence des données. Utilisez le champ metadata pour étiqueter les attributs des documents, tels que la catégorie, la version et la période de validité, et combinez-le avec le filtrage par métadonnées pour offrir une récupération précise des documents de conformité. |
L'analyse des documents, leur découpage et la construction des index après l'importation sont asynchrones et réalisés automatiquement par le système. Évaluez attentivement si le service Knowledge Storage convient aux scénarios nécessitant un traitement en temps réel ou des stratégies de découpage strictement personnalisées.
Pour les requêtes portant exclusivement sur des données structurées, nous recommandons le modèle wide-column ou une base de données relationnelle. Pour l'indexation de données de streaming en temps réel, il est préférable d'utiliser directement un index de recherche Tablestore.
Glossaire
Les données d'une base de connaissances sont organisées en quatre niveaux d'entités :
| Entité | Description |
| KnowledgeBase | Une base de connaissances. Chaque base de connaissances correspond aux données de documents, de Chunks et d'index. |
| Document | Un enregistrement associé à un fichier OSS qui capture l'état du document et ses métadonnées. |
| Chunk | Un segment de document qui stocke les données vectorielles et le texte original. Il constitue l'unité de récupération la plus petite. |
| Index | Un index vectoriel et en texte intégral géré par le service, utilisé pour récupérer les Chunks candidats. |
Le système crée automatiquement les tables de données correspondantes dans Tablestore. Dans les noms de table suivants, les espaces réservés représentent le nom et l'ID de la base de connaissances :
Table des documents :
{knowledge_base_name}_{knowledge_base_id}Table des Chunks :
{knowledge_base_name}_{knowledge_base_id}_chunkTable des index :
{knowledge_base_name}_{knowledge_base_id}_index
Configuration de la source de données de la base de connaissances
La source de données d'une base de connaissances est Alibaba Cloud Object Storage Service (OSS). Quelle que soit la méthode de téléchargement des documents, leurs données brutes sont stockées dans votre propre compartiment OSS.
Une base de connaissances nécessite un accès en lecture et en écriture au compartiment OSS : elle lit les documents sources pour l'analyse et le découpage, et écrit les résultats intermédiaires de l'analyse dans OSS.
Vous pouvez importer des documents dans une base de connaissances de trois manières :
Télécharger des fichiers locaux — Spécifiez un fichier ou un répertoire local. Le SDK le télécharge automatiquement dans OSS, puis l'ajoute à la base de connaissances. Si vous spécifiez un répertoire, le SDK parcourt tous les fichiers de manière récursive.
Ajouter des fichiers OSS — Si un fichier se trouve déjà dans OSS, spécifiez son chemin OSS pour l'ajouter directement à la base de connaissances sans avoir à le télécharger.
Importer en masse un répertoire OSS — Spécifiez le chemin d'un répertoire OSS. Le système analyse automatiquement tous les fichiers du répertoire de manière récursive. Vous pouvez utiliser
inclusionFiltersetexclusionFilterspour filtrer les fichiers selon un motif de nom.
Pour plus de détails sur chaque méthode, consultez la rubrique Gestion des documents.
Configuration d'intégration de la base de connaissances
La configuration d'intégration détermine la manière dont les Chunks de documents sont vectorisés. Elle est spécifiée lors de la création d'une base de connaissances.
Vous ne pouvez pas modifier la configuration d'intégration après la création d'une base de connaissances. Pour changer de modèle ou de dimension, vous devez supprimer et recréer la base de connaissances. Évaluez soigneusement le choix du modèle avant de créer la base de connaissances.
| Élément de configuration | Description |
provider |
Fournisseur du modèle : bailian (Model Studio intégré) ou custom (personnalisé). |
model |
Nom du modèle. Model Studio prend en charge text-embedding-v3 et text-embedding-v4. |
dimension |
Dimension du vecteur. Par exemple, text-embedding-v4 possède 1 024 dimensions. |
url |
Requis uniquement en mode custom. Contactez Tablestore à l'avance pour enregistrer une URL valide. |
apiKey |
Requis uniquement en mode custom. |
Si embeddingConfiguration n'est pas spécifié, le système utilise par défaut le modèle intégré Model Studio text-embedding-v4 avec 1 024 dimensions. Cette configuration convient à la plupart des scénarios.
Recommandations de sélection
Pour les scénarios généraux en chinois et en anglais, nous recommandons
text-embedding-v4avec 1 024 dimensions. Ce modèle offre un bon équilibre entre compréhension sémantique et performances.Pour intégrer un service d'intégration existant développé en interne ou tiers, utilisez le mode
customafin de maintenir la cohérence de votre pile technologique.Des dimensions plus élevées offrent une représentation sémantique plus riche, mais augmentent également les coûts de stockage et de calcul. Pour la plupart des scénarios, nous recommandons 1 024 dimensions.
Configuration de la stratégie de récupération de la base de connaissances
Lorsque vous appelez l'API Retrieve, la configuration de récupération (retrievalConfiguration) est déterminée selon l'ordre de priorité suivant :
| Priorité | Source | Description |
| 1 (la plus élevée) | Paramètres de l'API Retrieve | La configuration transmise dans la requête actuelle s'applique uniquement à cette requête. |
| 2 | Configuration au niveau de la base de connaissances | Définie lors de la création de la base de connaissances et modifiable via UpdateKnowledgeBase. |
| 3 (la plus basse) | Valeur par défaut du système | Récupération hybride vectorielle et en texte intégral avec fusion pondérée WEIGHT (vecteur 0,7 : texte intégral 0,3). |
Types de récupération
| Type | Description | Scénario applicable |
DENSE_VECTOR |
Récupération vectorielle basée sur la similarité sémantique. | Décrivez les besoins en langage naturel lorsque la compréhension sémantique est nécessaire. |
FULL_TEXT |
Récupération en texte intégral basée sur la correspondance exacte de mots-clés. | Saisissez des mots-clés exacts, des noms propres ou des ID. |
Nous recommandons d'activer les deux types de récupération et de combiner leurs résultats via le mécanisme de reclassement.
Stratégies de reclassement
| Type | Description | Scénario applicable |
RRF |
Fusion pondérée par rang réciproque sans appel de modèle supplémentaire. | Scénarios généraux nécessitant une faible latence. |
WEIGHT |
Pondère les scores de récupération vectorielle et en texte intégral selon un ratio spécifié. | Un contrôle fin de la contribution des deux canaux de récupération est requis. |
MODEL |
Appelle un modèle de reclassement pour réorganiser les résultats candidats. | Une qualité de classement élevée est requise et une latence supplémentaire est acceptable. |
Pour plus de détails sur la configuration et l'optimisation des stratégies de récupération, consultez la rubrique Récupération et classement.
Gestion multi-locataires
Subspace est une partition d'isolation des données au sein d'une base de connaissances. Utilisez-la pour isoler les données par utilisateur, département ou locataire au sein d'une même base de connaissances. Définissez "subspace": true lors de la création d'une base de connaissances pour l'activer.
Règles principales :
Vous ne pouvez pas modifier le paramètre Subspace après la création d'une base de connaissances.
Une fois Subspace activé, toutes les opérations sur les documents (ajout, requête, suppression et liste) ainsi que les opérations de récupération doivent spécifier le champ
subspace. Sinon, une erreur est renvoyée.Retrieve permet d'interroger plusieurs Subspaces simultanément en passant une liste contenant jusqu'à 32 Subspaces.
Un nom de Subspace peut comporter jusqu'à 128 octets.
Dans un environnement d'entreprise, chaque employé d'un même département possède ses propres documents. L'administrateur du département crée une base de connaissances avec Subspace activé et attribue un Subspace indépendant à chaque employé, par exemple employee_zhangsan et employee_lisi. Les documents de chaque employé sont invisibles pour les autres, tandis que l'administrateur gère centralement la configuration de la base de connaissances. Pour récupérer des données couvrant plusieurs employés, passez plusieurs Subspaces à Retrieve pour une récupération conjointe.
Subspace et multiples bases de connaissances
| Dimension | Subspace | Multiples bases de connaissances |
| Granularité de l'isolation | Partitions logiques au sein d'une même base de connaissances | Bases de connaissances complètement indépendantes |
| Configuration d'intégration | Configuration partagée | Chaque base de connaissances possède une configuration indépendante |
| Portée de la récupération | La récupération conjointe entre Subspaces est prise en charge | La récupération est limitée à une seule base de connaissances |
| Coût de gestion | Faible : une seule base de connaissances gère tous les locataires | Élevé : plusieurs bases de connaissances doivent être gérées |
| Scénario applicable | Isolation des données multi-locataires pour des données homogènes | Différents domaines métier et exigences d'intégration |