Схема 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, получает да |