2026-06-17 Памятка о структуре генерации данных на основе детектора Godot RAG

Структурное изображение

Основная идея

Эта структура основывается на том, что окончательное решение о метке не передаётся LLM. LLM берёт на себя вспомогательные задачи генерации, такие как исправление кода, объяснения, вопросы/ответы SFT, плохие ответы DPO, черновики патчей, а окончательная сборка и проверка реальных меток и финального JSONL осуществляется локальным конвейером системы.

Итого, это следующие принципы.

LLM — вспомогательный генератор  
Метка определяется системой  
Итоговый JSONL собирается/проверяется конвейером

Общий поток

Подготовка документа
-> Создание локальной БД
-> Ввод исходных данных GitHub
-> Извлечение символов
-> Поиск правил/векторов/ключевых слов
-> Оценка и определение меток
-> Помощь в создании LLM
-> Генерация окончательного JSONL

Эта структура — черновик для создания данных классификации Godot 3/4, сопоставления API, исправления миграции, instruction SFT, предпочтения DPO, исследователя репозитория, генерации патчей и проверки метаданных в одном конвейере.

1. Подготовка документации

На офлайн‑этапе собираются и очищаются официальные документы Godot.

• Сбор официальных документов Godot
• Удаление ненужных фраз
• Классификация типов документов
• Парсинг на основе структуры
• Создание фрагментов документов
• Создание эмбеддингов и построение индекса

Основные результаты:

docs_chunks.jsonl

2. Создаваемые 3 ключевых БД

База данных сопоставления API

Сохраняет отношения изменений между API Godot 3 и API Godot 4.

Пример:

KinematicBody2D -> CharacterBody2D
yield -> await
export var -> @export
move_and_slide(v) -> move_and_slide()

Сохраненный файл:

api_mapping.jsonl

Официальная документация векторной БД

Создайте векторную БД для поиска по доказательствам, встраивая фрагменты документа.

Назначение:

• Поиск связанных фрагментов официальной документации
• Предоставление оснований для преобразований
• Объяснение причин изменения API
• Снижение галлюцинаций

Прототип БД меток

Сохраняет прототип для поиска по схожести с кандидатами меток.

Пример метки:

godot3_code
godot4_code
mixed_code
broken_code

Сохраненный файл:

label_prototypes.jsonl

3. Поиск/Определение метки

Когда в систему поступают исходные данные, собранные на GitHub, сначала система анализирует код и документацию.

Пример ввода:

repo: owner/repo
file_path: scripts/Player.gd
content: ...
repo_tree: ...

Система извлекает символы.

Пример:

KinematicBody2D
move_and_slide(velocity)
export var
yield

Далее выполняется следующий поиск.

• Просмотр базы данных сопоставления API
• Поиск в векторной базе данных официальной документации
• Поиск в базе данных прототипов меток

Окончательная метка определяется не LLM, а системным скорингом.

Пример:

label: godot3
confidence: 0.93
bad_apis:
  - KinematicBody2D
  - move_and_slide(v)
  - export var
replacement_apis:
  - CharacterBody2D
  - move_and_slide()
  - @export

4. Помощь в генерации LLM

LLM не определяет метку напрямую, а помогает в генерации, получая в качестве ввода метку и обоснование, определённые системой.

Возможные задачи генерации:

• Создание исправленного кода
• Создание описания/обоснования
• Создание вопросов/ответов SFT
• Создание плохих ответов DPO
• Создание ответов для поиска файлов
• Помощь в создании патча
• Проверка/анализ проблем

Важно следующее:

Результат генерации LLM является черновиком.  
Метка, окончательная схема, confidence, проверка управляются системой.

5. Финальное создание JSONL

Конвейер собирает результаты системы и результаты генерации LLM в один JSON‑объект.

На этапе проверки проверяется следующее.

• Наличие обязательных полей
• Согласованность меток
• Отсутствие оставшихся ошибочных API
• Пересчёт confidence
• Связь между документальными основаниями и выводом

Создаваемые 8 наборов данных

1. Данные классификации версий

Файл:

version_classification.jsonl

Содержание:

• Классификация Godot 3/4/mixed/broken
• Определение valid_for_godot4
• Извлечение bad_apis

2. Данные сопоставления API

Файл:

api_mapping.jsonl

Содержание:

• old_api → new_api сопоставление
• change_type, category и т.д.

3. Данные правильных преобразований/изменений

Файл:

migration_fix.jsonl

Содержание:

• before/after код
• Причина изменения
• Список настроек

4. Вопросы/Ответы SFT данные

Файл:

instruction_sft.jsonl

Содержание:

• instruction/input/output
• образцы различных шаблонов

5. DPO предпочтительные данные

Файл:

dpo_preference.jsonl

Содержание:

• chosen
• rejected
• Причина/Условие

6. Данные Repo Explorer

Файл:

repo_explorer.jsonl

Содержание:

• Прогноз файлов, которые нужно прочитать для решения задач/ошибок
• Причина, по которой нужно читать

7. Данные патча

Файл:

patch_generation.jsonl

Нет содержимого для перевода.

• before/after
• unified diff / patch
• Причина применения

8. Мета/информация проверки

Файл:

metadata_verification.jsonl

Содержание:

• confidence
• оценка
• основание
• идентификатор фрагмента исходного документа
• информация о качестве/риске

Сводка выполнения

GitHub исходные данные
-> извлечение символов
-> поиск правил/БД
-> оценка меток
-> помощь в создании LLM
-> окончательная сборка и сохранение JSON

Основные принципы

• Лейблы определяются системой.
• LLM выполняет только вспомогательную роль в генерации.
• Конечный JSONL собирает и проверяет конвейер.
• Сохраняются документы-основания, оценка, confidence и информация об источнике.
• Обязательно проверять, не осталось ли неверных API Godot 3.