abbey
1.0.0
Abbey é uma interface de IA com notebooks, bate -papo básico, documentos, vídeos do YouTube e muito mais. Orquestra uma variedade de modelos de IA em um pacote privado auto-hospedado. Você pode executar a Abbey como um servidor para vários usuários usando seu próprio provedor de autenticação, ou pode executá -lo em sua própria máquina. Abbey é altamente configurável, usando seus LLMs escolhidos, modelos TTS, modelos OCR e mecanismos de pesquisa. Você pode encontrar uma versão hospedada da Abbey aqui, usada por muitos estudantes e profissionais.
Tendo algum problema? Por favor, poste um problema ou entre em contato com o Criador diretamente! Twitter dm @gkamer8, e -mail [email protected] ou de outra forma ping nele - ele gosta.
Se a Abbey não for configurável por padrão, e você se sentir confortável em escrever um código, considere abrir um PR com suas melhorias! Adicionar novas integrações e até interfaces completas é direto; Veja mais detalhes na seção "contribuindo" abaixo.
docker compose instalado. Veja detalhes aqui.Se você tem uma versão anterior do Abbey e está fazendo o padrão "novo instalação" com o Settings.yml pela primeira vez, puxe, crie um novo Settings.yml e .env, conforme descrito abaixo, mova seus arquivos de back-end/app/static para armazenamento de arquivos e reconstruir com--build
A configuração envolve clonagem/download deste repositório, criando arquivos .env e settings.yml com as integrações de IA escolhidas e, em seguida, executando docker compose para o desenvolvimento (pior desempenho, mas fácil de brincar) ou produção (melhor desempenho, mas mais lento para alterar as configurações). Aqui estão as etapas:
Etapa 1: Clone / Baixe este repositório e navegue dentro dele.
Etapa 2: Crie um arquivo chamado .env para chaves secretas e um arquivo chamado settings.yml para configurações de configuração na raiz do repo (ou seja, no mesmo nível que o arquivo docker-compose.yml ). Em seguida, insira esses arquivos as chaves / modelos que você deseja usar. Você pode encontrar detalhes sobre como configurar cada tipo de integração ao longo deste Readme.
O arquivo .env contém quaisquer chaves da API ou outros segredos necessários. Você também deve incluir uma senha para o banco de dados MySQL que a Abadia usa. Um arquivo .env para alguém que usa a API oficial do OpenAI, uma API compatível com o OpenAI que requer uma chave, e a API antrópica pode parecer:
MYSQL_ROOT_PASSWORD="my-password"
OPENAI_API_KEY="my-openai-key"
OPENAI_COMPATIBLE_KEY="my-api-key"
ANTHROPIC_API_KEY="my-anthropic-key"
O arquivo settings.yml configura a abadia para usar os modelos e opções que você deseja. No mínimo, você deve usar pelo menos um modelo de idioma e um modelo de incorporação. Coloque os melhores modelos em primeiro lugar para que a Abadia os use por padrão. Por exemplo, aqui está um arquivo settings.yml que usa modelos da API oficial do OpenAI, uma API compatível com o OpenAI, Antrópico e 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"
E, dado que você também colocou as chaves relevantes em .env , isso seria um arquivo de configurações completo. Para configurar modelos diferentes, mecanismos de pesquisa, serviços de autenticação, modelos de texto em fala, etc.: Por favor, procure a documentação apropriada abaixo!
Etapa 3: se você ainda está brincando com suas configurações, poderá executar a abadia no modo dev simplesmente usando:
docker compose up
No modo DEV, quando você altera suas configurações / segredos, você só precisa reiniciar os contêineres para que suas configurações sejam aplicadas, o que pode ser feito com:
docker compose restart backend frontend celery db_pooler
Quando estiver pronto, você pode executar a abadia no modo de produção para dar melhor desempenho:
docker compose -f docker-compose.prod.yml up --build
Se você deseja alterar suas configurações / segredos no modo Prod, é necessário reconstruir os contêineres:
docker compose down
docker compose -f docker-compose.prod.yml up --build
Etapa 4: agora a Abadia deve estar em execução em http://localhost:3000 ! Basta visitar esse URL no seu navegador para começar a usar Abbey. No modo DEV, pode levar um segundo para carregar.
Observe que o back -end é executado em http://localhost:5000 - Se você for lá, você deve ver uma letra de Gilbert e HMS Pinafore de Sullivan. Caso contrário, o back -end não está em execução.
Se algo não estiver funcionando corretamente, por favor (por favor) registre um problema ou entre em contato com o Criador diretamente - @gkamer8 no Twitter ou [email protected] por e -mail.
Por padrão, a Abbey é executada no host localizador nos portos 3000 para o front -end e 5000 para o back -end. Se você deseja alterá -los (já que você é bastante experiente em tecnologia), precisará modificar o arquivo de composição do Docker e adicione -o ao seu 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
Certifique -se de atualizar o arquivo do Docker compor, por exemplo, alterando o mapeamento da porta para o back -end para 1234: 5000, se alterar a porta. Certifique-se de alterná-lo para o arquivo correto do docker-composição ( docker-compose.prod.yml para builds cour, docker-compose.yml para dev). Aqui está como isso seria o back -end:
backend:
# ... some stuff
ports:
- "1234:5000" # now the backend is at http://localhost:1234 in my browser
# ... some stuff
Geral: verifique se todos os contêineres do Docker estão realmente funcionando com docker ps . Você deve ver 6: back -end, front -end, aipo, redis, mysql e db_pooler (desculpe que haja tantos - a abadia pode executar tarefas de IA em segundo plano e em vários threads, o que requer os contêineres de pool, redis e aipo). Se alguém não estiver em execução, tente reiniciá -lo com docker compose restart backend (ou front -end, ou o aipo, ou o que você tem). Se continuar travando, há uma boa chance de você estragar suas settings.yml ou esqueceu de colocar segredos apropriados em .env . Caso contrário, olhe para os logs.
Docker Config inválido: se está lhe dizendo que seu Docker Compose é inválido, você provavelmente precisará atualizar o Docker em sua máquina para algo> = versão 2. Abadia aproveita certos recursos relativamente novos do docker, como padrões para variáveis e perfis Env. Vai ser mais fácil apenas atualizar o Docker a longo prazo - confie.
As coisas parecem em branco / não carregam / solicitações no back -end não parecem funcionar bem. Primeiro, navegue até o back -end no navegador, como http://localhost:5000 ou qualquer URL que você coloque originalmente. Ele deve dar uma mensagem como "Um alcatrão britânico é uma alma crescente ..." Se você vê isso, o back -end está em funcionamento, mas sua configuração de URL de back -end está errada ou incompleta (você estava brincando com ela?). Se o seu back -end não estiver em execução, verifique os logs no Docker para obter mais informações - leia o que eles dizem!
Docker fica preso baixando/instalando/executando uma imagem. Existe a possibilidade de você ficar sem espaço em sua máquina. Primeiro, tente correr docker system prune para limpar qualquer coisa desagradável em Docker que você esqueceu. Em seguida, tente limpar o espaço no seu computador - talvez o suficiente para ~ 10 GB em sua máquina. Em seguida, reinicie o Docker e tente novamente. Se você ainda tiver problemas - tente desinstalar / reinstalar o Docker.
O comando docker compose se recusa a ser executado por causa de algum problema de "API" ou algo assim. Se o Docker estiver em execução (Docker Desktop no Mac, por exemplo), você deve reiniciá -lo. Se isso não ajudar, tente purgar/limpar seus dados antes de reiniciar (clique no ícone "bug" na área de trabalho do Docker, se você o tiver - então consulte os dados clean/purge ). Se o Docker não estiver em execução, esse é o seu problema! Você precisa garantir que o Docker Daemon (ou seja, o Docker Desktop no Mac) esteja em execução.
Uma porta já está sendo usada. O back -end da abadia é executado na porta 5000 por padrão; O front -end da Abbey é executado na porta 3000. É possível que algo no seu computador já esteja usando a porta 5000 ou a porta 3000. No Mac, que geralmente significa o AirPlay. Seu objetivo deve ser verificar se alguma coisa está em execução nas portas 3000 ou 5000 e, nesse caso, desligar esses processos. No Mac/Linux: use lsof -i :5000 ou lsof -i :3000 para verificar se algum processo está em execução nessas portas. Se você notar um processo como 'Controlce' em execução no Mac, isso significa "Centro de Controle", e provavelmente é uma coisa do Receptor de Airplay. Você pode entrar nas configurações do seu sistema no Mac e desmarque o "Receptor do Airplay". Se você encontrou outra coisa, pode matá -lo com kill -9 YOUR_PID onde YOUR_PID é substituído pelo ID do processo (mostrado usando LSOF). No Windows: use netstat -ano | findstr :5000 ou netstat -ano | findstr :3000 . Em seguida, você pode matar o processo com taskkill /PID YOUR_PID /F - substitua YOUR_PID pelo ID do processo do processo relevante.
As integrações de terceiros são gerenciadas em seus arquivos de variáveis de ambiente e ambiente. Aqui está um resumo dos disponíveis:
Modelos de idiomas (LMS)
Modelos de incorporação (incorporação)
Text-to-fala (TTS)
Reconhecimento de caracteres ópticos (OCR)
Mecanismos de pesquisa (web)
https://api.bing.microsoft.com/v7.0/search )Armazenamento de arquivos (armazenamento)
file-storage (padrão)Autenticação
Algumas integrações requerem configuração no settings.yml. Se estiver usando alguma das seguintes integrações, você deve especificar suas configurações como assim:
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
Estes vão na raiz do settings.yml no mesmo nível que lms ou embeds .
Os modelos de idiomas são configurados no lms em settings.yml . Você pode especificar modelos de idiomas de qualquer provedor que você deseja apoiar, além de padrões usados nos bastidores para coisas como geração de questionários, resumos e perguntas sugerindo. Você deve ter pelo menos um LM para a Abadia funcionar corretamente. Lembre -se de definir as configurações do provedor relevante, se necessário, conforme mostrado acima.
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...
Esta tabela fornece o código do provedor para cada provedor e o nome de chave da API relevante para colocar em .env :
| Provedor | Código do provedor | Nome da chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| Openai | Openai | OpenAi_API_KEY | Não |
| Antrópico | Antrópico | Anthropic_API_KEY | Não |
| Ollama | Ollama | Sim | |
| OpenAI Compatível | Openai_compatible | Openai_compatible_key | Sim |
Os modelos de texto para fala são configurados no tts em settings.yml . Você pode especificar modelos TTS a partir de qualquer provedor que você deseja apoiar, além de um padrão. Os modelos TTS são totalmente opcionais. Lembre -se de definir as configurações do provedor relevante, se necessário, conforme mostrado acima.
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
| Provedor | Código do provedor | Nome da chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| Openai | Openai | OpenAi_API_KEY | Não |
| Elevenlabs | Eleven_labs | Eleven_labs_api_key | Não |
| OpenAI Compatível | Openai_compatible | Openai_compatible_key | Sim |
Os modelos de incorporação são configurados em embeds em settings.yml . Por enquanto, exatamente um modelo de incorporação obrigatório é usado na abadia de cada vez. Modelos de incorporação são usados para pesquisar documentos. Lembre -se de definir as configurações do provedor relevante, se necessário, conforme mostrado acima.
embeds:
models:
- provider: "openai" # required
model: "text-embedding-ada-002" # required
| Provedor | Código do provedor | Nome da chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| Openai | Openai | OpenAi_API_KEY | Não |
| Ollama | Ollama | Sim | |
| OpenAI Compatível | Openai_compatible | Openai_compatible_key | Sim |
Os mecanismos de pesquisa são configurados na web em settings.yml . Eles são usados quando você verifica, Use Web ao conversar na Abbey. Lembre -se de definir as configurações do provedor relevante, se necessário, conforme mostrado acima.
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
| Provedor | Código do provedor | Nome da chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| Bing | Bing | Bing_api_key | Não |
| Searxng | Searxng | Sim |
Searxng não permite o acesso da API. Ao executar sua instância do Searxng, você deve garantir que suas configurações de Searxng (não no repositório da Abbey, mas no searxng/settings.yml ) permitem que o JSON como formato, como:
search:
formats:
- html
- json
Você pode garantir que sua instância do Searxng esteja funcionando corretamente quando a seguinte solicitação de curl (substitua o URL pelo seu URL da instância Searxng - a porta pode ser diferente.)
curl -kLX GET --data-urlencode q='abbey ai' -d format=json http://localhost:8080
As APIs de reconhecimento de caracteres ópticas são configuradas no ocr em settings.yml . Por padrão, nenhum OCR é usado. Opcionalmente, a configuração do OCR permite que a Abbey leia os PDFs digitalizados. Abbey determina automaticamente se o OCR parece necessário.
ocr:
models:
- provider: "mathpix"
| Provedor | Código do provedor | Nomes de chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| Mathpix | Mathpix | Mathpix_api_app e mathpix_api_key | Não |
As APIs de email são configuradas em email em settings.yml . A configuração do email permite que a Abbey envie links para ativos na Abadia quando forem compartilhados, além de algumas outras circunstâncias. Por padrão, Abbey não envia e -mails. Executando a abadia com o perfil de email (como docker compose up --profile email ) permite que a Abbey envie e -mails adicionais de lembrete para alguns modelos.
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]"
| Provedor | Código do provedor | Segredos obrigatórios | Precisa de configuração do provedor |
|---|---|---|---|
| SendGrid | sendGrid | Sendgrid_api_key | Não |
| Email SMTP | smtp | SMTP_SERVER, SMTP_PORT, SMTP_EMAIL e SMTP_PASSWORD | Não |
As APIs de armazenamento de arquivos são configuradas em storage em settings.yml . Por padrão, o Abbey armazena todos os arquivos enviados na pasta de file-storage montados. Ao fazer backup da abadia, você deve fazer backup dessa pasta mais o banco de dados. Se você deseja usar o S3, pode usar o seguinte:
storage:
default: s3 # All new uploads go to the default provider (you don't need to set up local)
locations:
- provider: s3
| Provedor | Código do provedor | Nomes de chave da API | Precisa de configuração do provedor |
|---|---|---|---|
| S3 | S3 | AWS_ACCESS_KEY e AWS_SECRET_KEY | Não |
| Local | local | Não |
Os provedores de autenticação são configurados em auth in settings.yml . Por padrão, a Abbey usará um único usuário "padrão". A configuração de provedores de autenticação adicionais permite configurações de vários usuários. Você pode usar um provedor OAuth2 como o Google, ou pode se auto-hospedar uma instância do keycloak (instruções abaixo). Para fornecedores como Google e Github, você precisará de um segredo e ID do cliente. Ao se registrar na Abadia, talvez você precise fornecer o URL onde a abadia está acessível - que seria http://localhost:3000 por padrão, ou qualquer URL público que você esteja usando para o front -end da Abbey.
auth:
providers:
- google
- github
- keycloak
| Provedor | Código do provedor | Variáveis Env | Como adquirir ID / segredo do cliente |
|---|---|---|---|
| Google_client_id e google_secret | Veja aqui | ||
| Github | Github | Github_client_id e github_secret | Veja aqui |
| Keycloak | keycloak | Keycloak_public_url, keycloak_internal_url, keycloak_realm, keycloak_secret e keycloak_client_id | Veja abaixo |
Nos ambientes de produção, você também deve fornecer segredos de autenticação adicionais para lidar com os tokens de autenticação. Faça isso adicionando o seguinte ao seu arquivo de ambiente:
CUSTOM_AUTH_SECRET="my-auth-secret"
REFRESH_TOKEN_SECRET="my-refresh-secret"
Você pode autenticação de auto-hospedeiro inteiramente usando o keycloak. Usando o keycloak com abadia requer certas configurações - por exemplo, um URL front -end para o reino deve ser especificado para permitir que a abadia e o keycloak funcionem na mesma VM do Docker. Se você possui uma instância de keycloak existente, crie um novo cliente para a Abbey com um ID do cliente e segredo do cliente que você coloca no .env . Caso contrário, aqui estão as instruções da criação de uma nova instância para a Abbey:
Aqui está um arquivo keycloak-realm.json que você pode colocar ao lado do seu arquivo docker-compose que configura o keycloak automaticamente:
{
"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"
}
]
}
]
}
Aqui está um exemplo de serviço que você pode executar ao lado do seu arquivo 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 também requer alguns segredos adicionais em .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"
Acrescentando que o serviço + criando o arquivo keycloak-realm.json + inserindo segredos no .env deve permitir que a abadia "apenas trabalhe" com o keycloak em um ambiente de desenvolvimento.
Por padrão, a Abbey possui um serviço MySQL para o qual você deve fornecer um MYSQL_ROOT_PASSWORD em .env . Abbey usa dois bancos de dados, custom_auth para autenticação e learn para todo o resto. Eles podem estar no mesmo ou em servidores diferentes. A partir de agora, o servidor deve ser compatível com MySQL ou MySQL (não PostGres).
Você pode alterar onde o servidor MySQL está disponível, usando essas variáveis .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
Quando o serviço MySQL padrão é iniciado, ele se inicializará usando os arquivos dentro mysql-init . Se você configurar seu próprio serviço MySQL, você iniciará os bancos / tabelas relevantes, executando esses arquivos .sql (copiando e colando em um terminal seria suficiente).
Você pode notar que na página inicial (enquanto assinada), o lado direito tem uma imagem e uma descrição. Na inicialização do banco de dados, há uma imagem que aparecerá lá por padrão (que está hospedado na Internet). Para alterar essa imagem ou adicionar mais, você precisa adicionar entradas à tabela ART_HISTORY no banco de dados Learn (no serviço MySQL). Lá você coloca um URL para a imagem e a marcação para a descrição. O (s) domínio (s) em que a imagem é hospedada também precisa ser incluída no settings.yml , como assim:
images:
domains:
- "my-domain.com"
Para adicionar a entrada no Art_history, você precisa executar alguns SQL. Com o Docker-Comppose, você pode usar:
docker-compose exec mysql mysql -u root -p
e, em seguida, use sua senha do MySQL Root (disponível no arquivo .env localizado na raiz do projeto). Então, você precisará executar:
use learn;
INSERT INTO art_history (`markdown`, `image`)
VALUES ('This is my *description*', 'https://my-domain.com/image.webp');
Uma imagem é selecionada aleatoriamente para ser exibida a partir dessa tabela art_history .
Você pode alterar o nome de Abbey para o que quiser usar esta opção em settings.yml :
name: "Abbey" # Replace with your chosen name
Outras marcas como logotipos, favicons e assim por diante estão localizadas no frontend/public . Você pode alterá -los substituindo os arquivos (mas mantendo seus nomes). As imagens de fundo estão na pasta frontend/public/random .
Por padrão, a Abbey pingá um URL codificado quando o back -end começar e a cada hora depois. Isso é feito para rastrear estatísticas de uso. A versão de back -end em que você está, mais o seu settings.yml está incluído no ping. Para desativar o ping, coloque o seguinte em seus settings.yml :
ping: false
Como não sei dizer a diferença entre um usuário que está definido ping: false e um usuário que parou de usar a abadia, considere procurar [email protected] para que eu possa obter um número difícil de usuários que desativam o ping.
Um dos principais pontos fortes da Abadia é sua extensão. Você pode implementar novas integrações e interfaces diretamente.
Cada tipo de integração, exceto para auth (veja as notas abaixo), reside em um arquivo no backend/app/integrations . Cada tipo de integração implementa uma classe específica (por exemplo, lm.py fornece uma classe LM e cada tipo de integração implementa essa classe). Você pode simplesmente adicionar uma classe que herda da classe base (LM, TTS, OCR, etc.). Em seguida, você deve adicionar sua classe ao PROVIDER_TO_ dicionário (há um diferente para cada tipo de integração). Para integrações que podem ser escolhidas pelo usuário, ele deve aparecer automaticamente assim que a alteração apropriada for feita no settings.yml (por exemplo, um usuário pode selecionar seu mecanismo de pesquisa, modelo de idioma e modelo de texto em fala). Para integrações como embed que são escolhidas pela Abbey por padrão, você deve garantir que sua integração seja o padrão no settings.yml .
Se a sua integração depende de segredos, adicione -o ao backend/app/configs/secrets.py usando o padrão especificado e depois importá -lo para o arquivo de integração (por exemplo, lm.py ).
Ao contrário das outras integrações, se você está simplesmente adicionando um provedor OAuth2, de fato não há motivo para fazer qualquer coisa no back -end do frasco. O NEXT.JS Frontend Server lida com tudo. O que você precisa fazer é:
frontend/src/pages/api/auth/[...auth].js . O exemplo mais simples é a classe GoogleAuth (estendendo a base), que fornece três URLs: um endpoint de autenticação OAuth2; um terminal de token OAuth2; e um terminal de informações do usuário do OpenID Connect. Como o GitHub não implementa o Standard OpenId Connect, ele implementa diretamente a função getUserData ().authProviders com base na disponibilidade de segredos.frontend/src/auth/custom.js . Primeiro, isso significa pressionar para enabledProviders o código do seu novo provedor condicionalmente com base no fato de uma variável de ambiente estar definida como 1 (a variável de ambiente deve começar com o Next_public para que esteja disponível no lado do cliente). Segundo, isso significa adicionar um objeto à lista de providers , especificando o código do seu provedor e o valor do botão (você pode adicionar o logotipo do seu provedor seguindo o padrão e adicionando o logotipo ao frontend/public/random ). Uma nota nos mecanismos de pesquisa: algumas funções de classe para um mecanismo de pesquisa retorna objetos de pesquisa personalizados; As classes relevantes são implementadas no web.py e você deve dar uma olhada se optar por implementar uma nova integração do mecanismo de pesquisa.
Na Abadia, tudo é um "ativo", e todo ativo implementa um "modelo". Por exemplo, se você enviar um documento, ele se tornará um "ativo" do document de modelo. Da mesma forma, se você criar um novo espaço de trabalho, ele se tornará um "ativo" do notebook de modelo (o nome interno para um espaço de trabalho). No frontend, a interface fornecida a um usuário é determinada pelo modelo que ele está olhando. Há uma littânia de variáveis comuns que devem ser definidas para cada modelo (por exemplo, se o modelo pode ou não ser conversado, se estiver na pasta ou algo assim). Essas variáveis e funções implementadas determinam, entre outras coisas, a maneira como os pontos finais gerais como /asset/chat se comportam.
No back -end, todos os modelos são classes que herdam da classe base Template . Esses modelos estão localizados em seus próprios arquivos em backend/app/templates . Os modelos são registrados no backend/app/templates.py . Você deve adicionar uma instância do seu modelo para ativá -lo. Você também deve adicionar o modelo ao backend/app/configs/user_config.py . Dentro de um arquivo de modelo também pode ser um terminal específico para esse modelo; Se você optar por criar um, ele deve ser registrado no backend/app/__init__.py .
No front -end, todos os modelos são implementados em um arquivo, frontend/src/template.js . Cada modelo existe uma classe que herda da classe Template . Na parte inferior do arquivo, existem várias listas e objetos que determinam a disponibilidade do modelo; Você deve, no mínimo, adicionar seu modelo ao objeto de TEMPLATES para disponibilizá -lo aos usuários.
Alguns modelos são como folhas; Por exemplo, os documentos não têm fontes de ativos vinculadas, o que significa que, quando você conversa com um documento, você está realmente conversando apenas com esse documento. Outros modelos têm fontes vinculadas. Por exemplo, o conteúdo de uma pasta são ativos vinculados. Esse sistema existe para outros modelos, como o editor de texto, que pode obter material de outros ativos com sua funcionalidade de gravação da IA. O uso de fontes de maneira consistente garante que a funcionalidade que se estenda entre modelos, como compartilhar ativos, permaneça funcional. Se você compartilhar uma pasta com alguém, por exemplo, as permissões se propagam até todos os itens dentro dessa pasta.
A maneira padrão de recuperar informações sobre as fontes de um ativo no front-end é com o endpoint /assets/sources-info . A maneira padrão de adicionar uma fonte a um ativo é com os pontos de extremidade /assets/add-resource e /assets/add-resources . Esses pontos de extremidade estão procurando uma entrada na tabela asset_metadata com retrieval_source de chaves, cujo valor é um ID de ativo. Veja mais detalhes sobre esses pontos de extremidade no backend/app/assets.py .
