gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
;;; gptel-openai.el --- ChatGPT suppport for gptel -*- lexical-binding: t; -*-
|
|
|
|
|
|
|
|
|
|
;; Copyright (C) 2023 Karthik Chikmagalur
|
|
|
|
|
|
|
|
|
|
;; Author: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
|
|
|
|
|
|
|
|
|
|
;; This program is free software; you can redistribute it and/or modify
|
|
|
|
|
;; it under the terms of the GNU General Public License as published by
|
|
|
|
|
;; the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
;; (at your option) any later version.
|
|
|
|
|
|
|
|
|
|
;; This program is distributed in the hope that it will be useful,
|
|
|
|
|
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
;; GNU General Public License for more details.
|
|
|
|
|
|
|
|
|
|
;; You should have received a copy of the GNU General Public License
|
|
|
|
|
;; along with this program. If not, see <https://www.gnu.org/licenses/>.
|
|
|
|
|
|
|
|
|
|
;;; Commentary:
|
|
|
|
|
|
|
|
|
|
;; This file adds support for the ChatGPT API to gptel
|
|
|
|
|
|
|
|
|
|
;;; Code:
|
|
|
|
|
(require 'cl-generic)
|
2024-01-18 01:10:58 +00:00
|
|
|
(eval-when-compile
|
|
|
|
|
(require 'cl-lib))
|
2023-10-31 20:18:00 -07:00
|
|
|
(require 'map)
|
|
|
|
|
|
|
|
|
|
(defvar gptel-model)
|
|
|
|
|
(defvar gptel-stream)
|
|
|
|
|
(defvar gptel-use-curl)
|
|
|
|
|
(defvar gptel-backend)
|
|
|
|
|
(defvar gptel-temperature)
|
|
|
|
|
(defvar gptel-max-tokens)
|
|
|
|
|
(defvar gptel--system-message)
|
|
|
|
|
(defvar gptel--known-backends)
|
|
|
|
|
(defvar json-object-type)
|
|
|
|
|
|
|
|
|
|
(declare-function gptel--get-api-key "gptel")
|
|
|
|
|
(declare-function prop-match-value "text-property-search")
|
|
|
|
|
(declare-function text-property-search-backward "text-property-search")
|
|
|
|
|
(declare-function json-read "json")
|
2023-12-20 14:23:45 -08:00
|
|
|
(declare-function gptel-prompt-prefix-string "gptel")
|
|
|
|
|
(declare-function gptel-response-prefix-string "gptel")
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
|
|
|
|
|
;;; Common backend struct for LLM support
|
|
|
|
|
(cl-defstruct
|
|
|
|
|
(gptel-backend (:constructor gptel--make-backend)
|
|
|
|
|
(:copier gptel--copy-backend))
|
|
|
|
|
name host header protocol stream
|
|
|
|
|
endpoint key models url)
|
|
|
|
|
|
|
|
|
|
;;; OpenAI (ChatGPT)
|
|
|
|
|
(cl-defstruct (gptel-openai (:constructor gptel--make-openai)
|
|
|
|
|
(:copier nil)
|
|
|
|
|
(:include gptel-backend)))
|
|
|
|
|
|
|
|
|
|
(cl-defmethod gptel-curl--parse-stream ((_backend gptel-openai) _info)
|
|
|
|
|
(let* ((json-object-type 'plist)
|
|
|
|
|
(content-strs))
|
|
|
|
|
(condition-case nil
|
|
|
|
|
(while (re-search-forward "^data:" nil t)
|
|
|
|
|
(save-match-data
|
|
|
|
|
(unless (looking-at " *\\[DONE\\]")
|
|
|
|
|
(when-let* ((response (json-read))
|
|
|
|
|
(delta (map-nested-elt
|
|
|
|
|
response '(:choices 0 :delta)))
|
|
|
|
|
(content (plist-get delta :content)))
|
|
|
|
|
(push content content-strs)))))
|
|
|
|
|
(error
|
|
|
|
|
(goto-char (match-beginning 0))))
|
|
|
|
|
(apply #'concat (nreverse content-strs))))
|
|
|
|
|
|
|
|
|
|
(cl-defmethod gptel--parse-response ((_backend gptel-openai) response _info)
|
|
|
|
|
(map-nested-elt response '(:choices 0 :message :content)))
|
|
|
|
|
|
|
|
|
|
(cl-defmethod gptel--request-data ((_backend gptel-openai) prompts)
|
|
|
|
|
"JSON encode PROMPTS for sending to ChatGPT."
|
|
|
|
|
(let ((prompts-plist
|
|
|
|
|
`(:model ,gptel-model
|
|
|
|
|
:messages [,@prompts]
|
|
|
|
|
:stream ,(or (and gptel-stream gptel-use-curl
|
|
|
|
|
(gptel-backend-stream gptel-backend))
|
|
|
|
|
:json-false))))
|
|
|
|
|
(when gptel-temperature
|
|
|
|
|
(plist-put prompts-plist :temperature gptel-temperature))
|
|
|
|
|
(when gptel-max-tokens
|
|
|
|
|
(plist-put prompts-plist :max_tokens gptel-max-tokens))
|
|
|
|
|
prompts-plist))
|
|
|
|
|
|
|
|
|
|
(cl-defmethod gptel--parse-buffer ((_backend gptel-openai) &optional max-entries)
|
|
|
|
|
(let ((prompts) (prop))
|
|
|
|
|
(while (and
|
|
|
|
|
(or (not max-entries) (>= max-entries 0))
|
|
|
|
|
(setq prop (text-property-search-backward
|
|
|
|
|
'gptel 'response
|
|
|
|
|
(when (get-char-property (max (point-min) (1- (point)))
|
|
|
|
|
'gptel)
|
|
|
|
|
t))))
|
|
|
|
|
(push (list :role (if (prop-match-value prop) "assistant" "user")
|
|
|
|
|
:content
|
|
|
|
|
(string-trim
|
|
|
|
|
(buffer-substring-no-properties (prop-match-beginning prop)
|
|
|
|
|
(prop-match-end prop))
|
2023-12-20 14:23:45 -08:00
|
|
|
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
|
|
|
|
|
(regexp-quote (gptel-prompt-prefix-string)))
|
|
|
|
|
(format "[\t\r\n ]*\\(?:%s\\)?[\t\r\n ]*"
|
|
|
|
|
(regexp-quote (gptel-response-prefix-string)))))
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
prompts)
|
|
|
|
|
(and max-entries (cl-decf max-entries)))
|
|
|
|
|
(cons (list :role "system"
|
|
|
|
|
:content gptel--system-message)
|
|
|
|
|
prompts)))
|
|
|
|
|
|
|
|
|
|
;;;###autoload
|
|
|
|
|
(cl-defun gptel-make-openai
|
2024-01-19 14:43:07 -08:00
|
|
|
(name &key models stream key
|
|
|
|
|
(header
|
|
|
|
|
(lambda () (when-let (key (gptel--get-api-key))
|
|
|
|
|
`(("Authorization" . ,(concat "Bearer " key))))))
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
(host "api.openai.com")
|
|
|
|
|
(protocol "https")
|
|
|
|
|
(endpoint "/v1/chat/completions"))
|
2024-01-04 17:19:57 -08:00
|
|
|
"Register an OpenAI API-compatible backend for gptel with NAME.
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
|
|
|
|
|
Keyword arguments:
|
|
|
|
|
|
|
|
|
|
HOST (optional) is the API host, typically \"api.openai.com\".
|
|
|
|
|
|
|
|
|
|
MODELS is a list of available model names.
|
|
|
|
|
|
|
|
|
|
STREAM is a boolean to toggle streaming responses, defaults to
|
|
|
|
|
false.
|
|
|
|
|
|
|
|
|
|
PROTOCOL (optional) specifies the protocol, https by default.
|
|
|
|
|
|
|
|
|
|
ENDPOINT (optional) is the API endpoint for completions, defaults to
|
|
|
|
|
\"/v1/chat/completions\".
|
|
|
|
|
|
|
|
|
|
HEADER (optional) is for additional headers to send with each
|
|
|
|
|
request. It should be an alist or a function that retuns an
|
|
|
|
|
alist, like:
|
|
|
|
|
((\"Content-Type\" . \"application/json\"))
|
|
|
|
|
|
|
|
|
|
KEY (optional) is a variable whose value is the API key, or
|
2024-01-19 14:19:22 -08:00
|
|
|
function that returns the key."
|
|
|
|
|
(declare (indent 1))
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
(let ((backend (gptel--make-openai
|
|
|
|
|
:name name
|
|
|
|
|
:host host
|
|
|
|
|
:header header
|
|
|
|
|
:key key
|
|
|
|
|
:models models
|
|
|
|
|
:protocol protocol
|
|
|
|
|
:endpoint endpoint
|
|
|
|
|
:stream stream
|
|
|
|
|
:url (if protocol
|
|
|
|
|
(concat protocol "://" host endpoint)
|
|
|
|
|
(concat host endpoint)))))
|
|
|
|
|
(prog1 backend
|
|
|
|
|
(setf (alist-get name gptel--known-backends
|
|
|
|
|
nil nil #'equal)
|
|
|
|
|
backend))))
|
|
|
|
|
|
|
|
|
|
;;; Azure
|
|
|
|
|
;;;###autoload
|
|
|
|
|
(cl-defun gptel-make-azure
|
|
|
|
|
(name &key host
|
|
|
|
|
(protocol "https")
|
|
|
|
|
(header (lambda () `(("api-key" . ,(gptel--get-api-key)))))
|
|
|
|
|
(key 'gptel-api-key)
|
|
|
|
|
models stream endpoint)
|
|
|
|
|
"Register an Azure backend for gptel with NAME.
|
|
|
|
|
|
|
|
|
|
Keyword arguments:
|
|
|
|
|
|
|
|
|
|
HOST is the API host.
|
|
|
|
|
|
|
|
|
|
MODELS is a list of available model names.
|
|
|
|
|
|
|
|
|
|
STREAM is a boolean to toggle streaming responses, defaults to
|
|
|
|
|
false.
|
|
|
|
|
|
|
|
|
|
PROTOCOL (optional) specifies the protocol, https by default.
|
|
|
|
|
|
|
|
|
|
ENDPOINT is the API endpoint for completions.
|
|
|
|
|
|
|
|
|
|
HEADER (optional) is for additional headers to send with each
|
|
|
|
|
request. It should be an alist or a function that retuns an
|
|
|
|
|
alist, like:
|
|
|
|
|
((\"Content-Type\" . \"application/json\"))
|
|
|
|
|
|
|
|
|
|
KEY (optional) is a variable whose value is the API key, or
|
2023-10-29 00:31:56 -07:00
|
|
|
function that returns the key.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
(gptel-make-azure
|
|
|
|
|
\"Azure-1\"
|
|
|
|
|
:protocol \"https\"
|
2023-10-31 20:18:00 -07:00
|
|
|
:host \"RESOURCE_NAME.openai.azure.com\"
|
|
|
|
|
:endpoint
|
|
|
|
|
\"/openai/deployments/DEPLOYMENT_NAME/completions?api-version=2023-05-15\"
|
2023-10-29 00:31:56 -07:00
|
|
|
:stream t
|
2023-10-31 20:18:00 -07:00
|
|
|
:models \\='(\"gpt-3.5-turbo\" \"gpt-4\"))"
|
2024-01-19 14:19:22 -08:00
|
|
|
(declare (indent 1))
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
(let ((backend (gptel--make-openai
|
|
|
|
|
:name name
|
|
|
|
|
:host host
|
|
|
|
|
:header header
|
|
|
|
|
:key key
|
|
|
|
|
:models models
|
|
|
|
|
:protocol protocol
|
|
|
|
|
:endpoint endpoint
|
|
|
|
|
:stream stream
|
|
|
|
|
:url (if protocol
|
|
|
|
|
(concat protocol "://" host endpoint)
|
|
|
|
|
(concat host endpoint)))))
|
|
|
|
|
(prog1 backend
|
|
|
|
|
(setf (alist-get name gptel--known-backends
|
|
|
|
|
nil nil #'equal)
|
|
|
|
|
backend))))
|
|
|
|
|
|
|
|
|
|
;; GPT4All
|
|
|
|
|
;;;###autoload
|
|
|
|
|
(defalias 'gptel-make-gpt4all 'gptel-make-openai
|
|
|
|
|
"Register a GPT4All backend for gptel with NAME.
|
|
|
|
|
|
|
|
|
|
Keyword arguments:
|
|
|
|
|
|
|
|
|
|
HOST is where GPT4All runs (with port), typically localhost:8491
|
|
|
|
|
|
|
|
|
|
MODELS is a list of available model names.
|
|
|
|
|
|
|
|
|
|
STREAM is a boolean to toggle streaming responses, defaults to
|
|
|
|
|
false.
|
|
|
|
|
|
|
|
|
|
PROTOCOL specifies the protocol, https by default.
|
|
|
|
|
|
|
|
|
|
ENDPOINT (optional) is the API endpoint for completions, defaults to
|
|
|
|
|
\"/api/v1/completions\"
|
|
|
|
|
|
|
|
|
|
HEADER (optional) is for additional headers to send with each
|
|
|
|
|
request. It should be an alist or a function that retuns an
|
|
|
|
|
alist, like:
|
|
|
|
|
((\"Content-Type\" . \"application/json\"))
|
|
|
|
|
|
|
|
|
|
KEY (optional) is a variable whose value is the API key, or
|
|
|
|
|
function that returns the key. This is typically not required for
|
2023-10-29 00:31:56 -07:00
|
|
|
local models like GPT4All.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
(gptel-make-gpt4all
|
|
|
|
|
\"GPT4All\"
|
|
|
|
|
:protocol \"http\"
|
|
|
|
|
:host \"localhost:4891\"
|
2023-10-31 20:18:00 -07:00
|
|
|
:models \\='(\"mistral-7b-openorca.Q4_0.gguf\"))")
|
gptel: Add multi-llm support
README.org: Update README with new information and a multi-llm demo.
gptel.el (gptel-host, gptel--known-backends, gptel--api-key,
gptel--create-prompt, gptel--request-data, gptel--parse-buffer, gptel-request,
gptel--parse-response, gptel--openai, gptel--debug, gptel--restore-state,
gptel, gptel-backend):
Integrate multiple LLMs through the introcution of gptel-backends. Each backend
is composed of two pieces:
1. An instance of a cl-struct, containing connection, authentication and model
information. See the cl-struct `gptel-backend` for details. A separate
cl-struct type is defined for each supported backend (OpenAI, Azure, GPT4All and
Ollama) that inherits from the generic gptel-backend type.
2. cl-generic implementations of specific tasks, like gathering up and
formatting context (previous user queries and LLM responses), parsing responses
or responses streams etc. The four tasks currently specialized this way are
carried out by `gptel--parse-buffer` and `gptel--request-data` (for constructing
the query) and `gptel--parse-response` and `gptel-curl--parse-stream` (for
parsing the response). See their implementations for details. Some effort has
been made to limit the number of times dispatching is done when reading
streaming responses.
When a backend is created, it is registered in the collection
`gptel--known-backends` and can be accessed by name later, such as from the
transient menu.
Only one of these backends is active at any time in a buffer, stored in the
buffer-local variable `gptel-backend`. Most messaging, authentication etc
accounts for the active backend, although there might be some leftovers.
When using `gptel-request` or `gptel-send`, the active backend can be changed or
let-bound.
- Obsolete `gptel-host`
- Fix the rear-sticky property when restoring sessions from files.
- Document some variables (not user options), like `gptel--debug`
gptel-openai.el (gptel-backend, gptel-make-openai, gptel-make-azure,
gptel-make-gpt4all): This file (currently always loaded) sets up the generic
backend struct and includes constructors for creating OpenAI, GPT4All and Azure
backends. They all use the same API so a single set of defgeneric
implemenations suffices for all of them.
gptel-ollama.el (gptel-make-ollama): This file includes the cl-struct,
constructor and requisite defgeneric implementations for Ollama support.
gptel-transient.el (gptel-menu, gptel-provider-variable, gptel--infix-provider,
gptel-suffix-send):
- Provide access to all available LLM backends and models from `gptel-menu`.
- Adjust keybindings in gptel-menu: setting the model and query parameters is
now bound to two char keybinds, while redirecting input and output is bound to
single keys.
2023-10-23 23:40:52 -07:00
|
|
|
|
|
|
|
|
(provide 'gptel-openai)
|
|
|
|
|
;;; gptel-backends.el ends here
|
