Abbey는 노트북, 기본 채팅, 문서, YouTube 동영상 등이있는 AI 인터페이스입니다. 개인 자체 호스팅 패키지로 다양한 AI 모델을 오케스트레이션합니다. 자체 인증 제공 업체를 사용하여 여러 사용자를 위해 Abbey를 서버로 실행하거나 자신의 컴퓨터에서 직접 실행할 수 있습니다. Abbey는 선택한 LLM, TTS 모델, OCR 모델 및 검색 엔진을 사용하여 구성 가능합니다. 많은 학생들과 전문가들이 사용하는 호스팅 버전의 수도원을 찾을 수 있습니다.
문제가 있습니까? 제발, 문제를 게시하거나 제작자에게 직접 연락하십시오! Twitter dm @gkamer8, 이메일 [email protected] 또는 그렇지 않으면 그를 좋아합니다.
Abbey가 기본적으로 귀하의 취향에 따라 구성 할 수없고 코드를 작성하는 것이 편한 경우 개선 사항이있는 PR을 열어주십시오! 새로운 통합 및 전체 인터페이스를 추가하는 것은 간단합니다. 아래의 "기고"섹션을 참조하십시오.


docker compose 설치되어 있어야합니다. 자세한 내용은 여기를 참조하십시오.이전 버전의 Abbey가 있고 Settings.yml이있는 "새 설치"패턴을 처음으로 수행하는 경우 처음으로 당기고 새 settings.yml 및 .env를 작성하고 백엔드/앱/정적에서 파일 스토리지로 이동하고-빌드로 재구성하십시오.
설정에는 클로닝/다운로드이 리포지트를 클로닝/다운로드하고, 선택한 AI 통합으로 .env 및 settings.yml 파일을 작성 한 다음 docker compose 개발 (성능이 좋지만 재생하기 쉬운) 또는 제작 (더 나은 성능이지만 설정이 느리게)을 실행하는 것이 포함됩니다. 다음은 다음과 같습니다.
1 단계 : 이 저장소를 복제 / 다운로드하여 내부를 탐색하십시오.
2 단계 : 비밀 키를 위해 .env 라는 파일을 만들고 Repo의 루트에서 구성 설정을 위해 settings.yml 이라는 파일을 만듭니다 (즉, docker-compose.yml 파일과 같은 수준). 그런 다음 사용하려는 키 / 모델을 해당 파일에 입력하십시오. 이 readme 전체에서 각 유형의 통합을 구성하는 방법에 대한 세부 정보를 찾을 수 있습니다.
.env 파일에는 필요한 모든 API 키 또는 필요한 비밀이 있습니다. Abbey가 사용하는 MySQL 데이터베이스에 대한 비밀번호도 포함해야합니다. 공식 OpenAI API를 사용하는 사람을위한 .env 파일, 키가 필요한 OpenAI 호환 API 및 Anthropic 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를 구성합니다. 최소한 하나 이상의 언어 모델과 하나의 임베딩 모델을 사용해야합니다. Abbey가 기본적으로 사용하도록 최고의 모델을 먼저 배치하십시오. 예를 들어, 여기에 settings.yml 파일은 공식 OpenAi API의 모델을 사용하는 OpenAI 호환 API, Anthropic 및 Ollama를 사용합니다.
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 단계 : 여전히 설정을 가지고 놀면서 단순히 사용하여 Dev 모드에서 Abbey를 실행할 수 있습니다.
docker compose up
Dev Mode에서 설정 / 비밀을 변경하면 컨테이너를 다시 시작하여 설정을 적용 할 수 있습니다.
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을 방문하여 수도원 사용을 시작하십시오. DEV 모드에서는로드하는 데 1 초가 걸릴 수 있습니다.
백엔드는 http://localhost:5000 에서 실행됩니다 - 거기에 가면 Gilbert와 Sullivan의 HMS Pinafore의 가사를 볼 수 있습니다. 그렇지 않다면 백엔드가 실행되지 않습니다.
무언가가 제대로 작동하지 않는 경우, 문제를 제기하거나 제작자에게 직접 연락하십시오 - @gkamer8 twitter 또는 [email protected] 는 이메일로.
기본적으로 Abbey는 Ports 3000에서 Frontend의 경우 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 파일 (prod builds, docker-compose.prod.yml for dev for dev for docker-compose.yml )에 대해 전환하십시오. 백엔드의 모습은 다음과 같습니다.
backend:
# ... some stuff
ports:
- "1234:5000" # now the backend is at http://localhost:1234 in my browser
# ... some stuff
일반 : 모든 Docker 컨테이너가 실제로 docker ps 와 함께 작동하는지 확인하십시오. 6 : Backend, Frontend, Celery, Redis, MySQL 및 DB_Pooler를 볼 수 있습니다 (Abbey는 배경과 여러 스레드에서 AI 작업을 수행 할 수있어서 풀러, Redis 및 Celery 컨테이너가 필요합니다). 실행되지 않으면 docker compose restart backend (또는 Frontend 또는 Celery 또는 귀하가 무엇인지)로 다시 시작하십시오. 계속 충돌하는 경우 settings.yml 엉망으로 만들거나 적절한 비밀을 .env 에 넣는 것을 잊었을 가능성이 높습니다. 그렇지 않으면 로그를보십시오.
Docker Config Invalid : Docker Compose가 유효하지 않다고 말하면 시스템의 Docker가> = 버전 2로 업그레이드해야 할 것입니다. Abbey는 ENV 변수 및 프로파일의 기본값과 같은 비교적 새로운 Docker 기능을 활용합니다. 장기적으로 Docker를 업그레이드하는 것이 더 쉬울 것입니다 - 신뢰.
비워 보이거나로드하지 않습니다. 백엔드에 대한 요청은 제대로 작동하지 않는 것 같습니다. 먼저, http://localhost:5000 또는 원래 URL을 사용하는 것과 같은 브라우저의 백엔드로 이동하십시오. "영국의 타르는 급증하는 영혼입니다 ..."와 같은 메시지를 주어야합니다. "보시면 백엔드가 시작되고 실행 중이지만 백엔드 URL 구성이 잘못되었거나 불완전합니다 (당신이 그것으로 놀고 있었습니까?). 백엔드가 실행되지 않으면 더 자세한 정보는 Docker의 로그를 확인하십시오 - 그들이 말하는 내용을 읽으십시오!
Docker는 이미지를 다운로드/설치/실행 중입니다. 기계의 공간이 부족할 가능성이 있습니다. 먼저, docker system prune 실행하여 잊어 버린 Docker에있는 불쾌한 물건을 정리하십시오. 그런 다음 컴퓨터에서 공간을 정리하십시오 - 아마도 컴퓨터에서 ~ 10GB에 충분할 것입니다. 그런 다음 Docker를 다시 시작하고 다시 시도하십시오. 여전히 문제가 발생하면 - Docker를 제거 / 재설치하지 마십시오.
docker compose 명령은 "API"문제 등으로 인해 실행을 거부합니다. Docker가 실행중인 경우 (예를 들어 Mac의 Docker Desktop)를 다시 시작해야합니다. 도움이되지 않으면 다시 시작하기 전에 데이터를 제거/청소해보십시오 (Docker Desktop에서 "버그"아이콘을 클릭 한 다음 clean/purge 데이터를 참조하십시오). Docker가 실행되지 않으면 그게 당신의 문제입니다! Docker Deomon (예 : Mac의 Docker Desktop)이 실행 중인지 확인해야합니다.
포트가 이미 사용되고 있습니다. 수도원 백엔드는 기본적으로 포트 5000에서 실행됩니다. 대 수도원 프론트 엔드는 포트 3000에서 실행됩니다. 컴퓨터의 무언가가 이미 포트 5000 또는 포트 3000을 사용하고있을 가능성이 있습니다. 목표는 포트 3000 또는 5000에서 실행 중인지 확인하고 해당 프로세스를 종료하는 것입니다. Mac/Linux : lsof -i :5000 또는 lsof -i :3000 사용하여 해당 포트에서 프로세스가 실행 중인지 확인하십시오. Mac에서 실행되는 'Controlce'와 같은 프로세스를 발견하면 "Control Center"를 의미하며 아마도 AirPlay 수신기 일 것입니다. Mac에서 시스템 설정으로 이동하여 "AirPlay 수신기"를 선택 취소 할 수 있습니다. 다른 것을 발견하면 kill -9 YOUR_PID 로 YOUR_PID 가 프로세스 ID (LSOF를 사용하여 표시)로 처치 할 수 있습니다. Windows : netstat -ano | findstr :5000 사용하십시오 netstat -ano | findstr :5000 또는 netstat -ano | findstr :3000 . 그런 다음 taskkill /PID YOUR_PID /F YOUR_PID 관련 프로세스의 프로세스 ID로 바꾸십시오.
제 3 자 통합은 설정 및 환경 변수 파일에서 관리됩니다. 다음은 사용 가능한 사람들의 요약입니다.
언어 모델 (LMS)
임베딩 모델 (임베드)
텍스트 음성 (TTS)
광학 문자 인식 (OCR)
검색 엔진 (웹)
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 에서 구성됩니다. 지원하려는 모든 공급자로부터 언어 모델을 지정할 수 있으며 퀴즈 생성, 요약 및 제안 질문과 같은 장면 뒤에서 사용되는 기본값을 지정할 수 있습니다. Abbey가 제대로 작동하려면 하나 이상의 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:
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 | 아니요 |
| elevenlabs | eleven_labs | eleven_labs_api_key | 아니요 |
| Openai 호환 | OpenAi_compatible | openai_compatible_key | 예 |
임베딩 모델은 settings.yml 의 embeds 에서 구성됩니다. 현재로서는 한 번에 Abbey 전역에 정확히 하나의 필수 임베딩 모델이 사용됩니다. 임베딩 모델은 문서를 검색하는 데 사용됩니다. 위와 같이 필요한 경우 관련 공급자 설정을 구성해야합니다.
embeds:
models:
- provider: "openai" # required
model: "text-embedding-ada-002" # required
| 공급자 | 제공자 코드 | API 키 이름 | 제공자 설정이 필요합니다 |
|---|---|---|---|
| Openai | Openai | Openai_api_key | 아니요 |
| 올라마 | 올라마 | 예 | |
| Openai 호환 | OpenAi_compatible | openai_compatible_key | 예 |
검색 엔진은 web in settings.yml 에서 구성됩니다. 수도원에서 채팅 할 때 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 설정 (Abbey의 리포지어가 아니라 searxng/settings.yml )이 JSON을 다음과 같은 형식으로 허용해야합니다.
search:
formats:
- html
- json
다음 컬 요청이 작동하면 searxng 인스턴스가 올바르게 작동하는지 확인할 수 있습니다 (URL을 searxng 인스턴스 URL로 교체 - 포트가 다를 수 있습니다.)
curl -kLX GET --data-urlencode q='abbey ai' -d format=json http://localhost:8080
광학 문자 인식 API는 ocr 에 따라 settings.yml 있습니다. 기본적으로 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는 이메일을 보내지 않습니다. 전자 메일 프로파일 ( docker compose up --profile email )으로 Abbey를 실행하면 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 폴더에 저장합니다. Abbey를 백업 할 때는 해당 폴더와 데이터베이스를 백업해야합니다. 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_public_url, keycloak_internal_url, keycloak_realm, keycloak_secret 및 keycloak_client_id | 아래를 참조하십시오 |
생산 환경에서는 인증 토큰을 처리하기위한 추가 인증 비밀도 제공해야합니다. 환경 파일에 다음을 추가하여하십시오.
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을 자동으로 설정하는 docker-compose 파일 옆에 배치 할 수있는 keycloak-realm.json 파일입니다.
{
"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 서비스가있어 .env 에서 MYSQL_ROOT_PASSWORD 제공해야합니다. Abbey는 인증을 위해 custom_auth 라는 두 개의 데이터베이스를 사용하고 다른 모든 것에 대해 learn . 동일하거나 다른 서버에있을 수 있습니다. 현재 서버는 MySQL 또는 MySQL 호환 (Postgres가 아님)이어야합니다.
이 .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 파일을 실행하여 관련 데이터베이스 / 테이블을 초기화합니다 (터미널에 복사 및 붙여 넣기가 충분합니다).
홈페이지 (로그인하는 동안)에서 오른쪽에는 이미지와 설명이 있음을 알 수 있습니다. 데이터베이스의 초기화시 기본적으로 표시되는 이미지가 있습니다 (인터넷에서 호스팅). 해당 이미지를 변경하거나 더 추가하려면 Learn 데이터베이스 (MySQL 서비스)의 Art_history 테이블에 항목을 추가해야합니다. 거기에서 이미지에 대한 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을 핑하고 그 이후에 매 시간을 할 것입니다. 사용 통계를 추적하기 위해 수행됩니다. 백엔드 버전과 settings.yml 이 핑에 포함되어 있습니다. 핑을 비활성화하려면 다음을 settings.yml 에 넣으십시오.
ping: false
ping: false 사용을 중단 한 사용자의 차이점을 알 수 없으므로 [email protected]로 연락하여 핑을 비활성화하는 수많은 사용자를 얻을 수 있습니다.
수도원의 주요 강점 중 하나는 확장 성입니다. 새로운 통합 및 인터페이스를 간단하게 구현할 수 있습니다.
인증을 제외한 각 유형의 통합 (아래 참고 참조)은 backend/app/integrations 의 파일에 있습니다. 각 유형의 통합은 특정 클래스를 구현합니다 (예 : lm.py LM 클래스를 제공하며 각 유형의 통합은 해당 클래스를 구현합니다). 기본 클래스 (LM, TTS, OCR 등)에서 상속되는 클래스를 추가 할 수 있습니다. 그런 다음 PROVIDER_TO_ 사전에 클래스를 추가해야합니다 (각 유형의 통합마다 다른 것이 있습니다). 사용자가 선택할 수있는 통합의 경우 settings.yml 에서 적절한 변경이 이루어지면 자동으로 팝업해야합니다 (예 : 사용자는 검색 엔진, 언어 모델 및 텍스트 음성 연설 모델을 선택할 수 있음). 기본적으로 Abbey가 선택한 embed 와 같은 통합의 경우, 통합이 settings.yml 의 기본값인지 확인해야합니다.
통합이 비밀에 의존하는 경우 지정된 패턴을 사용하여 backend/app/configs/secrets.py 에 추가 한 다음 통합 파일 (예 : lm.py )으로 가져와야합니다.
다른 통합과 달리 OAUTH2 제공 업체를 추가하는 경우 플라스크 백엔드에서 어떤 일도 할 이유가 없습니다. 다음 .js 프론트 엔드 서버는 모든 것을 처리합니다. 당신이해야 할 일은 다음과 같습니다.
frontend/src/pages/api/auth/[...auth].js 에서 제공자 클래스를 만듭니다. 가장 간단한 예는 세 가지 URL을 제공하는 GoogleAuth 클래스 (확장 BaseAuth)입니다. OAUTH2 토큰 종말점; 그리고 OpenID 연결 사용자 정보 엔드 포인트. GitHub은 표준 OpenID Connect를 구현하지 않으므로 getUserData () 함수를 직접 구현합니다.authProviders 변수에 조건부 추가하십시오.frontend/src/auth/custom.js 에서 해당 제공 업체의 프론트 엔드 로그인 버튼을 만듭니다. 첫째, 이는 환경 변수가 1으로 설정되어 있는지 여부를 기반으로 조건부로 새 공급자의 코드를 enabledProviders 데 도움이되는 것을 의미합니다 (환경 변수는 다음 _public으로 시작하여 클라이언트 측면 이용 가능). 둘째, 제공자 코드 및 버튼 값을 지정하는 providers 목록에 객체를 추가하는 것을 의미합니다 (패턴을 따르고 로고를 frontend/public/random 에 추가하여 제공자 로고를 추가 할 수 있음). 검색 엔진에 대한 하나의 메모 : 검색 엔진에 대한 일부 클래스 기능이 사용자 정의 검색 개체를 반환합니다. 관련 클래스는 web.py 에서 구현되며 새로운 검색 엔진 통합을 구현하려면 살펴 봐야합니다.
수도원에서는 모든 것이 "자산"이며 모든 자산은 "템플릿"을 구현합니다. 예를 들어, 문서를 업로드하면 템플릿 document 의 "자산"이됩니다. 마찬가지로 새 작업 공간을 만들면 템플릿 notebook (작업 공간의 내부 이름)의 "자산"이됩니다. 프론트 엔드에서 사용자에게 제공된 인터페이스는 그가보고있는 템플릿에 의해 결정됩니다. 각 템플릿에 대해 설정 해야하는 일반적인 변수가 있습니다 (예 : 템플릿이 폴더에 있거나 그와 비슷한 경우 템플릿을 채팅 할 수 있는지 여부). 이러한 변수 및 구현 된 기능은 무엇보다도 /asset/chat 같은 일반적인 엔드 포인트가 작동하는 방식을 결정합니다.
백엔드에서 모든 템플릿은 Template 베이스 클래스에서 상속되는 클래스입니다. 이 템플릿은 backend/app/templates 의 자체 파일에 있습니다. 템플릿은 backend/app/templates.py 에 등록됩니다. 활성화하려면 템플릿 인스턴스를 추가해야합니다. 또한 backend/app/configs/user_config.py 에 템플릿을 추가해야합니다. 템플릿 파일 내부에는 해당 템플릿의 특정 엔드 포인트가있을 수 있습니다. 하나를 만들기로 선택한 경우 backend/app/__init__.py 에 등록해야합니다.
프론트 엔드에서 모든 템플릿은 하나의 파일 인 frontend/src/template.js 로 구현됩니다. 각 템플릿에는 Template 클래스에서 상속되는 클래스가 있습니다. 파일 하단에는 템플릿의 가용성을 결정하는 다양한 목록과 개체가 있습니다. 최소한 TEMPLATES 객체에 템플릿을 추가하여 사용자가 사용할 수 있도록해야합니다.
일부 템플릿은 잎과 같습니다. 예를 들어, 문서에는 연결된 자산 소스가 없으므로 문서와 채팅 할 때 해당 문서와 만 채팅하는 것이 좋습니다. 다른 템플릿에는 연결된 소스가 있습니다. 예를 들어, 폴더의 내용은 연결된 자산입니다. 이 시스템은 텍스트 편집기와 같은 다른 템플릿에 대해 존재하며,이 텍스트는 AI 쓰기 기능을 갖춘 다른 자산의 자료를 공급할 수 있습니다. 일관된 방식으로 소스를 사용하면 자산 공유와 같은 템플릿에서 확장되는 기능이 여전히 기능적으로 유지됩니다. 예를 들어 폴더를 누군가와 공유하면 권한이 해당 폴더 내부의 모든 항목으로 전파됩니다.
프론트 엔드에서 자산의 소스에 대한 정보를 검색하는 표준 방법은 /assets/sources-info 엔드 포인트와 관련이 있습니다. 자산에 소스를 추가하는 표준 방법은 엔드 포인트 /assets/add-resource 및 /assets/add-resources 있습니다. 이 엔드 포인트는 자산 ID 인 Key retrieval_source 가있는 asset_metadata 테이블의 항목을 찾고 있습니다. backend/app/assets.py 의 해당 엔드 포인트에 대한 자세한 내용을 참조하십시오.