abbey
1.0.0
Abbeyは、ノートブック、基本的なチャット、ドキュメント、YouTubeビデオなどを備えたAIインターフェイスです。プライベート自己ホストパッケージにさまざまなAIモデルを組織します。独自の認証プロバイダーを使用して、複数のユーザーのサーバーとしてAbbeyを実行することも、自分のマシンで自分で実行することもできます。修道院は、選択したLLM、TTSモデル、OCRモデル、および検索エンジンを使用して、高度に構成可能です。ここでは、多くの学生や専門家が使用しているAbbeyのホストバージョンを見つけることができます。
何か問題がありますか？お願いします、問題を投稿するか、作成者に直接連絡してください！ Twitter dm @gkamer8、gordon @us.aiにメールするか、そうでなければ彼をpingしてください - 彼はそれが好きです。
Abbeyがデフォルトで好みに合わせて構成できず、コードを書くのが快適である場合は、改善でPRを開くことを検討してください。新しい統合や完全なインターフェイスを追加することは簡単です。詳細については、以下の「貢献」セクションをご覧ください。
docker composeをインストールする必要があります。こちらの詳細をご覧ください。Abbeyの以前のバージョンがあり、settings.ymlで「新しいインストール」パターンを初めて実行している場合は、以下に説明するように新しいsettings.ymlおよび.envを作成し、backend/app/staticからファイルストレージに移動し、-buildで再構築します。
セットアップでは、このレポをクローニング/ダウンロードし、選択したAI統合を使用して.envおよびsettings.ymlファイルを作成し、 docker compose 。ここにステップがあります：
ステップ1：このリポジトリをクローン /ダウンロードして、その内側にナビゲートします。
ステップ2： secretキー用の.envと呼ばれるファイルと、 settings.ymlのファイルを作成します。レポのルート（つまり、 docker-compose.ymlファイルと同じレベルで）。次に、それらのファイルに使用したいキー /モデルを入力します。このREADME全体で各タイプの統合を構成する方法の詳細を見つけることができます。
.envファイルは、必要なAPIキーまたはその他の秘密を保持します。また、Abbeyが使用するMySQLデータベースのパスワードも含める必要があります。公式Openai APIを使用している人のための.envファイル、キーを必要とするOpenAI互換API、および人類APIは次のように見える場合があります。
MYSQL_ROOT_PASSWORD="my-password"
OPENAI_API_KEY="my-openai-key"
OPENAI_COMPATIBLE_KEY="my-api-key"
ANTHROPIC_API_KEY="my-anthropic-key"
settings.ymlファイルは、必要なモデルとオプションを使用するようにAbbeyを構成します。少なくとも、少なくとも1つの言語モデルと1つの埋め込みモデルを使用する必要があります。アビーがデフォルトでそれらを使用するように、最高のモデルを最初に置きます。たとえば、OpenAI互換API、人類、およびOllama：Openai APIのモデルを使用するsettings.ymlファイルは次のとおりです。
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"
また、関連するキーも.envに入れていることを考えると、それは完全な設定ファイルになります。さまざまなモデル、検索エンジン、認証サービス、テキストツースピーチモデルなどを構成するには：以下の適切なドキュメントを探してください！
ステップ3：まだ設定を使用して遊んでいる場合は、次を使用してAbbeyをDevモードで実行できます。
docker compose up
開発モードでは、設定 /秘密を変更する場合、設定を適用するためにコンテナを再起動するだけです。
docker compose restart backend frontend celery db_pooler
準備ができたら、生産モードで修道院を実行してパフォーマンスを向上させることができます。
docker compose -f docker-compose.prod.yml up --build
Prodモードで設定 /秘密を変更する場合は、コンテナを再構築する必要があります。
docker compose down
docker compose -f docker-compose.prod.yml up --build
ステップ4：今、修道院はhttp://localhost:3000で実行する必要があります！ブラウザのそのURLにアクセスして、Abbeyの使用を開始してください。開発モードでは、ロードに1秒かかる場合があります。
バックエンドはhttp://localhost:5000で実行されることに注意してください。そこに行くと、ギルバートとサリバンのHMS Pinaforeの歌詞が表示されるはずです。そうでない場合は、バックエンドが実行されていません。
何かが正しく機能していない場合は、（お願いします）問題を提出するか、作成者に直接連絡してください - @gkamer8でtwitterまたは[email protected]で電子メールで。
デフォルトでは、Abbeyは、Frontendの場合はPorts 3000のLocalHost、バックエンドで5000で実行されます。これらを変更したい場合（あなたはかなりテクノロジーに精通しているので）、Docker Composeファイルを変更してから、これを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
ポートを変更する場合、バックエンドのポートマッピングを1234：5000に変更するなどして、Docker Composeファイルを必ず更新してください。必ず正しいDocker-Composeファイル（ docker-compose.prod.yml for prod builds、 docker-compose.yml for dev）に切り替えてください。これがバックエンドにとってどのように見えるかです：
backend:
# ... some stuff
ports:
- "1234:5000" # now the backend is at http://localhost:1234 in my browser
# ... some stuff
一般：すべてのDockerコンテナが実際にdocker psで実行されていることを確認してください。 6：バックエンド、フロントエンド、セロリ、レディス、MySQL、およびdb_poolerが表示されます（非常に多数あります - アビーはバックグラウンドと複数のスレッドでAIタスクを実行できます。実行されていない場合は、 docker compose restart backendください。クラッシュし続ける場合、 settings.ymlを台無しにしたり、適切な秘密を.envに入れるのを忘れてしまった可能性があります。それ以外の場合は、ログを見てください。
Dockerの構成無効：Docker Composeが無効であることを伝えている場合、おそらくマシンのDockerを何かにアップグレードする必要があります> =バージョン2。Abbeyは、env変数やプロファイルのデフォルトなど、特定の比較的新しいDocker機能を利用します。長期的にはDockerをアップグレードするだけで、信頼しやすくなります。
物事は空白に見えます /バックエンドへのロード /リクエストはまったく正しく動作しないようです。まず、 http://localhost:5000などのURLを元々に入れたように、ブラウザのバックエンドに移動します。 「ブリティッシュタールは急上昇する魂です...」などのメッセージを提供するはずです。それを見ると、バックエンドが稼働していますが、バックエンドのURL設定が間違っていますか、それとも不完全です（あなたはそれで遊んでいましたか？）。バックエンドが実行されていない場合は、詳細についてはDockerのログを確認してください。彼らの言うことをお読みください！
Dockerは、画像のダウンロード/インストール/実行に陥ります。マシンのスペースが足りなくなる可能性があります。まず、 docker system pruneアップしてみてください。次に、コンピューターのスペースをクリアしてみてください。おそらく、マシンで〜10GBで十分です。次に、Dockerを再起動して再試行します。それでも問題が発生した場合は、Dockerのアンインストール /再インストールを試してみてください。
docker composeコマンドは、「API」の問題などのために実行を拒否します。 Dockerが実行されている場合（たとえば、MacのDockerデスクトップ）、再起動する必要があります。それが役に立たない場合は、再起動する前にデータをパージ/クリーニングしてみてください（Dockerデスクトップで「バグ」アイコンをクリックしてください。次に、 clean/purgeデータを参照してください）。 Dockerが実行されていない場合、それがあなたの問題です！ Dockerデーモン（つまり、MacのDockerデスクトップ）が実行されていることを確認する必要があります。
ポートはすでに使用されています。修道院のバックエンドは、デフォルトでポート5000で実行されます。修道院のフロントエンドはポート3000で実行されます。コンピューター上の何かがすでにポート5000またはポート3000を使用している可能性があります。あなたの目標は、ポート3000または5000で動作しているものを確認すること、そしてもしそうなら、それらのプロセスをシャットダウンすることです。 Mac/Linuxで： lsof -i :5000またはlsof -i :3000を使用して、それらのポートでプロセスが実行されているかどうかを確認します。 Macで実行されている「Controlce」のようなプロセスに気付いた場合、それは「コントロールセンター」を意味し、おそらくAirPlay Receiverのものです。 Macのシステム設定に移動して、「AirPlay Receiver」をチェックすることができます。何か他のものを見つけた場合、あなたはYOUR_PIDがプロセスID（LSOFを使用して表示）に置き換えられるkill -9 YOUR_PIDでそれを殺すことができます。 Windowsで： netstat -ano | findstr :5000を使用しますnetstat -ano | findstr :5000またはnetstat -ano | findstr :3000 。その後、 taskkill /PID YOUR_PID /Fでプロセスを殺すことができます - 関連プロセスのプロセスIDにYOUR_PID置き換えます。
サードパーティの統合は、設定および環境変数ファイルで管理されます。これが利用可能なものの要約です：
言語モデル（LMS）
埋め込みモデル（埋め込み）
テキストツースピーチ（TTS）
光学文字認識（OCR）
検索エンジン（Web）
https://api.bing.microsoft.com/v7.0/searchを使用）ファイルストレージ（ストレージ）
file-storageフォルダー（デフォルト）認証
一部の統合では、settings.ymlで構成が必要です。次の統合のいずれかを使用する場合は、次のような設定を指定する必要があります。
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
これらは、 lmsまたはembedsと同じレベルでsettings.ymlのルートに移動します。
言語モデルは、 settings.ymlのlmsで構成されています。サポートしたいプロバイダーから言語モデルを指定できます。さらに、クイズの世代、要約、提案のような質問のために舞台裏で使用されるデフォルトを指定できます。修道院が適切に機能するには、少なくとも1つのLMが必要です。上記のように、必要に応じて関連するプロバイダーの設定を構成することを忘れないでください。
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...
このテーブルは、各プロバイダーのプロバイダーコードと、 .envに配置する関連するAPIキー名を提供します。
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| Openai | Openai | openai_api_key | いいえ |
| 人類 | 人類 | Anthropic_api_key | いいえ |
| オラマ | オラマ | はい | |
| Openai互換性 | openai_compatible | openai_compatible_key | はい |
テキストから音声モデルは、 settings.ymlのttsで構成されています。サポートしたいプロバイダーからTTSモデルを指定し、デフォルトを指定できます。 TTSモデルは完全にオプションです。上記のように、必要に応じて関連するプロバイダーの設定を構成することを忘れないでください。
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
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| Openai | Openai | openai_api_key | いいえ |
| evelenlabs | Eleven_labs | Eleven_labs_api_key | いいえ |
| Openai互換性 | openai_compatible | openai_compatible_key | はい |
埋め込みモデルは、 settings.ymlのembedsの下で構成されています。今のところ、正確に1つの必須の埋め込みモデルが一度に修道院全体で使用されています。埋め込みモデルは、ドキュメントを検索するために使用されます。上記のように、必要に応じて関連するプロバイダーの設定を構成することを忘れないでください。
embeds:
models:
- provider: "openai" # required
model: "text-embedding-ada-002" # required
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| Openai | Openai | openai_api_key | いいえ |
| オラマ | オラマ | はい | |
| Openai互換性 | openai_compatible | openai_compatible_key | はい |
検索エンジンは、 settings.ymlでwebで構成されています。 AbbeyでチャットするときにUse Web確認するときに使用されます。上記のように、必要に応じて関連するプロバイダーの設定を構成することを忘れないでください。
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
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| ビング | ビング | bing_api_key | いいえ |
| searxng | searxng | はい |
searxngは、デフォルトではAPIアクセスを許可していません。 searxngインスタンスを実行するときは、searxngの設定（修道院のレポではなく、 searxng/settings.yml ）であることを確認する必要があります。
search:
formats:
- html
- json
次のCurlリクエストが機能する場合、Searxngインスタンスが正しく機能していることを確認できます（URLをSearxngインスタンスURLに置き換えます - ポートが異なる場合があります。）
curl -kLX GET --data-urlencode q='abbey ai' -d format=json http://localhost:8080
光学文字認識APIは、 settings.ymlのocrの下で構成されています。デフォルトでは、OCRは使用されません。オプションでOCRの構成により、AbbeyはスキャンされたPDFを読み取ることができます。 Abbeyは、OCRが必要かどうかを自動的に決定します。
ocr:
models:
- provider: "mathpix"
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| Mathpix | Mathpix | Mathpix_api_appおよびMathpix_api_key | いいえ |
電子メールAPIは、 settings.ymlのemailで構成されています。電子メールの構成により、Abbeyは共有されているときにAbbeyの資産へのリンクを送信できます。デフォルトでは、Abbeyはメールを送信しません。電子メールプロファイルで修道院を実行している（ docker compose up --profile emailなど）、Abbeyはいくつかのテンプレートに追加のリマインダーメールを送信できます。
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]"
| プロバイダー | プロバイダーコード | 必須の秘密 | プロバイダーの設定が必要です |
|---|---|---|---|
| sendgrid | sendgrid | sendgrid_api_key | いいえ |
| SMTPメール | SMTP | SMTP_SERVER、SMTP_PORT、SMTP_EMAIL、およびSMTP_PASSWORD | いいえ |
ファイルストレージAPIは、 settings.ymlのstorageで構成されています。デフォルトでは、Abbeyはすべてのアップロードされたファイルをマウントされたfile-storageフォルダーに保存します。修道院をバックアップするときは、そのフォルダーとデータベースをバックアップする必要があります。 S3を使用する場合は、以下を使用できます。
storage:
default: s3 # All new uploads go to the default provider (you don't need to set up local)
locations:
- provider: s3
| プロバイダー | プロバイダーコード | APIキー名 | プロバイダーの設定が必要です |
|---|---|---|---|
| S3 | S3 | AWS_ACCESS_KEYおよびAWS_SECRET_KEY | いいえ |
| 地元 | 地元 | いいえ |
認証プロバイダーは、 settings.ymlのauthの下で構成されています。デフォルトでは、Abbeyは単一の「デフォルト」ユーザーを使用します。追加の認証プロバイダーを設定すると、マルチユーザーのセットアップが可能になります。 GoogleなどのOAUTH2プロバイダーを使用するか、keycloakインスタンスを自己ホストすることもできます（以下の手順）。 GoogleやGithubなどのプロバイダーには、クライアントの秘密とクライアントIDが必要です。 Abbeyを登録する場合、AbbeyがアクセスできるURLを提供する必要がある場合があります。これは、デフォルトでhttp://localhost:3000 、またはAbbeyのフロントエンドに使用しているパブリックURLです。
auth:
providers:
- google
- github
- keycloak
| プロバイダー | プロバイダーコード | env変数 | クライアントID /秘密を取得する方法 |
|---|---|---|---|
| グーグル | グーグル | Google_client_idおよびgoogle_secret | こちらをご覧ください |
| github | github | github_client_idおよびgithub_secret | こちらをご覧ください |
| keycloak | keycloak | keycloak_public_url、keycloak_internal_url、keycloak_realm、keycloak_secret、およびkeycloak_client_id | 以下を参照してください |
生産環境では、AUTHトークンを処理するための追加の認証秘密も提供する必要があります。環境ファイルに以下を追加して、次のことを行います。
CUSTOM_AUTH_SECRET="my-auth-secret"
REFRESH_TOKEN_SECRET="my-refresh-secret"
Keycloakを使用して完全に認証を自己ホストできます。 Abbeyを使用してKeycloakを使用するには、特定の設定が必要です。たとえば、AbbeyとKeycloakが同じDocker VMで実行できるように、レルムのフロントエンドURLを指定する必要があります。既存のKeyCloakインスタンスがある場合は、 .envに配置するクライアントIDとクライアントの秘密を備えたAbbey用の新しいクライアントを作成する必要があります。それ以外の場合は、ここに、Abbeyの新しいインスタンスを設定しています。
keycloak-realm.jsonファイルは、keycloakを自動的にセットアップするdocker-composeファイルの隣に配置できます。
{
"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"
}
]
}
]
}
以下は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には、 .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"
そのサービス + keycloak-realm.jsonファイルの作成 + .envに秘密を入力することで、Abbeyが開発環境でKeyCloakで「機能する」ことを可能にするはずです。
デフォルトでは、AbbeyにはMySQLサービスがあり、 MYSQL_ROOT_PASSWORDを.envで提供する必要があります。 Abbeyは、認証のためにcustom_auth 2つのデータベースを使用し、他のすべてについてlearn 。それらは同じまたは異なるサーバー上にあります。現在のところ、サーバーはMySQLまたはMySQL互換である必要があります（ポストグレスではありません）。
これらの.env変数を使用して、MySQLサーバーが利用可能な場所を変更できます。
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
デフォルトのMySQLサービスが開始されると、 mysql-init内のファイルを使用して初期化します。独自のMySQLサービスを設定すると、それらの.sqlファイルを実行して、関連するデータベース /テーブルを初期化します（コピーして端末に貼り付けても十分です）。
ホームページ（サインイン）には、右側に画像と説明があることに気付くかもしれません。データベースの初期化には、デフォルトで表示される画像が1つあります（インターネットでホストされています）。その画像を変更したり、さらに追加するには、LearnデータベースのART_Historyテーブルにエントリを追加する必要があります（MySQLサービス）。そこでは、画像用のURLを配置し、説明にマークダウンします。画像がホストされているドメインは、 settings.ymlなどにも含める必要があります。
images:
domains:
- "my-domain.com"
ART_HISTORYにエントリを追加するには、SQLを実行する必要があります。 Docker-Composeを使用すると、以下を使用できます。
docker-compose exec mysql mysql -u root -p
次に、MySQLルートパスワード（プロジェクトのルートにある.ENVファイルで使用できます）を使用します。次に、実行する必要があります。
use learn;
INSERT INTO art_history (`markdown`, `image`)
VALUES ('This is my *description*', 'https://my-domain.com/image.webp');
画像がランダムに選択されて、そのart_historyテーブルから表示されます。
Abbeyの名前をsettings.ymlでこのオプションを使用して好きなものに変更できます。
name: "Abbey" # Replace with your chosen name
ロゴ、ファビコンなどの他のブランディングはfrontend/publicにあります。ファイルを交換する（ただし、名前を保持する）ことで変更できます。背景画像はfrontend/public/randomフォルダーにあります。
デフォルトでは、バックエンドが起動したときにハードコーディングされたURLをpingし、その後1時間になります。これは、使用統計を追跡するために行われます。あなたがオンになっているバックエンドバージョンに加えて、 settings.ymlはpingに含まれています。 pingを無効にするには、 settings.ymlに次のものを置きます。
ping: false
ping: falseを設定しているユーザーとAbbeyの使用を停止したユーザーの違いはわかりませんので、[email protected]に連絡することを検討してください。
修道院の主な強みの1つは、その拡張性です。新しい統合とインターフェイスを簡単に実装できます。
AUTHを除く各タイプの統合（下記の注を参照）はbackend/app/integrationsのファイルにあります。統合の各タイプは特定のクラスを実装します（たとえば、 lm.py LMクラスを提供し、各タイプの統合はそのクラスを実装します）。基本クラス（LM、TTS、OCRなど）から継承するクラスを追加するだけです。次に、クラスをPROVIDER_TO_ Dictionaryに追加する必要があります（統合の種類ごとに異なるものがあります）。ユーザーが選択できる統合の場合、 settings.yml （たとえば、ユーザーは検索エンジン、言語モデル、テキストツースピックモデルを選択できます）で適切な変更が行われたら、自動的にポップアップする必要があります。デフォルトでAbbeyによって選択されるembedのような統合の場合、統合がsettings.ymlのデフォルトであることを確認する必要があります。
統合がシークレットに依存している場合は、指定されたパターンを使用してbackend/app/configs/secrets.pyに追加して、統合ファイル（例： lm.py ）にインポートする必要があります。
他の統合とは異なり、OAUTH2プロバイダーを追加するだけである場合、実際にはフラスコバックエンドで何もする理由はありません。 Next.js Frontendサーバーはすべてを処理します。あなたがする必要があるのは：
frontend/src/pages/api/auth/[...auth].jsでプロバイダークラスを作成します。最も単純な例は、3つのURLを提供するGoogleAuthクラス（Baseauth）です。OAUTH2AUTHエンドポイント。 OAuth2トークンエンドポイント。 OpenID Connectユーザー情報エンドポイント。 GitHubは標準のOpenID Connectを実装していないため、getuserdata（）関数を直接実装します。authProviders変数に条件付きで追加します。frontend/src/auth/custom.jsのプロバイダーのフロントエンドログインボタンを作成します。第一に、それは環境変数が1に設定されているかどうかに基づいて、新しいプロバイダーのコードを条件付きでenabledProvidersことを意味します（環境変数は、クライアント側にあるようにnext_publicで開始する必要があります）。次に、プロバイダーコードとボタン値を指定するprovidersリストにオブジェクトを追加することを意味します（パターンに従ってロゴをfrontend/public/randomに追加することで、プロバイダーのロゴを追加できます）。 検索エンジンに関する1つのメモ：検索エンジンの一部のクラス機能カスタム検索オブジェクトを返します。関連するクラスはweb.pyで実装されており、新しい検索エンジン統合を実装することを選択した場合は、確認する必要があります。
修道院では、すべてが「資産」であり、すべての資産が「テンプレート」を実装しています。たとえば、ドキュメントをアップロードすると、テンプレートdocumentの「資産」になります。同様に、新しいワークスペースを作成すると、テンプレートnotebook （ワークスペースの内部名）の「資産」になります。フロントエンドでは、ユーザーに提供されるインターフェイスは、彼が見ているテンプレートによって決定されます。各テンプレートに設定する必要がある一般的な変数があります（たとえば、テンプレートがフォルダーにある場合など、テンプレートをチャットすることが許可されているかどうかなど）。これらの変数と実装された関数は、とりわけ、一般的なエンドポイントが/asset/chat動作方法を決定します。
バックエンドでは、すべてのテンプレートがTemplateベースクラスから継承されるクラスです。これらのテンプレートはbackend/app/templatesの独自のファイルにあります。テンプレートはbackend/app/templates.pyに登録されています。テンプレートを有効にするには、テンプレートのインスタンスを追加する必要があります。また、テンプレートをbackend/app/configs/user_config.pyに追加する必要があります。テンプレートファイル内には、そのテンプレートの特定のエンドポイントもあります。作成することを選択した場合は、 backend/app/__init__.pyに登録する必要があります。
フロントエンドでは、すべてのテンプレートが1つのファイル、 frontend/src/template.jsに実装されます。各テンプレートには、 Templateクラスから継承するクラスがあります。ファイルの下部には、テンプレートの可用性を決定するさまざまなリストとオブジェクトがあります。少なくともテンプレートをTEMPLATESオブジェクトに追加して、ユーザーが利用できるようにする必要があります。
一部のテンプレートは葉のようなものです。たとえば、ドキュメントにはリンクされた資産ソースがありません。つまり、ドキュメントとチャットすると、その1つのドキュメントと本当にチャットすることができます。他のテンプレートにはリンクソースがあります。たとえば、フォルダーのコンテンツはリンクされた資産です。このシステムは、AI Write機能を備えた他の資産から資料を調達できるテキストエディターのような他のテンプレート用に存在します。一貫した方法でソースを使用すると、資産の共有などのテンプレート全体に拡張される機能が機能的であることを確認します。たとえば、フォルダーを誰かと共有する場合、そのフォルダー内のすべてのアイテムにアクセス許可が伝播します。
フロントエンドの資産のソースに関する情報を取得する標準的な方法は/assets/sources-infoエンドポイントを使用しています。資産にソースを追加する標準的な方法は、エンドポイント/assets/add-resourceおよび/assets/add-resourcesを使用することです。これらのエンドポイントは、 asset_metadataテーブルのエントリretrieval_source探しています。 backend/app/assets.pyのエンドポイントの詳細を参照してください。
