Qwen Validation Debugger стратегия и запись реализации

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

Цель

Этот документ описывает причины создания tools/qwen-validation-debugger и фиксирует реальный процесс его работы.

28 июня вручную создал фрагменты кода Godot и JSONL с помощью Qwen, затем напрямую объединил промпт + фрагмент кода + JSONL, чтобы проверить, как выводятся ответы «да»/«нет». Этот метод был полезен для определения направления, но по мере увеличения количества пунктов стоимость ручного копирования, запоминания критериев генерации и сравнения результатов становилась слишком высокой.

Поэтому 30 июня я превратил этот процесс в отдельный веб‑инструмент. Цель этого инструмента — не обучение окончательной модели, а визуальное отслеживание взаимосвязи между сгенерированным Qwen тестовым кодом и JSONL, а также быстрое обнаружение неправильных решений «да»/«нет».

Текущий экран

Текущий инструмент запускается по адресу http://localhost:8520/.

Экран разделён на три основные области.

• Слева: чек‑лист из 50 пунктов тестов Godot
• По центру/в правом верхнем углу: AI‑метка выбранного пункта и результат генерации кода Godot
• Внизу: слоты создания/проверки JSONL docs_chunks, api_mapping, label_prototypes

Почему потребовался отдельный инструмент

Изначально такие запросы делались напрямую в чат‑боте Qwen.

Создайте один фрагмент кода Godot,  
и создайте правильный JSONL и неправильный JSONL в формате `docs_chunks/api_mapping/label_prototypes`.  
Затем проверим, правильно ли выводятся «да/нет», когда объединить `SOURCE_CODE` и JSONL.

Однако при проведении ручного тестирования оказалось, что осей, которые нужно проверять, гораздо больше, чем ожидалось.

| Кодовый критерий | Один общий код или код Godot 3 + код Godot 4 | | Таблица | docs_chunks, api_mapping, label_prototypes | | Характеристика JSONL | Обоснование описания, описание другого кода, требуется преобразование, уже применено, общий/не нужен, преобразование без значения | | Объект проверки | Проверяется ли в том же коде, который создал JSONL, или в противоположной версии кода |

Если это общая грамматика, то слотов 6.

Общий код
  docs_chunks       Обоснование описания / Описание другого кода
  api_mapping       Общий/ненужный / Не относится преобразование
  label_prototypes  Общий/ненужный / Не относится преобразование

Если это синтаксис разделения версий, то слотов 12.

Код Godot 3
docs_chunks       описание основание / другое описание кода
api_mapping       Требуется преобразование / Не требуется преобразование
label_prototypes  требуется преобразование / преобразование не требуется

Godot 4 код
docs_chunks       описание основания / другое описание кода
api_mapping       уже применено / несущественное преобразование
label_prototypes  уже применено / преобразование не имеет значения

Если продолжать делать это вручную, на копирование/вставку и оформление результатов уходит больше времени, чем на сам тест. Поэтому в GUI объединили элементы, код, JSONL и результаты проверки в одном окне.

Общий процесс

flowchart TD
  A["50 тестовых пунктов"] --> B["Выбор пункта"]
  B --> C["Маркировка Qwen"]
  C --> D{"Это общая грамматика?"}
  D -->|"common"| E["Создание общего кода"]
  D -->|"separate"| F["Создание кода Godot 3"]
  D -->|"separate"| G["Создание кода Godot 4"]
  E --> H["6 слотов JSONL"]
  F --> I["6 JSONL по стандарту Godot 3"]
  G --> J["6 JSONL по стандарту Godot 4"]
  I --> K["Проверка кода Godot 3"]
  I --> L["Проверка кода Godot 4"]
  J --> K
  J --> L
  H --> M["Проверка общего кода"]

Инструмент вызывает Qwen в трёх ролях.

Этап маркировки

При щелчке по элементу Qwen сначала определяет, общий ли это синтаксис или он разделён по версиям.

Например, _process(delta) используется как функция обновления кадра и в Godot 3, и в Godot 4, поэтому её можно считать общим синтаксисом.

Напротив, применение скорости и ускорения игрока может различаться в способе вызова move_and_slide() для физического тела, поэтому создаются отдельные коды для Godot 3 и Godot 4.

Проектирование слотов JSONL

Сначала слоты делились лишь на правильный JSONL и неправильный JSONL. Однако такой критерий оказался слишком грубым.

docs_chunks — это обоснование описания. Поэтому, если описание соответствует коду, ответ «да», а если описывает работу другого кода, естественно ответ «нет».

Но api_mapping и label_prototypes — это не просто описания, а основания для преобразования при переходе с Godot 3 на Godot 4. Поэтому, если в уже написанном для Godot 4 коде присутствует api_mapping или label_prototypes с пометкой «да», это может читаться как «это уже Godot 4, а вы всё ещё предлагаете миграцию».

Поэтому названия слотов были изменены следующим образом.

Благодаря этому критерию ответы «да/нет» перестали быть простым определением релевантности и стали оценкой в соответствии с назначением таблицы.

Разделение кода‑генератора и кода‑проверки

Самая важная изменившаяся часть находится здесь.

В первой реализации проверка проводилась только для кода, принадлежащего конкретному слоту.

JSONL, созданный с помощью кода Godot 3
-> Проводится проверка только в коде Godot 3

JSONL, созданный кодом Godot 4
-> Проверка только в коде Godot 4

Однако на практике необходимая проверка шире этого.

JSONL, созданный кодом Godot 3, при присоединении к коду Godot 4 также должен выдавать нет. С другой стороны, нужно посмотреть, какой результат получается, когда JSONL, созданный кодом Godot 4, присоединяется к коду Godot 3. Только так можно найти проблему, когда строки source/target смешиваются и ошибочно выводится да.

Поэтому кнопку разделили на две.

Теперь каждый слот элемента разделения версии может выполнять все перечисленные проверки.

JSONL, созданный кодом Godot 3
  → Проверка кода Godot 3  
  → Проверка кода Godot 4  

JSONL, созданный кодом Godot 4
  → Проверка кода Godot 3  
  → Проверка кода Godot 4

Внутри инструмента это разделяется следующим образом.

Критерий расчёта ожидаемого ответа

Результат проверки всё ещё получает от Qwen в виде «да» или «нет». Однако теперь ожидаемый ответ рассчитывается не только по одному слоту, а учитывает «таблицу + версию создания JSONL + целевую версию проверки + характер слота».

| Неприменимый JSONL | Нет |

Этот критерий скорее не окончательный критерий оценки, а отладочный критерий, позволяющий увидеть, где на текущем этапе происходит расхождение в сопоставлении аргументов Qwen.

Изменения в проверочных подсказках

В проверочную подсказку теперь включается информация о двух версиях.

JSONL_GENERATED_FROM_CODE_VERSION:
godot3

VERIFY_TARGET_CODE_VERSION:
godot4

Такой подход нужен, чтобы Qwen не отвечал «да» только потому, что target_api в JSONL совпадает с текущим кодом.

В api_mapping и label_prototypes важны следующие критерии.

• source_api, source_pattern, input_pattern, before_code, required_when_seen_in_code должны присутствовать непосредственно в текущем коде → «да».
• Если только target_api, after_code, форма recommended target совпадают с текущим кодом, то это уже применённое состояние → «нет».
• Если указано signature_stable, no_change, common и т.п., что означает отсутствие необходимости в преобразовании → «нет».
• Если к коду Godot 4 или к общему синтаксису прикреплён миграционный JSONL, но дополнительное преобразование не требуется → «нет».

Запись тестов 50 пунктов

1/50 Инициализация функции _ready() и установка размеров вьюпорта

3 июля был проверен первый пункт из 50 тестовых пунктов. Этот пункт был помечен как общий код, а эталонный код выглядел следующим образом.

func _ready():
    var vp_size = get_viewport().get_visible_rect().size
    position = Vector2(vp_size.x / 2, vp_size.y / 2)

В начале слот docs_chunks с неправильными ответами назывался 무관 설명 JSONL. Однако при реальном тестировании оказалось, что это название неточно. Этот слот предназначен не для создания намеренно странного или неправильного JSONL, а для того, чтобы Retriever мог подбирать другие официальные описания документации, а Qwen проверял, отфильтрует ли их в финальной верификации.

Поэтому смысл этого слота был уточнён как 다른 코드 설명 JSONL.

В этом тесте проблемный JSONL описывал Viewport.get_visible_rect и _ready(), но фактическое содержание касалось safe area, UI scaling, $Label, $Button.rect_position и других действий кода. SOURCE_CODE читает размер вьюпорта и перемещает position текущего узла в центр экрана, поэтому даже если некоторые API пересекаются, это не считается прямым основанием.

Ожидаемый ответ был 아니오, но Qwen вернул 예. Причина заключалась в том, что проверочный запрос интерпретировал 실제 문자열/API 호출과 직접 일치 слишком широко, принимая описания из других документов, содержащие те же API, как прямое основание.

Изменения:

• Переименовано неправильное название слота docs_chunks с 무관 설명 JSONL на 다른 코드 설명 JSONL.
• В подсказке для создания JSONL этот слот определён как «как кандидат для поиска, некоторые API/темы могут совпадать, но на самом деле описывают другие действия кода в виде официального JSONL».
• В проверочном запросе критерий 예 для docs_chunks усилен: вместо простого совпадения строк API учитывается основная цель кода, целевой объект и конечный результат.
• Даже если тот же API или метод встречается, но JSONL описывает другую цель, другой объект или иной результат, это считается лишь кандидатом для поиска, а не прямым основанием, поэтому указывается 아니오.
• Метки слотов и подсказки в пользовательском интерфейсе также приведены к этим же критериям.
• Добавлен тест в core.test.js, проверяющий сохранение этих критериев в запросе.

2/50 _process(delta) цикл обновления по кадрам

3 июля был проверен пункт 2. Этот пункт Qwen пометил как общий код.

Сводка пометки:

syntax_scope: common
label: _process(delta) обновление по кадрам
reason: В Godot 3 и 4 сигнатура и способ вызова функции _process(delta) одинаковы, и при написании логики на каждый кадр нет синтаксических различий.

Результаты проверки совпали с ожидаемыми ответами во всех 6 слотах.

Этот пункт записывается как пример, когда в общей грамматике docs_chunks получает «да» как обоснование, а api_mapping и label_prototypes получают «нет» как общие/необязательные или несвязанные преобразования, и процесс работает корректно.

3/50 обработка ввода перемещения игрока

Пункт 3 был помечен Qwen как код разделения версии.

Сводка пометок:

syntax_scope: separate
label: Обработка ввода перемещения игрока
reason: Хотя проверка ввода схожа, из‑за введения в Godot 4 функции Input.get_vector() и изменения сигнатуры move_and_slide() у CharacterBody2D необходимо разделить структуру кода.
godot3_focus: Наследование от KinematicBody2D, ручной расчёт velocity.x/y и вызов move_and_slide(up_direction)
godot4_focus: Наследование от CharacterBody2D, упрощённое диагональное перемещение с помощью Input.get_vector() и удаление параметра из move_and_slide()

Результаты проверки:

Несоответствия:

Наблюдения по подсказке:

В гибридном поиске естественно, что вместе с фрагментом кода появляются похожие JSONL‑кандидаты. Поэтому подсказка проверки должна определять, является ли найденный кандидат обоснованием для реального применения к текущему SOURCE_CODE. Три несоответствия показывают, что вопрос недостаточно чётко сформулирован, и Qwen интерпретировал api_mapping и label_prototypes как широкое соответствие, а не как необходимость миграции.

Особенно в случае 3 проявились следующие проблемы:

• Если функция, такая как move_and_slide, встречается как в Godot 3, так и в Godot 4, её одиночное совпадение может заставить Qwen ответить «Да».
• При применении JSONL, созданного для Godot 3, к коду Godot 4, если код уже изменён, label_prototypes · Требуется преобразование не должно давать «Да».
• При применении нейтрального JSONL, созданного для Godot 4, к коду Godot 3, если преобразование не актуально, ответ также не должен быть «Да».
• Ключевой момент — не способ генерации JSONL, а формулировка вопроса проверки. Нужно определить, является ли текущий код «до» изменения, уже «после» изменения или вовсе другим преобразованием.

Поэтому критерий подсказки был изменён следующим образом:

• Вопрос проверки меняется с «Связан ли JSONL с кодом?» на «Нужно ли на основе этого JSONL применять миграцию к текущему SOURCE_CODE?».
• Если текущий SOURCE_CODE уже имеет форму цели Godot 4, даже при наличии описания миграции, следует явно указывать «Нет».
• label_prototypes · Требуется преобразование считается «Да» только когда текущий SOURCE_CODE действительно использует старый способ, параметры и паттерн вызова.
• Нейтральный JSONL считается «Нет», даже если объект проверки — код Godot 3, если к текущему SOURCE_CODE он не применим.
• Каждый поле JSONL служит контекстом для суждения. На этапе проверки необходимо по этому контексту определить, находится ли SOURCE_CODE в «до» или «после» состоянии.
• Поскольку source_api и target_api могут иметь одинаковые имена, а match_terms могут включать термины обеих сторон, простое совпадение имени функции или широких match_terms не считается «Да».
• Даже при совпадении имени функции, должны совпадать аргументы вызова, обработка возвращаемого значения, наследуемый узел, структура окружающего кода — то есть паттерн до‑изменения, описанный в JSONL, должен явно присутствовать в SOURCE_CODE, чтобы ответ был «Да».
• Если JSONL_GENERATED_FROM_CODE_VERSION и VERIFY_TARGET_CODE_VERSION различаются, сначала следует определить, относится ли текущий SOURCE_CODE к коду до изменения или уже к изменённому коду.

4/50 Применение скорости и ускорения перемещения игрока

Пункт 4 также был помечен Qwen как код, разделённый по версиям.

Сводка маркировки:

syntax_scope: separate
label: Применение скорости перемещения игрока и ускорения
reason: В Godot 4 физический узел был изменён с KinematicBody на CharacterBody, и сигнатура move_and_slide() изменилась на передачу аргументов, из‑за чего структура кода изменилась.
godot3_focus: Присвоение скорости свойству velocity, затем вызов move_and_slide(), использование KinematicBody2D/3D
godot4_focus: Передача аргумента move_and_slide(velocity), использование CharacterBody2D/3D, при применении ускорения использовать lerp() или move_toward()

Проверка результатов:

Несоответствия:

Наблюдения по запросу:

Несоответствия в пункте 4 были меньше, чем в пункте 3, но причина та же. Если в api_mapping имена исходных и целевых функций совпадают или похожи, Qwen может дать «Да», полагая, что «этот JSONL описывает изменение функции». Однако в этом инструменте важна не оценка релевантности, а необходимость миграции в текущий код.

Поэтому, исходя из наблюдений до пункта 4, проверочный запрос был усилен: помимо простого совпадения имени API, учитываются следующие аспекты.

• Содержит ли текущий код фактический шаблон до изменения, описанный в JSONL
• Даже при одинаковом имени функции, соответствуют ли аргументы вызова и способ обработки возвращаемого значения коду до изменения
• Если проверяемый код уже находится в пост‑изменённом виде, требуется ли миграция («Нет»)
• Не попадает ли нерелевантный JSONL в ответ «Да» только из‑за простой релевантности

Ограничение максимальной скорости игрока 5/50

Пункт 5 был помечен Qwen как код разделения версий.

Сводка пометок:

syntax_scope: separate
label: Ограничение максимальной скорости игрока
reason: Из‑за изменения названия класса между KinematicBody2D в Godot 3 и CharacterBody2D в Godot 4, а также различий в сигнатуре метода move_and_slide() и способе передачи velocity, требуется отдельный код.
godot3_focus: Наследование от KinematicBody2D, присвоение скорости self.velocity, затем вызов move_and_slide(), ограничение скорости через limit_length()
godot4_focus: Наследование от CharacterBody2D, присвоение скорости переменной velocity, явная передача в move_and_slide(velocity), применение limit_length()

Сгенерированный поток кода:

Результаты проверки:

Несоответствие:

Наблюдения по запросу:

Пункт 5 близок к реальной ситуации гибридного поиска. При последующем поиске в базе данных могут появляться не только полностью несвязанные JSONL, но и похожие кандидаты из той же категории API или обработки перемещения/скорости. В таком случае проверочный запрос должен оценивать не «похожий ли кандидат», а «объясняет ли данный JSONL непосредственно фактическое поведение текущего SOURCE_CODE».

В пункте 5 api_mapping и label_prototypes работали согласно ожиданиям в проверках как для Godot 3, так и для Godot 4. Особенно заметно, что в коде Godot 4 уже применённый вариант или JSONL типа no_change, pattern_validation привёл к ответу «Нет», что можно рассматривать как сигнал смягчения проблем с оценкой миграции, наблюдавшихся в пунктах 3 и 4.

С другой стороны, docs_chunks требует дальнейшего изучения. Поскольку docs_chunks относится не к применимости миграции, а к сопоставлению объяснительных оснований, если только совпадают имена API или версии, это приводит к ответу «Да», что оставляет шум на этапе проверки гибридных кандидатов. Поэтому в последующих проверочных запросах следует более строго проверять, совпадают ли цель, объект и результирующее состояние SOURCE_CODE с описанием в JSONL.

Записи дополнительной проверки 6~10/50

С 6‑й по 10‑й сначала фиксируются результаты, а затем исправляется проверочный запрос. На этом этапе без изменения запроса фиксируется, в каких слотах текущий инструмент дает правильные и неправильные ответы.

Общий итог:

Сводка по пунктам:

Пункты 6, 9 и 10 все оказались в соответствии с ожидаемыми значениями. В пункте 6 потоки Godot 3 PackedScene.instance(), Input.is_mouse_button_pressed(1), get_viewport().get_mouse_position() и Godot 4 instantiate(), InputEventMouseButton, get_global_mouse_position() были разделены, и варианты правильных/неправильных ответов также чётко различились. В пункте 9 варианты, связанные с перемещением и вращением юнита, также были оценены согласно ожиданиям. Пункт 10 отнесён к общему синтаксису, и при обработке выхода за пределы экрана на основе get_viewport_rect().size, global_position, hide() документальное обоснование указано как 예, а варианты миграции типа api_mapping/label_prototypes отмечены как 아니오.

Несоответствия:

Наблюдение:

Если посмотреть на пункты 6–10, в целом наблюдаются сигналы улучшения. Из 102 проверок 97 совпали с ожидаемыми значениями, а пункты 6, 9 и 10 прошли полностью. Особенно в общем пункте 10, где api_mapping и label_prototypes оба получили «нет», это пример того, что подход «не привязывать причины миграции к общему коду» работает в определённой степени.

Оставшиеся несоответствия делятся на две категории. Первая — как в пункте 7, когда обоснование миграции из Godot 3 также получает «да» в коде Godot 4. В этом случае нужно уточнить, является ли текущий код уже изменённым или всё ещё в исходном виде. Вторая — как в пункте 8, когда кандидат docs_chunks поднимается с «да» из‑за схожей темы или похожего API. Здесь важно различать, объясняет ли обоснование реальное поведение SOURCE_CODE или просто является похожим поисковым кандидатом.

Важно отметить, что эту проблему нельзя решать блокировкой конкретных строк или конкретных кандидатов. Когда позже JSONL будет загружен в базу данных и использован гибридный поиск, появление похожих, но разных кандидатов будет нормой. Поэтому последующие правки должны быть направлены не на искусственное отсеивание кандидатов, а на то, чтобы проверочный запрос точнее оценивал связь между текущим SOURCE_CODE и найденными кандидатами.

Усиление проверочного запроса после записи:

• В docs_chunks проверяется, объясняет ли JSONL текущую работу кода версии, выбранной для проверки, когда версия создания JSONL отличается от версии, подлежащей проверке.

• Даже если версии различаются, при явном описании общего API/общего поведения это может быть «да», но если кандидат описывает структуру кода или различия узлов/API между версиями, необходимо отдельно убедиться, что поведение соответствует текущему SOURCE_CODE.

• В api_mapping и label_prototypes сначала определяется, является ли текущий SOURCE_CODE кодом до изменения, уже изменённым кодом, нерелевантным кодом или кодом, не требующим преобразования.

• В примере было сделано так, чтобы предложение было чётким, позволяя только в случае, когда текущий SOURCE_CODE — код до изменения, и преобразование, описанное в JSONL, должно быть применено сейчас.

• Это усиление не относится к способу обработки конкретных строк, а усиливает процедуру оценки кандидатов, полученных гибридным поиском, на основе текущего кода.

Проверка результатов верификации

Результаты верификации отображаются отдельно по версиям под каждым слотом.

Таким образом, внутри одного слота можно сразу увидеть следующее.

Godot 3 перед проверкой кода / ответ / ожидание / соответствие  
Godot 4 перед проверкой кода / ответ / ожидание / соответствие

Раньше отображалось только «Этот JSONL правильный/неправильный». Теперь можно увидеть «правильный/неправильный при присоединении к определённому коду».

Проблема, решённая текущим инструментом

| Godot 3 JSONL проверяется только в коде Godot 3 | Проверка возможна как в коде Godot 3, так и в Godot 4 | | Результаты копируются вручную и запоминаются | Для каждого слота сохраняются raw‑response, prompt и результаты проверки | | Трудно отследить причину сбоя | Можно сразу увидеть, в каком слоте и при какой проверке произошла ошибка | | Тестирование 50 пунктов фактически требует ручной работы | Предоставляются кнопки загрузки образцов, добавления/удаления пунктов, генерации всех и проверки всех |

Изменения в продуктивности разработки

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

1. Описание тестовых пунктов для Qwen  
2. Запрос кода Godot 3  
3. Запрос кода Godot 4  
4. Запрос JSONL с правильными/неправильными ответами docs_chunks  
5. Запрос JSONL с правильными/неправильными ответами api_mapping  
6. Запрос JSONL с правильными/неправильными ответами label_prototypes  
7. Снова соединить каждый JSONL с SOURCE_CODE и проверить  
8. Записать результаты «да/нет» вручную  
9. Сравнить в уме, соответствует ли ожидаемое значение

Сейчас тот же поток зафиксирован в экране.

1. Нажмите элемент  
2. Создать AI‑метку  
3. Сгенерировать общий код или код Godot 3/4  
4. Сгенерировать JSONL по слотам  
5. Проверка кода Godot 3 / проверка кода Godot 4  
6. Просмотр результатов и проверка подсказки/ответа

Особенно часть, где повысилась продуктивность, ближе к «не запутываться», чем к «быстро делать много». В этой работе важнее, чем просто объём генерации, чтобы критерий оценки не менялся. С появлением инструмента стало проще:

• Сначала фиксировать, является ли это общей грамматикой или разделением по версиям
• На экране постоянно проверять назначение JSONL для каждой таблицы
• Разделять ожидаемые критерии генерации и фактические результаты проверки
• Перекрёстно проверять один и тот же JSONL в коде Godot 3/4
• Сразу просматривать подсказку и raw‑response для неудавшегося слота
• При повторении 50 пунктов уменьшать количество состояний, которые человек должен помнить

Пока открытые вопросы

Этот инструмент ещё не является окончательным оценщиком. Сейчас это отладочный инструмент.

Открытые вопросы таковы:

• Обоснование docs_chunks может быть признано общим описанием, даже если версии различаются.
• В api_mapping, если строки source/target обе попадают в JSONL, Qwen может увидеть только строку target и ответить «да».
• Для label_prototypes важнее различать паттерны before/after, чем простое совпадение строк.
• Текущий расчёт ожидаемого ответа служит лишь для отладки; позже критерии реального расчёта score/F1 нужно будет доработать.
• Проблемы выбора кандидатов для поиска и оценки проверочных подсказок трудно разделить, глядя только на результат.

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

28 июня было ощущение «давайте вручную проведём 50 тестов». На практике оказалось, что осей для тестирования слишком много, и когда смешиваются общая грамматика, разделение по версиям, критерий генерации и версия проверяемого объекта, быстро возникает путаница.

30 июня, создавая инструмент, эта проблема была довольно сильно упорядочена. Теперь Qwen‑созданный JSONL рассматривается не просто как «правильный/неправильный», а с указанием, в каком коде он был сгенерирован и в каком коде проверен.

Этот инструмент можно будет использовать и после добавления реальных результатов поиска в docs_chunks, api_mapping, label_prototypes. То есть он стал базовым средством, пригодным не только для ручных демонстрационных данных, но и для проверки результатов поиска в базе данных.