Цель документа

Qwen Validation Debugger — это инструмент для тестирования полного потока с синтетическими данными до завершения разработки операционного Retriever и валидатора.

Для одной тестовой темы создайте код для Godot 3 и Godot 4, а также JSONL, соответствующий коду, и JSONL, не соответствующий коду. Затем подставьте один и тот же JSONL в код каждой версии и проверьте, будет ли окончательное решение 예 или 아니오 правильным.

Схему ответа и типы оценок оставили без изменений.

Область синтаксиса: common, separate
Таблица JSONL: docs_chunks, api_mapping, label_prototypes
Слоты: positive, negative
Окончательное решение: 예, 아니오

Третье значение решения, оценка, поле дополнительных причин не были созданы.

Общий поток

TEST_ITEM
  -> common / separate классификация
  -> Сохранить результаты классификации
  -> Создать код целевой версии
  -> Проверка реального парсера движка Godot
  -> Проверка кода Qwen да/нет
  -> Создание JSONL только из прошедшего кода
  -> Проверка существующей JSON Schema
  -> Проверка текущего кода и прямых доказательств
  -> Перекрестная проверка JSONL и кода

separate элемент сначала создает код Godot 3. Код Godot 4 принимает этот код Godot 3 как REFERENCE_GODOT3_CODE и генерирует соответствующий код, сохраняющий ту же функциональность и порядок выполнения.

Разделение классификации и ввода генерации кода

Ответ классификации сохраняет существующие пять полей.

{
  "syntax_scope": "common 또는 separate",
  "label": "짧은 한국어 라벨",
  "reason": "분류 근거",
  "godot3_focus": "Godot 3 코드 생성 포인트",
  "godot4_focus": "Godot 4 코드 생성 포인트"
}

reason, godot3_focus, godot4_focus остаются в отображении на экране и в журнале, но не передаются в запрос генерации кода. Это делается, чтобы даже если этап классификации объясняет неверный синтаксис версии, это предложение не стало фактическим основанием для следующей генерации кода.

Для генерации кода используются только следующие входные данные.

Тестовый пункт
common или separate
Целевая версия генерации
Код Godot 3, прошедший предварительно при генерации separate Godot 4
При повторной попытке последний отклонённый код и фактический диагностический результат проверки

Синтетический кодовый контракт

Сгенерированный код должен быть не строкой, похожей на фрагмент кода, а одним файлом GDScript, который может быть разобран движком.

Первая исполняемая строка — объявление extends.
Используется класс, реально владеющий тестовым API.
Обычные функции не вложены в другие функции.
Используется реальное API действия тестового пункта.
Не имитировать целевое действие с помощью pass, комментариев или локального call.
Не смешивать синтаксис, предназначенный только для противоположной версии, в комментариях или коде.
Код Godot 4 сохраняет функции, ввод, цель и результат кода Godot 3, который уже прошёл проверку.

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

Реальная проверка движка Godot

Qwen смог пропустить неверный синтаксис, просто переоценивая свой собственный код. На реальном тесте был случай, когда в коде Godot 3 присутствовал @rpc из Godot 4, но проверяющий Qwen ответил «да».

Сейчас после генерации кода сразу запускается реальный движок.

Godot 3: --no-window --check-only --script
Godot 4: --headless --check-only --script
common: проверка Godot 3 и Godot 4

Исполняемый файл можно указать как GODOT3_BIN, GODOT4_BIN. Локальная базовая установка размещается в каталоге пользовательских данных вне репозитория. Код для проверки создаётся только во временном файле и удаляется после проверки. В диагностическом логе удаляются временный путь и путь к домашнему каталогу пользователя.

Генерация кода и проверка выполняются максимум три раза. При неудаче seed меняется, чтобы не повторять тот же ответ, а предыдущий код и реальную диагностику движка включаются в следующий запрос на генерацию.

Сохранение схемы JSONL

Поля верхнего уровня такие же, как в определениях трёх существующих таблиц.

docs_chunks

chunk_id, doc_version, source_url, source_file, source_sha256,
doc_type, symbol, section_path, heading, content, code_blocks,
language_tags, godot_version_tags, api_symbols, token_count, metadata

api_mapping

mapping_id, source_api, target_api, change_type, godot_from,
godot_to, confidence, evidence_chunk_ids, match_terms, notes,
negative_patterns

прототипы_меток

prototype_id, label, task_type, input_pattern, expected_finding,
recommended_action, evidence_mapping_ids, evidence_chunk_ids,
severity, validator_rules

validator_rules также использует только существующие четыре поля.

{
  "required_when_seen_in_code": [],
  "before_code": "",
  "after_code": "",
  "reject_when_seen_in_code": []
}

После получения ответа проверяется существующая JSON‑Schema на обязательные поля, типы, enum и наличие дополнительных полей. Если модель использует confidence как число или section_path как строку, запрос отклоняется и генерируется повторно до трёх раз.

Генерация positive и negative

positive JSONL использует прямые доказательства текущего синтезированного кода.

docs_chunks: непосредственно описывает цель кода, его объект, входной поток и результат.
api_mapping: source_api Godot 3 и target_api Godot 4 должны присутствовать в соответствующем реальном коде.
label_prototypes: доказательства before находятся в коде Godot 3, доказательства after — в коде Godot 4.
В negative_patterns и reject_when_seen_in_code у positive находятся пустые массивы.

Для генерации negative JSONL текущий код и текущий элемент не предоставляются. После текущего элемента динамически выбирается образец‑элемент и помечается как NEGATIVE_TEST_ITEM; на основе только этого другого элемента создаётся JSONL. После генерации сервер сравнивает с текущим кодом и отклоняет, если доказательства source/before пересекаются.

Этот процесс не заменяет конкретные имена API или предложения один‑к‑одному. Используются только выбор порядка образцов и сравнение строковых результатов.

Порядок проверки

Проверка выполняется в следующем порядке.

Если результат окончательно определён структурой версии‑слота, модель не вызывается и ставится оценка «нет».
Если перед миграцией нет ни одного прямого доказательства в текущем коде, ставится оценка «нет».
Только если первые два условия не сработали, Qwen сравнивает смысл и способ использования.

Детерминированный шлюз не создаёт новое состояние. Возврат остаётся прежним: 예 или 아니오 → теперь да или нет.

JSONL	Объект проверки	Ожидаемый ответ
positive `docs_chunks` той же версии	исходный код	да
positive `docs_chunks` другой версии	перекрёстный код	нет
negative `docs_chunks`	любой код	нет
positive миграции `3 -> 4`	код Godot 3	да
positive миграции `3 -> 4`	код Godot 4	нет
negative миграции `3 -> 4`	любой код	нет

Надёжность API‑запросов

Отключить вывод thinking.
Запрашивать ответы, соответствующие JSON‑Schema только с существующими полями, для классификации, кода и JSONL.
Окончательная оценка допускает только да или нет в грамматике.
При повторной генерации кода и JSONL менять seed.
При HTTP 429, 502, 503, 504, разрыве соединения или тайм‑ауте повторять запрос до трёх раз.

API‑ключ включается в запрос только из текущего ввода браузерной памяти. Он не сохраняется в репозитории, документации, логах или коммитах.

Результаты тестов от 15 июля 2026 г.

Из 27 модульных контрактных тестов все прошли.

При проверке реального движка Godot было обнаружено следующее.

Код remote func в Godot 3 прошёл парсер Godot 3.
При добавлении @rpc в код Godot 3 получена ошибка Unexpected '@'.
Код @rpc в Godot 4 прошёл парсер Godot 4.

Итоги испытаний RunPod Qwen:

Начальное полное E2E: 5 из 12 пройдено. Были обнаружены неверные синтезированные коды Godot 3 и слишком широкие оценки релевантности.
После применения проверок движка и контрактов генерации: 10 из 12 пройдено.
После добавления динамических negative‑элементов и прямого строкового шлюза для migration negative: 4 из 4 пройдено.
Оставшиеся 2 случая — модель проигнорировала условие, что positive‑миграцию нельзя применить к Godot 4; это условие перенесено в детерминированный версионный шлюз, и модульные тесты прошли.
При попытке повторного полного теста сервис RunPod вернул HTTP 502 на /v1/models и запросы генерации, поэтому тестирование прервано. Это не отказ кода или JSONL, а отсутствие ответа удалённого сервиса.

Когда удалённый сервис возобновит работу, все 12 E2E‑случаев придётся выполнить заново с нуля.