2026-06-28 Ретроспектива

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

Программа отладки AST, которую мы создали, извлекает фрагменты кода из проекта Godot. На основе этих фрагментов нужно было придумать стратегию поиска в таблицах docs_chunks, api_mapping, label_prototypes в JSONL. Поэтому я описал стратегии от A до F и в текущий момент выбрал стратегию F.

Сейчас процесс сбора Markdown в JSONL ещё идёт, поэтому сразу протестировать поиск в базе и работу ретривера сложно. Поэтому я сегодня создал 50 чек‑листов и попросил Qwen сгенерировать произвольный код Godot. Я также подготовил соответствующий и несоответствующий JSONL, и проверил, как Qwen оценивает их, когда я передаю jsonl + prompt + chunk. Я попробовал около пяти примеров и уже понял, что эта работа требует гораздо больше усилий, чем я ожидал.

План тестов на 50 пунктов и реальность

Изначально я планировал протестировать все 50 функций Godot.

Но на практике оказалось, что идеалы и реальность различаются. Сначала я составил список из 50 функций, которые часто встречаются в виде отдельных функций или небольших блоков кода в Godot 3, и оформил его в виде документа. Затем я подготовил шаблон подсказки, который будет использоваться при передаче jsonl + prompt + chunk, чтобы проверить, будет ли Qwen правильно определять соответствие с ответом «да» (да) или «нет» (нет).

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

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

Если синтаксис общий, достаточно одного кода, чтобы проверить успешные и неуспешные JSONL во всех трёх таблицах. Если же синтаксис различается, пришлось готовить варианты как для Godot 3, так и для Godot 4. Затем нужно было сравнивать результаты, когда JSONL, созданный для Godot 3, используется с кодом Godot 3, с кодом Godot 4, и наоборот.

В итоге сегодня я протестировал лишь около пяти из пятидесяти пунктов. Это гораздо меньше первоначального плана, но, возможно, лучше остановиться на этом этапе. Если бы я попытался вручную обработать все 50 пунктов, столкнулся бы с серьёзными трудностями.

Общий синтаксис и версия

Во время тестов я понял, что делить Godot 3 и Godot 4 просто на две категории слишком упрощённо.

Некоторые функции имеют почти одинаковый синтаксис в обеих версиях. В таком случае пытаться определить, относится ли код исключительно к Godot 3 или Godot 4, выглядит искусственно. Если синтаксис общий, следует рассматривать его как общий и проверять, правильно ли разделяются релевантные и нерелевантные JSONL в docs_chunks, api_mapping, label_prototypes.

Для функций, где есть различия между версиями, ситуация сложнее. JSONL, созданный для Godot 3, может дать ответ «да» и при проверке кода Godot 4, и наоборот, из‑за некоторых полей. Особенно проблематичны JSONL, связанные с миграцией, где одновременно присутствуют строки source и target, и простое строковое сопоставление может дать неоднозначный результат.

Поэтому я пришёл к выводу, что необходимо фиксировать два параметра: какой версии был создан JSONL и какой версии соответствует проверяемый код. Даже если ответ «да», нужно различать, является ли он результатом общего синтаксиса или же неоднозначным случаем, когда в строках присутствуют и source, и target.

Нужно фиксировать F1‑score

Если просто записывать «успех» или «неуспех», потом будет трудно анализировать паттерны.

Я предлагаю сохранять сырые результаты оценки, а не сразу вычислять F1‑score. Например, фиксировать, когда должен был быть «да», но получен «нет», и наоборот; а также отмечать, является ли «да» результатом общего синтаксиса или неоднозначного случая миграции. Такой журнал позволит позже понять, где проблема — в подсказке, в генерации JSONL или в дизайне полей таблиц. Если же продолжать записывать всё вручную без структуры, будет сложно отследить причины ответов.

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

Ограничения ручного тестирования

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

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

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

Поэтому я задумался о создании инструмента отладки: один интерфейс, где можно загрузить фрагмент кода, указать тип таблицы, версию JSONL, версию проверяемого кода, ожидаемый и полученный ответ, а затем автоматически сохранять результат вызова Qwen. Как и при просмотре AST и ретривера в веб‑интерфейсе, такой GUI‑инструмент упростил бы тестирование соответствий JSONL.

Проблемы генерации тестовых данных для Qwen‑чатбота

Сегодня я размышлял о том, как с помощью Qwen‑чатбота генерировать произвольные тестовые данные.

Мне хотелось создать небольшой набор демо‑данных, который позволил бы «потрясти» процесс валидации. Идея: попросить чатбота сгенерировать один фрагмент кода Godot 3, один фрагмент кода Godot 4 и соответствующие релевантные и нерелевантные JSONL для docs_chunks, api_mapping, label_prototypes.

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

Сегодня я понял, что необходимо более точно формулировать подсказки для создания тестовых данных, чтобы убедиться, что Qwen действительно опирается только на строки‑доказательства из JSONL, а не на свои собственные знания.

Сегодняшний вывод

Сегодня был не столько день массового тестирования, сколько день, когда я убедился, что стратегии поиска Retriever и эксперименты по сопоставлению JSONL на основе чат‑бота Qwen требуют гораздо больше усилий, чем я ожидал.

Сначала я думал, что смогу выполнить все 50 тестов. Однако на практике уже 5 тестов показали достаточно проблем. Иногда Godot 3 и Godot 4 полностью расходятся, но есть и общие синтаксисы, а в случаях вроде migration JSONL, когда source и target находятся вместе, оценка может колебаться.

Поэтому сейчас нужно не просто бездумно увеличивать количество тестов, а создать структуру, в которой результаты тестов фиксируются правильно: версия создания JSONL, версия проверочного кода, тип таблицы, ожидаемый ответ, фактический ответ, неоднозначные причины. Тогда, даже после выполнения всех 50 тестов, мы получим не просто субъективные впечатления, а наблюдаемые паттерны.

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