idea_world_labDEV JOURNAL
воскресенье, 28 июня 2026 г.

Схема JSONL для тестирования Qwen и её назначение

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

Цель

Создавать фрагменты кода Godot с помощью Qwen, к каждому фрагменту прикреплять правильный JSONL и неправильный JSONL, а затем при проверке «да»/«нет» использовать указанный формат JSONL и описать назначение каждого JSONL.

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

Общие правила

JSONL записывается построчно: в каждой строке один JSON‑объект.

{...}
{...}
{...}

В тесте обёртка, охватывающая имя таблицы, не используется, а поле, соответствующее колонке целевой таблицы, размещается на верхнем уровне.

Хорошо:
{"chunk_id":"...","content":"...","code_blocks":[...]}

Избегать:
{"table":"docs_chunks","payload":{"chunk_id":"..."}}

Поля, которые автоматически создаются в базе данных или используются в поисковом индексе, не нужно заполнять вручную в тестовом JSONL.

Поле управления БД Тестовый критерий JSONL
id Исключить
embedding исключить или null
search_tsv исключить
created_at Исключить

В проверке прямых доказательств Qwen важно то, что «какое поле в JSONL непосредственно соответствует реальной строке/API/шаблону в SOURCE_CODE».

docs_chunks

Назначение

docs_chunks — это JSONL, в котором содержимое официальной документации, учебных материалов и текста справочника классов сохраняется по кускам (chunks).

Используется для запросов объяснения кода, проверки общего использования API, проверки описания общих синтаксических конструкций Godot 3/4. Это служит основанием для проверки того, связан ли данный код напрямую с конкретным описанием в официальной документации, а не просто с правилами миграции.

Формат JSONL

{
  "chunk_id": "text, required",
  "doc_version": "text, required",
  "source_url": "text, required",
  "source_file": "text, required",
  "source_sha256": "text, required",
  "doc_type": "text, required",
  "symbol": "text or null",
  "section_path": "array, required",
  "heading": "text or null",
  "content": "text, required",
  "code_blocks": "array, required",
  "language_tags": "array<string>",
  "godot_version_tags": "array<string>",
  "api_symbols": "array<string>",
  "token_count": "integer or null",
  "metadata": "object"
}

Прямые доказательства по полям

Поле Критерий прямого доказательства
content Должно описывать API, имя функции, имя узла, шаблон кода, присутствующие в SOURCE_CODE
code_blocks Должна содержать строку кода или шаблон вызова, аналогичный SOURCE_CODE
api_symbols Должны точно совпадать с API/символами, присутствующими в SOURCE_CODE
heading Вспомогательное доказательство. Сильное только при совпадении заголовка без подтверждения в тексте/коде — слабое
godot_version_tags Для справки о версии. Не должно использоваться единственно для оценки «да»

Роль в тестах

Случай Ожидание
SOURCE_CODE использует get_viewport_rect().size, и то же выражение присутствует в content или code_blocks да
Совпадает только широкая тема с SOURCE_CODE, но конкретных строк/API нет нет
Описание общей синтаксической конструкции Godot 3/4, и строка кода точно совпадает да
Совпадают только теги версии, без кодового подтверждения нет

api_mapping

Назначение

api_mapping — это JSONL, в котором хранится информация о том, как изменились имена, названия классов, функции и символы при переходе от Godot 3 к Godot 4.

Используется для определения простых переименований, замен, устаревших/удалённых API. Примеры, где полностью меняется способ использования функции, относятся к разделу label_prototypes.

Формат JSONL

{
  "mapping_id": "text, required",
  "source_api": "text, required",
  "target_api": "text or null",
  "change_type": "text, required",
  "godot_from": "text, required",
  "godot_to": "text, required",
  "confidence": "text, required",
  "evidence_chunk_ids": "array<string>",
  "match_terms": "array<string>",
  "notes": "text",
  "negative_patterns": "array<string>"
}

Прямое доказательство по полям

Поле Критерий прямого доказательства
source_api Должно фактически встречаться в SOURCE_CODE
target_api Используется для проверки кода после преобразования или описания миграции
match_terms Должно точно совпадать с реальной строкой/API в SOURCE_CODE
notes Дополнительные пояснения. Считается вместе с source_api/match_terms, а не отдельно
negative_patterns Если SOURCE_CODE соответствует этому шаблону, это становится доказательством «нет»

Роль в тестах

Случай Ожидание
В SOURCE_CODE есть KinematicBody2D, а в JSONL source_api тоже KinematicBody2D Да
В SOURCE_CODE есть yield(, а в JSONL match_terms есть yield( Да
JSONL содержит Camera -> Camera3D, а SOURCE_CODE — KinematicBody2D Нет
Совпадают только широкие термины, такие как Godot 3/4, migration Нет

label_prototypes

Назначение

label_prototypes — это JSONL, в котором сохраняются примеры, когда меняется не просто имя, а полностью меняется способ использования функции, состав аргументов и паттерн вызова.

Если api_mapping отвечает на вопрос «какое имя изменилось на какое», то label_prototypes отвечает на вопрос «каким паттерном следует писать код».

Формат JSONL

{
  "prototype_id": "text, required",
  "label": "text, required",
  "task_type": "text, required",
  "input_pattern": "text, required",
  "expected_finding": "text, required",
  "recommended_action": "text, required",
  "evidence_mapping_ids": "array<string>",
  "evidence_chunk_ids": "array<string>",
  "severity": "text",
  "validator_rules": "object"
}

validator_rules может иметь следующие подполя.

{
  "required_when_seen_in_code": "array<string>",
  "before_code": "text",
  "after_code": "text",
  "reject_when_seen_in_code": "array<string>"
}

Прямые доказательства по полям

Поле Критерий прямого доказательства
input_pattern Должен точно соответствовать вызывающему шаблону SOURCE_CODE
expected_finding Описание того, какую проблему/шаблон нужно найти
recommended_action Направление преобразования или объяснения
validator_rules.required_when_seen_in_code Должен реально присутствовать в SOURCE_CODE, чтобы стать «да» доказательством
validator_rules.before_code Если совпадает с тем же предыдущим шаблоном в SOURCE_CODE, это сильное «да» доказательство
validator_rules.reject_when_seen_in_code Если в SOURCE_CODE присутствует этот шаблон, прототип считается «нет»

Роль в тестах

Случай Ожидание
В SOURCE_CODE есть yield(get_tree().create_timer(...), "timeout") и before_code тоже такой же шаблон да
В SOURCE_CODE есть move_and_slide(velocity), а прототип объясняет изменение способа вызова да
SOURCE_CODE использует yield, а прототип — преобразование в Color8 нет
Есть только одинаковая метка, но реального шаблона нет нет

Границы трёх JSONL

JSONL Ключевой вопрос Что обычно должно совпадать
docs_chunks Является ли этот код напрямую связанным с официальной документацией/учебником content, code_blocks, api_symbols
api_mapping Изменилась ли в Godot 3 → 4 названия или цели API/символов source_api, target_api, match_terms
label_prototypes Является ли пример полным изменением способа использования/аргументов/шаблона вызова input_pattern, validator_rules, before_code

Обработка общих синтаксисов

Если синтаксис одинаков в Godot 3 и Godot 4, различия версий не учитываются.

Ситуация Какой JSONL использовать Критерий оценки
Код, используемый в обоих версиях, например _ready(), _process(delta), print() Один JSONL с этим кодом/функцией + один JSONL с совершенно другой функцией Если есть прямое доказательство по тому же chunk кода — да, иначе для другой функции — нет
Присоединение JSONL миграции, не относящегося к общему синтаксису api_mapping или label_prototypes — неверный ответ Если реального API/шаблона нет — нет
Появление специфичного API Godot 3 JSONL только для Godot 3 + JSONL только для Godot 4 JSONL, который напрямую совпадает со строкой/шаблоном Godot 3 в SOURCE_CODE, получает да
Появление специфичного API Godot 4 JSONL только для Godot 4 + JSONL только для Godot 3 JSONL, который напрямую совпадает со строкой/шаблоном Godot 4 в SOURCE_CODE, получает да