2026-06-14 Отчёт

Мысли, возникшие в автобусе, едущем в Сеул

Сегодня в автобусе, едущем в Сеул, я вновь задумался о разработанном ранее конвейере данных/ RAG для Godot 4. 12 июня я планировал собрать официальную документацию, собрать проекты Godot с GitHub, а затем разместить RAG‑чат‑бота на переднем плане, чтобы определять, относится ли проект к Godot 3 или Godot 4, и генерировать инструкционные данные.

Но сегодня, пересмотрев всё, я понял, что для корректной работы этой структуры остаётся довольно много нерешённых вопросов. Особенно меня беспокоит большой разрыв между «собранными документами» и тем, как «модель эффективно использует эти документы».

Первый вопрос: сможет ли RAG‑чат‑бот обработать весь контекст?

Ранее я думал, что если собрать официальную документацию Godot с помощью краулинга и создать RAG‑чатбота, её можно будет использовать для классификации или проверки собранных проектов на GitHub. Однако, представив сценарий, в котором проект с GitHub скрапится, преобразуется в форматы md, jsonl и затем весь этот контент сразу передаётся чатботу, возникли сомнения.

Сможет ли модель принять весь этот входной контекст?

Даже один проект Godot включает README, структуру каталогов, множество файлов .gd, файлы сцен и пути к ресурсам. Если к этому добавить фрагменты официальной документации, найденные через RAG, объём ввода быстро возрастёт. То, что документ был получен путём краулинга, не гарантирует, что модель сможет стабильно прочитать весь проект и связанные с ним документы при каждом запросе.

В конечном итоге создание RAG‑чатбота означает не то, что вы загружаете целый документ, а то, что вы создаёте структуру поиска/отбора, которая решает, какие фрагменты документа извлекать для конкретного вопроса. Если этот механизм слаб, модель может упустить важные файлы или, читая ненужные документы, потерять действительно необходимый контекст проекта.

Второй вопрос: достаточно ли одного кода‑ответа на один вопрос

Второй возникший вопрос касался формы набора данных инструкций. Например, если подумать о вопросе «Создай карту», ответ на него может быть не просто одним куском кода.

Чтобы LLM действительно сгенерировал ответ, необходимо пройти несколько этапов. Нужно посмотреть структуру проекта, понять, какие сцены и скрипты есть, проверить доступные ассеты, прочитать существующий стиль кода, убедиться, что он соответствует синтаксису Godot 4, и в конце решить, какие файлы и какой код нужно изменить.

То есть вопрос «Создай карту» выглядит как одна просьба, но внутри требует прохождения нескольких слоёв вывода. Возникает сомнение, сможет ли модель выучить промежуточный процесс рассуждения, если в обучающих данных оставить только финальный код ответа.

В правильных данных должно быть не только готовое решение, но и информация о том, какие файлы нужно читать, на каких данных основано решение, почему выбран тот или иной API и т.д. Особенно если хочется, чтобы агент вёл себя как кодирующий помощник, может быть более уместно сохранять в данных поток «вопрос → поиск → оценка → правка → проверка», а не просто «вопрос → ответ».

Третий вопрос: не вернётся ли вес Python при обработке чанков

Третий вопрос был о проблеме весов языка. Даже если в запросе указать «Создай карту в Godot 4», при разбиении проекта или документации на чанки модель может сильнее активировать весы, связанные с Python‑кодом или типичными паттернами решения задач на Python.

Универсальные модели кодинга, скорее всего, обучались гораздо больше на Python. Поэтому простого добавления слова Godot в начало запроса может быть недостаточно. Если в найденных чанках контекст Godot 4 недостаточно сильный, или в процессе промежуточных рассуждений всплывают общие паттерны кодинга, ответ может «переключиться» на стиль Python.

Поэтому нужно не просто говорить «Сделай это в Godot 4», а на этапе подсказки и предобработки данных усиливать контекст Godot 4. Например, помечать входные данные специальным тегом Godot 4, более строго фильтровать данные, где смешаны Godot 3 или другие языки, либо перед генерацией ответа многократно вводить ограничение «Эта задача решается в GDScript Godot 4».

Сегодняшнее резюме

Главный вывод, который я сделал сегодня, заключается в том, что RAG или краулинг сами по себе не являются решением. Более важно, чем собрать много документов, — спроектировать, какой контекст должен читать модель из реального запроса и какие выводы она должна делать.

Текущая структура, кажется, должна быть разбита на более мелкие этапы.

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

В итоге, чтобы создать «модель кодирования Godot 4», недостаточно просто собрать код Godot 4. Нужно отразить в данных, в каком порядке модель читает проект, по каким критериям определяет, что это Godot 4, и как выбирает лучший ответ.

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

Сегодня я не писал много кода, но снова увидел пробелы в предыдущем дизайне. Размышляя в автобусе, я заметил проблему, которую упустил за столом. Сказать, что создаёшь RAG‑чатбота, легко, но на практике всё связано: единицы поиска, размер контекста, структура вопросов/ответов и управление весом языка.

Ответов пока нет. Но появление вопросов — хороший сигнал. Если зафиксировать их сейчас, они станут критериями для проверки при реализации пайплайна позже.

Дальше нужно конкретизировать, на какие единицы делить контекст проекта, насколько включать процесс вывода в instruction‑данные и как создать правила предобработки, чтобы сохранять сильный контекст Godot 4.