Проблема: движок выигрывает, но иногда проигрывает без причины
Движок показывает прекрасные результаты, но в некоторых ситуациях необъяснимо терпит поражение. Винрейт по серии матчей выглядит здорово, отдельные партии проваливаются, и по итоговой сводке причина не читается. Автор описал этот случай в разборе калибровки параметров шахматного движка.
Чтобы понять, что происходит, нужен цикл: анализировать большое количество данных (записи партий против программ-конкурентов), выявлять аномалии, вносить изменения в алгоритмы, подстраивать коэффициенты, запускать тестовые матчи и сравнивать результаты с прошлыми версиями. Один прогон ничего не доказывает, потому что отдельная партия зависит от дебюта, случайности и поведения конкретной сборки движка.
Движок автора играет против приложения Chess.com. Одна партия даёт слишком мало информации: статистически значимый результат получается только при многочисленных повторениях эксперимента, поэтому матчи состояли из 10-60 партий. Условия держали одинаковыми: один и тот же уровень сложности, попеременно белый и чёрный цвет, один и тот же противник. Статистика по каждой партии записывалась в CSV-файл, и в итоге получалась сводная таблица матча.
Сравнивать такие серии между версиями движка непросто: на итог влияют время на ход, формат партии и сам соперник. Почему шахматный результат плохо работает как универсальная метрика, разбираем в отдельном материале про шахматный бенчмарк.
Почему ИИ-чат не справился с анализом данных
Анализ данных с помощью ИИ-чата показал сомнительную пользу: Claude упускает важные детали, выдвигает необоснованные предположения, советует неэффективные решения. Работа замедляется и идёт по ложному следу. Так описывает результат сам автор проекта.
Причина в характере инструмента. Чат отвечает на сформулированный вопрос, но не проверяет гипотезу на всём наборе данных и не отличает правдоподобную версию от подтверждённой. В таблице из десятков партий это приводит к выводам, которые выглядят логично и разваливаются на первом же пересчёте.
Информация о каждом ходе в сводную таблицу не попадала: получилось бы слишком много данных. Для высокоуровневого анализа этого хватало, но именно там, где нужны детали, модель начинала достраивать картину сама и выдавала уверенные, но неверные объяснения.
Первые отчёты автор смотрел прямо в Терминале, в виде таблиц, которые печатал Claude. Сам формат оказался рабочим: по таблицам быстро вскрылись некоторые проблемы движка, например нехватка времени при игре на сильных уровнях, когда каждый ход обдумывался слишком долго. Код и вывод данных сработали, интерпретация данных от ИИ нет.
Вывод простой: ИИ не может заменить ручную проверку и понимание предметной области. Если вы сами не знаете, как выглядит аномалия в ваших данных, модель тем более не знает.
Где ИИ оказался полезен: скрипты для управления программами-конкурентами
Зато ИИ справился с написанием скриптов для управления программами-конкурентами. Под чётким руководством Claude научился выбирать уровень противника, распознавать позицию и последний сделанный ход, время на часах и признаки окончания партии.
Задачи конкретные и проверяемые: распознать состояние экрана, эмулировать ввод, понять, что партия закончилась. Здесь ИИ работал по ТЗ и выдавал код, который можно запускать сразу, без долгой отладки.
Ещё одно свойство скриптов: они работают без обращения к самому ИИ и к интернету. Это экономит токены и убирает зависимость от сети и доступности API, что критично, когда матч длится часами.
Управление приложением Chess.com мышью стало отдельной головной болью. Приложение реагирует только на мышь, Claude забирал курсор и не давал работать параллельно. Автор рассматривал перенос в виртуальную машину и подключение двух мышей с раздельными драйверами, но на тот момент посчитал это перебором. Поэтому матчи гонялись ночами, пока он спал.
Из этого кейса вытекает граница применимости: ИИ эффективен для написания кода по чёткому ТЗ. Есть сформулированное требование, есть способ проверить результат, есть готовый ответ.
Как собрать локальный дашборд для анализа статистики: PHP, HTML/CSS и минимум JavaScript
Для анализа накопленной статистики автор собрал собственный локальный дашборд на PHP, HTML/CSS и минимуме JavaScript. Код написал Claude, а визуализацию автор проектировал сам: набросок в Figma и текстовое ТЗ. Разделение ролей здесь ключевое: модель отвечает за синтаксис и рутину, человек за метрики и компоновку.
До дашборда был промежуточный шаг. Данные матча загружались в Apple Numbers (аналог Microsoft Excel), добавлялись 4 столбца, приводящих данные к удобному для отображения виду, и строился график. Этого хватило, чтобы увидеть примерную силу игры. Ручное обновление быстро надоело, и появился дашборд, который автоматизировал разбор накопленной статистики.
Стек выбран по прагматичным причинам. PHP и HTML/CSS дают локальный инструмент без внешних сервисов и подписок, минимум JavaScript не превращает страницу в SPA, а данные лежат рядом с движком. Для проекта, где анализ нужен автору, а не команде из десяти человек, этого набора достаточно.
Текстовое ТЗ плюс набросок в Figma работают лучше, чем длинные описания словами. Схема фиксирует, какие графики и таблицы нужны, а промпт описывает поведение каждого блока. Почему красивый ИИ-дашборд не заменяет аналитика, мы разбирали отдельно.
Универсальных дашбордов не существует. Набор метрик для шахматного движка (винрейт по уровням, среднее время на ход, доля партий, проигранных по часам, распределение результата по цвету) бесполезен в другом проекте. Шаблонная панель с общими графиками не покажет, где именно ломается ваша логика.
Если проект разрастается до оркестратора задач с несколькими интерфейсами, одного дашборда мало. Пет-проект на Java, выросший в оркестратор задач с веб-дашбордом, показывает, во что превращается такая система, когда в неё добавляются CLI-сессии, tmux и git worktree.
Что выявил дашборд: баги, аномальные партии и настройка сложности
Дашборд помог выявить баги и аномальные партии, которые терялись в средних цифрах. Именно на графиках стали заметны выбросы: партии, выбивающиеся из общей картины по времени на ход или по результату.
По описанию кейса, на основе данных автор настроил плавный рост сложности, добавил разогрев уровня, понижение уровня при нехватке времени и правило десяти секунд. Логика этих механизмов читается так: разогрев даёт движку несколько спокойных ходов до выхода на боевой режим, понижение уровня спасает партию, когда часы поджимают, а правило десяти секунд ограничивает время на отдельный ход.
Одна из подтверждённых проблем вскрылась ещё по таблицам в Терминале: нехватка времени при игре на сильных уровнях. Каждый ход обдумывался слишком долго, и движок проигрывал по часам, а не по позиции.
Ограничение, о котором стоит сказать прямо: конкретные пороги и формулы этих настроек в опубликованном разборе не приводятся. Известно, что дашборд помог их подобрать, но точные значения придётся выводить самому под свой движок и свой регламент времени.
Без дашборда такие закономерности остаются неочевидными. В сводной таблице матча видно только итог, а причина провала прячется в распределении времени и в редких выбросах.
Честные ограничения ИИ в таких проектах
ИИ-чат не подходит для анализа данных, если нужна точность и учёт деталей. Он может упускать важное, строить необоснованные предположения и предлагать неэффективные решения, а в шахматном кейсе это прямо замедляло работу.
ИИ хорошо пишет код по чёткому ТЗ, но не заменяет аналитика. Скрипты для управления конкурентами и код дашборда это подтверждают: обе задачи раскладываются на требования и проверяются запуском. Гипотезы о том, почему движок теряет очки на конкретном уровне, так не разложишь.
Полезное побочное свойство скриптов: они работают без обращения к ИИ и интернету, что экономит токены и время на длинных сериях матчей.
Общая закономерность та же, что и в обычной разработке с ИИ: ускоряется рутина, а ответственность за решения остаётся на человеке. Границы применимости и типичные провалы ИИ в разработке мы разбирали на примере проекта, который развалился после добавления новой функции.
Выводы: кому подходит такой подход и что учесть
- ИИ берите на рутину: скрипты управления интерфейсом, распознавание состояния экрана и хода, код дашборда по готовому макету.
- Анализ данных ведите сами или специализированным инструментом. Каждую гипотезу модели проверяйте на полном наборе, а не на удобной выборке.
- Фиксируйте условия матчей: 10-60 партий, один уровень сложности, чередование цвета, один противник. Иначе сравнение версий движка ничего не значит.
- Проектируйте визуализацию до кода. Набросок в Figma и текстовое ТЗ дают ИИ понятную рамку и экономят итерации.
- Помните, что универсальных дашбордов нет: набор метрик под свой проект придётся определить самому.
Локальный дашборд на PHP, HTML/CSS и минимуме JavaScript - рабочий вариант для небольших проектов: без облака, подписок и лишних зависимостей. Такой подход стоит брать, если вы ведёте свой движок или похожий проект и хотите видеть данные, а не полагаться на догадки. Ручная проверка выводов ИИ при этом остаётся обязательной частью процесса.