17 lines
1.4 KiB
Markdown
17 lines
1.4 KiB
Markdown
# AnythingLLM — workspaces par projet
|
||
|
||
## Principe
|
||
|
||
- Un **workspace AnythingLLM** est créé (ou associé) **par projet** : documents indexés, embeddings, threads et paramètres RAG sont **scopés au projet**, pas mélangés entre dépôts.
|
||
- Cela permet à la mémoire interrogée par `ask` / les agents de rester **pertinente** et **traçable** par contexte métier.
|
||
|
||
## Synchronisation avec le dépôt
|
||
|
||
- Une **moulinette** (pipeline de synchro) met à jour le workspace à partir de fichiers sélectionnés du dépôt : sources, doc, configs exposées volontairement, etc.
|
||
- Les règles de ce qu’on synchronise (inclusions / exclusions, secrets interdits) doivent être **explicites** et alignées avec la politique de sécurité du projet.
|
||
|
||
## Exploitation
|
||
|
||
- Instance Docker décrite dans [services.md](./services.md) : stockage hôte typiquement sous `$HOME/anythingllm` sur l’**hôte qui exécute le conteneur** — en **première cible de déploiement**, cet hôte est le **serveur distant** (SSH), pas obligatoirement le poste Linux client ; la création de **plusieurs workspaces** se fait dans l’UI AnythingLLM (ou via API) en conservant la convention « un workspace = un projet ».
|
||
- L’orchestrateur IDE décide **quand** interroger AnythingLLM (voir [system-architecture.md](./system-architecture.md)). L’URL vue depuis le client peut exiger un **tunnel SSH** ou un rebond réseau : [deployment-target.md](./deployment-target.md).
|