Архитектура оценки анализа исходного кода Godot

Дата создания: 25 июня 2026 г.

Цель

С помощью RAG официальной документации Godot классифицировать исходный код GitHub по проектам, а затем оформить процесс создания данных SFT/DPO.

Ключевой момент этого обзора — рассматривать docs_chunks, api_mapping и label_prototypes как единый объект классификации официальной документации Markdown → JSONL. В зависимости от характера документа фрагменты описания попадают в docs_chunks, изменения имён функций/классов/символов — в api_mapping, а изменения способов использования функций/структуры аргументов/шаблонов вызовов — в label_prototypes.

Текущее заключение

На этапе первоначального сбора официальной документации ключевые таблицы, которые нужно подготовить, следующие три.

Финальная единица анализа

Входом является проект GitHub или локальная директория проекта.

Анализатор просматривает файловую систему и разбивает файлы Godot на фрагменты AST или кода.

Начальные цели:

Поток вызова LLM по требованию

LLM не работает постоянно, а вызывается по требованию для каждого необходимого фрагмента AST/кода.

Каждый фрагмент AST передаётся в LLM вместе с соответствующими обоснованиями.

AST/code chunk
+ Результаты поиска необходимой официальной документации JSONL
+ Схема выводимого JSONL
+ Информация об идентификации проекта/файла

Схема ответа LLM и столбцы сохранения в базе данных score еще не определены. В текущем документе записывается только то, какие таблицы ищутся в каком потоке и как результат используется для классификации файловой системы.

Создание описания кода: поток данных

В процессе создания описания кода docs_chunks является ключевым основанием.

Поток:

1. Пользователь вводит «Что это значит?» и исходный код.

2. AST‑парсер разбивает код на фрагменты.

3. Retriever ищет соответствующую официальную документацию в docs_chunks.

4. Qwen 3.6 проверяет, связаны ли между собой подсказка, фрагмент кода и найденные доказательства.

5. Нерелевантные результаты поиска отбрасываются.

6. Связанные доказательства и фрагменты кода передаются обратно Qwen 3.6 для создания объяснительного JSONL.

7. Validator проверяет ответ.

8. Сохранить проверенный результат в базе данных score.

9. Классифицировать файловую систему по результатам базы данных score.

Godot 3 -> Godot 4 функция преобразования потока

Миграция опирается на api_mapping как основной источник.

Поток:

1. Пользователь вводит «Нужна ли эта трансформация?» и исходный код.
2. AST‑парсер извлекает кандидаты символов Godot API.
3. Retriever ищет в api_mapping исходный API, целевой API и тип изменения.
4. Qwen 3.6 проверяет, действительно ли найденный результат относится к данному фрагменту кода.
5. Неактуальные сопоставления отбрасываются.
6. На основе только релевантных сопоставлений генерируется JSONL для миграции Godot 3 → 4.
7. Validator проверяет ответ преобразования.
8. Проверенный результат сохраняется в базе данных оценок (score DB).
9. По результатам score DB файловая система классифицируется.

Godot 3 -> Godot 4 поток преобразования паттернов использования

Для преобразования паттернов использования ключевым источником является label_prototypes.

Поток:

1. Пользователь вводит «Нужна ли эта трансформация?» и исходный код.
2. AST‑парсер извлекает вызовы функций, состав аргументов и кандидаты паттернов вызова.
3. Retriever ищет в label_prototypes основания для преобразования способов использования/аргументов/паттернов вызова.
4. Qwen 3.6 проверяет, действительно ли найденный результат относится к данному фрагменту кода.
5. Неактуальные прототипы отбрасываются.
6. На основе только релевантных прототипов генерируется JSONL для преобразования паттернов использования Godot 3 → 4.
7. Validator проверяет ответ преобразования.
8. Проверенный результат сохраняется в базе данных оценок (score DB).
9. По результатам score DB файловая система классифицируется.

Score DB

Результаты поиска Retriever по отдельным фрагментам AST, результаты проверки LLM и результаты прохождения Validator сохраняются в окончательной базе данных score DB.

score DB — это не исходные обучающие данные, а хранилище результатов оценки, используемое для классификации файловой системы. В ней фиксируются результаты Retriever/LLM/Validator, полученные в процессе анализа исходного кода.

• docs_chunks — результаты поиска: проверка того, действительно ли ссылки на официальную документацию, указанные в запросе описания кода, относятся к рассматриваемому коду.
• api_mapping — результаты поиска: проверка того, действительно ли основания преобразования имён функций/символов из Godot 3 в Godot 4 относятся к рассматриваемому коду.
• label_prototypes — результаты поиска: проверка того, действительно ли основания преобразования способов использования функций, состава аргументов и шаблонов вызовов относятся к рассматриваемому коду.

Колонки, методы агрегации и метки классификации в score DB пока не определены. В этом документе фиксируется лишь роль score DB как «хранилища предварительных результатов оценки перед классификацией».

Окончательная классификация файловой системы:

project source
  -> AST/code chunks
  -> official docs JSONL retrieval
  -> on-demand LLM verification
  -> score DB
  -> classified filesystem

Создание SFT и DPO

Подробный дизайн SFT и DPO ещё не определён. Сейчас подтверждено лишь то, что база данных оценок (score DB) сама по себе не является источником обучающих данных. Сначала будет классифицирована файловая система, а затем, опираясь на классифицированную файловую систему, будет создан источник для проектирования SFT и DPO.

Критерии безопасной загрузки в Git

В этой документации не загружаются веб‑интерфейс, локальные скрипты преобразования, скрипты анализа AST, API‑ключи, файлы JSONL и тестовый исходный код.

Разрешённые к загрузке:

• Документация по архитектуре
• Изображения схем потоков
• Текстовые материалы с отзывами/дорожными картами, которые можно публиковать

Запрещённые к загрузке:

• Код Streamlit‑приложения
• Скрипт экспериментального преобразования Markdown → JSONL
• Скрипт экспериментального анализа Retriever/AST
• API‑ключ, endpoint, файл .env
• Полный архив исходных Markdown‑файлов, собранных полностью
• Результаты анализа AST/фрагментов кода
• Промежуточные файлы JSONL
• Исходный код внешнего проекта Godot, клонированный только для тестов