chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
b3edea4d90
commit
74ff95e6a3
@ -2,47 +2,48 @@
|
||||
read_when:
|
||||
- Розширення qa-lab або qa-channel
|
||||
- Додавання QA-сценаріїв, що підтримуються репозиторієм
|
||||
- Побудова реалістичнішої QA-автоматизації навколо панелі Gateway
|
||||
summary: Форма приватної QA-автоматизації для qa-lab, qa-channel, початково підготовлених сценаріїв і звітів протоколу
|
||||
title: QA E2E-автоматизація
|
||||
- Створення автоматизації QA з вищим рівнем реалізму навколо панелі керування Gateway
|
||||
summary: Приватна форма автоматизації QA для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
|
||||
title: Автоматизація QA E2E
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T22:58:57Z"
|
||||
generated_at: "2026-04-24T01:50:42Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8cf607af9e85c1f6908049da2b31a1c6c9eaa1fc95bc3af2136babb1a3b9b48f
|
||||
source_hash: f6924a05faebdd22ac5222db6b9579b57d9c7f3dfac71df6c5f2ee7d2bf0a5f8
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Приватний стек QA призначений для того, щоб перевіряти OpenClaw у більш реалістичний,
|
||||
схожий на справжні канали спосіб, ніж це може зробити один unit-тест.
|
||||
Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
|
||||
орієнтований на канали спосіб, ніж це може зробити один unit-тест.
|
||||
|
||||
Поточні складові:
|
||||
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, треду,
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки,
|
||||
реакцій, редагування та видалення.
|
||||
- `extensions/qa-lab`: UI для налагодження та QA-шина для спостереження за транскриптом,
|
||||
ін’єкції вхідних повідомлень і експорту Markdown-звіту.
|
||||
- `qa/`: початкові ресурси, що підтримуються репозиторієм, для стартового завдання та базових QA-сценаріїв.
|
||||
- `extensions/qa-lab`: UI налагодження та QA-шина для спостереження за транскриптом,
|
||||
інʼєкції вхідних повідомлень і експорту звіту у Markdown.
|
||||
- `qa/`: ресурси початкових даних, що підтримуються репозиторієм, для стартового завдання та базових QA-
|
||||
сценаріїв.
|
||||
|
||||
Поточний робочий процес QA-оператора — це двопанельний QA-сайт:
|
||||
Поточний робочий процес QA-оператора — це двопанельний сайт QA:
|
||||
|
||||
- Ліворуч: панель Gateway (Control UI) з агентом.
|
||||
- Ліворуч: панель керування Gateway (Control UI) з агентом.
|
||||
- Праворуч: QA Lab, де показано схожий на Slack транскрипт і план сценарію.
|
||||
|
||||
Запустіть його так:
|
||||
Запустіть так:
|
||||
|
||||
```bash
|
||||
pnpm qa:lab:up
|
||||
```
|
||||
|
||||
Це збирає QA-сайт, запускає lane Gateway на базі Docker і відкриває
|
||||
сторінку QA Lab, де оператор або цикл автоматизації можуть дати агенту QA-місію,
|
||||
спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що зламалося або
|
||||
що залишилося заблокованим.
|
||||
Це збирає QA-сайт, запускає доріжку gateway на базі Docker і відкриває
|
||||
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-
|
||||
місію, спостерігати реальну поведінку каналу й фіксувати, що спрацювало,
|
||||
що не спрацювало або що залишилося заблокованим.
|
||||
|
||||
Щоб швидше ітерувати UI QA Lab без перебудови Docker-образу щоразу,
|
||||
запустіть стек із bind-mounted bundle QA Lab:
|
||||
Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу,
|
||||
запустіть стек із bind-mounted збіркою QA Lab:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa docker-build-image
|
||||
@ -51,165 +52,167 @@ pnpm qa:lab:up:fast
|
||||
pnpm qa:lab:watch
|
||||
```
|
||||
|
||||
`qa:lab:up:fast` тримає сервіси Docker на попередньо зібраному образі та bind-mount-ить
|
||||
`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mount
|
||||
`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
|
||||
перебудовує цей bundle при змінах, а браузер автоматично перезавантажується, коли хеш ресурсів QA Lab змінюється.
|
||||
перезбирає цю збірку при змінах, а браузер автоматично перезавантажується, коли
|
||||
змінюється хеш ресурсу QA Lab.
|
||||
|
||||
Для smoke-lane Matrix із реальним транспортом виконайте:
|
||||
Для smoke-доріжки Matrix з реальним транспортом виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa matrix
|
||||
```
|
||||
|
||||
Цей lane створює тимчасовий homeserver Tuwunel у Docker, реєструє
|
||||
тимчасових користувачів driver, SUT та observer, створює одну приватну кімнату, а потім запускає
|
||||
справжній Plugin Matrix усередині дочірнього QA gateway. Lane із живим транспортом тримає
|
||||
конфігурацію дочірнього процесу обмеженою транспортом, який тестується, тому Matrix працює без
|
||||
`qa-channel` у конфігурації дочірнього процесу. Він записує артефакти структурованого звіту та
|
||||
об’єднаний журнал stdout/stderr у вибраний вихідний каталог Matrix QA. Щоб
|
||||
також захопити зовнішній вивід збірки/запуску `scripts/run-node.mjs`, установіть
|
||||
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` на локальний для репозиторію файл журналу.
|
||||
Ця доріжка розгортає одноразовий homeserver Tuwunel у Docker, реєструє
|
||||
тимчасових користувачів driver, SUT та observer, створює одну приватну кімнату,
|
||||
а потім запускає реальний Plugin Matrix всередині дочірнього процесу QA gateway. Доріжка живого транспорту тримає
|
||||
конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тому Matrix запускається без
|
||||
`qa-channel` у конфігурації дочірнього процесу. Вона записує структуровані артефакти звіту та
|
||||
обʼєднаний лог stdout/stderr у вибраний вихідний каталог Matrix QA. Щоб
|
||||
також захопити зовнішній вивід збирання/запуску `scripts/run-node.mjs`,
|
||||
встановіть `OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` у лог-файл усередині репозиторію.
|
||||
|
||||
Для smoke-lane Telegram із реальним транспортом виконайте:
|
||||
Для smoke-доріжки Telegram з реальним транспортом виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa telegram
|
||||
```
|
||||
|
||||
Цей lane націлений на одну реальну приватну групу Telegram замість створення
|
||||
тимчасового сервера. Для нього потрібні `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
|
||||
Ця доріжка націлюється на одну реальну приватну групу Telegram замість розгортання
|
||||
одноразового сервера. Вона вимагає `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
|
||||
`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і
|
||||
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, а також два різні боти в одній
|
||||
приватній групі. Бот SUT повинен мати ім’я користувача Telegram, а спостереження бот-до-бота
|
||||
працює найкраще, коли в обох ботів увімкнено режим Bot-to-Bot Communication Mode
|
||||
в `@BotFather`.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій не пройшов. Використовуйте `--allow-failures`, якщо
|
||||
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, а також двох різних ботів в одній
|
||||
приватній групі. Бот SUT повинен мати імʼя користувача Telegram, а
|
||||
спостереження бот-до-бота працює найкраще, коли в обох ботів увімкнено режим Bot-to-Bot Communication Mode
|
||||
у `@BotFather`.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли
|
||||
вам потрібні артефакти без коду завершення з помилкою.
|
||||
Звіт і підсумок Telegram включають RTT для кожної відповіді — від запиту на
|
||||
надсилання повідомлення driver до спостереженої відповіді SUT, починаючи з canary.
|
||||
Звіт Telegram і підсумок містять RTT для кожної відповіді від запиту
|
||||
надсилання повідомлення driver до спостережуваної відповіді SUT, починаючи з canary.
|
||||
|
||||
Тепер lane живого транспорту використовують один менший спільний контракт замість того, щоб кожен вигадував
|
||||
власну форму списку сценаріїв:
|
||||
Тепер доріжки живого транспорту використовують один менший спільний контракт, замість того щоб
|
||||
кожна вигадувала власну форму списку сценаріїв:
|
||||
|
||||
`qa-channel` залишається широким синтетичним набором перевірок поведінки продукту і не входить
|
||||
`qa-channel` залишається широким синтетичним набором перевірок поведінки продукту й не входить
|
||||
до матриці покриття живого транспорту.
|
||||
|
||||
| Lane | Canary | Обмеження за згадкою | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальші дії в треді | Ізоляція треду | Спостереження за реакціями | Команда help |
|
||||
| -------- | ------ | -------------------- | -------------------- | ------------------------- | ----------------------------- | -------------------- | -------------- | -------------------------- | ------------ |
|
||||
| Matrix | x | x | x | x | x | x | x | x | |
|
||||
| Telegram | x | | | | | | | | x |
|
||||
| Доріжка | Canary | Фільтрація згадок | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальша дія в гілці | Ізоляція гілки | Спостереження реакцій | Команда help |
|
||||
| --------- | ------ | ----------------- | -------------------- | ------------------------- | ----------------------------- | -------------------- | -------------- | --------------------- | ------------ |
|
||||
| Matrix | x | x | x | x | x | x | x | x | |
|
||||
| Telegram | x | | | | | | | | x |
|
||||
|
||||
Це залишає `qa-channel` широким набором перевірок поведінки продукту, тоді як Matrix,
|
||||
Telegram і майбутні живі транспорти мають спільний явний чеклист транспортного контракту.
|
||||
Це зберігає `qa-channel` як широкий набір перевірок поведінки продукту, тоді як Matrix,
|
||||
Telegram і майбутні живі транспорти спільно використовують один явний контрольний список транспортного контракту.
|
||||
|
||||
Для lane з тимчасовою Linux VM без використання Docker у QA-шляху виконайте:
|
||||
Для доріжки з одноразовою Linux VM без залучення Docker до QA-шляху виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
|
||||
```
|
||||
|
||||
Це запускає нову гостьову машину Multipass, встановлює залежності, збирає OpenClaw
|
||||
усередині гостьової машини, запускає `qa suite`, а потім копіює звичайний QA-звіт і
|
||||
Це запускає нову гостьову машину Multipass, установлює залежності, збирає OpenClaw
|
||||
усередині гостя, виконує `qa suite`, а потім копіює звичайний QA-звіт і
|
||||
підсумок назад у `.artifacts/qa-e2e/...` на хості.
|
||||
Він повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
|
||||
Вона повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
|
||||
Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
|
||||
з ізольованими працівниками gateway. `qa-channel` за замовчуванням має concurrency 4,
|
||||
з ізольованими worker-процесами gateway. `qa-channel` за замовчуванням використовує concurrency 4,
|
||||
обмежений кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
|
||||
кількість працівників, або `--concurrency 1` для послідовного виконання.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій не пройшов. Використовуйте `--allow-failures`, якщо
|
||||
кількість worker-процесів, або `--concurrency 1` для послідовного виконання.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли
|
||||
вам потрібні артефакти без коду завершення з помилкою.
|
||||
Живі запуски передають підтримувані QA-входи автентифікації, які практичні для
|
||||
гостьової машини: ключі провайдера через env, шлях до конфігурації QA live provider і
|
||||
Живі запуски передають підтримувані вхідні дані QA-автентифікації, які практичні для
|
||||
гостя: ключі провайдера через env, шлях до конфігурації QA live provider і
|
||||
`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
|
||||
міг записувати назад через змонтований робочий простір.
|
||||
|
||||
## Початкові дані, що підтримуються репозиторієм
|
||||
|
||||
Початкові ресурси живуть у `qa/`:
|
||||
Ресурси початкових даних знаходяться в `qa/`:
|
||||
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/<theme>/*.md`
|
||||
|
||||
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
|
||||
агенту.
|
||||
Вони навмисно зберігаються в git, щоб план QA був видимий і для людей, і для
|
||||
агента.
|
||||
|
||||
`qa-lab` має залишатися універсальним виконавцем Markdown. Кожен Markdown-файл сценарію є
|
||||
`qa-lab` має залишатися загальним виконавцем markdown. Кожен markdown-файл сценарію є
|
||||
джерелом істини для одного тестового запуску й має визначати:
|
||||
|
||||
- метадані сценарію
|
||||
- необов’язкові метадані категорії, можливості, lane і ризику
|
||||
- необовʼязкові метадані категорії, можливостей, доріжки та ризику
|
||||
- посилання на документацію та код
|
||||
- необов’язкові вимоги до Plugin
|
||||
- необов’язковий patch конфігурації gateway
|
||||
- необовʼязкові вимоги до Plugin
|
||||
- необовʼязковий патч конфігурації gateway
|
||||
- виконуваний `qa-flow`
|
||||
|
||||
Повторно використовувана поверхня runtime, що лежить в основі `qa-flow`, може залишатися універсальною
|
||||
і наскрізною. Наприклад, Markdown-сценарії можуть поєднувати транспортні
|
||||
допоміжні засоби з браузерними допоміжними засобами, які керують вбудованим Control UI через
|
||||
seam `browser.request` у Gateway, не додаючи спеціалізований виконавець.
|
||||
Повторно використовувана поверхня runtime, яка лежить в основі `qa-flow`, може залишатися загальною
|
||||
і наскрізною. Наприклад, markdown-сценарії можуть поєднувати
|
||||
допоміжні засоби на стороні транспорту з допоміжними засобами на стороні браузера, які керують вбудованим Control UI через
|
||||
інтерфейс Gateway `browser.request`, не додаючи спеціалізованого виконавця.
|
||||
|
||||
Файли сценаріїв слід групувати за можливостями продукту, а не за папкою дерева вихідного коду.
|
||||
Зберігайте стабільність ID сценаріїв під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
|
||||
для простежуваності реалізації.
|
||||
Файли сценаріїв слід групувати за можливістю продукту, а не за папкою
|
||||
дерева вихідного коду. Зберігайте ідентифікатори сценаріїв стабільними при переміщенні файлів; використовуйте `docsRefs` і `codeRefs`
|
||||
для відстежуваності реалізації.
|
||||
|
||||
Базовий список має залишатися достатньо широким, щоб охоплювати:
|
||||
|
||||
- чат у DM і каналі
|
||||
- поведінку тредів
|
||||
- чати в DM і каналах
|
||||
- поведінку гілок
|
||||
- життєвий цикл дій із повідомленнями
|
||||
- зворотні виклики Cron
|
||||
- відтворення пам’яті
|
||||
- зворотні виклики cron
|
||||
- відтворення з памʼяті
|
||||
- перемикання моделей
|
||||
- передачу підлеглому агенту
|
||||
- читання репозиторію та документації
|
||||
- одне невелике завдання зі збірки, наприклад Lobster Invaders
|
||||
- одне невелике завдання зі збирання, наприклад Lobster Invaders
|
||||
|
||||
## Mock-lane провайдерів
|
||||
## Доріжки mock-провайдерів
|
||||
|
||||
`qa suite` має два локальні mock-lane провайдерів:
|
||||
`qa suite` має дві локальні доріжки mock-провайдерів:
|
||||
|
||||
- `mock-openai` — це залежний від сценарію mock OpenClaw. Він залишається типовим
|
||||
детермінованим mock-lane для QA, що підтримується репозиторієм, і перевірок паритету.
|
||||
- `mock-openai` — це обізнаний про сценарії mock OpenClaw. Він залишається
|
||||
типовою детермінованою mock-доріжкою для QA, що підтримується репозиторієм, і перевірок паритету.
|
||||
- `aimock` запускає сервер провайдера на базі AIMock для експериментального покриття
|
||||
протоколу, фікстур, record/replay і chaos. Він є додатковим і не замінює
|
||||
диспетчер сценаріїв `mock-openai`.
|
||||
протоколу, фікстур, запису/відтворення та хаосу. Це доповнення і воно не
|
||||
замінює диспетчер сценаріїв `mock-openai`.
|
||||
|
||||
Реалізація provider-lane знаходиться в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера,
|
||||
конфігурацією моделей gateway, потребами staging для профілів автентифікації та прапорцями live/mock можливостей. Спільний код suite і gateway має маршрутизувати через реєстр провайдерів, а не розгалужуватися за назвами провайдерів.
|
||||
Реалізація доріжок провайдерів розміщена в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделей gateway,
|
||||
потребами підготовки auth-profile і прапорцями можливостей live/mock. Спільний код suite та
|
||||
gateway має проходити через реєстр провайдерів замість розгалуження за назвами провайдерів.
|
||||
|
||||
## Транспортні адаптери
|
||||
## Адаптери транспорту
|
||||
|
||||
`qa-lab` володіє універсальним seam транспорту для Markdown QA-сценаріїв.
|
||||
`qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша:
|
||||
майбутні реальні або синтетичні канали мають підключатися до того самого виконавця suite,
|
||||
а не додавати специфічний для транспорту QA-виконавець.
|
||||
`qa-lab` володіє загальним інтерфейсом транспорту для markdown-сценаріїв QA.
|
||||
`qa-channel` — перший адаптер на цьому інтерфейсі, але ціль проєктування ширша:
|
||||
майбутні реальні або синтетичні канали мають підключатися до того самого виконавця suite
|
||||
замість додавання спеціалізованого QA-виконавця для транспорту.
|
||||
|
||||
На рівні архітектури поділ такий:
|
||||
|
||||
- `qa-lab` відповідає за універсальне виконання сценаріїв, concurrency працівників, запис артефактів і звітність.
|
||||
- транспортний адаптер відповідає за конфігурацію gateway, готовність, спостереження за вхідними та вихідними подіями, транспортні дії й нормалізований стан транспорту.
|
||||
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає повторно використовувану поверхню runtime, яка їх виконує.
|
||||
- `qa-lab` володіє загальним виконанням сценаріїв, паралельністю worker-процесів, записом артефактів і звітністю.
|
||||
- адаптер транспорту володіє конфігурацією gateway, готовністю, спостереженням за вхідними та вихідними подіями, транспортними діями та нормалізованим станом транспорту.
|
||||
- markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає повторно використовувану поверхню runtime, яка їх виконує.
|
||||
|
||||
Орієнтовані на мейнтейнерів рекомендації щодо впровадження нових адаптерів каналів наведено в
|
||||
[Testing](/uk/help/testing#adding-a-channel-to-qa).
|
||||
Настанови з упровадження для супровідників нових адаптерів каналів містяться в
|
||||
[Тестування](/uk/help/testing#adding-a-channel-to-qa).
|
||||
|
||||
## Звітність
|
||||
|
||||
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на такі питання:
|
||||
`qa-lab` експортує протокольний звіт у Markdown зі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на запитання:
|
||||
|
||||
- Що спрацювало
|
||||
- Що зламалося
|
||||
- Що не спрацювало
|
||||
- Що залишилося заблокованим
|
||||
- Які наступні сценарії варто додати
|
||||
- Які додаткові сценарії варто додати
|
||||
|
||||
Для перевірок характеру та стилю запустіть той самий сценарій на кількох живих model
|
||||
refs і створіть оцінений Markdown-звіт:
|
||||
Для перевірок характеру та стилю виконайте той самий сценарій для кількох живих ref моделей
|
||||
і запишіть оцінений звіт у Markdown:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa character-eval \
|
||||
--model openai-codex/gpt-5.5,thinking=xhigh \
|
||||
--model openai/gpt-5.4,thinking=medium,fast \
|
||||
--model openai/gpt-5.2,thinking=xhigh \
|
||||
--model openai/gpt-5,thinking=xhigh \
|
||||
--model anthropic/claude-opus-4-6,thinking=high \
|
||||
@ -217,7 +220,7 @@ pnpm openclaw qa character-eval \
|
||||
--model zai/glm-5.1,thinking=high \
|
||||
--model moonshot/kimi-k2.5,thinking=high \
|
||||
--model google/gemini-3.1-pro-preview,thinking=high \
|
||||
--judge-model openai-codex/gpt-5.5,thinking=xhigh,fast \
|
||||
--judge-model openai/gpt-5.4,thinking=xhigh,fast \
|
||||
--judge-model anthropic/claude-opus-4-6,thinking=high \
|
||||
--blind-judge-models \
|
||||
--concurrency 16 \
|
||||
@ -225,40 +228,39 @@ pnpm openclaw qa character-eval \
|
||||
```
|
||||
|
||||
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії character eval
|
||||
мають задавати персонажа через `SOUL.md`, а потім виконувати звичайні ходи користувача,
|
||||
такі як чат, допомога з робочим простором і невеликі файлові завдання. Модель-кандидат
|
||||
не повинна знати, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, фіксує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з
|
||||
міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models`, коли порівнюєте провайдерів: промпт для судді все одно отримує
|
||||
кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними
|
||||
мітками на кшталт `candidate-01`; звіт зіставляє рейтинги з реальними refs після
|
||||
розбору.
|
||||
Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI,
|
||||
які це підтримують, — `xhigh`. Перевизначте конкретного кандидата inline через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
|
||||
глобальне запасне значення, а старіша форма `--model-thinking <provider/model=level>` збережена
|
||||
для сумісності.
|
||||
Для refs кандидатів OpenAI за замовчуванням використовується fast mode, щоб застосовувалася
|
||||
пріоритетна обробка там, де провайдер це підтримує. Додайте inline `,fast`, `,no-fast` або `,fast=false`, коли
|
||||
одному кандидату або судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
|
||||
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалості кандидатів і суддів
|
||||
записуються у звіт для аналізу бенчмарків, але в промптах для суддів явно сказано
|
||||
мають задавати persona через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
|
||||
такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату
|
||||
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, записує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з
|
||||
міркуванням `xhigh`, де це підтримується, ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models`, коли порівнюєте провайдерів: запит для судді все одно отримує
|
||||
кожен транскрипт і статус запуску, але ref кандидатів замінюються нейтральними
|
||||
мітками на кшталт `candidate-01`; звіт зіставляє ранжування назад із реальними ref після парсингу.
|
||||
Запуски кандидатів за замовчуванням використовують `high` thinking, з `medium` для GPT-5.4 і `xhigh`
|
||||
для старіших eval-ref OpenAI, які це підтримують. Перевизначте конкретного кандидата безпосередньо через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` і далі задає
|
||||
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>`
|
||||
зберігається для сумісності.
|
||||
Ref кандидатів OpenAI за замовчуванням використовують fast mode, щоб застосовувалася пріоритетна обробка там,
|
||||
де це підтримує провайдер. Додайте `,fast`, `,no-fast` або `,fast=false` безпосередньо, коли
|
||||
окремому кандидату або судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
|
||||
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
|
||||
записується у звіт для аналізу продуктивності, але в запитах до суддів прямо вказано
|
||||
не ранжувати за швидкістю.
|
||||
І для кандидатів, і для суддів за замовчуванням використовується concurrency 16. Зменште
|
||||
`--concurrency` або `--judge-concurrency`, коли обмеження провайдера чи навантаження на локальний gateway
|
||||
роблять запуск надто шумним.
|
||||
Коли не передано жодного кандидата `--model`, для character eval за замовчуванням використовуються
|
||||
`openai-codex/gpt-5.5`, `openai/gpt-5.4`, `openai/gpt-5.2`, `anthropic/claude-opus-4-6`,
|
||||
І запуски моделей-кандидатів, і запуски моделей-суддів за замовчуванням використовують concurrency 16. Зменшуйте
|
||||
`--concurrency` або `--judge-concurrency`, коли обмеження провайдера чи локальне навантаження на gateway
|
||||
роблять запуск занадто шумним.
|
||||
Якщо не передано жодного `--model` кандидата, character eval за замовчуванням використовує
|
||||
`openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
|
||||
`anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
|
||||
`moonshot/kimi-k2.5` і
|
||||
`google/gemini-3.1-pro-preview`, якщо `--model` не передано.
|
||||
Коли не передано жодного `--judge-model`, за замовчуванням суддями є
|
||||
`openai-codex/gpt-5.5,thinking=xhigh,fast` і
|
||||
`google/gemini-3.1-pro-preview`, якщо не передано `--model`.
|
||||
Якщо не передано жодного `--judge-model`, суддями за замовчуванням є
|
||||
`openai/gpt-5.4,thinking=xhigh,fast` і
|
||||
`anthropic/claude-opus-4-6,thinking=high`.
|
||||
|
||||
## Пов’язані документи
|
||||
## Повʼязана документація
|
||||
|
||||
- [Testing](/uk/help/testing)
|
||||
- [Тестування](/uk/help/testing)
|
||||
- [QA Channel](/uk/channels/qa-channel)
|
||||
- [Панель керування](/uk/web/dashboard)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user