Mistral API подключают к внутреннему сервису через серверный вызов: создают ключ для рабочего пространства, выбирают доступную модель и отправляют запрос на официальный endpoint. Ответ модели подходит для подготовки текста или объяснения, а запись в учётную систему проходит через правила сервера и подтверждение человека. Такой путь уместен, когда компания готова передавать отобранные данные облачному сервису.
Граница вызова
Рабочая связка состоит из серверного ключа, вызова POST https://api.mistral.ai/v1/chat/completions и проверки результата до любых действий в бизнес-системе.
Представим внутренний экран поддержки: сотрудник открывает заявку, сервис берёт уже очищенное описание проблемы и просит модель предложить черновик ответа. Скрипт получает полные данные заявки, удаляет лишние поля и собирает короткий контекст. Модель объясняет ситуацию по переданному фрагменту. Сотрудник сверяет объяснение с заявкой, а сервер проверяет права на изменение карточки и ждёт подтверждения перед сохранением. Так видна польза API без передачи модели роли администратора.
Здесь речь об облачном вызове Mistral; запуск весов на собственном оборудовании разбирается отдельно. Для выбора между облаком и своим сервером пригодится разбор открытых моделей Mistral. Внутреннему сервису нужен ясный контракт: какие поля он отправляет, какой ответ ждёт и что делает при сбое. Этот контракт записывают до кода, поскольку красивый ответ модели сам по себе оставляет вопрос о допустимости операции открытым.
Для первой проверки возьмите одну задачу: объяснение заявки по её обезличенному фрагменту. Полезный выход — черновик, основанный на переданных фактах; опасный выход — уверенное добавление обстоятельств, которых во входе нет. Зафиксируйте оба случая как критерии проверки. Документация Mistral описывает первый API-запрос; состав бизнес-данных и порог допуска остаются решением вашей команды.
Ключ и модель
Начните с рабочего пространства в Mistral Studio и создайте отдельный ключ для проекта внутреннего сервиса. По правилам Mistral, ключ привязан к рабочему пространству; там учитываются его квоты и права. Название ключа связывайте с назначением, храните значение в менеджере секретов либо переменной окружения серверного процесса. Полный ключ показывается при создании, поэтому порядок хранения продумайте заранее. Серверный процесс читает секрет из настроенного хранилища, а браузер пользователя видит только ваш серверный маршрут.
Для тестового и рабочего окружения заведите разные пространства и ключи, если структура вашей организации это позволяет. Так расход и сбои теста проще отличить от работы сотрудников. Ротацию проводите с проверкой нового ключа до удаления прежнего. Логи должны содержать имя окружения и технический идентификатор вызова, но исключать значение секрета, текст заявки и полный ответ модели. При подозрении на утечку ключ отзывают через панель управления, затем проверяют доступ сервиса с новым секретом.
Модель выбирают по доступности в своём рабочем пространстве и результату на своих примерах. Список можно запросить через GET https://api.mistral.ai/v1/models с заголовком Authorization: Bearer и вашим ключом; этот маршрут указан в документации рабочих пространств. Возьмите идентификатор из ответа и сохраните его в настройке сервиса. Копировать название из старого примера рискованно: доступность меняется. Для более широкой проверки языковых задач полезна статья о выборе модели Mistral для компании.
После выбора сравните черновики на одинаковых очищенных заявках: точность фактов, читаемость русского текста, случаи пропуска существенного условия. Такой набор важнее общего рейтинга. Решение о смене модели записывают вместе с версией тестового набора, чтобы команда понимала причину следующего изменения.
Первый запрос
Тестовый вызов проводите с вымышленной заявкой. Перед первым запросом проверьте, что переменная MISTRAL_API_KEY задана на сервере и отсутствует в коде приложения. В тело отправляйте выбранный идентификатор модели и массив messages с ролью user и коротким содержимым. Официальный пример Mistral Studio показывает адрес, заголовки и формат такого вызова. Ответ ищите в поле choices[].message.content; дальше включается ваша проверка формы и смысла.
- Откройте заявку с синтетическим текстом: «Клиент просит уточнить состав заказа, номер заказа скрыт». Сформулируйте задачу модели как подготовку черновика без добавления новых фактов.
- Получите список доступных моделей для рабочего пространства. Сохраните выбранный идентификатор в конфигурации сервера, рядом с названием тестового окружения.
- Отправьте запрос на
/v1/chat/completionsс заголовкамиAuthorization: BearerиContent-Type: application/json. Проверьте код ответа и наличие текстового содержимого. - Сравните черновик с исходной заявкой: факты, просьба клиента, лишние обещания. Отметьте результат в журнале теста и только затем покажите черновик сотруднику.
Для внутреннего сервиса ответ лучше превратить в объект своей схемы: исходная заявка, черновик, статус проверки, причина отказа. Поле с текстом модели может оказаться пустым или содержать ответ вне ожидаемой задачи; такая запись остаётся черновиком с ошибкой. Отправлять письмо до проверки нельзя. Сервис задаёт ограничения длины входа и выхода, контролирует сетевой таймаут и сохраняет признак версии инструкции. Эти настройки нужны для повторяемой диагностики.
На этом шаге важно отделить исправный транспорт от качества текста. Успешный HTTP-ответ доказывает доступ к API, но фактологическую точность устанавливает сверка человеком. Для следующего теста меняйте по одному элементу: модель, инструкция либо состав полей. Так причина изменения в результате остаётся понятной.
Ошибки и данные
Ответы сервера и смысловые ошибки требуют разных действий. Код ошибки говорит, дошёл ли вызов и где искать причину. Уверенный черновик с придуманным фактом требует проверки источника и инструкции. Подмена одной проверки другой оставляет риск: API возвращает ответ, а сотрудник получает ложное объяснение. Документация Mistral отдельно описывает ошибки API; внутреннее правило реакции задаёт команда.
| Сигнал | Проверка сервера | Действие команды |
|---|---|---|
| Ошибка запроса | Формат JSON, обязательные поля, выбранная модель | Исправить тело вызова и повторить синтетический тест |
| Ошибка доступа | Ключ, окружение, права рабочего пространства | Проверить секрет и разрешённый доступ |
| Ограничение вызовов | Журнал частоты и ответ API | Отложить повтор с увеличением интервала |
| Временный сбой | Код ответа, таймаут, идентификатор вызова | Передать заявку на ручную обработку |
| Лишний факт в тексте | Исходная заявка и черновик рядом | Отклонить черновик, проверить вход и инструкцию |
Повтор запроса после ограничения или временного сбоя допустим с паузой и пределом попыток. Решение о записи в CRM, отправке письма или смене статуса заявки живёт за пределами вызова модели. Сервер проверяет право сотрудника на действие и наличие его подтверждения; при отсутствии любого условия операция останавливается. Даже точный текст модели остаётся предложением до сверки фактов человеком с карточкой и журналом переписки.
Перед отправкой данных определите разрешённые поля. Для черновика ответа часто хватает темы и очищенного описания обращения; телефоны, адреса и вложения проходят отдельную оценку необходимости. Если политика компании требует особого режима хранения, проверьте условия хранения данных Mistral для выбранного режима: расширенные настройки требуют отдельного включения и охватывают определённые вызовы. Запись исходного текста в собственные логи тоже проверьте.
Обсудим подключение Mistral API к вашему сервису: данные, права и проверку ответа
Допуск в работу
Перед пилотом соберите короткий журнал прогонов: очищенный вход, идентификатор модели, версия инструкции, технический статус и отметка сотрудника о точности. Полный текст заявки хранится в исходной системе по её правилам доступа. В журнале хватает ссылки на внутреннюю карточку, доступную только уполномоченным. Такой набор позволяет воспроизвести ошибку и понять, связана она с данными, сетью, выбором модели или проверкой человеком.
Критерий допуска привяжите к конкретной задаче и выразите через ясные признаки годного черновика. Для черновика поддержки это отсутствие добавленных обязательств, сохранение важных фактов и понятная передача на проверку. Сотрудник отмечает расхождение по каждому пункту; владелец процесса рассматривает спорные примеры. Если модель пропускает важное условие, верните черновик в ручную обработку, поправьте состав входа или инструкцию и повторите тот же набор. Автоматическая отправка ответа требует отдельного решения владельца процесса и серверных правил.
Пилот можно предложить для одного типа заявок и группы сотрудников, у которых есть право сверять такие обращения. Сначала выясните, кто владеет ключом, кто отвечает за структуру данных и кто подтверждает итоговый текст. Затем согласуйте порядок остановки вызовов при массовых ошибках и способ возврата к ручному маршруту. Расход API отслеживайте по рабочему пространству, а состав работ по интеграции обсуждайте после разбора процесса и требований к данным.
Возьмите синтетическую заявку и опишите допустимый черновик рядом с исходными фактами. Проверьте ключ, список моделей и один вызов, затем разберите ответ вместе с владельцем процесса. Если нужен проектный маршрут с правами, журналом и приёмкой, обсудите с нами внедрение ИИ во внутренний сервис. Состав работ и стоимость определим после знакомства с задачей.