AI-система автотестування та QA для ігор: розробка під ключ

AI-система тестування та QA для ігор під ключ

Ручне QA тестування гри не масштабується: відкритий світ з 1000+ квестами і 100+ механіками не протестувати вручну за розумний час. Команда з 5 тестувальників за тиждень покриває близько 2000 унікальних станів, а наш RL-агент — 10 мільйонів за день. Ми розробили систему під ключ, яка автономно досліджує ігровий світ, знаходить краші, софтлоки, експлойти та проблеми балансу — працюючи 24/7 і збільшуючи покриття до 90% за години.

Чому ручне тестування не справляється?

Навіть велика QA-команда пропускає edge cases: рідкісні комбінації дій, race conditions, квести в нестандартній послідовності. Наш RL-агент з curiosity-driven exploration (ICM) цілеспрямовано шукає незвідані стани, а Go-Explore алгоритм запам'ятовує цікаві точки і повертається до них. За 10 млн кроків агент відвідує більше унікальних станів, ніж команда з 5 осіб за місяць. В результаті ми знаходимо в 3 рази більше багів на старті, а витрати на QA знижуються в 10 разів.

Як ми будуємо AI-систему тестування?

Crash/Softlock тестування

Агент випадково досліджує весь простір дій, тригерить edge cases, які крашать гру або застрягають у петлі. Код агента з ICM:

class GameTestingAgent:
    """Агент для coverage-based тестування"""

    def __init__(self, game_env):
        self.env = game_env
        self.visited_states = set()
        self.crashes = []
        self.softlocks = []

        # Curiosity-driven exploration
        # ICM (Intrinsic Curiosity Module): reward за нові стани
        self.icm = ICM(obs_dim=game_env.obs_dim,
                       action_dim=game_env.action_dim)

        self.policy = PPO("MlpPolicy", game_env,
                          ent_coef=0.05)  # висока entropy для exploration

    def collect_coverage_data(self, n_steps=1_000_000):
        obs = self.env.reset()
        for step in range(n_steps):
            try:
                action, _ = self.policy.predict(obs)
                obs, _, done, _, info = self.env.step(action)

                # логуємо нові стани
                state_hash = self._hash_state(obs)
                self.visited_states.add(state_hash)

                # детектуємо softlock (агент ходить по колу)
                if self._detect_softlock():
                    self.softlocks.append(self.env.get_state_dump())

                if done: obs = self.env.reset()

            except Exception as e:
                self.crashes.append({
                    'error': str(e),
                    'state': self.env.get_state_dump(),
                    'action_sequence': self.recent_actions[-100:]
                })
                obs = self.env.reset()

Content coverage testing

Перевіряємо, чи є зони, предмети або досягнення, які ніколи не досягаються нормальним ігровим шляхом. Агент з ICM винагороджується за відвідування нових станів — приховані області виявляються автоматично. В одному з проєктів ми знайшли 23 нереалізованих квести і 5 прихованих досягнень, про які розробники забули.

Exploit detection

Спеціальний агент навчений максимізувати score без обмежень:

# exploit reward: ТІЛЬКИ score, ігноруємо всі "нормальні" шляхи
def exploit_reward(info):
    return info['score']  # + info['gold'] + info['level']

# навчаємо на мінімальній кількості кроків (швидкий експлойт)
model = PPO("MlpPolicy", env,
            gamma=0.5,        # короткий горизонт = хоче швидких нагород
            ent_coef=0.1)     # багато exploration

# якщо агент знаходить спосіб отримати 10× середній score за 1 хвилину
# → це exploit для QA команди

Що таке Intrinsic Curiosity Module (ICM)?

class ICM(nn.Module):
    """Intrinsic Curiosity: reward = prediction error for new states"""
    def __init__(self, obs_dim, action_dim, feature_dim=256):
        super().__init__()
        # feature encoder
        self.phi = nn.Sequential(
            nn.Linear(obs_dim, feature_dim), nn.ELU(),
            nn.Linear(feature_dim, feature_dim)
        )
        # forward model: predict next state features
        self.forward_model = nn.Sequential(
            nn.Linear(feature_dim + action_dim, feature_dim), nn.ELU(),
            nn.Linear(feature_dim, feature_dim)
        )

    def intrinsic_reward(self, obs, action, next_obs):
        phi_obs = self.phi(obs)
        phi_next = self.phi(next_obs)

        # prediction error = наскільки новий цей стан
        a_onehot = F.one_hot(action, self.action_dim).float()
        predicted_next = self.forward_model(torch.cat([phi_obs, a_onehot], dim=1))
        curiosity = F.mse_loss(predicted_next, phi_next.detach(), reduction='none').mean(-1)
        return curiosity  # високий для нових, низький для вивчених

Як Go-Explore вирішує проблему sparse reward?

Класичний RL застрягає в іграх з рідкісними нагородами. Go-Explore (Adept AI):

1. Зберігає архів цікавих станів (за різноманітністю).
2. Випадково обирає стан з архіву.
3. Повертається до нього (deterministic replay).
4. Продовжує дослідження звідти.

class GoExploreAgent:
    def __init__(self, game):
        self.game = game
        self.archive = {}  # cell -> (score, state_snapshot)

    def cell_key(self, state):
        """Discretize state into cell (спрощення для зберігання)"""
        # для 2D гри: (x//50, y//50, level_id)
        return (state['x'] // 50, state['y'] // 50, state['level'])

    def run(self, n_iterations):
        for _ in range(n_iterations):
            # обрати стан з архіву (рідко відвідуваний)
            cell = self._select_cell()
            state = self.archive[cell]['snapshot']

            # відновити стан (savestate)
            self.game.load_state(state)

            # випадково дослідити N кроків
            for _ in range(np.random.randint(5, 100)):
                action = self.game.action_space.sample()
                new_state, _, done, _, _ = self.game.step(action)
                new_cell = self.cell_key(new_state)
                if new_cell not in self.archive:
                    self.archive[new_cell] = {
                        'snapshot': self.game.save_state(),
                        'visits': 0
                    }
                if done: break

Порівняння підходів: ICM vs Random vs Expert

Що входить в роботу під ключ?

Разом: 12–16 тижнів на повноцінну систему. Вартість розраховується індивідуально після аудиту вашого проєкту. Зв'яжіться з нами — оцінимо обсяг робіт і терміни. Замовте консультацію, щоб обговорити вашу гру.

Метрики ефективності

• State space coverage: % відвіданих ігрових станів (ціль ≥90%).
• Crash count per build: середнє 3 краші на білд до оптимізації, після — 0.
• Softlock incidents found: 50+ на проєкт.
• New exploits detected per patch: в середньому 8.
• Time to 90% coverage: від 4 до 8 годин (вручну — місяць).

Regression testing

Після патча — запустити агентів, переконатися, що previously passing tests не зламалися. CI/CD пайплайн автоматично запускає тести на кожний pull request:

# GitHub Actions / Jenkins
name: Game QA Tests
on: [push, pull_request]

jobs:
  ai-qa:
    runs-on: ubuntu-latest
    steps:
      - name: Run Coverage Agent (10 min budget)
        run: python run_coverage_agent.py --budget 600 --headless

      - name: Check Coverage Metrics
        run: |
          python check_coverage.py \
            --min-level-coverage 0.85 \
            --max-new-crashes 0

Наші інженери мають 10+ років досвіду в AI геймдеві, понад 50 успішних проєктів. Ми гарантуємо: система знайде мінімум 3× більше багів, ніж ручне тестування на старті. Отримайте консультацію — оцінимо вашу гру та запропонуємо рішення.

Навчання з підкріпленням: PPO, SAC, DQN та промислове застосування

Ми щодня бачимо проєкти, які гинуть не через слабкий алгоритм, а через неправильну винагороду. Інженер пише reward = +1 за правильну дію, запускає навчання, а через 10 млн кроків агент знаходить спосіб отримати максимум, не вирішивши завдання. Це reward hacking — системний біль промислового RL. Наш досвід показує: правильний reward займає 70% успіху.

Чому RL складніше, ніж supervised learning?

У supervised learning є датасет з правильними відповідями. У RL правильної відповіді немає — є скалярний сигнал «краще/гірше», який надходить із затримкою в сотні кроків. Агент сам досліджує простір і знаходить стратегію.

Наслідки: нестабільність навчання, висока чутливість до гіперпараметрів, повільна збіжність. PPO (Proximal Policy Optimization) на Atari сходиться за 10 млн кроків — це години. На роботизованих завданнях з реальною фізикою — дні або тижні в симуляторі.

Чому reward engineering вирішальний для RL?

Без якісної reward-функції навчання перетворюється на лотерею. Reward hacking — класична пастка: агент знаходить неочевидний спосіб максимізувати винагороду, ігноруючи справжню ціль. Один із проєктів — сортування компонентів на PCB — demand: ми витратили 2 тижні на формалізацію reward: штраф за зіткнення, бонус за швидкість, penalty за неправильне розташування. Без цього агент навчився скидати деталі з конвеєра, отримуючи +1 за кожну скинуту, а не за відсортовану.

Як обрати алгоритм під задачу?

Як налаштувати PPO та уникнути типових проблем?

PPO — робоча конячка RL. Основна ідея: обмежуємо оновлення політики через кліпування ratio clip_range=0.2. Це дає стабільність порівняно з vanilla policy gradient. Але без грамотного налаштування агент не сходиться.

Одна з частих пасток — entropy collapse: агент занадто швидко стає детермінованим, перестає досліджувати. Симптом — entropy coefficient падає до нуля. Лікування — ent_coef=0.01–0.05 і не знижувати нижче 0.001. Інша проблема — value function розходиться, коли vf_loss_coef високий, а explained_variance від'ємний. Рекомендуємо vf_coef=0.5 і gradient clipping max_grad_norm=0.5.

Неправильний n_steps також ламає навчання. n_steps=2048 — дефолт Stable‑Baselines3. Для завдань з довгим горизонтом (>500 кроків) потрібно збільшувати, для швидких (10–50 кроків) — зменшувати до 256–512.

Для швидкого старту використовуємо stable‑baselines3 + sb3‑contrib. Для research і кастомних алгоритмів — tianshou або CleanRL.

SAC для безперервного керування

SAC (Soft Actor‑Critic) додає в objective максимізацію ентропії — агент вчиться бути і ефективним, і різноманітним. Це дає відмінну sample efficiency та стійкість до шуму в reward. На задачах керування техпроцесами SAC зазвичай обходить PPO за збіжністю: потребує на 30–40% менше взаємодій для досягнення тієї ж якості. Ключовий параметр — target_entropy. Стандартне значення ‑dim(action_space) часто підходить, але для специфічних завдань краще налаштовувати вручну.

Як перенести навченого агента на реальний пристрій?

Навчати RL на реальному роботі — дорого та небезпечно. Стандартний підхід: навчання в симуляторі → трансфер на реальне залізо. Основна проблема — reality gap: симулятор не відтворює фізику, тертя, шум датчиків.

Головний інструмент — domain randomization. Під час навчання випадково варіюємо параметри середовища: маса об'єктів ±30%, коефіцієнт тертя ±50%, затримка дій 0–100 мс, шум спостережень σ=0.01–0.1. Агент навчається бути робастним до варіацій, і реальний світ стає лише ще однією варіацією.

Порівняння популярних симуляторів:

RLHF: навчання LLM з людського зворотного зв'язку

RLHF став стандартом після InstructGPT. Класична схема: supervised fine‑tuning → reward model → PPO.

Проблеми класичного PPO: нестабільність (KL‑дивергенція може вибухнути), повільна збіжність, складність налаштування. Тому популярні альтернативи:

• DPO — обходить reward model, вчиться на парах уподобань. Простіше, стабільніше, але менш гнучкий.
• GRPO — використовується в DeepSeek‑R1, хороший для reasoning tasks.
• ORPO — об'єднує SFT та alignment в одну стадію.

Бібліотека trl від Hugging Face — стандарт. Підтримує PPO, DPO, ORPO, GRPO з коробки, працює з PEFT/LoRA для memory‑efficient fine‑tuning.

Reward hacking залишається однією з головних причин провалів у RL, поряд з неправильно обраною архітектурою середовища. Це підтверджують дослідження з відкритих джерел (Reward hacking in reinforcement learning, Wikipedia).

Що входить в роботу

• Архітектурне рішення та обґрунтування вибору алгоритму
• Розробка та документування reward‑функції
• Створення симулятора або налаштування існуючого
• Навчання, hyper‑parameter sweep (Optuna / Ray Tune)
• Трансфер на реальне залізо або інтеграція в продукт
• Документація, доступи до коду та симуляторів
• Навчання команди та 3‑місячна підтримка після деплою

Процес роботи

1. Аудит завдання — фіксуємо цілі, ресурси, обмеження.
2. Reward engineering — формалізація бажаної поведінки, перевірка на reward hacking.
3. Вибір середовища та алгоритму — baseline, перші прогони.
4. Систематичний hyperparameter sweep — використовуємо Optuna.
5. Навчання в симуляторі з domain randomization.
6. Тестування на реальному обладнанні (за потреби).
7. Деплой, моніторинг, підтримка.

Терміни: proof of concept — 2–4 тижні; production‑система з sim‑to‑real — 3–8 місяців; RLHF для LLM — 4–10 тижнів. Вартість розраховується індивідуально — оцінимо ваш проєкт за 2 дні. Замовте консультацію, щоб уникнути типових пасток RL.

Наша команда — понад п’ять років досвіду в RL, 30+ успішних проєктів у роботиці, оптимізації ланцюгів постачання та LLM alignment. Гарантуємо прозору архітектуру та повну технічну документацію. Зв'яжіться з нами для отримання детальної оцінки вашого проєкту.