Сегодня цель — определить, какой из вариантов поиска/валидации выбрать.
При сохранении chunkText как входных данных нужно решить, как комбинировать BM25, полнотекстовый поиск PostgreSQL, embedding, reranker и валидатор Qwen direct‑evidence.
Сначала не было окончательного проекта, а лишь собранные материалы о плюсах и минусах каждого способа поиска и ответы «да»/«нет», полученные от ChatGPT.
Затем, опираясь на симуляцию каждого варианта и сводную сравнительную таблицу, было решено отдать приоритет стратегии F.
То есть — chunkText остаётся поисковым вводом, BM25 и embedding собирают широкий набор кандидатов, затем reranker переупорядочивает их, а в конце Qwen проверяет, действительно ли найденный JSONL соответствует текущему коду‑чанку.
Следующая проверка будет выполнена Qwen для таблиц docs_chunks, api_mapping, label_prototypes, по 50 примеров в каждой.
В каждой таблице будет отобрано около 50 образцов, разделённых на релевантные и нерелевантные случаи, чтобы увидеть, как различаются ответы «да» и «нет».
Этот тест проверяет не только качество поиска, но и то, признаёт ли валидатор Qwen найденный JSONL доказательством, соответствующим реальному коду‑чанку, или отклоняет его.
При ручном выполнении объём тестов оказался гораздо больше, чем ожидалось.
Было создано 50 тестовых пунктов для Godot, и для каждого из них необходимо проверить все три таблицы: docs_chunks, api_mapping, label_prototypes.
Если речь идёт о общей функции/синтаксисе, создаётся один Godot‑чанк, а затем формируются ожидаемые данные «да»/«нет» для каждой из трёх таблиц; после этого в запрос включаются промпт, тестовый код и шесть наборов данных, чтобы проанализировать, как меняется паттерн ответов.
Если функция не общая, приходится делать отдельные версии кода для Godot 3 и Godot 4, что удваивает объём работы.
Чтобы позже собрать метрики классификации (например, F1‑score), необходимо вручную фиксировать true/false для всех случаев.
Поэтому было решено, что завершить все 50 пунктов за один день невозможно; сегодня планируется обработать 5 пунктов.
После выполнения пяти пунктов вместо простого увеличения количества тестов будет проведён анализ уже полученных паттернов ответов «да»/«нет».
Фактически было выполнено 5 из 50 пунктов.
Уже после пяти пунктов заметно различие в потоках ответов между JSONL, созданными по версии Godot 3, и JSONL, созданными по версии Godot 4.
Особенно в коде с различиями версий может случиться, что при проверке кода Godot 4 с помощью JSONL для Godot 3 получаем «да» из‑за общих строк или миграционных доказательств; наоборот, при проверке кода Godot 3 JSONL‑файлом для Godot 4 результаты могут стать неоднозначными, если перемешаны строки source/target.
Поэтому в следующих тестах необходимо не только проверять, совпадают ли шесть ответов «да/нет», но и сначала разделять их по типу (общий синтаксис vs различия версий), а затем фиксировать отдельные версии «версия создания JSONL» и «версия проверяемого кода», записывая сырые ответы.
Это показывает, что проблема не только в корректировке промпта, но и в необходимости пересмотреть стратегии промптинга и сбора датасетов.
В дальнейшем при создании JSONL следует более чётко разделять сбор/генерацию данных по категориям: общий синтаксис, доказательства только для Godot 3, доказательства только для Godot 4, двунаправленные миграционные доказательства.
Кроме того, продолжается преобразование официальной документации из Markdown в JSONL; на текущий день из 1 570 Markdown‑файлов уже преобразовано около 600 в JSONL.