chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
c13c63c702
commit
271a69584b
@ -3,13 +3,13 @@ read_when:
|
||||
- Розширення qa-lab або qa-channel
|
||||
- Додавання сценаріїв QA з підтримкою репозиторію
|
||||
- Побудова більш реалістичної автоматизації QA навколо панелі керування Gateway
|
||||
summary: Приватна структура автоматизації QA для qa-lab, qa-channel, попередньо підготовлених сценаріїв і звітів протоколу
|
||||
summary: Приватна форма автоматизації QA для qa-lab, qa-channel, сценаріїв із початковими даними та звітів протоколу
|
||||
title: Автоматизація QA E2E
|
||||
x-i18n:
|
||||
generated_at: "2026-04-17T15:05:27Z"
|
||||
generated_at: "2026-04-20T02:15:03Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: adf8c5f74e8fabdc8e9fd7ecd41afce8b60354c7dd24d92ac926d3c527927cd4
|
||||
source_hash: 34245ce871356caeab0d9e0eeeaa9fb4e408920a4a97ad27567fa365d8db17c7
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,33 +17,33 @@ x-i18n:
|
||||
# Автоматизація QA E2E
|
||||
|
||||
Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
|
||||
орієнтований на канали спосіб, ніж це може зробити один модульний тест.
|
||||
каналоподібний спосіб, ніж це може зробити один модульний тест.
|
||||
|
||||
Поточні складові:
|
||||
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, потоку,
|
||||
реакцій, редагування та видалення.
|
||||
- `extensions/qa-lab`: UI налагодження та QA bus для спостереження за транскриптом,
|
||||
ін’єкції вхідних повідомлень і експорту Markdown-звіту.
|
||||
- `qa/`: ресурси початкових даних із підтримкою репозиторію для стартового завдання та базових сценаріїв QA.
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, треду,
|
||||
реакції, редагування та видалення.
|
||||
- `extensions/qa-lab`: UI для налагодження та шина QA для спостереження за транскриптом,
|
||||
інʼєкції вхідних повідомлень і експорту Markdown-звіту.
|
||||
- `qa/`: ресурси з початковими даними з підтримкою репозиторію для стартового завдання та базових сценаріїв QA.
|
||||
|
||||
Поточний операторський потік QA — це двопанельний сайт QA:
|
||||
Поточний робочий процес оператора QA — це сайт QA з двома панелями:
|
||||
|
||||
- Ліворуч: панель керування Gateway (Control UI) з агентом.
|
||||
- Праворуч: QA Lab, що показує схожий на Slack транскрипт і план сценарію.
|
||||
- Праворуч: 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-образу щоразу
|
||||
Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу
|
||||
запустіть стек із bind-mounted збіркою QA Lab:
|
||||
|
||||
```bash
|
||||
@ -53,80 +53,79 @@ 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.
|
||||
|
||||
Для Matrix smoke lane з реальним транспортом запустіть:
|
||||
Для транспортно-реалістичної лінії smoke для Matrix виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa matrix
|
||||
```
|
||||
|
||||
Цей lane розгортає в Docker одноразовий homeserver Tuwunel, реєструє
|
||||
тимчасових користувачів driver, SUT і observer, створює одну приватну кімнату,
|
||||
а потім запускає справжній Matrix Plugin у дочірньому 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>` на файл журналу всередині репозиторію.
|
||||
|
||||
Для Telegram smoke lane з реальним транспортом запустіть:
|
||||
Для транспортно-реалістичної лінії 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`.
|
||||
приватній групі. Бот SUT повинен мати імʼя користувача Telegram, а спостереження бот-до-бота
|
||||
працює найкраще, коли в обох ботів увімкнено Bot-to-Bot Communication Mode
|
||||
у `@BotFather`.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується помилкою. Використовуйте `--allow-failures`, якщо
|
||||
вам потрібні артефакти без коду завершення з помилкою.
|
||||
|
||||
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 і майбутні живі транспорти спільно використовують один явний контрольний список
|
||||
транспортного контракту.
|
||||
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-звіт і
|
||||
усередині гостя, запускає `qa suite`, а потім копіює звичайний звіт QA та
|
||||
підсумок назад у `.artifacts/qa-e2e/...` на хості.
|
||||
Використовується така сама поведінка вибору сценаріїв, як і для `qa suite` на хості.
|
||||
Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних
|
||||
сценаріїв паралельно з ізольованими працівниками Gateway — до 64 працівників
|
||||
або до кількості вибраних сценаріїв. Використовуйте `--concurrency <count>` для
|
||||
налаштування кількості працівників або `--concurrency 1` для послідовного виконання.
|
||||
Живі запуски передають підтримувані вхідні дані автентифікації QA, які практично
|
||||
можна використовувати в гостьовій системі: ключі провайдерів через env,
|
||||
шлях до конфігурації QA live provider і `CODEX_HOME`, якщо він присутній.
|
||||
Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
|
||||
міг записувати результати назад через змонтований workspace.
|
||||
Вона повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
|
||||
Запуски suite на хості й у Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
|
||||
з ізольованими воркерами gateway. `qa-channel` за замовчуванням має concurrency 4,
|
||||
обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
|
||||
кількість воркерів, або `--concurrency 1` для послідовного виконання.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується помилкою. Використовуйте `--allow-failures`, якщо
|
||||
вам потрібні артефакти без коду завершення з помилкою.
|
||||
Живі запуски пересилають підтримувані вхідні дані автентифікації QA, які практично
|
||||
використовувати в гостьовій системі: ключі провайдера через env, шлях до конфігурації живого провайдера QA і
|
||||
`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
|
||||
міг записувати дані назад через змонтований workspace.
|
||||
|
||||
## Початкові дані з підтримкою репозиторію
|
||||
|
||||
Ресурси початкових даних зберігаються в `qa/`:
|
||||
Ресурси з початковими даними зберігаються в `qa/`:
|
||||
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/<theme>/*.md`
|
||||
@ -135,81 +134,78 @@ pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
|
||||
агенту.
|
||||
|
||||
`qa-lab` має залишатися загальним виконавцем markdown. Кожен markdown-файл сценарію є
|
||||
джерелом істини для одного тестового запуску і повинен визначати:
|
||||
джерелом істини для одного тестового запуску та має визначати:
|
||||
|
||||
- метадані сценарію
|
||||
- необов’язкові метадані категорії, можливостей, lane і ризику
|
||||
- посилання на документацію та код
|
||||
- необов’язкові вимоги до Plugin
|
||||
- необов’язковий patch конфігурації Gateway
|
||||
- необовʼязкові метадані категорії, можливості, лінії та ризику
|
||||
- посилання на docs і код
|
||||
- необовʼязкові вимоги до Plugin
|
||||
- необовʼязковий patch конфігурації gateway
|
||||
- виконуваний `qa-flow`
|
||||
|
||||
Багаторазово використовувана поверхня середовища виконання, що лежить в основі `qa-flow`,
|
||||
може залишатися загальною та наскрізною. Наприклад, markdown-сценарії можуть
|
||||
поєднувати helpers на стороні транспорту з helpers на стороні браузера, які керують
|
||||
вбудованим Control UI через шов Gateway `browser.request`, не додаючи
|
||||
спеціального виконавця для окремих випадків.
|
||||
Багаторазова поверхня виконання, яка лежить в основі `qa-flow`, може залишатися загальною
|
||||
і кросфункціональною. Наприклад, markdown-сценарії можуть поєднувати допоміжні засоби
|
||||
з боку транспорту з допоміжними засобами з боку браузера, які керують вбудованим Control UI через
|
||||
поверхню Gateway `browser.request`, не додаючи спеціалізованого виконавця.
|
||||
|
||||
Файли сценаріїв слід групувати за можливостями продукту, а не за папкою дерева
|
||||
вихідного коду. Зберігайте стабільність ідентифікаторів сценаріїв при переміщенні файлів;
|
||||
використовуйте `docsRefs` і `codeRefs` для трасування реалізації.
|
||||
вихідного коду. Зберігайте ідентифікатори сценаріїв стабільними, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs`
|
||||
для трасування реалізації.
|
||||
|
||||
Базовий список має залишатися достатньо широким, щоб покривати:
|
||||
Базовий список має залишатися достатньо широким, щоб охоплювати:
|
||||
|
||||
- DM і чат каналу
|
||||
- поведінку потоку
|
||||
- чат у DM і каналі
|
||||
- поведінку тредів
|
||||
- життєвий цикл дій із повідомленнями
|
||||
- зворотні виклики Cron
|
||||
- відновлення з пам’яті
|
||||
- виклик памʼяті
|
||||
- перемикання моделей
|
||||
- передавання підзадачі субагенту
|
||||
- читання репозиторію та документації
|
||||
- одне невелике завдання зі збірки, наприклад Lobster Invaders
|
||||
- читання репозиторію та docs
|
||||
- одне невелике завдання зі збирання, наприклад Lobster Invaders
|
||||
|
||||
## Mock lanes провайдерів
|
||||
## Лінії mock провайдерів
|
||||
|
||||
`qa suite` має два локальні mock lanes провайдерів:
|
||||
`qa suite` має дві локальні лінії mock провайдерів:
|
||||
|
||||
- `mock-openai` — це сценарійно-орієнтований mock OpenClaw. Він лишається типовим
|
||||
детерміністичним mock lane для QA з підтримкою репозиторію та перевірок паритету.
|
||||
- `aimock` запускає сервер провайдера на основі AIMock для експериментального
|
||||
покриття протоколу, фікстур, record/replay і chaos. Це доповнення, яке не
|
||||
замінює диспетчер сценаріїв `mock-openai`.
|
||||
- `mock-openai` — це сценарійно-орієнтований mock OpenClaw. Він залишається типовою
|
||||
детермінованою лінією mock для QA з підтримкою репозиторію та перевірок паритету.
|
||||
- `aimock` запускає сервер провайдера на базі AIMock для експериментального покриття протоколу,
|
||||
фікстур, record/replay та chaos. Це доповнення, а не заміна диспетчера сценаріїв `mock-openai`.
|
||||
|
||||
Реалізація provider-lane розташована в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера,
|
||||
конфігурацією моделі Gateway, потребами staging для auth-profile, а також
|
||||
прапорами можливостей live/mock. Спільний код suite і Gateway повинен
|
||||
маршрутизуватися через реєстр провайдерів, а не розгалужуватися за назвами провайдерів.
|
||||
Реалізація ліній провайдерів розміщена в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделей gateway,
|
||||
потребами підготовки профілів автентифікації та прапорцями можливостей live/mock. Спільний код suite і
|
||||
gateway має маршрутизувати через реєстр провайдерів замість розгалуження за назвами провайдерів.
|
||||
|
||||
## Адаптери транспорту
|
||||
|
||||
`qa-lab` володіє загальним транспортним швом для markdown-сценаріїв QA.
|
||||
`qa-channel` — перший адаптер на цьому шві, але ціль дизайну ширша:
|
||||
майбутні реальні або синтетичні канали повинні підключатися до того самого
|
||||
виконавця suite замість додавання transport-specific виконавця QA.
|
||||
`qa-lab` володіє загальною транспортною поверхнею для markdown-сценаріїв QA.
|
||||
`qa-channel` — перший адаптер на цій поверхні, але ціль дизайну ширша:
|
||||
майбутні реальні або синтетичні канали мають підключатися до того самого виконавця suite
|
||||
замість додавання виконавця QA, специфічного для транспорту.
|
||||
|
||||
На рівні архітектури розділення таке:
|
||||
На рівні архітектури розподіл такий:
|
||||
|
||||
- `qa-lab` володіє загальним виконанням сценаріїв, паралелізмом працівників, записом артефактів і звітністю.
|
||||
- адаптер транспорту володіє конфігурацією Gateway, готовністю, спостереженням за вхідними та вихідними подіями, транспортними діями та нормалізованим станом транспорту.
|
||||
- markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану поверхню середовища виконання, яка його виконує.
|
||||
- `qa-lab` володіє загальним виконанням сценаріїв, паралельністю воркерів, записом артефактів і звітністю.
|
||||
- адаптер транспорту володіє конфігурацією gateway, готовністю, спостереженням за вхідними та вихідними подіями, транспортними діями та нормалізованим станом транспорту.
|
||||
- markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазову поверхню виконання, яка його виконує.
|
||||
|
||||
Рекомендації для мейнтейнерів щодо підключення нових адаптерів каналів розміщені в
|
||||
Орієнтовані на мейнтейнерів вказівки з упровадження нових адаптерів каналів розміщені в
|
||||
[Testing](/uk/help/testing#adding-a-channel-to-qa).
|
||||
|
||||
## Звітність
|
||||
|
||||
`qa-lab` експортує Markdown-звіт протоколу на основі спостережуваної часової шкали bus.
|
||||
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на запитання:
|
||||
|
||||
- Що спрацювало
|
||||
- Що не спрацювало
|
||||
- Що лишилося заблокованим
|
||||
- Які додаткові сценарії варто додати
|
||||
- Що залишилося заблокованим
|
||||
- Які подальші сценарії варто додати
|
||||
|
||||
Для перевірок характеру та стилю запустіть той самий сценарій на кількох live model
|
||||
refs і запишіть оцінений Markdown-звіт:
|
||||
Для перевірок характеру й стилю запустіть той самий сценарій для кількох живих ref моделей
|
||||
і запишіть оцінений Markdown-звіт:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa character-eval \
|
||||
@ -228,43 +224,39 @@ pnpm openclaw qa character-eval \
|
||||
--judge-concurrency 16
|
||||
```
|
||||
|
||||
Команда запускає локальні дочірні процеси QA Gateway, а не Docker. Сценарії
|
||||
оцінювання характеру повинні задавати persona через `SOUL.md`, а потім виконувати
|
||||
звичайні користувацькі ходи, такі як чат, допомога з workspace і невеликі
|
||||
завдання з файлами. Моделі-кандидату не слід повідомляти, що її оцінюють.
|
||||
Команда зберігає кожен повний транскрипт, записує базову статистику запуску,
|
||||
а потім просить judge models у fast mode з reasoning `xhigh`
|
||||
ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models` при порівнянні провайдерів:
|
||||
prompt для judge, як і раніше, отримує кожен транскрипт і статус запуску,
|
||||
але refs кандидатів замінюються нейтральними мітками, такими як `candidate-01`;
|
||||
після парсингу звіт зіставляє рейтинги назад із реальними refs.
|
||||
Для кандидатів за замовчуванням використовується thinking `high`, а для моделей OpenAI,
|
||||
які це підтримують, — `xhigh`. Перевизначте конкретного кандидата безпосередньо через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
|
||||
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>`
|
||||
збережена для сумісності.
|
||||
Refs кандидатів OpenAI за замовчуванням використовують fast mode, щоб там, де
|
||||
це підтримується провайдером, застосовувалася пріоритетна обробка. Додайте `,fast`,
|
||||
`,no-fast` або `,fast=false` безпосередньо в рядку, якщо для окремого кандидата
|
||||
або judge потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
|
||||
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість запусків
|
||||
кандидатів і judge також записується у звіт для аналізу бенчмарків, але prompts для
|
||||
judge явно вказують не ранжувати за швидкістю.
|
||||
Запуски моделей-кандидатів і judge за замовчуванням виконуються з concurrency 16.
|
||||
Зменшуйте `--concurrency` або `--judge-concurrency`, коли обмеження провайдера або
|
||||
навантаження локального Gateway роблять запуск занадто шумним.
|
||||
Якщо не передано жодного кандидатського `--model`, character eval за замовчуванням
|
||||
використовує
|
||||
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії оцінювання характеру
|
||||
мають задавати persona через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
|
||||
такі як чат, допомога з workspace та невеликі файлові завдання. Моделі-кандидату
|
||||
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, записує базову статистику запуску, а потім просить моделі-суддів у швидкому режимі з
|
||||
міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models` при порівнянні провайдерів: підказка для суддів усе одно отримує
|
||||
кожен транскрипт і статус запуску, але ref кандидатів замінюються на нейтральні
|
||||
мітки, такі як `candidate-01`; після парсингу звіт зіставляє рейтинги назад із реальними ref.
|
||||
Запуски кандидатів за замовчуванням використовують рівень мислення `high`, а для моделей OpenAI, які це підтримують, — `xhigh`.
|
||||
Щоб перевизначити конкретного кандидата, використовуйте inline-форму
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` і надалі задає
|
||||
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>` зберігається
|
||||
для сумісності.
|
||||
ref кандидатів OpenAI за замовчуванням працюють у швидкому режимі, щоб використовувати пріоритетну обробку там,
|
||||
де це підтримується провайдером. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
|
||||
одному кандидату або судді потрібно перевизначення. Передавайте `--fast`, лише якщо хочете
|
||||
примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
|
||||
записується у звіт для аналізу продуктивності, але підказки для суддів прямо кажуть
|
||||
не ранжувати за швидкістю.
|
||||
Запуски моделей-кандидатів і моделей-суддів за замовчуванням обидва використовують 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`, judges за замовчуванням:
|
||||
Коли не передано `--judge-model`, за замовчуванням як судді використовуються
|
||||
`openai/gpt-5.4,thinking=xhigh,fast` і
|
||||
`anthropic/claude-opus-4-6,thinking=high`.
|
||||
|
||||
## Пов’язана документація
|
||||
## Повʼязані docs
|
||||
|
||||
- [Testing](/uk/help/testing)
|
||||
- [QA Channel](/uk/channels/qa-channel)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user