← Блог

Perplexity Decisions API: почему имя модели не фиксирует версию

Разбор документации Perplexity: восемь имён моделей, текущие маршруты, поле model и пределы воспроизводимости. Своя проверенная матрица без вызова API.

Perplexity Decisions API: почему имя модели не фиксирует версию

В Perplexity Decisions API строка pplx-decider-v1.1-27b уже не означает, что запрос обслужит версия v1.1. По текущей документации это имя направляет запрос к pplx-decider-v1.2. Поэтому старое название в настройках и то же название в ответе ещё не подтверждают неизменность модели.

Ниже — разбор официальной документации, проверенной 19 октября 2026 года. Мы не вызывали API и не измеряли ответы Perplexity. Собственный результат — матрица восьми имён и выполненная проверка её состава, маршрутов и правил записи. Она помогает понять, какие сведения нужно сохранить перед сравнением результатов.

Разделите три разных сведения

Имя в запросе — значение, которое приложение отправляет в поле model. Документированный маршрут — модель, к которой это имя сейчас должно вести по правилам поставщика. Фактически обслужившая версия — отдельный вопрос: её нельзя установить по любой похожей строке в ответе.

В руководстве Decisions API указано: поле model ответа повторяет отправленное имя. Если запросить pplx-decider-latest, ответ с таким же значением не раскрывает конкретную обслужившую версию. Это правило документации; реального ответа API в нашем примере нет.

Представьте условный редакционный архив. Две конфигурации распределяют документы по категориям: обычная и быстрая. Разработчик сохраняет название модели рядом с каждым результатом. Через некоторое время он сравнивает новые решения со старыми. Для вывода о сопоставимости одной одинаковой строки недостаточно: сначала нужно проверить, не изменился ли её маршрут.

Матрица восьми имён

Официальный журнал изменений описывает замену прежней модели, два псевдонима latest и варианты с префиксом. Мы свели эти правила в таблицу. Правая колонка показывает документированный маршрут на дату проверки, а не результат отправленного запроса.

Имя, указанное в запросеТекущий маршрут по документации
pplx-decider-v1.2pplx-decider-v1.2
pplx-decider-latestpplx-decider-v1.2
perplexity/pplx-decider-latestpplx-decider-v1.2
pplx-decider-v1.1-27bpplx-decider-v1.2
pplx-decider-v1-27bpplx-decider-v1.2
pplx-decider-flash-v1.2pplx-decider-flash-v1.2
pplx-decider-flash-latestpplx-decider-flash-v1.2
perplexity/pplx-decider-flash-latestpplx-decider-flash-v1.2

Одинаковый маршрут в нескольких строках не означает одинаковое назначение имён. Версионное имя называет выпуск, а latest следует за новой версией своей модели. Префикс perplexity/ у двух перечисленных псевдонимов не создаёт отдельную модель. Эти сведения не относятся к обычному веб-чату Perplexity.

Что мы проверили самостоятельно

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

Локальный скрипт подтвердил: все восемь имён различны; пять записей относятся к основной модели и три — к Flash; неизвестных направлений нет. Он также проверил, что каждая запись сохраняет исходную строку имени и не обозначена как наблюдённый серверный ответ. Все имена сопоставлены с сохранённым текстом официального руководства.

Такой контроль выявляет ошибку в нашей таблице или пропущенную конфигурацию. Он не подтверждает работу удалённого сервера, точность классификации, доступ конкретного аккаунта или сохранность прежних вероятностей. Эти вопросы требуют отдельного обращения к сервису и проверки на своей задаче.

Как сохранить возможность сравнения

Для условного архива полезно вести две записи: неизменённую настройку приложения и датированное описание маршрута из документации. Тогда после изменения правил можно увидеть, что именно осталось прежним. Не заменяйте старое значение в журнале задним числом: иначе исчезнет различие между тем, что отправляло приложение, и тем, что позднее объявил поставщик.

Перед сравнением сохраните исходный документ, вопросы, порядок их объединения и критерии оценки. Если приложение использует порог вероятности, подготовьте контрольную выборку с известными решениями. После смены модели проверьте этот порог заново — такую рекомендацию даёт руководство Perplexity. Мы её не выполняли на сервисе и не предлагаем вымышленные числовые результаты.

Версионное имя тоже не даёт бессрочной гарантии: документация допускает перенаправление после вывода версии из эксплуатации. Если для вашей процедуры нужна строгая воспроизводимость, выясните доступные гарантии у поставщика и запишите границы проверки. Когда точную обслужившую версию установить нельзя, это ограничение должно остаться в отчёте.

Что считать итогом проверки

Для нашего примера итог конкретен: восемь настроек описывают два текущих документированных направления, а повторённое имя в поле model не доказывает, какой выпуск обработал запрос. Прежде чем объяснять разницу результатов новым запросом или порогом, проверьте историю маршрута. Матрица фиксирует сведения на 19 октября; при следующем сравнении её нужно сверить с руководством и журналом изменений.

Текст подготовлен с помощью GPT. Оригинальная обложка создана GPT Image и служит условной иллюстрацией маршрутов. Практический тест Perplexity не проводился.