Collections de connaissances
Les sources sont stockées une fois dans la bibliothèque d'un projet, puis rattachées à des collections. Un agent interroge les collections que vous lui attribuez, et rien d'autre.
La connaissance dans Rikoo a deux niveaux. Une source est un document que vous ajoutez à un projet : un fichier, un texte collé, ou un contenu récupéré par un connecteur. Une collection regroupe des sources et les indexe avec un modèle d'embedding. On attribue aux agents des collections, jamais des sources, et c'est cette séparation qui permet au même document de servir deux publics sous deux jeux de règles différents.
Sources
Une source appartient à un projet et n'est stockée qu'une fois. Elle peut être rattachée à plusieurs collections de ce projet, et chaque rattachement est indexé séparément, avec les réglages de sa collection : une source peut être prête dans une collection et en erreur dans une autre.
- Des fichiers : PDF, Word (
.docx), Markdown, HTML, texte brut, CSV, JSON, XML et H5P. Les fichiers Excel, PowerPoint et OpenDocument ne sont lus que si le service facultatifsidecar-parsingest déployé, voir Infrastructure. - Du texte collé directement.
- Des pages web, Notion et Confluence, via les connecteurs de sources, un module Enterprise.
L'ingestion extrait le texte, le découpe en fragments, et calcule un embedding pour chaque fragment avec le modèle de la collection. Tout se passe dans le worker : le serveur d'API ne parle jamais à un fournisseur.
Collections
Une collection est indexée avec un seul modèle d'embedding à la fois, et ce modèle fixe la taille de ses vecteurs. L'index de recherche couvre les vecteurs de 1 536 et de 3 072 dimensions : deux collections peuvent donc utiliser des modèles différents, et un modèle connu pour produire une autre taille est refusé avant qu'aucun embedding ne soit payé. Changer le modèle d'une collection qui contient déjà des fragments exige une réindexation explicite, qui recalcule l'embedding de chaque source avec le nouveau modèle. La taille des fragments et leur chevauchement se règlent aussi par collection, et s'appliquent à la prochaine indexation.
La recherche reçoit les collections attribuées à l'exécution et filtre dessus dans la requête elle-même, pas après coup. Un agent ne peut pas lire une collection qui ne lui a pas été attribuée, ni une collection d'un autre projet ou d'une autre organisation. La suite de tests comprend des cas qui tentent de franchir chacune de ces frontières.
Ce que l'agent récupère
La recherche est hybride : une recherche vectorielle (pgvector, index HNSW) et une recherche plein texte PostgreSQL tournent côte à côte, et leurs classements sont fusionnés. Selon le réglage de l'agent, la recherche porte sur le message de l'utilisateur avant que le modèle réponde, ou le modèle appelle un outil search_knowledge avec ses propres requêtes, ou les deux.
L'exécution enregistre les extraits fournis au modèle : le fragment, sa source, sa collection et son score, pour qu'une réponse puisse être remontée jusqu'au passage d'où elle vient. Un agent peut aussi exiger des citations. Une réponse qui ne cite aucun extrait, ou qui en cite un qui n'a pas été retrouvé, est alors rejetée et l'exécution échoue.
Les extraits sont aussi du contenu non fiable. Un document peut contenir des instructions destinées au modèle : le texte retrouvé est donc encadré comme des données avant d'atteindre le prompt. Voir Garde-fous.
Cycle de vie
| Action | Effet |
|---|---|
| Supprimer une source | Ses fragments, dans toutes les collections, et son fichier stocké sont retirés, en base et dans le stockage objet |
| Détacher une source d'une collection | La source reste dans la bibliothèque, et ses fragments ne quittent que cette collection |
| Supprimer une collection | Refusé tant qu'un agent a reçu la collection. Sinon ses fragments partent, et ses sources restent dans la bibliothèque |