Введение

В этом документе подробно описаны интерфейсы и структуры данных, необходимые для реализации плагинов моделей Интеллос. Он служит техническим справочником для разработчиков, интегрирующих ИИ-модели с платформой Интеллос.
Прежде чем переходить к этому справочнику по API, рекомендуем прочитать Правила проектирования моделей, чтобы понять концептуальную модель, и Создание нового поставщика модели — пошаговое руководство.

Быстрое решение: какой метод реализовывать?

Каждый поставщик также реализует validate_provider_credentials (аутентификация на уровне поставщика) и, если модель настраивается пользователем, validate_credentials для каждого типа модели.

Реализация поставщика

Узнайте, как реализовать классы поставщика модели для различных поставщиков ИИ-сервисов

Типы моделей

Детали реализации пяти поддерживаемых типов моделей: LLM, Embedding, Rerank, Speech2Text и Text2Speech

Структуры данных

Полный справочник по всем структурам данных, используемым в API модели

Обработка ошибок

Рекомендации по правильному сопоставлению ошибок и обработке исключений

Поставщик модели

Каждый поставщик модели должен наследоваться от базового класса __base.model_provider.ModelProvider и реализовывать интерфейс проверки учётных данных.

Проверка учётных данных поставщика

dict
Информация об учётных данных, как определено в YAML-конфигурации поставщика в разделе provider_credential_schema. Обычно включает такие поля, как api_key, organization_id и т. п.
Если проверка не пройдена, ваша реализация должна вызвать исключение CredentialsValidateFailedError. Это обеспечивает корректную обработку ошибок в интерфейсе Интеллос.
Для предопределённых поставщиков моделей следует реализовать тщательный метод проверки, который убеждается, что учётные данные работают с вашим API. Для поставщиков пользовательских моделей (где у каждой модели свои учётные данные) достаточно упрощённой реализации.

Модели

Интеллос поддерживает пять различных типов моделей, каждый из которых требует реализации определённых интерфейсов. При этом все типы моделей разделяют некоторые общие требования.

Общие интерфейсы

Каждая реализация модели, независимо от типа, должна реализовывать эти два основных метода:

1. Проверка учётных данных модели

string
required
Идентификатор конкретной модели для проверки (например, “gpt-4”, “claude-3-opus”)
dict
required
Информация об учётных данных, как определено в конфигурации поставщика

2. Сопоставление ошибок

class
Сбои сетевого подключения, тайм-ауты
class
Поставщик сервиса недоступен или не работает
class
Достигнуты лимиты частоты запросов или квоты
class
Проблемы аутентификации или прав доступа
class
Недопустимые параметры или запросы
В качестве альтернативы вы можете вызывать эти стандартизированные типы ошибок напрямую в своём коде вместо того, чтобы полагаться на сопоставление ошибок. Такой подход даёт больше контроля над сообщениями об ошибках.

Реализация LLM

Чтобы реализовать поставщика большой языковой модели, наследуйтесь от базового класса __base.large_language_model.LargeLanguageModel и реализуйте эти методы:

1. Вызов модели

Этот основной метод обрабатывает как потоковые, так и непотоковые вызовы API языковых моделей.
string
required
Идентификатор модели (например, “gpt-4”, “claude-3”)
dict
required
Учётные данные для аутентификации в API
list[PromptMessage]
required
Список сообщений в стандартизированном формате Интеллос:
  • Для моделей completion: включите единственное сообщение UserPromptMessage
  • Для моделей chat: включите SystemPromptMessage, UserPromptMessage, AssistantPromptMessage, ToolPromptMessage по необходимости
dict
required
Параметры, специфичные для модели (temperature, top_p и т. п.), как определено в YAML-конфигурации модели
list[PromptMessageTool]
Определения инструментов для возможностей вызова функций
list[string]
Последовательности остановки, при обнаружении которых генерация модели прекращается
boolean
default:true
Возвращать ли потоковый ответ
string
Идентификатор пользователя для мониторинга API
Generator[LLMResultChunk, None, None]
Генератор, выдающий чанки ответа по мере их поступления
LLMResult
Полный объект ответа с целиком сгенерированным текстом
Рекомендуем реализовать отдельные вспомогательные методы для потоковых и непотоковых вызовов, чтобы код оставался организованным и удобным в сопровождении.

2. Подсчёт токенов

Если модель не предоставляет токенизатор, для приемлемой оценки можно использовать метод базового класса _get_num_tokens_by_gpt2(text).

3. Схема пользовательской модели (необязательно)

Этот метод необходим только для поставщиков, которые поддерживают пользовательские модели. Он позволяет пользовательским моделям наследовать правила параметров от базовых моделей.

Реализация TextEmbedding

Модели текстовых эмбеддингов преобразуют текст в высокоразмерные векторы, отражающие семантический смысл, что полезно для поиска, поиска по сходству и классификации.
Чтобы реализовать поставщика текстовых эмбеддингов, наследуйтесь от базового класса __base.text_embedding_model.TextEmbeddingModel:

1. Основной метод эмбеддинга

string
required
Идентификатор эмбеддинг-модели
dict
required
Учётные данные для аутентификации в сервисе эмбеддингов
list[string]
required
Список текстовых входных данных для эмбеддинга
string
Идентификатор пользователя для мониторинга API
object
required
Структурированный ответ, содержащий:
  • model: модель, использованная для эмбеддинга
  • embeddings: список эмбеддинг-векторов, соответствующих входным текстам
  • usage: метаданные об использовании токенов и стоимости

2. Метод подсчёта токенов

Для эмбеддинг-моделей точный подсчёт токенов важен для оценки стоимости, но не критичен для работоспособности. Метод _get_num_tokens_by_gpt2 даёт приемлемую оценку для большинства моделей.

Реализация Rerank

Реранкинг-модели помогают улучшить качество поиска, переупорядочивая набор документов-кандидатов на основе их релевантности запросу, как правило, после начального этапа поиска.
Чтобы реализовать поставщика реранкинга, наследуйтесь от базового класса __base.rerank_model.RerankModel:
string
required
Идентификатор реранкинг-модели
dict
required
Учётные данные для аутентификации в API
string
required
Текст поискового запроса
list[string]
required
Список текстов документов для реранкинга
float
Необязательный минимальный порог оценки для фильтрации результатов
int
Необязательное ограничение на количество возвращаемых результатов
string
Идентификатор пользователя для мониторинга API
object
required
Структурированный ответ, содержащий:
  • model: модель, использованная для реранкинга
  • docs: список объектов RerankDocument с полями index, text и score
Реранкинг может требовать значительных вычислительных ресурсов, особенно при больших наборах документов. Реализуйте пакетную обработку для крупных коллекций документов, чтобы избежать тайм-аутов или чрезмерного потребления ресурсов.

Реализация Speech2Text

Модели распознавания речи преобразуют устную речь из аудиофайлов в письменный текст, делая возможными такие приложения, как сервисы транскрипции, голосовые команды и функции доступности.
Чтобы реализовать поставщика распознавания речи, наследуйтесь от базового класса __base.speech2text_model.Speech2TextModel:
string
required
Идентификатор модели распознавания речи
dict
required
Учётные данные для аутентификации в API
IO[bytes]
required
Бинарный файловый объект, содержащий аудио для транскрибирования
string
Идентификатор пользователя для мониторинга API
string
required
Текст, транскрибированный из аудиофайла
Определение формата аудио важно для корректной обработки разных типов файлов. Рассмотрите возможность реализации вспомогательного метода для определения формата по заголовку файла, как показано в примере.
Некоторые API распознавания речи имеют ограничения на размер файла. При необходимости рассмотрите реализацию чанкинга для больших аудиофайлов.

Реализация Text2Speech

Модели синтеза речи преобразуют письменный текст в естественно звучащую речь, делая возможными такие приложения, как голосовые ассистенты, программы чтения с экрана и генерация аудиоконтента.
Чтобы реализовать поставщика синтеза речи, наследуйтесь от базового класса __base.text2speech_model.Text2SpeechModel:
string
required
Идентификатор модели синтеза речи
dict
required
Учётные данные для аутентификации в API
string
required
Текстовое содержимое для преобразования в речь
boolean
required
Возвращать ли потоковое аудио или полный файл
string
Идентификатор пользователя для мониторинга API
Generator[bytes, None, None]
Генератор, выдающий аудиочанки по мере их поступления
bytes
Полные аудиоданные в виде байтов
Большинство API синтеза речи требуют указывать голос вместе с моделью. Рассмотрите возможность реализации сопоставления между идентификаторами моделей Интеллос и вариантами голоса поставщика.
Длинные текстовые входные данные может потребоваться разбить на чанки для лучшего качества синтеза речи. Рассмотрите реализацию предварительной обработки текста для корректной обработки пунктуации, чисел и специальных символов.

Реализация Moderation

Модели модерации анализируют контент на наличие потенциально вредоносного, неуместного или небезопасного материала, помогая поддерживать безопасность платформы и соблюдение политик в отношении контента.
Чтобы реализовать поставщика модерации, наследуйтесь от базового класса __base.moderation_model.ModerationModel:
string
required
Идентификатор модели модерации
dict
required
Учётные данные для аутентификации в API
string
required
Текстовое содержимое для анализа
string
Идентификатор пользователя для мониторинга API
boolean
required
Булево значение, указывающее на безопасность контента:
  • False: контент безопасен
  • True: контент содержит вредоносный материал
Модерация часто используется как механизм безопасности. При реализации своего решения учитывайте последствия ложноотрицательных срабатываний (пропуск вредоносного контента) и ложноположительных (блокировка безопасного контента).
Многие API модерации предоставляют детальные оценки по категориям, а не только бинарный результат. Рассмотрите возможность расширения этой реализации, чтобы возвращать более подробную информацию о конкретных категориях вредоносного контента, если этого требует ваше приложение.

Сущности

PromptMessageRole

Роль сообщения

PromptMessageContentType

Тип содержимого сообщения, разделённый на обычный текст и изображения.

PromptMessageContent

Базовый класс содержимого сообщения, используется только для объявления параметров, не может быть инициализирован.
В настоящее время поддерживаются два типа: текст и изображения; можно одновременно использовать текст и несколько изображений. Необходимо отдельно инициализировать TextPromptMessageContent и ImagePromptMessageContent.

TextPromptMessageContent

При передаче текста и изображений текст нужно сконструировать как эту сущность в составе списка content.

ImagePromptMessageContent

При передаче текста и изображений изображения нужно сконструировать как эту сущность в составе списка content. data может быть url или строкой изображения в кодировке base64.

PromptMessage

Базовый класс для всех тел сообщений Role, используется только для объявления параметров, не может быть инициализирован.

UserPromptMessage

Тело сообщения UserMessage, представляет сообщения пользователя.

AssistantPromptMessage

Представляет сообщения-ответы модели, обычно используется для few-shots или ввода истории чата.
Здесь tool_calls — это список tool call, возвращаемый моделью после передачи ей tools.

SystemPromptMessage

Представляет системные сообщения, обычно используется для задания системных инструкций модели.

ToolPromptMessage

Представляет сообщения инструментов, используется для передачи результатов модели для планирования следующего шага после того, как инструмент был выполнен.
Поле content базового класса передаёт результат выполнения инструмента.

PromptMessageTool

LLMResult

LLMResultChunkDelta

Сущность delta для каждой итерации в потоковом ответе

LLMResultChunk

Сущность итерации в потоковом ответе

LLMUsage

TextEmbeddingResult

EmbeddingUsage

RerankResult

RerankDocument

Связанные ресурсы


Edit this page | Report an issue