12 июня 2026 г.

Окончательно решили снова написать обзор разработки после долгого перерыва

• За это время из‑за желания оставлять только идеальные записи откладывал их написание
• Чтобы осмысленно зафиксировать попытки и размышления последних ~10 дней, собрал материалы по исследованию и проектированию архитектуры модели, специализированной для Godot

Провёл эксперимент по размещению модели семейства Qwen на локальном ПК, чтобы сократить расходы на RunPod

• Пытался запустить 9‑млрд‑параметровую модель в WSL на системе с RTX 3060
• Однако проблемы с пропускной способностью сети и задержкой отклика были серьёзными: уже на этапе «размышления» перед генерацией ответа требовалось более 5 минут, поэтому эксперимент с локальным запуском был прекращён

Для обучения модели, специализированной на Godot, сначала исследовал способы сбора датасетов

• В качестве эталонного датасета рассмотрел wallstoneai/godot-gdscript-dataset от Hugging Face
• С помощью Gemini проанализировал, как был создан этот датасет
• Ключевая идея — объединить в один текст файлы репозитория GitHub: README.md, файлы .gd, структуру проекта, а затем, используя файл настроек project.godot и различия в синтаксисе GDScript, классифицировать версии Godot 3/4
• Особенно полезным оказался вывод, что, используя такие версии‑специфичные подсказки, как config_version, config/features, onready var, @onready, KinematicBody, CharacterBody3D, можно фильтровать даже редкие языки без JSON‑зависимых файлов

Чтобы понять процесс дообучения, посмотрел обучающее видео по дообучению классического языка программирования OPL

• Ссылка: https://www.youtube.com/watch?v=5wGD92ktQL4
• При этом понял, что сбор датасета — это отдельная задача от приведения его к форме, пригодной для обучения

Спросил у наставника SSAFY, как эффективно собирать данные редких языков определённой версии

• Получил ответ, что текущий датасет Godot больше похож на набор «сырого» кода, а не на Q&A‑датасет для обучения ассистента
• Чтобы создать чат‑бот, лучше не просто загружать сырой код, а с помощью LLM генерировать пары вопрос‑ответ и формировать instruction‑датасет
• Без этого модель будет склонна отвечать, как обычно, на запросы типа «спроектируй карту», используя преимущественно обученные ответы на Python

Рассмотрел в качестве candidate‑instruction‑датасета ise-uiuc/Magicoder-Evol-Instruct-110K

• Большая часть материалов ориентирована на Python, поэтому напрямую использовать их для обучения исключительно на Godot 4 нецелесообразно
• Возник вопрос: «Можно ли заставить модель отвечать по‑Godot, даже если в запросе нет явного упоминания Godot?», но из‑за сильного влияния Python‑весов в базовой модели лучше явно указывать контекст Godot, чтобы повысить вероятность правильного ответа

Проконсультировался со старшим коллегой по поводу RAG и подходов к prompting

• Получил совет, что вместо подачи всей коллекции данных модели целесообразнее построить векторный поиск по markdown‑документам и подсказывать модели только нужные фрагменты
• Поскольку переиндексация больших объёмов текста требует значительных ресурсов и времени, на текущем этапе более практичным выглядит решение на основе поиска/промптинга, а не полного обучения

Спроектировал начальную архитектуру для создания модели, специализированной на коде Godot

Сначала я думал о простой структуре вроде сбор датасета -> создание набора вопросов/ответов -> обучение модели

• Но возникла проблема: чтобы точно фильтровать и генерировать правильные данные, нужно хорошо разбираться в переходе от Godot 3 к 4
• Я решил, что если ошибиться, в набор ответов могут попасть код Godot 3, Python‑код и устаревший API, поэтому пересмотрел архитектуру

Для классификации и преобразования версий Godot 3/4 спроектировал структуру с RAG‑чат‑ботом на переднем плане, основанным на официальной документации

• Я представил, что можно собрать RAG‑чат‑бот, проанализировав миграционную документацию Godot и документы Godot 4, а затем с его помощью классифицировать, относится ли собранный материал к Godot 3 или 4
• Затем планируется обрабатывать только данные, определённые как Godot 4, в набор инструкций

Через ChatGPT получил дополнительные идеи по обучению SFT/DPO

• В SFT можно создавать задачи вроде классификации Godot 3/4, преобразования Godot 3 → 4, генерации кода Godot 4, исправления ошибок Godot 4, исправления/отказа от устаревшего API Godot 3
• В DPO/Preference можно сформировать предпочтительные данные, где плохой ответ = ответ с кодом Godot 3, хороший ответ = чистый код Godot 4

Использовал unclecode/crawl4ai для обхода официальной документации Godot

• Начальный документ: https://docs.godotengine.org/en/stable/tutorials/migrating/upgrading_to_godot_4.html
• Обошёл и задокументировал около 1 500 страниц, включая официальную документацию Godot 4, миграцию Godot 3 → 4, справочник классов Godot 4 и учебные материалы Godot 4
• Хотя объём выглядел большим, по сравнению с контекстом всей модели это лишь около 3 %

Получил дополнительный совет от старшего коллеги по узкому месту диска I/O в пайплайне хранения и обучения данных

• Вместо постоянного онлайн‑тюнинга лучше собирать и предварительно/постобрабатывать данные почти в реальном времени, а обучение проводить пакетно
• Решил использовать метрико‑ориентированную пакетную обработку, запускающую усиленное обучение или дообучение, когда набор данных превысит определённый порог
• Поскольку полностью избавиться от расходов на переиндексацию невозможно, я пришёл к выводу, что стабильность пайплайна сбора и обработки данных важнее, чем реальное время обучения

Текущий суммированный план

• Обойти официальную документацию и построить RAG‑базу знаний на основе Godot 4
• Собрать проекты Godot с GitHub и объединить README, структуру проекта и файлы GDScript на уровне репозитория
• Выполнить первичную фильтрацию с помощью настроек project.godot и различий синтаксиса Godot 3/4
• С помощью RAG‑чат‑бота дополнительно определить, относится ли материал к Godot 3/4, использует ли устаревший API и подходит ли он для Godot 4
• На основе отфильтрованных данных Godot 4 создать наборы «instruction/response»
• Обучить модель кодинга Godot 4 на данных SFT и DPO/Preference

Ретроспектива

• За последние 10 дней я пытался оставить только готовый результат, поэтому не зафиксировал процесс
• Однако неудачные эксперименты, блокирующие моменты и изменённые решения оказались самыми ценными записями для будущего направления
• В дальнейшем я планирую не стремиться только к идеальному результату, а постоянно фиксировать ход мыслей и решений, чтобы постепенно развиваться

Ретроспектива разработки: docs/retrospectives/2026-06-12.md