abbey
1.0.0
Abbey est une interface AI avec des cahiers, un chat de base, des documents, des vidéos YouTube, etc. Il orchestre une variété de modèles d'IA dans un package auto-hébergé privé. Vous pouvez exécuter Abbey en tant que serveur pour plusieurs utilisateurs à l'aide de votre propre fournisseur d'authentification, ou vous pouvez l'exécuter par vous-même sur votre propre machine. Abbey est hautement configurable, en utilisant les LLM, les modèles TTS, les modèles OCR et les moteurs de recherche. Vous pouvez trouver une version hébergée d'Abbey ici, qui est utilisée par de nombreux étudiants et professionnels.
Vous avez des problèmes? S'il vous plaît, veuillez poster un problème ou contacter directement le créateur! Twitter dm @ gkamer8, envoyez un courriel à [email protected], ou autrement le faire ping - il aime ça.
Si Abbey n'est pas par défaut configurable à votre goût et que vous êtes à l'aise d'écrire du code, veuillez envisager d'ouvrir un RP avec vos améliorations! L'ajout de nouvelles intégrations et même des interfaces complètes est simple; Voir plus de détails dans la section "Contribution" ci-dessous.
docker compose . Voir les détails ici.Si vous avez une version précédente d'Abbey et que vous faites le modèle "Nouvelle installation" avec SetfitS.yml pour la première fois, tracez, créez un nouveau paramètres.yml et .env comme décrit ci-dessous, déplacez vos fichiers à partir de backend / app / statique à fichier-stockage, et reconstruisez-vous -
La configuration implique le clonage / télécharger ce dépôt, la création de fichiers .env et settings.yml avec les intégrations d'IA choisies, puis exécuter docker compose pour l'un ou l'autre développement (pire performance mais facile à jouer avec) ou la production (meilleures performances mais plus lentes à modifier les paramètres). Voici les étapes:
Étape 1: clone / télécharger ce référentiel et naviguer à l'intérieur.
Étape 2: Créez un fichier appelé .env pour les touches secrètes et un fichier appelé settings.yml pour les paramètres de configuration à la racine du référentiel (c'est-à-dire au même niveau que le fichier docker-compose.yml ). Ensuite, entrez dans ces fichiers les touches / modèles que vous souhaitez utiliser. Vous pouvez trouver des détails sur la façon de configurer chaque type d'intégration tout au long de cette lecture.
Le fichier .env contient toutes les clés API ou autres secrets dont vous avez besoin. Vous devez également inclure un mot de passe pour la base de données MySQL que Abbey utilise. Un fichier .env pour une personne utilisant l'API OpenAI officielle, une API compatible OpenAI nécessitant une clé, et l'API anthropique pourrait ressembler:
MYSQL_ROOT_PASSWORD="my-password"
OPENAI_API_KEY="my-openai-key"
OPENAI_COMPATIBLE_KEY="my-api-key"
ANTHROPIC_API_KEY="my-anthropic-key"
Le fichier settings.yml configure Abbey pour utiliser les modèles et les options que vous souhaitez. Au minimum, vous devez utiliser au moins un modèle de langue et un modèle d'intégration. Mettez les meilleurs modèles en premier pour qu'Abbey les utilise par défaut. Par exemple, voici un fichier settings.yml qui utilise des modèles de l'API OpenAI officielle, une API compatible OpenAI, anthropic et olllay:
lms:
models:
- provider: anthropic
model: "claude-3-5-sonnet-20241022"
name: "Claude 3.5 Sonnet" # optional, give a name for Abbey to use
traits: "Coding" # optional, let Abbey display what it's good for
desc: "One of the best models ever!" # optional, let Abbey show a description
accepts_images: true # optional, put true if the model is a vision model / accepts image input
context_length: 200_000 # optional, defaults to 8192
- provider: openai_compatible
model: "gpt-4o"
accepts_images: true
context_length: 128_000
- provider: ollama
model: "llama3.2"
openai_compatible:
url: "http://host.docker.internal:1234" # Use host.docker.internal for services running on localhost
ollama:
url: "http://host.docker.internal:11434" # Use host.docker.internal for services running on localhost
embeds:
models:
- provider: "openai"
model: "text-embedding-ada-002"
Et étant donné que vous avez également mis les clés pertinentes dans .env , ce serait un fichier de paramètres complet. Pour configurer différents modèles, les moteurs de recherche, les services d'authentification, les modèles de texte vocale, etc .: Veuillez rechercher la documentation appropriée ci-dessous!
Étape 3: Si vous jouez toujours avec vos paramètres, vous pouvez exécuter Abbey en mode Dev en utilisant simplement:
docker compose up
En mode Dev, lorsque vous modifiez vos paramètres / secrets, il vous suffit de redémarrer les conteneurs pour obtenir vos paramètres à appliquer, ce qui peut être fait avec:
docker compose restart backend frontend celery db_pooler
Une fois que vous êtes prêt, vous pouvez exécuter Abbey en mode de production pour donner de meilleures performances:
docker compose -f docker-compose.prod.yml up --build
Si vous souhaitez modifier vos paramètres / secrets en mode prod, vous devez reconstruire les conteneurs:
docker compose down
docker compose -f docker-compose.prod.yml up --build
Étape 4: Maintenant, Abbey devrait fonctionner sur http://localhost:3000 ! Visitez simplement cette URL dans votre navigateur pour commencer à utiliser Abbey. En mode Dev, il pourrait prendre une seconde pour charger.
Notez que le backend fonctionne sur http://localhost:5000 - Si vous y allez, vous devriez voir une parole de Gilbert et Sullivan's HMS Pinafore. Sinon, le backend ne fonctionne pas.
Si quelque chose ne fonctionne pas correctement, veuillez (s'il vous plaît) déposer un problème ou contacter directement le créateur - @gkamer8 sur Twitter ou [email protected] par e-mail.
Par défaut, Abbey fonctionne sur localhost à Ports 3000 pour le frontend et 5000 pour le backend. Si vous souhaitez les modifier (puisque vous êtes assez averti en technologie), vous devrez modifier votre fichier Docker Compose, puis ajouter ceci à votre settings.yml :
services:
backend:
public_url: http://localhost:5000 # Replace with your new user-accessible BACKEND URL
internal_url: http://backend:5000 # This probably won't change - it's where the frontend calls the backend server side, within Docker
frontend:
public_url: http://localhost:3000 # Replace with your new user-accessible FRONTEND URL
Assurez-vous de mettre à jour votre fichier Docker Compose par, par exemple, en modifiant le mappage du port pour le backend à 1234: 5000, si vous modifiez le port. Assurez-vous de le commander pour le fichier Docker-Compose correct ( docker-compose.prod.yml pour les builds prod, docker-compose.yml pour dev). Voici à quoi cela ressemblerait pour le backend:
backend:
# ... some stuff
ports:
- "1234:5000" # now the backend is at http://localhost:1234 in my browser
# ... some stuff
Général: Assurez-vous que tous les conteneurs Docker fonctionnent réellement avec docker ps . Vous devriez voir 6: backend, frontend, céleri, redis, mysql et db_pooler (désolé qu'il y ait tellement - l'abbaye peut effectuer des tâches AI en arrière-plan et dans plusieurs fils, ce qui nécessite le Poader, Redis et les conteneurs de céleri). Si l'on ne fonctionne pas, essayez de le redémarrer avec docker compose restart backend (ou frontend, ou céleri, ou quoi avez-vous). S'il continue de s'écraser, il y a de fortes chances que vous ayez gâché vos settings.yml Ou avez oublié de mettre des secrets appropriés dans .env . Sinon, regardez les journaux.
Docker Config invalid: s'il vous dit que votre composition Docker est invalide, vous devez probablement mettre à niveau Docker sur votre machine vers quelque chose> = version 2. Abbey tire parti de certaines fonctionnalités docker relativement nouvelles telles que par défaut pour les variables et les profils Env. Il sera plus facile de mettre à niveau Docker à long terme - confiance.
Les choses semblent vides / ne chargez pas / les demandes du backend ne semblent pas fonctionner tout à fait correctement. Tout d'abord, accédez au backend dans le navigateur, comme pour http://localhost:5000 ou n'importe quelle URL que vous mettez à l'origine. Cela devrait vous donner un message comme "Un goudron britannique est une âme en plein essor ..." Si vous voyez cela, alors le backend est opérationnel, mais votre configuration d'URL du backend est erronée ou incomplète (jouez-vous avec?). Si votre backend n'exécute pas, consultez les journaux dans Docker pour plus d'informations - veuillez lire ce qu'ils disent!
Docker est coincé à télécharger / installer / exécuter une image. Il est possible que vous ne manquiez pas d'espace sur votre machine. Tout d'abord, essayez d'exécuter docker system prune pour nettoyer toutes les choses désagréables qui traînent dans Docker que vous avez oublié. Ensuite, essayez d'effacer l'espace sur votre ordinateur - peut-être assez pour ~ 10 Go sur votre machine. Ensuite, redémarrez Docker et réessayez. Si vous obtenez toujours des problèmes - essayez de désinstaller / réinstaller Docker.
La commande docker compose refuse d'exécuter à cause d'un problème "API" ou quelque chose. Si Docker est en cours d'exécution (Docker Desktop sur Mac, par exemple), vous devez le redémarrer. Si cela n'aide pas, essayez de purger / nettoyer ses données avant de redémarrer (cliquez sur l'icône "Bug" dans Docker Desktop si vous l'avez - alors voyez les données clean/purge ). Si Docker ne fonctionne pas, alors c'est votre problème! Vous devez vous assurer que le démon docker (c'est-à-dire Docker Desktop sur Mac) est en cours d'exécution.
Un port est déjà utilisé. Le backend Abbey s'exécute sur le port 5000 par défaut; L'Abbey Frontend fonctionne sur le port 3000. Il est possible que quelque chose sur votre ordinateur utilise déjà le port 5000 ou le port 3000. Sur Mac, cela signifie généralement AirPlay. Votre objectif devrait être de vérifier si quelque chose s'exécute sur les ports 3000 ou 5000 et, dans l'affirmative, pour fermer ces processus. Sur Mac / Linux: utilisez lsof -i :5000 ou lsof -i :3000 pour vérifier si un processus s'exécute sur ces ports. Si vous remarquez un processus comme «contrôle» en cours d'exécution sur Mac, cela signifie «Control Center», et c'est probablement une chose de récepteur Airplay. Vous pouvez accéder à vos paramètres système sur Mac et décocher le "récepteur AirPlay". Si vous avez trouvé autre chose, vous pouvez le tuer avec kill -9 YOUR_PID où YOUR_PID est remplacé par l'ID de processus (indiqué en utilisant LSOF). Sur Windows: Utilisez netstat -ano | findstr :5000 ou netstat -ano | findstr :3000 . Vous pouvez ensuite tuer le processus avec taskkill /PID YOUR_PID /F - remplacer YOUR_PID par l'ID de processus du processus pertinent.
Les intégrations tierces sont gérées dans vos paramètres et vos fichiers de variables d'environnement. Voici un résumé de ceux disponibles:
Modèles linguistiques (LMS)
Modèles d'intégration (intégres)
Text-vocation (TTS)
Reconnaissance de caractères optiques (OCR)
Moteurs de recherche (Web)
https://api.bing.microsoft.com/v7.0/search )Stockage de fichiers (stockage)
file-storage local (par défaut)Authentification
Certaines intégrations nécessitent une configuration dans les paramètres.yml. Si vous utilisez l'une des intégrations suivantes, vous devez spécifier ses paramètres comme tel:
s3:
bucket: 'your-bucket'
searxng:
url: "http://host.docker.internal:8080" # Replace with your URL
ollama:
url: "http://host.docker.internal:11434" # Replace with your URL
openai_compatible:
url: "http://host.docker.internal:12345" # Replace with your URL
Ceux-ci vont à la racine de settings.yml au même niveau que lms ou embeds .
Les modèles de langage sont configurés sous lms dans settings.yml . Vous pouvez spécifier des modèles linguistiques de tout fournisseur que vous souhaitez soutenir, ainsi que des valeurs par défaut qui sont utilisées dans les coulisses pour des choses comme la génération de quiz, les résumés et la suggestion de questions. Vous devez avoir au moins un LM pour Abbey pour fonctionner correctement. N'oubliez pas de configurer les paramètres du fournisseur pertinent si nécessaire comme illustré ci-dessus.
lms:
defaults: # all are optional, use the optional "code" you specify to refer to each model, or use "model-provider" like "gpt-4o-openai"
chat: "llama3.2-ollama" # User chat model (user can change) - defaults to first listed model
fast: "llama3.2-ollama" # Fastest model, used for suggested questions and other places - defaults to chat model
high_performance: "gpt-4o" # Your best language model, used for generating curricula - defaults to default chat model
long_context: "gpt-4o" # Model used in long-context situations - defaults to longest context model specified
balanced: "claude-3-5-sonnet-anthropic" # Model that is in the middle for speed / accuracy - defaults to default chat model
fast_long_context: "gpt-4o-mini-openai" # A long context model that's fast, defaults to long_context model, used for summaries / key points
alt_long_context: "claude-3-5-sonnet" # A long context model used for variation in things like question generation - default to long_context
models:
- provider: openai # required - see below table for options
model: "gpt-4o" # required, code for the API
context_length: 128_000 # optional (defaults to 4096)
supports_json: true # optional, defaults to false
accepts_images: true # optional, defaults to false
name: "GPT-4o" # optional display name for the model
desc: "One of the best models ever!" # optional, lets Abbey display a description
code: "gpt-4o" # optional - defaults to 'model-provider' like 'gpt-4o-openai' - used to specify defaults above.
disabled: false # optional
# Specify more in a list...
Ce tableau donne le code du fournisseur pour chaque fournisseur et le nom de clé API pertinent à placer dans .env :
| Fournisseur | Code du fournisseur | Nom de la clé API | Réglage des prestataires de besoins |
|---|---|---|---|
| Openai | Openai | Openai_api_key | Non |
| Anthropique | anthropique | Anthropic_api_key | Non |
| Ollla | ollla | Oui | |
| OpenAI compatible | Openai_Compatible | Openai_compatible_key | Oui |
Les modèles de texte vers la parole sont configurés sous tts dans settings.yml . Vous pouvez spécifier des modèles TTS à partir de tout fournisseur que vous souhaitez prendre en charge, plus une valeur par défaut. Les modèles TTS sont totalement facultatifs. N'oubliez pas de configurer les paramètres du fournisseur pertinent si nécessaire comme illustré ci-dessus.
tts:
default: "openai_onyx"
voices:
- provider: openai # required
voice: "onyx" # required
model: "tts-1" # required
name: "Onyx" # optional
desc: "One of the best models ever!" # optional
code: "openai_onyx" # optional, to set a default via a code (defaults to "voice-model-provider")
sample_url: "https://public-audio-samples.s3.amazonaws.com/onyx.wav" # optional
disabled: false # optional
| Fournisseur | Code du fournisseur | Nom de la clé API | Réglage des prestataires de besoins |
|---|---|---|---|
| Openai | Openai | Openai_api_key | Non |
| Elevenlabs | Eleven_labs | Eleven_labs_api_key | Non |
| OpenAI compatible | Openai_Compatible | Openai_compatible_key | Oui |
Les modèles d'intégration sont configurés sous embeds dans settings.yml . Pour l'instant, exactement un modèle d'incorporation obligatoire est utilisé à travers l'abbaye à la fois. Les modèles d'intégration sont utilisés pour rechercher des documents. N'oubliez pas de configurer les paramètres du fournisseur pertinent si nécessaire comme illustré ci-dessus.
embeds:
models:
- provider: "openai" # required
model: "text-embedding-ada-002" # required
| Fournisseur | Code du fournisseur | Nom de la clé API | Réglage des prestataires de besoins |
|---|---|---|---|
| Openai | Openai | Openai_api_key | Non |
| Ollla | ollla | Oui | |
| OpenAI compatible | Openai_Compatible | Openai_compatible_key | Oui |
Les moteurs de recherche sont configurés sous web dans settings.yml . Ils sont utilisés lorsque vous vérifiez Use Web lors du chat sur Abbey. N'oubliez pas de configurer les paramètres du fournisseur pertinent si nécessaire comme illustré ci-dessus.
web:
engines:
- provider: "bing" # required
# TO USE SEARXNG, MAKE SURE YOUR SEARXNG SETTINGS ARE CORRECT - SEE [BELOW](#searxng)
- provider: "searxng"
- engine: "pubmed" # Only used for SearXNG - leave blank to search over all engines you've enabled
- provider: "searxng"
engine: "arxiv"
use_pdf: true # Some SearXNG engines give PDF URLs - this tells Abbey to go to the PDF rather than the regular result
| Fournisseur | Code du fournisseur | Nom de la clé API | Réglage des prestataires de besoins |
|---|---|---|---|
| Bing | bing | Bing_api_key | Non |
| Searxng | searxng | Oui |
SEARXNG n'autorise pas par défaut l'accès à l'API. Lorsque vous exécutez votre instance SearXng, vous devez vous assurer que vos paramètres SearXng (pas dans Abbey's Repo, mais dans searxng/settings.yml ) permettent JSON en tant que format, comme:
search:
formats:
- html
- json
Vous pouvez vous assurer que votre instance SEARXNG fonctionne correctement lorsque la demande Curl suivante fonctionne (remplacer l'URL par votre URL d'instance SearXng - le port peut être différent.)
curl -kLX GET --data-urlencode q='abbey ai' -d format=json http://localhost:8080
Les API de reconnaissance de caractères optiques sont configurées sous ocr dans settings.yml . Par défaut, aucun OCR n'est utilisé. La configuration éventuellement de l'OCR permet à Abbey de lire les PDF numérisés. Abbey détermine automatiquement si l'OCR semble nécessaire.
ocr:
models:
- provider: "mathpix"
| Fournisseur | Code du fournisseur | Noms de clés de l'API | Réglage des prestataires de besoins |
|---|---|---|---|
| Mathpix | mathpix | Mathpix_API_App et Mathpix_API_KEY | Non |
Les API par e-mail sont configurées sous email dans settings.yml . La configuration de l'e-mail permet à Abbey d'envoyer des liens vers des actifs sur Abbey lorsqu'ils sont partagés, plus dans quelques autres circonstances. Par défaut, Abbey n'envoie pas de courriels. L'exécution d'Abbey avec le profil de messagerie (comme docker compose up --profile email ) permet à Abbey d'envoyer des e-mails de rappel supplémentaires pour certains modèles.
email:
default: smtp # Refer to each service by its provider name (defaults to first specified)
services:
- provider: sendgrid # Required
email: "[email protected]" # Required
unsub_group: 24624 # Optional, only for Sendgrid
- provider: smtp # Regular email
email: "[email protected]"
| Fournisseur | Code du fournisseur | Secrets obligatoires | Réglage des prestataires de besoins |
|---|---|---|---|
| Sendgrid | sendgrid | Sendgrid_api_key | Non |
| Email SMTP | smtp | Smtp_server, smtp_port, smtp_email et smtp_password | Non |
Les API de stockage de fichiers sont configurées sous storage dans settings.yml . Par défaut, Abbey stocke tous les fichiers téléchargés dans le dossier file-storage monté. Lorsque vous sauvegardez Abbey, vous devez sauvegarder ce dossier plus la base de données. Si vous souhaitez utiliser S3, vous pouvez utiliser ce qui suit:
storage:
default: s3 # All new uploads go to the default provider (you don't need to set up local)
locations:
- provider: s3
| Fournisseur | Code du fournisseur | Noms de clés de l'API | Réglage des prestataires de besoins |
|---|---|---|---|
| S3 | S3 | Aws_access_key et aws_secret_key | Non |
| Locale | locale | Non |
Les fournisseurs d'authentification sont configurés sous auth dans settings.yml . Par défaut, Abbey utilisera un seul utilisateur "par défaut". La configuration des fournisseurs d'authentification supplémentaires permet des configurations multi-utilisateurs. Vous pouvez utiliser un fournisseur OAuth2 comme Google, ou vous pouvez auto-héberger une instance KeyCloak (instructions ci-dessous). Pour les fournisseurs comme Google et GitHub, vous aurez besoin d'un secret client et d'un identifiant client. Lorsque vous enregistrez Abbey, vous devrez peut-être fournir l'URL où l'abbaye est accessible - ce serait http://localhost:3000 par défaut, ou quelle que soit l'URL publique que vous utilisez pour le frontend d'Abbey.
auth:
providers:
- google
- github
- keycloak
| Fournisseur | Code du fournisseur | Variables Env | Comment acquérir l'identification du client / secret |
|---|---|---|---|
| Google_client_id et google_secret | Voir ici | ||
| Github | github | Github_client_id et github_secret | Voir ici |
| Keycloak | keycloak | Keycloak_public_url, keycloak_internal_url, keycloak_realm, keycloak_secret et keycloak_client_id | Voir ci-dessous |
Dans les environnements de production, vous devriez également fournir des secrets d'autheurs supplémentaires pour la manipulation des jetons AUTH. Faites-le en ajoutant ce qui suit à votre fichier d'environnement:
CUSTOM_AUTH_SECRET="my-auth-secret"
REFRESH_TOKEN_SECRET="my-refresh-secret"
Vous pouvez l'authentification auto-hébergée entièrement à l'aide de Keyycloak. L'utilisation de KeyCloak avec Abbey nécessite certains paramètres - par exemple, une URL frontale pour le royaume doit être spécifiée pour permettre à Abbey et Keycloak d'exécuter dans le même Docker VM. Si vous avez une instance KeyCloak existante, vous devez créer un nouveau client pour Abbey avec un ID client et un secret client dans lequel vous placez .env . Sinon, voici les instructions mettent en place une nouvelle instance pour Abbey:
Voici un fichier keycloak-realm.json que vous pouvez placer à côté de votre fichier docker-compose qui configure automatiquement Keyycloak:
{
"realm": "abbey-realm",
"enabled": true,
"loginWithEmailAllowed": true,
"duplicateEmailsAllowed": false,
"registrationEmailAsUsername": true,
"attributes": {
"frontendUrl": "http://localhost:8080"
},
"clients": [
{
"clientId": "abbey-client",
"enabled": true,
"protocol": "openid-connect",
"publicClient": false,
"secret": "not-a-secret",
"redirectUris": ["http://localhost:3000/*"]
}
],
"users": [
{
"username": "[email protected]",
"email": "[email protected]",
"enabled": true,
"emailVerified": true,
"credentials": [
{
"type": "password",
"value": "password"
}
]
}
]
}
Voici un exemple de service que vous pouvez exécuter à côté de celui dans votre fichier docker-compose.yml :
services:
keycloak:
image: quay.io/keycloak/keycloak:22.0.3
container_name: keycloak
environment:
KEYCLOAK_ADMIN: admin
KEYCLOAK_ADMIN_PASSWORD: admin
ports:
- 8080:8080
volumes:
- ./keycloak-realm.json:/opt/keycloak/data/import/myrealm.json
command: ["start-dev", "--import-realm"]
volumes:
keycloak_data:
Keycloak nécessite également quelques secrets supplémentaires dans .env :
# The Public URL should be user accessible
KEYCLOAK_PUBLIC_URL="http://localhost:8080"
# The optional Internal URL should be accessible within Docker
KEYCLOAK_INTERNAL_URL="http://keycloak:8080"
KEYCLOAK_REALM="abbey-realm"
KEYCLOAK_SECRET="not-a-secret"
KEYCLOAK_CLIENT_ID="abbey-client"
L'ajout de service + création du fichier keycloak-realm.json + entrant des secrets dans .env devrait permettre à Abbey de "travailler" avec Keycloak dans un environnement de développement.
Par défaut, Abbey a un service MySQL pour lequel vous devez fournir un MYSQL_ROOT_PASSWORD dans .env . Abbey utilise deux bases de données, custom_auth pour l'authentification et learn pour tout le reste. Ils peuvent être sur les mêmes serveurs ou différents. À partir de maintenant, le serveur doit être compatible MySQL ou MySQL (pas Postgres).
Vous pouvez modifier où le serveur MySQL est disponible, en utilisant ces variables .env :
MYSQL_ROOT_PASSWORD=my-root-password
# Remember that the endpoint is accessed server side, so "mysql" is the default network name
DB_ENDPOINT=mysql
DB_USERNAME=root
DB_PASSWORD=my-root-password
DB_PORT=3306
DB_NAME=learn
DB_TYPE=local # 'local' or 'deployed' --> changes how app deals with transaction settings
# You should set global transaction isolation level to READ COMMITTED when using your own database
CUSTOM_AUTH_DB_ENDPOINT=mysql
CUSTOM_AUTH_DB_USERNAME=root
CUSTOM_AUTH_DB_PASSWORD=my-root-password
CUSTOM_AUTH_DB_PORT=3306
CUSTOM_AUTH_DB_NAME=custom_auth
Lorsque le service MySQL par défaut est démarré, il s'initialisera à l'aide des fichiers dans mysql-init . Si vous configurez votre propre service MySQL, vous avez inauguré les bases de données / tables pertinentes en exécutant ces fichiers .sql (copier et coller dans un terminal serait suffisant).
Vous remarquerez peut-être que sur la page d'accueil (lorsqu'elle est connectée), le côté droit a une image et une description. Lors de l'initialisation de la base de données, il y a une image qui y apparaîtra par défaut (qui est hébergée sur Internet). Pour changer cette image ou pour en ajouter plus, vous devez ajouter des entrées à la table ART_HISTORY dans la base de données Learn (sur le service MySQL). Là, vous mettez une URL pour l'image et la marque de la description. Le (s) domaine (s) où l'image est hébergée doit également être incluse dans settings.yml , comme tel:
images:
domains:
- "my-domain.com"
Pour ajouter l'entrée dans art_history, vous devez exécuter un SQL. Avec Docker-Compose, vous pouvez utiliser:
docker-compose exec mysql mysql -u root -p
puis utilisez votre mot de passe root MySQL (disponible dans le fichier .env situé à la racine du projet). Ensuite, vous devrez exécuter:
use learn;
INSERT INTO art_history (`markdown`, `image`)
VALUES ('This is my *description*', 'https://my-domain.com/image.webp');
Une image est sélectionnée au hasard pour afficher à partir de ce tableau art_history .
Vous pouvez modifier le nom d'Abbey en ce que vous aimez en utilisant cette option dans settings.yml :
name: "Abbey" # Replace with your chosen name
D'autres marques tels que Logos, Favicons, etc. sont situés en frontend/public . Vous pouvez les modifier en remplaçant les fichiers (mais en gardant leurs noms). Les images d'arrière-plan sont dans le dossier frontend/public/random .
Par défaut, Abbey aura un cinglé une URL codé en dur lorsque le backend démarre et chaque heure par la suite. Ceci est fait pour suivre les statistiques d'utilisation. La version backend sur laquelle vous vous trouvez et vos settings.yml sont incluses dans le ping. Pour désactiver le ping, mettez ce qui suit dans vos settings.yml :
ping: false
Comme je ne peux pas faire la différence entre un utilisateur qui a défini ping: false et un utilisateur qui a cessé d'utiliser Abbey, envisagez de contacter [email protected] afin que je puisse obtenir un nombre approximatif d'utilisateurs qui désactivent le ping.
L'une des principales forces d'Abbey est son extensibilité. Vous pouvez implémenter de nouvelles intégrations et interfaces directement.
Chaque type d'intégration sauf pour Auth (voir les notes ci-dessous) réside dans un fichier dans backend/app/integrations . Chaque type d'intégration implémente une classe spécifique (par exemple, lm.py donne une classe LM, et chaque type d'intégration implémente cette classe). Vous pouvez simplement ajouter une classe qui hérite de la classe de base (LM, TTS, OCR, etc.). Ensuite, vous devez ajouter votre classe au dictionnaire PROVIDER_TO_ (il y en a un différent pour chaque type d'intégration). Pour les intégrations qui peuvent être choisies par l'utilisateur, elle devrait automatiquement apparaître une fois que la modification appropriée a été apportée dans settings.yml (par exemple, un utilisateur peut sélectionner son moteur de recherche, son modèle de langue et son modèle de texte à dispection). Pour les intégrations comme embed qui sont choisies par Abbey par défaut, vous devez vous assurer que votre intégration est la valeur par défaut de settings.yml .
Si votre intégration repose sur des secrets, vous devez l'ajouter à backend/app/configs/secrets.py en utilisant le modèle spécifié, puis l'importez-le dans le fichier d'intégration (par exemple, lm.py ).
Contrairement aux autres intégrations, si vous ajoutez simplement un fournisseur OAuth2, il n'y a en fait aucune raison de faire quoi que ce soit sur le backend Flask. Le serveur Frontend suivant NEXT.js gère tout. Ce que vous devez faire est:
frontend/src/pages/api/auth/[...auth].js . L'exemple le plus simple est la classe GoogleAuth (Extension Basauth) qui fournit trois URL: un point de terminaison OAuth2 Auth; un point de terminaison de jeton OAuth2; et un point de terminaison d'informations utilisateur OpenID Connect. Étant donné que GitHub n'implémente pas la connexion OpenID standard, il implémente directement la fonction getUserData ().authProviders en fonction de la disponibilité des secrets.frontend/src/auth/custom.js . Tout d'abord, cela signifie pousser à enabledProviders le code de votre nouveau fournisseur conditionnellement en fonction de la définition d'une variable d'environnement sur 1 (la variable d'environnement doit commencer par next_public afin qu'elle soit disponible en côté client). Deuxièmement, cela signifie l'ajout d'un objet à la liste providers spécifiant le code de votre fournisseur et la valeur de bouton (vous pouvez ajouter le logo de votre fournisseur en suivant le modèle et en ajoutant le logo à frontend/public/random ). Une note sur les moteurs de recherche: certaines fonctions de classe pour un moteur de recherche renvoient les objets de recherche personnalisés; Les classes pertinentes sont implémentées dans web.py , et vous devriez jeter un œil si vous choisissez d'implémenter une nouvelle intégration du moteur de recherche.
Dans Abbey, tout est un "actif", et chaque actif implémente un "modèle". Par exemple, si vous téléchargez un document, il devient un "actif" de document de modèle. De même, si vous créez un nouvel espace de travail, il devient un "actif" de notebook de modèle (le nom interne d'un espace de travail). Sur le frontend, l'interface fournie à un utilisateur est déterminée par le modèle qu'il regarde. Il existe une littéraine de variables communes qui doivent être définies pour chaque modèle (par exemple, si le modèle est autorisé à discuter, s'il est dans un dossier ou quelque chose comme ça). Ces variables et fonctions implémentées déterminent, entre autres, la façon dont les points de terminaison généraux comme /asset/chat se comportent.
Sur le backend, tous les modèles sont des classes qui héritent de la classe de base Template . Ces modèles sont situés dans leurs propres fichiers dans backend/app/templates . Les modèles sont enregistrés dans backend/app/templates.py . Vous devez y ajouter une instance de votre modèle afin de l'activer. Vous devez également ajouter le modèle à backend/app/configs/user_config.py . À l'intérieur d'un modèle, un fichier peut également être des points de terminaison spécifiques pour ce modèle; Si vous choisissez d'en créer un, il doit être enregistré en backend/app/__init__.py .
Sur le frontend, tous les modèles sont implémentés dans un seul fichier, frontend/src/template.js . Chaque modèle il y a une classe qui hérite de la classe Template . Au bas du fichier, il existe différentes listes et objets qui déterminent la disponibilité du modèle; Vous devez au moins ajouter votre modèle à l'objet TEMPLATES pour le mettre à la disposition des utilisateurs.
Certains modèles sont comme des feuilles; Par exemple, les documents n'ont pas de sources d'actifs liées, ce qui signifie que lorsque vous discutez avec un document, vous ne discutez vraiment qu'avec ce seul document. D'autres modèles ont lié des sources. Par exemple, le contenu d'un dossier est un actif lié. Ce système existe pour d'autres modèles comme l'éditeur de texte, qui peut trouver du matériel provenant d'autres actifs avec sa fonctionnalité d'écriture AI. L'utilisation de sources de manière cohérente garantit que la fonctionnalité qui s'étend à travers les modèles, comme le partage des actifs, reste fonctionnelle. Si vous partagez un dossier avec quelqu'un, par exemple, les autorisations se propagent à tous les éléments à l'intérieur de ce dossier.
Le moyen standard de récupérer des informations sur les sources d'un actif sur le frontend est avec le point de terminaison /assets/sources-info . La façon standard d'ajouter une source à un actif est avec les points de terminaison /assets/add-resource et /assets/add-resources . Ces points de terminaison recherchent une entrée dans la table asset_metadata avec Key retrieval_source dont la valeur est un ID d'actif. Voir plus de détails sur ces points de terminaison dans backend/app/assets.py .
