Перейти к содержанию

Машинный перевод

Эта страница была автоматически переведена ИИ и может содержать ошибки. Если что-то неясно, обращайтесь к английскому источнику.

Английский источник · Сообщить о проблеме перевода

Режимы бесед

Беседы Perplexity бывают пяти режимов: search / deep-research / computer / council / study. Режим определяется для каждой нити во время экспорта; он определяет, какие ответы API извлекаются, что попадает в каталог нити и какой путь архива получает нить (<account>/<mode>/…). Определённый режим записывается в thread.json (ключ mode) и используется фильтрацией pplx-export batch --mode. pplx-ask также может создавать новые нити в четырёх из пяти режимов (все, кроме computer) — см. pplx-ask.

a. Пять режимов кратко

Режим Имя в UI / модель Содержимое витка Цитаты Продукты Схематизированные блоки извлекаются
search "Best" (pplx_pro; labs STUDIO/pplx_beta также отображаются сюда) Запрос + Ответ, текстовые шаги на уровне витка + всей нити sources.* — Нет (raw_blocks.json отсутствует)
deep-research "Deep research" (pplx_alpha, фиксировано, без селектора) шаги исследования, включая RESEARCH_ANSWER да report.md (полный отчёт) Да
computer Computer (pplx_asi_opus, pplx_asi_opus_thinking) полный workflow_block: повествование, вызовы инструментов, подсказки/шаги субагента, пошаговые цитаты пошаговые + виток + нить версионированные файлы в assets/ + запуски субагентов Да
council model council (pplx_agentic_research; по умолчанию три модели) шаг COUNCIL_RESEARCH; вложенный рабочий процесс LLM_COUNCIL каждой модели свёрнут в <details> (раунды поиска, все источники, полный ответ каждой модели) на модель + агрегированные ответы каждой модели сравниваются бок о бок Да
study Study (pplx_study) шаги/цитаты через блоки (проверено, что также содержат ресурсы) да ресурсы, если присутствуют Да

b. Как определяется режим

Авторитетом для определения является собственное поле платформы entry.search_mode (SEARCH_MODE_MAP, normalize.py:50-59), собранное по всем записям (normalize.py:106-115). Оно было проверено по официальной конфигурации модели (GET /rest/models/config/v2): default_models.search=pplx_pro (UI "Best"), default_models.research=pplx_alpha (UI "Deep research"), и значения отображаются один к одному в режимы бесед:

Значение search_mode Режим
ASI computer
AGENTIC_RESEARCH council
STUDY study
RESEARCH deep-research
SEARCH, STUDIO search

Правила разрешения конфликтов (detect_mode, normalize.py:66-128):

  • Переключение режима внутри одной нити (записи расходятся): берётся наивысший по специфичности — computer > council > study > deep-research > search (_MODE_SPECIFICITY, normalize.py:63) — и log.warning.
  • Конфликт с нижестоящими сигналами (имена шагов / display_model): search_mode побеждает, log.warning (normalize.py:120-123).
  • search_mode полностью отсутствует → исходная цепочка: URL содержит /computer/tasks/ или metadata.mode == '4' или индексный режим ∈ ASI/COMPUTER → computer; шаг COUNCIL_RESEARCH → council; шаг RESEARCH_ANSWER → deep-research; избыточный сигнал display_model (DISPLAY_MODEL_MODE, normalize.py:32-37) побеждает при конфликте; ничего не совпало → search по умолчанию.
  • Отсутствие всех сигналов не означает search: конвейер всё равно извлекает схематизированные блоки (adapter.py:83-89), чтобы дрейф поля платформы не мог незаметно отбросить raw_blocks.json.

Почему pplx_alpha не является сигналом для определения

pplx_alpha — это модель, предназначенная для RESEARCH — она является целью, которую должен обнаружить классификатор, а не свидетельством для обнаружения, поэтому она намеренно исключена из таблицы соответствия (комментарий normalize.py:15-31).

Полное дерево решений со всеми ветвями: Конвейер экспорта — определение режима.

c. Куда попадают полезные данные субагентов

Запуски Computer/council порождают фоновые рабочие процессы субагентов. Каждый фоновый workflow_payload отображается ровно в одном месте, никогда дважды; на уровне пользователя три возможных места размещения:

  1. Привязан — внутри инициирующего витка: виток, запустивший субагента, содержит соответствующий идентификатор полезных данных, поэтому запуск отображается встроенно в рабочем процессе этого витка (turns/turn_NNNN.md), с подсказкой, шагами, ответом и источниками.
  2. Заглушка витка — раздел "子代理工作" (Работа субагента): виток-заглушка subagent_result в пределах 10-секундного окна завершения поглощает полезные данные; ответ не добавляется обратно.
  3. Приложение нити — конец conversation.md: всё оставшееся (прерванные запуски не создают уведомления о завершении, поэтому первые два уровня обязательно пропускают) архивируется дословно под "## 后台任务（未归入轮次）" (Фоновые задачи (не отнесённые к виткам)) — без угадывания привязки ко времени, принимается любой статус.

Правила сопоставления, структуры данных и гарантии однократного потребления: Субагенты и прерывания.

d. Прерывания: незавершённые рабочие процессы

Рабочие процессы, которые не завершились, аннотируются встроенно везде, где они отображаются — в заголовках рабочих процессов, заголовках субагентов и вложенных сводках <details>. Три аннотации (parsers.classify_wf_status, parsers.py:263-284):

Аннотация Условие Значение
⏸ 限额中断（内容截至中断点） (прервано лимитом — содержимое обрывается в точке прерывания) WORKFLOW_AWAITING_NEXT_STEPS + locked_reason=spending_limit_exceeded исчерпан лимит расходов; рабочий процесс остановлен на середине выполнения
⏸ 中断待续 (прервано, ожидает продолжения) WORKFLOW_AWAITING_NEXT_STEPS без locked_reason прервано, может быть продолжено на платформе
⛔ 已取消 (отменено) WORKFLOW_CANCELED отменено пользователем или платформой
  • COMPLETED никогда не аннотируется (здоровые нити получают нулевой diff); неизвестные будущие значения статуса остаются безмолвными.
  • Каждый аннотированный случай также регистрируется в thread.json.interruptions как {location, kind, headline, status} — местоположения выглядят как turn_0007, turn_0011/subagent, turn_0024/subagent_stub, background_unassigned (parsers.py:535-583; ключ отсутствует у здоровых нитей).
  • Возобновление не требует особого случая: когда вы продолжаете прерванную нить на платформе, её lastUpdated изменяется, следующий инкрементальный экспорт повторно извлекает её, и аннотации просто исчезают после завершения рабочего процесса. См. Инкрементальная синхронизация.

Наблюдаемые значения статусов и распределение: Ответы API и ошибки; конечный автомат: Субагенты и прерывания.

e. Варианты перезаписи ответов (answer_variants)

Когда платформа перезаписывает ответ (A/B-эксперименты), заменённый вариант невидим в API — возвращается только выбранный ответ, в то время как проигравший собрат оставляет след в entries[].side_by_side_metadata и может быть позже удалён (подтверждены мёртвые ссылки собратьев: 403 VIEW_THREAD_NOT_ALLOWED). Инструмент делает "перезапись произошла" наблюдаемой:

  • Регистрация: совпадения по суженным критериям записываются в thread.json.answer_variants (fs_writer.py:247-252; ключ отсутствует без совпадений) и добавляются в центральный реестр index/answer_variants_log.jsonl, дедуплицируются по (нить, запись) и идемпотентны (variant_log.py:76).
  • Оповещения: одна строка WARNING, доступная для grep, ANSWER_VARIANT_DETECTED с полными полями местоположения (uuid/uuid8 нити, entry_uuid, sibling_uuid, selection_status, experiment_role) при каждом онлайн-совпадении; re-render повторно регистрируется офлайн и предупреждает только при добавлении или изменении содержимого, поэтому полные перезапуски библиотеки остаются тихими; сводка пакета добавляет счётчик совпадений ⚠.
  • Ручной повторный архив: варианты-собратья эмпирически являются мёртвыми ссылками, поэтому альтернативный ответ обычно не может быть восстановлен через API. При совпадении оперативно подтвердите альтернативный ответ вручную (UI платформы, ваши собственные записи, скриншоты); если вы его получите, запишите его как rewritten_answer_variant.md внутри каталога нити. Если нет, thread.json.answer_variants вместе с реестром jsonl являются окончательной отслеживаемой записью.

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

f. Принципы точности отображения

Независимо от режима, отображение следует одному и тому же контракту точности:

  • Ответы полностью, никогда не усекаются — старый лимит [:4000] был удалён, потому что он обрезал предложения на середине (render.py:645-647).
  • Таблицы никогда не усекаются — WORKFLOW_ITEM_TABLE отображает каждую строку и столбец, экранируя | и символы новой строки в заголовках и ячейках, чтобы структура Markdown сохранялась (render.py:211-243).
  • Полные цитаты — три канала сбора (entry.sources + FINAL.web_results + WORKFLOW_ITEM_SOURCES), дедуплицированные по URL в sources.*; ни одна процитированная не отбрасывается.
  • Сырой JSON API является границей содержимого — всё отображаемое берётся из raw_entries.json / raw_blocks.json; то, что API не возвращает (например, заменённый вариант ответа), не может быть отображено и выводится через реестры вместо того, чтобы быть выдуманным.
  • Складки UI, архив раскрывает — детали, которые веб-UI скрывает за складками и кликами (повествование рабочего процесса Computer и ввод/вывод инструментов, запуски каждой модели council, шаги субагентов), отображаются полностью; блоки <details> сохраняют читаемость структуры документа без потери информации (render.py:46, render.py:404-413).
  • Структурная надёжность — размер блоков кода подгоняется под их содержимое (_fence_for, render.py:28-43), чтобы вывод инструмента, содержащий собственные блоки, не мог нарушить парность, и разделители LaTeX нормализуются до $$ / $ с защищёнными сегментами кода (normalize_math_delims).

Как сохранённые сырые ответы делают всё это регенерируемым офлайн: Конвейер экспорта и Офлайн-операции.

g. См. также