2026-07-03 Ретроспектива

Что было сделано сегодня

Сегодня я просто включил 24‑часовой стрим на YouTube, запустил сбор данных, провёл тест перевода и, используя инструмент проверки, созданный 30 июня, продолжил проверку.

В части Markdown → JSONL Converter количество собранных записей из официальной документации JSONL выросло с 737 до 850. Сегодня я также не стал запускать крупные новые реализации, а продолжал сбор, пока работает RunPod, и постепенно проверял процесс проверки и перевода.

В части перевода мы экспериментируем с отдельным конвейером, использующим бесплатный API модели NVIDIA. Через секреты GitHub workflow мы увидели некоторый успех и проверили экран, где генерируются README на японском/китайском. Пока ещё нельзя сказать, что это полностью внедрено, но по мере роста количества документации идея автоматического потока перевода становится всё сильнее.

Смысл создания инструмента проверки

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

Если бы мы действовали по старому методу, нам пришлось бы заставлять Qwen отдельно создавать код и JSONL, затем вставлять их в подсказку и сравнивать ожидаемый ответ в уме. Сейчас достаточно нажать на пункт, сгенерировать код и JSONL, запустить проверку для кода Godot 3 и кода Godot 4, а также увидеть raw prompt и raw response на одном экране. Ручная работа всё ещё есть, но, по крайней мере, теперь можно увидеть, что именно ошибочно, не упуская из виду.

Сегодня я проверил первые 10 из 50 тестовых пунктов, нажимая их последовательно. В процессе обнаружились случаи, когда LLM выдавал неправильные ответы.

• В пункте 1 кандидат docs_chunks был отмечен как «да», потому что имел те же подсказки _ready() или связанные с viewport, хотя на самом деле это было описание другого кода.
• В пунктах 3, 4 и 7, несмотря на то что JSONL миграции из Godot 3 уже был прикреплён к коду в формате Godot 4, система всё равно выдавала «да».
• В пункте 8 кандидат docs_chunks был признан «да», так как касался той же темы отслеживания/перемещения или похожего API, хотя фактическое поведение текущего SOURCE_CODE отличалось.
• В пунктах 6, 9 и 10 все элементы прошли проверку согласно ожиданиям, что показывает, что направление улучшения вовсе не ошибочно.

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

Впечатления

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

Проверка занимает больше времени, чем предполагалось. Даже если кажется, что достаточно посмотреть один файл кода и один JSONL, свойства docs_chunks, api_mapping, label_prototypes различаются, а также коды для Godot 3 и Godot 4 отличаются. Уже при обработке десяти таких пар появляется довольно много вариантов.

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

Если бы нужно было улучшить процесс, можно было бы не только полагаться на RunPod, но и использовать бесплатные API. Если бесплатные модели NVIDIA или другие бесплатные эндпоинты смогут надёжно выполнять такие задачи, как перевод, вспомогательная проверка и синхронизация документов, то зависимость от RunPod можно будет несколько снизить.